CWEs Top 25 is a view to the top 25 most dangerous software errors - weaknesses (CWE). The CWE list is maintained by MITRE Corporation. Weaknesses are types of vulnerabilities that can be exploited as vulnerabilities by attacks. MITRE Corporation supports lists for vulnerabilities (CVE) and attacks (CAPEC). The investigation process of given vulnerability, weakness or attack is a sophisticated navigation process in mentioned lists. The aim of presented research is to represent in an ontology Top 25 CWEs and related with them CVEs and CAPECs to facilitate the navigation.
The weakness is an error, bug or misconfiguration introduced at some stage of the software life cycle.
The vulnerability is an exploited by some attack weakness. Some weaknesses cannot be exploited because is not available an attack vector to them.
MITRE Corporation maintains:
CWE [
Every CVE is linked to concrete vendor(s), product(s) or product version(s).
CWEs are organized in several taxonomies at different abstract levels. CWEs are like CVE types.
MITRE Corporation with above-mentioned lists supports the community process of vulnerability registration, its classification as weaknesses and further investigation of applicable attack patterns. At the beginning is the vulnerability but new weaknesses and attack patterns sometimes have to be introduced.
NIST’s NVD [
CWE Top 25 Most Dangerous Software Errors
Top 25 Most Dangerous Software Errors (Top 25) [
The ranking methodology intensively uses NVD and CVSS scores assigned there to the CVEs. Only CVEs that have at least one CWE assigned to them as a root cause participate in the calculations.
Two basic values are assigned to each CWE weakness X mentioned in NVD CVEs: frequency – Fr(X) severity – Sv(X)
Let Freq(X) is the number of references to the weakness X in NVD CVEs.
Let Fmin is the minimum value and Fmax is the maximum value of Freq(X) over its domain.
Then weakness X frequency is: Fr(X) = (Freq(X) – Fmin) / (Fmax – Fmin)
Let AVG_CVSS(X) is the average CVSS score from the CVEs in which the weakness X is mentioned as a root cause.
Let CVSSmin is the minimal value and CVSSmax is the maximal value of AVG_ CVSS(X) over its domain.
Then the weakness X severity is: Sv(X) = (AVG_CVSS(X) – CVSSmin) / (CVSSmax – CVSSmin)
Finally, the weakness Tip 25 score is: Score(X) = Fr(X) * Sv(X) * 100
2019 Top 25 is presented in Table 1. Additionally, CWE team added 15 CWEs (Table 2) that are risky but have not enough score.
Rank ID
[
Initially, the new vulnerability is registered in the CVE database by some CVE Numbering Authorities (CNAs). This means that it is yet registered in some private or public repository. Then an investigation process follows to accept or reject this vulnerability. Sometimes, the new vulnerability is recognized as old one. Further, the investigation process relates the vulnerability (CVE entry) to a weakness (CWE entry) and to an attack pattern (CAPEC entry). Sometimes, it is impossible to clarify the vulnerability nature and to relate it with any weakness and/or attack pattern. It is possible a vulnerability to be related to several weaknesses and/or several attack patterns. Briefly, thisisthecontentsofvulnerabilityprocessingwithoutgoingindetailsaboutthelifecycle and the phases of vulnerabilities, weaknesses and attack patterns.
In the case of Top 25 Most Dangerous Software Errors, all CVEs are related with CWEs and CAPECs, simply because only such CVEs are used in the ranking procedure.
TheontologyisimplementedinOWL[
CVE,CWEandCAPECdatabasesarerepresentedintheontologyasdisjointclasses. Their definitions are as follow:
TheelementsofCVE,CWEandCAPEChaveanidentifier(ID)–positiveinteger,a name(Name)–string,andashortdescription(Description)–string.Thesecharacteristics are represented in the ontology as datatype properties:
CVEentrieshaveexternalreferencestootherrepositoriesinwhichtheyareregistered with different identifications. These references are important because they extend the view to the vulnerability but at this time, they are not included in the ontology.
The information about the CVE entry nature is in its description. This is semistructured text about the vendor, product, version, component root cause, attack vector etc., but this text is hardly readable even by a human-expert. Information extraction from the CVE description is out of the scope of this research.
CVEs are not organized in any taxonomies – they are simply lists. The information about the CVE entry is contained in its CWE “type”, but it is possible a vulnerability to be related with several CWEs. CWEs and CAPECs are organized in several taxonomies.
A CWE entry can have an extended description (ExtendedDescription) in addition to its description. This additional description is included in the ontology as a datatype property:
How a CWE can be detected is given in the datatype property DetectionMethods of the class CWE:
Another important information about the CWE are mitigation methods. These are represented in the datatype property PotentialMitigations:
Some CWEs are related to specific programming languages. In the CWE class, this is represented as a datatype property (Languages). This property is a simplification because relation can be not only to the programming languages but also to platforms, technologies etc.:
Usually, the most detailed CWEs (at abstraction levelVariant) are linked with some programming language, platform or technology etc., but in Top 25 Most Dangerous Software Errors, there are CWEs at different abstraction levels. This is another simplification accepting that all CWEs are at the same abstraction level. Just a same is the situation with CAPECs.
CWE entries have more characteristics that are interesting but at this stage only listed above are included in the ontology.
CAPECs are organized in several taxonomies. CAPEC entry has many interesting characteristics, but in our ontology, they participate only with their ID, Name and Description.
One of the most important concept in the ontologies are class relationships. They are modelled as class object properties.
As it has been mentioned, vulnerability “types” are the weaknesses. The object property WeaknessEnumerations links CVEs with their CWEs. The MITRE Corporation CVE list does not contains this relationship, but it is available in NVD with this name. This object property is defined as follows:
The object property ObservedExamples links weaknesses to their vulnerabilities:
Weaknesses, on the other hand, are linked with the attack patterns that can be used to exploit them. This relationship is represented as an object property with the name AttackPatterns that links CWEs to their CAPECs:
Finally, the relationship of attack patterns to the exploited by them weaknesses is represented by the object property RelatedWeaknesses:
Navigation in our ontology is via SPARQL queries. Starting point can be any weakness, vulnerability or attack pattern. The path and its scope depend of the case study scenario. Several case studies, roles (security manager, cyber security operational team, procurement employee, cyber security trainee) and scenarios have been investigated. Identified case studies, roles and scenarios are not exhausting, but it is clear that not all of these potential users can use SPARQL queries in their everyday duties. A specialized user-friendly interface to the ontology must be developed for them.
Presented here ontology is very simple. It contains the basic knowledge about Top 25 Most Dangerous Software Errors and related vulnerabilities and attack patterns but even now, it is populated with 493 individuals (CWEs – 25, CVEs – 156, CAPECs – 312). Further extensions of this ontology would be populated with many thousands CWEs, CVEs and CAPECs. This process have to automatic for a stable ontology structure. CVE, CWE and CAPEC databases are relatively stable but the devil is in the details. So, may be some automatic ontology structure must be developed.
Finally, it is clear that the real power of the semantic search can be achieved with the introduction of CWE and CAPEC taxonomies. This task is not so simple because the used taxonomies are not simple ones and further research and investigations must be done on them.
This research will be used in the context of updating of current curricula at University
of Sofia with cybersecurity topics as described in [
This work was conducted using the Protégé resource, which is supported by grant GM10331601 from the National Institute of General Medical Sciences of the United States National Institutes of Health.
This research is supported by the National Scientific Program “Information and Communication Technologies for a Single Digital Market in Science, Education and Security (ICTinSES)”, financed by the Ministry of Education and Science.