Risk Triage Rod Carney, CRISC 11/13/2014

Agenda What is Risk Triage? Developing a Triage Risk Assessment A Risk Triage Tool Approach Risk Triage Example

Triage – What comes to mind?

Triage – What comes to mind? Triage Defined: A process for sorting injured people into groups based on their need for or likely benefit from immediate medical treatment. A system used to allocate a scarce commodity, such as food, only to those capable of deriving the greatest benefit from it. A process in which things are ranked in terms of importance or priority. There are a few definitions for triage, the first of which relates to what is probably the most common thought when you hear the word. You typically think of fast-paced decisions made in a situation where multiple injuries have occurred. How does it work? A process has been established up front, probably rehearsed, where a very few, but very key elements are assessed to make decisions which hopefully, will result in the greatest positive impact. Many times it is a scenario involving a number of casualties. The definition that closely relates to a risk triage is that involving a ranking of things in terms of importance or priority….or in certain cases…risk.

Triage for Risk Analysis What does Triage mean to a risk assessment: Small number of risk elements Most key risk elements Quick assessment for deeper involvement Risk Management Security oversight Quick assessment for efficiency Business decisions Business authorizations How do we relate the concept of triage to assessing risk? Risk, especially technology risk, comes in all shapes & sizes and the process to assess risk can take on many shapes as well. On one extreme, it could involve a full visibility study in an area to develop and document what is known relative to the elements of risk in that area. It could involve a lengthy engagement with a professional Risk Management firm to complete an assessment. A triage is the “Reader’s Digest Condensed Version” of a risk assessment. In terms of prioritizing, it can be used to help determine areas of focused governance by groups such as Risk Management, Information Security or even an Enterprise Architecture group. An example might be assessing a portfolio of 200 projects to determine which pose the greatest risk the organization. To do that quickly and efficiently, you might develop a process, involving a triage risk analysis to help with the prioritization.

Triage for Risk Analysis Applications for Triage Risk Analysis Project implementations Enterprise release implementations Vendor evaluations / risk assessments Vulnerability assessments Considerations for Triage Risk analysis include Project Risk Triage Prioritizing involvement in projects, as mentioned a moment ago Assessing the completion of key elements to minimize risk associated with project implementations Release Risk Traige Assessing the aggregate relative risk of multiple projects implementing within the same implementation window Vendor assessments Assessing the key elements of vendor risk through various points of a vendor relationship Vulnerability assessments Taking into account the relevant layers of controls to determine residual risk associated with vulnerabilities identified by the various tools

Triage for Risk Analysis Why? What’s the benefit? Fast / Efficient Consistent input / analysis Quantitative Defendable Emotionless *** Better Informed Decisions *** Once you develop the triage and the process, it becomes a quick, easy and efficient means of accomplishing your assessment. It is based on real, known data, so that the results are defendable and helps to curb the emotional reactions. At the end of the day, it is all about making better informed decisions.

Planning a Triage Risk Assessment Follow a risk assessment methodology Scale it down to represent a triage Identify the key elements that influence risk Develop a repeatable process Follow a methodology for: - Consistency - Repeatability - Defendable Results There are a number of risk assessment methodologies. If you and your organization use one regularly, stick with it and scale it down into a quick and efficient assessment process. FAIR ISACA COBIT 5 ISO/IEC 31000:2009 and 27005:2011 NIST Special Publication 800-30 OCTAVE Allegro RiskSafe We have settled on the methodology represented with FAIR and through the remainder of the discussion, I’ll describe how we’ve taken the key elements of FAIR and built a process for triage risk assessments. Develop a repeatable process - Data Collection - Assessment through a tool that actually calculates the risk - Reporting Results

Planning a Triage Risk Assessment Categorize the risk being assessed Examples: Confidentiality Availability Integrity Result - a better focused triage assessment One of the first things to consider is categorizing the risk each assessment is focusing on. The reason for this is you want to keep the assessment focused on the key relevant elements and not let the assessment become diluted by elements, even real risk factors, that just don’t apply. For example, consider the Availability Risk associated with a project making architectural changes to a web-facing system supporting your business. For this assessment, you care about things like DR documentation and testing, along with system testing and adherence to architectural standards. Now then, you also care about the results of application vulnerability scanning, but more so for Confidentiality and Integrity risk rather than Availability risk. Sure it may apply, but for an Availability risk assessment, there are other more key assessment factors.

