A Vulnerability Scanner Is Not a Vulnerability Management Program
As we move into CIS Control 7, Continuous Vulnerability Management, we’re going to spend several weeks discussing how organizations identify and address weaknesses in their technology environments. We begin with Safeguard 7.1: Establish and Maintain a Vulnerability Management Process.
That wording matters. This safeguard isn’t asking whether you own a scanning tool or install patches. It’s asking whether you have a documented process that explains how vulnerability management is supposed to work across the organization.
The tool is not the program
Vulnerability management is often reduced to a technical activity. Someone runs a scan, receives a report containing hundreds or thousands of findings, and sends it to the people responsible for maintaining the affected systems. At that point, everyone can say the scan was completed.
That doesn’t necessarily mean the vulnerabilities are being managed.
A scanner can tell you that a weakness may exist. It can’t decide which systems are within scope, who’s responsible for reviewing the results, or how findings should be tracked. Those decisions require a process.
The same is true of patching. Installing updates is an important part of vulnerability management, but it isn’t the entire program. Vulnerabilities may also result from unsupported software, insecure configurations, exposed services, or technology implemented without an appropriate understanding of the risk.
The process provides the structure connecting those activities. It tells the organization how weaknesses are identified, who’s responsible for them, and how they move from discovery into review and action.
You can’t manage vulnerabilities on assets you don’t know about
Like several of the controls we’ve already discussed, vulnerability management depends on an accurate inventory.
You can’t assess a laptop, server, network device, cloud workload, or application that no one knows exists. The same problem applies when an asset is known but falls outside the normal management process. A server may have been installed for a temporary project. A business unit may have purchased a cloud application without involving IT. A vendor may manage equipment on the organization’s behalf.
A documented process should establish what types of enterprise assets are included and how newly added or significantly changed systems enter the program. It should also account for assets managed by service providers. Outsourcing the administration of a system doesn’t eliminate the organization’s responsibility for understanding the vulnerabilities associated with it.
Ownership has to be clear
One of the first questions I ask when reviewing a vulnerability management program is who owns it. The answer is often less clear than people expect.
Security may operate the scanning platform. An MSP may produce the reports. Internal IT may maintain the servers and workstations. Application owners may be responsible for business systems, while a separate team manages cloud infrastructure. None of those groups can manage the process effectively if their responsibilities begin and end in different places.
The process should identify who coordinates the program, who receives vulnerability information, who’s responsible for affected assets, and how issues are tracked.
This doesn’t require every organization to build a large vulnerability management department. In a smaller company, one person or service provider may perform several functions. The important part is that responsibilities are understood and documented rather than assumed.
Finding vulnerabilities is an ongoing activity
The word “continuous” in the title of Control 7 is important. New vulnerabilities are disclosed regularly, environments change, and assets that were reasonably secure yesterday may be exposed to a newly discovered weakness today.
That doesn’t mean every organization must scan every asset every minute. It means vulnerability management can’t be treated as a once-a-year compliance exercise.
A useful process should explain where the organization receives vulnerability information and how it’s evaluated. Sources may include vendors, security advisories, government and industry notifications, service providers, and vulnerability management tools. The process should ensure relevant information reaches someone who can determine whether it affects the organization.
The documentation itself also needs attention. CIS requires the process to be reviewed at least annually and whenever significant changes could affect it. A cloud migration, acquisition, new service provider, or meaningful change in the technology environment may make an existing process incomplete before the next scheduled review.
Reports are not the outcome
One of the easiest mistakes to make is measuring the program by the number of scans completed or reports generated. Those activities show that something happened, but they don’t prove the process is working.
I’ve encountered this more than once during risk assessments and audits. I ask about the organization’s vulnerability management program, and someone proudly opens a vulnerability scan to show me the work they’ve completed. The report is untouched. No notes. No assignments. No evidence that anyone evaluated the findings or addressed the vulnerabilities. They completed the scan, but the results went no further.
A clean report isn’t evidence of a clean environment. Sometimes it’s evidence that nobody has done anything with it.
Findings shouldn’t disappear into an inbox or remain buried in a portal that no one regularly reviews. The organization should be able to show where vulnerability information comes from, who receives it, and how it’s passed into the remediation process.
The specific decisions about prioritization, timelines, patching, scanning frequency, and remediation belong to the safeguards that follow. Safeguard 7.1 establishes the foundation those activities depend on. Without it, an organization may own several useful tools and still lack a repeatable way to manage the risks they identify.
A place to start
If your organization doesn’t have a documented vulnerability management process, begin by describing how the work happens today.
Identify the assets and environments the process is expected to cover. Document who coordinates vulnerability management, where vulnerability information comes from, who reviews it, and how findings are tracked and handed to the people responsible for affected systems. Include service providers and cloud environments rather than assuming they’re handled somewhere else.
Then compare the documented process to what actually happens. A policy describing an idealized workflow no one follows isn’t particularly useful.
Vulnerability management isn’t a scanner, a patching tool, or a monthly report. Those may support the program, but the program is the repeatable process that connects them. Before an organization can decide how quickly to fix a vulnerability, it first needs a reliable way to identify it, understand where it exists, assign responsibility, and make sure it doesn’t get lost.
