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 first dive into the goals of vulnerability management. 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 take all reasonable efforts to reduce the options for an attack. Thus it is essential to work with the latest knowledge 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 using 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 below) you will see attack vector (AV), access complexity (AC), Authentication (Au), as well as the impacts on Confidnetiality (C), Integrity(I) and Availability (A).
The standardized description of the attack vetor 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.
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. Learn more about the process on how to really assess a vulnerabilities in this article.
Article is closed for comments.