• No results found

Vulnerability and attack classification

2. BACKGROUND & RELATED WORK

2.2 COMPUTER SYSTEM VULNERABILITIES & ATTACKS

2.2.2 Vulnerability and attack classification

There are many works published addressing specific domains and root causes of vulnerabilities, and there is a considerable diversity of vulnerability classifications. These classifications allow specialists to collect statistics, to perform trend analysis, to check the correlation with exploits, and to evaluate the effectiveness of countermeasures. In the context of our work, these classifications allows us to organize vulnerability information collected from the field and study the impact and exploitability of vulnerabilities under the same group.

An overview of vulnerability classifications can be found in (Meunier 2008) and they are summarized as follows:

categorize vulnerabilities according to the moment when they were introduced in the software lifecycle (feasibility study, requirements definition, design, implementation, integration and testing, and operations and maintenance). The downside of this approach is that a vulnerability can be introduced in multiple points of the development cycle and this classification is not always applicable. Examples of software development lifecycle classifications are found at (Dowd, McDonald, and Schuh 2006), (J. D. Howard and Meunier 2002), and (Piessens 2002).

Classification by genesis. This approach aims to categorize vulnerabilities according to security flaws (the conditions or circumstances that lead to, for instance, denial of service, unauthorized disclosure, unauthorized modification of data, etc.). According to this approach the parts of software code or configuration that can cause a security compromise are used to classify the vulnerabilities. Examples of these classifications can be found at (S. Weber, Karger, and Paradkar 2005) and (Landwehr et al. 1994).

Classification by errors or mistakes. This aims to categorize vulnerabilities according to human errors or mistakes, considering error cause (e.g., validation error, domain error), impact (e.g., execution of code, access target resource), and fix (missing entity). The limitation here resides in the fact that it not always possible to determine the exact point of a vulnerability. An example of this classification is found at (Du and Mathur 1998).

Classification by enabling attack scenario. This approach aims to categorize vulnerabilities according to the attacks mounted to exploit vulnerabilities. For example, “cross-site scripting” (“XSS”) is an attack scenario, and “XSS vulnerabilities” are vulnerabilities enabling the injection of scripting code into web-based content. One concern here is that in certain cases a category is more directed to the consequence of the attack (e.g., denial of service) and is not helpful to guide users to identify the cause of the vulnerability. An example of this classification in the field of network protocol is present in (V. Pothamsetty and Akyol 2004). As exemplified, there are several approaches to classify vulnerabilities and each one of them has inherent limitations. In our view, the most important factor of a vulnerability classification is the ability it provides to users and developers to quickly identify system weaknesses (errors, mistakes, etc.) that might result in a vulnerability. Using the knowledge about the origin of a vulnerability (e.g., an improper input validation, etc.), developers can make their code more secure and

avoid the causes leading to vulnerabilities in the future. This means that, in our opinion, the most useful and relevant classifications are those that classify vulnerabilities by genesis and by errors and mistakes. One important contribution in this direction (and that we apply in the present thesis to classify vulnerabilities) is the Common Weakness Enumeration (CWE), which is maintained by MITRE sponsored by the U.S. Department of Homeland Security (CWE 2012). CWE is a dictionary of software weakness type that has become widely used to classify the causes of software vulnerabilities. Each weakness has an identifier (CWE- ID), where ID is the identification of the weakness in the CWE platform. For each weakness, there is a web page containing several details about the software weakness, including the common consequences, the likelihood of exploit, detection methods, examples, and etc. Taking CWE-89 as example, it is possible to obtain the full description of the weakness, along with time of introduction (architecture and design, implementation, operation), applicable platforms, modes of introduction, common consequences to the security attributes (confidentiality, integrity, and availability), likelihood of exploit, enabling factors for exploitation, detection methods, and demonstrative examples. It is worth noting that there are other efforts to enumerate and classify vulnerabilities, such as the PLOVER (Preliminary List of Vulnerability examples of Researchers), (Christey 2005), (R. A. Martin and Barnum 2008), and (R. A. Martin, Christey, and Jarzombek 2005). However, none of them has the details and the community acceptance of CWE. We can also find a diversity of attacks classifications in the literature. The following are some examples:

Network and computer attacks taxonomy. (Hansman and Hunt 2005) proposed a taxonomy for network and computer attacks. The proposed taxonomy consists of four dimensions. The first dimension covers the attack vector (means by which the attack reaches the target) such as viruses, worms, network attacks, physical attacks. The second dimension classifies the target of the attacks such as computer, operating system, application, network, and so on. The vulnerabilities and the exploits attacks uses are classified in the third dimension. Any additional effect of the attack or malicious component that is installed in the attack (e.g., Trojan horse termed by the authors as payload) is addressed in the fourth dimension.

Attack-centric and defense-centric taxonomy. Attack-centric taxonomies based on the objective of the attackers (e.g., steal information, bring the target down), while those based on defender goals (e.g., avoid information disclosure, keep the target available in the presence of

attacks) are defense-centric. (Killourhy, Maxion, and Tan 2004) proposed a defense-centric taxonomy based on attacks manifestations. This consists of building an experimental setup to emulate realistic attacks, observe the effects of these attacks, and then categorize the possible ways to defend the system against the attacks.

Signature classification. This refers to taxonomies based on the pattern by which an attack is detected. The evidence category refers to the patterns that are left behind by an attacker (presence of certain files, permission on certain files) that can be evaluated by inspecting the state of the attacked system. The interval and duration of an attack may also be evaluated and are covered in the sequence signature category. An example of this classification is found at (Kumar 1995).

Attack-effect classification. This refers to taxonomies that classify attacks based on the intended effect of the act (e.g., elevation of attack privileges). Examples of this classification are found at (J. D. Howard and Longstaff 1998; Lindqvist and Jonsson 1997; Ranum 1997; D. J. Weber 1998).

Attack threat classification. This refers to classifications that categorize the potential attacks that a system may be targeted by. (M. Howard and LeBlanc 2002) proposed a classification scheme named as STRIDE that characterizes known threats in accordance with the motivation of the attacker, for example: spoofing (e.g., stealing of user identity on systems), tampering (modification of system data without authorization), repudiation (e.g., denial of access of authorized users to a given system), information disclosure (reading of private content without proper authorization), denial of service, and elevation of privileges. Note that this kind of classification may be part of a treat modeling effort aimed at mapping possible threats against a system, such as the Trike methodology described at (Saitta, Larcom, and Eddington 2005). Although useful, these approaches do not guarantee that all possible threats are identified and categorized, since the threat analysis relies on the experience of the security specialist to map potential attacks and threat categories.

In the context of our work, a useful attack classification is the one that allows users to understand the effect of an attack to the system, as in the case of attack-effect classification. Although the knowledge of the attack vector or signature of an attack may be useful, our main concern resides in identifying the most harmful attacks. An important contribution in this regard is the Common Attack Pattern Enumeration and Classification (CAPEC 2014), also

maintained by MITRE and sponsored by the U.S. Department of Homeland Security. CAPEC is an attack dictionary that contains comprehensive information about the nature, characteristic and effects of attacks. Examples of attack information provided by CAPEC are attack description and category, execution flow, exploit techniques, solutions and mitigations, and also typical severity and likelihood of exploit. In our work, we take advantage of attack implementation techniques provided by CAPEC to guide users to build the experimental part of our security benchmark methodology.