REFERENCES, REIFICATION AND REALITIES
The CCE Team needs your input on a possible change in how CCE IDs are identified within our CCE lists.
PROPOSAL: The information that defines individual CCE IDs will be modified, as follows:
a) All CCE IDs will be associated with a mandatory "Proposed By" field that identifies the organization that has proposed the creation of the CCE. MITRE will maintain additional information such as submission dates and contact information that will not be published in the CCE list. (Nearly all) current CCEs will be updated with "Proposed By: MITRE".
b) CCE IDs can be augmented by 1 or more optional "Affirmed By" and "Disputed By" fields that identify the organizations that affirm/dispute the validity of the CCE. All disputation's will be accompanied by a short (100 word max) text description. MITRE will maintain additional information such as submission dates and contact information that will not be published in the CCE list.
c) CCE IDs can be augmented by 1 or more optional "References" fields (currently, at least 1 is mandatory) that provide citations to external documents and resources that refer to the configuration control identified by the CCE ID.
DISCUSSION: Several issues have come together to force us to make this proposal. First, as all parties with experience in configuration management recognize, we observe that it is sometimes very hard to determine is a configuration control is "real" or not. Registry keys can be created that have no affect on system behavior and Unix gurus will argue for days about the affects of minute changes to .conf files.
In the face of this, MITRE has always taken the position that we alone are not positioned to assert that any particular configuration control is "real". Consequently, we have enforced a rule that no CCE ID would be published unless it was accompanied with at least 1 publicly accessible security guide. Our argument has been that whether or not the control was "real", the fact that it was discussed in a referencable document provided sufficient justification for the CCE ID to be issued.
Three significant things have changed since CCE was established. First, we are increasingly finding ourselves needing to issue CCE IDs to supplement structured data streams that are not being published in traditional paper security guide format. A large part of this is that the CCE's are now being created or proposed by content development teams outside of MITRE. This is exactly what we want to happen, but it creates a chicken & egg problem. How can we create a CCE for the structured content, when we have no published document?
Second (and this is incredibly exciting) we are coming to the point where some content authors in a position to produce proposed CCE IDs for all or nearly all controls for a platform, even those that would not traditionally be listed in a security guide. In past CCE Working Group meetings, we've discussed the possibility of this happening at some point in the future and the rise of structured configuration management information is making this a current reality.
Third, MITRE has always recognized that it is infeasible for any single organization to have the technical expertise needed to technically verify proposed CCE IDs for all platforms of interest. With our sponsors support and your direct feedback and guidance, MITRE has invested a good amount of technical expertise in creating CCE IDs for the most common operating systems and applications. This has allowed a set of initial CCE IDs to be created in volumes that make CCE useful. More importantly it has allowed us to learn and document the core principals involved in creating well-formed CCEs. However, the only way for CCE to scale to volume and breadth needed, MITRE must take on a new role as trainer of CCE ID creators and moderator of the process.
We envision a future in which CCE IDs are created along the following process:
a) Two or more organizations with expertise in a particular platform are identified.
b) MITRE spends time training these organizations on how to create well formed CCE content.
c) MITRE helps support the collaboration and information exchange among the organizations collaborating on the platform.
d) MITRE provides (non-technical) review submitted content and distributes newly proposed content to the CCE Working Group for feedback.
e) MITRE publishes the created and approved CCEs.
Our proposal then is a first step toward this new process for CCE content creation. Your feedback and guidance is eagerly sought.
David Mann | Principle Infosec Scientist | The MITRE Corporation
e-mail:[hidden email] | cell:781.424.6003
|Free forum by Nabble||Edit this page|