Planning a Triage Risk Assessment The FAIR Methodology….. As I mentioned, we’ve based our triage assessments on the FAIR methodology. FAIR, in a slide, looks like this and the full taxonomy is even more involved than what you see here. The key for a triage is focusing on the highest elements that contribute to risk. We’ll focus on those elements that make up Loss Event Frequency and Loss Magnitude.

Scaling it Down for Triage Risk Loss Event Frequency Loss Magnitude Now that you understand the key components of the risk scenario, this is how they fit together for a triage risk analysis…. Loss Event Frequency and Loss Magnitude are the top level components of Risk in a FAIR assessment. These relate to what you traditionally think of with Likelihood and Impact when thinking of Risk assessments. These are calculated values based on threats, value/liability represented for the asset and controls intended to mitigate the threats and liability. For a triage assessment, we’ll take it down just 1 level to look at the elements that contribute to them. Loss Event Frequency is determined by the probable threats relevant to the scenario and the related vulnerability. Controls typically contribute significantly to the vulnerability assessment, plus with many of our triage assessments we’ve developed, we are looking specifically for evidence of the control activities, the triage diagram replaces Vulnerability in the FAIR taxonomy with Controls. We have a similar relationship with loss and control activities which are expected to reduce impact, should issues manifest themselves into loss. Threat Event Frequency Controls Primary / Secondary Loss Controls

Building a Triage Risk Assessment Articulate the risk scenario Identify the associated Asset Understand / define the potential loss associated with the risk scenario As with any risk assessment, you really can’t effectively get started without a few foundational components. You have to: First, Describe and document the scenario which could manifest itself into loss. If there is no scenario in which a loss could occur, there probably isn’t an analysis to be done. The most important part of the risk scenario is the asset involved or that which could be impacted. Have an idea of what the probable loss “looks or feels like.” Is it a financial loss… is it a property loss… Is loss in the form of an injury… Examples: Risk Scenario Project Implementations Release risk assessments Asset Financial Data Sensitive PII data An online system through which customers go for service Loss System outage Breach of sensitive customer Information Financial Loss

Building a Triage Risk Assessment Know the Threats Are there controls or expected actions to mitigate the threats or minimize impact? Once you know these things, you can start looking at the elements that actually act in such a way as to cause loss to occur. These elements are the THREATS. You should be able to quantify the threats and, by nature, these are the things that, by their existence, can increase the probability that some form of loss will occur, if not properly managed. Many of the triage assessments we’ve developed actually serve the purpose of monitoring activities that are expected as standard process to reduce the likelihood that loss will result from successful threats Examples: Threats Poorly written code or code with vulnerabilities Non-standard or unsupported system components Internet threats (DDOS) Controls Security standards compliance Up to date and tested tech recovery plans Testing complete with no high or critical rated defects

Building a Triage Risk Assessment Identify key triage THREAT and LOSS elements Keep the number of elements to no more than 3 per risk factor Qualify their severity in simple terms Yes/No Low/Moderate/High In just a moment, I’ll show you how the triage elements are arranged on a spreadsheet table for a Bayesian type analysis. But first, there are a few key guidelines to go over for consideration….strong consideration….as your analysis tool comes together. Generally, keep the elements for triage for each of the factors small in number and simple in response options. Remember – this is a Triage. When we look at some Bayes table examples, this will become clear.

Building a Triage Risk Assessment Identify key control elements Actions intended to mitigate against the effect of elements contributing to risk Keep the number of control elements to no more than 3 per risk factor Qualify as “control strength” in simple terms Yes/No High/Moderate/Low *** Caution *** This can become confusing Same guidance applies to the Control elements and just one additional word of caution. As you discuss Risk, Threats and Severity, we naturally equate the word “High” with the negative, or increasing risk. When we discuss Control Strength, Highs actually serve to decrease overall severity and risk. It’s just something that has tripped us up from time to time.

