Use Cases — Archive

Introduction

The creation of the CCE was motivated by five separate use cases within the context of security configuration management in the enterprise. The core use case is the internal Configuration Management Lifecycle that is conducted within an enterprise, described below in a four part process: system design, pre-deployment testing, deployment and assessment, and remediation.

The remaining four CCE use cases can be seen as spokes emanating from the core cycle as they all relate to coordination and communication between some part of the configuration management lifecycle and some set of stakeholders. These four use cases include: system design, configuration audit, consolidated audit reporting, and regulatory compliance.

A common theme among all of these use cases is the use of CCE-IDs to facilitate faster and more accurate correlation of configuration information across different, but closely related practices. Each of the practices has their own processes, procedures, and domain expertise. Additionally, members of each of these practices share information across their domain boundaries with other practices as part of their work. As work is conducted across domains, sometimes a set of commonly shared "objects" will emerge that allow the different practices to cooperate with each other and to coordinate their actions. These objects are sometimes called "boundary objects." CCE-IDs can act as boundary objects in all five use cases.

The concept of boundary objects was introduced by Geoffrey Bowker and Susan Star in Sorting Things Out: Classification and Its Consequences (Inside Technology), MIT Press, Boston, 1999:

Boundary objects are those objects that both inhabit several communities of practice and satisfy the informational requirements of each of them. Boundary objects are thus both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain common identity across sites. They are weakly structured in common use and become strongly structured in individual-site use. These objects may be abstract or concrete. Star and Griesemer (1989) first noticed the phenomenon in studying a museum, where specimens of dead birds had very different meaning to amateur bird watchers and professional biologists, but "the same" bird was used by each group. Such objects have different meaning in different social worlds but structure is common enough to more than one world to make them recognizable, a means of translation. The creation and management of boundary objects is a key process in developing and maintaining coherence across intersecting communities.

An excellent example of boundary objects that most users should be familiar with are the International Standard Book Numbers (ISBN) used to identify books. In the book world there are many different communities of practice, such as book publishers, retailers, and libraries, each have their own processes and procedures to track and manage information about books. We might expect two book publishers to have similar practices to have the same billing and inventory systems, but we would not expect that an inventory system tailored for book publication would be usable in any way by a library. The semantic or schematic meaning of "book" is different for these communities of practice. But despite these different localized definitions of books, the practices can coordinate their actions using ISBNs. CCEs are designed to foster this kind of cross-boundary coordination of action for the different practices within the context of security configuration management.

In each of the use cases discussed below CCE entries act as boundary objects between two different but related communities and provides them with a mutually recognized identification of a configuration issue.

BACK TO TOP

Configuration Management Lifecycle

This use case involves the communication and coordination of work among four (or more) groups involved in configuration management within an organization including system design, pre-deployment system testing, system provisioning and deployment, and configuration audit and remediation.

Scenario

Company A plans on deploying a set of new systems on their network. To accomplish this, four (or more) groups must coordinate their action in the context of a broader configuration management lifecycle. First, the system designers must design the system to be compliant with the set of requirements that may include internal security policies, externally defined security requirements, and operational requirements. Second, system testers will build one or more systems according to the design to test the system’s operational readiness. Third, the system deployment group will be responsible for deploying the tested system on the network. Finally, the assessment and management group (which may be further separated) is responsible for testing to ensure that systems remain compliant with the agreed upon configuration settings and for making changes as needed.

Typically, configuration standards for systems are captured in internally authored documents or spreadsheets. While there is a movement towards more automated expression of configuration standards, these automated solutions are typically focused primarily on a single part of the configuration management lifecycle and are thus inaccessible to groups in other parts of the lifecycle. Examples of these emerging technologies include policy management products, system provisioning systems, network management capabilities (e.g., active directory group policy objects), and configuration benchmarking and audit tools.

Problem

In order for the different groups in the configuration management lifecycle to coordinate their actions, they need to be able to efficiently and accurately identify specific configuration controls with each other. Without CCE-IDs, these groups must rely on the "names" presented to them in the context of different written documents (e.g., security configuration guides) and different security and IT tools (e.g., Group Policy Objects (GPOs)). While these names are often similar they are rarely the same and two kinds of errors are typically encountered. First, configuration issues that are the same but named slightly differently in different contexts are not recognized as being the same. Second, issues that are closely related but different are not recognized as being different due to the similarities of their names.

As a result, the internally authored written configuration standard is not effective in coordinating the actions of the different groups within the configuration management lifecycle. Mapping errors are made at each step of the process and the groups must spend a large amount of analysis time to resolve the discrepancies. The different groups need a mechanism that will allow them to quickly and accurately collaborate across each step of the lifecycle.

