Finishing the Security Automation Job

Thursday, September 06, 2012

Tripwire Inc


Article by Adam Montville

I’ve been working with David Waltermire in support of a SACM use case document.

The document describes five use cases for which the community will create supporting standards – these stem from ongoing security automation efforts (think NIST, MITRE, and company).  

I’ve mapped out what I think are the capabilities we need to support just two of the five use cases. Here are the use cases:

  • UC1: Assessment and Enforcement of Acceptable State
  • Uc2: Behavioral Monitoring and Enforcement
  • UC3: Security Control Verification and Monitoring
  • UC4: Secure Exchange of Risk and Compliance Information
  • UC5: Automated Forensics Investigation

Our approach is to derive functional capabilities and components, and then identify data exchange models and communication protocols (don’t think wire-line protocols).  In performing this work, I have found it useful to use a mind mapping tool (if you have a Mac, I recommend MindNode Pro).  It’s also important to note that the community has decided that initial work will focus on UC1 and UC3 (essentially, Security Configuration Management).

The difficulty I’ve been having is in separating the use cases from “functional capabilities” (in truth, we’ve only notionally defined what that means, so I’m not surprised that this is more difficult than I thought it would be).  At the most basic levels, the data models and protocols we specify need to ultimately support the following capabilities:

  • Asset management
  • Data collection
  • Data aggregation and reporting (including scoring)
  • Content management

Getting asset management right is important.  If you don’t have a handle on your assets, you’re in pretty bad shape for the rest of the work you need to get done.  The data collection we’re talking about here is essentially Security Configuration Management (per UC1 and UC3) with vulnerability management mixed in – we need to assess technical and non-technical controls to include interrogative, configuration, patch, and object state checks.  Once the data is collected, we need to aggregate it and report it.  

Finally, the entire notion of the SACM effort is predicated on the use of content to drive the implementing system.

This is essentially where the Security Content Automation Protocol has taken us.  We’re already this far.  Why do we need SACM, then?  Because SCAP is incomplete.  I’ve included an image of the mind map I created with this post to demonstrate how its incomplete.

(click image to enlarge)

Mapping standards to SACM capabilities through required models


As an example, SCAP covers the collection of data from the test level and provides a rudimentary way to relate tests to control frameworks, but without explicitly representing a control framework – this is ill-suited for any automation between frameworks (it at least makes the implementation difficult).  

There is one identified gap between what we really need is to ensure that we’re supporting the risk management umbrella over our security and compliance automation.

(click image to enlarge)

SACM Area of Concern

Again, the way I see it is that every organization manages risk – some less formally than others (ok, so that may not be “managing,” but I think the point is clear).  I’ve arbitrarily chosen a Basel II definition to be the overarching need that the controls – way down at the bottom – ultimately need to support.  

The way I see it, SACM needs to grow upward  and outward from where the SCAP efforts have gotten – move from controls into control frameworks and support the policies, processes, and procedures derived from Operational Risk Management.

We’ve got a lot of work ahead.  It’s all worth it.

If you’ve stuck with this post this long, you’re probably interested in what it’s saying.  You may even have an opinion.  Let me know what you think in the comments, or contact me on Twitter.  I’d love to hear from you. @adammontville

Cross-posted from Tripwire's State of Security

Possibly Related Articles:
Information Security
Best Practices Network Security Controls Configuration Data Management Protocols Automation SCAP SACM
Post Rating I Like this!
Jackie Singh How does this help the people who are truly responsible for the implementation and management of security in the workplace? While I appreciate the spirit of this article and the goals being worked towards, I have difficulty understanding how this work will translate across the wider workforce. The disconnect between individuals defining standards and security practitioners will continue to widen until industry addresses these issues.
Adam Montville Jackie, let me try to address your excellent comment. I posted a fairly comprehensive overview of my perspective on my personal site (not affiliated with Tripwire) about a year ago [1].

If the SACM efforts are fruitful, vendors will be able to provide organizations tools that close the divide between those who author policies and those who are held accountable to them by helping to ensure that those controls which truly matter have immediate focus. I have had the good fortune to be on both sides of that divide.

The controls put in place are typically well intended, but the spirit of what such a control means is often lost in translation and the policy wonks (I feel ok with that label - I used to be one) are often those who lose the spirit.

With efforts such as SACM, we should be able to automate most of the "mundane" work that needs to be done reconciling the differences. More accurately, imagine a heterogenous toolset that can present results to you (and your management) in a common way, thus allowing for more accurate risk management. SACM is just the start, and we eventually want to bring enterprise-specific attack information into the mix, but before we can do that, we need to get the basics done.

I would be interested in continuing this conversation, either here or offline (@adammontville). If you have time, a specific example of a gap you see between policy authors and practitioners could be instructional for everyone.

Jackie Singh Adam,

When we ask practitioners to digest guidance and implement/manage on site, we fail to realize that the reader's understanding will only hinge on their experience. The (qualified) resources (automation still requires human judgement) required to implement "cyber security" at a level that satisfies the guidance are still not widely available.

Anecdotally, I believe the higher-level language used in a typical top-down approach is too difficult to employ by most people, including those working in locations that bring secured communications in contact with insecure environments. The sheer number of regulations and their structure, density, and verbosity is mind-blowing. I don't currently see the DoD IA world as keeping sync with both the greater goals of secure agility for the warfighter and the overall conflict realities and potentials across the globe.

Although tools are helpful on the job, and you make a very salient point regarding complexity in your linked post, they do not address the finer point of ensuring practitioners know the "whys" and "hows" of the guidance in highly consolidated locations in a way that makes sense to a person that is not a policy wonk (layperson).

So, as requested, a more specific example of a gap that I perceive to be critical between policy authors and practitioners: Plainer English :-)
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.