VEA-bility Analysis of Network Diversification

Transcription

1 VEA-bility Analysis of Network Diversification Melanie Tupper Supervised by Nur Zincir-Heywood Faculty of Computer Science, Dalhousie University August 31, 2007 Abstract: In nature, genetic diversity increases a species' ability to survive when faced with biological, environmental, or predatory threats. In this work, we investigate whether computer networks may benefit from diversification in much the same way. To this end, we compare different network configurations to explore the ability of a computer network to defend itself against threats. In order to compare configurations, we also present a novel security metric, VEA-bility, which measures the desirability of a specific network configuration. Our metric is a numeric value that is computed by considering network vulnerabilities, network topology, intruder connectivity, and an attack graph of the network. The higher the value, the greater the ability of the network to defend against attacks.

2 Acknowledgements I would like to thank The Computer Research Association s Committee on the Status of Women in Computing Research (CRA-W) and The Natural Sciences and Engineering Research Council of Canada (NSERC) for supporting this research. I would like to thank my mentor, Dr Nur Zincir-Heywood for her inspiration and guidance that made this project an enjoyable and rewarding experience. I would like to thank the entire Tech Support team at Dalhousie University for their cooperation and assistance for the duration of this project they made this project possible. I would also like to thank my husband, Stewart Hardie, for his encouragement, love, and support. 1

3 Contents Section 1 - Introduction Motivation Overview... 8 Section 2 Related Work Diversity Security Metrics Section 3 Attack Graphs Section 4 - Methodology Data Collection Feature Selection Virtual Network Modeling and Simulation VEA-bility analysis Section 5 - Results Nessus Scans Results Selected Features Virtual Network Diversification Section 6 Network Example Section 7 Conclusions and Future Work References Appendix A: Sample Attack Graphs Appendix B: Sample XML File Appendix C: Network Configurations Appendix D: Sample Nessus Scan Result Appendix E: Configuration Data

4 List of Figures Figure 2.1 Monoculture Computer Networks...10 Figure 2.2 Diversified Computer Networks...10 Figure 2.3 Diversified Network Example...11 Figure 3.1 Sample Attack Graph...12 Figure 4.1 Base and Diversified Base Configurations...16 Figure 4.2 Initial and Diversified Firewalled Configurations...20 Figure 4.3 Initial and Diversified DMZ Configurations...20 Figure 4.4 Screenshot of Temporal Generation Interface...23 Figure 5.1 A Scan Result Sample...26 Figure 5.2 Average VEA-bility for Diversified Network Configurations...33 Figure 5.3 VEA-bility Distribution...34 Figure 6.1 Network Configuration Figure 6.2 Network Configuration Figure 6.3 Network Configuration Figure 6.4 Network Configuration Figure 6.5 Network Configuration Figure 6.6 Network Configuration Figure 6.7 Network Configuration

5 List of Tables Table 4.1 Virtual Network Configurations...22 Table 5.1 Nessus Scan Results by Operating System...26 Table 5.2 Virtual Network Vulnerabilities...27 Table 5.3 Average V N Dimensin s...29 Table 5.4 Average E N Dimensin s...30 Table 5.5 Average A N Dimensin s...31 Table 5.6 Average VEA-bility s

6 Section 1 Introduction 1.1 Motivation A primary objective for a computer network administrator is to maintain a stable, secure environment for network users. This objective includes ensuring that malicious computer users, known as attackers or intruders, are kept from compromising the network. An intruder exploits vulnerabilities in the software running on hosts within the network to gain access to network resources. The effects of such an exploit can range from low-level information access on one host to remote root access on multiple hosts, often including critical servers. Preventing intruder exploits includes detecting and patching, if possible, any known software vulnerabilities. Software vulnerabilities, most often the result of careless programming, are weaknesses in software that attackers can use to gain or escalate network privileges. A network service running software that is vulnerable is considered to be a vulnerable service. A common vulnerability, known as a buffer overflow or overrun, is the failure to check the size of a data buffer. Other vulnerabilities include format string vulnerabilities and logic errors. An exploit, or attack, is a way for the attacker to take advantage of vulnerabilities and can take the form of a piece of software, sequence of commands, or a block of data. If successful, the intruder will have gained privileges equal to that of the vulnerable program, allowing the intruder to access information or escalate privileges on the target host. Buffer overflow vulnerabilities can be exploited by an attacker by sending input that is too large for the intended buffer. This results in the extra data being overwritten to unauthorized memory locations, allowing the intruder to execute arbitrary code. Another common attack, the denial-ofservice (DoS) attack, occurs when an intruder sends more requests than the system can handle, thus rendering the service unable to process any valid requests. Although a DoS attack does not generally permit intruder access to the target host, this attack may serve as a distraction for a more serious attack on another host within the network. 5