Building a Triage Risk Assessment Loss Event Frequency Loss Magnitude Medium Risk High Low Control Strength Threat Event Frequency Medium Risk High Low Control Strength Primary / Secondary Loss I mentioned that, for many of our triage assessments, one of the goals is to provide evidence that expected control activities either exist or are being performed. It’s important to the triage assessment to define how the control or the strength of controls combines with Threat Event Frequency and loss elements to determine the Loss Event Frequency and Loss Magnitude. You see here that, the Lower the control strength, the Higher the severity.

Building a Triage Risk Assessment Medium Risk High Low Loss Magnitude Loss Event Frequency As you assess the effects of Loss Event Frequency and Loss Magnitude on risk, it stands to reason that, as they both increase, so does the risk. No surprises here. Loss Event Frequency (probability a threat will act in such a way as to cause loss) Loss Magnitude (impact or extent of loss given successful action by a threat)

Risk Assessment Example The Scenario What is the RISK associated with a project involving an upgrade or change to an internal Human Resources system? For this example, Availability Risk Consider a change that may be an application upgrade or some infrastructure upgrade that may be adding capacity in terms of adding servers or perhaps a change involving a database upgrade. These types of changes all pose some loss exposure in the event of issues resulting from the planned changes. Remember to categorize the Risk: This example focuses on Availability Risk, not taking into account the elements of Confidentiality or Integrity Risk for the scenario

Bayes Table Analysis Threat Event Frequency Control Strength Input TEF Element Severity Required Recovery Time Mod Low High Project / System Complexity Vendor supported Yes Y N LLY LLN LMY LMN LHY LHN MLY MLN MMY MMN MHY MHN HLY HLN HMY HMN HHY HHN INPUT OUTPUT Control Strength A table is laid out with all possible combinations and permutations of the various inputs so that each has a corresponding output. This is an example of possible Threat and control elements that contribute to Availability Risk associated with a Technology project implementation. For Threats, the output is a Threat Severity level. The way it works is as follows: A severity is entered for each The combination of inputs is captured as the first character of each of the inputs Each combination of inputs is represented on the table with a resulting corresponding severity An HLOOKUP formula determines, from the input combination, the resulting severity from the table and that becomes the output to represent the Threat Event Frequency The same process takes place to establish Control Strength, based on controls input. The outputs are carried forward to another table to determine Loss Event Frequency. Input Combination Controls - TEF System testing No Yes   Standards Alignment Aligned A N YA YN NA NN Mod High Low

Bayes Table Analysis Loss Event Frequency Threat Event Frequency H M L TEF High Low Mod Controls - TEF LH LM LL MH MM ML HH HM HL Threat Event Frequency H M L Control Strength

Bayes Table Analysis Primary Value/Liability # Employees Mod Low High Financial transactions No Yes LN LY MN MY HN HY Secondary Value/Liability # Customers None Federal reporting deadlines NN NY Controls - LM Disaster recovery testing Operational support YY YN Primary Loss and Secondary Loss follow the same definitions as those defined by FAIR.

Bayes Table Analysis And Finally….. Risk Loss Event Frequency Loss Magnitude Controls - LM Low High Mod Primary LM Secondary LM HLL HLM HLH HML HMM HMH HHL HHM HHH MLL MLM MLH MML MMM MMH MHL MHM MHH LLL LLM LLH LML LMM LMH LHL LHM LHH And Finally….. The Loss Magnitude table clearly illustrates why it’s important to keep the number of input elements and possible inputs for each to a maximum of 3. We do have a couple of tables with 4 input elements, but the really become unwieldy. Finally, the Loss Event Frequency and Loss Magnitude come together to determine the associated risk. Risk Loss Event Frequency High Low Mod Loss Magnitude LL LM LH ML MM MH HL HM HH

Questions….. Rod Carney Huntington National Bank rod.carney@huntington.com