It is a fact that vulnerability management is not equipped for modern DevOps environments. While there’s no shortage of new CVE discoveries year over year, the majority of the stack is not covered by CVEs, as most AppSec vulnerabilities are never reported. Rickard Carlsson, co-Founder and CEO of Detectify, shares why vulnerability management strategies and tools need to evolve for the modern tech stack to provide smarter security and effective threat management.
The modern tech stack is extremely diverse and creates an attack surface that is very difficult to manage. With organizations going fully serverless and leveraging multicloud, security teams have been tasked with defending an expanding, complex surface area and found out the hard way that many popular, proposed solutions don’t get the job done. There is now a clash between established methods that have been part of ISMSs for a long time, including vulnerability management, and what is needed to protect a more modern stack, such as DevSecOps. Security teams that rely on CVE disclosure processes and CVSS as rating methods for application security soon figure out that it doesn’t really work for modern stacks.
So, why isn’t vulnerability management up to the job?
1. The CVSS Rating Method Is Flawed for AppSec
Most cybersecurity teams use the Common Vulnerability Scoring System (CVSS) to prioritize vulnerability management operations. A CVSS score is a value from zero and ten that demonstrates how easily a vulnerability can be exploited and the potential impact of a successful exploit. It is calculated using three metrics groups: Base, Temporal, and Environmental, which look at the various characteristics of a vulnerability, such as its impact and environmental durability through time. This public scoring system has become the industry standard for rating vulnerabilities.
However, while the CVSS has its uses, it was never meant to be used for vulnerability prioritization for application security as it doesn’t provide enough granular separation of attacks. The model typically assigns a basic score to a vulnerability within two weeks of its discovery, but these values remain static and are seldom revisited after this first evaluation, regardless of changes in the threat landscape or additional research.
So why do many security teams still rely on it? The answer is simple – it was what they had. As vulnerabilities became more common and security teams found themselves unable to fix every issue as it occurred, they needed a rating system of some kind to help them prioritize. They adopted CVSS as a prioritization metric because it was all they had at the time. However, because CVSS was never intended for this purpose, security teams are increasingly wasting time and resources remediating vulnerabilities that represent little to no risk and failing to prioritize others that may represent a great deal of risk to the business.
See More: Unlocking a More Secure Cloud: An Introduction to Security as Code (SaC)
2. CVEs Have Poor Coverage
Application vulnerabilities are consistently the most common threat vector targeted by attackers. According to Verizon’s 2022 Data Breach Investigations Report, the web application was the top cyberattack vector in 2021, surpassing email as the most common attack vector and accounting for roughly 70% of security incidents. But, according to CVE scoring, AppSec vulnerabilities barely exist. If you look at the top CVEs, the most severe vulnerabilities are operating systems, with applications only appearing on the list a few times. This is because a large number of modern cloud/AppSec issues come from misconfigurations, combinations of tools, or developer mistakes that are not covered by CVEs.
Using CVEs for vulnerability management means that the AppSec layer is barely covered, despite the fact that it poses a significant risk. A single web application could be made up of dozens of technologies. Identifying these technologies and where they are being hosted requires a significant investment of time, which security teams do not have. Many of the vulnerabilities found in these technologies never receive a CVE, which exacerbates the challenge of prioritizing these vulnerabilities. As organizations grow more digital and increasingly direct-to-consumer, they must develop a new way to detect application-based vulnerabilities without relying on vulnerability management practices that base prioritization on CVE scores.
3. Patching Is a Slow Process
Even when vulnerabilities are discovered using vulnerability management, many still go unpatched for long periods of time. According to Trustwave’s 2021 Spiderlabs Telemetry Report, despite the high severity of some of the security flaws that were discovered, more than 50% of the servers were unprotected for weeks and even months after an update had been released.
In PCI DSS requirements, you can have a critical vulnerability in your infrastructure for a month before you have to patch it and still remain PCI compliant. With how fast the business world moves today and how much the threat landscape changes, this lag in patching represents an enormous amount of risk to the organization. Take the 2017 Equifax breach, for example. Equifax neglected to patch a basic vulnerability, despite having protocols in place to ensure such patches were delivered as soon as possible. Massive volumes of data were exfiltrated because someone failed to renew a security certificate and didn’t act fast enough, causing one of the biggest breaches in US history. This is an extreme example but demonstrates how vulnerability management procedures aren’t equipped for the modern tech landscape.
4. The Industry Is Dominated by Incumbent Legacy Players
The vulnerability management sector is dominated by a handful of incumbent players who are slow to innovate. Despite their dominance in the industry, these companies have not innovated their solutions in the last decade despite seismic shifts in the threat landscape. Furthermore, the standard ISMS frameworks are equally as reluctant to change and innovate due to the slow pace of the compliance sector.
Traditional security teams that rely on one-size-fits-all vulnerability management vendors are missing out on the most serious vulnerabilities because they can only choose from a menu of pre-set requirements that often do not apply to their business. They are hampered by an inability to implement their own custom policies for corporate assets based on the business context. Because policy violations can easily expose unprotected assets, the proactive resolution of policy violations is frequently a more effective method of vulnerability management than reactively hunting for vulnerabilities.
What Is the Modern Approach to Vulnerability Management?
Clearly, vulnerability management no longer works for the modern AppSec environment. Organizations regularly integrate security into the development stage and set lofty goals of achieving zero vulns; however, these are usually just vanity projects and don’t effectively remediate the vulns that represent the most risk.
Instead, organizations should continuously test for vulnerabilities in production environments without relying on outdated vulnerability management practices, such as using CVE ranking to prioritize remediation. Continuously testing the attack surface with real payloads that not only identify active vulnerabilities but also highlight those that represent the most risk is a much more sensible strategy. This approach helps the organization maintain an attacker’s view of the attack surface, eliminating blind spots and enabling the swift prioritization and remediation of any issues.
Don’t get me wrong – there is still a place for vulnerability management, especially in terms of compliance, but organizations should not rely on it as their central strategy and refocus on the tools and strategies that will effectively protect their modern tech stack.
How can vulnerability management be improved by refocusing on tools and strategies adapted to a diverse DevOps environment? Share with us on Facebook, Twitter, and LinkedIn. We’d love to know what you think!
Image Source: Shutterstock
