In October of 2015 the Center for Internet Security (CIS) released version 6.0 of the Critical Security Control Framework. The SANS Institute defines this framework as “A recommended set of actions for cyber defense that provide specific and actionable ways to stop today’s most pervasive and dangerous attacks. A principle benefit of the Controls is that they prioritize and focus a smaller number of actions with high pay-off results.” Many organizations throughout the world deploy the Critical Security Control Framework as a way to best manage available resources, guide future projects, or even as a means to get rid of existing systems that pose a security risk or under perform for the intended function. Given the organizations backing this framework, SANS and CIS, an update to the framework is a major deal.
For anyone wanting to get started with the Critical Security Control Framework version 6.0 check out the CSC Starter Kit.
Version 6 of the Critical Security Control Framework does some really great things in terms of helping organizations move forward with what next generation networks will look like as security models get baked into the core of redesigns. Additionally Version 6 dropped a control that never felt like it did much and replaced it with a control that was sorely missing and vaguely wrapped up in other more generic controls. Version 6 is not without its problems however as a major function, categorization of controls, was inexplicably removed which we will get to in a bit. Overall the new version is really good. It feels more streamlined and removes some of the fluffy sub controls that never really felt good, and with that let’s get to the good:
Reordering the controls
Understanding how to read the CSC helps one understand the simplicity of their approach. The higher up on the control list a control is the more important it seems to be. Prioritization is one of the five critical tenants of the CSC and it’s clear that CIS continues to invest in their approach. So how have things changed between version 5 and version 6?
- CSC 5: Controlled Use of Administrative Privileges (Up from Control 12)
- CSC 6: Maintenance, Monitoring, and Analysis of Audit Logs (Up from Control 14)
- CSC 7: Email and Web Browser Protections (New in Version 6.0)
- CSC 8: Malware Defenses (Down from Control 5)
- CSC 9: Limitation and Control of Network Ports, Protocols, and Services (Up from Control 11)
There is more reordering in Version 6 but by now you should get the point. The folks behind the Critical Security Controls are’t afraid of reassessing the situation and making adjustments based on the most important critical tenant of them all… Offense Informs Defense. If you look at the attacks going on across the world it’s clear that some of the adjustments here are designed to meet the new trends. For instance Wireless Access Control which was at number 7 in version 5.0 and has been dropped to number 15 in version 6.0. The most likely attack vector is not going to be through a compromise of a wireless access system (I’m saying likely not impossible). Likewise Control of Administrative Privileges was promoted from 12 to 5 as attackers are most likely to try and take an administrative account to gain persistence.
Probably the most important takeaway from these changes is the power of the 20 controls. When you remain smaller and more focused you can change with much greater speed. This is something that NIST 800-53 can’t do like the Critical Security Controls. These changes are not drastic either which allows previous CSC deployments to have a migration plan over to the newer version. Like software platforms handling upgrade paths is a tricky thing and version 6.0 of the framework appears to have considered that prior to publishing. Users of this framework should appreciate how the developers of the framework clearly consider how this framework has been and will be used.
So long Secure Engineering
In version 5.0 there was this lingering oddity… “CSC 19: Secure Network Engineering”. The previous security control had four sub-controls with the Quick Win sub-control being, “Design the network using a minimum of a three-tier architecture (DMZ, middleware, and private network).” This by itself seems to try to enforce an architecture in the environment and leaves questions like… how does the cloud work with this secure engineering? Anyway this control never really felt like it fit in because all the controls were broad and unfocused, a clear deviation from the rest of the framework. Hardly any of the controls were directly actionable as well. Secure Engineering is a great piece of guidance for organizations building out a new network or going through a redesign initiative, but for an operational framework designed to gauge maturity and ability to prevent/respond to cyber attacks it just doesn’t fit. Another good win by the Critical Security Control Framework for understanding this and removing it.
Hello Email and Web Browser Protections
Browsers and Email systems provide direct access to the wild west of the Internet and until now the framework kind of ignored them or at best treated these pieces of software as anything else. The reality is that the browser and email are tools used by nearly every single individual in the world and thus attract a lot of attention from attackers. In version 5.0 there is a control CSC 6: Application Software Security. Until version 6.0 this was where we sought guidance for all software security standards. If you go look at the control you’ll see that outside of ensuring that the software is supported by its vendor there is really nothing for vended products, and unless you’re Google or Microsoft the chance is that your organization is not using a custom developed browser or email system. So there was clearly a gap. Enter version 6.0.
While not perfect the new CSC 7: Email and Web Browser Protections at least begins to address things such as browser and email system standardization, the use of plug-ins, and the allowance of various scripting languages on the browser itself. Additionally there is now more focus on email systems which in version 5.0 was relegated to a single blip in the CSC 13: Boundary Defense (version 5.0) calling for the use of SPF. One cool side affect of this work was that the old Application Software Security control has been able to be reduced down to control 18 from control 6 because we are meeting a lot of the threat head on with this new control.
WHERE DID MY Metrics GO?
The most glaring omission between version 5.0 and version 6.0 is that the official guidance does not appear to provide metric guidance. Why is this a big deal? Well one of the five central tenants of the framework is to provide metrics on effectiveness and automation of controls deployed in an organization. This reporting piece is what makes CSC such a valuable tool to cyber security managers. I am currently working on a document to add back in the effectiveness and automation metrics for the new version and hope to have those out soon.
So I spoke with the fine people at the Center for Internet Security and they kindly pointed out that I was the one with the oversight. There is an additional document, that I completely missed, called “The Measurement Companion” and it’s a take on version 5’s metrics and so much more. If you review the measurement companion document it not only gives you the testing methods but also some general levels that can help the security manager asses their risk thresholds. The reason for the separation was that the metrics guidance can and should be updated faster than the controls themselves. Decoupling this guidance from the master document makes these updates easier to push out. This is the long term support stuff that makes CSC a great framework. The measurement companion can be found in the starter kit link above.
Where did My Categories Go?
In version 5.0 there were these things called Categories. There were four types:
- Quick Win – biggest bang for your buck
- Configuration / Hygiene – reduce number and severity of vulnerabilities
- Visibility / Attribution – monitor and identify security issues
- Advanced – Complex actions that provide advanced security capabilities
In version 6.0 they have replaced Categories with something called “Family”. There are three families:
The benefit of the Categories was that you could show organizational leadership what types of functions the expenditures were going towards or show weaknesses / strengths in an environment. Families is nice as it helps push security responsibilities to teams within the organization but at the same time why remove Categories? Families and categories can co-exist without issue especially when there is little guidance on the use of families.
So why not? Well first off there’s the issue with “Quick Wins”. A great concept that was also a bit misleading. Given the budget and the personnel deploying the quick wins does provide you the biggest and best leap forward in how you secure your environment, but calling things like Application Whitelisting a “Quick Win” is a bit troubling. Application Whitelisting is something that only really dedicated or advanced organizations are capable of, and that dovetails into the rest of the categories… Not all environments are the same and so planning for the controls based on categories potentially led to an over investment in areas such as detection. I wonder if we were using categories the wrong way as a metric rather than a classification. Either way I have a feeling that additional guidance is on the way from the Center for Internet Security as they understand that there is still work to be done in the prioritization department.
The Critical Security Controls remains the easiest framework for an organization to implement and communicate throughout the organization. The adjustments made to the ordering and removal of non-effective controls shows how serious the Center for Internet Security is regarding their charge of guidance to organizations on best practices for a security program. While the loss of categories and the omission of metrics guidance does pose a problem for organizations deploying this tool it is certainly not a show stopper. Hopefully the Center for Internet Security will re-integrate this data in a minor version update to the framework.
Organizations are more effective when there is a clear strategy with data backing the use of the various resources available to a security program and the Critical Security Control Framework Version 6.0 is an incredibly valuable tool available for free to anyone willing to give it a try.
So my organization is just a user of this framework and certainly not the experts. I highly recommend anyone interested in learning more go directly to the source at: https://www.cisecurity.org/critical-controls/. I found the email address ControlsInfo [@] cisecurity.org to be super helpful as well.