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:
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:
Following the process above, use the data you collected to calculate your potential budgetary needs. Example calculations may look like this:
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.
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.
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.
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 (https://owaspsamm.org/assessment/). 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.
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.
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.
