|
|||||
 |
 |
||||
| CCE Website is in "Archive" status — read the announcement | |||||
CCE List Editorial Policies — ArchiveDate: August 18, 2006 Document version: 0.1 This is a draft report and does not represent an official position of The MITRE Corporation. Copyright © 2006, The MITRE Corporation. All rights reserved. Permission is granted to redistribute this document if this paragraph is not removed. This document is subject to change without notice. Table of Contents
Summary and PurposeCCE Content Decisions (CDs) are intended to provide guidance on assigning CCE identifiers with some degree of consistency. The purpose of this document is to list and describe those content decisions and to provide examples of their application. While consistency is a goal of CCE, it is not the only goal nor even the highest goal. Providing useful identifiers is a higher goal and we recognize that utility may demand that we accept some degree of inconsistency. In particular, CCE attempts to enumerate the ways that humans name and discuss their intentions when configuring computer systems. We would be misguided to assume that system configurations are based on some universally recognized objective reality that would result in a natural, canonical enumeration of configurations. Instead, we recognize that systems are often over-specified, providing users with many different ways to achieve the same basic configuration goal. Also, systems generally provide users with user-interfaces in order to specify configurations and often these user-interfaces represent abstractions away from the internal system structures that implement them. Finally, the utility of CCE is driven primarily in its ability to bridge the gap between higher-level human readable contexts and lower-level technical implementations. The end result of these observations is that we must accept that CCE content decisions and the CCE ids will contain some degree of inconsistency. Content DecisionsCD.1 Effect vs. Technical Mechanism (Basic CD)RULE: Given a technical mechanism used to implement a configuration effect, a CCE id is assigned to a humanly understandable expression of the effect, not to the technical mechanism itself. DISCUSSION: CCEs must be human understandable. EXAMPLE 1: (Windows IPSec protection for Kerberos and RSVP traffic) Windows 2000 can be configured to ensure that Kerberos and RSVP traffic are protected by IPSec. This is implemented using the following Reg Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC\NoDefaultExempt In this example, the CCE entry should be attached to a human understandable phrase such as “Kerberos and RSVP Traffic Protected by IPSec should be properly configured.” The CCE should not be attached directly to the registry key. Instead, the CCE should be attached to the conceptual effect of the configuration, not the actual technical mechanism. CD.2 One Effect/Multiple Technical Mechanisms (Combine)RULE: In those cases where multiple technical mechanisms have the same general effect, they shall be combined in the same CCE id. This applies equally when: + A single platform provides multiple technical mechanisms
to achieve the same effect. This rule is enforced even in those cases when the different technical mechanisms have slightly different effects, which may result in significantly different security or operational implications. DISCUSSION: All Technical Mechanisms change the system in some manner. A CCE entry is assigned based on the essence of that change, not to the specific technical mechanisms that may be used to effect that change. EXAMPLE 1: (Password Length) In Windows, the setting of the minimum password length can be set in 2 ways. First, a local security policy could be used. Secondly, in an Active Directory context, this could be enforced with a Group Policy Object. These mechanisms may have slightly different implications with respect to when and if the minimum password length is enforced. Moreover, minimum password lengths may be enforced in very different manners in different operating systems such as Unix and Novell. Never the less, the basic concept of a minimum password length is the same. In this case, since the Technical Mechanisms are dealing with the same configuration-related goal of setting a minimum password length, CCE combines these Technical Mechanisms into a single CCE entry. EXAMPLE 2: (Solaris Services) In Solaris, services are started based upon their assigned ordering in a boot level. During bootup, first the kill service scripts are processed, then the start service scripts (in alphanumeric order) in the /etc/rc2.d/ and then the /etc/rc3.d/ directories. Therefore, there are at least two (similar) ways to disable a service at boot: (1) Remove the correct startup script (S[0-9].[service]) from the rc directories, or (2) add a kill script (K[0-9].[service]) at the next boot level to kill that service. Even though one method allows the service to start and later kills it, while the other prevents it from ever being run, they are both assign to the same CCE entry. Consider a CCE entry concerning the RCP service starting at boot-time. Two Technical Mechanisms associated with this CCE may be: + file presence - /etc/rc2.d/S71rpc CD.3 One Effect/Multiple Parameter Values (Combine)RULE: Given a single system object to be configured and given a set of different configuration choices for that object, a CCE id assigned to a humanly understandable expression that identifies the object and the configuration effect, not to set of individual configuration choices that are available. Instead, the configuration choices are expressed as parameters that are associated with the CCE id. Parameters should be used even in those cases where it is practically impossible to create an enumerated list of all of the valid values for the parameters. ( See Example 3. ) DISCUSSION: It is entirely possible for a Technical Mechanism of a CCE entry to contain multiple parameters, such as file access control, which may include file permissions (rwx) and file ownership (user/group), a listing of entries for inclusion into an ACL, or more OS-specific mechanisms (e.g., SE Linux controls). Under CCE, these multiple parameters remain as part of the same CCE entry; CCE does not split entries base on parameters. EXAMPLE 1: (Windows Account Lockout Threshold) In Windows 2000, the number of bad logon attempts that are allowed before the account is locked out is configurable. The Center for Internet Security Level-1 Benchmark, which is a minimum due care level of security specifies this to be set to 50 or less. Other configuration guides such as the NSA Security Guide dictate a more stringent setting of three bad logon attempts. In this case, the CCE id attaches to the statement “The account lockout threshold policy should meet minimum requirements.” The maximum number of allowed bad logon attempts is expressed as a parameter for this CCE. EXAMPLE 2: (Service Permissions for ftp) The ftp service may be allowed or disallowed on a network operating system depending on its security context. In this case, we do not attach CCE ids to statements of the following forms: + The ftp service should be disabled Instead, we attach the CCE id to the system object in question, which in this case is the ftp service. The different logical configuration states for the object (disabled, enabled) are handled as a parameters for the CCE. An acceptable form for this CCE id would be: + The correct service permissions for the ftp service should be assigned (enabled/disabled) EXAMPLE 3: (Windows Directory Permissions) In Windows 2000, it is not uncommon for configuration guides to dictate permission settings for the %ProgramFiles% directory. In this case, the CCE id attaches to a statement of the form: + The required permissions for the directory %ProgramFiles% should be assigned The various permissions for different specific users or user groups should be expressed as parameters to this CCE. We leave it to the checklist authors to enumerate all of the specific permissions that are desired for the %ProgramFiles% directory. All such statements will be assigned the same CCE id. This is a valid use of parameters even though it is practically impossible for CCE to enumerate all possible or even likely permissions that might be specified for this directory. CD.4 Single Object vs. Parameters (Split)RULE: In those cases where the same type of configuration statement could be made for an entire set or class of system objects, we assign individual CCEs for each individual system object. Specifically, the class of system objects are not expressed as a parameter of a single, higher-level CCE. DISCUSSION: Some system objects lend themselves to a natural categorization that might allow entire sets of system objects to be described in terms of a parameter. If CCEs were assigned at a higher level and individual system objects were identified within a single CCE by the use of a parameter, we would, in effect, be dictating the use of a multi-level name space. Our observation is that the vast majority of configuration statements made are statements about individual objects. For this reason, we attach CCEs to individual system objects, not to classes of objects.
EXAMPLE 1: (DISALLOWED - services running) It is common for configuration guides to specify which services can and can not be running. In this case, we do NOT attach a CCE id to a high-level statement that treats the specific services as parameters. For example, a statement of the following kind is NOT allowed: + The startup type of a service should be correct EXAMPLE 2: (ALLOWED - services running) The following statements are appropriate CCE statements. Each of these statements should receive their own CCE ids despite the fact that the class of network service could conceptually be described with a logical parameter. This enforces the content decision that CCE ids attach to single system objects.
+ The startup type of the Fax service should be correct CD.5 Issue Decomposition (Split)RULE: In those cases where a configuration statement is the composition of other, lower-level configuration statements, CCE ids should attach to the lower-level individual configurations, not to the higher-level compositions. DISCUSSION: If a configuration statement can be decomposed into lower-level system objects or lower-level configuration decisions that relate to same system object, then the configuration statement is too high-level to receive its own CCE id. EXAMPLE 1: (DISALLOWED - SSH in Solaris) In the CIS Solaris Benchmark, there is a recommendation to enable the ssh service. This recommendation is given in the form of a script that implements several specific configuration settings to properly configure ssh according to the CIS specifications. In this case, we would not associate a CCE with the statement: + Run ssh and configure it according the CIS standard Instead, we would associate a CCE entry with each of the lower level issues involved with running and configuring ssh. EXAMPLE 2: (ALLOWED - SSH in Solaris) Extending from Example 1 above, in this case, we would associate a CCE entry with each of the lower level issues involved with running and configuring ssh. Example Configuration Settings that have different results, and thus would require different CCE entries include:
+ SSH uses protocol 2 only?
EXAMPLE 3: (DISALLOWED - Strong Passwords) The statement “Strong passwords should be used” is not a CCE entry, because it does not specify what aspect of strength is under discussion nor does it specify a particular setting. The configuration goal of strong passwords is properly decomposed into lower-level issues. ( See Example 4. ) EXAMPLE 4: (ALLOWED - Strong Passwords) Extending from Example 3 above, the configuration goal of “strong passwords” is decomposable into lower-level issues. The following list would be acceptable CCE entries:
+ The "maximum password age" policy should meet minimum requirements
CD.6 Related Configurations (Split)RULE: In those cases where one configuration setting has a direct effect on another configuration setting, different CCE entries are assigned to each. This rule applies even in those cases where one configuration setting entirely subsumes or overrides the effect of the other. DISCUSSION: As systems have evolved over time, so to have the mechanisms used to configure the systems evolved. Not only is it common for there to be multiple technical mechanisms to implement the same basic effect (See: CD.x One Effect/Multiple Technical Mechanisms), but it is also common for there to be fundamentally different system management approaches to the same high level goal. Often, a system administrator may choose to use or another approach but there are also times when they choose to use more than one approach concurrently. EXAMPLE 1: (File permissions for files shared under SMB) On systems using file sharing using SMB, a remote user's access rights to files is determined by 2 different file permission systems. The first is managed by SMB directly. The second is determined by the native file system. In the case where configuration statements are made regarding files or directories that are shared, separate CCEs should be issued for the SMB permissions and for the file system permissions. EXAMPLE 2: (inetd and inetd services) As discussed in Example 2 of CD.x Single Object vs. Parameters, CCE will have separate entries to describe the start type for individual network services including: + The startup type of the Fax service should be correct At the same time, in Unix, several standard network services can be invoked through the use of the system service, inetd. These include: telnet, finger, tftp and ftp, among others. Disabling the inetd service can be accomplished with a technical mechanism, such as the presence of the file /etc/rc2.d/S72inetsvc. This will have the direct effect of also disabling the services invoked by inetd. In this case, we give disabling inetd its own separate CCE entry. CD.7 Configuration Setting / Compliance Check (Split)RULE: A global configuration setting and the existence of items that violate that configuration setting receive separate CCE ids. That is, the following 2 types of statements will each be given their own, separate CCE ids: + Apply a configuration setting to ensure that all newly created
instances of type X have the characteristic Y DISCUSSION: Some configuration settings have the effect of enforcing some characteristic on the creation of all newly created instances of some system object. However, given such a configuration, it is also possible for a system to have instances of that object type that fail to have the desired characteristic. This may be the result of instances that were created before the configuration setting was applied, instances that were imported from another system or created via another mechanism. EXAMPLE 1: (Minimum password length) The following statements receive their own CCE ids: + The "minimum password length" policy should meet minimum
requirements CD.8 Machine verifiability (Exclude)RULE: It is not uncommon for configuration guides and other documents to describe security and operational requirements for a system that cannot be directly verified based on facts about the machine state of the system. Such statements are explicitly excluded from the scope of CCE. DISCUSSION: The purpose of this content decision is to ensure that CCE entries DO NOT include high-level issues that are not related to the machine state of the system. EXAMPLE 1: (Written passwords) The following statement cannot be verified based on facts about the machine state of a system. It should not be assigned a CCE id: + Passwords should not be stored in written form and stored in close proximity to the machine CD.9 No Patches (Exclude)RULE: No CCE id will be associated with configuration statements regarding the installation of a patch. DISCUSSION: This decision is a scoping issue. At this point in time, CCE will not deal with patches nor the enumeration of all files for which file version statements may be made. CD.10 No File Versioning or File Integrity Issues (Exclude)RULE: Whether or not an installed version of a file meets a recommended criterion, is beyond the scope of CCE. Issues may include but is not limited to: file version, time stamp, size, or md5 checksum. No CCE entry will be issued for these. DISCUSSION: A version may be a prerequisite for a specific CCE issue, if, for example, a newer version adds a new configuration setting or adjusts a previous one. EXAMPLE 1: All of the new Technical Mechanisms introduced by a new Windows Service Pack would be assigned to CCE entries. CD.11 No File Installation or Presence Issues (Exclude)RULE: The existence of a file can only be associated with a CCE entry as a supporting technical mechanism. The actual CCE entry is associated with a more abstract description of the configuration effect achieved by the file's presence. DISCUSSION: If the presence of a file, or lack thereof, does not have a direct impact on system security or performance (outside the use of disk space), then it is outside the scope of CCE. EXAMPLE 1: In UNIX, the presence of certain logging files enables the related logging to occur. In such cases, the CCE should attach to the abstract issue of "[type] of logging is enabled." CD.12 No Non-software Configurations (Exclude)sRULE: CCE entries are currently limited to software-based configurations Recommendations for hardware and/or physical configurations are not supported. All CCE entries must be able to be machine verifiable through a software application, such as OVAL. |