How CCE Helps

By annotating their internally defined configuration standards with CCE-IDs, the groups involved in different parts of the configuration management lifecycle are better able to communicate with each other and coordinate their actions. At each step of the process, a given group can use the CCE-IDs to find more information on the configuration issue by accessing configuration information sources with which they are familiar. In this way, they can more quickly and accurately map the configuration standard into their own localized context and tool set.

In this scenario, CCE-IDs act as boundary objects across the boundaries of the different practices within the configuration management lifecycle. While each individual practice (design, testing, deployment, audit, and remediation) all deal with the concepts of configuration controls, the precise naming or articulation of those controls typically differs from practice to practice. The CCE-IDs are shareable objects that can be easily mapped into each practice.

BACK TO TOP

Guide Document Authoring and System Design

This use case involves the cross-boundary coordination and communication that takes place between configuration guide authors and system designers.

Scenario

A configuration guide author has been tasked with writing a guidance document for a particular platform. The deliverable produced will be a human-readable prose document that is provisioned either as a static document (e.g., PDF, MS-Word) or as a dynamically allocated document (e.g., HTML, XML, Extensible Configuration Checklist Description Format (XCCDF)). The author may work for the primary vendor organization that sells the platform (e.g., Apple, Microsoft, Red Hat, Sun) or an organization that is responsible for providing guidance for large populations (e.g., Center for Internet Security (CIS), U.S. Defense Information Systems Agency (DISA), National Institute of Standards and Technology (NIST), National Security Agency (NSA)).

At the same time, a system designer has been tasked to design a new (or update an existing) configuration standard (template) for a system to be deployed within their organization. The designer is required to consider the security implications of each configuration control to ensure that the system complies with the company’s security policies. Additionally, she is required to document if and how the design complies with industry best practices. To achieve this, she will read security configuration guides published by the platform vendor and by relevant third parties. She will also review information on particular configuration settings found on Web sites maintained by the vendor and in discussion forums. The end product that the system designer will produce will be a document that describes the configuration settings to be applied. She will, in most cases, also be required to document the references from the relevant best practices documents in order to justify her decisions.

Problems

One of the primary features of security configuration guides is their reliance on prose as the primary means of communication. This make these documents human readable. It also allows the author to provide generalized guidance that should be human interpreted in order to be applied to a particular technical implementation or within a particular operational setting. For example, the generalized guidance to "use strong passwords" is valid guidance but it must be interpreted by a human in order to be applied within a particular context since there are many aspects of password strength. On the other hand, the very strength of human prose that allows it to be useful for describing ambiguous concepts also allows for different readers to interpret the guidance in different ways. Not all technical readers will identify the same list of password attributes when interpreting "use strong passwords".

Increasingly, security guide authors are beginning to augment their human prose with specific technical line items that enumerate the lists of corresponding technical controls. While this helps to disambiguate portions of the human prose, this is not a complete solution for two reasons. First, lacking CCE-IDs, the configuration guides that the system designer consults all refer to individual configuration settings with their own terminology, which means that it is common for the same issue to be identified with different names in different documents. Second and closely related, due to frequency of related sets of functionality, it is not uncommon for related but significantly different configuration controls to be "named" in nearly the same manner. That is, a common error occurs when the system designer attempts to reconcile guidance from two different sources about what she believes to be about the same configuration control (due to their similar names) when, in fact, they are about different controls. Third, owing to the fact that many configuration controls are themselves built upon other sub-systems and system calls, it is not uncommon for different security guides to annotate their prose by attempting to enumerate system controls at different levels of abstraction or granularity, which further confuses system designer when she attempts to reconcile the two guidance documents.

The lack of a common way to identify the configuration controls mean that the system designer must search the documents either by hand or using error-prone keyword searches if she has an electronic copy of the document available. As a result, she must spend a significant portion of her time attempting to locate the applicable section within the guidance document. The similarity in the naming practices of similar but different controls means that sometimes she must spend additional analysis time to determine if sections from two different documents are, in fact, referring to the same controls. The lack of common identifiers for configuration controls also means that she must rely on error-prone keyword searches when consulting online resources maintained by the vendor or when searching the Web for addition information. The result is longer analysis times during her research and more errors when attempting to integrate information from multiple sources.

How CCE Helps

