Vulnerability prioritization is only the beginning
To date, most technology solutions focused on vulnerability management have focused on the prioritization of risks. That usually took the shape of some risk-ranking structure displayed in a table with links out to the CVEs and other advisory or threat intelligence information.
This is a necessary step, but it’s insufficient. While knowing which vulnerabilities are the most pressing is nice, the desired outcome is ensuring those vulnerabilities are addressed and mitigated as quickly as possible. While lots of security metrics focus on that outcome, the journey from prioritization to outcome remains opaque and poorly understood. The lack of visibility makes it hard to understand where bottlenecks may lie and how the process could be improved.
Why the security journey is so opaque
Most CISOs and their teams have clear metrics to assess progress on handling vulnerabilities, such as mean-time-to-detect, mean-time-to-response, percentage of critical vulnerabilities unpatched, time to patch, and more.
In theory, tracking these metrics should drive progress because teams are aware that is how they will be judged. However, the metrics alone cannot tell the complete story, nor can they optimize the security efficiency of any team, because:
- Metrics can be gamed
- Metrics can’t tell you which problems were solved and how
For example, a security team may modify the vulnerability policy to add exceptions but neglect to note that the vulnerability was never fixed even though the alert was silenced. This could result in new vulnerabilities that match that policy to also get ignored and impact overall security.
Metrics can provide a false sense of security if there are outliers who avoid the patch or otherwise hard to reach devices remain unpatched for extended periods. If metrics improve, without (re)viewing the process we cannot judge whether the improvements came through brute force and effort, through better systems, or better process design.
Why transparency of the security process is becoming more critical
Scrutiny of cybersecurity processes and performance is ratcheting up due to the dual hammers of increased regulatory scrutiny and the brutal trend of highly damaging attacks.
The US Securities and Exchange Commission, the European Union, the US Department of Defense, the British National Government, and the US Cybersecurity and Infrastructure Agency have all put or are putting in place significantly more stringent requirements for CISOs and their teams.
Both the SEC and CISA have moved to push accountability to the Board of Directors and the C-Suite. This means that metrics alone are no longer sufficient for CISOs that want to provide full transparency. Process transparency has become just as critical to validate KPIs and allow auditors and the government to peer inside what were formerly security process “bottlenecks”.
What security bottlenecks?
These bottlenecks are highly variable, human-centric processes, such as opening or closing a Jira ticket, back and forth commenting in a Slack thread, pushing a pull request on GitHub, or running a CI/CD pipeline to test and redeploy software after a patch. All can have human path dependencies, injecting uncertainty and variability.
For example, a Slack thread may contain critical decision making on who is going to push a patch and when. If the thread shows an engineer that is struggling to get the patch to pass unit tests, that could manifest in insufficient testing which might result in service interruptions when an improperly tested patch is deployed and even further delays in patch landings on live systems.
A Jira ticket may be reassigned from one security analyst or engineer to another for reasons such as someone going on vacation or someone not having the right expertise. This might add delay to remediation, which increases the exposure window. As more advanced attackers move faster and faster to exploit newly disclosed vulnerabilities, closing the exposure window is paramount.
Even when an organization has successfully implemented a security data mesh, rarely is process data included. This results in lack of context and visibility into human decisions.
Illuminating bottlenecks with a security process fabric
Security process mapping involves creating visual representations of workflows to understand and optimize security operations. These diagrams, often flowcharts, outline the steps needed to complete tasks, revealing inefficiencies and inconsistencies.
A security process fabric is all vulnerability data fabric plus important process context. This means not only visualizing process maps but also showing contextualized metadata from all the tools that are part of the process so teams can act quickly and make smarter decisions on what to do. By using a security process fabric, organizations can see exactly who did what, when, and then start to ask the right questions about why. Teams can also test hypotheses around processes.
For vulnerability management, the ability to visualize and track data on process execution changes prioritization from binary measurements (patched/unpatched) to a time-series that can be parsed and measured. This method transforms complex security process data into actionable insights, enhancing both efficiency and ROI on security investments.
Specifically in vulnerability management using a vulnerability scanner such as Wiz, a code repo like GitHub or GitLab, and a ticketing system like ServiceNow or Jira, mapping can clarify when a vulnerability is marked high priority, when a ticket is created, who owns the ticket, what activity is taken to resolve the ticket in GitHub (or in the CI/CD), and when the ticket is closed and by whom.
Over time, the security process fabric provides a longitudinal view of security processes. This will allow CISOs to develop and track a new set of metrics that will measure process efficiency and progress in making processes more efficient.
Security has always been a process but the lack of programmatic capture of processes has made them subject to recall error and high variability, generating security bottlenecks. Adding process mapping and incorporating process data plus contextual metadata that explains who, what, and why into a security process fabric finally closes the loop on security transparency.