Continuous monitoring, also known as continuous controls monitoring, continuous re-authorization, continuous diagnostics and mitigation (CDM), or just CM, is not yet mandatory in the federal government, but will be soon. All government agencies are supposed to be thinking about it, and planning and budgeting for it in the future, but only a handful of the most forward-thinking agencies have tried to do it in earnest.
The largest part of CM is continuously assessing your residual risk by checking your controls. It is continuously giving assurance to the AO who gave you permission to operate your Information System, that it is still at least as secure as the day they approved it. It is not to be confused with network security monitoring, and it is not something that is satisfied just by having a SIEM installed. We are talking about a broader and different context of monitoring.
One large obstacle in the discussion of continuous monitoring is the semantic differences and confusion caused by the terms continuous, constant, and automated. Continuous is in many ways just a relative term. OMB A-130 defined a three-year cycle for assessing controls, so any increment less than that can seem “continuous” in comparison. “Continuous” does not mean “constant”, however. NIST states in 800-137 that controls should be “assessed and analyzed at a frequency sufficient to support risk-based security decisions to adequately protect organization information”.
Another layer of confusion ensues when people start to equate “continuous” with “automated”. All of an Information System’s controls should be continuously monitored whether or not there are automated means. Some controls simply must be assessed manually.
Those agencies who are attempting continuous monitoring, however, are often focused more on a narrow band of controls, like vulnerability and configuration scanning, which are easily automated and / or seem more critical than other controls. Process-oriented controls like policy-writing and personnel security haven’t received much attention in the continuous monitoring world. While some controls are less important, none are unimportant, and there is no consensus on the frequencies and methods that should be used for an effective and comprehensive continuous control monitoring strategy (stay tuned for upcoming white paper on this subject). There are some written guidelines in the federal community, but many of them are in draft. The first two publications to mention concerning CM are NIST SP 800-37 Rev 1 and NIST SP 800-137.
800-37 Rev 1 describes NIST’s Risk Management Framework (RMF). Rev 1 was the first time NIST defined their RMF (the new way of saying C&A) and a new emphasis was put on the monitoring phase to set the stage for 800-137. SP 800-137 is the de facto CM bible right now. http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf . It is CM theory, not instructions, and it is written at a fairly high level. It can be ephemeral at times for people who are looking for explicit guidance (“Just tell what I need to do to comply!”). Chapter Three is the most specific in this publication and I will be covering a lot of that material in the third part of this blog series. SP 800-137 does a great job of emphasizing that CM means both continuous manual and automated assessments.
There are three other CM documents worth mentioning: NISTIRs 7756, 7799, and 7800. http://csrc.nist.gov/publications/PubsNISTIRs.html. These cover Continuous Asset Evaluation, Situational Awareness, and Risk Scoring Framework Extension (CAESARS FE). All three are still in draft. The point of these three NISITRs is to cover the CAESARS model defined by DHS, which is a CM model, in turn, based on the iPost model developed by the State Department. All of these models will be covered in more detail in my next installment of this series.
NISTIR 7756 is the introductory document of the CAESARS FE. It defines the components that should be present in a mature CM implementation and the roles of those components. They are referred to as subsystems, and there are six: Presentation/Reporting, Content, Collection, Data Aggregation, Analysis/Scoring, and the Task Manager. Most of the data collection discussed in 7756 is to support automated monitoring. The report is also ready to point out, however, that a CM model should also allow for non-automated controls which “will require some human data collection effort”.
NISTIR 7799 builds upon 7756. It takes the six previously defined subsystems and describes ways they can act in very complex use cases. The entire report is devoted to describing all of the possible work flows between the six subsystems. This means defining all of the possible inputs and outputs from one subsystem to another.
NISTIR 7800 defines how to bind the model described so far in 7756 and 7799 to three specific CM domains: vulnerability, configuration, and asset management. While describing how to do this, the report covers special XML formats called Security Content Automation Protocol (SCAP) specifications. These are covered below. Given the fact that 7800 only covers three CM domains and NIST defines “at least 11” in NISTIR 7756, one can guess that there will be future draft NISTIRs that cover the domains not listed in 7800 such as event, incident, malware, etc.
So, that’s a good starting point. Tune in February 11 for the next installment which covers iPost, CAESARS, CAESARS FE, what you can steal from those models, and how to apply those ideas to your organization.
Email me with any comments. Thanks!
Chris