Written security guides that are annotated with CCE-IDs allow the system designer to quickly and accurately identify which sections of the document relate to the configuration control with which she is concerned. The use of CCE-IDs to augment the human prose makes is more likely that the enumerations of technical controls that appear in two different documents are more likely to be expressed at the same level of abstraction (the level of abstraction of the corresponding CCE-IDs), which makes it more likely that the guidance documents are conceptually comparable. Additionally, the use of CCE-IDs in multiple security guides means that system designer can quickly and accurately correlate the information from both guides despite the fact that the guides are formatted differently and may refer to the same issues with slightly different proprietary names. The use of CCE-IDs allows her to quickly identify and ignore those sections that do not relate to the control she is interested in, despite its similar "name." This reduces her analysis time and makes it more likely that she will avoid mistakes made from attempting to incorporate erroneous information.

The use of CCE-IDs in online support facilities provided by the vendor and other online resources including discussion forums allow the system designer to quickly and accurately find additional relevant information on the Internet. This type of increased findability can be witnessed today with the use of CVE Identifiers.

Regarding the use of CCE-IDs as boundary objects in this scenario, we note that system design and security guide authoring are different but related practices. While is common for security guide authors to have had experience in system design and administration, the process of creating guides is different from the process of designing systems. To be effective, both security guide authors and system designers need to collaborate, albeit indirectly through the publication and reading of the written security guides. While a particular configuration control will have a different form of expression in guides compared to system definition, they are closely related. The CCE-ID is plastic enough to be usable in both domains, allowing the work of configuration guidance and system design to be effectively related.

It should be noted that the assignment of CCE entries on a per-platform group basis facilitates the inclusion of CCEs in the security guides and online help systems. Typically, these resources are compiled and created by groups of experts on a per-platform group basis. By issuing CCEs on per-platform basis, CCEs are more in line with the existing practices within the security guidance domain.

BACK TO TOP

Configuration Tool Configuration

The following use case concerns the communication and coordination between creators of configuration management tools and end users of those tools. This use case can be seen as a single component of the configuration management lifecycle use case described above. However, this use case emphasizes the external cross-boundary coordination between the vendor and the customer organization, whereas the configuration management lifecycle emphasizes the internal cross boundary coordination between groups within the organization.

Scenario

A vendor produces a tool targeted to a portion of the configuration management lifecycle. Some of the most commonly used products consist of configuration management tools that enforce or change configuration settings on end systems (e.g., MS Active Directory Group Policy Objects), and configuration audit tools that are used to test the configuration status of end systems. As the vendor creates the product, they strive to represent configuration issues in their product in a manner that will be the most useful and comprehensible to their customers, where their "customer" includes not only the end users of their product but also stakeholders within the customer’s organization that are involved with other aspects of the configuration management lifecycle and must coordinate and communicate with both the product and end users of the product. The vendor is faced with the challenge of how to present names or identifiers for configuration controls or configuration checks that will allow end users to understand the meaning of a single control or to find a particular control in the set of controls.

An IT administrator who is responsible for the deployment and operational use of a configuration management tool has been tasked with the responsibility for tuning the tool to implement a step in the configuration management lifecycle. As a part of the lifecycle, the administrator takes as input some set of configuration controls. This may be set of controls to be deployed or enforced using a configuration management tool or a set of controls to be audited for using a configuration assessment tool. To successfully complete this task the administrator must non-ambiguously map the input set of controls to specific checks or functional capabilities within the tool. In most cases, the administrator will also be required to document the mapping between the written configuration document and the specific checks within the tool.

Problem

Lacking CCE-IDs, the tool vendor must name individual checks or controls within their product that are based on their own proprietary naming conventions. These proprietary names are typically related to but still different from other names for the same configuration controls used in other tools or documents. In fact, the may choose to intentionally differentiate their own proprietary naming schemes from the naming schemes used by other vendors and security guide authors to avoid any possible challenges regarding copyright violations. Similar to challenges faced by configuration guide authors, the vendor must also choose the appropriate level of abstraction or granularity for their controls or checks so that the units of information in their tool are best aligned not only with the end user’s immediate needs, but also so that the tool integrates well with the other tools, capabilities, and stakeholders involved in the configuration management lifecycle at the user’s organization.

Lacking CCE-IDs in both the list of desired configuration controls that forms the input to the process and in the configuration management tool, the user must rely on detailed human analysis to successfully map the configuration control list into the tool. To accomplish this, the user will need to rely on her analysis of detailed documentation provided by the vendor to each control. The mapping errors produced by this process are similar to the mapping errors faced by the system designers. A control in the tool that matches a control in the input list might not be recognized as being the same. Conversely, the administrator may map an input control to a control in the tool when, in fact, the controls are different. Worse, if the controls in the tools and the controls in the input list (and the rest of the organization’s configuration management practices) are at different levels of abstraction, it will be practically impossible to map the input list into the tool with a high degree of one-to-one correspondences.