7 There are several online software vulnerability databases, including the Common Vulnerabilities and Exposures (CVE) list [1]. This list is an initiative to standardize vulnerability references and gives vulnerabilities a name in the form CVE-YYYY-XXXX, where YYYY is the year in which the vulnerability was first reported. The CVE list, which is searchable by the CVE name, also provides the status of the vulnerability, a description, and a list of references. Network hardening refers to the various methods that can be employed to secure a system, which includes patching software vulnerabilities. Other ways in which a network can be made more secure is through the addition of firewalls, Demilitarized zones (DMZs), intrusion detection systems (IDSs), or intrusion prevention systems (IPSs). Firewalls and DMZs protect a network by restricting the connectivity of hosts both inside and outside a network. An IDS monitors network traffic and can be configured to alert the administrator to suspicious activity. An IPS not only monitors network activity, but can also react in real time to block or prevent malicious activity. A firewall, which can be either a hardware or software device, restricts the connectivity of hosts outside a network to hosts inside a network, or vice versa, and aims to filter unwanted behavior to or from the network. A DMZ, also known as a perimeter network, is an area between an internal and external network. A DMZ configuration allows hosts on both the internal and external networks to connect to hosts in the DMZ. However, hosts inside the DMZ are generally restricted from connecting to hosts on the internal network. A DMZ configuration serves to protect the internal network from attack should an intruder be able to gain elevated privileges on a host inside the DMZ. Web servers are commonly placed in the DMZ to allow external users to request information while protecting hosts inside the network. An IDS or IPS is a software application that monitors malicious traffic between hosts, including worms and viruses, which would go undetected by a firewall. The presence of this type of unwanted traffic will alert the system administrator to suspicious activity. Even with the best security practices, it is inevitable that systems become vulnerable. A common practice for detecting vulnerabilities on a network employs a vulnerability scanner: a software program that can be used to pinpoint weaknesses in a network. A vulnerability scanner generally 6

8 searches for active IP addresses, then attempts to connect to open ports and determine the operating system and applications running on the host. If a vulnerable service is found, most scanners will identify the related CVE number and assign a risk factor to the vulnerability. A popular, open-source vulnerability scanner, which is available for numerous operating systems, is the Nessus Vulnerability Scanner [2]. Once vulnerabilities have been identified, the administrator can attempt to fix the hole by finding the corresponding vulnerability in one of the online databases, then downloading and applying a software patch, if one is available. While these tools are useful for increasing security, they can only be used on existing physical networks. Since new software vulnerabilities are being discovered at an alarming rate of approximately 18 vulnerabilities per day [3], exploit prevention has become an attractive research area. Network diversification is an emerging trend that is suggested to increase the security of a computer network [4]. In much the same way as biodiversity increases a species likelihood of survival and portfolio diversity increases an investor s chances of receiving a return on investment, network diversification aims to eliminate monoculture configurations by introducing additional hosts, operating systems, and applications into the network. However, to the authors knowledge, there has been no previous research investigating this hypothesis. Thus, the purpose of this research project is to explore the effects of network diversity on network security. Our approach involves 3 phases: (i) A data collection phase; (ii) An experimental phase; and (iii) An evaluation phase. In the data collection phase, we use a vulnerability scanner to gather host information from the test bed. An important aspect of this research is the ability to model realistic network topologies with known vulnerabilities. For this reason, we use a set of hosts on the Faculty of Computer Science network at Dalhousie University as our test bed. In the experimental phase, we use the data collected to model diversified networks from initial configurations, including known vulnerabilities. To this end, we use a software package to generate an attack graph, which is a tree based data structure describing all known courses of actions that an attacker can take to compromise the network. 7

9 In the final phase, evaluation, we propose a novel quantitative metric, VEA-bility, which can be used to compare different network configurations. The underlying idea behind our VEA-bility metric is that the security of a network is influenced by many factors, including the severity of existing vulnerabilities, distribution of services, connectivity of hosts, and possible attack paths. These factors are modeled into three network dimensions: vulnerability, exploitability, and attackability. The VEA-bility score, a numeric value in the range [0,10], is a function of these three dimensions. Based on our findings, we conclude that the diversification theory, when properly applied, can be employed to increase the security of a network. These conclusions are important to network administrators as they strive to provide secure, yet functional, network configurations. 1.2 Overview The following section, Section 2, provides an overview of network diversification and security metrics. Section 3 gives a detailed description of attack graphs. Section 4 reviews each phase of our research and Section 5 summarizes our results. Section 6 provides an example of our VEAbility metric applied to a diversified network. Section 7 presents our conclusions and suggests further directions for this research. 8

