1ECG - Assessing Operational Risk

Risk Management Framework (RMF) Demystifying the Risk Management Framework (Assessing Operational Risk) Organized by: Matthew Metheny, PMP, CISSP, CISA, CAP, CSSLP One Enterprise Consulting Group, LLC

Management of Risks - NIST SP 800-39 A relationship must exist between the organizations strategic view of risk and the more tactical view as it relates to the day-to-day operational aspects of an information system. 2

What is Risk? Definition: A measure of the extent to which an entity is threatened by a potential circumstance or event, and a function of: (i) the adverse impacts that would arrive if the circumstance or event occurs; and (ii) the likelihood of occurrence. What is the role of Risk Management? • The management of risks is an organization-wide activity that requires the organization to understand their responsibilities in managing risk from operating information systems that support the mission/business functions of the organization, and take responsibility for risk consequences and mitigation What is the role of the Risk Management Framework? • Changes the traditional focus on C&A as a static, procedural activity to a more dynamic approach where enterprise missions and business processes drive security requirements and associated safeguards and countermeasures for organizational information systems 3

Risk Management Activities within the RMF Step 1: Define Step 4: Determine Risk is continually assessed and communicated to criticality/sensitivity of security control information system stakeholders effectiveness according to potential (implemented correctly, worst-case, adverse operating as intended, impact to meeting security mission/business requirements for information system) Step 2: Select baseline security Step 5: Determine risk to controls; organizational operations, apply tailoring assets, individuals, other guidance and organizations, and the supplement controls Nation; if acceptable, as needed C authorize to operate based on risk assessment Step 6: Continuously track changes to C C information system that Step 3: Implement security controls may affect security within enterprise controls and reassess architecture using control effectiveness sound systems C C engineering practices; apply security configuration settings 4

What is Risk Acceptance? • The degree of risk that an organization is willing to accept • Who has the responsibility for accepting risk? – Authorizing Officials are responsible for making the final decision of whether or not to authorize a system to operate • What is the Authorizing Official’s role in determining risk acceptability? – Acceptable - Issues an authorization to operate (ATO) for a specified period of time – Unacceptable - Does not issue an ATO or halts activity on an information system currently in operation 5

Localized vs. Holistic Organizational Risk Management Future Risk Management Function Current Risk Management Function • Risk is primarily managed through individual information systems and authorization decisions • Authorization decision are made without always considering the complex relationships among the organization’s mission/business processes • Authorizing Officials may render authorization decisions without fully understanding or explicitly accepting the risk • Many organization lack of a comprehensive and holistic approach for addressing risk which inhibits the organization from have the visibility into and understanding of the integrated operations/business flows of the organization NOTE: While authorizing officials are by definition, senior leaders within the organization with mission, business, operational, and budgetary responsibilities, it is possible or likely that their authorization decisions may affect, either directly or indirectly, other parts of the organization. 6

What is the Role of the Risk Executive Function? • Provides senior leadership input and oversight for all risk management and information security activities across the organization • Ensures authorization decisions by authorizing officials consider all factors necessary for mission and business success organization-wide • Provides an organization-wide forum to consider all sources of risk (including aggregated risk from individual information systems) to organizational operations and assets, individuals, other organizations, and the Nation • Ensures that information security considerations are integrated into enterprise architectures, programming/planning/budgeting cycles, and acquisition/system development life cycles • Promotes cooperation and collaboration among authorizing officials to include authorization actions requiring shared responsibility; • Identifies the overall risk posture based on the aggregated risk from each of the information systems and supporting infrastructures • Ensures that information security activities (including the identification of deficiencies and gaps) are coordinated with appropriate organizational entities • Ensures that the shared responsibility for supporting organizational mission/business functions using external providers of information and services receives the needed visibility and is elevated to the appropriate decision- making authorities • Facilitates the sharing of security-related and risk-related information among authorizing officials and other senior leaders within the organization to help these officials consider all types of risks that may affect mission and business success and the overall interests of the organization at large • Ensures that the shared responsibility for supporting organizational mission/business processes using external providers receives the needed visibility and is elevated to the appropriate decision-making authorities 7

