Crown Jewels Analysis

Definition: Crown Jewels Analysis (CJA) is a process for identifying those cyber assets that are most critical to the accomplishment of an organization’s mission. CJA is also an informal name for Mission-Based Critical Information Technology (IT) Asset Identification. It is a subset of broader analyses that identify all types of mission-critical assets.

MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to help customers acquire robust systems that can successfully execute their mission even when under attack through cyberspace. To do this, MITRE SEs are expected to be conversant in best security practices and the basic principles for analyzing and identifying IT assets that are critical to accomplishing an organization’s mission. They are expected to keep abreast of new and evolving techniques for identifying mission-critical assets.

Background

In a large and complex enterprise, it is difficult to know how problems in a portion of an IT infrastructure may affect the broader operational mission. CJA provides a methodology to help understand what is most critical—beginning during systems development and continuing through system deployment. CJA is often the first step in a Mission Assurance Engineering (MAE) process (see Figure 1), which provides a rigorous analytical approach to:

Identify the cyber assets most critical to mission accomplishment—the "crown jewels" of CJA.

MAE offers a common, repeatable risk management process that is part of building secure and resilient systems [3]. The underlying premise for performing a CJA is that protection strategies focused entirely on "keeping the adversary out" are usually doomed to fail (recall the Maginot Line). The Advanced Cyber Threat (ACT) has sophisticated capabilities that adversaries can use to gain and maintain a persistent presence in the hardware and software that make up mission systems—providing the opportunity to "attack" (i.e., deny, degrade, deceive) these assets at a time and place of their choosing. As cyber threats continue to escalate, it is prudent to assume that adversaries will aim to successfully penetrate and then deny and/or degrade our cyber assets, requiring us to maintain our ability to "fight through" such attacks. Because it would be prohibitively difficult and costly to design every system component to fight through all conceivable attacks, a CJA is used to identify the most important cyber assets to an organization’s mission—allowing systems engineers, designers, and operators to focus on ensuring that these critical components can effectively endure an attack.

Organizations (especially operational units) often have limited resources to use to find their mission-critical cyber assets, and yet they need a reasonably accurate idea of what those are. One technique for performing a CJA makes use of "dependency maps" [4]. This technique stemmed from a need for a convenient but moderately rigorous approach—with more detail and structure than a questionnaire could provide. A CJA dependency map uses features adapted from MITRE’s Risk-to-Mission Assessment Process (RiskMAP) [4]. As a result, this particular CJA methodology and RiskMAP are often taken as one and the same, but they are not. A more rigorous approach would involve Cyber Mission Impact Assessment (CMIA) [5], which uses a more detailed description of the user’s system.

The dependency map method uses facilitated discussions with system subject matter experts (SMEs) to assemble a model, from the top down, as shown in Figure 2 [6].

Figure 2. CJA Model Using Dependency Maps

These dependencies are qualitatively expressed in terms of "If <child> fails or is degraded (as defined by the SMEs), the impact on <parent> is <failure, degrade, work-around, nominal>." Provisions are included to minimize subjectivity. Once the model is complete, it is possible to predict the impact of a cyber asset failure/degradation as the realization of each IF...THEN statement, tracing the potential impact back "up" to key Tasks and Objectives, as shown in Figure 3.

Figure 3. Predicted Impact of Cyber Asset Failure

Government Interest and Use

Government interest in identifying, prioritizing, and protecting critical elements of the national infrastructure crosses all departments and stems from Homeland Security Presidential Directive 7 (HSPD-7) [7]. Preserving the government’s ability to perform essential missions and deliver essential services is among the key policy tenets in HSPD-7. These tenets were carried into the National Infrastructure Protection Plan (NIPP) developed by the Department of Homeland Security (DHS) [8]. The NIPP outlines a risk management strategy that allows for choices of risk management methodologies so long as they meet certain criteria. Among the core criteria for making consequence or impact assessments is "mission disruption." The special importance of mission disruption is clear in the NIPP, which states, "Mission disruption is an area of strong NIPP partner interest for collaborative development of the appropriate metrics to help quantify and compare different types of losses. While development is ongoing, qualitative descriptions of the consequences [of loss] are a sufficient goal" [8].

Within the DoD, the Defense Critical Infrastructure Protection (DCIP) Program called for in DoDD 3020.40 [9] and described in DoDI 3020.45 [10] requires a mission-based criticality assessment of assets supporting DoD missions. The nine-step Critical Asset Identification Process (CAIP) set forth in DoDM 3020.45 V1 [11] requires mission owners and asset owners to jointly determine what is mission critical, based on performance criteria for missions and mission-essential tasks. CJA provides a useful framework for conducting this analysis, using Information Assets as the link between Tasks and the Cyber Assets that support them. Following the CJA with a TSA to determine risks and a RRA to identify possible risk mitigations is consistent with the guidance in these DoD documents.

Best Practices and Lessons Learned

The overarching goal. The general goal of a CJA is to make the adversary’s job both more "difficult" (more costly and more time consuming—hence more "expensive") and more risky.

Timing is critical. Generally, the more enlightening insights come from using the dependency map methodology to evaluate system designs (and any alternatives or "design trades") after the system design starts to take shape. Some efforts have been made to perform a CJA early in an acquisition effort to identify mission-critical functions and mission-critical data. This can help identify information to protect at rest and in transit, where this information might be either a critical input or a computational "product" of the designed system.

Include all tasks needed to achieve the mission objectives. This means looking beyond those tasks that are on the critical path in a mission thread. What are the security-related tasks? What are the logistics-related tasks, or other support-related tasks? Excluding such tasks overlooks what must be done to ensure continued mission capability. An honest assessment of mission dependency on security-related and other supporting tasks will ensure that the components supporting those tasks receive due attention.

Remember the supporting actors. Cyber assets that perform mission-critical functions are not the only crown jewels in a system. Any system components that have unmediated access to crown jewels, or that provide protection for crown jewels, or that enable crown jewels to perform their critical functions must themselves be considered for crown jewel status. Identifying them requires an understanding of the system architecture and the overall system functions, and the analysis will not be complete unless this step is performed. The Defense Acquisition Guidebook provides additional guidance with a section devoted to Criticality Analysis for Program Protection [12].

The devil's in the details. System design details influence "criticality" in ways that developers—not operators—will more readily understand, so identifying key system accounts, critical files, and other critical assets will require technical insights from the development team (as depicted in the bottom two rows of Figures 2 and 3). Deciding which cyber assets are most important to "protect" (by close monitoring, using redundancy or other measures to more quickly restore these critical assets) is based on the insights provided by the dependency map "linkage" to the Tasks and Mission Objective. CJA can provide insight into which nodes to protect, where to apply intrusion detection, whether anti-tamper software and hardware are needed, and where and how to apply them.

Remember to factor in changing priorities. When circumstances require operators to "fight through" a cyber attack, other considerations will also shape the CJA—such as putting priority into maintaining scenario-specific, "minimum essential" functions, or allowing for secure reconstitution from a pristine, protected software image that can be quickly patched to a current state and loaded with the latest data.

A life-cycle view of CJA. Figure 4 illustrates where CJAs might be performed at different points along a System Life Cycle (SLC) and describes the purposes they would serve. A CJA can be initiated at Milestone B and updated throughout the program, but it could certainly be started at a later phase if this analysis was not performed sooner.

Figure 4. Alternate Timeframes for Performing CJA During a System Life Cycle

Needs and resources—The big drivers. The choice of CJA method depends on the needs and resources of the requesting organization. If an organization's mission is clearly defined, with a modest number of tasks to accomplish their broader mission objectives, their crown jewels may be readily apparent. In some cases, they will have defined specific use cases, or in user parlance, "mission threads." For organizations that support many mission objectives and/or have complex and overlapping mission dependencies on IT, it is useful to employ the dependency map techniques of CJA. Where an even more detailed examination is necessary—based on complex ripple effects from IT failures or temporal effects during overlapping operations—a CMIA [13] approach offers the necessary capabilities to address these challenges.

MITRE intends to maintain a website that is fully accessible to all individuals. If you are unable to search or apply for jobs and would like to request a reasonable accommodation for any part of MITRE’s employment process, please contact MITRE’s Recruiting Help Line at 703-983-8226 or email at recruitinghelp@mitre.org