10 Section 2 Related Work 2.1 Diversity While network diversification is only an emerging strategy, the benefits of diverse populations have been extensively researched in many disciplines, including biology and economics. Biodiversity, the variation of life, has three levels: genetic diversity, species diversity, and ecosystem diversity [5]. While all three are essential to survival, we use the genetic level to demonstrate how diversity can impact the survival of a species or population. Genetic diversity refers to the differences in the raw material of a species; DNA and RNA are two forms of this raw material. It is this raw material that makes it possible for a species to evolve and adapt, thus surviving biological, environmental, or predatory threats. A decline in the number of individuals in a population lowers the genetic variability, which is common in endangered species. One such species that is vulnerable to extinction due to the lack of genetic variation is the cheetah. The few cheetah populations that do remain are being forced to compete for resources in limited and diminishing habitats. The cheetah s limited genetic diversity may affect their ability to adapt to these environmental changes, further limiting their chances of survival. Diversification in finance involves choosing different investments to comprise a portfolio. Two general categories of financial diversification are horizontal and vertical. Horizontal diversification refers to diversity among the same type of investment, stocks, for example. Vertical diversification refers to investing in different types of investments such as stocks, bonds and mutual funds. The main benefit of portfolio diversification is reduced risk. This strategy relies on historical evidence that it is unlikely that different investments will simultaneously move in the same direction, thus reducing the risk. 9

11 Figure 2.1 depicts a monoculture computer network consisting of hosts running the same operating system and offering like services. A firewall is used solely to illustrate the idea of an internal network. An example of a monoculture network would be a computer lab where the operating system and services on each machine are similar, if not identical. If an attacker were able to compromise one host, it is likely that the attacker would be able to compromise every host on the network. Unfortunately, the monoculture configuration approach is common in many organizations due to limited resources, including time, money, and network administration personnel. Figure 2.1 Monoculture Computer Network On the other hand, Figure 2.2 demonstrates how a network can be diversified by dispersing the network services among hosts running different operating systems. Industry professionals propose that monoculture networks can benefit from diversity strategies in much the same way as species benefit from genetic diversity and investors benefit from diverse portfolios [4,6,7]. As the saying goes, Don t put all your eggs in one basket! Figure 2.2 Diversified Computer Network 10

12 Jajodia et al. [8] attempt to demonstrate that network diversity is not always beneficial to a network. Although we do not disagree with their conclusion, that is, we agree that it is possible to obtain a less secure network through diversification, we believe that in order to make such a claim, a thorough investigation is needed providing examples to show whether the result they obtained is typical or exceptional. Their example case, shown in Figure 2.3, compares two firewalled configurations, which we refer to as configuration 1 and configuration 2. The internal network in configuration 1 consists of a vulnerable mail server running on a Linux host, an ftp directory running on a Linux host, and a Database Management System (DBMS) running on a FreeBSD host. Configuration 2 includes an additional vulnerable mail server running on a Windows 2000 host. Figure 2.3 Diversified Network Example Jajodia et al. [8] state that a network configuration that has less attack paths is considered to be more secure. They argue that since configuration 2 has twice as many attack paths as configuration 1, configuration 2 is less secure which shows that diversification may be detrimental to a network. However, the main purpose of their work is the proposition of a security metric that does not consider the number of attack paths. While we agree that the number of attack paths to the target host should be considered, we believe this exemplifies the need to include a myriad of factors when determining the level of security offered by a network configuration. 11

13 2.2 Security Metrics Comparing the desirability of different network configurations requires a security metric. In general, a metric is a quantifiable measurement that allows for comparison. A security metric can be either qualitative or quantitative, and measures the degree of security controls, policies and procedures. For a security administrator, a security metric allows for comparison of different network configurations. When reviewing related work, our primary interest lies with quantitative security metrics that generate a numeric score. Jajodia et al. [8] present such a metric based on the strength of the weakest adversary that can compromise the network. The algorithm they present starts with a goal state and works in reverse, decomposing the requirements for the previous network state until an initial state is found. This produces the minimum set of initial attributes that an attacker would need to compromise a specified host and can be compared to other configurations. Manadhata et al. [9] use an attack surface metric to compare the attack surfaces of two ftp servers. Although this research does not offer a metric to compare the security of networks, the contributions of this paper inspire us to consider a security metric for a network with multiple dimensions. Their metric computes a discrete score for each of their three proposed dimensions: methods, channels, and data. The metric proposed by Adedin et al. [10] to evaluate network security policies generates one unified score that is a weighted aggregation of different factors. These factors include existing network vulnerabilities, vulnerability history of exposed services, exposure of services, and traffic volumes handled by services. In calculating the Existing Vulnerability Measure (EVM), this metric uses an exponential average to ensure that the resulting score will be at least as high as the highest vulnerability score present in the system. Additional vulnerabilities serve only to increase this score. We also use an aggregated, unified security score as well as exponential averages in our own VEA-bility metric for network security. Another tool we use in calculating the VEA-bility of a network is an attack graph. The next section details how an attack graph is generated, the information it represents, and how we use this information in our VEA-bility metric. 12

