The Best Vulnerability Management Programs Incorporate These 3 Categories

In its simplest form, the charter for vulnerability management teams is to identify the cybersecurity risks in their business and do something about them. Making this a reality means identifying all security vulnerability instances — in code, containers, cloud, on-premises servers, or workstations — and mitigating or eliminating the threats that matter most to the business.

But how do you know if your vulnerability management program is actually addressing the highest-priority vulnerabilities?  If the scope of your security teams is siloed, the answer is easy: You don’t.

In my experience, the best vulnerability management programs are comprehensive — spanning multiple security programs from traditional on-premises infrastructure scanning to application security to cloud security and more. This ensures you are addressing — enterprise-wide — the greatest risks to the business.

This first post in our Practitioner’s Perspective series will provide an overview of the three most important categories your vulnerability management program should span — and why a siloed approach doesn’t work.

Vulnerability category #1: On-premises infrastructure

Vulnerability management teams have traditionally scanned on-prem infrastructure, and they should continue scanning these assets. However, modern vulnerability management incorporates more than just scanning infrastructure.

A siloed VM program leads to inconsistent enforcement and measurement of risk mitigation tactics. Critical risks found outside of on-prem infrastructure may not be prioritized when they should, which can lead to spending resources on the wrong things.

Using vulnerability scanners such as Qualys, Rapid7 or Tenable to scan hosts attached to an on-prem network featuring workstations, laptops, desktops, routers, switches, wireless access points, printers, etc., to find remote code execution vulnerabilities, vulnerabilities in encryption packages, and privilege escalation vulnerabilities should be familiar territory for vulnerability management teams, so we don’t need to dive further into that topic.

Once upon a time, vulnerability management might have focused exclusively on securing the organization’s on-prem infrastructure. Those days should be at (or near) an end. A modern vulnerability management program needs to do this and much more.

Vulnerability category #2: Applications

Vulnerability management programs need to consider application security findings. Software applications are the lifeblood of digital businesses, and security teams are applying more resources to protect them. Application security teams are constantly searching for security weaknesses within applications.

The best vulnerability management programs evaluate these findings holistically alongside other vulnerabilities (such as the infrastructure vulnerabilities mentioned above) to ensure teams are addressing the most critical risks across programs.

Application security scanners (as a category) identify a large number of findings for vulnerability management programs to prioritize. Traditional AppSec scanning tools such as SAST, DAST, IAST, SCA, and API security all produce security findings. Newer scanning tools, such as secret scanners, also are becoming mainstream and adding to the list of security findings. Additional security findings also are identified by penetration tests and bug bounty programs. Across all these tools, scanners might detect OWASP Top 10 violations, vulnerability dependencies (e.g., Log4J), and hardcoded secrets in plaintext.

These tools rank the severity of their findings from the tool’s perspective and commonly rank all classes of vulnerabilities the same. It’s not uncommon when a “critical” finding from these tools (e.g., XSS is always critical) turns out not to be a critical risk to your business once the vulnerability management team enriches the tool’s findings with business context and prioritizes them alongside the findings of other security programs.

And that brings us to the final category we’ll examine in this post, the cloud.

Vulnerability category #3: Cloud

Vulnerability management programs must consider cloud security findings.

While continuing their digital transformations, most businesses have greatly expanded their cloud infrastructure footprint. Like application security teams, cloud security teams constantly work to ensure they find all critical cloud risks in their infrastructure.

Cloud assets include storage (e.g., S3 buckets), compute (e.g., EC2 instances), containers, and more. It doesn’t matter if your infrastructure-as-a-service provider is Amazon Web Services, Google Cloud Platform, Microsoft Azure, or any other; each platform has similar components that can contain vulnerabilities or be subject to dangerous misconfigurations.

Cloud security teams use many technologies to find security vulnerabilities across these assets — including cloud security posture management (CSPM) tools, container scanners, and virtual machine scanning.

Cloud misconfigurations, in particular, can carry as much, if not more, risk than a traditional security vulnerability. Your team should treat them like any other vulnerability identified by infrastructure or AppSec scanners. Some examples include public S3 buckets that should not be public, security groups that allow all ports to be open to the world, or IAM users with keys that have not been rotated.

As I stated previously, the severity a cloud security tool assigns to a vulnerability or misconfiguration does not mean it is a critical risk for your business. After your vulnerability management team enriches the tool’s findings with business context and prioritizes them in conjunction with the findings of other tools, it’s not unusual for the team to discover that what a tool flagged as a critical vulnerability is less severe or protected by compensating controls.

Why siloed vulnerability management fails

When AppSec and cloud findings are handled outside of an established vulnerability management program, the following problems are likely to occur:

• Remediation occurs out of band. This undermines the prioritization established by the vulnerability management team.
• Needed remediation doesn’t happen. Vulnerability management teams can’t follow up to ensure remediation for issues they don’t know exist.
• The IT operations and development teams both lose trust in security. Without an authoritative voice that spans security programs, it’s too easy for unclear priorities to filter down to the teams tasked with addressing security issues.

There has been an exponential increase in the ways organizations are breached. It’s the job of your vulnerability management team to contemplate these growing challenges so you can reduce your organization’s breach risk even as your attack surface continues to expand.

Modern vulnerability management is about prioritizing the risks that pose the most significant threat to the business. You must look beyond only vulnerabilities found by on-premises infrastructure scans and also consider findings from AppSec and cloud tools.

The most advanced — and successful — teams go beyond these three categories, but every team needs a starting point. If your vulnerability management program isn’t evaluating findings across these three categories, start now.

In my next post, I’ll share my thoughts on the importance of using the vulnerability data you already have to level up your program.

_________________________

Want more practitioner perspectives? Watch our recent webinar Reframing Vulnerability Management. It features Ravi alongside fellow vulnerability management experts Martin Karel, global security and vulnerability management product lead for Nestlé, and Steve Hawkins, director of security architecture & engineering for Cambia Health.