BIBLIOGRAFÍA CONSULTADA A Documentación impresa
B. Documentación digital
Determining the public disclosure date of a vulnerability is vital to understanding the life cycle of a vulnerability. Previous studies (e.g., [102], [167], [168], [106], and [169]) have relied in their analysis on only a single SVDB (e.g., NVD) as their information source. While the CVE publication date used in these studies corresponds to the publication date in NVD, it is not necessarily the date the vulnerability was publicly disclosed [218]. In our approach we compare the publication dates of vulnerabilities in different SVDBs to identify inconsistencies among the dates and to provide security engineers with more accurate reporting date results.
Results and discussion: For our analysis, we take advantage of our ontological representation
which allows us to create a simple SPARQL query (Listing 2) that links all exploits based on their CVE-IDs from the two databases (D1 and D2) and returns the release date for each vulnerability recorded in the individual dataset.
PREFIX[…]
SELECT DISTINCT ?exploit ?expDate ?vulnerability ?vulDate
WHERE{
?exploit rdf:type sevont:Exploit.
?vulnerability rdf:type sevont:Vulnerability. ?exploit sevont:hasEntryReleaseDate ?expDate.
?vulnerability sevont:hasEntryReleaseDate ?vulDate. ?vulnerability sevont:hasExploit ?exploit.
}
Listing 2: Query to retrieve publish (Release) dates between vulnerabilities (D1)
The query results show that 21,654 CVEs appear in both datasets and that of these 16,337 (75%) are disclosed in D2 prior to being published in D1 (with a median number of seven days between the two reports). On the other hand, 3,848 (18%) of vulnerabilities were published first in D1 before they were included in D2. Only 7% of the vulnerabilities show the same publication date in both SVDBs. Table 24 shows an example of the retrieved data from our knowledge base for the vulnerabilities publication dates for D1 and D2.
Table 24: Example information retrieved from our Knowledge Base for NVD and Exploit-DB as denoted in Query 1
Exploit-DB entry Release Date NVD entry Release Date
Exploit-DB: 43376 20/12/2017 NVD: CVE-2017-17692 21/12/2017 Exploit-DB: 43363 14/12/2017 NVD: CVE-2017-17411 21/12/2017 Exploit-DB: 43378 20/12/2017 NVD: CVE-2017-17752 20/12/2017 Exploit-DB: 18818 01/05/2012 NVD: CVE-2012-2576 20/12/2017 Exploit-DB: 43377 20/12/2017 NVD: CVE-2017-17759 19/12/2017 Exploit-DB: 43355 18/12/2017 NVD: CVE-2017-15048 19/12/2017 Exploit-DB: 43354 18/12/2017 NVD: CVE-2017-15049 19/12/2017 Exploit-DB: 43344 15/12/2017 NVD: CVE-2017-17088 19/12/2017
For example, CVE-2012-2576 is a vulnerability in SolarWinds Storage manager 5.1.0 and earlier62 that was first discussed and assigned a CVE-ID in D2 in May 2012. The same
vulnerability was not published in D1 until December 2017. Our results show that users who rely only on D1 and are unaware of exploits reported in D2 will not receive any alerts from D1 until December 2017. However, once a vulnerability becomes public (in this case May 2012), its likelihood for being exploited increases significantly, since the vulnerability is now publicly announced.
4.5.2 Use Case Scenario #2: Enriching Vulnerability Data
As we discussed earlier, SVDBs are a rich data source that can be used for mining and analysis of security issues and their fixes. However, the level of details, the completeness, and the quality of vulnerability information may differ significantly among SVDBs. For example, a security engineer relying only on D2 would have to rely on CVE-ID to identify a vulnerability. While CVE-IDs are widely used to describe reported vulnerabilities, alternative or supplementary information might exist in other SVDBs.
Results and discussion: Query 2, an extension of the SPARQL query (Listing 2), establishes a
semantic link between D1 and D2 using the CVE-ID captured by both SVDBs. Given SPARQL query (Listing 3), we can now automatically infer missing vulnerability information in D2 such as the exploit type (described by CWE standard) and the exploit severity score (described by CVSS standard).
PREFIX[…]
SELECT DISTINCT ?exploit ?vulnerability ?weakness
?severityLevel ?CVSSscore
WHERE{
?exploit rdf:type sevont:Exploit.
?vulnerability rdf:type sevont:Vulnerability. ?vulnerability sevont:hasExploit ?exploit.
?vulnerability sevont:hasSeverity ?severityLevel. ?vulnerability sevont:hasWeakness ?weakness.
?vulnerability sevont:hasSeverityScore ?CVSSscore . }
Listing 3: Query to retrieve the missing vulnerability information between vulnerabilities (D1) and related exploits (D2).
Figure 23: Distribution of CVSS severity scores, which are on a scale of 0 to 10, rounded to the nearest integer.
CVSS scores assigned to D2 exploits. The results from query (Listing 3) can now, for example,
be used to classify exploits in D2 based on their CVSS severity scores. CVSS severity scores range from 0 to 10. Our query results (see Figure 23) show that vulnerabilities reported in D2 data consist mostly of vulnerabilities with a severity score of 5-10 (medium to high severity).
CWEs information assigned to D2 exploits. Based on Listing 3, we can now use the CWE
standard (captured in D1) for an additional classification of software exploits in D2 using the CVE-ID link we established among the two datasets. The results of our query show that for 54% of exploits a CWE-ID can be identified and classified based on the CWE standard. Table 25 lists the most common software weaknesses, including the frequency with which they occur in D2. SQL injection, buffer overflow errors, and cross-site scripting vulnerabilities are among the top three weaknesses.
Table 25: Top 10 CWE software weaknesses by the number of Exploits (D2)
CWE-ID Weakness Summary Num. Exploits
1. 89 SQL Injection 2825
2. 119 Buffer Overflow 2075
3. 79 Cross-site Scripting 1775
4. 94 Code Injection 1033
5. 22 Path Traversal 927
6. 20 Improper Input Validation 703
7. 264 Access Control Error 647
8. 399 Resource Management Error 301
9. 200 Information Disclosure 249
10. 352 Cross-Site Request Forgery 222
4.6 Chapter Summary
In this chapter we have presented a semi-automated method for developing a unified vulnerability knowledge base, i.e., SEVONT: a pyramid of software security vulnerabilities analysis ontologies, which allows us to reconcile and integrate heterogeneous vulnerability data from several SVDBs. Our knowledge modeling approach takes advantage of FCA to guide knowledge engineers in abstracting and reusing concepts across system level ontologies, while at the same time improving knowledge integration and reuse. We illustrated the applicability of our knowledge model through two examples that take advantage of our unified representation to verify the consistency of data in these SVDBs and to enrich existing SVDB knowledge resources by linking them to other resources.
In the next chapter we introduce SV-AF, a framework for integrating SEVONT with other SE ontologies (e.g., source code, build repositories, issue tracker). The objective of SV-AF is to provide a comprehensive, interlinked knowledge base that allows for novel types of cross artifact vulnerability analysis.