Quantitative Risk Exposures: Tools, Math, Forums, Data Sources, Self Insurance, Persuasive Uses

[arctific]

Make things simple, but not too simple.  The problem with measuring risk from High to Low or a scale of one to ten is that it is too simple.  It is next to impossible to know how much project budget is needed to change a risk from a 5 to 4.  It is possible to build tables to make the measure of risk more reliable and repeatable.  An example below that measures risk exposure on a scale from 1 to 25 by multiplying Frequency and Impact can help.

Impact	Description
1	Less than $10,000 for a single loss event
2	$10,000 to less than $100,000 for a single loss event
3	$100,000 to less than $1,000,000 for a single loss event
4	$1,000,000 to $10,000,000 for a single loss event
5	$10,000,000 or more per single loss event

Frequency	Description
1	Less than once in 100 years
2	Less than once in 10 years to 100 years
3	Less than once per year to 10 years
4	Less than once per month to a year
5	Less than once per month

Even adding factors such as how easy a risk is to fix helps a firm to sort out high risks that can be easily resolved first before considering medium risks.

Ease	Description
1	Will take more than $10,000,000 or 10 years to resolve
2	Will take more than $1,000,000 or 1 year but less than $10,000,000 or 10 years to resolve
3	Will take more than $100,000 or 1 month but less than $1,000,000 or 1 year to resolve
4	Will take more than $10,000 or 3 days but less than $100,000 or 1 month to resolve
5	Will take less than $10,000 or 3 days to resolve

A system of Frequency times Impact times Ease can help identify risks that have a high benefit to resolve quickly for a good benefit for the security operation dollar.  This is a whole lot better than an Audit table with risks from High to Low.  Fixing something worth fixing for any good reason from good risk assessment to compliance needs is never a bad idea.  But, with better math, good business cases for change can be created. 

Quantitative Risk:

What is a 4 worth and what kind of return on the project is worth it to your firm? 

[Bradleman]

Don,

This is the type of pratical information I've been looking for, thanks so much for posting it.

Bradley Adleman

[arctific]

Bradley,

You are welcome.  The table example above also scales somewhat with a firm's size.

Consider that a medium level risk should roughly correllate to 3% of a firms Annual Revenue or Cash flow from operations. This number can spread based on the "risk posture" of the firm.  95% of USA firms will be between 1% and 17% of annual revenue at risk from an impact.  Generally, the more staff leads to the more computers, the more on line records, and the more revenue from those records.  The more computers leads to a larger attack surface so more attacks per year.  But, as a firm gets larger, some economies of scale to protect computers begin to appear that smaller firms tend to skip.  A smaller firm could be more secure than a larger firm on a per computer basis if they invested in that security the way a larger firm does.  But, the frequency of attack is smaller so smaller firms are tempted to skip that investment.  As these firms grow, the attack surface and impact risk faster than the firm does until the firm gets large and the risk grows slower than the firm does.  

Excellent practices litterally can move a firm's sense of experienced damage by a power of 10 between worst case and best case security.  Typical security is about 3 times better than worst case security.

Next, I want start adding some finance math.

[arctific]

Small firms vs large firms:  The loss per record from a breach for a small firm is larger per record than from a large firm.  Below is one reason why.

Consider the lawsuit for the damage.  The lawsuits are going to cost about 3 Million in legal fees.  Then, the per record damages will engage.

Suppose we have a loss model that looks something like Home Depot's experience:

Loss = 3 MM + $3.14 * breached_credit_card

Loss/Breached Record = 3 MM / 40 MM_cards + $3.14  = $3.89 per breached card

Consider a small firm with the same breach costs that lost 20,000 credit cards.  But, the good news is that the lawsuit settled quicker so it only cost 0.5 Million.

Loss/Breached Record = 0.5 MM / 0.02 MM_cards + $3.14 = $28.14 per breached card

The other problem is that small firms are less able to absorbe cash hits.  Target's massive breach only cost it about 10% of its annual revenue.  But a small firm might easily experience a losss near 100% of its annual revenue.  So, the chances of going bankrupt due the breach go up.

Odds_Going_Bankrupt = 1 - exp(-(Breach_costs)/(Annual_Revenue))

Target's Bankruptcy odds = 1 - exp(-0.10) =  9.5%  (but it also bough cyber insurance so it did OK.)

