Vulnerability management continues to be a major topic in cybersecurity. It’s a fundamental CIS control, and as with most things in cybersecurity, it’s only getting more complicated as technology grows in complexity.
Vulnerability management used to revolve around the relative state of patches on some set of devices in an environment. This could have been servers, workstations, or some combination of the two. Today, vulnerabilities can come in from container images, open-source library dependencies, penetration test findings, cloud misconfigurations, and, of course, missing patches. By no means complete, that list is likely only going to get longer as technology evolves.
Personally, I am not a fan of recommending specific tools. These things change too quickly and everybody’s environment is unique. Instead, I want to offer a general way to think about finding the right tools for your environment, so here are four important factors to consider.
1. Flexibility
Oftentimes, vendor solutions will have flashy user interfaces to go with the underlying core features. Dashboards and vendor-specific visualizations can be helpful in some cases, especially if you’re working in a smaller environment. Sometimes things being presented exactly as the solution’s designers intended is helpful and drives the most value.
There are times, though, when teams will need the flexibility to modify what’s visualized within a tool and build on it. Sometimes this means new dashboards and sometimes it means workflows.
How will your team use the solution? How will your team’s primary stakeholders use it, if at all? Is flexibility going to get in the way or make you more efficient?
2. Exportability
Similar to the above comments on flexibility, there are times when it’s necessary to export some or all of the data out of a solution and put it into something else. This is common for reporting use cases where dashboards are built on top of some kind of data warehouse or data lake.
Vendor solutions that lock you into their ecosystem and don’t expose their data place limits on the way you use their technology. Limiting complexity can make things more streamlined and easy to use, though. So, there are benefits to a more restrictive ecosystem in the right contexts.
How do you intend to integrate this solution more widely? If you need to export data, what is it and why? Who’s going to maintain things once the data is exported, and who will be responsible for doing that work?
3. Integrations
This one is obvious. The tools you’re purchasing need to align with the tools you already have (or intend to purchase). If there are gaps in integration support here, you’ll have gaps in the value derived from a vulnerability management solution.
What’s the coverage of integrations with our current and intended future security stack? If something is missing, could we build it ourselves or would the vendor do it?
4. “Fix” or Respond Capabilities
Some vulnerability management solutions make an attempt at bridging the gap into remediation efforts. This could look like integrating into a CI/CD process and blocking builds based on vulnerability conditions. This could also mean integration with a cloud-based environment to auto-remediate an insecure configuration.
There are also solutions that can handle the patching of devices and so much more. These solutions can be very powerful, but they require full and complete buy-in from those who really own the part of the environment where such actions would take place.
Who owns the part of the environment where the actions would take place? What are the relationships that security has with those teams like? If something goes wrong and the solution breaks legitimate functionality, who owns that, and what’s our plan? Is the risk of internal friction worth the reward of faster remediation?
Concluding Thoughts on Vulnerability Management Tools
There are a lot of dynamics between your security team and your organization that should influence the solutions chosen to support a strong vulnerability management capability. It’s important to evaluate context alongside capabilities while making a decision. Context cannot be captured in the random articles you might stumble across on an internet search; it must come through reflection and awareness of the situation in which you’re operating.
Want more cybersecurity insights? Visit the Cybersecurity channel:
