*2.2.2. Mission/business process tier*

Tier 2 is where the mission/business processes necessary to implement the strategic goals and objectives established at Tier 1 are defined and prioritized [17]. This is also where the types of information required, the information sensitivity, and information flows necessary to support the Tier 1 goals and objectives is determined [17]. The IT enterprise architecture is defined and established at this tier, to include the implementation of the common controls identified in Tier 1. The decisions and activities at this tier have a direct effect on the activities undertaken at Tier 3.

#### *2.2.3. Information systems tier*

Tier 3 is where the information systems that support the organization reside. The decisions and prioritizations established in Tiers 1 and 2 are implemented in information systems at this tier. The activities required for each of the steps in the Risk Management Framework

<sup>6</sup> Common controls are security controls implemented in a way that they are available to information systems across the organization. Common controls can be "inherited" by a system, meaning that the system itself does not need to implement the control the system can leverage/use the control as implemented by the organization.

<sup>7</sup> The Risk Executive (Function) is an individual or office responsible for considering risk across the organization, to include mission, business, and security risks, balancing them appropriately for the organization, and making recommendations to decision-makers within the organization based on their risk determinations.

(RMF)8 and the system development life cycle 9 are performed here, to ensure each information system meets its technical, mission, and security requirements. In this tier, "information system owners, common control providers, system and security engineers, and information system security officers make risk-based decisions regarding the implementation, operation, and monitoring of organizational information systems" [17].

### **2.3. Risk management process**

The risk management process is comprised of a number of discrete steps. These steps take place at different times within the process, and possibly at multiple times in the process due the iterative nature of risk management activities. It is important that all of the steps are completed for a risk management program to be fully effective. These steps apply to risk management activities taking place at each tier within the organization, so this process is equally applicable to risk management activities taking place at Tier 1 as it is at Tier 2 or 3.

NIST describes four distinct steps in the risk management process. These steps are:

1. Risk Framing

210 Risk Management – Current Issues and Challenges

Other activities occurring at Tier 1 include:

*2.2.2. Mission/business process tier* 

activities undertaken at Tier 3.

*2.2.3. Information systems tier* 

Determination of organization-wide common controls6; and

accepting risks in one area or system on other systems or the organization.

located within the organization at this level [17].

At the organization tier, risk to the entire organization is considered and managed. Part of the responsibility for managing risk throughout the organization is the process of "risk framing", establishing the context within which all organizational risk management activities will be conducted [17]. Risk framing establishes the governance framework from which are derived the risk management activities and the risk tolerance of the organization.

Establishment and prioritization of activities and programs at the Mission/Business

The Risk Executive (Function)7 recommended by the NIST is established in and is

The Risk Executive (Function) (REF) is an individual or group within the organization that serves in an advisory role to organizational decision makers at all 3-tiers. The REF does not make decisions for the organization; rather it informs decision makers about the risks to the system, network, and the organization that may result from a particular risk decision. The REF considers risk from a holistic perspective, considering mission and business risks, in addition to security risks. This risk consideration is done with an organization-wide perspective, allowing the REF's recommendations to evaluate the potential impact of

Tier 2 is where the mission/business processes necessary to implement the strategic goals and objectives established at Tier 1 are defined and prioritized [17]. This is also where the types of information required, the information sensitivity, and information flows necessary to support the Tier 1 goals and objectives is determined [17]. The IT enterprise architecture is defined and established at this tier, to include the implementation of the common controls identified in Tier 1. The decisions and activities at this tier have a direct effect on the

Tier 3 is where the information systems that support the organization reside. The decisions and prioritizations established in Tiers 1 and 2 are implemented in information systems at this tier. The activities required for each of the steps in the Risk Management Framework

6 Common controls are security controls implemented in a way that they are available to information systems across the organization. Common controls can be "inherited" by a system, meaning that the system itself does not need to

7 The Risk Executive (Function) is an individual or office responsible for considering risk across the organization, to include mission, business, and security risks, balancing them appropriately for the organization, and making

implement the control the system can leverage/use the control as implemented by the organization.

recommendations to decision-makers within the organization based on their risk determinations.

*2.2.1. Organization tier* 

Tier;


### *2.3.1. Risk framing*

Risk framing is a governance activity that is performed at Tier 1. Its principal output is a risk management strategy "that addresses how organizations intend to assess risk, respond to risk, and monitor risk" [17]. The risk management strategy is created as a joint effort between an organization's senior management and/or executives in conjunction with the risk executive (function) [17]. The risk management strategy explicitly states the assumptions, constraints, risk tolerances, and priorities or trade-offs used in making investment and operational decisions for the organization [17]. It also details what types of risk responses are supported, how risk is assessed, and how risk is monitored for the organization [17].

#### *2.3.2. Risk assessment*

Risk assessment is the process of:


<sup>8</sup> The RMF is described in detail in NIST Special Publication (SP) 800-37, available from: http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

<sup>9</sup> The system development life cycle established by the NIST is described in NIST SP 800-64, *Security Considerations in the System Development Life Cycle*, Oct. 2008 [23].

3. Prioritizing the identified risks according to their severity to the organization [3, 17].

IA OM®

reassessment of the risk posture of an organizational asset, activity, or operation earlier than

These risk monitoring activities can be implemented at any tier in the organization [17]. The objectives and process for each tier will differ according to their respective needs, and, particularly at Tiers 1 and 2, are likely to involve cross-tier monitoring – as the upper tiers are directly affected by operational or process-level changes to the organization's risk posture at the lower levels [17]. An example of cross-tier monitoring would involve the monitoring of the risk posture of an information system authorized to operate within an organization. The organizational official responsible for the authorization decision will want to monitor the risk posture of the information system to ensure it continues to operate within an acceptable level of risk, and that any changes to the risk posture of the system or

The metrics or results derived from the IA OM® methodology are meaningful to the organization because the measurements themselves are "tied directly to questions that are important to the organization"[21] . The results are also useful to organizational management since they indicate the degree to which specific information security risk management goals are being met as action is taken to improve an organization's overall information security posture in terms of its information security objectives [1]. In this instance IA OM® can be conceptually expressed as providing a measure of the degree to which the organization's information security risk management objectives are being met [1]. The creators of the OM® methodology, Donaldson and Siegel [21, 22], have 20+ years of professional software engineering experience at Science Applications International Corporation (SAIC) and in the Department of Defense (DoD). The OM® methodology enables one "to measure software products and software systems development processes in everyday terms familiar and – therefore meaningful – to your organization" [21]. The OM® methodology measures software products and software systems development processes as part of a continual process improvement exercise. The OM® framework derives its effectiveness as a "management process" tool in that the OM® Index, akin to the Consumer Price Index, folds in a number of individual measurements into a single overall value [1, 22]. The OM® Index can also be deconstructed to gain insight into the elements comprising the index value. By looking at trends in the index values, it is possible to determine the effect or

The OM® quantifies software *product* "goodness" and software *process* "goodness", where an object (i.e., an attribute, component, or activity) is measured through its characteristics. "For products, these characteristics are called attributes; for processes, these characteristics are called components and activities" [22]. Software product "goodness" is the degree to which the product satisfies the customer and meets the customer's requirements. Software process "goodness" is a measure of the product creation process' ability to consistently and reliably

normally scheduled [3].

**3. IA OM®** 

its environment are properly evaluated and addressed.

outcome of changes within the organization.

create good quality products within budget [1].

as an Enterprise Risk Management Metric 213

Risk assessments can and should be conducted at every Tier of the organization. However, the objectives of risk assessments conducted at different Tiers will reflect the differences in responsibility and objectives for the Tier being assessed [17]. For example, a risk assessment at Tier 3, the Information Systems Tier, will go into considerable technical detail on a specific information system and the risks involved in its operation. Whereas a risk assessment at Tier 1, the Organization Tier, may address information systems from the perspective of the organization's enterprise architecture or common control framework, but will not go into significant technical detail, nor will it address a specific information system. However, a Tier 1 risk assessment will address business risks, and the risks involved in investing in particular missions or business areas.

### *2.3.3. Risk response*

Responding to risk involves deciding on and implementing a course of action to address the risk within the organization. The options available to the organization for risk response are defined in the organization's risk management strategy. The courses of action available to address risk as identified in NIST SP 800-39 [17] are:


#### *2.3.4. Risk monitoring*

Risk monitoring is conducted on an ongoing basis to ensure that the organization's risk posture remains within the organization's risk tolerance. The risk monitoring process allows an organization to:


Risk monitoring activities are normally conducted on a periodic basis, with the period determined in accordance with the organization's risk management strategy and the sensitivity of the information or business process being protected [16, 17]. Monitoring risk and changes to operating environments includes identifying changes to the threat environment, and determining whether a change in the threat environment requires a reassessment of the risk posture of an organizational asset, activity, or operation earlier than normally scheduled [3].

These risk monitoring activities can be implemented at any tier in the organization [17]. The objectives and process for each tier will differ according to their respective needs, and, particularly at Tiers 1 and 2, are likely to involve cross-tier monitoring – as the upper tiers are directly affected by operational or process-level changes to the organization's risk posture at the lower levels [17]. An example of cross-tier monitoring would involve the monitoring of the risk posture of an information system authorized to operate within an organization. The organizational official responsible for the authorization decision will want to monitor the risk posture of the information system to ensure it continues to operate within an acceptable level of risk, and that any changes to the risk posture of the system or its environment are properly evaluated and addressed.
