Posts

With the help of Greenbone products, known vulnerabilities in an IT infrastructure can be detected and subsequently eliminated. Assessing the severity of a vulnerability is an essential tool for planning and prioritizing subsequent remediation actions. CVSS provides such an assessment according to a metrics system. Since 2021, Greenbone’s current solutions also support CVSS versions 3.0 and 3.1, and at the same time, Greenbone started to provide all vulnerability tests for which a respective rating is available with it. As of October 2021, this work is now complete and there is – as far as possible – full CVSSv3x coverage in the Greenbone feeds.

Helpful Severity Metrics

Every cyber attack needs a vulnerability to be successful. Most vulnerabilities, namely 999 out of 1,000, have already been known for more than a year and can therefore be proactively detected and eliminated. For detection, a Greenbone vulnerability scanner is used, which finds the known vulnerabilities in an IT infrastructure.

If vulnerabilities are discovered, they can subsequently be eliminated using a wide variety of measures. The most urgent vulnerabilities to be eliminated are those that pose a critical risk to the IT system. Prioritization is required for selecting the measures and the order.

The severity is an essential tool for prioritization. However, we will take a closer look at how vulnerabilities are assigned a severity level in the first place and how it is calculated.

How Severity Ratings Are Created

In the past, different organizations and security research teams discovered and reported vulnerabilities at the same time and named them with different names. This resulted in the same vulnerability being reported by, for example, multiple scanners under different names, making communication and comparison of results difficult.

To address this, MITRE founded the Common Vulnerabilities and Exposures (CVE) project. Each vulnerability was given a unique identifier as a central reference, consisting of the year of publication and a simple number. The CVE database is used to link vulnerability databases with other systems and to allow comparison of security tools and services.

CVEs thus do not contain any detailed, technical information or information regarding the risks, effects or elimination of a vulnerability. In some cases, the version in which the vulnerability was removed is stored.

Further information about a vulnerability can be found in the National Vulnerability Database (NVD). The NVD – a U.S. government vulnerability management data repository – supplements CVEs with information regarding remediation, potential impact, affected products, and also the severity of a vulnerability.

How is the Severity of a Vulnerability Calculated?

The Common Vulnerability Scoring System (CVSS) was developed to enable the assessment of vulnerabilities. CVSS is an industry standard for describing the severity of security risks in IT systems. It was developed by the CVSS Special Interest Group (CVSS-SIG) of the Forum of Incident Response and Security Teams (FIRST). The latest CVSS version is 3.1.

The CVSS score evaluates vulnerabilities according to various criteria, so-called “metrics”: base-score metrics, temporal-score metrics and environmental-score metrics.

  • Base-score metrics: base-score metrics represent the basic characteristics of a vulnerability that are independent of time and the IT environment: how well can the vulnerability be exploited and what is the impact?
  • Temporal-score metrics: temporal-score metrics represent characteristics that can change over time but are the same in different IT environments. For example, the deployment of a patch by the deploying organization would lower the score.
  • Environmental-score metrics: environmental-score metrics represent the characteristics that apply to a specific IT environment. Relevant here are how well the affected organization can intercept successful attacks or what status a particular vulnerable system has within the IT infrastructure.

Since, in general, only the base score metrics are meaningful and can be determined permanently, only these are usually published and used.

CVSSv3.0/v3.1 Support Since GOS 21.04

Since GOS 21.04, which was released in April 2021, versions 3.0 and 3.1 of CVSS are also supported. Although some CVEs – and thus also the associated vulnerability tests – still contain version 2 CVSS data, this mainly affects older CVEs from the year 2015 and earlier, for which no CVSSv3.0/v3.1 score is yet stored in the NVD.

Let’s look at the biggest changes that versions 3.0 and 3.1 include.

Compared to CVSS version 2.0, version 3.0 retains the main groups of metrics – base, temporal, and environmental – but adds new criteria. For example, the metrics “Scope (S)”, which indicates whether a vulnerability can also affect other components of an IT network, and “User Interaction (UI)”.

Some existing criteria have also been replaced by newer ones: “Authentication (Au)” has become “Privileges Required (PR)”. It is no longer measured how often attackers have to authenticate themselves to a system, but what level of access is required for a successful attack.

In addition, the severity levels were subdivided more finely. In version 2.0, the values from 0 to 10 were divided into three severity levels: “Low” (0.0 – 3.9), “Medium” (4.9 – 6.9) and “High” (7.0 – 10.0). Since version 3.0, there are five levels: “None” (0.0), “Low” (0.1 – 3.9), “Medium” (4.0 – 6.9), “High” (7.0 – 8.9) and “Critical” (9.0 – 10.0).

