[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 damann@mitre.org.   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:damann@mitre.org    |      cell:781.424.6003
==================================================================

Windows-CCE-draft-2-1.xls

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 (nkennedy@mitre.org) or 
Claire Murphy (cmurphy@mitre.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.
Page Last Updated or Reviewed: May 22, 2007