Many organizations have vulnerability management tools in place like scanners, threat feeds, and patch managers, but don’t have the right people and supportive processes to complete the puzzle.
That’s why we welcomed one of our industry partners, Chad Truhn from BRTRC to chat with us about what it takes to build a successful vulnerability management program. Chad talked about the common challenges he sees among organizations, both big and small and shared some tips about where you should start if you’re seeing the same challenges. Paired with the industry insight of Sales Executive, Nevra Ledwon, we had a great (non-salesy) discussion.
In case you missed it, here’s what you should know:
1. Set an intention that justifies your vulnerability management program
You should start by setting an intention or goal for your program. Typically, this intention will be twofold: to minimize vulnerability-related risks and be able to communicate your results to the rest of your organization. Why? Because your program is only as successful as the results you’re able to share and the reasoning behind the decisions you made to remediate — or not remediate — vulnerabilities.
A good way to do this is by mocking up your dream dashboards. Think about those urgent, burning questions your executives come to you with, like when WannaCry or Not Petya hit the news and they wanted to know how vulnerable the organization is and/or why the related vulnerabilities may not have been patched right away. Use this knowledge of what they care about to mock up a “dream dashboard” and use it in your pitch to increase funding for your program. Once you come up with something that leadership is excited about, you can find the right tools that will help you get that data.
For many organizations, the dream dashboard includes a way of tracking your organization’s risk posture. It will also help to explain your remediation decisions, especially when an attack or breach occurs so you can answer the question “Why didn’t you patch this vulnerability in time?”
You might produce an audit trail showing the lifecycle of the vulnerability with specific details about when it was created, why it wasn’t the highest priority at the time, and which stakeholders were involved in the decision-making or approvals to delay patching the vulnerability (i.e. when the patch may break something else).
Imagine you had easy access to this type of reporting. It would be much easier to get the leadership buy-in and budget that you need to sustain a successful vulnerability management program.
2. Vulnerability counts can be a vanity metric without context
Both Nevra and Chad see a common trend where companies focus solely on vulnerability counts to track how they are doing in minimizing risk. Typically, this number will increase over time as scanners become more sensitive and you have finite resources available. This may lead you to the assumption that your overall risk is also going up. The same is true in the opposite scenario; you may think you’re doing a good job of decreasing risk if you see the number of vulnerabilities going down. However, that’s not necessarily the case.
Simply looking at vulnerability counts doesn’t allow you to track progress against your objective to reduce overall risk. You may not actually be optimizing the use of your limited resources to ensure the greatest risk reduction over time.
For example, if you add risk scores to these increasing vulnerabilities, you may find that even though vulnerability counts are going up, the total risk might be going down. Your IT team may have recently tackled a giant vulnerability on a critical system that they’ve been trying to patch for weeks or maybe even months. But if you only looked at the number, you wouldn’t have seen how critical this remediation was and how it played a role in reducing your overall risk.
By adding context to your vulnerabilities, you can get a better sense of where the riskiest vulnerabilities are for your specific organization, allowing you to make better remediation decisions.
3. Classify your assets to determine which ones are in scope
Another common theme seen among organizations is the lack of asset classification. We know it can be a very daunting task to classify your entire inventory of assets, but it’s also one of the most important pieces in helping your IT team prioritize vulnerabilities.
The key here is that you just need to start somewhere. While every IT Security team may dream of having a CIA-type of classification, a good place to start is with a simple binary classification. Identify what your core business data is, what systems this data is stored on, who has access to these systems, and whether you can limit this access. From there, you can work in a phased approach to tag these systems through a simple yes/no classification based on criteria such as business criticality or decommissioned status.
With a more defined scope, your IT team can be more efficient in optimizing its limited resources and prioritizing appropriately to remediate the RIGHT risks.
4. Map out your top workflow processes
The success of your vulnerability management program can only go as far as the processes you have defined to guide your teams. Some of the most common processes that should be mapped out include:
- Policy Definition: Map out how vulnerability management policies (i.e. remediation SLAs by severity, exceptions, and escalations) are defined, updated, and approved. Is there a process around when these policies should be revisited and optimized?
- Vulnerability Prioritization and Assignment: Define how you prioritize remediation activities and assign tickets to your IT team. Do you have a tool that automates this process and someone who manages this tool?
- Remediation Process: Define what remediation looks like and what the SLAs are that you’re tracking. Also go one step further to determine what happens when they are missed and who the issue should be escalated to.
- Exception Management: Sometimes you need to define vulnerability exceptions to avoid creating larger problems on your systems. You should define what this exception request and approval process looks like.
Make sure not to create these processes in silos; it’s important to create them in collaboration with all involved stakeholders so that you have buy-in up front and everyone is aligned on the objectives for success.
5. Automate as many processes as possible
The more processes you can automate through tools and defined processes, the more time your team is given to think strategically about how to optimize your vulnerability management program. The typical functions that many organizations automate upfront include reporting, vulnerability scanning, data aggregation and correlation, workflow management, risk scoring, and ticket generation.
As your processes become more defined, and your program gains momentum (typically with more budget), you can automate more manual processes and boost IT efficiency.
Find out if you have the right people, processes, and tools to support and sustain a successful vulnerability management program.