14 Section 3 Attack Graphs While identifying single vulnerabilities is useful, the security threat increases exponentially with multiple network vulnerabilities. One way to explore the effects of multiple vulnerabilities on a network is through an attack graph. An attack graph is a pictorial representation of the paths an attacker can take to exploit network vulnerabilities. The paths in the graph, known as attack paths, represent all the ways an intruder can penetrate the network. This can be used by a network administrator to identify how vulnerable the network is and what hardening measures should be taken to thwart attacks. Generation of an attack graph requires an attack model and a wealth of information regarding network topology and existing vulnerabilities. The network is usually modeled as state-machine where the nodes of the resulting attack graph represent a network state and the graph edges represent transitions, including actions taken by the attacker. Traditionally, attack graphs were produced manually by groups known as Red Teams who would generate hand drawn attack graphs on a large white board. Since attack graphs scale exponentially, this requires a substantial commitment of time and resources. Several software packages have been designed to automate the production of attack graphs, many of which are discussed in the following section. The main challenge of automating the generation of attack graphs is the exponential scaling of the graph with additional vulnerabilities. Most automated attack graph generators produce a pruned attack graph; the graph generated contains all the paths to a specific target host as opposed to the whole network. This type of graph can be aggregated for each host to comprise a network attack graph. A pruned attack graph is useful to an administrator wishing to protect a critical server. As the name suggests, a critical server offers essential network services; therefore, the security of a critical server is given a higher priority than other hosts on the network. When the critical server is identified as the target host, the pruned attack graph will identify attack paths to the critical server but not to other hosts on the network. 13

15 Network attack graphs are considered to be valuable tools for evaluating the security of a network. Therefore, much work has been done in the area of automated attack graph generation and analysis. Amman et al. [11] present an algorithm that scales well, and is implemented by Jajodia et al. [12] in their Topological Vulnerability Analysis (TVA) tool. The TVA tool automatically imports results from Nessus scans, but also requires that exploit and goal state information be entered by hand. TVA does not model firewall and router rules into the network model, but rather, relies on data collected from the Nessus scans to determine host connectivity. Since TVA requires Nessus scan info, it can only be used on an actual network and not on virtual networks or network simulations directly. Michael Artz s NetSPA tool [13] also requires information collected form Nessus scans, but must be entered into a database by hand. The NetSPA architecture relies on a software database and an action database to generate the network model. Software database entries can either be populated by hand or directly from an online vulnerability database. Action database entries must be entered manually and are used to model pre-conditions and post-conditions of intruder actions. The toolkit developed by Sheyner et al. [14] requires a user defined XML file describing the network for input. Therefore, this file can describe both virtual networks as well as existing physical networks, allowing analysts to consider alternate configurations before implementation. The input file specifies host information, connectivity among hosts, trust relations, a model of the intruder, intruder actions, and IDS information. This toolkit generates a pruned attack graph to a specified host. Although this toolkit does not produce a full attack graph, individual attack graphs to specific hosst can be combined if required. Our original research goal involved comparing the different automated attack graph generation software packages as described above on a test bed to determine which implementation had the most potential for further development. However, in spite of our efforts, we were only able to obtain a copy of one toolkit, which prompted the current research direction to use this toolkit to study the effects of diversity on security. 14

16 Our research uses a toolkit based on the work of Sheyner et al. This toolkit has been updated and is currently being maintained by David Swasey and is freely available for download [15]. We refer to this updated toolkit as the Sheyner/Swasey toolkit since the original toolkit designed by Sheyner et al. is still available, but not supported. Figure 3.1 is an example of a simple attack graph produced by the Sheyner/Swasey toolkit. The network configuration consists of one attacker and two internal hosts, A and B, each running one vulnerable service. For simplicity, we assume no restrictions on connectivity. Figure 3.1 Sample Attack Graph This is a pruned attack graph representing the attack paths to host A. Transitions from a parent node to a child are the result of a state change, represented as edges, and stored as Boolean values. Node 0 represents the initial state of the network with a simple transition to Node 1, most likely as the result of a network scan. Node 2 represents the attacker gaining access to host B, which is used to gain user access to host A (Node 3). The attacker escalates the privilege to root, resulting in Node 4. Alternatively, the attacker can directly gain user access to host A, Node 5, and escalate the user privilege to root, resulting in Node 6. Examples of other attack graphs can be found in Appendix A. 15

17 Section 4 Methodology 4.1 Data Collection Our goal to produce realistic virtual networks prompted us to seek permission to use the Dalhousie University network as our test bed. To accurately model networks mimicking the test bed, we use the Nessus Vulnerability Scanner to collect network topology information. The Nessus Scanner is an attractive research tool primarily because it allows safe checks. When the scanner is configured to scan a network using this option it will not attempt to exploit vulnerabilities, enabling us to compile vulnerability information without causing harmful Denial of Service (DoS) attacks. We run the scans from a Windows XP platform; however, the Nessus Scanner is also available for Mac OS X, Linux, FreeBSD, and Solaris. The Windows installation automatically installs and configures both server and client software, which may need to be configured separately for other operating systems. The Nessus Scanner gathers information by sending requests to all ports on hosts identified in the scan parameters. We use the scanner s default settings, but limit the number of hosts scanned for each scan to 20. The default range is 40 hosts per scan, as suggested in the Nessus 3.0 Client Guide [16]; however, we limit the number of hosts to 20 to further reduce the risk of overwhelming the system. The scan results are saved in XML format, but can also be viewed and resaved in plain text. In total, we scan 250 hosts, and generate results for 85 of these hosts. Failure to generate a report indicates that the Nessus Scanner was unable to connect to that host, and therefore, unable to extract any host information. The test bed is comprised of hosts located in diverse physical locations on the network, and includes network servers, faculty machines, and student machines. 16

18 4.2 Feature Selection The purpose of the Nessus scans is to model a realistic virtual network, which requires a wealth of host information. From the scan results we extract the following information: IP address Operating System Number of open ports Number of notes Number of warnings Number of holes Port number and corresponding services running on the open port CVE identification numbers and risk factors associated with vulnerabilities The magnitude of information requires that we construct a more compact representation of data from which to choose a set of operating systems to use in our experiments. We reorganize the host information into categories by operating system, further decomposing the operating systems by version or distribution. For each category we record: Number of hosts Number of warnings Number of holes Number of hosts with at least 1 vulnerability in each of the three highest risk categories After choosing three suitable operating systems we refer back to the original table to isolate similar vulnerabilities, also referring extensively to the National Vulnerability Database [17] to compare vulnerability characteristics including CVSS base score, access vector, access complexity, authentication, impact type, and age. We are concerned with these characteristics 17

19 because they express the severity of the vulnerability. By limiting the variation among these characteristics, we assure that our experiments measure the effects of different network configurations as opposed to different vulnerability characteristics. 4.3 Virtual Network Modeling and Simulation Before explaining how we diversify our virtual networks, it is important to understand what we mean by the term diversification. We define the diversification of a network as altering the topology of a network by redistributing services among additional hosts running either the same or another operating system as the original configuration. We model our diverse virtual networks into XML files to produce attack graphs using the Sheyner/Swasey toolkit. We chose this toolkit because of its availability, GUI interface, and ability to model virtual networks. Each XML file describes a network attack model comprised of the following components: Set of hosts connected to the network including operating system, IP address, vulnerabilities, open ports, and corresponding services; Connectivity information describing network topology and host reachability; Trust relations among hosts; Intruder information including connectivity information and level of privilege the intruder has on each of the other hosts; Set of exploits including CVE of exploited vulnerability, name, description, local and global exploit preconditions, and local and global exploit effects; A model of the intrusion detection system. Following the model provided by Sheyner et al. [14], we do not model trust relations among hosts within the network. We use the Sheyner/Swasey toolkit to generate attack graphs for each 18

20 configuration. The toolkit produces a pruned attack graph to a specified target host; therefore, a separate file must be generated for each host inside the network. Relevant data recorded includes number of nodes, number of edges, number of attack paths, and number of ways to traverse the network. A sample XML file can be found in Appendix B. We begin our modeling with the following three topologies: 1. One intruder and one network host running four services on Solaris Apache vulnerability 2. One intruder and one network host running four services on Windows rpc vulnerability 3. One intruder and one network host running four services on Linux ftp vulnerability These three topologies are considered to be the base configurations. We purposefully start with configurations that result in a low VEA-bility score, and then test the effects of diversification by adding additional hosts and operating systems; we refer to these diversified configurations as the diversified base configurations. Figure 4.1 depicts the Linux base configuration and a diversified configuration with 2 hosts running different operating systems. Figure 4.1 Base and Diversified Base Configurations We then add a firewall or DMZ to the base configurations to produce three initial firewalled configurations and three initial DMZ configurations, respectively. These new configurations act as a control and are also diversified by adding hosts and additional operating systems to produce diversified firewalled configurations and diversified DMZ configurations. The DMZ 19

21 configurations are constructed by isolating the host running a web server in the DMZ. This results in 12 fewer configurations since some configurations are duplicated. Figure 4.2 shows an initial firewall configuration and a diversified firewall configuration with 2 operating systems. Figure 7 depicts an initial DMZ configuration and a diversified DMZ configuration with 3 operating systems. Figure 4.2 Initial and Diversified Firewalled Configurations Figure 4.3 Initial and Diversified DMZ Configurations 20

22 In total, we test 303 configurations: 3 base configurations 24 diversified base configuration with 1 operating system 42 diversified base configurations with 2 operating systems 36 diversified base configurations with 3 operating systems 3 initial firewalled configurations 24 diversified firewalled configurations with 1 operating system 42 diversified firewalled configurations with 2 operating systems 36 diversified firewalled configurations with 3 operating systems 3 initial DMZ configurations 12 diversified DMZ configurations with 1 operating system 42 diversified DMZ configurations with 2 operating systems 36 diversified DMZ configurations with 3 operating systems Firewalled and DMZ configurations act initially as a control to show the level of security that can be achieved without diversification. Firewalls and DMZs are tools that administrators often use to increase the security of a network; therefore, we diversify the initial firewalled and DMZ configurations to show how the diversification approach in combination with existing security strategies can further affect security. A detailed verbal description of the test configurations can be found in Appendix C. 21

