Many questions arise at the mention of the Security Content Automation Protocol (SCAP): What is it, how does it work, and how can it be useful for an enterprise?
This tip is intended to offer some background on what SCAP is and when and how an organization would benefit by relying on this protocol to enhance enterprise security.
What is SCAP?
"…a suite of specifications that standardize the format and nomenclature by which security software products communicate software flaw and security configuration information."
SCAP was developed to 1) organize, 2) express and 3) measure security information in standardized ways, thus providing an automated approach to maintaining the security of enterprise systems.
More specifically, the NIST guidance lists three ways in which SCAP can be used to maintain the security of enterprise systems, including:
- Automatically verifying the installation of patches;
- Checking system security configuration settings, and;
- Examining systems for signs of compromise.
The primary driver for SCAP's development is to help organizations that need to comply with the U.S. Federal Desktop Core Configuration (FDCC) and the United States Government Configuration Baseline (USGCB)1 initiative, which has evolved from the Federal Desktop Core Configuration mandate requirements. SCAP-validated scanning tools can be used to scan affected systems and provide reports regarding whether those systems are compliant with FDCC. This is a time-saver and will help organizations be more readily prepared for audits that require FDCC compliance.
SCAP has two major elements:
First, it is a protocol. SCAP is a suite of four open specifications that standardize the format and nomenclature by which software communicates information about publically known software flaws and security configurations annotated with common identifiers and embedded in XML. Essentially this is a means of establishing some automated "on/off" switches when checking to see if a server or desktop is compliant with the standard in question. This is practical because the output is a standardized, non-proprietary format that can be used across different organizations. Each specification is known as an SCAP component. (NIST also gives more information on SCAP v1.0 components.)
- Second, SCAP includes software flaw and security configuration standard reference data, also known as SCAP content. This reference data is provided by the National Vulnerability Database (NVD), which is managed by NIST and sponsored by the Department of Homeland Security (DHS). SCAP content is available on the NVD.
So, there's SCAP content (i.e., reference data) and SCAP components (i.e., security specifications). In order to make these work effectively, the SCAP authors have integrated the SCAP content and the SCAP components into SCAP-expressed checklists that use a standardized language to express what platform is being discussed (think Common Platform Enumeration (CPE)) and what security settings should be addressed (think Common Configuration Enumeration (CCE)). It would also be possible to use the checklists in a manual manner to set up the system in question. However, the number of settings is substantial, and, as such, an automated system like SCAP is preferred.
The National Checklist Program (NCP) website is the repository for SCAP-expressed checklists.
An example of a checklist page from this website for FDCC Windows XP is shown in Figure 1 below:
Click to enlarge
Figure 1: Checklist for FDCC Windows XP
As a note, if you look at the Supporting Resources section of this page, there is a "Human Readable" or "prose" version of the settings that, when downloaded, provides a spreadsheet of the policy setting and name, the CCE reference, the registry setting, as well as the description and what the Federal Desktop Configuration should be for each policy (e.g., Disabled, Enabled, etc.). An example of the spreadsheet is shown in Figure 2.
Each checklist is assigned a tier relative to its automation operability as pertains to the SCAP protocol. The tiers are designated as I - IV.
Tier I checklists are prose-based, i.e., narrative descriptions of how a person can manually alter a product's configuration.
Tier II checklists tend to list the recommended security settings in a proprietary, machine-readable format.
Tier III checklists use the SCAP protocol to document their recommended security settings in machine-readable, standardized SCAP formats.
- Tier IV checklists include all the properties of the Tier III checklists. Additionally, they are considered production-ready and have been validated by NIST to ensure interoperability with SCAP-validated products. Tier IV checklists also demonstrate the ability to map low-level security settings to high-level security requirements as represented in such frameworks as SP 800-53 controls for FISMA. (Note: all the FDCC Checklists are tier IV in the National Vulnerability Database.)
Of note, organizations obligated to comply with federal mandate for SCAP are required to use the highest tier for their computer security automation. Also, there are plans for a Content Validation Program to allow vendors or anyone else to have their content posted to the NVD as Tier III or Tier IV content. However, a date for when this will be implemented is not currently available.
How can an enterprise take advantage of SCAP?
According to NIST, organizations interested in taking advantage of SCAP tools (.pdf) should adhere to the following recommendations as noted in the publication:
Use SCAP-expressed security configuration checklists to automatically improve and monitor a system's security. The SCAP-expressed checklists help automatically generate assessment and compliance evidence and can be downloaded from the National Checklist Program website referred to above. It is important to note, however, that the current version of SCAP does not fix or correct any discrepancies noted between actual configuration and the checklist –- that is anticipated for future SCAP tools and is already in some proprietary applications.
Take advantage of SCAP to demonstrate compliance with high-level security requirements that originate from mandates, standards and guidelines, such as FDCC. This also can help an agency be better prepared for a FISMA audit.
Use standardized SCAP enumerations, identifiers and product names such as Common Vulnerabilities and Exposures (CVE), Common Configuration Enumeration (CCE) and Common Platform Enumeration (CPE) nomenclature. In other words, use a common language so descriptions of vulnerabilities or exposures operate with the same terminology and reference the same MITRE CVE/CCE/CPE database. This allows organizations to better understand the system vulnerabilities and affected configurations when cross-talking between organizations and referring to security-related software flaws, security configuration issues and platforms.
Use SCAP for quantitative and repeatable vulnerability measurement and scoring through the combination of Common Vulnerability Scoring System (CVSS), CVE and CPE. Because SCAP does provide for some scoring during the analyses, you can use the scores to plot and establish trends, comparisons, etc.
Acquire and use SCAP-validated products. U.S. Federal agencies and those companies supporting U.S. government agencies must use SCAP-validated FDCC scanners for testing and assessing FDCC compliance.
Of note, NIST has established both an SCAP product-validation program and a National Voluntary Laboratory Accreditation Program (NVLAP). These programs are coordinated to ensure the SCAP products are effectively tested and validated to conform to SCAP requirements. NIST maintains a list of accredited laboratories and currently validated products. A graphic showing some of the currently validated products is shown in Figure 3.
Click to enlarge
Figure 3: SCAP Validated Products (Examples)
- Adopt SCAP and use its capabilities when developing software and/or security checklists, thus verifying the software provides the ability to assess underlying software configuration settings rather than relying on more costly manual checks or proprietary checking mechanisms.
In addition to the NIST SP 800-117 suggestions above, Karen Scarfone, a computer scientist and project manager with NIST, gave an excellent SCAP Overview Presentation (.pdf) that noted these common uses of SCAP:
Perform security configuration verification: Here you can use an SCAP-expressed checklist and compare it to a system's actual configuration. You can verify and audit a system before deployment using these checklists. Also, you can map individual system settings to high-level requirements such as FDCC, etc. using the checklist capability.
- Check system for signs of security compromise: If you know the characteristics of the attacks, then you can check for altered files or the presence of a malicious service. For example, if you know the attack alters a specific .dll file, then you can check for any particular changes to the associated file.
SCAP is moving along and is being implemented primarily due to federal mandate by the U.S. Office of Management and Budget. SCAP v1.0 is being adopted and products are being developed and tested for accreditation by NIST-approved laboratories. Version 1.1 was expected in late 2010 and candidate specifications for version 1.2 are already under review, per Karen Scarfone.
What are the potential organizational benefits of using SCAP? Here are a few:
By using SCAP, you can increase automation and reduce manual effort to obtain assessment results, determine those corrective actions needed and thus provide substantial cost savings.
Because you are using the common language mandated by SCAP, the resulting XML-coded results will allow for easier communication of results across the other SCAP system users. Also, this will allow for easier comparison of issue sets between security organizations because the vulnerabilities are described using the same codex of CVSS, CVE and CPE.
By using SCAP-validated products, organizations are more likely to be better prepared for FDCC audits.
- A primary benefit of SCAP content is the ability to make and modify your own checklists. You are not obligated to use only the FDCC /USGCB content unless you are under the government mandate.
I suspect we will all hear more about SCAP implementation in the future, and, with the newer versions of the protocol, there will be even more potential benefits for automated security.
1The United States Government Configuration Baseline (USGCB) will be the successor to FDCC and will contain Win 7 as well as other operating system coverage like Red Hat, Solaris, etc… when their content is finalized. USGCB is expected to be incorporated into SCAP 1.1.
About the author:
Ernest N. Hayden (Ernie), CISSP, CEH, is the founder and owner of 443 Consulting, LLC, an enterprise focused on providing quality thought leadership in the areas of information security, cybercrime/cyberwarfare, business continuity/disaster recovery planning, and research. Most recently, Ernie was Information Security Strategic Advisor in the Compliance Office at Seattle City Light.
This was first published in March 2011