Analyze and quantify the risks to systems and information.

UCF ID: 00701

Control Type: Process or Activity

Status: Live

Supporting and supported controls

This control directly supports:

Establish and maintain the IT Governance risk assessment framework. [UCF Control ID 00685]

This control has the following supporting controls:

Maintain a risk measurement and scoring system. [UCF Control ID 00703]

Establish a risk acceptance level appropriate for the organization's risk appetite. [UCF Control ID 00706]

Perform a gap analysis to review existing controls for identified risks and implement new controls. [UCF Control ID 00704]

Authority documents complied with:

COSO Enterprise Risk Management (ERM) Integrated Framework (2004), Pg 48, Pg 49; PCAOB Auditing Standard No. 5, ¶ 29; FFIEC Guidance on Authentication in an Internet Banking Environment, Pg 4; FFIEC IT Examination Handbook – Business Continuity Planning, March 2008, Pg F-2; FFIEC IT Examination Handbook – Information Security, Exam Tier I Obj 3.1; FFIEC IT Examination Handbook – Operations, July 2004, Pg 14; FFIEC IT Examination Handbook – Outsourcing Technology Services, June 2004, Exam Tier I Obj 4.2; FFIEC IT Examination Handbook – Supervision of Technology Service Providers, March 2003, Pg 5; Health Insurance Portability and Accountability Act of 1996 (HIPAA), § 164.308(a)(1)(ii)(A); Army Regulation 380-19: Information Systems Security, February 27, 1998, § 5-3.d; FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006, § 3; Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996, § 3.3.1; Recommended Security Controls for Federal Information Systems, NIST SP 800-53, Revision 3, App F § RA-3, App G § PM-1, App G § PM-8, App G § PM-9; Guide for Assessing the Security Controls in Federal Information Systems, NIST SP 800-53A, July 2008, RA-3; Business Continuity Institute (BCI) Good Practice Guidelines, 2005, Stage 1.3 Process; CobiT, Version 4.1, PO9.4; The Standard of Good Practice for Information Security, SM3.4.4, CB5.3.3, CI5.4.4, NW4.4.4, SD3.5.4; OGC ITIL: Security Management, § 2.2.4; Australian Government ICT Security Manual (ACSI 33), § 2.4.22, § 2.4.24; Australia Better Practice Guide - Business Continuity Management, January 2000, Pg 21, Pg 22; BIS Sound Practices for the Management and Supervision of Operational Risk, ¶ 25; Organizational Resilience: Security, Preparedness, and Continuity Management Systems -- Requirements with Guidance for Use, ASIS SPC.1-2009, § 4.3.1 ¶ 1(e); Disaster / Emergency Management and Business Continuity, NFPA 1600, 2007 Edition, § 5.4.3; Defense Industrial Base Information Assurance Standard, § 3.2.1, § 3.2.2; ISO/IEC 13335-5 Information technology — Guidelines for the management of IT Security — Part 5: Management guidance on network security, 2001, ¶ 12

Sarbanes Oxley Guidance

Potential risk events should be evaluated by determining the likelihood an event will occur and the effect the event could have on the organization. Management should determine how much attention should be given to assessing the risks. The analysis should be completed carefully using rational reasoning. If past data is used to help determine the likelihood of an event occurring, the organization should use caution, because influencing factors change over time. [Pg 48, Pg 49, COSO Enterprise Risk Management (ERM) Integrated Framework (2004)]

The qualitative and quantitative risk factors related to the financial statements should be evaluated. These risk factors include the size of the account; the susceptibility of the account to misstatements due to errors or fraud; the volume of activity; the accounting and reporting complexities; the nature of the account; the possibility of contingent liabilities; and changes from the previous period in account characteristics. [¶ 29, PCAOB Auditing Standard No. 5]

Banking and Finance Guidance

The organization should identify and assess the techniques used to minimize the risks for each transaction type and level of access. [Pg 4, FFIEC Guidance on Authentication in an Internet Banking Environment]

A loss impact analysis should be performed to quantify the findings of the vulnerability assessment. [Pg F-2, FFIEC IT Examination Handbook – Business Continuity Planning, March 2008]

[Exam Tier I Obj 3.1, FFIEC IT Examination Handbook – Information Security]

The organization should quantify all risks based on factors such as loss of revenue, data recovery expense, legal expense, and loss of market share. [Pg 14, FFIEC IT Examination Handbook – Operations, July 2004]

[Exam Tier I Obj 4.2, FFIEC IT Examination Handbook – Outsourcing Technology Services, June 2004]

When examining the quantity of risks, the examiners should evaluate the financial condition of the service provider; the number of clients the service provider is working with; the volume of transactions processed; the number and type of products the service provider provides; the reliability of the technology the service provider uses; and how adequate its business continuity planning is. [Pg 5, FFIEC IT Examination Handbook – Supervision of Technology Service Providers, March 2003]

