Skip navigation
All Places > Products > RSA Archer Suite > Blog > 2013 > March > 25

So far in this series I talked about CM documentation and CM models. What’s next?

     Beginning with the assumption that you are already using NIST RMF (or possibly DIACAP if in the military space) you build on what you’re already doing. This means you already have defined roles and responsibilities for A&A/C&A processes. Start there. It is essentially the same process but more frequent. CM should also start with the tools you already have. Implementing CM doesn’t mean reinventing and replacing all your current processes and tools. The A&A stakeholders need to first get together and establish monitoring strategies and agree on some model of measures and metrics.

       Every system owner needs a monitoring strategy for every Information System they own. Every common control provider needs a monitoring strategy for the controls they offer. A monitoring strategy should 1) account for every control that is allocated to a system and 2) say whether each control is manually or automatically assessed and 3) at what frequency.

     Which should be automated? Any that you can, right? Sadly, a small percentage of the controls in NIST SP 800-53 are conducive to automated assessment, and NIST has not made a declaration (or even recommendation) on which they are. For now, this has to be determined by your organization. One good indicator is that controls beginning with “The Information System…” are usually better candidates for automated assessment than the ones that begin “The organization…”. Some families are more automatable than others.

     It also boils down to which tools you have in place. If you have a good configuration scanning tool and program in place, you can automatically assess a few controls in the CM family. If you have an asset management tool, you can automate CM-8. Automated patch management gets you SI-2. Etc. You get the idea. This will be a tedious process for your organization to go through the first time. It will be slightly different for each Information System and each organization, but even an organization with mature processes and technologies would be challenged to automate a couple dozen controls worth of assessments.

The rest will of course be manual. AT, CP, MP, and PS are examples of control families with few if any automatable controls. Policy and process-oriented controls, physical and personnel controls, and even many technical controls cannot be automatically assessed. This is the point where, if you’re one of those organizations that brings in a third party assessor every time ($$$), you may want to reconsider hiring your own internal assessors. You’ll get your money’s worth out of them.

So, most of you know about SCAP by now. It’s a group of specialized XML formats that enable automation and enable security tools to share scan data, analyses, and results. I won’t talk about SCAP today in the interest of brevity, other than to say, of course, use it where you can and upgrade to tools that use SCAP when you can. The common language element provided by XML and by SCAP means that disparate tools and organizations can share data now where they couldn’t before, including high-volume, frequent scan data across huge ranges of hosts. SCAP has reduced obstacles in scanning and reporting workflow and so, has increased the frequency with which some scans can be performed. The point of interjecting SCAP into this discussion is to point out that automated assessments will be streamlined by this new technology, and automation is a significant consideration as to the frequency of assessments. Which leads to…

 

How to determine the frequency for each control assessment? There are a few important factors:

 

What is the criticality of the Information System? This can be decided by the criticality from a BIA and/or from the Security Category assigned according to FIPS 199 & NIST SP 800-60. A system with a higher criticality or Security Category should have its controls assessed more often. A system with a lower criticality or Security Category should have its controls assessed less often.

Is it automated or manual? Manual controls can likely not be assessed as frequently as automated controls. This is just a sheer logistical truth. A fixed amount of employees can only perform so many manual assessments in an allotted time. Automated controls, however, despite the potential for much higher frequency, should only be assessed as often as is useful. An enterprise patch scan may be run daily, for example. Running two patch scans a day would take twice the effort, but may not be twice as useful.

How volatile is the control? A control that is known to change more often should be assessed more often. This means, for example, configuration checks should be assessed more often than a written policy, because the former would change much more often than the latter. (I am just finishing a white paper on the subject on CM monitoring strategies. It should be available in the next week or so. Email me if you’d like a copy when it is done.)

So, you’ve figured out your monitoring strategy. Next is implementation and then scoring and reporting, which you have to figure out on your own because it’s specific to your environment and organization - but email me if you’d like to see a demo of Archer’s CM solution, and even if you don’t decide to buy it on the spot, you can maybe get some ideas you can use by seeing how we’ve done it. I’d also mention for the scoring piece, look at iPost and the original CAESARS for clear, simple, scoring models.

     Lastly, how do you know when you’re done? You’ll probably never be done, right? … but how do you know when you’re adequate? To answer this, I will close with this cool little yardstick, (with thanks to Peter Mell of NIST). This scale gives us all a lot to aspire to.

