Understanding the most important vulnerability acronyms

Since the Equifax event, vulnerability management gained a lot of attention. But what does "vulnerability" or "known vulnerability" mean? How to handle such an information? And why is this particular important to open source components?

To answer all these questions, we will publish a short series of articles. First we will dive into the goals of vulnerability management and basic concepts. Then we point our attention to the process of vulnerability management and finally show, how TrustSource may support you in performing these tasks.

The goal of vulnerability management

The goal of vulnerability management should be to MINIMIZE THE POSSIBLE ATTACK SURFACE of your environment, where "the environment" may be any scope of software you define (a SaaS, a software package or a complete enterprise). Minimizing the attack surface on the one hand means to accept that there will remain a risk. On the other hand, it means to know all possible attack vectors, assess the risk (maximal loss) associated and derive measures well suited to reduce the attack surface to a financially acceptable risk. This said, it is absolutely essential to assess your environment applying the most recent knowledge - known vulnerabilities - and to address all critical aspects.

The acronyms and concepts

This goal sounds ambitious. But no panic! tehre are some concepts out there helping you to do the job. Before we step into the process, we advise to familiarize with the following few abbreviations , terms and concepts:

  • CVSS = Common Vulnerability Scoring System

has been introduced to measure the impact of a vulnerability. Has a scale of 0-10, with 10 the highest, most critical. Everything above 7.5 may be considered as critical. CVSS is currently in v3, however, vulnerabilities reported prior to 2016 will have been reported in CVSS v2.

  • CAV = Common Attack Vector

describes the identified attack covering aspects such as prerequisites to execute the attack, impact and effect the attack will have. in v3 this will be attach vector (AV), attack complexity (AC), priviledges required (PR) and UI (User interaction). In version 2 (pictured in the tool tip on the right) you will see attack vector (AV), access complexity (AC), Authentication (Au), as well as the impacts on Confidentiality (C), Integrity(I) and Availability (A).

The standardized description of the attack vector is a great help when it comes to understand the impact a potential threat or a vulnerability may have.

  • CVE = Common Vulnerability and Exposure

The CVE is a key identifying a particular vulnerability. The key consists of the three letters CVE, the year and a counter. The counter is assigned by an assigning authority. The counter has no other meaning than to differentiate the particular vulnerability and exposure entries. It gets assigned in the moment it is requested. To request a number, no evidence is required. However, between assignment of an ID and its confirmation several weeks or months may pass.

  • CPE = Common Platform Enumeration

To provide a sound capability to match a vulnerability with the components concerned, the CPE has been introduced. Each component that has a vulnerability assigned, receives a CPE - currently following specification v2.3. A CPE is a unique identifier of a product allowing to refer back from the vulnerability to the product. The CPE (v2.3) consists of a type (h=hardware, o = Operating system, a = application), vendor, product and version information. A central directory, the CPE-dictionary contains all CPEs ever assigned.

However, the matching of CVEs with its assigned CPEs to real life components is critical. Wrong matches lead to false positives, putting the cat under the pigeons; missing matches leave vulnerabilities untreated. That is why we do spend so much attention on accuracy here.

  • CWE = Common Weakness Enumeration

This is a list of weaknesses found in applications. It is a community approach led by MITRE and SANS Institute, supported by huge number of technology heavy weights listing all kind of weaknesses, outlining their inner workings, exploit code and more details. CVEs may have a link to the corresponding weaknesses. the list is a great resource for security experts as well as wanna-be-hackers. It helps to understand the way attacks are created as well as what causes attacks to be successful.

The information supports the understanding of the impact a vulnerability really may have on the individual application.

So what?

Having read all this, you may want to turn your back at the topic and say, "Well, sounds good. Seems like all settled. Why bother?". Yes, there is a lot of structural work that has been done. But it these structures have only been created to allow you doing the job efficiently. The job still needs to be done. In our next post on vulnerabilities, we will cover the process on how to really assess a vulnerability and derive useful action.