Security Content Automation Protocol SCAP

CCE Creation Process

CCE entries are currently assigned to configuration issues by members of the CCE Content Team and posted on the public CCE Web site. Operating system vendors are encouraged to coordinate with the CCE Content Team to have CCEs assigned to their configuration controls and/or new platforms. Please contact cce@nist.gov for more information.

Typically, a CCE Content Team Analyst first encounters a configuration issue in one of two ways:

(1) The most common way an analyst encounters a configuration issue is a configuration guidance statement is in a resource document or audit tool. For example, "The minimum password length should be set to 8." This statement would lead to the identification of the resource itself, and to the capture of the configuration statement as a citation. The next step for the analyst is often to determine how to effectively set the configuration or test for its presence. In this example, this would lead her to various registry keys, local security policy settings, or Group Policy Object (GPO) settings, each of which would be captured as technical mechanisms. After the configuration statement and the associated technical mechanisms are identified, the analyst will generalize the configuration issue and capture it as a CCE description and conceptual parameters. In this way, the CCE entry binds together the references and technical mechanisms.

(2) The second and less frequent way an analyst creates a CCE entry is with a particular configuration control such as a particular registry key, file, or GPO setting. In this context, the analyst is considering the control without any specific external guidance on how the control should be set. Instead, she may be working to formulate what her own suggestion would be. Starting with a single technical mechanism (e.g., a registry key), she then typically expands her scope to consider what other technical mechanisms would have an equivalent effect (e.g., local security policy settings, GPO settings). These are captured as further technical mechanisms. Once a set of comparable technical mechanisms are identified, she can generalize the technical mechanisms and create a CCE entry as described above.

Once an analyst creates a CCE, it is published in the downloads posted on the CCE List page on this public CCE Web site.

CCE Core Concepts

Below is a high-level overview of the core concepts in the CCE creation process.

References and Technical Mechanisms

CCE entries can be thought of as being formed by a set of comparable "references" about configurations. These references are of two different kinds. The first kind consists of objects or constructs from within the platform itself. CCE refers to these as technical mechanisms. Examples include files, users, registry keys, local security policy settings, and graphical user interface (GUI) controls.

The second kind of configuration reference consists of statements embedded in "resources" that describe the platform, where the word "resource" is taken to include a very broad category that includes:

• Prose security guides that contain natural language configuration statements (e.g., NSA security guides, CIS Benchmarks, DISA STIGs).
• Online help resources that contain natural language configuration statements but may be provisioned using structured data (e.g., MS TechNet, UNIX main pages).
• Structured guidance documents that contain structured configuration statements (e.g., XCCDF checklists).
• Configuration audit or management tools that contain checks, control items or GUI controls.

CCE refers to the individual statements within a resource as references. CCE also collectively refers to both references (from a resource) and technical mechanisms (with the platform) as references.

Comparable References

When a set of references for a platform are essentially the same despite differences in their expression, CCE refers to them as "comparable references." Three types of comparability are included below to illustrate the concept.

• Parameters: In Microsoft Windows XP, you can establish a minimum password length that will be enforced for all newly created user accounts. CCE considers a citation that specifies a minimum password length of eight and another citation that specifies a minimum password length of 14 as being comparable. Both references are about the same configuration affect or issue. They differ only in their specific value.
• Multiple Mechanisms: In Microsoft Windows XP, you can establish the minimum password length by using a registry editing tool to create and set a specific registry key. Or you can accomplish the goal by using the local security policy tool. Or you can use an active directory group policy editor tool to achieve the same goal. CCE considers these three technical mechanisms to be comparable. While these different technical mechanisms may have subtle but significant differences and implications, they are comparable in that they are about the same configuration affect or issue. They differ only in the means used to achieve that affect.
• Shared Security Model: There are times when two different software packages may contain comparable configuration settings. This can happen if the packages share a common or commonly derived code base. This often happens among UNIX or Linux implementations and frequently happens when new versions of a platform are released that reuse functionality from prior versions. This can also happen when two platforms implement the same protocol. In these circumstances, the two different platforms have some commonality in their conceptual security model. For example, the security model for shared folders (directories) is the same for both Microsoft native file sharing (SMB) and for Samba implementations on Linux. In these cases, CCE considers the configuration statements to be comparable as they are about the same configuration affect or issue and based on the same conceptual security model-the security model of the SMB protocol. They differ only in the implementation or distribution. Conversely, SMB and Microsoft’s NTFS file system are built on different models and conceive of file permissions in fundamentally different ways. References about SMB file permissions and NTFS permissions are thus considered to be non-comparable.

