|
[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.
|
|
