How Do You Identify Vulnerabilities?
There are many tools on the market, and even some that are free of charge, that will enable your security or IT team to identify vulnerabilities. Tenable, Qualys, and Rapid 7 are some of the scanners and platforms with the most name recognition, but tools like OpenVAS (an open-source vulnerability management tool) are a good place to start to identify vulnerabilities. Scanners identify vulnerabilities either internally or externally. That is, devices scanned in an attempt to identify vulnerabilities that are accessible from the internet are scanned “externally,” while those devices not connected directly to the internet are considered “internal,” and therefore scanned internally to identify vulnerabilities. Vulnerabilities on external devices enable cyber criminals to penetrate, or gain a foothold on a network, while internal vulnerabilities are exploited by bad actors after they’ve gained access to the network to secure access to sensitive information. The first step in any vulnerability management program is to identify vulnerabilities, so if it’s done well, it can form the foundation for a successful program. Unfortunately, the opposite is true as well.
Why is it Important to Identify Vulnerabilities?
Unpatched vulnerabilities are responsible for a significant percentage of successful breaches, typically trailing only stolen credentials as the leading means of network compromise by cyber criminals. A 2019 Ponemon study put the percentage of breaches resulting from unpatched vulnerabilities at 60%, while other surveys land in the 30% range, and others even higher than 60%. But, no matter the analysis, an irrefutable tenant of cyber security is that unpatched vulnerabilities greatly increase the cyber risk of an organization. Thus, as a first step in an effective network cyber hygiene program, it’s important to identify vulnerabilities. Indeed, in the Ponemon study cited above, 62% of the respondents admitted they weren’t aware of their organizations’ vulnerabilities before the breach. You certainly can’t solve a problem if you don’t know you have one, and in the case of vulnerability management, the recognition starts with identifying vulnerabilities.
What’s the Best Strategy after we Identify Vulnerabilities on the Network?
Over 22,000 new vulnerabilities were discovered in 2022, or more than 60 per day, an impossible number for any human to track and process manually. Of course, not all 60 per day apply to every network, but it’s likely that of those 22,000, several will apply to the typical network. That having been said, the number of unpatched vulnerabilities on most corporate networks is counted in the thousands and tens of thousands, so when the cyber security team works to identify vulnerabilities, that’s a critical first step, but only the first one. The critical next step in a vulnerability remediation strategy is to prioritize the highest risk vulnerabilities. Many of the vulnerability management products on the market now include some degree of vulnerability prioritization, a capability that has spawned the term “risk-based vulnerability management” or RBVM. But, even without those products, a first-cut prioritization can be done by using the vulnerability’s CVSS (Common Vulnerability Scoring System) score. The CVSS score is based on a zero to 10 scale, so a vulnerability with a score of zero to 4 is considered a low risk, while a vulnerability with a score of 9 to 10 is categorized as critical. The primary deficiency of the CVSS score is that it lacks context. Depending on the network the vulnerability is on, where it’s located, and other factors, a vulnerability on one network may represent a higher or lower risk than the same vulnerability on a different network. In an extreme example, a device may have a vulnerability with a score of 10, but if that device isn’t connected to the network, or it’s on an isolated segment of the network, its risk to the organization is substantially lower than the score of 10 would imply. Vulnerability management vendors have developed solutions that use ML to prioritize vulnerabilities in the context of the network on which they’re located, and these tools can be highly valuable after your team has worked to identify vulnerabilities. As the number of unpatched vulnerabilities can be overwhelming, the process of prioritizing vulnerabilities in the context of a given network is a logical next step in the vulnerability management process. We discuss some other factors that can be considered when prioritizing vulnerabilities later in this discussion.
How Often Should We Identify Vulnerabilities?
Most cyber security practitioners recommend scanning for vulnerabilities no less frequently than every quarter, but that rule of thumb is often driven more by company reporting requirements or compliance issues than it is by security concerns. The short answer is to scan as frequently as the data can be processed and acted on. It’s important to remember that when you identify vulnerabilities, the process has no inherent security value unless you couple that with a robust vulnerability remediation program. Thus, how often you identify vulnerabilities is much less important than how quickly your team is patching them. A common and useful metric in this context is MTTR, or mean time to remediate, essentially a measure of how long it takes for your organization to patch a vulnerability after it’s identified and a patch is made available by the software manufacturer. Most security professionals cite the generally accepted figure of 60 to 150 days to remediate a vulnerability when asked what the typical timeframe is to deploy a patch after you identify vulnerabilities. This figure is both useful and misleading. First, it’s origin is over 8 years old, and second, it likely derives from a from a survey that treats all vulnerabilities equally (for example, patching a high risk vulnerability in a timely fashion is much more important than remediating a low-risk vulnerability that may not even be readily exploitable.) Despite the statistic’s shortcomings, it serves as a useful barometer for remediation teams from which to derive their performance. The MTTR for a given organization can be rendered more meaningful by, for example, segmenting the MTTR score for just the most critical or high-risk vulnerabilities, a much more relevant measure of the vulnerability remediation team’s performance.
What’s the Risk if you Don’t Identify Vulnerabilities and Patch Them Quickly?
An older study estimated that the chances of a vulnerability being exploited increases to 90% after 60 days. This means that an individual or cyber criminal group will develop the code to take advantage of a new vulnerability within 2 months, on average, faster if the vulnerability is widespread. Indeed, when a vulnerability is identified, there’s a race between the good guys and bad guys. The good guys work to 1) fix the code and make the corrected software available (patch), and 2) apply that patch on networks with the vulnerability. The bad guys 1) work to create code or tools that make it easy to exploit that vulnerability, and 2) distribute that code for a fee, or use it themselves to attack networks with the vulnerability. Each side gets a head start depending on who discovers the vulnerability. It’s clearly much more preferable if a white hat hacker or other non-criminal party discovers a given vulnerability, as it can be quickly reported to the software manufacturer, and a patch developed quickly. However, when threat actors find vulnerabilities before the good guys, it gives them a head start on the development of an exploit and its distribution. Thus, as a cyber security professional in an enterprise, it’s critical to identify vulnerabilities as quickly as possible so as to win that never-ending race against bad actors working to exploit any vulnerability that will enable their unauthorized access to the network.
Who in your Organization Should Identify Vulnerabilities?
In most organizations, the information security team are the ones that would identify vulnerabilities. The security team will use scanning and reporting tools to identify vulnerabilities on the network and create reports that typically will list, among other metrics, the vulnerabilities on the network, and the progress that’s been made over time remediating them. More sophisticated tools also aid the infosec team in prioritizing the unpatched vulnerabilities so the highest risk vulnerabilities are remediated first, making the best use of available resources. After vulnerabilities are identified and prioritized by the cyber security team, they’re handed off to the remediation team to be patched. As the remediation team is often a part of the IT team, and not the information security department, conflict between the two groups is common. Both teams are driven by different priorities. For example, the security team is focused solely on protecting the organization’s sensitive information, while the IT team is primarily responsible for making sure all information systems are running properly, are available, and the business functions effectively. Certainly, the remediation team members are security conscious as well, but they are typically overwhelmed with daily pedestrian tasks (e.g. endless help desk calls, new employees, deployment of new hardware and software, system maintenance), so their immediate priority is unlikely to be applying security patches. More sophisticated organizations successfully infuse their entire company with a sense of the importance of cyber security that can help to temper this age-old conflict between IT and information security, but it’s a common challenge for company leadership. Amplifying the friction between the two organizations is disparate reporting requirements: each team has different KPIs (key performance indicators) to which they’re working and that they’re measured against. Thus, it can seem at times that each team is rowing their boats in opposite directions.
How do you Prioritize after You Identify Vulnerabilities?
As mentioned in previous sections, many of the vulnerability management solutions on the market include (or make available) advanced vulnerability remediation prioritization packages, but it can be useful to think about vulnerability prioritization as it relates to your specific architecture and general network design. A good place to start for a high-level sense of which vulnerabilities should be addressed first would be the CVSS score, or the common vulnerability scoring system. Each vulnerability discovered and released publicly will have a 0 to 10 CVSS severity score assigned to, a useful point of departure for vulnerability prioritization after you identify vulnerabilities. As we’ve discussed, however, the CVSS score lacks context, so it’s important to consider other factors when prioritizing vulnerabilities. For example, certain assets or devices are more critical to an organization than others. A database server that houses sensitive information is clearly of more importance to the organization than a printer, so any vulnerabilities on that server would be assigned a higher priority level than those on the printer. Knowing whether or not the vulnerability has an active exploit in the wild is another factor to consider when ranking vulnerability remediation priorities. Vulnerabilities without active exploits clearly add much less risk to the organization. Another, more obscure, consideration is to identify vulnerabilities on devices that stand out, or are unique in some way. For example, a Linux machine on a network segment populated almost exclusively with Windows machines. Why is this important? Experienced pen testers know that threat actors, after penetrating a network, search for such out-of-place devices, as they often represent softer targets for compromise. Clearly, finding such outstanding devices on a large, complex network is a task best left for technically advanced vulnerability management solutions, but having some knowledge of this shared hacker (bad guy) and pen-tester (good guy) technique is useful whether you employ a prioritization tool or attempt to prioritize vulnerabilities manually.
What is the Best Way to Patch after You Identify Vulnerabilities?
There’s no question that using a quality patch management tool can provide a foundation for a robust vulnerability remediation program. To learn more about patch management software, review our blog here. Patch management software can deliver a number of functions that can help accelerate vulnerability remediation and reduce MTTR, which in turn lowers the enterprise’s cybersecurity risk. Patching tools can centralize the remediation function, track vulnerabilities (both patched and unpatched), establish patching cadence, set policies for auto-patches, and generate reports that can be useful for corporate leadership to understand the enterprise’s vulnerability exposure. The primary deficiency in typical patch management tools, however, is that they rely on human judgment to determine patching strategies for what could be hundreds, thousands, or more vulnerabilities on the typical corporate network. In fact, the vast majority of patches can be applied safely, with very little risk of network disruption, but after you identify vulnerabilities, most remediation teams are reluctant to leverage auto-patching as often as they practically can for fear of network disruption, a fear that is completely understandable, but, given the data, is borderline irrational. Or is it? Although upwards of 95% or more of all applied patches are not rolled back (replaced with the old software version after a failure or disruption), there’s no way for remediation teams to know which 5% to manually patch with great care, and which 95% to set to auto-patch. And the stakes are high for that bet. A major network disruption can have wide-ranging consequences for the business…and the remediation team members’ annual performance review. New vulnerability remediation technologies are working to address this gap in the patching process after you identify vulnerabilities. In this case, the key to identifying which patches are likely to cause disruption can be addressed using actual data. That is, data can be collected from the community of vulnerability remediation practitioners and used to inform everyone on their collective experiences with the same patch. Thus, if you know that a given patch was deployed by 100 – or 1000, for that matter – others and there were only 1 or 2 disruptions, your remediation team is now armed with the empirical data necessary to confidently set up auto-patching for that patch, removing the burden of applying that patch manually from the remediation team. Now, extrapolate that experience to, potentially, 95% or more of all the patches on the network, and there is significant potential to greatly speed remediation after you identify vulnerabilities. trackd is building just such a platform. Designed for one mission (materially reducing the MTTR of our customers), the trackd platform will provide the experiential insight and the tools to enable remediation teams to maximize the number of vulnerabilities they’re comfortable auto-patching, saving precious remediation team resources for those patches that require testing, off-hours deployment, and other manual intervention. To be part of our beta, and our effort to re-imagine the vulnerability remediation world, visit trackd.com.