Level 0: Manual Assessment – Security assessments lack automated solutions

Level 1: Automated Scanning

o    Decentralized use of automated scanning tools

o    Either provided centrally or acquired per system

o    Reports generated independently for each system

Level 2: Standardized Measurement

o    Reports generated independently for each system

o    Enable use of standardized content (e.g., USGCB/FDCC, CVE, CCE)

Level 3: Continuous Monitoring

o    Reports generated independently for each system

o    Federated control of automated scanning tools

o    Diverse security measurements aggregated into risk scores

o    Requires standard measurement system, metrics, and enumerations

o    Comparative risk scoring is provided to enterprise (e.g., through dashboards)

o    Remediation is motivated and tracked by distribution of risk scores

Maturity level 4: Adaptable Continuous Monitoring

o    Enable plug-and-play CM components (e.g., using standard interfaces)

o    Result formats are standardized

o    Centrally initiated ad-hoc automated querying throughout enterprise

o    on diverse devices (e.g., for the latest US-CERT alert)

Maturity level 5: Continuous Management

o    Risk remedy capabilities added (both mitigation and remediation)

o    Centrally initiated ad-hoc automated remediation throughout enterprise on diverse devices (with review and approval of individual operating units)

o    Requires adoption of standards based remediation languages, policy devices, and validated tools

 

Thanks for tuning in for this 3-part series on continuous monitoring! As always, any questions or comments, email me.

 

Chris

Over the last few blog entries, I outlined some of the dimensions that security operations need to think about during 2013 and beyond.   In some respects, this is the tip of the iceberg – there is only so much you can cover in a blog.   However, I think there are some important items to put on the radar.

 

First, Business Context is becoming a big priority for security.  No longer can companies chase vulnerabilities and events around the infrastructure.  There has to be a layer on top of the monitoring and analysis processes that is cognizant of the business impact.  This is not just about prioritizing events but understanding the business impact when specific systems are involved.  Escalation of a security incident can be triggered by the nature of the events, the magnitude of the threat or the data or business process impacted.   The only way to truly add this dimension to the “tuning” of security monitoring is through Business Context.

 

Secondly, we need to continue to recognize that security incident handling must evolve in parallel with the threat landscape.   Quarantining a virus infected system is one thing; responding to a data breach with significant regulatory and catastrophic business implications is a totally different animal.   Companies can begin with streamlining the security event-to-investigation transition to bolster the foundation.  Folding in Breach and Crisis Management takes the process to the next level.

 

Finally, there are many related processes that should be evaluated regularly to minimize attack vectors.  Processes that educate or involve the end users of the companies are key points of defense.  There is only so much that technology will do and the ‘flesh and blood’ of the company must be engaged.  One way to improve this within your company is to implement some type of threat assessment or brainstorming on a regular basis to highlight possible attack vectors.  Key business contacts can prove to be valuable assets when thinking outside the box on possible internal and external threat scenarios.

 

The need for a next generation security operations mindset is evident across the industry.  Technologies will continue to improve but we need to keep the pressure up on how we view security processes.   The attackers are constantly evaluating their methods and improvising new techniques.   The defenders must think in those same fluid terms.   I started this blog series using the analogy of the appearance of the catapult and trebuchet on the horizon outside a castle.   In some respects, this analogy holds water but in reality, the threats we need to prepare against are not obvious hulking pieces of machinery being drug across the battlefield but electrons and shadowy figures that we only catch in fleeting glances.  The next generation of security operations will need to dispel the shadows.  In the end, it isn’t just arming our lookouts with telescopes; we need to give them searchlights as well.

 

To follow my entire blog series on this topic, check out:

Next Generation Security Operations: Part 1

The specified item was not found.

The specified item was not found.

Next Generation Security Operations: Flesh and Blood

Filter Blog

By date: By tag: