This is a potential security issue, you are being redirected to https://csrc.nist.gov.
SCAP is a suite of specifications for exchanging security automation content used to assess configuration compliance and to detect the presence of vulnerable versions of software. The same SCAP content can be used by multiple tools to perform a given assessment described by the content.
A new specification can be created by any interested party. MITRE, NIST, NSA, DHS and FIRST collaboratively sponsored the original six SCAP specifications. These same organizations will continue to produce specifications. However, it benefits the community when new stakeholders bring ideas to the table.
When considering a new specification, organizations should evaluate the benefits of the new specification both on its own merits and how it might be used in conjunction with existing specifications.
Organizations should also consider contacting NIST or writing to the email@example.com discussion group to shape the idea. This prevents duplicate specifications, facilitates collaboration with existing specifications, and refines the scope of the proposed specification idea.
Write a proposal and submit it to either NIST or the firstname.lastname@example.org email list for feedback. Be sure to describe the specification as either a language (e.g., XCCDF, OVAL, OCIL), an enumeration (e.g., CCE, CVE), or a metric (e.g., CVSS, CCSS).
Organizations must categorize the specification as either an enumeration, a language, or a metric. The boundaries between the three categorizations ensures the proposed specifications can be validated once matured and enables products to validate to only those specifications that are applicable to their offering. Use cases which require more than one category of specification, may be implemented through a set of cooperating specifications decomposed into separate categories. For example languages are not prohibited from using enumerations or metrics, only that languages must not define a new enumeration or metric as a function of itself. Likewise, enumerations should not instantiate expression languages, etc. If an enumeration requires an expression language, then a language specification should be created referencing the separate enumeration specification.
The proposal should address the Heilmeyer questions with regard to the new specification.
WHAT ARE WE TRYING TO DO?
What is the problem? What are we trying to accomplish?
HOW DOES THIS GET DONE AT PRESENT?
Who does it? What are the limitations of the present approaches? Why is it hard?
WHAT IS NEW ABOUT OUR APPROACH?
What is the new technical idea? Why do we think we can be successful at this time?
IF WE SUCCEED, WHAT DIFFERENCE DO WE THINK IT WILL MAKE?
What is the impact? Provide metrics.
HOW LONG DO WE THINK IT WILL TAKE?
How will the program be organized? How will intermediate results be generated? What are our mid term and final exams to see how we are doing?
CAN WE FACILITATE ADOPTION?
How do we bring the benefits of the specification to the user community?
HOW MUCH WILL IT COST?
Also consider the following questions:
Based on the proposal, create a specification. The specification should follow the general pattern of existing specifications for the category you selected (language, enumeration, or metric) to include, but not limited to, conventions such as:
The new specification shall exist in its own name space.
If the new specification is an enumeration, then it should not include other enumerations as part of the specification.
If the new specification is a language, it must be accompanied by a schema.
For example specification formats, please refer to NISTIR 7275 Rev. 3: Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.1.4 and NIST IR IR 7435: The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems.
While much of this information will be provided in feedback, NIST is consolidating these conventions and will update this web site accordingly.
Next, create a home page for the specification so that the community can work with the new specification and updated versions as they become available. Please do not delete old versions of the specification, as archives may be beneficial to stakeholders who have dependencies on them.
Create a collaborative environment to facilitate community discussion, such as online discussion or email lists. Alternatively, you may ask NIST for permission to use the email@example.com email list. In general, the most interested parties will be subscribed to the firstname.lastname@example.org mailing list and prefer not to subscribe to additional lists. If it becomes apparent that the proposed specification is of great community interest beyond the initial flurry of email, NIST may ask the submitting organization to host a separate mailing list for the specification.
Produce a reference implementation based on the specification to illustrate how the specification can be used to provide security automation capabilities. The following implementations may be used based on the purpose of the specification:
Language - Produce a reference tool implementation that is capable of processing content expressed in the specification syntax to produce valid results.
Enumeration - Produce an enumerated listing of content using the specification guidance/format.
Metric - Produce a calculator based on the algorithms described in the specification.
As the specification owner, it is incumbent on you to demonstrate value in your emerging specification. In general, the specification should have the following attributes:
It also helps to have a reference implementation, tools, utilities, and other methods of demonstrating the integration and ease-of-use regarding the proposed specification.
Not all specifications are destined for NIST validation. However, if a specification is to be considered for inclusion in a NIST validation program, it must:
Be in final specification format.
For example specification formats, please refer to NIST IR 7275: Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.1.4 and NIST IR 7435: The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems.
According to the SCAP Release Cycle, NIST will evaluate emerging standards for inclusion in NIST validation programs. If your specification is selected, NIST will work with your organization to develop criteria to evaluate product capabilities based on your specification.
A "configuration guidance statement" specifies a preferred or required setting or policy for a computer system. Configuration statements can be found in a variety of repositories such as security guides, benchmarks, vendor guidance and documentation, configuration assessment and management tools, and consolidated reporting systems.
A "configuration control" is a configurable unit of control within the conceptual security model of a computer system.
Use of CCEs improves configuration management work processes by allowing people to quickly and accurately correlate configuration data across multiple information sources and tools.
CCEs are associated with configuration issues that express the way humans name and discuss their intentions when configuring computer systems. In this way, the use of CCEs as tags provide a bridge between natural language, prose-based configuration guidance documents, and machine-readable or executable capabilities such as configuration audit tools.
CCEs are the main identifiers used for the settings in the Federal Desktop Core Configuration (FDCC) data file downloads. In addition, CCE is one of six existing open standards used by NIST in its Security Content Automation Protocol (SCAP) program, which combines "a suite of tools to help automate vulnerability management and evaluate compliance with federal information technology security requirements." Numerous products have been validated by NIST as conforming to the CCE component of SCAP.
CCE entries are unique, common identifiers assigned to particular security-related configuration issues. Each entry on the CCE List contains the following five attributes:
Refer to the CCE List for more information.
The format of a CCE Identifier number is "CCE-2715-1":