Risk Management Overview • Risk management helps organizations select the most appropriate controls • The quality of the output of the risk management processes depends on the quality of the input to the risk management processes and the type of analytical methodology used • Includes two components: – Risk Assessment – Risk Mitigation 8

What is a Risk Assessment? • The process of analyzing and interpreting risk, is comprised of three basic activities: (1) determining the assessment's scope and methodology (2) collecting and analyzing data (3) interpreting the risk analysis results • Risk assessment often produces an important side benefit – “in-depth” knowledge about a system and an organization as risk analysts try to figure out how systems and functions are interrelated • A risk assessment can focus on many different areas such as: technical and operational controls to be designed into a new application, the use of telecommunications, a data center, or an entire organization. 9

Determining Scope and Methodology • The first step in assessing risk is to identify the system under consideration, the part(s) of the system that will be analyzed, and the analytical method including its level of detail and formality • The boundary, scope, and methodology definition will have major consequences: (i) the total amount of effort spent on risk management (ii) the type and usefulness of the assessment's results Potential factors that influence the scope include but not limited to: • phase of the life cycle a system is in • the relative importance of the system under examination • magnitude and types of changes the system has undergone • addition of new interfaces 10

Collecting and Analyzing Data Risk has many different components: • Assets • Threats • Vulnerabilities • Safeguards • Consequences • Likelihood The examination of these component normally includes gathering data about the threatened area and synthesizing and analyzing the information to make it useful. 11

Interpreting Risk Analysis Results • Risk assessment support two related functions: acceptance of risk and the selection of cost-effective controls • Risk assessments must produce a meaningful output that reflects what is truly important to the organization to be effective • Limiting the risk interpretation activity to the most significant risks is another way that the risk management process can be focused to reduce the overall effort while still yielding useful results • If risks are interpreted consistently across an organization, the results can be used to prioritize systems to be secured 12

Risk Analysis Results • Risk analysis results are typically represented quantitatively and/or qualitatively • Quantitative measures may be expressed in terms of reduced expected monetary losses, such as annualized loss expectancies or single occurrences of loss • Qualitative measures are descriptive, expressed in terms such as high, medium, or low, or rankings on a scale of 1 to 10 13

Risk Mitigation • Represents the second part of Risk Management • Involves prioritizing, evaluating, and implementing the appropriate risk-reducing controls recommended from the risk assessment process – Feeds into the requirements that are planned into the information system and documented in the Security Plan and Plan of Action and Milestones • It is the responsibility of senior management and functional and business managers to use the least-cost approach and implement the most appropriate controls to decrease mission risk to an acceptable level, with minimal adverse impact on the organization’s resources and mission 14

Risk Response Options • Accept risk • Operational risk reduction or mitigation via management and operational security control and/or compensating controls • Technical risk reduction or mitigation through corrective action and/or compensating technical controls • Contractual risk transfer (outsource) • Transfer of risk to a 3rd party (e.g., insurance) • Reject risk (without pursuing mitigation) NOTE: Not all options are available at all times 15

Residual Risk Definition: The potential for the occurrence of an adverse event after adjusting for the impact of all in-place safeguards What role does “residual risk” plays in the Risk Management process? • Provides information into the extent of the risk reduction generated by the new or enhanced controls in terms of the reduced threat likelihood or impact • Assists Authorizing Officials in determining the acceptability of operating the information system given the kind of severity of remaining risks 16

NIST SP 800-30, Rev. 1 Status: Being updated in 2010 with an anticipated revision date of December 2010. • Current publication (NIST SP 800-30) will be down-scoped from a risk management focus to risk assessment focus • Guidance will address conducting risk assessments at each step in the Risk Management Framework • Incorporates threat information for cyber preparedness Gap = Lack of a mature Risk Assessment Methodology (NIST SP 800-30) (NIST SP 800-30, Rev. 1) Current Threat: Guidance Gaps Future Outcome: Increased Security Costs 17

Solution = Training 18