Achieving consistency in the decisions about what constitutes comparable (or non-comparable) references is, in practice, the most difficult aspect of the analytics of CCE creation. The current state of the art of these editorial decisions is documented in the CCE Editorial Policies page, a living document that reflects the evolving community understanding of comparability of references.

Reference Clustering and CCE Creation

The following analogy is intended to explain how comparable references form a CCE entry.

Plotting a set of references and technical mechanisms on a plane while grouping comparable references near each other look something like a constellation of stars. See below.

Clusters of Comparable References Plotted on the Plane

In this representation, each cluster of comparable references forms or creates a CCE entry. Stating it another way, a CCE entry is an identifier that is associated with a set or cluster of comparable references. See below.

CCE-1238-5

CCE-784-9

CCE-2876-1

CCE-3469-4

CCE Entries Assigned to Clusters of Comparable References

The core challenge involved in CCE creation is that given a set of references and technical mechanisms about a new platform as input, the analyst must:

1. Identify clusters of comparable references.
2. For each cluster output a new CCE entry.

The core challenge involved in CCE maintenance is that given a set of references and technical mechanisms about a platform for which CCEs currently exist the analyst must:

1. For each new reference search the CCE data to determine if there are any comparable references.
2. If comparable references are found, merge the new reference into the existing CCE.
3. If no comparable references are found, create a new CCE.
4. Output an updated CCE List.

Assumptions

In order to define the various process options by which CCE operates, the CCE Working Group has made certain assumptions to serve as guardrails for creating CCE entries.

Assumption 1: No single organization has the charter, capability, or subject matter expertise to produce CCE data for all platforms of interest. Therefore, the CCE process must accommodate the involvement of multiple organizations in order to achieve adequate coverage of all platforms of interest.

Assumption 2: Multiple organizations publish different but overlapping resources for high-interest platforms. The creator of the platform is clearly best positioned to define the set of references and technical mechanisms that define their platform and to create the CCEs for that platform. However, there are other subject matter experts (SME) who are also chartered to make statements about configuration choices for that platform. These include:

• Governmental authors of prose security guides such as NSA and DISA.
• Governmental authors of structured configuration guidance such as NIST’s Security Content Automation Program (SCAP).
• Commercial authors of prose security guides such as the Center for Internet Security.
• Creators of information sharing schemas such as WMI, WBEM, CMDB, OMG, and others.

CCE recognizes that historically different platforms will have different subsets of these types of SMEs involved in the creation of content that would feed into the CCE creation and maintenance process. And while many have strived to unify configuration guidance within a particular context, CCE understands that for high-interest platforms that are deployed in many different contexts, there will continue to be a wide range of SME published resources that should be taken into consideration in the CCE content creation process. Thus, for a platform (especially high-interest platforms) the CCE creation process must provide some mechanism by which configuration statements made by multiple organizations can be merged together.

Assumption 3: CCE data will be provisioned to the world via the Web. The full indexical utility of CCE Identifiers to foster fast and accurate correlation of configuration information will only be realized if and when they are widely used to tag configuration issues throughout all aspects of the industry. Currently, the MITRE Corporation is providing this capability. NIST’s U.S. National Vulnerability Database (NVD) also offers a Web-based repository of CCE content.

Assumption 4: The utility of CCE data will be determined by its basic correctness. As Wikipedia has demonstrated, community feedback and input into the content creation and maintenance process is a powerful mechanism by which content can be provisioned in an "emergent" manner. While the CCE creation process may attempt to leverage this power, Wikipedia has also demonstrated that malicious subversion of content creation and maintenance processes is a very real and likely prospect, especially when large state and financial interests are at stake.

