• United States




Risk Mitigation Drives Breach Prevention Costs

Mar 13, 20096 mins
Business ContinuityData and Information Security

What do you tell your CIO or CEO when you try to get additional—or any—breach control dollars into the IS budget?  How do you position these controls to demonstrate business value?  If you aren’t talking in terms of business risk, you might be pounding harder on the table than necessary.

Most seasoned security professionals know there is no way to completely protect a network and sensitive information from a highly motivated attacker.  Rather, the goal is to reduce the risk of an attack. 

What is risk?

Risk is represented in various ways.  The one I prefer is Risk = Probability of Occurrence * Business Impact.  In simple terms, probability of occurrence (PO) is an estimate of the probability of a successful attack against a specific target, typically expressed in terms of annual occurrence.  I say specific target because PO varies from system to system or between data types.  Business impact (BI) is the damage done to the business if an attack is successful.

There are two approaches to plugging values into the PO and BI: quantitative and qualitative.  Using the quantitative approach, an analyst uses actual statistics and dollar values.  For example, probability of occurrence might be calculated by the number of successful attacks against similar systems or data across the industry in which the organization operates.  So if the average number of successful attacks against a business in the target industry over the past 10 years is 5, the PO might be calculated as .5 (annual probability). 

The qualitative approach relies on experience of stakeholders and the analyst to arrive at estimated values.  Qualitative risk scores are easier to calculate since actual statistics or dollar values associated with an attack don’t have to be available—and usually aren’t.  Further, they tend to give additional weight to attacker motivation and capabilities.  So the rest of this article focuses on qualitative risk assessment.

Calculating risk with qualitative measures

Qualitative measures are usually expressed as a range of values based on information collected by the analyst.  Here are some questions to ask when trying to determine PO for a specific target:

  • What is the value of the data?  How much effort will an attacker be willing to expend to get to the data?
  • What exploits currently exist?  What are the possible attack paths for an internal or an external attacker?  What controls are in place to detect or block intrusion or extrusion activities along these paths?
  • Are all hardware and software components along each attack path patched?  Are they hardened in compliance with best practice or vendor recommendations?  Are all unneeded services shut down and all ports either closed or managed via access control lists?
  • What skills will an attacker need to successfully breach your defenses?  Can an entry-level hacker crack your defenses or will it take an experienced black hat?
  • In general, what vulnerabilities exist at each component in the attack path?

Using attack trees as part of formal threat modeling is often valuable when trying to answer these questions.  And remember, there can be more than one path from an attacker to a target.  All paths must be assessed.  Once the analyst understands weaknesses and strengths along attack paths, he or she works with relevant personnel (e.g., developers, network engineers, and system administrators) to assign a value representing the probability of a successful breach. 

The next step is assessing business impact.  Again, this can be a value representing a point in a range between low impact and severe impact.  It can also be a dollar value representing the impact of a single event.  My white paper, A Practical Approach to Threat Modeling (PDF), contains a detailed discussion about how to arrive at these values with an expanded view of PO and BI.  It also contains threat modeling tools

Only management, with the analyst’s assistance, can determine whether a risk score is too high.  If a decision is made to reduce risk, the work done up to this point provides most of the information needed to reduce the organization’s exposure.

Mitigating risk

Risk mitigation should focus on two things: strengthening of key vulnerabilities or reduction in the value of the target data.  During the analysis phase, the analyst identified the possible paths to the target and weaknesses along that path.  Using that information, here are some mitigation steps he or she should consider:

  1. Install all unapplied security patches?
  2. Revisit system hardening misses?
  3. Get rid of sensitive information the organization doesn’t need and stop storing data from customers, patients, employees, etc. that isn’t absolutely necessary for business operation?

These three mitigation steps cost nothing but time.  Once resolved, risk should be recalculated.  If the score is still too high, the analyst proceeds to mitigation steps which typically require budget.  The process might look something like this:

  1. Identify one or more controls for each attack path.  These are typically associated with each software or hardware component on the path or placement of an additional control device, such as a firewall or network intrusion protection system.
  2. Assign a dollar amount to each control.
  3. Starting with the lowest-cost control in each path, determine if it alone will stop an attacker’s progress toward the target.  If the answer is yes in all cases, you’ve identified the lowest cost risk mitigation budget.
  4. If one or more lowest-cost controls won’t sufficiently reduce risk along a path, move to a next higher-cost control in the path and redo the analysis.  Continue until all paths are protected in a reasonable and appropriate manner.

Sometimes a combination of controls is necessary to secure a path.  However, the analyst with business value in mind tries to mitigate risk while keeping costs as low as possible.  Using diagrams which demonstrate this effort are very valuable when pitching the solutions to decision makers.

The final word

Remember the objective of breach risk mitigation is to increase the effort necessary to successfully breach a network, system, etc. beyond the value gained by a successful attack.  Most cyber-criminals are in it for the money.  Make it more cost effective to go someplace else for their next breach attempt while minimizing your organization’s costs for control acquisition and management.


Tom Olzak is an information security researcher and an IT professional with more than 34 years of experience in programming, network engineering and security. He has an MBA and a CISSP certification. He is an online instructor for the University of Phoenix, facilitating 400-level security classes.

Tom has held positions as an IS director, director of infrastructure engineering, director of information security and programming manager at a variety of manufacturing, healthcare and distribution companies. Before entering the private sector, he served 10 years in the U.S. Army Military Police, with four years as a military police investigator.

Tom has written three books: Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide. He is also the author of various papers on security management and has been a blogger for, TechRepublic, and Tom Olzak on Security.

The opinions expressed in this blog are those of Tom Olzak and do not necessarily represent those of IDG Communications Inc. or its parent, subsidiary or affiliated companies.