23 Table 4.1 matches the configurations in each category with the descriptions in Appendix C. Table 4.1 Virtual Network Configurations Configuration group Number of Configurations in group Corresponding Configurations in Appendix C Base configurations 3 1, 10, 19 Diversified base configurations with 1 operating system Diversified base configurations with 2 operating systems Diversified base configurations with 3 operating systems , 11-18, Initial firewalled configurations 3 106, 115, 124 Diversified firewalled configurations with 1 operating system Diversified firewalled configurations with 2 operating systems Diversified firewalled configurations with 3 operating systems , , Initial DMZ configurations 3 211, 216, 221 Diversified DMZ configurations with 1 operating system Diversified DMZ configurations with 2 operating systems Diversified DMZ configurations with 3 operating syatems , ,

24 4.4 VEA-bility analysis Given that the objective of this work is to explore the effects of diversification on network security, a metric is required to compare the different aforementioned network configurations. Thus, a security metric is defined to capture the numerous factors that influence the security of a network. To this end, we propose the VEA-bility metric to be a function of the security scores along three dimensions: vulnerability, exploitability, and attackability. For the sake of simplicity, the vulnerability, exploitability, and attackability scores will be represented in equations as V, E, and A, respectively. Each of the three dimension scores is a numeric value in the range [0,10]. The VEA-bility metric uses data from three sources: network topology, attack graphs, and scores as assigned by the Common Vulnerability Scoring System (CVSS) [18]. VEA-bility uses the following CVSS values: impact score, temporal score, and exploitability score. The impact score measures the impact that a successful exploit will have on the availability, integrity, and accessibility of information resources. The temporal score assigns a value based on the age of the vulnerability, the remediation status of a patch, and the credibility of the patch source. The vulnerability of a network is the degree to which an exploit can impact a system; a measure that is influence by time. Therefore, our vulnerability dimension is a function of the impact and temporal scores. Figure 4.4 shows a screenshot of the online temporal score interface. Our exploitability dimension is a function of the exploitability score, which evaluates the likelihood of exploitation. Temporal Metrics These metrics describe elements about the vulnerability that change over time. If all of these values are left as 'Undefined', the environmental score will be based on the base score. Availability of exploit (Exploitability) Functional exploit exists Type of fix available (RemediationLevel) Official fix Level of verification that vulnerability exists (ReportConfidence) Confirmed Figure 4.4 Screenshot of Temporal Generation Interface 23

25 Since a network is only as secure as its host, we define the three dimensions for a network configuration as a function of the three dimensions for each host on the network. The vulnerability score of a network is the exponential average of the vulnerability scores of each host on the network, or a maximum of 10. This captures the requirement that the vulnerability score of the network is at least as large as the largest host vulnerability score; additional vulnerable hosts serve only to increase this value, which can be a maximum of 10. The exploitability and attackability scores of a network are the summation of the exploitability and attackability scores of each host, respectively. Therefore, the following equations represent the Vulnerability, Exploitability, and Attackability dimension scores for a network: For a network, N, let HV(N) be the set of hosts in N that contain vulnerabilities. A network void of vulnerabilities scores a 0 along each dimension; otherwise, we define the network dimensions: Vhost V N = min(10, ln e ) host HV ( N ) E N = host HV ( N ) E host A N = host HV ( N ) A host We propose that a host with multiple vulnerabilities is less secure than a host with a single vulnerability, which is modeled into the vulnerability and attackability dimensions by taking the exponential average of the values for all vulnerabilities. Again, this allows the value to be at least as large as the highest value, and additional scores serve to increase this value to a maximum value of 10. Let each vulnerability, v, have an impact score, temporal score, and exploitability score as defined by the CVSS [18]. An impact and exploitability sub-scores are automatically generated for each CVE name, the temporal score requires user input. 24

26 We define the severity, S, of a vulnerability to be the average of the impact and temporal scores: S v = (Impact v + Temporal v ) / 2 The host vulnerability score is an exponential average of the severity scores of the vulnerabilities on a host, or 10, whichever is lower. The exploitability is the exponential average of the exploitability score for all host vulnerabilities multiplied by the ratio of network services on the host. Attackability is the ratio of attack paths produced by attack graphs to total number of attack paths, and is multiplied by a factor of 10 to produce a number in the range [0,10], ensuring that all dimensions have the same range. For a host, host, let V(host) be the set of vulnerabilities on a host. We then define the three host dimensions as: V host = min(10, ln e Sv ) v V ( host ) Exploitability v E host = (min(10, ln e )) ( services on host) / ( network services) v V ( host ) A host = (10) (attack paths) / ( network paths) The final equation for network VEA-bility is: VEA-bility N = 10 ((V+E+A) N / 3) According to the NIST Security Metrics Guide for Information Technology Systems [19], a metric must yield quantifiable information, be useful for tracking system performance, measure a repeatable process, and supporting data must be readily obtainable. The metric we propose, VEA-bility, conforms to these standards in that it is quantifiable, that is, it is expressed as a numeric value in the range [0,10]. By using the Nessus scanner and the Sheyner/Swasey toolkit, both freely available online, the methods we employ can be easily duplicated. Also, this metric serves to track the performance of a network configuration by comparing the score to other possible configurations. Thus, a network administrator can use the VEA-bility metric to direct or reallocate resources. 25