Small firm Bankruptcy odds = 1 - exp(-1) = 63%  (Very dangerous, the firm is small and its death does not show up on the news.)

    - Note: the SEC reports the small firm bankruptcy rate within a year of a breach is closer to 61%.

[Frank_Mayer]

Good discussion but the effectiveness of the fix in terms of effectiveness in view of the actual threat  needs a factor as well.  It is impossible to know even the probable effectiveness of a fix unless the threat to your system is understood in terms of threat and can be explained to management with solid back up evidence in terms they can understand.  The body of knowledge on line at the NIST Computer Security Resource Center Special Publication 800-30, Guide for Conducting Risk Assessments (see https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final) points to the real need for understanding the threat as part of any calculation.  What really makes this difficult is, as noted in 800-30 "adversaries change some characteristic of their intent/targeting in order to avoid and/or overcome those safeguards/countermeasures."  All this needs to be factored in the metrics and methods of collecting input data for those metrics and in computing the metrics.   I have decades of experience doing this and I can tell you it is complex and still you wind up with an approximation since the threat is very dynamic.

[arctific]

Frank,

Correct.  This will lead us to an model of the attacker.  This will be especially important when I present the cost of an unpatched vulnerability.  For now, I would like to present the view intuitively in short story -- always good when discussing risk with leadership to be able to use story form.

The Cold Yogurt Problem:  A customer in a grocery story goes to the refridgerator section intending to buy a cold yogurt.  After selection, the customer turns toward the checkout line intending to buy it.  If the line is too long, the customer may wait until the yogurt warms up.  If so, they may refuse to buy it.  They may also express unhappiness with the store and change their buying habits to seek out a competitors store.  Knowing this, the grocery story manager watches to look at line lengths in the store.  As a general rule in grocery stores if the line gets longer than three customers, the manager seeks to open up another register, split the line so that each customer purchases items quickly.  The yogurt never gets cold.  Similarly, if the lines are too short, the grocery store manager shuts down parallel payment registers to save money.  Also, bored staff can present its own problems.  

In this story, a new vulnerability in line to be resolved is that cold yogurt.  The line to resolve newly arriving vulnerabilities each month is Information Security Patching Operations.  There is a cost trade off between the time in line that a vulnerablity waits to be resolved -- more time for a villain to find it and exploit it -- and the cost of the security patching capability.  A business leader needs to understand how to adapt that to conditions of the firm or is in peril of knowing less about their business that a grocery store manager does about cold yogurts.

[arctific]

Dynamic Risk: Later, I will start a section dealing with time depedent probability and its affect on process failure rates and business costs.  These tools will help Information Security staff present business cases for prevention, detection, resolution, process improvement intiatives as well as cost effectiveness of mitigation strategies.

[Frank_Mayer]

I like your analogy.  This kind of story is just is what is needed to get management to understand why mundane and seemingly costly processes, like patching, need to be done.  I have seen where time taken to develop presentations and discussions to ensure good senior management engagement has really paid off in implementing proactive patch management despite other major forces in an organization wanting to slow roll the process because it was "too hard" from their perspective. 

[JoePete]

---

@arctific wrote:

Even adding factors such as how easy a risk is to fix helps a firm to sort out high risks that can be easily resolved first before considering medium risks.

Ease	Description
1	Will take more than $10,000,000 or 10 years to resolve
2	Will take more than $1,000,000 or 1 year but less than $10,000,000 or 10 years to resolve
3	Will take more than $100,000 or 1 month but less than $1,000,000 or 1 year to resolve
4	Will take more than $10,000 or 3 days but less than $100,000 or 1 month to resolve
5	Will take less than $10,000 or 3 days to resolve

---

Some interesting food for thought. I'd worry that your ease factor really combines two factors in one - cost and time. They don't always vary together. I like the idea of trying to quantify the "low-hanging" fruit. Some might say this speaks to recovery point objectives in a business impact analysis and thus may be more suited for business continuity than risk. The problem is these two related assessments often are done in isolation. This also explains a lot of the news of the day - too many security incidents seem easily preventable, but the mitigation may have been too small to show up on the risk radar, and business continuity tends to only get rolled out once an incident happens (not before it).

[jordanpw]

Great topic. I read a great book on this recently, that makes a very strong case for traditional qualitative risk assessment being close to useless, and in some ways even harmful and misleading. The Book is:

'How to Measure Anything in Cybersecurity Risk' - Amazon link

That's not an affiliate link or any nonsense like that. I just think it was an excellent read and made a powerful case for moving away from qualitative risk assessment.