Linking Risk Management Approach to the SDLC Organizations use risk assessments to determine the extent of the potential threat and the risk associated with an IT system throughout its SDLC The need for an IT system is expressed and the Identified risks are used to support the development of the Phase 1 - Initiation purpose and scope of the IT system is documented system requirements, including security requirements, and a security concept of operations (strategy) The IT system is designed, purchased, The risks identified during this phase can be used to support the Phase 2 - Development/ programmed, developed, or otherwise constructed security analyses of the IT system that may lead to architecture Acquisition and design tradeoffs during system development The system security features should be configured, The risk management process supports the assessment of the enabled, tested, and verified system implementation against its requirements and within its Phase 3 - Implementation/ modeled operational environment. Decisions Assessment regarding risks identified must be made prior to system operation The system performs its functions. Typically the Risk management activities are performed for periodic system system is being modified on an ongoing reauthorization (or reaccreditation) or whenever major changes Phase 4 - Operation/ basis through the addition of hardware and are made to an IT system in its operational, Maintenance software and by changes to organizational production environment (e.g., new system interfaces) processes, policies, and procedures This phase may involve the disposition of Risk management activities are performed for system information, hardware, and software. components that will be disposed of or replaced to Phase 5 - Disposal Activities may include moving, archiving, ensure that the hardware and software are properly disposed discarding, or destroying information and sanitizing of, that residual data is appropriately handled, and that system the hardware and software migration is conducted in a secure and systematic manner 19

NIST 800-30 Risk Assessment Methodology Step 1: System Characterization Step 2: Threat Identification Step 3: Vulnerability Identification Step 4: Control Analysis Step 5: Likelihood Determination Step 6: Impact Analysis Parallel Activities (Optional) Step 7: Risk Determination Step 8: Control Recommendations Step 9: Results Documentation NOTE: Steps 2, 3, 4, and 6 can be conducted in parallel after Step 1 has been completed 20

Step 1: System Characterization • Define scope of the effort by characterizing the information system (or subsystem components) and operational environment: – Boundary of the information (or subsystem components) – Decomposition to understand hardware and software system components – Other information that would be required to support the assessment of risk (e.g., supporting mission/business processes, interfaces, system and data criticality and sensitivity, functional and non-functional requirements, user community, network topology, etc.) NOTE: For new development and legacy systems without necessary supporting artifacts in-place, additional information may be developed as a by-product of executing the RMF 21

Step 1: System Characterization • Mechanisms that can be used to gather pertinent information to support the Risk Assessment activities include, but not limited to: – Questionnaires – On-site Interviews (on-site visits are important to allow the risk assessment personnel to observe and gather information about the operational and technical security control in-place) – Document Reviews – Automated Scanning Tools NOTE: The above list is not conclusive and was based on those identified in NIST SP 800-30 22

Attack Tree Methodology “Attack trees provide a formal, methodical way of describing the security of systems, based on varying attacks. Basically, you represent attacks against a system in a tree structure, with the goal as the root node and different ways of achieving that goal as leaf nodes.” (Concept Introduced by Bruce Schneier in1999) Goal: Attempt to understand who the attackers (including their abilities, motivations, and capabilities) and all the ways an information system can be attacked through a systematic categorization Advantages (Not comprehensive): • Can be applied to more than a computer system, software application, or network • Enables vulnerabilities to be viewed from an operational settings (emphasis is placed on operational/business consequences) • Allows organization’s to fully appreciate the complexity and practicality of a breach in security (prioritize low-cost remediations to mitigate non-consequential security violations) • Reusable attack scenarios that provide more comprehensive “what-if” impact analyses to proposed changes to systems Disadvantages (Not comprehensive): • Holistic approach that requires more analysis (and time to approach each system as a systematic evaluation of all potential threats and vulnerabilities) • Requires maintenance of attack scenarios to ensure changes are incorporated that change the underlying tree structure 23

Attack Tree Methodology What are they? • Method for analyzing which assets (e.g., hardware, software, data, and information, etc.) to consider (mission/business value and associated impact) and which risks exist that are relevant to the organization(*) How are they created? • Start with the identification of the attackers goal (root node) or the target of the attacker • Each supporting goal (although a potential target by itself) that can be used to achieve the ultimate goal would become a attackers sub-goal (leaf node) • Some attacks may require different objectives to be completed (although represented as sub-goals) to achieve the ultimate goal which requires the addition of notations (or conjunctions) to represent the relationship between parent and child nodes, or peer nodes – Most commonly used conjunctions include: AND and OR * Analysis is supported by the characterization (Step 1) of the information system and the operational environment 24