27 Section 5 Results 5.1 Nessus Scans Results Scan results can be viewed in HTML, XML or plaintext format. Figure 5.1 is an excerpt from one of the resulting plaintext output files; the complete result can be found in Appendix D. An example is provided to show the structure of the report and type of information provided. All IP address references and other information that could potentially identify this host have been removed. surf (1010/tcp) NOTE Port is open; surf (1010/tcp) NOTE RPC program version 1 'status' is running on this port;; vnc (5900/tcp) NOTE The remote VNC server supports those security types:;+ 30;; netbios-ssn (139/tcp) NOTE An SMB server is running on this port; Figure 5.1. A Scan Result Sample Due to the nature of the information, we are unable to publish our original table of results. However, Table 5.1 presents a summary of the data we obtained to select three suitable operating systems. Table 5.1. Nessus Scan Results by Operating System Operating System Hosts Warnings Holes hosts with 1+ medium CVE hosts with 1+ high CVE hosts with 1+ critical CVE Mac OS X Windows Linux Solaris FreeBSD

28 5.2 Selected Features From Table 5.1, we choose to model our networks using Linux, Solaris, and Windows operating systems. These were chosen because we were able to identify similar vulnerabilities on each operating system on our test bed. Table 5.2 summarizes the identified vulnerabilities. Table 5.2 Virtual Network Vulnerabilities Operating System Vulnerable Service CVE Name Description Linux File Transfer Protocol (ftp) CVE Buffer overflow Solaris Apache (web) CVE Heap-based buffer overflow Windows Remote Procedure Call (rpc) CVE Stack-based buffer overflow All three vulnerabilities have a CVSS base score of 10. They are network exploitable and low complexity. They do not require authentication, but do provide administrator access. Finally, all were first reported in We believe that by keeping the exploits similar, the resulting VEAbility scores will reflect the effects of changes in the network configurations and will not be influenced by different vulnerability factors. In all experiment scenarios, a tested virtual network offers the following services: rpc on port 135, web server on port 80, ftp server on port 21 and a database. Port numbers are assigned to network exposed services as required to model the XML files. The database service is for illustration only and represents any critical service running on the network; it is used to show how a critical service could be exploited without being directly exposed to the network. 27

29 5.3 Virtual Network Diversification Detailed results for each network configuration tested can be found in Appendix E. These results correspond to the configurations in Appendix C. For each configuration, we have recorded the impact score, temporal score, exploitability score, number of attack paths, number of ways to traverse the network, network dimension scores, and the VEA-bility score of the network. As discussed earlier, the vulnerabilities were intentionally chosen to be similar as not to skew the results. As a consequence, the severity, S, of the three vulnerabilities is constant. A temporal score of 8.7 was generated by using the online metric with availability of exploit field set to widespread, the type of fix available field set to Official Fix, and the Level of verification that vulnerability exists field set to Confirmed. The severity score for the three vulnerabilities is: S v = (Impact v + Temporal v ) / 2 = ( ) / 2 = 9.35 We are only dealing with one vulnerability per host; therefore, V host = S v = 9.35 if a vulnerability exists, and 0 otherwise. Our network configurations may have either 0, 1, 2, or three hosts, the respective V N values will be 0, 9.35, 10, and 10. This demonstrates the value of using an exponential average. A network with one vulnerability has a vulnerability dimension value of 9.35 since this is the only vulnerability. However, when there are more vulnerabilities, the risk to the network is greater than 9.35 depending on the severity of the additional vulnerabilities. A simple average of severity scores would yield a 9.35 rating for a configuration with 2 vulnerabilities, which would not accurately represent the increased risk. 28

30 Due to the large dataset, comparing individual results is not practical. Therefore, in Table 5.3, we present the average vulnerability dimension scores for comparison. A higher score indicates a more vulnerable network configuration. Table 5.3 Average V N Dimension s Configuration Average V N Dimension Base configurations 9.35 Initial firewalled configurations 9.35 Initial DMZ configurations 9.35 Diversified base configurations with 1 O/S 9.35 Diversified base configurations with 2 O/S 6.86 Diversified base configurations with 3 O/S 6.40 Diversified firewalled configurations with 1 O/S 9.35 Diversified firewalled configurations with 2 O/S 6.86 Diversified firewalled configurations with 3 O/S 6.40 Diversified DMZ configurations with 1 O/S 9.35 Diversified DMZ configurations with 2 O/S 6.86 Diversified DMZ configurations with 3 O/S 6.40 These results indicate that with diversification by adding different operating systems it is possible to reduce the vulnerability of a network. This occurs since running a vulnerable service on a different operating system removes the vulnerability, provided the software is not vulnerable on the alternate operating system. It should be noted here that, based on our experiments, the addition of firewalls and DMZs seems to affect connectivity only and has no effect on the network vulnerability dimension. 29

