VRM Wishlist for 2019

At this time of the year, like any other year, the security industry goes back to reflect on itself and foresee future trends in what we call the “New Year predictions”. Most of the time these predictions are meaningless and serve as nothing more than a marketing tool. With this blog post I want to take a different path. Instead, I will summarize the trends and feature requests that I gathered during conversations with current and prospective customers regarding building a well-balanced and efficient vulnerability management program.

I realized that based on these conversations this list is not really a prediction for the New Year’s trends; it represents a wishlist for an improved, more effective approach to vulnerability management in the enterprise.

And with that, let’s begin with the current state of Vulnerability Management.

When we talk with enterprises having a developed vulnerability management program and we dig a bit further, we often discover that they only have a single security analyst running one or more vulnerability scanner. Typically, the analyst finds themselves overwhelmed with thousands of pages of vulnerabilities, that are insignificant (useless) or false positives. The problem is a low signal-to-noise ratio, with no lighthouse to navigate through this sea of vulnerabilities. Usually, security vulnerabilities are assigned an identifier (CVE ID) and a risk score (CVSS) between one and ten. Based on our analysis, many of the 100K+ vulnerabilities in the National Vulnerability Database (NVD) are ranked critical or high, making useful prioritization nearly impossible.

Moreover, organizations typically run network vulnerability scanners on their entire network infrastructure several times a month to detect newly released vulnerabilities, putting the infrastructure and network under continuous stress. Most of the time, network and system administrators are concerned about the availability of their network and systems because of the continuous vulnerability scanning pressure.

Vulnerability Scanning Goals

Based on customer feedback and conversations, there is a desire to focus a less on detecting more vulnerabilities and generating more data. Instead, the goal to spend more effort on prioritizing existing vulnerabilities. Instead of simply using CVSS score, most organizations have realized prioritization should be based more on exploit availability, targeted attacks and threat intelligence, social media interactions and patch availability.

My New Year prediction is that many organizations will still prioritize vulnerabilities based on CVSS score, though more mature organizations will start prioritizing vulnerabilities using other factors including threat intel, exploit availability and asset value, among others.

Security vulnerabilities are not all created equal. Moreover, not all enterprise assets have the same value in terms of the data stored in them and the business processes they support. Fixing vulnerabilities without focusing on the value of the asset affected by them is like spending limited security resources to protect an empty bank vault. The other problem in modern organizations is a lack of data classification and that asset inventories are not maintained and updated. Therefore, organizations are missing critical information needed to effectively prioritize vulnerabilities based on asset value, other than using some asset value classification used for business continuity / disaster recovery purposes. I also observed in my discussions with clients that enterprise CMDB systems are rarely updated or effectively maintained. Using these data sources to determine asset value is often not a viable option.

Asset Value Management Goals

Many organizations I spoke with in 2018 expressed a desire to begin taking asset and data value into consideration when calculating vulnerability priority. This was so that vulnerabilities affecting critical and infrastructure assets could be prioritized for remediation.

My New Year prediction is that asset value determination will still be coming from spreadsheets related to Business Continuity and Disaster Recovery (DR/BCP) efforts. Enterprise CMDB systems will still be waiting for the necessary polish and connectivity to integrate their data feeds into other enterprise security systems.

Most of the vulnerability prioritization in modern vulnerability management systems happens via correlation between vulnerability CVE ID and public exploit availability, and through inclusion of exploits in public databases such the Exploit-DB and others. However, the code included in these public databases are often not working exploits, but ‘Proof of Concept’ code that needs additional development  to be weaponized for targeted attacks. For predictive purposes – to predict the probability that a specific vulnerability could be used in targeted attacks – using the inclusion of certain vulnerabilities in public exploit databases is not enough: the target of the prediction should be the probability that certain vulnerabilities could be used in targeted attacks and malware in the wild.

Vulnerability Attack Prediction Goals

I wish that in the New Year vulnerability management program could evolve to include prediction of real-world attacks using certain vulnerabilities. This would allow organizations to jump-start the prioritization of their remediation efforts to focus on vulnerabilities likely to  be weaponized in real-world attacks or malware in the near future.

My New Year prediction is that organizations and vulnerabilities scanners will continue prioritizing based on CVSS score, missing critical information to help  prioritization and correlation with real-world attacks.

When using vulnerability scanners, often the enterprise scans their network infrastructure several times a month. This has the potential to create duplicate findings in the vulnerability management system. What is the definition of duplicates for vulnerability management? Same CVE vulnerability on the same IP, on the same host, on the same port and protocol. But what about about scanner’s plugins scanning for different vulnerabilities categorized under several and different CVEs? Are these vulnerabilities different or they should be considered duplicate vulnerabilities

Clearly, accounting for the scanner’s vulnerability duplicates is more complicated that what it might seem.

Vulnerability Categorization Goals

In discussions with enterprises in 2018, many desired a solution that would account for vulnerability duplicates and for improved association between detection plugins and vulnerabilities.

My New Year prediction is that vulnerability scanners will continue to generate vulnerability duplicates, with a situation becoming more and more complicated since the remediation tickets are now created directly into central enterprise systems.

Now to conclude (like icing on the cake) a few words about remediation.

Based on our conversations with enterprise customers, remediation of vulnerabilities is often a disjointed and different world from the administration of the enterprise security program. Different priorities, management structure, definitions of systems and/or assets and asset values. A common trait of a successful vulnerability management program lies in its capability to bridge the gap between security and the sysadmin/devops world, so that the priorities and the systems used to get to the remediation goals are the same for both departments.

Remediation Goals

I wish that in the New Year vulnerability remediation could be fully integrated with the security vulnerability management workflow. Seamless connections with the various ITSM ticketing systems used within organizations (ServiceNow, Jira, BMC Remedy, etc,) could represent a significant productivity and efficiency boost to remediate and prioritize vulnerabilities, and get those work tickets quickly to the people in the organization with the capability to resolve them in a timely fashion.

My New Year prediction is that enterprises will continue to use spreadsheets and email to manage vulnerabilities and communicate or track priorities and remediation status.

Conclusion

Same as it ever was, enterprises continue doing the same things, but hoping for better results. “Just one more full-time employee and we can get our vulnerability management program squared away”, they’re each hoping. The reality is that consolidated and established processes are hard to redesign and revamp. The practice of running vulnerability scans, fixing vulnerabilities based on CVSS risk score and hoping for the best is very established and hard to change. Change is especially difficult in highly regulated industries that have a mandate to follow CVSS for remediation – PCI compliance, for example. There is hope, however, that making regular, iterative changes to vulnerability management processes and adopting a more effective approach to vulnerability risk management could replace these long established (and broken) practices.