Creating Attack Trees • The construction of an attack tree starts with the Goal 1 root node which branches off to leaf events Unauthorized access to firewall • As threats and vulnerabilities are identified, consideration is given to how the threat-source with the associated motivation/capabilities can exploit the vulnerability to reach sub-goals and the ultimate goal of the attacker Example: Goal 1: Obtain unauthorized access to the firewall Sub-goal 1.1 Sub-goal 1.2 1.1 Exercise a vulnerability on the firewall; OR Firewall vulnerability is Firewall passwords are 1.2 Compromise the firewall password exercised compromised 1.2.1 Gain access to the corporate network; AND 1.2.2 Steal unencrypted passwords from the system administrators workstation NOTE: Each goal requires a separate tree (although sub-trees or sub-nodes may link separate trees depending on the Sub-goal 1.2.1 Sub-goal 1.2.2 complexity of the analysis) Corporate network is Passwords are stolen from an unencrypted compromised file 25

Step 2: Threat Identification What are threats? • The potential for a threat-source to exercise a particular vulnerability What are threat-sources? • Intent or method targeted at an intentional exploitation of a vulnerability; or • Situation and method that may accidently trigger a vulnerability What are vulnerabilities? • Weaknesses that can be accidently triggered or intentionally exploited What is the goal of threat identification? • Identify the potential threat-sources and compile a threat statement (lists potential threat-sources which are applicable and will be evaluated) NOTE: Prior to determining the likelihood (Step 5), a determination of the threat-source (Step 2), vulnerability (Step 3) and existing controls (Step 4) 26

Step 3: Vulnerability Identification (Observations) What is the goal of vulnerability identification? • Develop a list of system vulnerabilities (flaws or weaknesses) that could be exploited by the potential threat-source identified in Step 2 What are good sources for vulnerability identification (technical and no-technical)? • Organizational policies and procedures • Analysis of security controls in-place (development or operational security testing or penetration testing) • National Vulnerability Database (or vendor-specific databases) • Prior Risk Assessments (or Risks Assessments from other information system where the information system resides) • OIG, GAO, or other Audit Reports • Vulnerability scan results (analysis will likely be required to isolate “false positives” and “non-consequential” vulnerabilities) • System-Specific Security Requirements (e.g., NIST SP 800-53) 27

