[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The Common Configuration Enumeration (CCE)
All, As discussed at the last 2 OVAL Developer Days and in the most recent CVE Editorial Board Teleconference, the Common Configuration Enumeration initiative is attempting to assign identifiers to configuration issues. Since the very first days, the CVE Editorial Board has recognized the need to address both software flaws (aka vulnerabilities) and mis-configurations (aka exposures). The CCE project is logical next step in the evolution of CVE to finally address the 'E' in CVE. As members of the CVE and OVAL Editorial Boards, you are invited to join the CCE Working Group. The purpose of the Working Group is to help validate the current draft CCE list for Windows. Attached you will find an Excel spreadsheet containing the current CCE draft along with a text file that describes the meaning of the fields. You will also find a description for a CCE Working Group meeting, which will be held on Wednesday, September 20. This meeting will be held at the NIST Campus in Gaithersberg, MD on the day following NIST's National Security Automation Conference & Workshop. (http://csrc.nist.gov/checklists/workshop.html) If you are interested in joining the CCE Working Group, please contact me at email@example.com. Please note, I will be away from the office till August 28 -Dave ================================================================== David Mann, Ph.D. | CVE Project Lead | The MITRE Corporation ------------------------------------------------------------------ e-mail:firstname.lastname@example.org | cell:781.424.6003 ==================================================================
COMMON CONFIGURATION ENUMERATION WORKING GROUP MEETING ====================================================== OVERVIEW -------- The CCE Working Group will be holding a face to face working session on Wednesday, September 20. NIST has graciously offered to host this meeting on the day following their "National Security Content Automation Initiative Conference", which will be held on September 18 and 19. (http://csrc.nist.gov/checklists/workshop.html) DATE AND TIME ------------- Wednesday, September 20, 2006 9:00 am - 1:30 pm (optional afternoon session from 1:30 - 3:00) LOCATION -------- NIST Campus in Gaithersburg, Maryland Rooms are TBA PURPOSE ------- The primary objective of this meeting is for the group to come to agreement on how CCE identifiers and definitions should be constructed. In particular, we will be considering a small subset of draft CCE entries with the purpose of coming to agreement on: + Is the CCE entry defined at the correct level of abstraction? + How should the CCE Definition be worded? + How should logical CCE Parameters be defined? + How should CCE Technical Mechanisms be defined? + Should CCE Technical Mechanisms be referencable in a standardized manner and if so, how? + What should the relationship be between CCE ids and OVAL definitions? + What should the relationship be between CCE ids and XCCDF rules? If time permits, we will also consider the following questions: + What should be the format of the CCE identifiers? + What should the process be for creating and vetting new identifiers for other platforms? WHO SHOULD ATTEND ----------------- Attendees should have a working knowledge of the current draft CCE list for Windows as well as a familiarity with both OVAL and XCCDF. It would be helpful if attendees to the workshop also have familiarity with one of more of the following problem areas: + Authoring configuration check list documents + Authoring checks for configuration audit tools + Integrating data from multiple configuration tools + Automated configuration management + Lower level configuration data models such as WMI + Automated configuration management Current members of the CCE Working Group are encouraged to attend as are interested members of the CVE Editorial Board and OVAL Editorial Board. It should be noted that this meeting will be a working session with little to no time devoted to background. Please note, registration will be limited to approximately 25 persons and preference will be given to current CCE Working Group members. AGENDA ------ 09:00a - 09:15a - Greetings and Introductions 09:15a - 10:30a - Working Session 1 10:30a - 10:45a - Break 10:45a - 12:00p - Working Session 2 12:00p - 01:00p - Lunch at the NIST Cafeteria 01:00p - 03:00p - Working Session 3 (If needed) REGISTRATION ------------ Please send e-mail to Nancy Kennedy (email@example.com) or Claire Murphy (firstname.lastname@example.org) to register. Please include the following information: + Name + Phone number + e-mail address + Company or Organization + Citizenship
Currently, entries in the CCE list contain the following attributes: 1. CCE IDENTIFIER – Like CVE, CCE assigns identifier tags to each commonly recognized configuration issue. These identifiers are intended to be unique tags or keys, not descriptive names. By way of a loose analogy, CCE ids are like scientific names for animals, providing a precise identifier for a species that is agreed upon by the technical community but which may have little or no meaning in common language usage. 2. DESCRIPTION – CCE entries contain a humanly understandable description of the configuration issue. This description is intended to describe the generic issue. In particular, it is not intended to make an assertion as to what particular configuration should or should not be made. For example, a valid CCE descriptions might be "The minimum password length should be set appropriately". CCE makes no assertion whether the minimum password length should be 8, 10 or 14. It only describes the generic and non-qualified issue of minimum password length. 3. LOGICAL PARAMETERS – CCE entries contain a list of logical parameters that would be needed to be specified in order to implement a CCE on a system. For example, for the CCE associated with "The start up permissions on telnet should be set appropriately" (for Windows) the logical parameters would be Automatic, Manual and Disabled. CCE entries distinguish between such humanly understandable logical parameters and machine understandable parameters such as the specific registry key values that might be associated with the logical notions of "Automatic", "Manual" and "Disabled". 4. TECHNICAL MECHANISMS - For any given configuration issue, there may be more than one way to implement the desired result. For example, in Windows the issue of "The Autoplay feature should be set correctly for all drives" issue can be set either with a direct registry key edit or by way of a Group Policy Object if the system participates in an Active Directory domain. And in most forms of Unix and Linux, the issue of "The start up permissions for FTP should be set correctly" can be done in multiple ways. One way to understand the distinction between the CCE Description and its corresponding set of Technical Mechanisms is that the former describes a goal and the latter describes a set of ways to achieve that goal. It should be noted that this distinction has been and continues to be topic of lively discussion among the CCE participants and may change significantly as CCE matures. 5. REFERENCES – Each CCE entry has a set of references into published configuration guidance documents such as the NSA Security Guides, the Center for Internet Security Benchmark, and DISA Stigs. These references point to the specific sections of the documents or tools in which the configuration issue is described in more detail. These references serve 3 purposes. First, they provide a logical linkage to more detailed information. Second, the references validate the need for a CCE id for any given configuration issue. Thirdly, the reference validates that the CCE id is described at a level of abstraction that used and accepted within the community.