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 emerging-specs@nist.gov 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 emerging-specs@nist.gov 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.

The Heilmeyer Questions

• 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:

• Who are the stakeholders and what is their role?
• How could this specification work in conjunction with other existing specifications?
• Are we the right organization to develop this specification or are there more appropriate organizations? Have we contacted those organizations and if so are they willing to participate?

1. 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.

2. 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.

3. 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 emerging-specs@nist.gov email list. In general, the most interested parties will be subscribed to the emerging-specs@nist.gov 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.

4. 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:

• Addresses the proposed use cases
• Being adopted by software/hardware vendors
• Used by organizations as part of their operations.

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.

• Address use cases that are consistent with the SCAP vision and provide value and utility to the SCAP community.
• Demonstrate a high degree of maturity.
• Demonstrate uptake and adoption by product vendors, agencies, and organizations.
• Demonstrate interoperability with existing SCAP component specifications.
• Have a specification submission that is accompanied by a functioning reference implementation.
• Have a specification submission that includes evidence of public vetting (mailing lists, workshops, etc.)
• Be operationally used in organization(s) as a pilot or full operations.
• Be free from proprietary claims of intellectual property.

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.

The Common Configuration Enumeration, or CCE, assigns unique entries (also called CCEs) to configuration guidance statements and configuration controls to improve workflow by facilitating fast and accurate correlation of configuration issues present in disparate domains. In this way, it is similar to other comparable data standards such as theCommon Vulnerability and Exposure (CVE®) List, which assigns identifiers to publicly known system vulnerabilities.

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.

Examples include:

• The required permissions for the directory %SystemRoot%\System32\Setup should be assigned to the "Administrator account" only.
• The "account lockout threshold" setting should be set to 3.
• The startup type of the Remote Shell service should be set to "disabled".

A "configuration control" is a configurable unit of control within the conceptual security model of a computer system.

Examples include:

• The access permissions for files and directories, such as %SystemRoot%\System32\Setup.
• The account policy settings, such as account lockout threshold setting.
• The startup type for network services, such as the Remote Shell service.

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 included for the settings in Microsoft Corporation’s Windows Server 2008 Security Guide and 2007 Microsoft Office Security Guide.

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:

• CCE Identifier Number — "CCE-2715-1"
• Description — a humanly understandable description of the configuration issue
• Conceptual Parameters — parameters that would need to be specified in order to implement a CCE on a system
• Associated Technical Mechanisms — for any given configuration issue there may be one or more ways to implement the desired result
• References — pointers to the specific sections of the documents or tools in which the configuration issue is described in detail

Refer to the CCE List for more information.

The format of a CCE Identifier number is "CCE-2715-1":

• CCE = the type of identifier
• 2715 = the identifier, which is random and non-descriptive
• 1 = a check digit produced according to the Luhn Check Digit Algorithm, which can be used to detect common transcription errors

See CCE Creation Process.

A CCE "platform group" roughly identifies the operating system or application to which a CCE entry applies. CCE’s platform groups adhere to the same level of granularity commonly found in security configuration guidance that are written for individual platforms, as well as in the sets of checks and other features found in configuration audit and management tools. For example, Microsoft Windows XP and Sun Solaris 10. See About CCE Entries for a detailed discussion.

Refer to the CCE List page for a detailed list.

See CCE List References.

CCE List downloads are updated by individual platform group as necessary. The version of the file is the date of the individual downloads files, which are noted for each file on the CCE List page and encoded in the individual download file names.