According to the National Institute of Standards and Technology (NIST), Information Security Continuous Monitoring (ISCM) is a process for continuously analyzing, reporting, and responding to risks to operational resilience (in an automated manner, whenever possible). Compared to the traditional method of collecting and assessing risks at longer intervals--for instance, monthly or annually--ISCM promises to provide near-real-time situational awareness of an organization's risk profile. ISCM creates challenges as well as benefits, however, because the velocity of information gathered using ISCM is drastically increased. Development, operation, and maintenance processes built for a more leisurely pace can thus be overwhelmed. This blog post explores how organizations can leverage Agile methods to keep pace with the increased velocity of ISCM risk information, while ensuring that changes to systems are conducted in a controlled manner.

Agile methods enable organizations to more rapidly address changes in requirements for organizational services and assets. In the field of operational resilience, risks form the basis for such requirements. Risk management of organizational services and assets may be simple (e.g., patch a workstation) or complex (e.g., patch a service relied upon by an enterprise information system). By combining ISCM, risk management, and Agile, organizations can manage both simple and complex changes to organizational services and assets in a structured yet nimble manner.

Figure 1 below depicts the process of implementing ISCM as described in NIST Special Publication (SP) 800-137. During the day-to-day implementation of ISCM, risks will be identified at a far greater velocity than an organization may be used to.

NIST SP 800-137 describes ISCM in a three-tier implementation:

1. Organization. It is at this level where the risk executive function defines the risk management policies, to include risk tolerances for the organization as a whole.
2. Mission/business processes. It is at this level that program management of the organization's assets and services occurs.
3. Information system. Functions at this level ensure that technical, operational, and management controls are performed at the information-system level.

Data that supports risk-management-related measurement and analysis is generally collected at the information systems tier but can be coupled with other data at each subsequent tier. Data is assessed quantitatively and qualitatively to support risk management functions at each tier via tools. This analyzed data informs risk management decisions at each tier and the tiers below them.

As old risks are mitigated and new ones are identified, the prioritization of these risks will change according to the frequency of collection, analysis, and the organization's criteria for risk management decisions. Developers and administrators implementing risk mitigations may often find themselves overwhelmed by these changes in risk prioritizations. The resulting situation may be similar to playing the popular arcade game Whack-a-Mole, in which the player successfully whacks one mole only for one or two others to pop up elsewhere. If these new resilience requirements are not organized in an actionable way, risk mitigations may become ad hoc or incomplete because developers and administrators may prematurely cease working on the last set of prioritized risks to begin working on the new set.

In a previous organization where I was in charge of system security, we instituted an ISCM program that vastly increased the velocity of prioritized vulnerability information. Our process was to calculate a composite score based on the quantity of vulnerabilities on a machine, the average length of time vulnerabilities were present on the machine, and the average severity level of the vulnerabilities. This approach solved one problem: ensuring that developers and administrators balanced the mitigation of new risks with the need to mitigate old risks. However, ISCM posed a new problem: Every couple of days, developers and administrators faced a new prioritized list due to the patching they had done since receiving the previous set of vulnerability information. Other leaders in the organization and I did not want developers and administrators to feel compelled to cut corners when testing components that rely on the component being updated; doing so would, in turn, degrade the confidentiality, integrity, and available of organizational services and assets. However, we wanted risk mitigation to respond to changes in priority. Consequently, we decided to create snapshots of risks we wanted to mitigate at any given time.

According to Paul E. McMahon, in his book, Integrating CMMI® and Agile Development, "The phrase 'Agile approach' refers to the extension of Agile concepts to include the critical domains of Systems Engineering and Project Management, and software." Functionality is delivered in sprints of approximately one to four weeks. Requirements are documented in user stories that are then identified from a project backlog for inclusion in the next sprint. The sprint itself is an atomic unit of work, meaning that it encompasses not only the development of the functionality but also testing to ensure that changes to the system do not engender additional problems. At the end of the sprint, a fully functional piece of work is delivered and implemented. Work is managed through a process called Scrum. While a full discussion of Agile, and related techniques, such as Scrum and Kanban, is beyond the scope of this blog post, Agile can be summarized in the 12 principles behind the Agile manifesto.

In my previous organization, although the process I described exhibited some of the features of Agile, it was not Agile. In hindsight, we could have developed multi-functional sprint teams consisting of developers, administrators, and security personnel who would see each set of system changes from cradle to grave. We could have benefitted from use of methods such as Scrum to improve communication between these three categories of professionals. Use of Kanban--a method to control the flow of work in an Agile project--could have better ensured that system changes reached fruition more quickly and in a more controlled fashion.

The use of ISCM to develop operational resilience requirements, coupled with the short-time-cycle nature of the Agile methodology, enables risk management that can evolve and adapt to changes in threat intelligence but must be implemented in a controlled, deliberate fashion. That is, organizations can better respond to changing priorities by managing risks as a requirements backlog. Risk mitigations are assigned to a sprint, and the sprint team mitigates the risks through to completion, including testing any components that may rely on that service. Meanwhile, risk mitigations still in the backlog are re-prioritized based on changing risk management considerations.

ISCM can help organizations to adapt more quickly to changing risk environments. By leveraging Agile methods to manage the work necessary to mitigate these risks, organizations can ensure that changes to organizational services and assets are made in a methodical way that ensures the organization can adapt to that changing risk environment.

We are interested in your feedback. If you have a success story (or a cautionary tale) regarding using Agile to support risk mitigation, we would love to hear from you. Please take a moment to provide some feedback in the comment section below. As always, please be sure not to include any sensitive information.

Additional Resources

Suzanne Miller and Mary Ann Lapham have recorded a series of 12 podcasts exploring the application of the 12 Agile principles across the DoD. To listen to those podcasts, please click here.