Security Remediation Budgeting - Everything You Need to Know

Roee Shohat, Head of Go to Market

February 8, 2024

As security professionals, building your budget can be a long-winded, challenging and overall exhausting process. Justifying your needs to top management requires trying to explain and provide context to things such as risk reduction and exposure reduction, which are hard to quantify and difficult to attach value to. If your explanations don’t resonate with the executives - there goes your budget.

Placing value on things that relate to compliance, legal liability or which may impact the company’s ability to conduct business, is easier to justify - no compliance means no income or worse - jail time. But when it comes to remediation, which usually demands a larger budget than compliance, the trade-off is usually with business functionality, because engineers need to actively participate in the remediation process, and the tools required are costly.

To help you bridge these gaps, here are several approaches you can adopt to make the process a little less painful:

A risk-based approach to remediation budgeting

This approach works best if you have a well-established GRC and implement your risk management policy and procedures, and if your risk management framework already includes business impact elements associated with costs for the company. When the foundations of risk management are already present in the company, senior management can translate potential loss with the cost of remediation which should be lower.

The steps to generate a risk-based business case for your remediation should include the following as a baseline:

Choose the scope of the remediation you'd like to focus on. It could be several applications, a single application, or potentially your organization's crown jewels.
The second phase includes gathering all of the vulnerabilities impacting the scope you defined in step one.
With the help of your risk or GRC team, locate and define the business impact of these vulnerabilities on the organization by calculating Annual Loss Expectancy, to find the potential cost associated with them.
Work with the engineering teams to assess the cost of their work on remediation, across all teams, either for a single effort, such as an application and interfaces upgrade, or perhaps a monthly cost for fixing application security issues.
It's always helpful to learn from publicly available case studies on remediation from your specific industry, or even sample breaches to demonstrate the potential impact.

Following the process above, use the data you collected to calculate your potential budgetary needs. Example calculations may look like this:

Remediation cost

The application has 100 critical and high vulnerabilities. The cost of fixing can be estimated as 6 hours per vulnerability on average = 600h. Assuming the average cost of a software engineer is $100 per hour, the remediation cost is around $60K.

Risk Annual Loss Expectancy

Annual Loss Expectancy is calculated as Single Loss Expectancy (SLE) x Annual Rate of Occurrence (ARO), as the Single Loss Expectancy depends on the type of asset/application and what vulnerabilities you have. If you’re interested in the details, you might want to use simple terms such as below, otherwise it could mean SLE = $30M and ARO 0.25. So ALE would be = $7.5M.

Availability impacting vulnerabilities (usually part of the CVSS Score): Use the cost impact of a potential downtime of that application, and multiply it by the time it will take to recover from it. If one day of revenue from that application is worth $10M, that would be the number to start from and multiply the ARO of once in 4 years (0.25), giving you $2.5M in ALE.
If you have potential confidentiality issues and could lose customer records, an approach to calculate it would be to multiply the number of customer records stored in the application by the average fine per record (it could also be as high as $350 per record depending on the breach and reason for it). Unpatched vulnerabilities are sometimes considered as examples of negligence, and therefore the fines could be very high. If our portal application has 3000 customer records, fines could be 3000 x $350, which is approximately $1M, the ARO could be 2, and our ALE is $2M.
There are other factors like brand damage and customer satisfaction but those are subjective and your Risk team should be aware of them.

If you can look into past vulnerabilities in the organization or in the scope you chose, comparing annual remediation costs vs. ALE is the way to go. In your business case, it’s also helpful to cite published breaches and their impact. One example could be from the aviation industry, where British Airways was breached and lost over 400K customer and employee records. Their original fine was 183M GBP. This can be an example of the SLE.

The corporate approach to getting remediation budgeted

A remediation budget must be secured differently in organizations with a disconnect or friction between security and development/business teams. There may be a conflict here due to the age-old gap between security needs, which dictate caution and thorough assessments, and development priorities, which include fast, efficient production. There may be a lack of communication as a result of this gap, so here are two approaches that may help.

