Draft guidelines issued for using SCAP to automate security validation

The National Institute of Standards and Technology has released a draft of its guidelines for using the Security Content Automation Protocol (SCAP) for checking and validating security settings on IT systems.

SCAP is a NIST specification for expressing and manipulating security data in standardized ways. It can enumerate product names and vulnerabilities, including software flaws and configuration issues, identify the presence of vulnerabilities and assign severity scores to software flaws.

Managing the configurations and security settings of information systems is a challenging job to do manually because the of size, complexity and constant changes in the systems. A wide variety of hardware and software platforms typically are used for many purposes with differing levels of risk in a single environment. The platforms and the threats to them are constantly evolving.

“Organizations need a comprehensive, standardized approach to overcoming these challenges, and the Security Content Automation Protocol has been developed to help provide such an approach,” NIST says in Special Publication 800-117, titled "Guide to Adopting and Using the Security Content Automation Protocol." “SCAP can be used for maintaining the security of enterprise systems, such as automatically verifying the installation of patches, checking system security configuration settings, and examining systems for signs of compromise.”

Several organizations created and maintain the SCAP components, including Mitre Corp., the National Security Agency and the Forum for Incident Response and Security Teams. NIST provides SCAP content such as vulnerability and product enumeration identifiers via the National Vulnerability Database. All database content and the high-level SCAP specification are freely available from NIST. Nongovernment organizations also create and make SCAP content available.

The specifications that make up SCAP are:

  • Common Vulnerabilities and Exposures, a dictionary of names for publicly known security-related software flaws.
  • Common Configuration Enumeration, a dictionary of names for software security configuration issues, such as access control settings and password policy settings.
  • Common Platform Enumeration, a naming convention for hardware, operating systems and software.
  • Extensible Configuration Checklist Description Format, an Extensible Markup Language specification for structured collections of security configuration rules used by operating systems and applications.
  • Open Vulnerability and Assessment Language, an XML specification for exchanging technical details on how to check systems for security-related software flaws, configuration issues and patches.
  • Common Vulnerability Scoring System, a method for classifying characteristics of software flaws and assigning severity scores.

Vendors have begun incorporating SCAP in tools for scanning software settings and configuration and, in July, the Office of Management and Budget required agencies to use SCAP-validated products to check compliance with the Federal Desktop Core Configuration settings for government computers running Windows XP and Windows Vista.

NIST also has released a revised version of testing requirements for security products using SCAP, describing requirements products must meet to achieve SCAP validation. Draft NIST Interagency Report 7511, titled "Security Content Automation Protocol Validation Program Test Requirements, Revision 1," was written primarily for laboratories that are accredited to perform SCAP product testing, vendors interested in receiving SCAP validation for their products, and agencies and integrators deploying SCAP tools.

The NIST guidelines offer these recommendations for using SCAP:

  • Organizations should use security configuration checklists that are expressed using SCAP. This documents desired security configuration settings, installed patches, and other system security elements in a standardized format. SCAP-expressed checklists are available relevant to specific software, and can be easily customized to meet specific organizational requirements.
  • Organizations should use SCAP to demonstrate compliance with high-level security requirements. NIST has created mappings between Windows XP security configuration settings and the high-level security controls in NIST Special Publication (SP) 800-53, which supports Federal Information Security Management Act. The mappings are embedded in SCAP-expressed checklists, which allows SCAP-enabled tools to automatically generate assessment and compliance evidence.
  • Organizations should use standardized SCAP enumerations — identifiers and product names.
  • Organizations should use SCAP for vulnerability measurement and scoring. SCAP enables quantitative and repeatable measurement and scoring of software flaw vulnerabilities across systems through the combination of the Common Vulnerability Scoring System (CVSS), CVE, and CPE.
  • Organizations should acquire and use SCAP-validated products. Whenever possible, software developers should ensure that their software provides the ability to assess underlying software configuration settings using SCAP, rather than relying on manual checks or proprietary checking mechanisms. NIST also encourages IT product vendors to participate in SCAP content development because of their depth of knowledge and their ability to speak authoritatively about the most effective and accurate means of assessing their products’ security configurations.

Comments on the draft guidelines should be sent by June 12 to [email protected], with "Comments SP 800-117" in the subject line.

About the Author

William Jackson is a Maryland-based freelance writer.


  • Records management: Look beyond the NARA mandates

    Pandemic tests electronic records management

    Between the rush enable more virtual collaboration, stalled digitization of archived records and managing records that reside in datasets, records management executives are sorting through new challenges.

  • boy learning at home (Travelpixs/Shutterstock.com)

    Tucson’s community wireless bridges the digital divide

    The city built cell sites at government-owned facilities such as fire departments and libraries that were already connected to Tucson’s existing fiber backbone.

Stay Connected