3. PROCESO DE DEGRADACIÓN
3.2. Conclusiones específicas
Different knowledge engineering methodologies have been discussed in the literature (e.g., Noy et al. [211] and Uschold et al. [21]). For our knowledge modeling approach, we adopt a similar modeling methodology as the one presented by Noy et al. [211]. In their knowledge-engineering approach for ontology development they propose the following seven core steps: (1) determining the domain and scope of the ontology, (2) considering the reuse of existing ontologies, (3) enumerating essential terms in the ontology, (4) defining the classes and class hierarchy, (5)
defining the properties of class-slots, (6) defining the facets of the slots, and (7) creating instances.
Similarly, we first conducted a thorough review of existing work on ontologies in the software vulnerability domain to help us define and determine the domain and scope of our knowledge model. As part of this review we identified and extracted key concepts from existing software vulnerability ontologies discussed in the 22 papers of our dataset using the same classification as in Section 4.2.1. Table 12 summarizes the core concepts used by the authors to construct their software security domain ontologies.
Our analysis shows that articles in the software development process category include mostly concepts related to software security requirements and requirements elicitation (e.g., dependability, confidentiality). There are cybersecurity ontologies mostly focused on Internet attacks, which typically involve different software assets that can be exploited by vulnerabilities. Ontologies used mainly for vulnerability management focus on modeling vulnerabilities knowledge sources (e.g., vulnerability databases, malware activities datasets, intrusion detections tools results, etc.) to enrich and link these knowledge resources [175].
For establishing our initial domain ontology for software vulnerabilities, we further manually identified shared (common) concepts used by these reviewed ontologies (Table 12). For example, a more detailed analysis of the ontologies and their supporting documentation shows that the security and vulnerability concepts share a similar meaning across the surveyed ontologies. These concepts are used to describe security vulnerability issues affecting software products. Also, threat, attack, weakness, and risk are concepts commonly found in these ontologies to classify software security vulnerability attacks. Based on these common concepts, we derived our initial core SEVONT ontology which includes the following concepts (Figure 11):
Table 12: Core concepts (classes) defined in the surveyed vulnerabilities ontologies
Category Reference Core concepts
Software security ontologies applied in software development
[179] Security concerns, attack, frauds, asset, prevention, threats, auditing [180] Vulnerability, effect, security impact, malicious action, attacker, attack, malicious goal [184] Security requirements terms (confidentiality, integrity, dependability, availability, authenticity, non-repudiation, ...),
security exploits, bugs, attack models
[183] Asset, location, organization, person, threat, vulnerability, risk severity, impact, threat agent, attack tool, attack method, security goal, security criterion, security requirement, control
Ontologies for software cybersecurity [171], [189], [186], [187], [191]
Vulnerability, vulnerability source, product, software, hardware, operating system, web browser, consequences, means, weakness, other terms
[192] Software, vulnerability, malware, attack, flow, attacker, user, account, host, address, IP, port, domain name, service, address range
[193]
Vulnerability, CVSS metric, consequences, countermeasure, IT product category, IT product, IT vendor, software, hardware, privileged program, unprivileged program, cloud type, attacker, attack intent, attack mechanism, attack
[196],
[197] Security mechanism, security tool, security protocol, cryptographic concept, technology, attack
Ontologies for information security management [202], [201], [199], [198], [172], [200]
Active location, introduction phase, vulnerability, IT product, IT vendor, attacker, attack, countermeasure, consequence, attack intent, attack mechanism
[203],
[204] Weakness, attack, vulnerability, platform, countermeasure, configuration, exploit [205] Control type, organization, asset, security attribute, standard control, control, threat, threat source, severity scale,
Countermeasures - Security patch, ..., etc
Vulnerability has Score has Action Impacts -Type has achieve isResultOf Author - Attacker producedBy Severity measuredBy Weakness has Software - Product affects References - SVDBs has Date - Release date,...,etc has
Figure 11: Initial software security vulnerability domain ontology (high-level overview).
Vulnerability. In software security, a vulnerability refers to “an instance of a flaw, caused by a mistake in the design, development, or configuration of software such that it can be exploited to violate some explicit or implicit security policy” [212]. Software vulnerabilities are introduced in
a system by adopting a vulnerable software product, inadvertent coding mistakes by developers (e.g., bad coding practices), executing vulnerable external services (e.g., libraries), etc.
Product. This concept is used for eliciting software vulnerability information. Software product
is an Asset—“anything that has value to the organization” [213], including stakeholder,
information, hardware, and artifacts.
Attackers (or malicious actor) can be considered either internal or external entities of the system
who attack a product. They perform malicious Actions which attempt to break the security of a software system or its components. Security databases are capturing a Vulnerability that has an associated Action and Impact, with an attacker exploiting a vulnerability to produce an Action which has an Impact on the system.
An Attack is a set of intentional unwarranted (malicious) actions designed to compromise and violate software security policies [214]. By analyzing such an attack or vulnerability pattern, analysts can study the behavior of attackers, estimate the cost of attacks, and determine their impact on overall system security.
Security analysts often rely on References found in SVDBs to identify vulnerable system components and to evaluate the potential Impact of such vulnerabilities on other parts of an ecosystem. This information is used to decide on cost-effective Countermeasures to eliminate a risk. When the risk of an attack is higher than the risk tolerance of stakeholders, analysts need to take an adequate Countermeasure to mitigate such risks.
A countermeasure therefore is a protection mechanism employed to secure a software system [197] (e.g., patch development, encryption/decryption enhancement, and updated system security configurations). Available information about the Author of a vulnerability can be used by security analysts to develop countermeasures to protect the system.
Weakness has been proposed as a concept to evaluate the impact of such an attack on the
software system. Score is used to capture the probability of a successful attack and its severity on the system.
Finally, incorporating the concept of Date as part of a vulnerability analysis knowledge base allows for modeling the sequence of actions and exploits employed by attackers. Security analysts can take advantage of this information when designing and evaluating adequate countermeasures.