CCE also recognizes that any federated content creation process is subject to drift and internal inconsistencies, even when all participating parties are well intentioned. Further, CCE recognizes that any federated content creation process opens up the possibility that authorized participants might disagree about the formation and correctness of particular data elements.

Finally, CCE recognizes that historically the different resources (e.g., guides, XCCDF, schemas, tools) produced by different SMEs about the same platform have different content orientations. Some of these resources also do not provide enough information to adequately create a CCE entry. This implies that a necessary aspect of the information merge process is the extension of some SME-authored resources to include all information needed to create a CCE entry. This could mean requiring the authoring SMEs to extend their traditional content creations processes to include the necessary additional information, or it could mean extending the SME data by those responsible for the information merge. At the current time, MITRE fulfills this role in the CCE creation process.

The CCE creation process must therefore provide some mechanisms for guaranteeing an adequate level of consistency, completeness, and correctness in the CCE data. Options include training and documentation for those involved in CCE data creation, controls on who is authorized to create and edit CCE data, some centralized review and oversight capability, copyright, and redistribution controls, or all of the above.

Assumption 5: CCE data must have sufficient structure to be useful. In order for CCE to be adopted and used widely across the industry, it must be provisioned in a manner that allows the data set to be parsed and modified. Currently, MITRE posts the CCE List as individual MS-Excel spreadsheet and in XML-format downloads.

CCE recognizes that the resources published by platform SMEs range from prose documents (e.g., MS-Word, PDF) to structured resources (e.g., XCCDF, WMI, CMDB, OVAL). Therefore, the creation process will need a defined schema for the shared representation and transport of CCE-related data. A step by which unstructured and structured data is merged into this centralized CCE data format will also be necessary.

Assumption 6: The CCE process will leverage structured configuration content standards and their supporting content creation processes to achieve efficiencies in the CCE creation process, thereby minimizing the need for a centralized CCE creation role.

That is, CCE recognizes that (1) the SMEs for a given platform are best positioned to provide the information needed to create CCEs, and (2) these same SMEs are increasingly using information standards like Extensible Configuration Checklist Description Format (XCCDF) and Open Vulnerability and Assessment Language (OVAL®). It would be natural to extend these developing capabilities among the SMEs to also provision structured CCE data. The more structured the data is that is created by the SMEs, the smaller the burden becomes on the other stages of the CCE creation process.

NOTE: CCE has grown out of the Common Vulnerabilities and Exposures (CVE®) project, which offers several lessons learned regarding a federated model of CCE content creation. CVE maintains a relationship with a set of organizations referred to as Candidate Numbering Authorities (CNAs). The list of current CNAs includes Apple, Cisco, Debian, Microsoft, Oracle, and Red Hat, among others. CNAs are given some amount of training on the proper assignment of CVE Identifiers (CVE-IDs), especially regarding the CVE content decisions. They are then given blocks of CVE-IDs to assign to vulnerabilities within their advisories. In this way, CVE today is operating on a federated CVE assignment model.

CNAs release their newly assigned CVE-IDs to the public in their security advisories. These advisories are typically released to the public as text or HTML publications and they typically vary considerably in terms of the amounts and kinds of technical details that are disclosed.

The creation of a structured CVE data stream is done based on a "pull" model. The CVE content team learns about new CVE-IDs issued by CNAs by way of the advisories. The CVE team then pulls the data down from these advisories, analyzes it for correctness and completeness, and then puts it into a structured format.

The CCE effort is taking place in a different environment in terms of content creation and provisioning. Adoption of semantically rich information standards for expressing configuration guidance such as the XCCDF standard and for expressing technical details such as OVAL may give us the opportunity to improve upon the CVE model to gain efficiencies in the CCE creation process. This is the basis for Assumption 6.

Additional Information

For additional information about CCE entries see About CCE Entries and CCE Editorial Policies.