The organization should quantify its exposure to risk to help in assessing the risk exposure and developing a plan to control the risks. [¶ 25, BIS Sound Practices for the Management and Supervision of Operational Risk]

Healthcare and Life Science Guidance

Risk analysis is required. An accurate and thorough assessment of all possible risks and vulnerabilities that may affect stored health information should be conducted. [§ 164.308(a)(1)(ii)(A), Health Insurance Portability and Accountability Act of 1996 (HIPAA)]

US Federal Security Guidance

Management should determine the relative risks to the organization. This is best determined when specific vulnerabilities are matched to known threats. [§ 5-3.d, Army Regulation 380-19: Information Systems Security, February 27, 1998]

Calls for Risk Assessment (RA): Organizations must periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational information systems and the associated processing, storage, or transmission of organizational information. [§ 3, FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006]

§ 3.2.1 If a DIB facility meets any of the following criteria, they are considered important: • are a sole source; • use obsolete enabling/emerging technology; • require a long lead time; • lack surge production; and • have a significant unit cost escalation. § 3.2.2 The following representative questions may be used tog guide the screening criteria on the impact to human, economic, and public confidence: • Would destruction of the facility result in significant loss of life at or near the facility? • Does the facility contain specialized material or equipment that could cause a public health incident? • Would destruction or impairment of the facility cause significant reduction in the gross domestic product? • Does the facility house material necessary to maintain national economic stability? [§ 3.2.1, § 3.2.2, Defense Industrial Base Information Assurance Standard]

NIST Guidance

Risk analysis is composed of a few sections:
• Determine the Assessment’s Scope and Methodology
• Collecting and Analyzing Data
• Interpreting Risk Assessment Results
Determining the assessment’s scope and methodology includes identifying the system under consideration, the part of the system that will be analyzed, and the analytical method including its level of detail and formality.
Collecting and analyzing data involves examining the multiple components of risk to see which are most pertinent. Components include asset valuation, consequence assessment, threat identification, safeguard analysis, vulnerability analysis and likelihood assessment.
Interpreting risk assessment results involves reviewing the results of assessment to determine what risks are of most concern to the organization. [§ 3.3.1, Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996]

App F § RA-3 The organization must establish and maintain risk assessment policies and procedures that includes assessment of operational, environmental, and business risk; documents results in organizational report; periodically reviews assessment; and responds to changes in risk.
App G § PM-1 The organization must establish and maintain information security plan policies and procedures that develops and disseminates and organization wide security program plan that provides an overview and description of the security program management controls and common controls in place or planned; clearly explains implementation of the plan and risks associated; establishes roles, management commitment and compliance; is approved by senior management; reviews the plan on a predefined schedule; and revises the plan to address organization changes, problems identified, or security control assessments.
App G § PM-8 The organization must develop, document, and update a critical infrastructure and key resources protection plan.
App G § PM-9 The organization must develop, document, and implement a risk management strategy for operations, assets, individuals, or other organizations associated with the operation and use of information systems; and consistently implement across the organization. [App F § RA-3, App G § PM-1, App G § PM-8, App G § PM-9, Recommended Security Controls for Federal Information Systems, NIST SP 800-53, Revision 3]

Organizational records and documents should be examined to ensure assessments are made of the risks and potential magnitude of harm that can result from unauthorized access, disclosure, modification, disruption, or destruction of information; risk assessments are performed in accordance with NIST Special Publications 800-30 and 800-95; and specific responsibilities and actions are defined for the implementation of the risk assessment control. Any problems discovered during the implementation of the risk assessment control should be documented and used to improve the controls.
Interviews should be conducted with personnel involved in performing risk assessments and analyzing the amount of harm that could occur to the system. [RA-3, Guide for Assessing the Security Controls in Federal Information Systems, NIST SP 800-53A, July 2008]

ISO Guidance

