PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free
download.

Security Content Automation Protocol
(SCAP) Checklists

by James G. Barr

Copyright 2019, Faulkner Information Services. All
Rights Reserved.

Docid: 00021041

Publication Date: 1912

Report Type: TUTORIAL

Preview

Based on the Secure Content Automation Protocol, SCAP checklists
are machine-readable documents containing instructions or procedures for
securely configuring an information technology (IT) product within a
specified operating environment, or verifying that an IT product has
already been securely configured.

Report Contents:

• Executive Summary
• Description
• Current View
• Outlook
• Recommendations
• Web Links

Executive Summary

[return to top of this
report]

With the increasing diversity and complexity of information systems,
security officials are realizing that the use of automated checklists is
essential to ensuring that effective security settings are applied – both
consistently and reliably – across an enterprise.

An automated checklist is a machine-readable document containing
instructions or procedures for securely configuring an information
technology (IT) product within a specific operational environment, or
verifying that an IT product has already been securely configured.
Automated checklists address security requirements more thoroughly and
more expeditiously than manual methods, and permit security professionals
to concentrate more on planning than implementation. 

Automated checklists are necessary in today’s IT environment because:

• Guidance in support of compliance initiatives has become more
  complicated.
• Organizations need to secure a greater number of systems, and a wider
  variety of software.
• Software has become more intricate; there are typically many more
  security-related configuration settings available, as well as more
  vulnerabilities that must be mitigated.
• Customizing security tools has become increasingly expensive.
• Information systems face many more threats, both in type and
  frequency.
• Organizations need to regularly verify their security posture, as
  part of routine security assessments and periodic compliance audits.¹

With a push from the US Office of Management and Budget (OMB), the US
federal government is promoting an automated checklist regimen based on
the Security Content Automation Protocol (SCAP), a set of selected open
standards that enable automated software vulnerability management and
security policy compliance.

SCAP

The

Security Content Automation Protocol (SCAP), pronounced “S – Cap”,

is a suite of specifications that standardize the format

and nomenclature by which software flaw and security configuration information

is communicated, both
to machines and humans.

SCAP utilizes
reference data
provided by the National Vulnerability Database (NVD),
which is managed
by US National Institute of Standards and Technology (NIST) and sponsored by
the US Department of Homeland Security (DHS).

SCAP
is a multi-purpose

framework that supports:

• Automated

  configuration

• Vulnerability
  and patch checking
• Technical
  control compliance activities
• Security measurement

Importantly, SCAP is derived from "community" ideas, because participation by
the security automation community ensures that the broadest possible range of
use cases is reflected in SCAP functionality.

SCAP Checklists

A SCAP checklist is a document containing instructions or procedures for:

• Securely configuring an information technology (IT) product within a
  specific operational environment.
• Verifying that an IT product has already been securely configured.

Other Standards

Other security standards similar to SCAP include:

• Security Automation and Continuous Monitoring (SACM)
• Common Criteria (CC)
• Software Identification (SWID) tags
• Federal Information Processing Standards (FIPS)²

Description

[return to top of this
report]

SCAP 1.3

The current effective version of SCAP is SCAP version 1.3.
SCAP
1.3
is comprised of twelve
component
specifications
in five
categories:

1. Languages – The SCAP languages provide standard vocabularies and conventions for expressing security policy, technical check mechanisms, and assessment results.
   The SCAP language

   specifications are Extensible
   Configuration Checklist Description Format (XCCDF), Open

   Vulnerability and Assessment Language (OVAL), and

   Open Checklist
   Interactive Language (OCIL).

2. 
   Reporting

   formats
   –

   The SCAP reporting formats
   provide the necessary constructs to express

   collected information in standardized formats. The SCAP reporting format
   specifications

   are

   Asset

   Reporting Format (ARF) and Asset Identification.

3. 
   Identification

   schemes
   –

   The SCAP identification schemes provide a means to identify key concepts

   such as software products, vulnerabilities, and configuration items using
   standardized identifier

   formats. They also provide a means to associate individual identifiers with
   additional data pertaining

   to the subject of the identifier.

   The SCAP identification scheme specifications

   are Common Platform

   Enumeration (CPE), Software Identification (SWID) Tags, Common Configuration
   Enumeration

   (CCE), and Common Vulnerabilities and Exposures (CVE).

4. Measurement and scoring systems
   –

   In SCAP this refers to evaluating specific characteristics

   of a

   security weakness (for example, software vulnerabilities and security
   configuration issues) and, based

   on those characteristics, generating a score that reflects their
   relative

   severity.
   The SCAP

   measurement and scoring system specifications are Common Vulnerability
   Scoring System (CVSS)

   and Common Configuration Scoring System (CCSS).

5. Integrity – A SCAP integrity specification helps
   to preserve the integrity of SCAP content and

   results. Trust
   Model for Security Automation Data (TMSAD)

   is the SCAP integrity specification.³

SCAP 2.0

NIST is planning for the next major revision of SCAP, SCAP version 2.
The first version, SCAP 2.0, will focus on improving support for software
inventory and vulnerability management use cases. Additional use cases,
including configuration assessment, will be addressed in future versions.

SCAP Checklists

Written in machine-readable form, SCAP checklists may
include the following:

1. Configuration files that automatically set or verify various security
   settings.
2. Documents that guide the checklist user to manually configure an IT
   product.
3. Documents that explain the recommended methods to securely install
   and configure a device.
4. Policy documents that establish guidelines for security auditing,
   user authentication, etc.

National Checklist Program

SCAP checklists are catalogued via the National Checklist Program (NCP), a US government repository of
publicly available security checklists (or benchmarks) that provide
detailed low-level guidance on setting the security configuration of
operating systems and applications.

Current View

[return to top of this
report]

As of December 12, 2019, there are 52 NCP checklists that are
compatible with SCAP 1.3 (including its predecessors, 1.2 and 1.1).

To illustrate, Table 1 offers the five SCAP checklists for Windows 7 and
Windows 10.

Source: NCP

Outlook

[return to top of this
report]

The US Office of Management and Budget (OMB) has decreed that
“Information technology providers must use SCAP validated tools, as they
become available, to certify their products do not alter the US Federal
Desktop Core Configurations (FDCC), and agencies must use these tools when
monitoring use of these configurations.”

The US National Institute of Standards and Technology (NIST) encourages
IT product vendors to develop security configuration checklists for their
products, since the vendors have the most expertise on the possible
security configuration settings, and the best understanding of how the
settings relate to and affect each other.

Vendors that create security configuration checklists should submit them
for inclusion in the National Checklist Program (NCP) repository. The NCP
provides a process and guidance for developing checklists in a consistent
fashion. For checklist developers, steps include initial development of
the checklist, checklist testing, documenting the checklist according to
the guidelines of the NCP, and submitting a checklist package to NIST.
NIST screens the checklist according to program requirements and then
releases the checklist for public review, which lasts thirty
(30) days. After the public review period and subsequent
resolution of issues, the checklist is listed on the NIST checklist repository
with its information. Checklist maintenance may potentially be performed by the
vendor, resulting in the release of updated checklists. NIST
retires or archives checklists as they become outdated or incorrect.⁴

Recommendations

[return to top of this
report]

Enterprises Should Employ SCAP Checklists to Enhance Overall Security

Enterprises should apply checklists – especially SCAP checklists – to
their operating systems and applications to reduce the number of
vulnerabilities that attackers can attempt to exploit, and to lessen the
impact of successful attacks. Using checklists that emphasize both system
“hardening” (e.g., by applying patches and eliminating unnecessary
functionality) and secure system configuration will reduce the number of
ways in which the systems can be attacked, resulting in greater levels of
product security and protection from future threats. Checklists can also
be used to verify the configuration of some types of security controls for
system assessments, such as confirming compliance with certain US Federal
Information Security Management Act (FISMA) requirements.

