|
|||||
 |
 |
||||
| CCE Website is in "Archive" status — read the announcement | |||||
About CCE Entries — ArchiveIntroduction | Conceptual Parameters | Technical Mechanisms | Platform Groups | Additional Information
IntroductionCCE Entries (also called "CCEs," "CCE Identifiers," and "CCE-IDs") provide unique, common identifiers to configuration issues. A configuration issue may be a configuration statement that specifies a preferred or required setting or policy for a computer system, or a configuration control such as a particular registry key, file, or GPO setting. Every CCE entry includes descriptive elements that describe the CCE in a human-understandable manner. This consists of a textual description of the configuration element (with no specific recommendation) and the logical parameter values that might be associated with the control. For example, logical parameters might include "enabled" or "disabled" but not the actual storage values associated with these conceptual values. Each CCE entry also includes links to associated technical mechanisms (files, users, registry keys, permission bits), and references (prose statements, XCCDF, audit checks). Specifically, each entry on the CCE List contains the following:
See the CCE List Key on the CCE List page for detailed descriptions of each component.
Configuration issues can be found in a variety of repositories such as security guides, benchmarks, vendor guidance and documentation, configuration assessment and management tools, and consolidated reporting systems. CCE facilitates fast, accurate correlation between elements in these domains by assigning a unique name to each atomic configuration issue. Example:
In general, the scope of CCE-IDs is determined by the ability of an automated process to check the parameter of a particular configuration issue. For example, if a configuration statement can be verified by an assessment tool or applied by configuration management system, it should be assigned a CCE-ID. Configuration Issues that Should Get CCEs
The examples above are able to be verified automatically and can be set and checked using automated scripts, programs, or OS functions. These do not require any human effort in order to verify or interpret, and therefore can all be assigned CCE-IDs. Configuration Issues that Should NOT Get CCEs
There are several reasons why a configuration issue might not be assigned a CCE entry. For example, configuration statements that are effectively impossible to verify such as verifying the methods that a user might use to edit users.conf would require a substantial effort and is non-trivial without finer accountability systems within operating systems. Also, statements that require substantial human interpretation in order to be technically implemented are not assigned a CCE entry such as the statement "Use strong passwords", which is ambiguous and different analysts will interpret its technical meaning differently. Example:For Microsoft Windows XP, CCE would replace the statement "Use strong passwords" with these five statements:
See CCE Editorial Policies for additional information. Conceptual ParametersCCE conceptual parameters identify the possible values a configuration control might have at a conceptual level. For example, CCE considers the two statements below to be comparable as they are both about the same setting, the "Account logon lockout threshold". Example Configuration Statements:
These two statements differ only in the particular value for that setting asserted by the different guide authors. To capture this, CCE treats the number of maximum logon attempts as a parameter. The resulting CCE entry is: Example CCE:
It is important to note that the definition is written to be agnostic towards a specific recommended parameter value. CCE attempts to capture all potential values a configuration statement might encompass in a set of parameters. See CCE Editorial Policies for additional information. Technical MechanismsCCE technical mechanisms describe the underlying technical control(s) used to affect the desired change on the system as indicated by the configuration control. The following examples are for Windows Vista. Example Technical Mechanisms:
These examples illustrate that there are at least three methods for setting the "Log Dropped Packets" option in the Windows Firewall: (1) by making direct registry key edits, (2) by using the GPO editor, or (3) by using the Windows Firewall tool interface. While there are subtle reasons why an administrator would choose one method over another, there is agreement that each of these methods is accomplishing a comparable goal. Within CCE, these statements represent three comparable technical mechanisms for the same CCE. Example CCE:
See CCE Editorial Policies for additional information. Platform GroupsA CCE "platform group" roughly identifies the operating system or application to which a CCE entry applies. CCE’s platform groups adhere to the same level of granularity commonly found in security configuration guidance that are written for individual platforms, as well as in the sets of checks and other features found in configuration audit and management tools. They are a set of high-level "buckets" that imply a particular CCE is "related to" the OS or application named by the platform group. These groups are meant for human interpretation, and are not definitive declarations of a CCE entry’s relation to a particular platform. CCE Platform Group Examples:
Each CCE entry is assigned a single platform group. Similar configuration issues that cross the CCE platform groups are assigned separate CCE-IDs. For example, Windows 2000 is distinguished from Windows XP, but Windows XP pre-Service Pack 2 and Windows XP post-Service Pack 2 are not distinguished. In general, assignment of CCE entries to CCE platform groups are as follows:
Additional InformationFor additional information about CCE entries see CCE Entry Creation Process and CCE Editorial Policies |
|||||||||||||