Determine the Types of Security Risk. The majority of organizations today are dependent on the use of IT systems and networks to support their business operations. Further, in many cases there is a definite business requirement for the use of network connections between the IT systems at each organization's location, and to other locations both within and outside the organization. When a connection is made to another network, considerable care should be taken to ensure that the connecting organization is not exposed to additional risks. These risks could, for example, result from the connection itself or from network connections at the other end.
Whilst network connections are important for business reasons, it has to be recognized that the use of these connections could yield additional security risks - some possibly related to ensuring adherence to relevant legislation and regulation. The types of risk reflected in this clause relate to concerns about unauthorized access to information, unauthorized sending of information, the introduction of malicious code, denial of receipt or origin, and denial of service connection. Thus the types of security risk that an organization might face relate to loss of:
• confidentiality of information,
• integrity of information,
• availability of information and service,
• non-repudiation of commitments,
• accountability of transactions,
• authenticity of information,
• reliability of information.
Not all of the possible types of security risk will apply to every location, or to every organization. However, the relevant types of security risk need to be identified so that potential safeguards areas can be identified (and eventually safeguards selected, designed, implemented and maintained). Information should be gathered on the implications to business operations related to the types of security risk referred to above (desirably from the results of a security risk analysis and management review 1), with due consideration of the sensitivity or value of information involved (expressed as potential adverse business impacts) and related potential threats and vulnerabilities. Related to this, if there is likely to be more than a minor adverse impact on the business operations of the organization, then reference should be made to the matrix in Table 5 below.
It is emphasized that in completing this task, use should be made of the results from security risk analysis and management review(s) conducted with regard to the network connection(s). These results will enable a focus, to whatever level of detail the review(s) have been conducted, on the potential adverse business impacts associated with the types of security risk listed above, as well as the threat types, vulnerabilities and hence risks of concern.
The relevant trust relationship references determined from using clause 11 above should be identified along the top of the matrix in Table 5, and the impacts of concern on the left hand side of the matrix. The references at the pertinent intersections should then be noted – these are the references to the potential safeguard areas that are introduced in clause 13 below.
It should be noted that the table appears to indicate that the more a user is trusted, the more safeguards are necessary. There are two reasons for this.
Firstly, there are a number of safeguards described in Part 4 of TR 13335 (and thus not repeated in this TR) that would be selected to protect the host IT facilities, including for identification and authentication, and logical access control. The configuration of the permissions (privileges) in the lower trust situations needs to ensure that access is only provided to resources that are consistent with the trust model and needs of the intended access. In low trust situations the strength of identification and authentication, and logical access control, safeguards (as described in Part 4 of TR 13335), needs to be higher than in high trust situations. If this cannot be assured, then relevant additional safeguards would need to be implemented.
Secondly, trusted users are usually given access to more important/critical information and/or functionality. This can mean a need for additional safeguards, as a reflection of the value of the resources accessed and not on the trust in the users. [¶ 12, ISO/IEC 13335-5 Information technology — Guidelines for the management of IT Security — Part 5: Management guidance on network security, 2001]

ITIL Guidance

Conducting a risk analysis is called for to best determine how to spend money and resources defending the organization against potential risks. [§ 2.2.4, OGC ITIL: Security Management]

General Guidance

Initially a system for quantitatively scoring risk should be created and agreed upon. Next threats to critical business processes should be listed. This can be done by drawing from the BIA. For each risk listed, estimate the impact on the organization using a numerical scoring system. The likelihood of each risk occurring should also be assessed. Taking the scores for each, calculate the risk and prioritize them according to a formula which includes a measure of the ability to control that threat. When this work is complete it should be approved and signed-off on by the organization’s sponsor. For each risk listed, management should determine whether to transfer the risk through insurance, accept the risk if it is low enough impact, reduce the risk by adding more controls or avoid the risk by removing the cause or source of the threat. If any controls are to be added, ensure they do not increase other risks. [Stage 1.3 Process, Business Continuity Institute (BCI) Good Practice Guidelines, 2005]

The organization should assess on a recurrent basis the likelihood and impact of all identified risks, using qualitative and quantitative methods. The likelihood and impact associated with inherent and residual risk should be determined individually, by category and on a portfolio basis. [PO9.4, CobiT, Version 4.1]

The risk analyses should determine the risks to the system and network by analyzing the vulnerabilities and threats. Risk analyses also should be completed on systems under development. [SM3.4.4, CB5.3.3, CI5.4.4, NW4.4.4, SD3.5.4, The Standard of Good Practice for Information Security]

A formal and documented evaluation process must be established, implemented, and maintained by the organization to determine risks that will have significant impact on functions, products, services, activities, stakeholder relationships, and the environment. [§ 4.3.1 ¶ 1(e), Organizational Resilience: Security, Preparedness, and Continuity Management Systems -- Requirements with Guidance for Use, ASIS SPC.1-2009]

The organization must have a system implemented that monitors the identified hazards and adjusts the level of preventative measures to that commensurate with the risks. [§ 5.4.3, Disaster / Emergency Management and Business Continuity, NFPA 1600, 2007 Edition]

Asia and Pacific Rim Guidance

The identified risks should be analyzed to separate the acceptable risks from the unacceptable risks; to determine the consequences of each risk; to determine the likelihood of each risk and the source; and to determine the overall level of risk. [§ 2.4.22, § 2.4.24, Australian Government ICT Security Manual (ACSI 33)]

The objective of risk analysis is to separate risks identified in the previous step into minor and major risks. To do this, an organization needs to compare each list to predetermined criteria of acceptability. For each risk, define a maximum acceptable outage-- the length of time a device or process is allowed to be out of service. [Pg 21, Pg 22, Australia Better Practice Guide - Business Continuity Management, January 2000]

Metrics

The metrics associated with this control are as follows:

Report on the percentage of critical assets and functions for which the cost of compromise (loss, damage, disclosure, disruption in access to) has been quantified. [UCF Control ID 02041]