Vulnerability management is a discipline that many organizations struggle with due to one simple factor: complexity. Today, organizations manage environments with technology that changes at an ever-increasing speed while relying upon legacy systems to support key business processes.
In response to this complexity challenge, cybersecurity professionals continue to create new vulnerability management processes to manage the problem which includes vulnerability scanning, configuration management databases (CMDB), common vulnerabilities and exposure (CVE) IDs, policies, patch-by dates, and an endless variety of reports. In short, cybersecurity professionals have made a complicated problem even more complicated. We (cybersecurity professionals) have been doing it all wrong. It is important for CIOs and CISOs to acknowledge this truth as we explore methods that can be used to simplify the vulnerability management solution and create a greater chance for success in our organizations.
Abandon the pursuit of perfection
When it comes to problem solving within the vulnerability management space, there are any number of approaches. As technologists, we often don’t split hairs on our approach to manage vulnerabilities, as much as we obsess over perfection in our pursuit of answers and too often, this pursuit of perfection leads to wasted time. We have found that the most efficient approach during problem solving is a “progress over perfection” mentality. This perspective is most commonly achieved by beginning with what we know to be true in any given situation. Whether this is leveraging corporate data stores, making educated assumptions based upon known cybersecurity vulnerabilities and their characteristics, or more simply managing the amount of ambiguity for a given process, progress should always be the priority. The sooner that the “pursuit of perfection” mindset is abandoned, the sooner project teams will make progress toward determining the solution.
Create effective vulnerability remediation dates
A common challenge between IT and the business that often arises within vulnerability management programs is creating a successful remediation process that is realistic for all stakeholders. Implementing a successful vulnerability remediation process begins with understanding how IT works and working within their framework of current capabilities. When the business continues to enforce unrealistic expectations, nothing is accomplished. Instead, understanding and developing a process for the current state of the vulnerability management program, while subsequently forecasting expectations for a future state is often the best practice. Communicating risk in terms the business understands and aligning business expectations to how IT works is the key to setting successful parameters for vulnerability remediation timelines.
Identify the real problem
Vulnerability management programs often adopt the mantra of “fix it and forget it” without properly vetting and exploring the root cause of the issue. Some may refer to this as the “whack-a-mole” approach, which is generally adopted when the objective of a vulnerability management solution is to eliminate the backlog of missing patches. The problem with this approach, if not caught early on, is that known vulnerabilities will consistently be remediated (or “fixed”) without understanding the context for systematic or program-level issues, which allows the frequency of these issues to persist. Our solution to this approach is simple: Organizations should dedicate resources to perform root cause analysis for their most critical issues. This analysis can be conducted in a variety of ways but usually begins by simply asking “why.” Until adequate time is invested to conduct root cause analysis at the program level, the true cause of the most persistent critical vulnerability types will remain unknown.
Remain consistent in the communication of program results
As information security practitioners, communicating vulnerability management program results can be a nerve-wracking process if done without the appropriate context and direction. For example, communicating results to the wrong owners can lead to confusion that results in less efficient reporting processes. Luckily, many of these issues can be solved through consistency and transparency. Communication of vulnerability management program results should be consistent to provide metrics for trending and progress over time. Program performance results should also be transparent with the intended audience to highlight wins and shortcomings within the program. Eliciting feedback is important to confirm understanding when these vulnerability management reporting processes are getting started. Overall, encouraging information security practitioners to articulate known vulnerabilities in a way that helps the intended audience derive value out of the reporting process and cut down confusion should always be our objective.
Tailor metrics to executive management
The most important factor to consider when determining metrics that will be used to diagnose the health of a vulnerability management program is polarization. Metrics should polarize the audience to either provide enough comfort to stay seated or enough alarm to get out of their chairs. This is most commonly seen in practice by defining thresholds for program metrics that best answers the question “how bad is it?” In addition, when it comes to reporting to executive management, metrics need to make sense to non-IT personnel. The complexity pitfall can appear when it comes to tailoring metrics as well. When operating effectively, program metrics should highlight the largest or most important problem areas within the organization. Metrics are meant to be used as the telemetry of a vulnerability management program. Thus, tying program metrics to organizational goals and also changing metrics when goals are achieved is extremely important to overall success. Risks will continue to evolve over time and our metrics must adapt to remain in line with those changes. Overall, vulnerability management metrics should be clear and direct to help the organization understand its current security posture.
The question that follows this simple and effective guidance is often, “what now?” Implementing the above takeaways into a large and complex organizational program starts with communication. More specifically, the first step is communicating with stakeholders about program challenges and the vision and approach to resolving conflict and reducing risk. Change should start small while leveraging organizational data and enriched vulnerability management reporting. Near-term examples to realizing these changes include the development and refreshment of vulnerability management processes that align with IT and pairing that with report development that answers simple questions. As security professionals, we must always hold ourselves accountable for real change to occur.