CVSS version 3.1 did not bring any changes to the metrics or the calculation formulas. Instead, the focus was on emphasizing that CVSS measures the severity of a vulnerability rather than the risk it poses. A common mistake was to view the CVSS score as the sole characteristic of a vulnerability’s risk, rather than performing a fully comprehensive risk assessment.

In the course of this, the definitions of the metrics were formulated more clearly and the glossary was expanded.

Full CVSSv3.0/v3.1 Coverage in the Feed

With CVSSv3.0/v3.1 support in April 2021, Greenbone began updating all vulnerability tests assigned a CVSSv3.0/v3.1 score in the NVD to include a CVSSv3.0/v3.1 score.

This was done in daily stages of 500 – 600 vulnerability tests. The update and conversion were thoroughly reviewed and tested. Since October 2021, this work has now been completed. Thus, there is – as far as possible – full CVSSv3x coverage in the Greenbone feeds.

The goal of vulnerability management is to detect all security gaps in an IT network before an attacker does so. The Greenbone Security Feed (GSF) provides the vulnerability tests (VTs) that the scanner of the Greenbone solutions performs for this purpose. As a component of the Greenbone Security Manager (GSM) and the Greenbone Cloud Services (GCS), it is updated daily and provides protection against major and well-known vulnerabilities such as SUPERNOVA, BlueKeep and PrintNightmare.
We are happy to announce that the success story is growing steadily and that since this month our Greenbone Security Feed contains more than 100,000 vulnerability tests!

Let’s take a look at the history of the feed.

In 2005, the development of the Nessus vulnerability scanner decided to stop working under open source licenses and switch to a proprietary business model. By that time, members from Intevation and DN-Systems – the two companies that would later found Greenbone Networks – were already contributing developments to Nessus. In 2006, several forks of Nessus were created in response to the discontinuation of the open source solution. Of these forks, only one remains active: OpenVAS, the Open Vulnerability Assessment System.

In late 2008, Greenbone was formed to push OpenVAS. In the same year, two other companies became active: Secpod from India and Security Space from Canada. Both focused on providing vulnerability testing and partnered with Greenbone to create a reliable and up-to-date feed of vulnerability tests.

This started with the removal of source code and vulnerability tests where the license was unclear or incompatible. Several thousand vulnerability tests were eliminated to get a clean baseline with just under 3000 vulnerability tests at the time.

Shortly after, the content of the feed grew rapidly and steadily to over 10,000 vulnerability tests. 50,000 tests were then contained in the feed after about 8 years of development in 2016. The next 50,000 followed after only 5 more years and represent the current state with more than 100,000 vulnerability tests.

Number of vulnerability tests over time up to more than 100,000 vulnerability tests

Number of VTs over time

How Is the Feed Composed Anyway?

It is also interesting to see how these 100,000 vulnerability tests in the feed are put together. In our SecInfo Portal, you can easily take a look at all the included tests yourself.

About half of the tests detect vulnerabilities with a high severity class – i.e., with a severity between 7.0 and 10.0. Another 40,000 tests such with the severity class “Medium” (severity 4.0 to 6.9).

Distribution of the more than 100,000 vulnerability tests among the severity classes

Distribution of VTs by severity class

Vulnerabilities for the same area are grouped into families. Among the largest families of vulnerability tests are mainly those for local security checks, i.e., authenticated scans. In these, the target is scanned both from the outside via the network and from the inside using a valid usage login. Thus, more details about vulnerabilities can be found on the scanned system. Vulnerability tests for such authenticated scans already account for over 60,000 tests. The largest VT families with a total of almost 30,000 vulnerability tests are “Fedora Local Security Checks” and “SuSE Local Security Checks”.

Number of vulnerability tests of the top 10 families of vulnerability tests

Number of VTs in the top 10 VT Families

Globally Known Vulnerabilities Are also Covered

The general public is unaware of many vulnerabilities. But every now and then, particularly significant and spectacular cyber attacks make it into the media – especially when many large companies or governments are affected.

Greenbone reacts immediately when such incidents become known and starts developing a corresponding vulnerability test. Such notable vulnerabilities in recent years include Heartbleed (2014), POODLE (2014), DROWN (2016), Meltdown (2018), Spectre (2018), BlueKeep (2019) and PrintNightmare (2021). Most people probably also particularly remember the Solarwinds attack in 2019 and 2020. The attackers had exploited a previously unknown vulnerability to inject the malicious webshell “SUPERNOVA”.
All of these vulnerabilities can be detected via tests in the Greenbone Security Feed.

