Can risk mitigation controls bring down the impact?

Question

While doing a Risk Assessment, I found that in some old RA documents, after controls have been placed, the Impact in the forcasted value was changed that did not make sense to me. To me the impact never changes as the impact of a critical service being down is the same whether a control is in place or not. What changes however is the probability bring the Risk down (Risk = Probability x Impact). Is this correct?

Answer 1

The impact may change if the control put in place alters a potential attacker's abilities should the problem be exploited.

A good example of where the impact would change is when the mitigation involves segregating networks. Before the segregation, an exploit on OldCorp Unsupported Legacy Daemon X might lead to someone getting access to the internal network, then exfiltrating all your yummy internal documents out of SMB shares. After segregation, the box on which OldCorp ULDX sits is no longer in a position to route packets to your "regular" corp network, so the impact of it getting owned is reduced.

Answer 2

depends on what you mean by "controls" then. given the fact you use a monitoring-system you still will have the impact of a service going down, but you will get noticed very soon and can start recovery. or, if monitoring intelligently, get noticed and act before a service might go down.

the sames goes for implemented standby-systems that could take over sevices, either fully or halfautmated, or stuff like emergeny-response-plans. everything that helps keep the time-to-recovery short, will limit the impact.

you'll always try to avoid outages, but redundancy is costly, so your option is very often to limit the time to recover, if an outage might occure. If you take the calculation from Feral Oink, Impact(event) might be described as Impact(outage * outage_time) where you are able to influence the outage_time, thus decreasing the impact.

Answer 3

Your definition of risk is Risk = Impact(event) * Probability(event).

The general case is expected value, or E(x) = x * Prob(x).

If we want to describe it in measurable terms, dollar value is the most general metric of choice that people can be convinced to care about, so

Dollars-at-Risk = Loss due to event * Probability of event occurring

Your risk policies will lower Probability of the event occurring (the incidence level), we hope!

In the absence of any documentation, it seems likely that your predecessors, who drafted the old risk policies, made the mistake of changing both terms. The only way that the other term, Loss due to event will change would be from something external but causal e.g. passage of time, or due to contingency. Let's say the incident is a network breach that results in a system outage.

Passage of time
The dollar loss due to an outage could have increased since your colleagues drafted their risk analysis documents. For example, costs due to outage, and the associated lost productivity, might be higher because current staff, i.e. data scientists, are more skilled and more highly compensated than their predecessors, i.e. applied statisticians.

System outage impact might have decreased. For example, statisticians, I mean data scientists, do all their high performance computing in the AWS EC2 cloud (via BYOD smartphone) now, instead of a Cray or mainframe in the basement.

Contingency
Contingency-based risk assessment would be exceedingly unlikely without an accompanying explanation. Any such explanation would be included, as part of the risk control policy.

Also, it would be difficult to do with any accuracy. Merely as a thought experiment, let's extend that outage scenario. An outage might not affect the data scientists, but it could take out billing and payroll processing, which would be very costly! But that would mean that the basement mainframe went offline. No risk mitigation policy is likely to cover such an extreme outlier event, nor should it, not as long as there are mainframes running MVS/TSO, and RACF.