After having seen in a first article the state of the threat and the current issues related to vulnerability management, we will see in this second article the new approaches to be considered to better manage vulnerabilities, in particular through the prioritization of vulnerability remediation proposed by Hackuity.

The advent of Risk-Based Vulnerability Management (RBVM)

Risk Based Vulnerability Management (RBVM) is an approach that treats each vulnerability according to the risk it represents for each company.

In this context, the classic formula for calculating a risk applies:

The first part of the formula, vulnerability × threat, can also be considered as a probability. This probability describes the chances that a given vulnerability will be discovered and used by a threat actor in the specific technical context of the organization.The last part of the formula describes the consequences, or impact, of a successful attack by a threat actor in the company’s business context.

This is in synthesis the approach adopted by CVSS, a standard developed by FIRST (Forum of Incident Response and Security Teams), initially to quantify the technical severity of a vulnerability. Through 3 metrics (basic, temporal, environmental), the full CVSS score (now in its version 3.1) is supposed to reflect the real risk of each vulnerability, in the context of each company.

Source: FIRST (https://www.first.org/cvss/specification-document)

Our purpose here is not to describe CVSS, so we assume that the reader is familiar with the concept. The CVSS score has many advantages, among the main ones:

• The only standard on the market available to quantify the criticality of a vulnerability,
• A detailed and transparent algorithm,
• A scoring widely adopted by the industry,
• Several world-wide reference databases available (in particular to qualify the criticality of CVE).

However, it has many limitations, the main ones of which can be listed here:

1. Its low granularity: each of the metrics is composed of categorical values with predetermined values (e.g., low, medium, high) which limits its discrimination capabilities.
2. Its vocation to unitarily qualify vulnerabilities: it is thus impossible to evaluate the criticality of a complete attack scenario with CVSS. For example, some cyber-attacks exploit several low vulnerabilities to compromise an entire perimeter. However, the CVSS assessment will only cover each of the vulnerabilities independently; it is necessary for the auditor to present a global scenario to highlight the overall risk, and they cannot rely solely on CVSS to do so since it was not designed to be aggregated.
3. Its arbitrary nature: the weights in the algorithm sometimes seem to be composed of arbitrary figures making the interpretation of these values complex. In the end, there is sometimes a significant margin of error in the CVSS quantification of the same vulnerability by two professionals.

On the other hand, should it be reminded, the public CVSS scores, such as those referenced in the NVD, are only base scores. They represent the intrinsic criticality of a vulnerability, but do not reflect the risk that this vulnerability represents for the company. In other words, they answer the question “Is it dangerous?” but not “Is it dangerous for my company right now?”.

Effective vulnerability management must take into account not only the base score, but also temporal and environmental metrics. The FIRST provides the framework, but the NIST cannot compute the CVSS score for the enterprise, as it requires knowledge of the criticality of the assets, identification of controls in place, the exploitability of the vulnerability in this specific context, or the intensity of the actual and current threat.

In the field, however, we note that nearly 45% of the companies surveyed – of all sizes – only use the CVSS base score as the sole metric for quantifying the criticality of vulnerabilities.

Beyond the relevance of this approach, the use of this single metric does not solve the major problem of the industry, which remains the volume of vulnerabilities to be addressed.

Of the 123,454 vulnerabilities (CVE) identified as of 01/15/2020, more than 16K had a CVSS base score (V2.0) deemed critical (i.e., more than 13% of the total).

Beyond CVSS ?

The objective of prioritization is therefore to reduce the stock of vulnerabilities by discriminating the most critical in order to allow the teams and means of remediation to focus on the vulnerabilities that matter the most.

On the other hand, there is no doubt that the daily flood of new vulnerabilities brought up by the detection arsenal can no longer be managed manually. It is totally unrealistic to manually examine, analyze and prioritize all identified vulnerabilities.

Automation should enable teams to work more efficiently, reducing repetitive and/or low value-added manual tasks and processes.

To meet these needs and respond to the limitations of CVSS, the RBVM players are introducing:

• New risk metrics (scores) – proprietary – that complete, overload or replace CVSS,
• Automation of analysis and measurement tasks, including correlation with threat sources (CTI) to continuously qualify the threat intensity associated with each vulnerability.

More generally, the RBVM approach takes into account numerous evaluation metrics to establish a score based on context and threat. There seems to be a consensus on 4 main categories of criteria:

1/ The vulnerability or the individual – intrinsic – characteristics of the vulnerability itself.

Through these criteria, the aim is to measure the severity of a vulnerability by taking into account metrics that are constant over time and regardless of the environment, such as the privileges required to exploit the vulnerability or its attack vector (remotely, on the same local network, with physical access, etc.).

For this category, the CVSS base score (generally taken in its version 2.0 to ensure anteriority) is a solid starting point for analyzing the intrinsic criticality of the vulnerability. This is the score used by most solutions on the market.

2/ The external threats that will be used to quantify the current intensity of the threat associated with each vulnerability.

The metrics used reflect characteristics that may change over time but not from one technical environment to another.

“Is the vulnerability associated with hot topics on discussion forums, the darknet and social networks? Does it have an exploitation mechanism been published or is it currently being exploited by a particularly virulent ransomware?”

The availability of an “exploit” associated with a vulnerability is, for example, an important factor taken up by most risk-based vulnerability management solutions. According to a Tenable Research study, 76% of vulnerabilities with a CVSS baseline score > 7 do not have an exploit available.

Source: (https://fr.tenable.com/research)

This means that companies that are focusing on fixing all their vulnerabilities with a “high” or “critical” risk according to CVSS would spend three thirds of their time filling in holes that ultimately represent little risk. For better operational efficiency, it is therefore appropriate to focus remediation efforts on vulnerabilities for which an exploit has already been released.

But this is far from being the only relevant criteria. Without known exploit, the age of the vulnerability can be taken into account to compute its probability of exploitation, using a statistical approach based on the occurrences of exploitation measured. Some initiatives such as EPSS (Exploit Prediction Scoring System[1] ) even try to predict the “weaponization” of vulnerabilities.

Like the age of the vulnerability, the age of the exploit is also a factor that will highly influence the probability of exploitation. For example, the CVE exploitation rate skyrockets as soon as an exploit is published, and then progressively decreases.

More generally, the threat intensity is an important metric in the prioritization algorithm. Beyond statistical approaches, it can be measured by monitoring CTI sources, social networks or various publications, such as quantifying the number of occurrences of these vulnerabilities in cybercriminal forum discussions. It will thus be possible to determine that a new or particularly active malware exploits a vulnerability and therefore to increase its criticality score.

Many other indicators can be integrated to refine the relevance of vulnerability prioritization. The Hackuity solution takes into account more than 10 criteria in addition to the CVSS metrics to compute its “True Risk Score”:

In addition to the relevance of the choice of these criteria and the algorithm itself, the type and quality of the CTI sources monitored to continuously feed these metrics represent an important issue.

Some of the sources used include the numerous open sources (OSINT) on vulnerabilities and threats (NIST-NVD, Exploit-db, Metasploit, Vuldb, PacketStorm, …), some of which are consolidated through open-source initiatives such as VIA4CVE (https://github.com/cve-search/VIA4CVE).

There are also a large number of private and commercial players offering CTI feeds with virous levels of specialization in vulnerability intelligence.

3/ The technical context or the unique characteristics of the environment in which the asset is located.

This category is used to measure the probability / difficulty to exploit a vulnerability in the specific context of each organization.

“Is the asset exposed on the Internet or hidden somewhere in the company’s datacenter? What are the technical measures (protection, detection) that make it more or less vulnerable to attacks?”

If some market actors just determine that an asset is exposed on the Internet based on its IP addressing scheme, others like Hackuity will seek to measure the depth of the attack trees needed to exploit the vulnerability in the company’s IS.

These characteristics are by definition specific to each environment. It is therefore necessary to have, take from, or determine such information, in particular by feeding the prioritization formula with contextual data linked to the assets. For example, the data may exist and therefore be extracted from internal repositories.

4/ The business criticality of the asset.

This involves measuring the consequences, or impact, of a successful attack by a threat player in the business context of the company.

“Is the asset impacted by the vulnerability critical to the organization in one way or another? Does it host sensitive or nominative information? What are the impacts for the company in terms of financial, reputation or compliance if the vulnerability is exploited?”

As much as for the technical context, these characteristics are specific to each environment. They may be manually entered or derived from risk analysis results such as Business Impact Analyses.

To conclude on RBVM, whatever the degree of automation brought by the Solution, it will only take its full strength with the contribution of contextual elements that the tool cannot guess (business impacts, technical environment of the assets, organization, processes, etc.).

Beyond RBVM: Vulnerability Prioritization Technologies (VPTs)

While the major market leaders in vulnerability detection have adopted a risk-based approach to Vulnerability Management, they have not addressed the main problem associated with the “best-of-breed” approach to detection: companies use multiple detection tools and practices to ensure complete and effective coverage of their technical perimeter.

Average number of detection tools by company size / Hackuity – Panel of 93 companies

As mentioned above, this necessary use to a heterogeneous arsenal promotes a fragmented and unconsolidated view of the situation, which limits the ability to scale and, with the growing volume of vulnerabilities, leads to an explosion of costs.

To address this problem, emerging market players named VPTs (Vulnerability Prioritization Technologies) by Gartner, such as Hackuity, agnostically exploit existing sources of vulnerability.

They collect and centralize vulnerabilities from any company’s detection arsenal: multiple practices (pentest, bug-bounty, red team, etc.), vulnerability detection solution providers (vulnerability scans, SAST, DAST, IAST, SCA, etc.) and vulnerability watch feeds. The main features of VPT solutions are described below.

Functional diagram of the Hackuity solution

A comprehensive view of the state of the stock of vulnerabilities

Automating the collection of vulnerabilities enables security teams to have, sometimes for the first time, a consolidated and centralized view of the company’s stock of vulnerabilities, regardless of the solutions or detection practices implemented.

A crucial operation – and one that is very rarely performed – is the conversion of proprietary formats into a normalized format. This allows clones of the same vulnerability, which have been identified by several sources, to de deduplicated (e.g. the same SQL injection identified during an intrusion test and during a vulnerability scan).

As such, Hackuity’s vulnerability’s meta-repository is a multilingual knowledge base that provides a unified and standardized description of all vulnerabilities, including corrective actions, patches, remediation costs, or exploitability, with no loss of information from the original source.

The establishment and enrichment of an inventory of assets

In the field, there are only rare exceptions of companies that have an inventory of their assets that is considered complete or at least reliable (CMDB, ITAM, …). This is an endemic problem in the practice and sometimes the main obstacle to the implementation of an efficient vulnerability management policy in companies. In order to solve this problem, some solutions integrate into their operations the dynamic and continuous establishment of the repository of the company’s assets inventory. This inventory is established by analyzing and correlating the technical data collected (e.g. the software stack installed on a server, its various aliases, etc.) and provides an asset database that is continuously kept up to date with data from multiple sources.

Asset criticality is also a key element in the vulnerability risk measurement process and accounts for nearly 50% in a prioritization approach. Without an accurate inventory of assets and an assessment of their criticality in the company’s business environment, it is impossible to accurately compute the real risk associated with each vulnerability. Some solutions, such as Hackuity, will compensate for the absence or non-completeness of risk analyses by automatically assessing the criticality of assets based on their technical and operational properties (types and families of tools installed, density of interconnections, hosted databases, etc.).

In the end, to have consolidated information about vulnerabilities or the company’s assets, you no longer need to master dozens of tools or formats: the cost and workload associated with managing disparate tools is significantly reduced.

The missing link between detection and remediation of vulnerabilities

Finally, the bidirectional link with the teams in charge of remediation or security supervision provides a collaborative approach in managing the stock of vulnerabilities.

Indeed, while automation has become a key lever for vulnerability management, the human factor remains at the heart of the process.

In most companies, Vulnerability Management involves 3 actors who must work together:

1. The security teams in charge of operating the detection tools and managing remediation plans,
2. The business managers who arbitrate or clarify the remediation plans in the light of business constraints,
3. Operational staff in charge of deploying corrective measures (patch management, configuration, development, etc.).

The efficiency of the process is therefore not limited to the automation of vulnerability collection. In the downstream part of the process (remediation management), play-books can be used to mobilize the resources needed to implement corrective measures: identification of the person in charge of the task, automatic creation of incident tickets, generation of scripts for Infrastructure as Code solutions, etc.

Upstream, the CISO finally has, and often for the first time, a real-time perception of the progress of remediation plans.

The vulnerability management solution is then the orchestrator of the ecosystem of solutions aiming at detecting, qualifying, correcting and monitoring vulnerabilities affecting the company.

Designed as an open system, it also allows third party tools and processes (SIEM, GRC, Compliance, Forensics, …) to be fed with consolidated and structured data on vulnerabilities, assets and threats affecting the business.

Conclusion

As a true cornerstone of corporate cyber security, vulnerability management can finally be synonymous with a scalable, effective practice for which it is now possible to have factual indicators reflecting the efforts made by security teams and teams in charge of remediation.

Besides the direct impact on the company’s security posture, through a reduction in the vulnerability exploitation window, or even the mobilization of experts on high added-value tasks, the integration of a vulnerability management orchestration solution can also have indirect benefits, such as better understanding the information system thanks or even a tenfold increase in the commitment of the teams thanks to the quantification of the impact of their actions on the company’s security.

[1] https://arxiv.org/pdf/1908.04856.pdf

Cet article Hackuity | Shake’Up – The future of vulnerability management: towards new approaches based on risk and prioritization (2/2) est apparu en premier sur RiskInsight.

What are we talking about?

ISO 27005 defines a vulnerability as “a weakness of an asset or group of assets that can be exploited by one or more cyber threats where an asset is anything that has value to the organization, its business operations and their continuity, including information resources that support the organization’s mission”. For the SANS Institute, vulnerability management is “the process in which vulnerabilities in IT are identified and the risks of these vulnerabilities are evaluated. This evaluation leads to correcting the vulnerabilities and removing the risk or a formal risk acceptance by the management of an organization”. Over time, Vulnerability Management has become a fundamental practice in cybersecurity, and now all industry professionals would agree to say that it is an essential process for minimizing the company’s attack surface.

Source: https://blogs.gartner.com/augusto-barros/2019/10/25/new-vulnerability-management-guidance-framework/

Nowadays, vulnerability management is integrated into all the major security frameworks, standards, sector regulations, guides and good security practices (ISO, PCI-DSS, GDPR, Basel agreements, French LPM, NIS, etc.) and is even regulatory in some contexts. Every “good” corporate security policy includes a significant chapter on this topic. Many would consider that a necessary evil.

Vulnérabilités : état de la menace

However, in 2019, according to a study conducted by the Ponemon Institute[1], “60% of security incidents were [still] the consequence of exploiting a vulnerability that is known but not yet corrected by companies”. To illustrate the current extent of the phenomenon, let’s consider ransomwares, the main cyber threat of 2020 and probably 2021. Although ransomwares are generally spread through user-initiated actions, such as clicking on a malicious link in a spam or visiting a compromised website, a large proportion of ransomwares also exploits computer vulnerabilities. Thus, if we look at the top-5 most virulent 2020 ransomwares ranked by intel471[2], we can see that their “kill-chains” all exploit vulnerabilities (CVE).

Source: Hackuity & National Vulnerability Database (https://nvd.nist.gov/)

It is worth noticing that such vulnerabilities have often been referenced by the NIST when the ransomware first appeared, sometimes for several years. Moreover, patches or workarounds have often been released in most cases. A recent CheckPoint[3] study confirms that the oldest vulnerabilities are always the most exploited. In mid-2020, more than 80% of the cyberattacks identified used a vulnerability published before 2017 and more than 20% of these attacks even exploited a vulnerability that had been known for more than 7 years.

This highlights the importance – even today – of rapid installation of security patch as a defense mechanism to minimize cyber risks. Therefore, it’s not surprising that Vulnerability Management – one of the oldest practices in cybersecurity – remains one of the major 2021 CISO challenges for Wavestone[4]. Does this mean that we should try to correct all the vulnerabilities? Let’s go back in time.

« Vulnerability Assessment » vs. « Vulnerability Management »

When they first appeared on the market at the end of the 1990s, the vulnerability management solutions worked similarly to an antivirus: the objective was to detect as many potential threats as possible. They were more commonly referred to as “vulnerability scanners”.

The volume of vulnerabilities then was relatively low compared to today. In 2000, the NVD identified about 1,000 new vulnerabilities over the year, compared to more than 18,000 in 2020.

A comprehensive and manual treatment of vulnerabilities was still possible at that time. Scanners provided a list of vulnerabilities, their relevance in the business context was analyzed by IT teams and a report was sent to business managers. Once the report was approved, administrators would fix the vulnerabilities and re-test to ensure that patches were properly implemented.

Source : National Vulnerability Database (https://nvd.nist.gov/)

Over the next two decades, the number of discovered vulnerabilities has increased steadily at first, then started to skyrocket in 2017, a trend that is still continuing today. In 2020, a record of more than 18,000 new vulnerabilities were published by the NIST. But no, the code quality is not worse than ever! There are several reasons behind the growing number of vulnerabilities being disclosed:

1. Innovation and the accelerated digitization of business lead to an increase in published hardware and software products. In 2010, the NIST recorded 22,188 new entries in its CPE repository, including 1,332 new products and 406 publishers. In 2020, 324,810 entries (+1,460 %), 35,794 new products (+2,690 %) and 6,060 publishers (+1,490%) have appeared in the repository.
2. Demand for faster time-to-market is driving vendors to shorten development cycles to release and sell products faster, even if it means saving on resources needed for quality assurance and security testing.
3. Cybercrime has become a lucrative business. A growing number of vulnerabilities are now attributed to cybercriminals seeking new tools to support their attacks.
4. At the same time, the number of experts and independent organizations involved in the research and disclosure of vulnerabilities is increasing. The democratization and industrialization of Bug-Bounty programs are not unrelated to this.
5. And finally, with rare exceptions such as GDPR, in the lack of adequate legislation and regulations to protect consumer rights in the event of software vulnerabilities, the industry has no incentive to invest in safer products nor take responsibility for the damage caused.

However, the problem is not only the higher number of vulnerabilities identified in the NVD databases or other repositories. With the advent of ultra-mobility, home-office, cloud-computing, social media, IoT, but also the convergence between IT and OT, Information Systems have continued to become more complex and to expand, open up and multiply the number of their suppliers, …creating as many potential new entry points for cybercriminals.

At the same time, companies are deploying and operating a vulnerabilities detection arsenal that is continually growing and has become more mature in recent years, or even commoditized:

• Intrusion tests & red-teams,
• Vulnerability scanners: on the entire external and/or internal park
• Vulnerability Watch
• SAST, DAST & SCA: often directly integrated into development pipelines
• Bounty Bug Campaigns

All these detection practices are complementary and generally stacked in a best-of-breed approach to evaluate specific parts of the IS or SDLC. Unfortunately, it is often once the arsenal in place that the problems are obvious (non-exhaustive list):

• The heterogeneity in the deliverables’ formats: pentest reports in PDF or Excel files, results of scans in the tool own console, vulnerabilities on the bug bounty platform, …, often force the company to adopt a siloed Vulnerability Management approach. It’s the same for vulnerability scores, which in the end turns out to be a patchwork of CVSS and its multiple versions, proprietary scales and a clever (J) mix of the two.
• This results in the inability to prioritize remediation efforts globally due to a fragmented and heterogeneous perception of vulnerabilities stock.
• Managing volumes of data that have become far too large to be processed manually: it is not uncommon for a company that performs authenticated scans on its fleet to see the volume of vulnerabilities exceed several million entries in the scanner’s console.
• Difficulty in coordinating remediation actions: identification of the asset owner and the holder of a share, exchange of e-mails, progress monitoring, Excel reporting, etc…
• The frustration of the teams in charge of remediation, who do not have factual reporting reflecting the remediation effort on the company’s overall security posture.

Facing these problems, companies have no choice but to work on the implementation of processes that are often costly because they rely on manual actions, the development of ad-hoc tooling or an assembly of bits and pieces of solutions gleaned here and there. The lack of automation of this process is all the more absurd since it generally mobilizes rare and expensive cyber security experts on low-value tasks such as compiling data in Excel, endlessly searching for the right stakeholder or tracking email threads.

In its study “Cost and consequences of gaps in vulnerability management responses” (2019), the Ponemon institute estimates that companies with more than 10,000 employees spent an average of more than 21,000 hours (or nearly 12 FTEs) in 2019 on the prevention, detection and treatment of vulnerabilities. This represents a total of more than $1M for a very disappointing quality/price ratio.

The « patching paradox »

In theory, the best way to stay protected is to keep each system up to date by correcting each new vulnerability, as soon as it is identified. IRL, this task has become impossible due to the volume of vulnerabilities too large, the human or financial resources too limited, the existence of legacy systems, and the time of availability of the fix or operational constraints on patch deployment.

Ultimately, no matter how large or small an organization may be, it will never have enough human or financial resources to address all of its vulnerabilities. In fact, the mistaken belief that more people dedicated to addressing vulnerabilities equals better security is called the “Patching Paradox” in the industry.

To reduce the pressure to increase staff at a time when there is a shortage of qualified security experts, and to prevent Vulnerability Management from becoming a frantic and lost race to fix more and more vulnerabilities, organizations today need to determine which ones of their vulnarabilities should be addressed first.

After having seen in this first article the threat status and the current issues related to the management of vulnerabilities, we will see in a second article the new approaches to be taken into account to better manage vulnerabilities.

[1] Ponemon Institute – Cost and consequences of gapes in vulnerability management responses – 2019

[2] https://intel471.com/blog/ransomware-as-a-service-2020-ryuk-maze-revil-egregor-doppelpaymer/

[3] https://www.checkpoint.com/downloads/resources/cyber-attack-trends-report-mid-year-2020.pdf

[4] https://www.wavestone.com/fr/insight/radar-rssi-quelles-priorites-2021/

Cet article Hackuity | Shake’Up – The future of vulnerability management: threat status and current issues in vulnerability management (1/2) est apparu en premier sur RiskInsight.