31 Limiting vulnerabilities to one per host results in the following calculation: E host = (Exploitability v ) ( services on host) / ( network services) The E N score is then the summation of E host values. Table 5.4 shows the average exploitability dimension scores, E N, for each configuration category. A higher score indicates a more exploitable network configuration. Table 5.4 Average E N Dimension s Configuration Average E N Dimension Base configurations 10 Initial firewalled configurations 10 Initial DMZ configurations 5.8 Diversified base configurations with 1 O/S 5.3 Diversified base configurations with 2 O/S 5.7 Diversified base configurations with 3 O/S 3.8 Diversified firewalled configurations with 1 O/S 5.3 Diversified firewalled configurations with 2 O/S 5.7 Diversified firewalled configurations with 3 O/S 3.8 Diversified DMZ configurations with 1 O/S 3.3 Diversified DMZ configurations with 2 O/S 3.9 Diversified DMZ configurations with 3 O/S 3.1 These results show that exploitability is best controlled by the addition of a DMZ, but can be improved through diversification. Since the exploitability dimension is related to the number of services on hosts with vulnerabilities, it seems to reason that isolating the web server on a host will best affect this dimension. 30

32 Attackability is a function of the ratio of attack paths to total paths through the network. This ratio is multiplied by 10 to generate a number compatible with the other two dimensions. Average attackability, A N, dimension scores for each configuration category are presented in Table 5.5. A higher score indicates a more attackable network configuration. Table 5.5 Average A N Dimension s Configuration Average A N Dimension Base configurations 10 Initial firewalled configurations 6.7 Initial DMZ configurations 1.7 Diversified base configurations with 1 O/S 2.2 Diversified base configurations with 2 O/S 3.9 Diversified base configurations with 3 O/S 1.6 Diversified firewalled configurations with 1 O/S 1.5 Diversified firewalled configurations with 2 O/S 2.6 Diversified firewalled configurations with 3 O/S 1.0 Diversified DMZ configurations with 1 O/S.6 Diversified DMZ configurations with 2 O/S 1.3 Diversified DMZ configurations with 3 O/S 1.1 These figures highlight both the benefits of diversity and a DMZ on the network security as represented in the attack graphs. While many system administrators use attack graphs alone to evaluate the security of a network [14], we propose that they are more useful when aggregated with other network factors. 31

33 For example, consider a vulnerable host on a network that cannot be exploited due to connectivity restrictions. We consider this network less secure than a network with no software vulnerabilities, but more secure than a network with no connectivity restrictions. This is reflected in our VEA-bility metric score. The overall average VEA-bility scores are found below in Table 5.6. A higher score indicates a more secure configuration, which we call more VEA-ble. Table 5.6 Average VEA-bility s Configuration Average VEA-bility Base configurations.2 Initial firewalled configurations.6 Initial DMZ configurations 4.4 Diversified base configurations with 1 O/S 4.4 Diversified base configurations with 2 O/S 4.5 Diversified base configurations with 3 O/S 6.1 Diversified firewalled configurations with 1 O/S 4.6 Diversified firewalled configurations with 2 O/S 5.0 Diversified firewalled configurations with 3 O/S 6.3 Diversified DMZ configurations with 1 O/S 5.6 Diversified DMZ configurations with 2 O/S 5.8 Diversified DMZ configurations with 3 O/S 6.5 Although these scores are averages, it is evident that it is possible to increase the security rating of a network configuration through diversification. Figure 5.1 is a pictorial representation of this data which highlights the benefits of diversification alone or in combination with a firewall or DMZ. 32

34 The significant advantage of network diversity is apparent when comparing the average scores for the diversified base configurations with three operating systems to the diversified DMZ configurations with three operating systems. As indicated, the DMZ adds only.4 to the final VEA-bility score. Average VEA-bility of Diverse Network Configurations No Firewall Firewall DMZ Initial Configurations Same O/S Two O/S Three O/S Figure 5.2 Average VEA-bility for Diversified Network Configurations 33

35 The following table shows the distribution of diversified network VEA-bility scores. Although it is possible to decrease security, the tables show the distribution of configurations which resulted in lower and higher VEA-bility scores than the average initial scores of.22,.6, and 4.4. To reduce influencing the results by including firewalled and DMZ configurations, we divide the results into three categories: base, firewalled, and DMZ. VEA-bility Distribution Less VEA-ble More VEA-ble Percentage of Hosts Base Firewalled DMZ Figure 5.3 VEA-bility Distribution 34