When is It Okay to Accept Software Risk?

‍

In the context of cybersecurity risk is any situation where the company is exposing itself to a potential cyber attack, typically in the form of an unresolved vulnerability. Typically the approach to risk is to mitigate it by removing the security vulnerability and therefore eliminating the risk altogether. However, there are many situations where this is simply infeasible and therefore it’s a necessity to accept the risk. As a cybersecurity professional, it’s important to understand when a risk should be accepted.

Why is the accepting risk function necessary?

To understand this you first need to understand the goal of cybersecurity in a business. Like any other department, cybersecurity is meant to support the business, by protecting the company’s reputation and assets, cybersecurity protects profit. While it’s important to reduce risk, not all risk is equal. For example, if you have an asset that holds customer financial information like credit cards or social security numbers and leaking that information could lead to fraud, then that information should be protected. But if the information is simply a list of physical addresses without any names attached then the risk to the business and the customer is negligible. It’s important to weigh out the time intensity of the fix vs the potential risk of the vulnerability. This simply means that not all vulnerabilities need to be patched. We acknowledge that all vulnerabilities should be patched, but in business, we must prioritize the most impactful risks for remediation. We aren't suggesting that your critical and high vulnerabilities should be left unattended after you receive your pentest report but some low, informational, and even medium severity vulnerabilities may not be worth the time and budget required to fix them compared to the risk they truly present. Instead, you may choose to delegate or accept that risk.

In many of our pentesting engagements, we have had clients simply remove/delete entire portions of their applications that can not easily be remediated. It's kind of the opposite of accepting risk, but it's almost a cousin of it because they never actually fix the component, they judge it to no longer be necessary due to the risk. When it may have been more productive for the business to simply accept that risk and prepare compensating controls around that vulnerability. While accepting risk should not be the norm, it should be a viable option when it is supported by good business reasoning. To correctly make this decision the business must have a process of evaluating the costs in time and budget required to fix the issue vs the benefits of doing so. It should also evaluate the potential impact of that vulnerability on the business's critical assets and overall IT infrastructure and the risk that the vulnerability poses to adjacent systems. The only exception to this evaluation should be critical/high vulnerabilities, typically these should always be patched quickly due to the high potential impact on the business.

The benefits of accepting low-risk vulnerability

You can focus on bigger vulnerabilities that may have a bigger impact on your application: In a simple vulnerability scan, assessment or penetration test you may come across hundreds of vulnerabilities of varying severities. Each of these vulnerabilities would cost time and money to resolve. One strategy is to focus your resources on vulnerabilities that pose the largest impact on your business.

You can save time and money: As explained above it may be more profitable for the business to accept some vulnerabilities that don’t pose a big risk to the business. While absolute security is the goal from an operational level, from an overall business point of view the goal is to maximize profit. By accepting vulnerabilities that aren’t cost-effective to resolve you save time and money that can be allocated to other important tasks.

Dev work is not bogged down by informational and low vulnerabilities, they can use this time to work on other things: Most of the time even if the security team identifies the vulnerabilities and comes up with a remediation plan it typically falls to the dev team to implement the changes required. Accepting certain lower-impact vulnerabilities after investigation, allows the company to free up some dev time for adding more features etc.

Disadvantages to accepting low vulnerability risks

There are some disadvantages to accepting low vulnerability risk that you need to be aware of. Firstly, there is a chance that the vulnerability will be exploited. Any vulnerability no matter how small can be exploited to cause harm to the business. This means there is a potential that your customer data will be exposed and you may be called into question on your decision to accept the risk rather than remediate it. To limit the impact in these situations the security team should have these decisions reviewed by upper management and have them accept the risk as well. This way the blame doesn’t just fall on you. When it comes to explaining this to external stakeholders you should have a clear justification for why this risk was accepted and why it’s not a concern to them.

When it is okay to accept risk

It can be difficult to identify the right time to accept the risk a vulnerability poses, so here are some guidelines you can use to make the correct decision:

Cost evaluation: Mitigation cost is always the first thing to consider. The question to ask is: does it cost significantly more to fix than the potential damage? You always want to be cost-effective with your risk management program.

You have involved all stakeholders: It’s important to have input from all stakeholders on how you are going to handle accepting certain risks. All stakeholders namely security, privacy, compliance and risk management in particular should be informed on whether the company will be accepting certain risks and given the chance to object if they choose to.

Risk acceptance criteria: You should consult your company’s internal risk acceptance criteria and ensure that you are following all of your company’s guidelines when evaluating risk and deciding whether to accept or not.

Periodically reevaluate risk: It’s important that you keep track of vulnerabilities that you accept and periodically check to see if it’s still something that should be left alone or if you have sufficient resources at this time to resolve it. Also, depending on other changes in the environment the risk of a given vulnerability may change and this may make it more or less of a priority as time goes on.

Conclusion

When considering vulnerability mitigation strategies, the potential benefits of accepting the risk associated with the issue should be evaluated. Risk acceptance is the least expensive option in the near term but can be the most expensive option in the long term should an event occur. This is why it should be reserved for security vulnerabilities with very low potential impact such as low or informational severity. Alternatively, it is sometimes possible to "partially fix" a vulnerability that would then turn a critical into, perhaps a medium or low. There is still an accepted risk but it is much less than what it originally was. There's sometimes a sweet spot between not fixing (accepting risk) and a complete remediation, this is a "partial fix" which is just good enough to then accept the risk. It’s important to look at all available options so that you can find the solution that makes the most business sense.