How CCE Helps

When both the input list of controls (generated by another part of the organization’s internal configuration management practice) and the controls in the vendor’s product are both correctly annotated with CCE-IDs, the administrator can quickly and accurately correlate the data sets with each other, which results in lower deployment costs and a minimization of errors which could otherwise be propagated throughout the rest of the organization’s configuration management lifecycle. More fundamentally, if both the tool and organization’s manner of managing configuration controls are both at the same level of abstraction, then the tool’s results can be integrated into the organization’s configuration lifecycle with a maximum number of one-to-one correspondences.

It is worth noting at this point that the majority of controls in configuration management and assessment products are managed on a "per platform" basis that is well aligned with CCE’s platform groups. By treating similar controls from different platform groups as being distinct, CCE-IDs are more closely aligned with existing configuration management tools and with the internal practices at organizations that produce internal configuration standards.

In this scenario, CCE-IDs act as boundary objects across the boundaries that exist between the configuration management tool and the customer’s organization. To be successful with their individual mandates, both the vendor and customer’s organization must forge and maintain a durable shared practice with respect to recognizing and managing configuration controls. By providing a sharable set of identifiers and by articulating a sharable level of abstraction for CCE definitions, CCE helps these different groups coordinate their practices.

BACK TO TOP

Audit Tool Result Integration

Like the previous use case, this use case can be seen as a part of the configuration management lifecycle. However, this use case typically is only associated with large, enterprise organizations that need to integrate the results from multiple configuration audit tools deployed by different parts of their organization. This use case may be properly seen as involving coordination and communication between multiple configuration audit tool vendors, as proxied by the organization attempting to integrate the results.

Scenario

An internal developer at an organization is responsible for consolidating system audit reports from several different sources in order to create and support an integrated reporting capability. The data sources he must integrate range from manually conducted internal system audits, manually conducted external third-party audits, and the results from several commercial audit tools that are deployed by multiple parts of the enterprise. The intended uses for the integrated reporting capability might include situational awareness for IT operations, decision support for IT management, or compliance reporting.

To fully accomplish this task, the developer must do two things. First, he must create a representation of configuration controls that can capture the maximum number of configuration controls tested for by the various assessment capabilities. Second, he must map each of different assessment capabilities into this centralized representation.

Problem

Lacking CCE-IDs, the difficulty lies in the fact that the findings from each data source express the results using proprietary terminology. The manual process of integrating the various audit reports is extremely time-consuming and error prone in the same way that other mapping exercises are. Comparisons must be done based on crude searching mechanisms such as keyword searches and must be verified by labor-intensive analysis of the individual items. The common error modes are similar as well. Items from different tools that check for the same configuration controls are not identified as being the same and items are matched with each other when, in fact, they check for different issues. More fundamentally, if and when the different tools, manual audit techniques, and the internal configuration management practice all use different levels of abstraction to represent configuration information, there are instances where one-to-one correspondence between items is impossible to achieve. As a result, integrated reporting is frustrated by extensive labor costs, costly errors, and ambiguous results that are a consequence of level of abstraction mismatches.

How CCE Helps

If all of the configuration tools and capabilities are tagged with CCE-IDs, the developer can map them together faster and with more accuracy. More deeply, if the developer builds his internal, unified representation of configuration issues based on CCE, then it is more likely that his reporting capability and the tools will all be managing and representing configuration information at roughly the same level of abstraction, thereby maximizing the number of instances in which data is correlated with a one-to-one correspondence.

It should be noted that the majority of configuration assessment checks in commercial products are created and distributed on a per-platform basis that corresponds closely with CCE’s platform groups. By assigning different CCE-IDs to similar issues that appear within different versions of platforms, CCE-IDs are in closer alignment with the common practices encoded in the auditing tools. This ensures a maximum number of one-to-one correspondences between CCE-IDs and checks with assessment products.

(Note: It is common for configuration audit capabilities and tools to test for configuration issues for which there are currently no CCE-IDs. In particular, it is common for audit tools to contain tests that produce list of system objects so that an administrator can review the list and make decisions as to whether or not the list is appropriate. For example, a common check of this type is to produce a list of all local users that have administrative rights on the system. The list of users with administrative privileges must be manually reviewed before an audit finding can be created. As of the time of writing of this document, CCE-IDs have not been issued for these types of issues, although they may at some point in the future. Contact cce@mitre.org for more information.)

