Twenty Critical Security Controls Part Two:
Configurations and Vulnerability Assessments
By
Adam Montville
Recently, the Center for Strategic and International Studies (CSIS) released version 4 of the Twenty Critical Security Controls (here). Because the Controls are so expansive and detailed, I developed this digest to briefly highlight specific requirements so you can later use it as a checklist. Links to more expansive examinations of each Control are also provided.
In the first installment of this two-part series, we covered the Inventory of Authorized and Unauthorized Devices and the Inventory of Authorized and Unauthorized Software, which we concluded could be combined into 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.
In this article we will look at two more Controls designed to offer guidance on managing secure hardware and software configurations on a variety of devices, as well as implementing continuous vulnerability assessments and remediation efforts.
Control 3:
Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
In a Nutshell:
- If you do one thing, do this: The plain and sad truth is that you’re going to have to implement some parts of Controls 1 and 2 to get this Control in place. Start with Security Configuration Management (SCM), which is really what this Control is all about. If you look at the breach reports from any of a variety of sources, you’ll find that misconfigurations—or configuration vulnerabilities—are very common breach factors.
- Prepare for incidents: This Control ties to the Incident Detection and Response processes your organization has in place, so if you need SCM resources to be on standby for your IR program, then prepare for it with this Control.
- Take these requirements to your vendors: Once again there are several requirements here that you need to take to your vendors, especially if you’d like to see frameworks such as the 20 CSC succeed in the long run.
- Take these requirements to your developers: If you’re developing software in-house, then this Control presents requirements your internal developers need. Have your developers read through this, especially the parts on requiring interoperability between tools and alerting administrative personnel. It would also benefit your organization to consider internal Common Configuration Enumeration identifiers for your in-house application configuration settings.
Areas for Improvement:
- Use consistent terminology: Again, like in Controls 1 and 2, I found that some of the terms used are ill-defined or ambiguous—not helpful for clarity.
- Too many dependencies: It’s annoying that we have such intricate dependencies in Control Frameworks, and this is no exception. The first key takeaway says to implement this Control first, but also says that parts of Controls 1 and 2 need to be in place. There are also business processes that go unmentioned but are alluded to that this Control will affect. It seems that there should be a better way to communicate all this.
- Leverage data exchange formats: This and other Controls in this Framework are just begging to be automated. Having tools that work together without complicated, one-off integrations works to your advantage—and if you’re developing in-house, leverage the data exchange formats described in the Security Content Automation Protocol (SCAP), then ask for SCAP by name from your vendors.
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.
Control 4:
Continuous Vulnerability Assessment and Remediation
In a Nutshell:
- On operational maturity: Perhaps it is because the vulnerability patch cycle has been around for so long, but this Control seems to be different than the others in that it is more focused on the time it takes to accomplish specific tasks than it is on the quantity of the results. In other words, it is about the process of continuous vulnerability management. I foresee other controls going in this direction in the very near future—the efficiency of security processes is what is important, and this can always be improved over time.
- On interoperability: This Control is no different from the others in that it is part of the overall framework’s intricate web. The three obvious points of integration are the asset management, alerting, and ticketing systems, less obvious are integration opportunities with LDAP for user roles and the relationship of vulnerability management with configuration management, which are critically important to the security automation story.
- On coverage: This Control leans quite heavily on ensuring that you’ve covered your enterprise, and at more than one point explicitly states that integration with the asset inventory system is important. Be sure to have a list of all software asset classes covered straight out of your asset inventory system when looking for scanning tools, as this will help you ensure that you have adequate coverage.
Areas for Improvement:
- Provide more explanation: At times, the requirements are not obvious—even to security professionals. Consider what it must be like from the organizational, non-security perspective to read some of these requirements. If the reason for doing work is not clearly articulated, it will not be supported by the organization.
- Categorize requirements appropriately: A couple of requirements describe metrics that were not in the metrics section of the framework. This may simply be an oversight, but it’s still something that could be corrected.
- General housekeeping: Some of the requirements should probably be reworded—one in particular talks about patches when it would be better to talk about vulnerabilities—and others could be safely omitted.
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.>
If there is any conclusion to make, I believe it is that Controls 3 and 4 are critically important to your organization. If you’re just starting out, you’re going to need to roll in some of the inventory management pieces from Controls 1 and 2, but take it small, fail fast, and scale quickly. It should be okay to get it wrong initially (if it isn’t in your organization, then you’re additionally going to need to work on setting expectations and really start small).
Just remember that data can be your friend—look to breach reports for data supporting the importance of configuration management, present it in a way that makes sense to your stakeholders, and you should be on a successful path.