Building a relationship with security-minded colleagues from the technology area in your organization will most likely be based on shared interests and personal relationships. In order to identify the right stakeholders, we suggest offering a security webinar or lecture for other teams and gauging their interest in the issues raised. Follow-up sessions can be offered, in which security teams could illuminate joint concerns such as secure development, input sanitation and other relevant topics, which may increase buy-in.

Additional shared activities around these concerns, including a security poll, games and competitions around building the most secure app will help drive the understanding that security is just another important aspect of the software or solutions quality, making it easier to prioritize such activities in other teams. For example, security teams can suggest a questionnaire focused on secure development such as OPENSAMM. When compiling the results, they can be compared to industry benchmarks and shared with technology managers to illustrate the topic’s importance.

Another option would be to implement and leverage a patching or vulnerability management policy within your organization. Using this policy as a way for security teams to liaise with management and state your case for remediation, underlining the importance of this policy baed on external obligations like compliance frameworks (PCI DSS, for example), regulatory requirements (GDPR/CCPA) or customer requirements. Executives will hopefully understand and give technology teams the mandate they need to work on remediation.

This top-down approach is usually less effective than the bottom-up approach because it essentially forces technology teams to do something without their inherent buy-in or will, with their primary goal remaining the delivery of the product’s next version or feature.

Budgeting for security remediation tools

In case you also need a budget for remediation tools, you might want to start by providing the reasons behind this procurement. If you’ve gotten this far in this blog, that means you probably already have some detection tools, and the hard work and time spent on remediation are used to prioritize and remediate the vulnerabilities these tools are producing.

It doesn’t matter whether you need a tool to help you aggregate vulnerabilities into a single place, a tool to help with threat modeling to improve prioritization or to operationalize, orchestrate and automate the remediations themselves. The basis of your approach should be simply providing data on the effort that will be potentially saved by these tools vs. the spend required.

If that doesn’t add up, it might not be worth it for the organization to invest in that tool. For example, if your security team spends four days a month on prioritizing vulnerabilities and your fancy new threat modeling tool will save you two days out of these four, and will save the engineering team another two because half of the vulnerabilities won’t be seen as critical to fix anymore, you’ve just saved 4x $800 per day =$3200 x 12 = $38,400 per year in working hours because of your tool. But if the tool costs $50,000, you may have a problem justifying it. On the other hand, if your tool saves you $100K a year on remediation efforts, and it costs you $50K, you have a better chance of justifying it.

As with every calculation, this doesn’t take into consideration other factors including the fact that engineers may miss opportunities for development and production due to their focus on security issues, which is critical when considering ROI. Additionally, it eliminates any other security controls that may be implemented in order to prevent other types of breaches.

‍Other ways of approaching security remediation budgeting

Using a combination of the two approaches described above will help you make a stronger case, but it might be harder to explain and take longer to prepare.

It may also be the case that while security has the responsibility for remediation, the tools and budgets involved are not your decision. This is where you might need to be creative and utilize your relationship with the technological teams that hold the budget. Finding an engineering advocate for security is usually a helpful way to start these conversations with your tech counterparts.

Assess when and where the next budget plan is taking place in the technological team you work closely with, and try to use the organizational security policy as a foot in the door to state your case.

One way of communicating your needs can be along the lines of “security is another quality feature, hence it should be dealt with similarly to other product features”. You could match security criticality levels with the bug impact levels that are used in your organization, and that would also apply to contracts you may have with IT/software development providers.

Furthermore, you could help establish a similar approach to quality-testing in the development pipelines and make sure that the security-related tools are budgeted similarly to the quality-testing ones. Some of them may even be combined into one suite.

When it comes to security remediation and orchestration tools, demonstrating ROI + risk reduction should be easy to do if you quantify it correctly. Following the approaches above and combining them with a well-established demonstration of ROI should allow you to build the right case for the right stakeholders in your organization and get your remediation program up and running.

‍