In this scenario, CCE-IDs act as boundary objects across the boundaries that exist between the different configuration assessment tools and capabilities. While the specific tools vendors may or may not intend to coordinate and communicate with each other, the data integration needs of the organization demand that the tool output be integrated. In a sense, the organization’s developer who is responsible for the data integration acts as a proxy through which the vendor tools communicate with each other and the specific work by each proprietary tool is coordinated with the work done by other tools. By providing a sharable set of identifiers and by articulating a sharable level of abstraction for CCE definitions, CCE helps the proprietary practices within the different tools be coordinated with each other.

BACK TO TOP

Regulatory Compliance

This use case involves the cross-boundary coordination and communication that takes place between practitioners within the configuration management lifecycle and stakeholders with regulatory compliance interests. These stakeholders may be internal to the organization or external to the organization, but in either case, they are not directly involved in the configuration management lifecycle directly. Rather, they are interested in how the organization’s configuration management practices support certain regulatory compliance goals.

These regulatory goals may be motivated out of a need to comply with applicable laws and accords such as Sarbanes-Oxley, HIPAA, FISMA, Basel II, industry partnership standards such as VISA/PCI, or even their own internal policies. However, IT controls are not mapped into laws or regulatory mandates directly. Rather, compliance is judged from the perspective of security standards or auditing frameworks. Examples of frameworks include ISO 17799, COBIT, NIST sp800-53, ITIL, and DoD 8500.2.

Scenario

A member of an organization’s configuration management team has been tasked with documenting how their internal configuration standard for a particular platform comply with or support a particular set of regulatory compliance requirements. The deliverable that she is responsible for providing is a document that maps the configuration standard into a set of requirements, which is often derived from a framework document. At the same time, an auditor is tasked with reviewing the organization’s configuration standards to determine how well it complies with or supports the list of regulatory goals.

The collaboration between the configuration management team and the auditor will take on one or both of two forms. First, the auditor may choose to directly inspect artifacts and documents from the configuration management practice that represent or document how the configuration standard is defined and deployed. This might include the written configuration standard produced by the system designer, and shared with the rest of the configuration management team. This might also include inspecting data stored in the configuration deployment tools being used such as active directory group policy objects. Or this might include review of configuration audit tool results.

The second way that configuration management team and the auditor may communicate is via a report that maps the specific configuration controls to the list of regulatory requirements. This mapping is sometimes referred to as a requirements traceability matrix (RTM). Since framework documents are written to address a different point of view that is typically platform independent, it is common for RTMs to contain both one-to-many and many-to-many relationships.

Problem

Without CCE-IDs, the configuration management team must present their configuration standard for the platform using either their own internal naming conventions or by borrowing from a non-standardized naming convention from one of their many tool sets. While their internal naming choices may have some degree of familiarity to those people working within the internal configuration management lifecycle, it will not be familiar to the auditor. So, without CCE-IDs the auditor and configuration management team must work to make each individual configuration item comprehensible to the auditor. To accomplish this, they will need to rely entirely on the configuration team’s internal documentation to help clarify each configuration item and then map that to the auditor’s own expectations of the list of controls. As with other mapping exercises, this process is labor-intensive and error-prone.

More deeply, it is not uncommon for auditors to think about configuration controls at different levels of abstraction in different contexts. It is not uncommon for auditors and practitioners within the configuration management lifecycle to think about and discuss configuration controls at different levels of abstraction.

How CCE Helps

When the organization annotates its own internal configuration standards with CCE-IDs, it becomes easier for the auditor to assess the compliance. With CCE-IDs, it would be possible for the auditor and configuration management team to quickly and accurately compare the organizations RTM with other industry best practice RTMs. That is, by standardizing the identification of the configuration controls with CCE-IDs, it becomes possible to articulate standardized expected RTMs for a particular platform. Also, with CCE-IDs the auditor can quickly and accurately review how the configuration standard is implemented across all aspects of the configuration management lifecycle.

In this scenario, CCE-IDs act as boundary objects between auditors and participants in the configuration management lifecycle. In particular, we note that by establishing a standard at the level of abstraction that is common among practitioners within the configuration management practice and codifying that level of abstraction within CCE, CCE-IDs help clarify the otherwise mutable concept of a configuration control for the auditor, which allows the auditors to better orient themselves to the expressions of controls used by the configuration management practitioners. We must emphasize that the ongoing practice of cooperation between auditors and configuration managers is durable enough that it is possible for auditors to ultimately comprehend the controls, despite their own inclinations to think of controls at different levels of abstraction. However, the CCE-IDs acting as boundary objects help facilitate the mutual orientation of the auditing and configuration management practices to each other.

BACK TO TOP

This Web site is sponsored and managed by The MITRE Corporation to enable stakeholder collaboration.
All trademarks are the property of their respective owners.

Privacy Policy
Terms of Use