In the future, we will continue to work on expanding the scope of our feed to provide users with the opportunity to detect vulnerabilities at an early stage and not give attacks a chance. So with our solutions constantly updated to cover the latest and most critical vulnerabilities, you can relax. The next 100,000 vulnerability tests will follow – stay tuned!

SiSyPHuS Win10 is a project of the German Federal Office for Information Security (BSI).
Based on an analysis of the security-critical functions in the operating system Microsoft Windows 10, recommendations for action to harden it were developed. These recommendations are now also part of the Greenbone Security Feed in the form of a compliance guideline and Greenbone customers can conveniently check them directly with the Greenbone appliances.

The measures include configuration recommendations, password policies, encryption requirements and, of course, updates. They help to make Windows 10 systems significantly more secure. By integrating the compliance policy into the Greenbone Security Feed, the measures can be easily integrated into the Greenbone Vulnerability Management audit routines.

More information can be found here.

Compliance Policies are used by companies, organizations, or authorities to check whether all products, applications, operating systems and other components used meet certain specifications. The Center for Internet Security (CIS) provides so-called CIS benchmarks for this purpose. Since March 2021, the Greenbone solutions also offer the possibility to check the fulfillment of CIS Benchmarks – with the help of new compliance policies.

But what do we actually mean by a compliance policy?

In addition to legal requirements, companies, organizations and authorities often have their own requirements that must be met for the secure configuration of a system. Such requirements can be formulated, for example, by a software or application vendor for its own products, but also by IT security organizations.

The aim is to ensure the information and data security of a company or an authority by guaranteeing the confidentiality, integrity, availability and authenticity of information.

All specifications and guidelines, but also recommendations to be fulfilled for this purpose, are bundled in a policy in written form.

These guidelines form the basis for compliance policies developed by Greenbone Networks, i.e., for the collection of tests that a Greenbone solution runs on a target system. A vulnerability test is developed for each individual requirement or recommendation to check compliance with that requirement or recommendation. All tests are combined to scan configurations by Greenbone Networks and added to the Greenbone Security Feed.

Since the scan configurations in this case map company or authority guidelines, they are referred to as “compliance policies”.


Example: A company issues a policy with the following requirements:

  • Version 2 of software A is installed on the target system
  • SSH is enabled on the target system
  • Software B is not installed on the target system

For each of the requirements, Greenbone Networks develops a vulnerability test that queries whether the respective condition is met.

The three tests are then combined into a compliance policy that a user of Greenbone solutions can select for running a vulnerability scan. During the scan, it is then checked whether the conditions listed above are met on the target system.


 CIS Benchmarks as decisive security guidelines

The Center for Internet Security (CIS) also publishes such security guidelines: the so-called CIS Benchmarks. CIS is a non-profit organization founded in 2000 to provide best practices for IT security that are used by governments, industry and academia.

One of the largest fields of activity of the organization is the so-called CIS Benchmarks. These are recommendations for handling and configuring numerous products from a wide range of product families. For example, there are CIS benchmarks for web browsers such as Mozilla Firefox or Google Chrome, for operating systems like Microsoft Windows or different Linux distributions, but also for the Microsoft Office products.

In contrast to many other security standards, which only make basic specifications regarding IT security – for example, that there must be vulnerability management – the CIS benchmarks are very detailed. They provide requirements that must be met in order to harden a system, i.e. make it more secure and protect it against attacks. Among other things, this can include criteria for passwords, but also the specification for a certain installed software version.

The CIS Benchmarks are provided by CIS free of charge as a PDF and are constantly being expanded. For CIS SecureSuite Members – just like Greenbone Networks is since 2021 – the CIS Benchmarks are also available via the CIS Workbench in other formats, for example for Microsoft Word or Excel.

CIS-certified Compliance Policies at Greenbone Networks

As with the security policies of other companies, organizations or authorities, Greenbone Networks has now developed own compliance policies based on the CIS benchmarks. These enable users of a Greenbone solution to check their networks, systems and applications against the requirements from the CIS benchmarks. Since March 2021, several compliance policies that map CIS benchmarks are included in the Greenbone Security Feed.

And the special thing about it: the compliance policies developed by Greenbone Networks are certified by CIS! This means that users can be sure that their system is tested according to the hardening recommendations of CIS.

Users can now check their systems to see whether the CIS requirements are met. This also simplifies the preparation of audits. Important criteria can already be checked in advance with a scan by a greenbone solution and any weaknesses found can be eliminated.

But these CIS certified compliance policies will not be the end of the story. Many more policies that map CIS Benchmarks are in the planning or even already in development at Greenbone Networks.