SCAP is a means of applying standards to ensure management and measurement of vulnerabilities. The objective of SCAP is to facilitate evaluation and policy compliance by integrating the goals of IT with those of IT security.

What is SCAP?

SCAP (Security Content Automation Protocol) enables maintenance and assessment of enterprise systems security to be conducted in a standardized manner. SCAP is made up of several open standards that are used to identify and describe flaws and other security issues. SCAP standards may be able to carry out any of the following tasks:

-       Automatically verify patches

-       Check system security configuration settings

-       Search systems for vulnerabilities and risks

As the standards are transparent, interoperable, repeatable and automated, organizations can evaluate their policy compliance. For instance, an organization can evaluate for FISMA compliance with SCAP standards. With SCAP, compliance is an automatic result of good enterprise security, since compliance reporting is linked to the system configuration.

NIST (US National Institute of Standards and Technology) defines SCAP standards, defines the mappings and manages the protocol. However, NIST is not responsible for controlling the underlying SCAP standards, which are discussed later in this article.

Components of SCAP

SCAP is made up of security checklist data, vulnerability enumerations and the mappings between these enumerations. SCAP content is described below:

  • Security Checklist Data

Checklists are overseen by the NIST National Checklist program. This is written in machine-readable language.

  • Vulnerability Enumerations

This is a list of all security related flaws or issues as well as a list of vendor/product names.

  • Mappings

These mappings are provided by the National Vulnerability Database (NVD). The mappings describe the affected product names and help identify the standard impact score for flaws or issues.

In addition to the main SCAP standard, there are also six underlying SCAP standards. The underlying standards are listed and described below:

1.   CVE

o   Common Vulnerability Enumeration

o   This describes publicly known IT vulnerabilities and issues.

o   CVE provides common names to identify publicly-known problems. These names are also referred to as “CVE names,” “CVE numbers,” “CVE-IDs” and “CVEs.”

o   CVE supports an organization’s vulnerability management functions.

o   CVE names contain the following information:

§  CVE identification number

§  Either “entry” or “candidate” status

§  Description of security vulnerability

§  Important references, such as vulnerability reports or OVAL-ID

2.   CCE

o   Common Configuration Enumeration

o   This describes system configuration issues.

o   CCE also enables the correlation of configuration data from multiple sources in an efficient, accurate manner.

o   CCE assigns enumerations (referred to as “CCEs”) to configuration statements and controls. It is similar to the CVE list.

o   CCE supports an organization’s configuration management functions.

o   CCEs contain the following information:

§  CCE identifier number

§  Human-readable description of the issue

§  Parameters specifying CCE implementation

§  Related technical mechanisms regarding the configuration issue

§  References to the documents or tools that describe the configuration issue in detail

3.   CPE

o   Common Platform Enumeration

o   This is a naming scheme for a number of IT platforms (i.e. operating systems, applications and hardware).

o   CPE enables the identification of specific platforms, based on URI (Uniform Resource Identifiers) syntax.

o   CPE supports an organization’s asset management functions.

o   CPE includes the following:

§  Formal name format

§  Description of complex platforms

§  System to check names

§  Description format

§  Tests to a name

4.   CVSS

o   Common Vulnerability Scoring System

o   This helps to determine the impact of IT vulnerabilities. Other vulnerability scoring systems, such as the CERT/CC or the SANS vulnerability analysis scale may also be used by commercial as well as non-commercial organizations.

o   CVSS also serves as a means to communicate vulnerability characteristics.

o   CVSS supports an organization’s configuration management and vulnerability management functions.

o   CVSS is made of the following metric groups, as described below:

a) Base Metric Group

    • This measures the intrinsic, fundamental characteristics of certain vulnerabilities. Base metrics are constant, regardless of time and user environments.
    • Base metrics include:
      • Access Vector
      • Access Complexity
      • Authentication
      • Confidentiality Impact
      • Integrity Impact
      • Availability Impact

b) Temporal Metric Group

  • This measures characteristics that change over the course of time, but are unrelated to user environments.
  • Temporal metrics include:
    • Exploitability
    • Remediation Level
    • Report Confidence

c) Environmental Metric Group

  • This measures the characteristics that are dependent upon a specific user environment.
  • Environmental metrics include:
      • Collateral Damage Potential
      • Target Distribution
      • Confidentiality Requirement
      • Integrity Requirement
      • Availability Requirement

5.   XCCDF

o   eXtensible Checklist Configuration Description Format

o   This is an XML-based language.

o   XCCDF is used to represent checklists, benchmarks and other pertinent documents in machine-readable format.

o   XCCDF supports an organization’s compliance management and configuration management functions.

6.   OVAL

o   Open Vulnerability and Assessment Language

o   This is an XML-based language.

o   OVAL represents configuration information; analyzes the system for patches, vulnerabilities, security configuration standards or other machine states; and reports assessment results.

o   OVAL supports an organization’s configuration management and vulnerability management functions.

SCAP Validation & Emerging Specifications

SCAP protocols facilitate the exchange of system configuration controls and vulnerability information in a standardized format. The Validation Program assesses the ability of the products to use the SCAP components. SCAP validation is carried out by independent laboratories, accredited by the NIST. Based on lab results, the product is SCAP-validated. The information is announced on the NIST web page.

There are a number of different SCAP Validated Products, distributed by the following five vendors:

1.   Gideon Technologies – SecureFusion

2.   netIQ – Secure Configuration Manager

3.   secure elements – CS Compliance Platform

4.   ThreatGuard – Secutor Prime and S-CAT

5.   Tenable Network Security – Security Center

A number of other SCAP products are in the testing process. Other products are on the potential validation list. There are a number of emerging specifications, which are listed below:

  • ARF (Asset Reporting Format)
  • OCIL (Open Checklist Interactive Language)
  • OCRL (Open Checklist Reporting Language)
  • CCSS (Common Configuration Scoring System)
  • CMSS (Common Misuse Scoring System)

SCAP Release Cycle

SCAP specifications are under ongoing change in order to meet the needs of its users. SCAP change management is outlined in its Release Cycle:

  • NIST review, community feedback and candidate process – consideration of new or updated specifications that may become part of SCAP.
  • Review of potential SCAP candidates – this allows the community to offer comments or feedback before finalization of the specification.
  • Publication of draft SCAP – gives notices regarding new/updated specifications.
  • SCAP beta content – provided for testing and use by the community.
  • Publication of final NIST specification – after this step, the specification becomes effective.
  • SCAP content finalization – any previously released beta content becomes final.
  • Laboratory product validation period – product testing by accredited laboratories. This extends for a period of twelve months.
  • Expiration of product validations – product validations expire after one year.


This article introduces SCAP open standards by exploring the reasons for which they may be implemented within an organization. The article describes the functions of the six components (or underlying standards) of SCAP, which include: the Common Vulnerabilities and Exposures (CVE); Common Configuration Enumeration (CCE); Common Platform Enumeration (CPE); Common Vulnerability Scoring System (CVSS); eXtensible Configuration Checklist Description Format (XCCDF); and Open Vulnerability and Assessment Language (OVAL). The process by which emerging standards are validated and updated is also described.

CIPP/G Preparation

In preparation for the Certified Information Privacy Professional/US Government exam, a privacy professional should be comfortable with topics related to this post, including:

  • Federal Information Security Management Act of 2002 – FISMA (I.C.f.)
  • System compliance (I.C.f.ii.)
  • Program management – FISMA model (II.A.b.i.)

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>