Twenty Critical Security Controls
By
Adam Montville
The Center for Strategic and International Studies (CSIS) recently released Version 4 of the Twenty Critical Security Controls (here) as was determined by a consortium which included representatives from the National Security Administration (NSA), United States Computer Emergency Readiness Team (US CERT), the Department of Defense’s Joint Task Force for Global Network Operations and Cyber Crime Center, the Department of Energy, the State Department, and some top commercial forensics experts and pen testers from the banking and critical infrastructure sectors.
The critical controls identified by the workgroup focus on four basic tenets:
- Offense Informs Defense:Using knowledge from actual attacks to build effective defenses
- Metrics:Establishing metrics standards to measure the effectiveness of security
- Continuous Monitoring:Continuous monitoring/auditing to validate security measures in a timely manner
- Automation:To achieve reliable, scalable, and continuous measurements of controls
Implementing these Controls will take you on an eye-opening journey through your enterprise and its critical networks, and it will help you plan for improvements over time. Because the Controls are so expansive and highly detailed, I organized this series so you can refer back to this digest as a roadmap for identifying the primary actors, processes and tools involved. The articles are intended to highlight the specific requirements you need to understand, and can later be used as a checklist. Links to a more expansive examination of each Control identified are also provided. Here are the key points for the first two Controls we will be examining:
Control 1: Inventory of Authorized and Unauthorized Devices
In a Nutshell:
- Don’t do it all at once:This Control involves the orchestration of several business processes and is proportional to the size of the organization.
- Take these requirements to your vendors:If your tool vendors aren’t aware of these requirements, the data integration between business processes will be your burden.
- Look for standard data formats to be supported in tools:The tools you have today and in the future should support standard data formats, in particular the Asset Identification specification.
- Start small and basic:This Control is process heavy and will benefit from automation. Start by getting the discovery and inventory maintenance down pat and integrating that with the incident detection and response.
Areas for Improvement:
- Use terminology consistently:The term “system” is a great example, as it can mean a tool or component or can encompass people, processes, and technology.
- Level of Abstraction:This Control really assumes an IP-based network, but some of the more critical problem domains may not use IP-based networks exclusively and may have different requirements. It would be nice to see some level of abstraction to cover these fringe cases.
- Explain Why:In a couple of instances recommendations are made without any real explanation as to why. Clarification would be helpful.
- Dependencies:Throughout this Control there are allusions to processes that must exist for the implementation to be successful.
Control 2: Inventory of Authorized and Unauthorized Software
In a Nutshell:
- Don’t do it all at once:A repeat from Control 1. Asset inventory is hard, and the software piece of that is no exception.
- Start small and basic: Another repeat from Control 1. There’s too much that can go wrong if you try to go big too soon. Understand that there are some obvious ‘edge’ cases that will need to eventually be covered.
- Take Control 1 and Control 2 together:There are too many similarities between Control 1 and Control 2 to not treat them as ‘one Control.’ Why make the distinction from a process perspective? Computing devices and software are assets from a business perspective, so tracking both with a degree of accuracy is important.
- Take these requirements to your vendors:This too is likely to be a trend. This Control is full of requirements you should bring to your vendors, especially those related to interoperability features and functionality.
Areas for Improvement:
- Combine Control 1 and Control 2:It’s pretty easy to see that computing devices are the same as software if we look at the world from the perspective of what an “asset” is—they all have value to an organization. When we get to the tenth requirement, you’ll see what I mean.
- Dependencies:There are many allusions to a menagerie of processes and procedures throughout this Control, so it makes some sense that having a succinct list of these dependencies would be helpful for interpreting control frameworks.
- Rethink Today’s Organizational Needs:There are always exceptions, so there is no way a single Control framework can address everything for all types of organizations. I recognize this as a fact, and I think some of the requirements here are stuck somewhere in the last decade. For example, what organization is going to subject a R&D organization to a change management process for installing software? The majority give developers admin rights because they need them to regularly install software on their systems, which presents a dilemma from a security perspective, but it’s the reality of the situation.
For more details on this Control—including a numbered list containing each requirement, its description, and my notes pertaining to the requirements—refer to the full analysis here. In conclusion, I recommend that you consider treating physical/virtual and software assets the same and use a single Asset Management system to manage them. If your first thought was, “What Asset Management system!?” then you should spend a significant portion of your time planning to implement one and remember to start at the most basic level—computing device and operating system seems like a good start—and to iterate from there. Document your processes and procedures along the way and keep them up-to-date (you’ll thank me for this later, I promise you).
Adam Montville is a Security and Compliance Architect at Tripwire. From humble beginnings as a secure hash implementer at Oregon State University’s Information Security Laboratory in the mid ’90s, Adam has come to be a voice in the Security Automation and larger security community. He has held a variety of security-related positions throughout his fourteen-year information security career, including civil service at the Department of Defense, CTO of a secure messaging company, and Director of IT Operations for a secure information sharing service. He is an avid blogger on information security topics, and believes that being a hacker is not equivalent to being evil. LinkedIn.
