Vulnerabilities Cost Estimate Approach

The possible economic impacts of data breach by inefficient vulnerability fix program

Juan Carlos Lujan Duque
Globant
5 min readJun 27, 2024

--

Vulnerability and data breach - Image from Google Search

Rapid vulnerability exploitation is an issue to consider when a vulnerability fix is not working fast and agile. Attacks by state actors are becoming more sophisticated and quick-moving. According to the Microsoft Threat Intelligence Center, organizations must follow the changes of these actors and change their barriers simultaneously, as confirmed in Microsoft’s Digital Defense Report of 2022. The State of Cybercrime and chapter Nation-State Threats explain that the disclosure timeline should start by disclosing the vulnerability, using it in the wild within 14 days, submit a proof of concept on GitHub within 60 days. Then, negotiate the vulnerability and availability of scanning tools within 120 days, at each stage scale and risk increase.

Vulnerability prioritization and remediation is a great challenge that many organizations face today because of evolving and rapidly growing vulnerability exploitation. Companies must fully understand when to address vulnerabilities to minimize the risk of data breaches. They must be aware of the costs associated with these vulnerabilities and the importance of timely repairs in their vulnerability program.

Concerns About Rapid And Growing Vulnerability Exploitation

The following chart shows that, on average, an attack takes just 14 days to occur after a vulnerability is disclosed. This view looks at the number of systems vulnerable to a specific vulnerability active on the Internet since its initial deployment, with an updated vulnerability timeline:

Speed and scale of vulnerability commoditization — Image from Microsoft

Key actions report highlights:

  • Be sure to patch zero-day vulnerabilities at release. Don’t wait to implement your patch management cycle.
  • Document all software assets and company resources to identify issues and quickly decide when to patch.

There is also an issue to review with Planning Report 02–3, called The economic impacts of inadequate infrastructure for software testing, from the Program Office of Strategic Planning and Economic Analysis Group from NIST. It was prepared by Gregory Tassey, Ph.D., from a conceptual economic model standpoint that says, “Test early, test often”, as the mantra of experienced programmers. When defects are detected early in the software development process before they are allowed to migrate to the next stage, fewer remain in the shipped product. They are less costly to correct than if they are discovered later in the process. For example, if a bug is identified and fixed during the unit testing stage, the impact is usually limited to the specific unit or component being tested. The bug can be isolated and resolved within a smaller codebase, making it relatively easier and less time-consuming to fix it.

An important reason why it is more costly to correct bugs the longer they are left undetected is that additional code is written around the code containing the bug. The task of unraveling mounting layers of code becomes increasingly costly the further downstream the error is detected. If the location of bugs can be made more precise, both the calendar time and resource requirements of testing can be reduced.

There are two variables to consider when we are developing a system that could have a positive perspective: time and cost. Testing our system early is a good way to identify and rectify any potential problems before they become more time-consuming and costly to fix.

Companies like Sysdig, who provide cloud security and observability powered by runtime insights, said “Encourage the shift-left approach when applying security in Vulnerability Management. This means that the further to the left we implement Vulnerability Management, the better.

Further to the left…?

With left, we mean sooner in the software’s lifecycle. We identify multiple phases, from the developer’s machine (left-most) to running in production (right-most side)”. This image will bring you the full picture of the different phases:

Container phases — Image from Sysdig

According to OWASP, “DevOps is empowering organizations to deploy changes to production environments at blazing rates. Since the time to deliver is a critical feature during this process, the main question for a security person is “How can I secure this process?” or “How much of our deliverable products are secure?”. In this regard, we can embed some security-related steps throughout our DevOps process to perform some automated tests. Considering the DevSecOps (or secure DevOps) culture can help us promote the shift-left security strategy in our company, at least in the tech department.

A simple definition of shift-left security strategy according to OWASP is, “The shift-left security strategy is a way or solution to embedding security as a part of our development process and to consider security from the inception steps of application or system design. In other words, security is responsible for everyone who works in the software development and operating process”. This approach can help to discover countless vulnerabilities in the early phase of SDLC and to solve and fix most of the vulnerabilities.

DevSecOps — Image from OWASP

Conclusion

In summary, diving deeper into the cost and time savings from taking a prevention-first and shift-left approach to cybersecurity could show us positive economic impacts when testing and fixing vulnerabilities early.

Early testing helps to mitigate the risk of bugs spreading throughout the system, reduces the complexity of bug fixes, and minimizes the overall impact on the development timeline and budget.

The approach from reactive to proactive posture in the remediation of vulnerabilities is not only a matter of strengthening the technology so that it resists threats and breaches; it is also a purely economic issue.

References

--

--