National Institute of Standards and Technology (NIST) - Information technology Laboratory (ITL)

Emerging Specifications Frequently Asked Questions

  1. Who should create new specifications?
  2. What should I consider when embarking on a new specification?
  3. OK, I determined there are no existing specifications or planned efforts regarding the idea for my specification. What is my next step?
  4. I submitted my proposal, received feedback, and want to proceed. What next?
  5. My proposal is not getting much attention. What should I do?
  6. My proposal is getting lots of attention. Why has NIST not adopted it into the NIST validation program?
  7. What happens if NIST selects my specification for inclusion in a NIST validation program?

Answers

  1. Who should create new specifications?
    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.
    Back to Top
  2. What should I consider when embarking on a new specification?

    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.

    Back to Top
  3. OK, I determined there are no existing specifications or planned efforts regarding the idea for my specification. What is my next step?

    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?
    Back to Top
  4. I submitted my proposal, received feedback, and want to proceed. What next?

    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 NIST IR 7275: Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.1.4 and 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.

    Back to Top
  5. My proposal is not getting much attention. What should I do?

    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.

    Back to Top
  6. My proposal is getting lots of attention. Why has NIST not adopted it into the NIST validation program?

    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 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.
    Back to Top
  7. What happens if NIST selects my specification for inclusion in a NIST validation program?
    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.
    Back to Top