Step 4: Controls Analysis What is the goal of controls analysis? • Analyze the controls that have been implemented (or planned to be implemented to minimize or eliminate the likelihood (probability) of a threat exercises a specific vulnerability NOTE: Deficiencies of controls that were previously identified as in-place or planned does not necessary mean the likelihood will be increased (i.e., the capability or interest in exercising the vulnerability may be either limited or mitigated through other existing controls – technical or non-technical) 28

Step 5: Likelihood Determination High Likelihood Level • Threat-source is highly motivated • Threat-source is sufficiently capable • Controls to prevent vulnerability from being exercised are ineffective Medium Likelihood Level • Threat-source is motivated • Threat-source is capable • Controls are in-place that may impede successful exercise of the vulnerability Low Likelihood Level • Threat-source lacks motivation • Threat-source lacks capability • Controls are in-place to prevent, or at least significantly impede, the vulnerability from being exercised 29

Step 6: Impact Analysis What is the goal of an impact analysis? • Determine the adverse impact results from a successful threat exercise of a vulnerability What information is required? • System mission (supporting organizational business process or functions) • System and data criticality (criticality to supporting organizational mission) • System and data sensitivity (confidentiality, integrity, and availability) What can the information be obtain? • OMB Exhibit 300 • Business Impact Analysis • Prioritization of the hardware, software, services and related technologies supporting other organization’s (i.e., shared resources) NOTE: Although mostly qualitative in nature, quantitative metrics can be established that can be used to support the impact determination, which include: lost revenue, cost of replacement or repair, level of effort required to correct a successful execution of a vulnerability (given knowledge of the potential consequences) 30

Step 6: Impact Analysis High Magnitude of Impact • Highly costly loss of major tangible assets or resources • Significantly violate, harm, or impede an organization’s mission • Human death or serious injury Medium Magnitude of Impact • Costly loss of tangible assets or resources • Violates, harms, or impedes an organizations mission, reputation or interest • Human Injury Low Magnitude of Impact • Loss of tangible assets, or resources • Noticeably affect an organization’s mission, reputation or interest 31

Step 7: Risk Determination Expressed as a function of: • Likelihood of a given threat-source’s attempt to exercise a vulnerability • Magnitude of impact should a threat-source be successful • Adequacy of planned or existing controls that would reduce or eliminate the vulnerability (Impact X Likelihood) = Risk-Level* NOTE: Although not expressed in NIST SP 800-30, the organization can consider the cost and/or complexity required to exercise a vulnerability normalize the probability variable which if using the attack tree would increase as the attacker traversed up the tree (or succeeded in intermediate sub-goals): (Impact x (Likelihood / Cost (or Complexity) = Risk Level * The assigned risk-level value is a calculation of multiplying the threat likelihood (probability) and the threat impact (actual ratings will varying depending on the matrix size used – 3x3, 4x4, or 5x5) 32

Step 7: Risk Determination High Risk Level • Strong need for corrective measures • Information system can continue to operate with corrective actions in-place Medium Magnitude of Impact • Corrective actions are needed • Plan of action must be developed to incorporate these action plans within a reasonable period of time Low Magnitude of Impact • Authorizing Official must determine whether a corrective action is required; or • Accept the risk 33

Step 7: Control Recommendations What is the goal of the recommended controls? • Reduce the level of risk to the information system and information to an acceptable level • What factors should be considered in recommending control and alternative solutions: – Effectiveness of recommended options – Legislative and regulatory concerns – Organizational policy – Operational impact – Safety and reliability Do all controls recommended need to be implemented? • A cost-benefit analysis should be used to demonstrate the opportunity achieved by the implementation of a control to reduce the risk level NOTE: Recommended are the result of the Risk Assessment process and the input to the Risk Mitigation process (both are part of Risk Management) 34

Step 9: Results Documentation Where should results of the risk assessment be documented? • The Risk Assessment Report (RAR) is a management report that provides a systematic and analytics approach to assess risk • The RAR, unlike and audit report, is meant to enable senior management to understand risks that drive the decision of which resources should be allocated to reduce and correct potential losses • Although no specific format is required, as a Risk Management function, the results of the Risk Assessment should focus on supporting organization-wide “cyber preparedness” (Level 1–Foundation Defense to Level 5-Pervasive Agility) 35

Supplementing Tailored Baseline Approaches to integrating Risk Assessment results into the tailored security control baseline? • Requirements Definition Approach - the organization acquires specific and credible threat information (or makes a reasonable assumption) about the activities of adversaries with certain capabilities or attack potential (e.g., skill levels, expertise, available resources) – To effectively withstand cyber attacks from adversaries with the stated capabilities or attack potential, the organization strives to achieve a certain level of security capability or cyber preparedness • Gap Analysis Approach – the organization assesses the current security capability or level of cyber preparedness and determines the types of threats it can reasonably expect to address – If the organization’s current security capability or level of cyber preparedness is insufficient, the gap analysis determines the required capability and level of preparedness Adversary Capabilities Defend Intentions Security Resources Capability 36

Perception = Time-Consuming Activity 37

Reality = Cost-Saving Activity 38

How Do We Bridge the Gap Translate? Risk = Threat + Vulnerabili ty (Impact X Likelihood) = Risk-Level 39

http://www.slideshare.net	17
http://1ecg.com	3
http://www.1ecg.com	3

1ECG - Assessing Operational Risk

by 1ECG on Apr 07, 2010

Accessibility

Tags

Upload Details

Usage Rights

3 Embeds 23

Statistics

1ECG - Assessing Operational Risk — Presentation Transcript