Over the summer of 2023, I had the opportunity to present a talk at a few conferences, including Optiv’s Source Zero Con and at our booth at Black Hat. In the talk, titled, “Don't [You] Forget About [Me]… (or Forgotten Components of a Vulnerability Management Program),” I discussed different areas of a vulnerability management (VM) program that are often overlooked or forgotten entirely. Later, I started thinking about the subject matter differently. If I had to distill the content of the talk down to just three areas, I would focus on policy, organization, and reporting and metrics. Below you will find my suggestions on how an organization can enhance an existing vulnerability management program. This post assumes that your organization is already using or will soon use a vulnerability management platform, which could be from one of the big three vendors—Tenable, Qualys, or Rapid7—or from an open-source option such as OpenVAS.

Policy

Policy is the foundation of any program, including vulnerability management. At a minimum, a vulnerability management policy should establish the scope and frequency of vulnerability scans. It should also establish expected timelines for the remediation of discovered vulnerabilities.

Most importantly, however, a vulnerability management policy must be approved and supported by upper management. Leveraging this higher-level support can help ensure that IT support teams remediate vulnerabilities in a timeframe that meets established SLAs. When critical zero-day vulnerabilities such as Log4J and EternalBlue arise, it is especially important to shift priorities and to address immediate remediation needs.

Organization

Despite its criticality to an organization, vulnerability management teams sometimes get overlooked and undervalued for several reasons.

The first is insufficient staffing. Smaller organizations can probably get by with having a single person or a small handful of people dedicated to vulnerability management on a part-time basis. Past a certain point, though, an organization should have dedicated vulnerability management personnel. Unfortunately, figuring out exactly how many personnel are needed becomes more of an art than a science. A 20-person start-up doesn’t need 5 people dedicated to vulnerability management, but a large multi-national corporation probably needs more support.

Vulnerability management also gets overlooked because of skills gaps. A VM team should be staffed with people that have a cybersecurity background or mindset. This experience could be professional or even purely academic. What is important is that VM teammates can understand the risk of a particular vulnerability and communicate it to others within the company so that even non-technical people can understand. This communicated risk could include anything from misconfigurations, missing patches, or the XSS-alert-box-of-doom. If you already have an experienced team, adding a team member with lesser or no experience should not be a dealbreaker. Other teammates should be able to quickly and adequately onboard and train the person. However, if an organization is building a brand-new team from the ground up, starting with experienced personnel is a must.

Relatedly, a lack of training opportunities is a third reason that vulnerability management teams tend to get overlooked. When an organization buys a new VM platform, platform training is often included in the package so that the team can become familiar with the new tool. New team members should also receive platform training as soon as possible after joining the team. Sometimes, this could be the only training that they receive. Because cybersecurity threats and vulnerabilities are always changing, vulnerability management team members should receive annual training to keep their skills current. This is especially true when the scope of the VM program changes. If the organization transitions to using a cloud platform for the first time, then the VM team should receive platform-specific training. Similarly, if internally developed applications come into scope, then the team should receive training on application security testing methods.

While staffing, skills, and training gaps can minimize the integral value or effectiveness of a vulnerability management program, it is important to invest time and resources into setting up a VM team for success. After all, retaining talent and ensuring progressive skill development is key to building a reliable VM program.

Reporting and Metrics

At a minimum, an organization should have an idea of what kind of reports and metrics it wants from its vulnerability management program. These will change over time. As vulnerability scan results come in, and reports and metrics go out to the business, a metric that once seemed good may not be as helpful after a while. Similarly, asset owners may request that larger reports be split out to smaller ones if they later find the reports to be difficult to work with. Rarely will either remain unchanged through the life of the program.

Reports and metrics also need to be customized for the intended audience. Senior leadership interests will be different than the interests of the various infrastructure teams. Senior leadership is usually more concerned about high-level metrics and reports at the organizational level. Examples could include total vulnerabilities, mean-time-to-remediation, and various trends over time. Infrastructure teams usually prefer to see their team-specific details. Server teams want metrics and reports that show their performance. Desktop and networking teams are the same. But they also need to know specific vulnerability details, so they know what issue needs to be addressed on which hosts. Patching teams will also need to know what patches are missing on what hosts so they can push fixes to the appropriate hosts. Senior leadership, on the other hand, does not need such in-the-weeds information. The ability to customize metrics and reporting for different areas of the business are pivotal for a VM program’s organizational success and impact.

Conclusion

If your VM program could only focus on 3 areas, then policy, organization, and reporting and metrics are great places to start. Once these have been properly addressed, other areas of the program can then be tackled.