Twenty Critical Security Controls
By Adam Montville
- 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
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.
- 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.
- 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.
- 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.
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.