Finishing The Security Automation Job
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.
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.
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.