Since Congress instituted the Federal Information Security Management Act (FISMA) of 2002 to address information security challenges facing government agencies, the National Institute of Standards and Technology (NIST) has regularly recommended new guidance to help give agencies a clearer deployment path to a more robust information security program. Some soon to be published, recently published and recently updated guidance includes;
- NIST SP 800-137: Information Security Continuous Monitoring for Federal Information Systems and Organizations (final revision scheduled for May 2011) developing a continuous monitoring strategy and implementing a related program.
- NIST SP 800-39, Revision 1: Guide for Applying the Risk Management Framework to Federal Information Systems (published Dec 2010) establishes a Risk Management Framework (RMF) that promotes the concept of near-real-time risk management through the implementation of a continuous monitoring process.
- NIST SP 800‐53, Rev 3: Recommended Security Controls for Federal Information Systems and Organizations(published May 2010) defines many of the technical security controls needed to implement both SP 800-137 and SP 800-39.
Continuous Monitoring, along with APT and malware, seems to be top of mind right now across all civilian, DOD and intelligence agencies. While these sets of guidance can be interpreted, deployed and audited in a wide variety of ways, let’s try to interpret what NIST is actually trying to say about Continuous Monitoring. As we all know, the spirit of the “law” (though I know we’re talking about “guidance” in this case), getting the compliance box checked, and actually being secure can be very different things. First, we need to understand exactly what NIST means by “Continuous Monitoring.” According to NIST, most organizations tend to associate monitoring with periodic security assessments, system reauthorizations, data analysis and associated reporting. In addition to these passive security practices, NIST states that a well-designed continuous monitoring strategy must also include proactive testing to effectively mitigate risk. NIST describes continuous monitoring as helping to “ensure ongoing situational awareness and control of the security of systems across the organization and ongoing knowledge of associated threats and vulnerabilities, despite inevitable changes to organizational information systems and their environments of operation.” As part of the continuous monitoring documents, NIST SP 800-137 states that the following are “essential to organization-wide continuous monitoring”: 1. Ongoing assessment of security controls – Read this as, “Test the stuff you already bought and figure out if it is working.” 2. Configuration management, change control and a corresponding security impact analyses – In other words, “If you make a change, like standing up a new app, what is the overall effect? Are you more secure or less secure now?” 3. Security status reporting – When doing this, you need to consider the metrics and reports you are using. Do they reflect the real risks your organization is facing? The third point above deals with numbers/metrics/reports, though it’s not about getting numbers for the sake of having more data. Most CSOs I’ve spoken with (commercial, federal – doesn’t matter) state quite emphatically in fact, that they don’t need more data or more tools – but instead that they need to get better (yes I know) information from the volume of data they already have. NIST is asking us to measure and collect data in a way that most accurately pinpoints and validates actual risks to critical assets, while also specifying that the data be meaningful and actionable.NIST recognizes this not only by emphasizing security data collection, but also by specifying that the data be meaningful and actionable. For instance, NIST SP 800-137 states that, “Metrics are measures that have been organized into meaningful information to support decision making. Metrics are developed for system-level data to make it meaningful in the context of mission/business or organizational risk management.” So what does all this mean? Here’s my take on it, in a nut shell:
- Figure out if your most secure information is actually secure.
- Test and retest your security regularly (once a quarter doesn’t cut it, let alone once a year).
- Be able to prove whether your security controls working.
- Ask yourself what you really are reporting on. Is getting detail on the 358,453rd malware attempt in your environment important – or is it more important to gain metrics that a line of business manager or executive will actually care about (and frankly understand)?
If you don’t have an integrated, repeatable security methodology in place today that will allow you to accomplish all of this, now would be a good time to put one together …