US federal agencies are required to use appropriate security
configuration checklists from the National Checklist Program (NCP) when
available. In January 2017, Part 39 of the US Federal Acquisition
Regulation (FAR) was amended as follows, “In acquiring information
technology, agencies shall include the appropriate IT security policies
and requirements, including use of common security configurations
available from the National Institute of Standards and Technology’s website at
https://checklists.nist.gov. Agency
contracting officers should consult with the requiring official to ensure the
appropriate standards are incorporated.”

Also, FISMA requires each federal agency to determine
minimally-acceptable system configuration requirements and to ensure
compliance with them. Accordingly, federal agencies, as well as
vendors of products for the federal government, should acquire or
implement and share such checklists using the NIST repository.

Enterprises, whether public or private, should consider the availability
of security configuration checklists during their initial IT product
selection screen.⁵

Enterprises Should Customize and Test Checklists in Non-Production
Environments

Checklist users should customize and test checklists before applying them
to production systems. Before incorporating a checklist that will be used
to alter product settings, users should first test it on non-critical
systems, preferably in a controlled non-operational environment. Each
checklist in the NIST repository has been tested by its developer, but
there are often significant differences between a developer’s testing
environment and an enterprise’s operational environment, and some of these
differences may affect checklist deployment.⁶

Enterprises Should Prepare to Transition to SCAP Version 2

For practical advice in transitioning to SCAP Version 2,
enterprises are encouraged to consult the NIST white paper, "Transitioning to the Security Content Automation
Protocol (SCAP) Version 2."⁷

References

¹ Stephen D. Quinn, Peter Mell, and Karen Kent. “The Security
Content Automation Program (SCAP): Automating Compliance Checking,
Vulnerability Management, and Security Management (Draft).” US National
Institute of Standards and Technology. October 2006.

² Andy O’Donnell. "What Does SCAP Mean?" Lifewire.
September 27, 2017.

³ Karen Scarfone and Dragos Prisaca. NIST Special Publication
800-126 Revision 4: "The Technical Specification for the Security Content
Automation Protocol (SCAP;" SCAP Version 1.3. US National Institute of Standards
and Technology. February 2018:viii.

⁴ Stephen D. Quinn, Murugiah Souppaya, Melanie Cook, and Karen
Scarfone. NIST Special Publication 800-70 Revision 4: "National Checklist
Program for IT Products – Guidelines for Checklist Users and Developers." US
National Institute of Standards and Technology. February 2018:viii.

⁵ Ibid. pp. vi-vii.

⁶ Ibid. pp. vii-viii.

⁷ David
Waltermire and
Jessica Fitzgerald-McKay.
"Transitioning to the Security Content Automation Protocol (SCAP) Version 2." US
National Institute of Standards and Technology. September 10, 2018.

Web Links

[return to top of this
report]

• Internet Security Alliance: http://www.isalliance.org/
• MITRE Corporation: http://www.mitre.com/
• SCAP: http://scap.nist.gov/
• US General Services Administration: http://www.gsa.gov/
• US National Checklist Program: http://checklists.nist.gov/
• US Office of Management and Budget: http://www.whitehouse.gov/omb/
• US National Institute of Standards and Technology: http://www.nist.gov/
• US National Vulnerability Database: http://nvd.nist.gov/

About the Author

[return to top of this
report]

James G. Barr is a leading business continuity analyst
and business writer with more than 30 years’ IT experience. A member of
“Who’s Who in Finance and Industry,” Mr. Barr has designed, developed, and
deployed business continuity plans for a number of Fortune 500 firms. He
is the author of several books, including How to Succeed in Business
BY Really Trying, a member of Faulkner’s Advisory Panel, and a
senior editor for Faulkner’s Security Management Practices. Mr.
Barr can be reached via e-mail at jgbarr@faulkner.com.

[return to top of this
report]