Risk Mitigation
The cost of selecting countermeasures to safeguard an asset should not exceed the value of the asset. Risk mitigation is the second half of risk analysis. After the probable risk cost estimation has been done, the emphasis turns toward how to manage the risk mitigation. At this point, a cost-benefit analysis is done to guide the next steps.
Security Control Value Calculation
The rule of thumb for selecting a security control is that it should not cost more than the asset it protects. It doesn’t make business sense to pay more to protect an asset than it is worth. So, how is the value of a security control determined? The value of the security control is the net reduction of loss it brings to the organization by its function. How is this different from the ALE? It goes beyond the reduction to the ALE by the reduced risk to add back the annual cost of the security control. It costs money to save money, so the total savings of the reduced ALE is adjusted to add back the cost of the security control. This adjusted amount reflects the real expense to the organization of the risk and cost of the control.
The next consideration is how the value of the security control is calculated. A cost-benefit analysis compares the calculated expected financial cost of the realized risk’s impact on the assets versus the cost to safeguard those assets. Here is where quantitative risk analysis is useful. Quantitative risk analysis describes risk in measurable metrics and monetary values. These values can be used in a cost-benefit analysis to estimate the value of a security control to the organization.
Using the quantitative approach to estimate the value of a security control on an annual basis, a cost-benefit analysis calculates the reduction of risk-related ALE provided by the security control, less the annual cost of the security control. The equation looks like this:
(Amount of risk reduced by security control) = (ALE before security control) – (ALE after security control)
(Security control value) = (Risk reduced by ALE) – (Annual cost of the security control)
To illustrate a cost-benefit analysis of a security control, now you will evaluate the value of a DDoS mitigation solution for a company’s e-commerce website.
In this example, the company’s revenue exclusively comes from sales generated from its e-commerce site. This company had been affected by DDoS attacks in the past, causing it to conduct a detailed quantitative risk analysis to determine the cost of this type of attack and the best approach to mitigate the problem.
The quantitative risk analysis determined that the ALE with the combined losses of revenue, remedial operational costs, and the loss of customers from DDoS attacks over a year’s time was about $10,000. After selecting a DDoS mitigation solution as a safeguard, the ALE was reduced to $2,000. The annual cost for the DDoS mitigation solution safe- guard is $3,500.
- ALE before applying DDoS mitigation security control: $10,000.00
- ALE after applying DDoS mitigation security control: $2,000.00
- Annual cost of DDoS mitigation security control: $3,500.00
Plugging these values into the cost-benefit calculation gives the results shown in Table 8.8.
As you can see from the calculation in Table 8.8, there is more to the equation than just the reduction of the ALE. Let’s examine the steps of the calculation more closely. After applying the security control, the dollar amount of the expected annual loss is reduced from $10,000 to $2,000. This amounts to an $8,000 reduction of ALE. This $8,000 of reduced loss to an organization is realized by the security control. The cost of the security control is factored into calculating the total cost reduction resulting from the reduced risk.
Factoring in this cost adjusts the value of the “total savings” realized by the organization. This total savings is the value that the security control brings to an organization. How is this the value of the security control? First, recall that the organization by its ALE calculation was losing $10,000 per year. After implementing the security control, this ALE was reduced to $2,000. This means that the company still expects to lose $2,000 per year due to residual risk. Add to this the annual cost of the security control, $3,500, which brings the total expense of the ALE + security control costs to $5,500 per year. Compared to the original ALE of $10,000, this results in a net savings, or value, to the organization of $4,500. This is the value of the security control.
Security Control Costs
Security controls come with a price, but how much do they cost? Is it just the purchase price? Should support costs be considered? The answer is that a security control’s price is always more than its purchase price. When calculating the cost of a countermeasure for a cost-benefit analysis, you should always consider its full cost, which is made up of a number of accessory costs that should be considered:
- Product costs
- Professional services costs
- Design/planning cost
- Implementation cost
- Testing/evaluation cost
- Training costs
- Cost for compatibility with other safeguards
- Maintenance costs
- Operating and support costs
- Cost impact on staff productivity
- Subscription costs
These additional costs are but a sample of additional, “hidden” costs of the safeguards that are purchased. As a security professional, you should understand that the price of a safeguard is always more than the purchase price and that it is important not to spend more to protect an asset than what the asset is worth.
Evaluating Security Controls
The goal of countermeasure selection is to find those countermeasures that reduce the costs of a risk event by more than the cost to use the countermeasures. This goal was explained by the countermeasure value calculations earlier.
The overall qualities of a countermeasure should also be evaluated to determine its fitness and usability by the organization within its operating environment. The following are some qualities to consider when evaluating countermeasures:
- Ease of use
- Testability
- Least privilege defaults
- Configurability
- Administrative functionality
- Auditing functionality
- Maintainability
- Understandability and usage of output
Residual Risk
There will always be some risk that exists for an organization even after implementation of safeguards or countermeasures to reduce the risk. The risk that remains after the implementation of countermeasures is known as the residual risk.
It is important to understand a few concepts first to understand residual risk. Residual risk calculations are based on the knowledge of the total risk that an organization faces before the implementation of safeguards and countermeasures. Safeguards, pro- active security controls, countermeasures, and reactive security controls all are applied to reduce risk. These security controls reduce the total risk to the extent by which they diminish the potential for threat realization. Security controls can also reduce the impact of a risk exploitation, such as when a firewall block is put in place after a workstation is found to contain malware. A control gap is where security controls do not cover the potential for threat realization. Therefore, to understand residual risk, it is necessary to know that it is based on these two variables, the security controls’ risk reduction capability and the gap in protection that remains after the security controls’ implementation.
Total Risk Equation
The equation to calculate total risk is a multiplication of the affected assets’ value, their vulnerabilities, and their associated threats as follows:
Total risk = Threats × Vulnerability × AV
Residual Risk Equation
There are two equations to calculate residual risk, as mentioned earlier. The first residual risk calculation takes into account the amount of risk reduction realized by the implementation of selected security controls, as such:
Residual risk = Total risk – Security controls (also known as countermeasures)
Alternatively, residual risk is calculated as the product of the unprotected portion of the total risk, also known as the security controls gap:
Residual risk = Total risk × Controls gap
Risk Treatment
There are four different ways an organization can treat risks: reduction, transfer, avoidance, or acceptance. Here are some examples of risk treatment applied to the software development environment:
- Risk reduction: Risk reduction, also known as risk mitigation, is the process of reducing the risk to the point where it is acceptable to the organization. Typically, implementing security controls reduces risk. In the software development environment, risk is reduced by applying and enforcing controls with examples such as following secure SDLC processes, enforcing secure coding guidelines, using automated and comprehensive testing (including automated security testing), and imposing a strict separation of software development, deployment, and data environments.
- Risk transfer: Risk transfer is when risk is legally assigned to a third party. With respect to software development, risk transfer is often done by outsourcing a project to a third party. This is typically thought of as a cost-savings tactic, but it also can reduce the security risks related to software development. A third-party development organization can have more expertise in secure software develop- ment. It may also have more mature secure SDLC processes. Transferring the software development in this case places the risks of the software project on a more mature organization that is more capable in producing secure software.
- Risk avoidance: Risk avoidance is when an organization chooses to deflect or terminate situations that cause a Avoiding security risk in a software development project can be done in many ways. One way is to reduce the number of features to be developed to allow more development attention to a smaller set of features to release. This makes room for improved code quality and testing. This also gives the software developers the opportunity to learn better ways to write secure software. Another motivation is to remove software features and functionality that have an unacceptable level of vulnerability exposure.
- Risk acceptance: Risk acceptance is the assumption of risk. Risk acceptance is necessary because it is impossible to reduce risk levels to zero. There will always be an element of security risk in software development and its artifacts. How does an organization accept these risks? First there needs to be an understanding of the level of risk and the potential consequences and cost of the damage. A software risk assessment supports this discovery. Among many things, a software risk assessment should take into account the software’s data classification to get a good understanding of the risk mitigation impact. Another software security risk mitigation that is often hidden behind notions of “progress” and delivery is the risk of haste. Skip- ping steps in the secure SDLC, rushing software construction, and weak testing can cause or allow flaws, defects, and insufficiencies in software security controls to manifest. When conducting a risk review for risk acceptance purposes, be sure to incorporate compliance checklists of secure SDLC processes and practices in your risk assessment criteria. As a security professional you should beware of accepting a risk mitigation that is not fully understood.
