text:
Continuous Security Metrics for Prevalent Network Threats: Introduction and First Four Metrics
- Nicholas Craig
- 3 years ago
- Views:
1 ESC-TR Project Report IA-3 Continuous Security Metrics for Prevalent Network Threats: Introduction and First Four Metrics R.P. Lippmann J.F. Riordan T.H. Yu K.K. Watson 22 May 2012 Lincoln Laboratory MASSACHUSETTS INSTITUTE OF TECHNOLOGY LEXINGTON, MASSACHUSETTS Prepared for the Department of Defense under Air Force Contract FA C Approved for public release; distribution is unlimited.
3 Massachusetts Institute of Technology Lincoln Laboratory Continuous Security Metrics for Prevalent Network Threats: Introduction and First Four Metrics R.P. Lippmann J.F. Riordan T.K. Yu Group 68 K.K. Watson NSA Project Report IA-3 22 May 2012 Approved for public release; distribution is unlimited. Lexington Massachusetts
4 This page intentionally left blank.
5 EXECUTIVE SUMMARY The goal of this work is to introduce meaningful security metrics that motivate eective improvements in network security. We present a methodology for directly deriving security metrics from realistic mathematical models of adversarial behaviors and systems and also a maturity model to guide the adoption and use of these metrics. Four security metrics are described that assess the risk from prevalent network threats. These can be computed automatically and continuously on a network to assess the eectiveness of controls. Each new metric directly assesses the eect of controls that mitigate vulnerabilities, continuously estimates the risk from one adversary, and provides direct insight into what changes must be made to improve security. Details of an explicit maturity model are provided for each metric that guide security practitioners through three stages where they (1) Develop foundational understanding, tools and procedures, (2) Make accurate and timely measurements that cover all relevant network components and specify security conditions to test, and (3) Perform continuous risk assessments and network improvements. Metrics are designed to address specic threats, maintain practicality and simplicity, and motivate risk reduction. These initial four metrics and additional ones we are developing should be added incrementally to a network to gradually improve overall security as scores drop to acceptable levels and the risks from associated cyber threats are mitigated. iii
6 This page intentionally left blank.
7 ACKNOWLEDGMENT We would like to thank George Moore from the Department of State for his consistently insightful and cogent remarks. v
8 This page intentionally left blank.
9 TABLE OF CONTENTS Executive Summary Page iii Acknowledgment v List of Illustrations xi List of Tables xiii 1. INTRODUCTION 1 2. LIMITATIONS OF PAST METRICS USED TO ASSESS RISK 3 3. RISK ASSESSMENT AS A SCIENTIFIC METHOD 9 4. GOALS A METRIC MATURITY MODEL DESIRED METRIC CHARACTERISTICS OVERVIEW OF FIRST FOUR METRICS ADVERSARIAL INTERACTION BETWEEN ATTACKERS AND DEFEND- ERS NOTATIONAL CONVENTIONS AND INTRODUCTION 21 vii
10 10. MODELING DEFENDER AND ATTACKER SCANNING Instantaneous Scanning Periodic Scanning Poisson Scanning Pareto Sampling Comparison of Four Types of Sampling USING PERIODIC SAMPLING ADVERSARY MODELS TO COMPUTE COMPROMISE PROBABILITIES COMBINING THE EFFECT OF MANY INDIVIDUAL INSECURE CON- DITIONS CONSIDERING ERRORS CAUSED BY SAMPLING INSECURE CONDI- TION DURATIONS COMMON METRIC COMPONENTS AND OPTIONS LR-1 METRICS FOR ATTACKERS EXPLOITING UNAUTHORIZED DE- VICES LR-1 Checklist LR-1 Capability Decit Metric LR-1 Operational Metric LR-2 METRICS FOR ATTACKERS EXPLOITING UNAUTHORIZED SOFT- WARE LR-2 Checklist LR-2 Capability Decit Metric LR-2 Operational Metric LR-3 METRICS FOR KNOWN VULNERABILITIES LR-3 Checklist 74 viii
11 17.2 LR-3 Capability Decit Metric LR-3 Operational Metric LR-4 METRICS FOR MISCONFIGURATIONS LR-4 Checklist LR-4 Capability Decit Metric LR-4 Operational Metric LIMITATIONS DISCUSSION AND CONCLUSIONS BIBLIOGRAPHY 87 ix
12 This page intentionally left blank.
13 LIST OF ILLUSTRATIONS Figure No. Page 1 The number of serious vulnerabilities on a network is not an accurate risk metric. 5 2 The number of detected incidents in a network is not an accurate risk metric. 6 3 The total duration hosts are vulnerable or the total window of vulnerability is not an accurate risk metric. 7 4 Metrics support a continuous security improvement loop A network should be protected from at least three types of threats ranging from ankle biters to criminal malware to advanced persistent threats. Each threat will use the least sophisticated attack that can be successful, but each type has accesses to more sophisticated techniques Three stages of a metric maturity model Sequence of events when a defender detects and removes a security condition before it is discovered by an attacker Attackers and defenders scan for exploitable security conditions Graphical summary of notation used to describe sampling intervals and durations Periodic sampling used to detect insecure conditions Probability of detecting a security condition of duration w by periodic scanning with a sampling interval of Probability of missing a condition of duration w by scanning with a sampling interval of δ Poisson sampling used to detect insecure conditions Probability of detecting a condition of duration w by Poisson scanning with an average sampling interval of λ Pareto sampling used to detect insecure conditions Probability of detecting a condition of duration w by Pareto scanning with an average sampling interval of m and a = Probability of detecting a condition of duration w by Pareto scanning with an average sampling interval of m and a = 1.5. The x-axis uses a log scale and ranges from 0.1 to 1, Probability of detecting a condition of duration w by four dierent types of sampling. 35 xi
14 19 Probability of missing a condition of duration w by four dierent types of sampling Event tree for a long-duration insecure condition Joint distribution of the time it takes an attacker and defender to detect a security condition Probability of compromise as a function of defender sampling time Estimating the duration of insecure conditions using periodic sampling Maximum expected error in estimating the probability of attacker detection LR-1 attack model Processing required to create LR-1 metrics Example inventory of authorized and unauthorized devices for LR The LR-2 attack model includes server-side attacks (left) and clientside attacks (right) Processing required to create LR-2 metrics Device proles and inventories of authorized and unauthorized software required by LR Package classication owchart for LR Process to create and maintain lists of authorized and unauthorized software Combining vulnerability windows for unauthorized client and server software to assess risk Vulnerability detection process for LR xii
15 LIST OF TABLES Table No. Page 1 Characteristics of Four Lincoln Risk (LR) Metrics 17 2 Summary of the Most Important Notation 22 3 Failure Probability Combination Formulas 42 4 Two Options for Computing Capability Decit Metrics. The Default is CD-A Three Options for Computing Operational Metrics. The Default is OM-A Characteristics of LR-1 Metrics 55 7 Characteristics of LR-2 Metrics 63 8 Characteristics of LR-3 Metrics 73 9 Characteristics of LR-4 Metrics 79 xiii
16 This page intentionally left blank.
17 1. INTRODUCTION Government, commercial, and institutional computer networks are under constant cyber attack. Recently, high-prole successful attacks have been detected against the International Monetary Fund, Citibank, Lockheed Martin, Google, RSA Security, Sony, and Oak Ridge National Laboratory[13]. These and other attacks have heightened securing networks as a high priority for many organizations, including the U.S. Government. One of the most important strategies to protect networks is to know what types of attacks adversaries employ, to develop metrics to assess susceptibility to each attack type, and then to use metrics to guide addition of controls that are most eective in preventing attacks. Since we are engaged in an arms race with attackers, this strategy can only be eective if defender actions evolve more rapidly than those of the attacker. As such, metrics that accurately assess risk from current attacks must be rapidly developed and deployed. To be ecient and eective, metrics must (1) focus on the most common damaging attacks occurring today and anticipated in the near future, (2) be automated when possible and continuously evaluated, and (3) motivate and quantify security improvements. Driven by these concerns, this report presents a methodology that enables rapid metric development for new threats. This methodology consists of estimating risk by creating an accurate probabilistic model of threats and defenders informed by continuous real-time measurements of important network security conditions. It is illustrated by presenting new metrics for four of the most prevalent modern attack types. These metrics can be computed automatically and continuously, and they estimate the potential damage expressed as the expected number of hosts that can be directly compromised from each attack type. All metrics assess risk for one attack type over a specic measurement interval. Risk represents the expected number of hosts or infrastructure devices directly compromised by an attacker that provide an initial foothold into a network. If asset values are available, risk can represent the total asset value of the compromised devices. The term host or device will refer to any networkconnected device with an IP address including infrastructure devices such as routers, switches, and rewalls and also user devices such as desktops, laptops, netbooks, smart phones, PDA's, music players and other devices. We will assume that attackers have the intent and capability to use specic attack types and will initially characterize attackers by the rate at which they scan network devices searching for exploitable security properties. We will use the term compromise to refer to a victim failing to perform its function including loss of condentiality, integrity, or availability. The remainder of this report reviews past related metric research, describes goals and a metric maturity model used to facilitate metric development and installation, presents desired metric characteristics, reviews common analyses and terminology used across all metrics, analyzes our adversary models, reviews and provides details of four metrics, reviews limitations, and ends with a discussion. 1
18 This page intentionally left blank.
19 2. LIMITATIONS OF PAST METRICS USED TO ASSESS RISK Risk analysis is a methodology that requires the following three main steps (e.g., [1]): 1. Dene and characterize the threat by specifying capabilities, goals, and possible outcomes resulting from the threat attempting to reach dierent goals. 2. Characterize the system being protected including vulnerabilities and defenses that are relevant to the specic threat. 3. Analyze the risk using statistical approaches to determine probabilities and the damage for dierent outcomes and the eect of relevant defenses. In this section we review past approaches that have been developed to create risk metrics for large enterprise networks and also individual software applications. We nd that some metrics that claim to measure risk omit one or more of these steps such as dening the threat. Others are labor intensive or require human judgment and thus can not be automated. Because our goal is to develop systems that provide real-time continuous risk assessment, we end this review by focusing on more recent data-driven approaches that motivate some of our work. One of the most common past approaches to assess risk is to employ a group of security experts, often called a red team, who demonstrate that they can compromise the condentiality, integrity, or availability of a network or application (e.g., [20]). Although the work factor required by a red team measured in person days or cost may be a useful metric, red teams are used infrequently because they are expensive, not repeatable, and have dicult-to-calibrate skill levels. They also may not comprehensively explore all important threat types. A second approach is to subjectively measure risk by using subject matter experts who separately assess the potential impact and ease of exploitation for dierent threats. The overall risk is found by either multiplying the impact times the ease-of-exploit (often incorrectly called likelihood) or using a risk matrix that provides the risk for all combinations of impact and ease-of-exploit. This is the approach recommended by NIST [44], by the early security consulting [17], and by many modern risk assessment approaches [15, 17]. The Mission Oriented Risk and Design Analysis (MORDA) methodology is another important example of a subjective approach that relies on subject matter experts to suggest attacks and defenses for a system being designed [4]. It combines adversary preference scores for various attacks, scores rating the eectiveness of a system with various countermeasures, and overall system cost together to assess the risk of alternative system designs that employ dierent countermeasures. Two more recent subjective approaches have been created to assess the risk to software applications from a library of well-dened threats [11, 14]. The threat modeling approach of [11] begins by creating an annotated dataow diagram that shows external entities, processes, and dataow interactions. Each dataow interaction is then compared to a library of 35 threats to determine if any threats apply to that interaction. The threat library includes entries such as Access using default credentials, Network sning, and SQL Injection. After a user lls in answers to 10 3
20 questions concerning the impact and ease of creating and executing an exploit corresponding to a threat, a risk score is created using a modied version of the Common Vulnerability Scoring System [23]. Risk scores are created for all relevant threats and interactions and sorted to address the most serious threats rst. All the above subjective approaches share common weaknesses. First, they are often highly subjective, labor intensive, and yield results that may vary dramatically across dierent subject matter experts. Results are often not comprehensive or explanatory and these approaches can not be automated and used for continuous security monitoring. More recently, the Security Content Automation Program (SCAP) [34] was developed by the National Institute of Standards and Technology (NIST) and others to support data-driven risk assessment. It supports the National Vulnerability Database (NVD) [28] that provides a repository for known vulnerabilities and software that contains these vulnerabilities. The NVD is often used to associate vulnerabilities with software. SCAP includes the Common Vulnerability Scoring System (CVSS) [23]. This provides a score for each new software vulnerability discovered that prioritizes the importance of this vulnerability. It is created based on a few questions answered by a subject matter expert. Although the base CVSS score is not necessarily a risk, it is computed by adding a score that represents the ease of exploiting a vulnerability to another score that represents the impact of exploiting the vulnerability. CVSS scores and the common dictionary provided by the Common Vulnerabilities and Exposures (CVE) list [22] have been used extensively in data-driven risk assessment to both enumerate vulnerabilities and assess their importance. SCAP components have enabled many modern data-driven risk assessment approaches for enterprise networks. The overwhelming majority of these risk metrics are simply counts or percentages that measure compliance to a policy or aspects of a network related to security. Representative examples of recently recommended metrics of this type are the number of open ports reachable from the Internet [3] and the number of missing patches, rewall rule changes, and vulnerabilities over a given interval [17]. Examples of counts provided by commercial tools include the number of high-severity vulnerabilities found by network vulnerability scanners (e.g., [40]) and the numbers or percentages of hosts that are are not patched to a desired level (e.g., [12]). A recent comprehensive list of metrics for enterprise networks provided by the Center for Internet Security [5] is also dominated by percentages based on counts. For example, three key metrics in the proposed scorecard [5] are the percentage of systems with no known severe vulnerabilities, the percentage of systems that are compliant with the current patch policy, and the percentage of systems that are compliant with the current conguration policy. Other metrics also assess the percentage of systems that are covered or included in these metrics. A more comprehensive example of how SCAP enables continuous security monitoring in real time is the U.S. Department of State's ipost system [15]. Metrics are gathered using commercial tools and include items such as the number of vulnerabilities on a host, the number of missing software patches per host, the number of account password ages above a threshold, the number of hosts not reporting to management tools, and the number of hosts not included in vulnerability scans. These per-host measures are combined across sites and across the entire enterprise to compute 4
21 Figure 1. The number of serious vulnerabilities on a network is not an accurate risk metric. site and enterprise security summaries including a single score and a grade from A to F. Metrics are designed to motivate security improvements by computing scores consistently and fairly and by making scores visible to all. As this system was deployed and used, it was found that fairness was important for acceptance. Fairness included not penalizing a system administrator for failing to install a software upgrade that has not yet been approved or that is not approved because it disables critical functionality. It also includes not assuming a security condition fails a test because a test is not successfully completed, but waiting until a test has completed successfully and only then using the PASS or FAIL result of the test. Risk is not measured by either the ipost metrics or any of the other metrics described above that claim to assess risk using counts or percentages. Although these counts and percentages measure network properties that are related to risk, they do not assess risk. As noted above, determining risk requires three major steps not provided by count and percentage metrics. In particular, counts and percentages do not dene the threat, specify the probability of dierent outcomes, or indicate how probabilities change when defenses change. Without an explicit threat model that provides an answer to the question Secure against what?, counts and percentages are dicult to interpret. For example, it is impossible to know whether specic threats are prevented, to determine expected number of hosts that may be compromised for a specic threat type, or to determine whether dierent defensive strategies such as patching known vulnerabilities more rapidly might reduce risk signicantly. One of the diculties in interpreting counts as a risk metric is illustrated in Figure 1. Consider a situation where the metric used is the total number of software packages on a network with severe vulnerabilities as indicated by a CVSS score of 10. As shown in Figure 1, this could represent a network where one host contains all the vulnerabilities as shown on the left or where the vulnerabilities are spread across all hosts as shown on the right. If the threat model of concern 5
22 Figure 2. The number of detected incidents in a network is not an accurate risk metric. was a rapidly scanning worm on the inside of this network attacking all severe vulnerabilities, and these vulnerabilities were all on web or database servers, risk could vary dramatically for these two situations. The expected number of hosts compromised by a rapidly scanning worm with access to the network could be one for the left network and 20 for the right network, even though they have the same number of total vulnerabilities. A second major problem with this simple count is that the importance or asset value of hosts in a network could dier substantially. For example, one host could be an administrative host that would enable compromise of all other hosts in the network, another might be a database server containing highly condential material, and others might be simple user workstations with web servers left on by default. As noted above, accurate risk assessment must include the damage caused by the threat and this includes the host-specic asset values obtained by the threat. Instead of the expected number of hosts compromised, a more accurate risk metric would be the expected asset value compromised. This can be used whenever asset values are available. Figure 2 illustrates another problem with using counts as metric. In this gure, we assume there is a mechanism to detect the number of incidents or hosts that have been compromised by an attacker in a network. Incidents could be detected by anti-virus tools, host-based rewalls, or known signatures in network trac detected by an intrusion detection system when malware signals back to command and control hosts. Here we assume the number of incidents is the metric used to assess risk. The far left panel in Figure 2 represents a network (network A) where all incidents are detected and there are two incidents. The middle panel represents a second network (network B) with poor incident detection where only two incidents are detected. Without further information, it would appear that the risk of compromise is the same in networks A and B. The truth for network B is shown in the far right panel where it can be seen that with perfect incident detection, 12 incidents are detected. The risk as measured by the number of hosts compromised is thus six times as great in network B as in A, but using incident counts incorrectly indicates that the risk is identical. Another problem with using incident counts is that the result is not diagnostic because the number of attempted but failed attacks is usually unknown. One network could experience few successful attacks because there are few attempted attacks but poor defenses while another 6
23 Figure 3. The total duration hosts are vulnerable or the total window of vulnerability is not an accurate risk metric. network may experience few successful attacks because there are many more attempted attacks but strong defenses. Overall, the number of incidents is dicult to interpret as risk because it is usually impossible to normalize for both threat intensity and incident detection rate. Figure 3 illustrates a nal problem with using simple counts as a risk metric. Here we are interested in windows of vulnerability or the time intervals when hosts have vulnerabilities and can be successfully compromised by the appropriate threat. We assume the metric used is the total of all windows of vulnerability across all hosts measured in vulnerability months. Windows of vulnerability are accumulated across all hosts over a year to create this metric. The diagram on the left of Figure 3 shows a network where only one host is vulnerable, but it is vulnerable all year. The total window of vulnerability is 12 host months for this network. The diagram on the right of Figure 3 shows a network where all 12 hosts in the network are vulnerable but only for the same month. The total window of vulnerability for this network is also 12 host months. The risk from a specic threat for these two networks depends on the threat. For a threat that attempts to exploit these known vulnerabilities once a month all year long, the expected number of hosts compromised is 1 for the network on the left and 12 for the network on the right. For a threat that is present during only the last month of the year, the expected number of hosts compromised is one for the network on the left and zero for the network on the right. The actual risk depends on the temporal details of windows of vulnerabilities and the threat. This can not be determined by a simple overall sum of windows of vulnerabilities. 7
24 This page intentionally left blank.
25 3. RISK ASSESSMENT AS A SCIENTIFIC METHOD Many of the above described approaches to risk assessment seem unscientic, poorly justied, and ad hoc. Our goal, however, is to develop a scientic method to risk assessment as discussed in a recent paper [43]. This paper presents some metrics that suggest how the security research eld might become a science, but most of these metrics assess the computational complexity or utility of a specic attack or defense component but not the overall risk across network devices. A good discussion of requirements necessary for risk assessment to be considered a scientic method is provided in [1]. The following requirements for scientic risk assessment are adapted from these requirements: 1. The mathematical approaches used to model threats, the overall system, and defense models are clearly stated and agree to the extent possible with known threat, system, and defense characteristics. Assumptions, simplications, limitations, and constraints are clearly dened to make sure they can be reviewed for accuracy and the results can be replicated. 2. The analysis focuses on determining the risk or probability of dierent outcomes for dierent threats and with dierent defenses. 3. The analysis and results are reliable, meaning that a dierent group of researchers making the same assumptions would obtain similar results, and they are valid, meaning that they estimate the true underlying risk. Our risk metric development discussed below is designed to satisfy these requirements. A key component of our scientic approach is threat modeling. Our initial approach to developing threat models is to take advantage of recent collaboration across security organizations that led to a document entitled Twenty Critical Security Controls for Eective Cyber Defense: Consensus Audit Guidelines [38]. This document identies the twenty most important current cyber threats and also the critical security controls that protect against these threats. The four metrics we describe focus on four important foundational critical controls in [38] and the attacks these are designed to detect. We have rened and extended attack models and used them and the controls to create mathematical models of threats and defenses that are used to predict risk. Each new metric is based on a realistic and well-dened adversary model, directly measures the eect of controls that mitigate adversaries, continuously estimates risk, and provides direct insight into what network changes must be made to improve security. System, defense, and vulnerability descriptions required for metric development are also enabled by many SCAP components and the NVD National Vulnerability Database. 9
26 This page intentionally left blank.
27 4. GOALS Our goal is to develop metrics that motivate the continuous security improvement loop shown in Figure 4. Important network characteristics such as active devices, operating system congurations, installed applications, and vulnerabilities are measured continuously at the bottom of this loop and are used to compute metrics at the left that estimate the risk for a specic attack type. Per-device metrics are used to determine the most ecient actions that reduce risk as shown on the top and actions taken such as removing unauthorized devices, removing unauthorized applications, and patching lead to more secure networks over time. This continuous process requires metrics that can be computed rapidly, continuously, and automatically using existing security tools. Figure 4. Metrics support a continuous security improvement loop. Each metric in this process assesses the risk from a specic threat and, if the feedback process is successful, the risk from that threat will be reduced. Figure 5 illustrates the three major types of threats that networks should be protected against. This notional chart indicates the range of sophistication of these threats. The simplest ankle biter threats are frequent and use attacks with little sophistication that are well known. It is usually easy to detect and protect a network from these attacks. Organized cyber criminals use more sophisticated malware with the goal of making money illicitly. This malware must constantly change to maintain success in compromising hosts and avoiding defensive measures. Compromised hosts may be used for many purposes including gathering personal information, sending spam, capturing online banking information, and launching distributed denial of service attacks. Criminal threats are carefully monitored by security companies that can provide tools for protection and detection. Nation states and other groups with sucient funding can create the most sophisticated advanced persistent threats (e.g., [36]). It can be very dicult to detect and protect a network from these threats. As shown in Figure 5, each of the three threats has access to both unsophisticated attacks and ever more sophisticated threats. They will 11
28 Figure 5. A network should be protected from at least three types of threats ranging from ankle biters to criminal malware to advanced persistent threats. Each threat will use the least sophisticated attack that can be successful, but each type has accesses to more sophisticated techniques. use the simplest threat necessary to penetrate the defenses in a target network without exposing more sophisticated approaches to discovery and analysis that could lead to development of eective protection. Our goal is to develop metrics for the most important known threats including attacks from ankle biters, organized crime, and some known advanced persistent threats. If these metrics are driven down to low enough values using defensive controls, a network will be protected from important known threats. This is indicated by the dashed line in Figure 5. Eective metrics can protect against the known threats to the left of this dotted line. They may not protect against unknown and extremely sophisticated advanced persistent threats to the right of this dotted line. They will, however, increase the diculty of launching these advanced attacks, potentially make it easier to detect them, and force the adversary to use ever more sophisticated and costly attacks. 12
29 5. A METRIC MATURITY MODEL The metric maturity model shown in Figure 6 is an essential foundation of our approach that supports gradual introduction and use of security metric components across an enterprise. The notional curve in this gure shows how security improves over time during three maturity stages. The rst checklist stage provides a foundation necessary to compute metrics. During this phase, system administrators develop an understanding of their system and the most important threats. They begin to implement processes, add tools to gather data, and develop controls. While this stage does not directly implement security measures, we posit that it does have a signicant security impact. The slight improvement in security shown by the curve in the left of Figure 6 is presumed to be due to improvements in general network hygiene and the fact that improved understanding informs existing security processes. The large improvement towards the end of this phase might be caused by discovery of previously unknown network structure made possible by improved hygiene, new security tools, and by the repair of non-functional security tools, processes, and controls. Figure 6. Three stages of a metric maturity model. The second capability stage of the maturing process focuses on generating specications of security properties and improving the timeliness, coverage, and accuracy of measurements used to compute risk in the third stage. Capability decit metrics implemented in this stage measure the gap between the actual capability and a parametrized gold standard capability. Until values of these metrics are close enough to the gold standard, risk cannot be computed accurately. Security improves slowly during this stage due to further discovery and repair of security issues as coverage 13
30 improves across the entire network, specications are developed, rapid sampling discovers previously missed short-duration security conditions, and security properties are measured accurately. Operational metrics in the third maturity stage are the key component of the OODA-like [30] improvement loop described in Figure 4. They lead to continuous security improvements by assessing risk and indicating which devices, software packages, miscongurations, or other network characteristics are responsible for the greatest increase in risk. In our current metrics, we assume that a threat is always present and attackers continuously scan for exploitable insecure conditions with a given sampling interval. Risk is thus the expected impact of the threat. This is normally the expected number of hosts compromised, or if asset values for hosts are available, it can be the total asset values of the compromised hosts. Assessing risk with operational metrics makes it possible to act on the metrics and modify a network to reduce risk. Operational metrics lead to a large improvement in security when followed by a response that modies the network security properties in a way that reduces risk. They can only be determined after capability decit metrics are low enough to guarantee that the operational metrics are computed accurately. This is why they follow capability decit metrics in the metric maturity model. After designing this security maturity model, we found that it is supported by, and in some ways parallel to, the the four step Visible OPS maturity process described in [18] that is designed to improve overall IT operations. The Visible OPS approach includes the following steps: 1) stabilize the patient and get plugged into production, 2) nd business risks and x fragile artifacts, 3) implement development and release controls, and 4) continual improvement. Networks where the Visible OPS process is followed will have good situation awareness, a good understanding of devices and software on networks, procedures in place for upgrades and change management, an understanding of asset values of devices and which devices and software packages are most critical, good visibility across the IT infrastructure, and a well-trained IT workforce. Although the Visible OPS process does not dene continuous security metrics, it will be much easier to implement our metrics in a network where the Visible OPS process is followed. 14
31 6. DESIRED METRIC CHARACTERISTICS We have already described key characteristics of a scientic approach to risk assessment. These include carefully dening assumptions and models, developing risk metrics that estimate the probability of various outcomes, and making sure metrics are accurate and the analysis is correct and consistent with the data and assumptions. In addition to these principles, we established the following three key additional guidelines for risk metric development: 1. Each metric must be simple to understand and practical to implement. 2. Each metric must accurately estimate the risk from one specic important threat. 3. Metrics must motivate actions to reduce the risk from threats. Maintaining practicality and simplicity are common goals. Practicality includes using data that can be gathered with existing security tools and simplicity includes modeling mainly primary eects that can be predicted accurately with simple models. Accurately estimating the risk from one threat at a time allows us to focus on important threats and create additional detailed threat models and metrics as necessary without having to model all threats at once. Motivating defenders to make the right decisions to improve security, however, is more unusual guideline and is the focus of this section. As noted in [37], motivational metrics must be objective, computed fairly, and be visible to all involved in the security process to allow comparisons over hosts, subnets, and enterprises and over time. As in [37] we have adopted the convention that high scores are bad and low scores (near zero) are good. If scores are normalized to range from 0 to 100 and high scores are good, it was found in the past [27] that system administrators stopped trying to improve scores once they reached 80 or 90 because these represent good test scores in an academic setting. Alternatively they continued to try to reduce scores to zero after reaching 10 or 20 if low scores are best. One of the most dicult motivating metric characteristic to achieve is that incremental improvement in controls must lead to incremental improvements in the metric. If this doesn't occur, then there will be little positive incentive to add controls. When multiple controls contribute to overall security, their settings should be combined in a way that motivates addition of controls by giving credit to incremental improvements. This goal often needs to be traded o against the desire for accurate statistical defense models. An example of the application of this goal is providing credit for creating a specication that enables a security test when computing the capability decit metric, even if the test is not yet implemented. Another motivational feature is fairness. To be fair, a metric should not penalize a system administrator for a centrally controlled router with vulnerabilities if that system administrator has no control over that router. A metric should also not penalize a system administrator for a legacy system if that system is essential and it has been determined that the risk posed is acceptable. It should also be easy to determine major security aws that create poor (high) metric scores. For 15
32 example, devices with the worst individual scores should be easy to identify and the reason for these high scores should be evident. A nal motivational feature is that the overall diculty of obtaining a good low metric score value should increase over time. Initially it should be relatively easy to get a good low score, but this should become more dicult as capabilities, controls, and responses mature. This property is enabled by our metrics via parameters that can be adjusted over time to raise the standard of capability and operation required for good metric scores. 16
33 7. OVERVIEW OF FIRST FOUR METRICS We will demonstrate how to develop risk metrics for any well-dened threat and system. As we develop new risk metrics, they will be labeled using the prex LR followed by a dash and a number such as LR-1 for the rst metric. The LR prex stands for Lincoln Risk metric. Initially, we focus on the most important threats selected by the authors of the 20 Critical Controls document [38]. This document describes 15 critical controls and associated attacks that are amenable to continuous monitoring and 5 that are not. We selected the threats from an initial 5 of these 15 (1, 2, 3, 4, and 10) to create foundational risk metrics to develop and denote our metrics as LR-1 through LR-4. Likewise, we denote the critical controls from [38] using the prex CC followed by a dash and the number of the critical control. TABLE 1 Characteristics of Four Lincoln Risk (LR) Metrics LR CC Entity with security condition Security condition exploited by attacker 1 1 Subnet Unauthorized computer systems and laptops 2 2 Device Unauthorized software Specication that enables security condition test Authorized devices on each subnet Unauthorized and authorized software on each device Data required by operational metric List of rst and last seen times of unauthorized devices List of rst and last seen times for each unauthorized software package on each device 3 10 Device Known software vulnerabilities List of known vulnerabilities on each device 4 3,4 Devices Miscongurations List of correct congurations on each device List of rst and last seen times and score for each vulnerability on each device List of rst and last seen times and score for each misconguration on each device The rst two columns of Table 1 show the LR number followed by the corresponding number of the critical control (CC) in [38] whose threat is modeled by the LR metric. It can be seen that the 17
34 LR and CC numbers for the rst two rows in this table correspond. For example, LR-1 models risk from the threat for CC-1 and LR-2 models risk from the threat for CC-2. This diers for the next two rows where LR-3 corresponds to CC-10 and LR-4 corresponds to CC-3 and CC-4. The fourth column of Table 1 indicates the insecure condition that is exploited by the threat being modeled. For example, LR-1 estimates the risk from an attacker who compromises unauthorized devices on a network such as test servers, personal laptops, or smart phones. It corresponds to the rst critical control that is entitled Inventory of Authorized and Unauthorized Devices. Implementing the rst two metrics (LR-1 and LR-2) provides general network situation awareness required for other metrics. LR-1 monitors unauthorized devices and its implementation provides a list of all devices on a network. LR-2 monitors all software packages and its specication provides a list of all software packages used in a network. The third and fourth metrics (LR-3 and LR-4) were selected because counts of vulnerabilities and miscongurations are common, well supported by SCAP, and are often currently available at secure networks. These two metrics also illustrate how to combine multiple miscongurations and vulnerabilities on one device and how to fuse data gathered from network scanners and host-based agents. Table 1 describes further details of the rst four metrics. All metrics are associated with exploitable insecure conditions that can occur at any time. If an attacker detects an insecure condition rst after it occurs, a network device such as a host or laptop may be compromised. If a defender detects an insecure condition rst, and removes it fast enough, the device is protected. The fourth column in Table 1 lists the exploitable security condition corresponding to each metric and the third column indicates the network entity that contains this condition. For LR-1, attackers look for unauthorized devices on each subnet. For LR-2, attackers look for unauthorized software on all devices. For LR-3, attackers look for known vulnerabilities on all software packages. Finally, for LR-4, attackers look for software miscongurations. The fth column in this table lists the specications that are required to determine if an exploitable security condition is present. A major component of the second maturity stage of metric development is creating these specications. As can be seen, sometimes they include lists of allowable devices, authorized and unauthorized software, known software vulnerabilities, and conguration checks. The nal column in Table 1 describes the data required to compute the expected number of hosts compromised for the attack model associated with each metric. This is always a list containing each device with an exploitable insecure condition, the window of vulnerability (start and end times) of the condition, and some measure of the severity of the exploitable condition. 18
35 8. ADVERSARIAL INTERACTION BETWEEN ATTACKERS AND DEFENDERS As noted above, all four metrics are associated with exploitable insecure conditions that can occur at any time. If a defender detects an insecure condition rst, and eliminates it fast enough, the device is protected. If an attacker detects it rst, a network device may be compromised. Successful defense is illustrated in Figure 7. The horizontal axis in this gure represent time starting when the insecure condition begins. For LR-1, this corresponds to an unauthorized device being placed on a network. The solid bar labeled Window of Opportunity for Attack marks the time interval that the insecure condition could be exploited by an adversary to compromise a host. Note that we assume the security condition is exploitable even while being processed by the defender. In this example, the defender detects the security condition and responds fast enough to remove it before it is detected by the adversary. If the attacker had detected the insecure condition before it was removed, it would have enabled an attack. Figure 7. Sequence of events when a defender detects and removes a security condition before it is discovered by an attacker. Figure 8 illustrates the interaction between defenders searching for and eliminating vulnerable conditions and attackers also searching for vulnerable conditions and using them to exploit devices. The vertical axis in this gure represents an enumeration of all possible insecure conditions in a network that could be exploited by one attack type. For LR-1, this would be the available IP address space. The horizontal axis represents time with vertical lines at weekly intervals. Each thick horizontal gray bar represents an insecure condition that begins and lasts for a specic duration. For LR-1, each bar represents an unauthorized device with an IP address that was put on the network. We normally assume defenders and attackers do not know when security conditions will begin and how long they will last. 19
36 The steeply slanted lines in Figure 8 represent sequential continuous periodic defender scans over all security conditions that are searching for insecure conditions. When a defender nds an insecure condition, it is processed. Processing can eliminate the insecure condition by adding controls or removing the entity with the vulnerability from the network or it can determine that the test used to detect the insecure condition was incorrect and the insecurity does not exist. This processing is indicated by making the horizontal bars darker. For LR-1, this corresponds to removing an unauthorized device from the network, adding patches and other security controls required to authorize the device, or analyzing the device and determining that it should be authorized. This defender processing occurs rapidly in Figure 8 as shown by terminating security conditions soon after they are detected by the defender. Figure 8. Attackers and defenders scan for exploitable security conditions. The less steep horizontal dotted lines in Figure 8 represent sequential continuous attacker scans looking to nd and exploit insecure conditions. Two insecure conditions are detected by the attacker and exploited in this gure as shown by the bars that become dark after attacker detection on the upper left and bottom right. For simplicity, we assume that a device is compromised as soon as an exploitable security condition is detected by an attacker. As noted above, we also assume that a device can be compromised as long as it is on the network and still assessed to be insecure, even if it has been detected by a defender who is processing and analyzing the device. 20
37 9. NOTATIONAL CONVENTIONS AND INTRODUCTION In this section we introduce some notational conventions and describe important notation that is used in the introduction and the metric descriptions. Additional notation is introduced in the metric descriptions. The most important temporal notation that describes durations and sampling intervals is summarized in Figure 9 and described below. Additional notation used when computing metrics is also described below and both temporal and metric notation is summarized in Table 2. Figure 9. Graphical summary of notation used to describe sampling intervals and durations. As noted above, we have adopted the convention that high scores represent poor security and low scores (near zero) represent good security. Capability decit metrics are designed to range from 0 to 1. Low values near 0 are good and high values near 1 are bad. These scores can be normalized to range from 0 to 100 by multiplying by 100 for presentation to security analysts and administrators. Operational metrics normally represent risk or the expected number of devices compromised. If asset values are available for devices, they can represent the total assets compromised. Operational metrics can also be normalized to range from 0 to 100, when desired by taking into account the total number of devices or assets and other network characteristics. Component functions used to compute operational and capability decit metrics are also designed to follow the convention that high values represent poor security. For example, we derive formulas that compute the probability of an attacker detecting an insecure condition P detect and the probability that a defender misses an insecure condition P miss. High values for both of these 21
38 Term Meaning TABLE 2 Summary of the Most Important Notation W m Measurement window or time span over which metrics are computed. δ or δ d Interval between defender scans that test for a specic security condition. or a Interval between attacker scans that test for a specic security condition. w i Window of opportunity or duration that insecure condition i is present. W t Target window or minimum duration of an insecure condition that a defender should always detect. P detect Probability that an attacker detects an insecure condition. P miss Probability that a defender misses an insecure condition. CDM i Capability Decit Metric for Lincoln Risk Metric number i. SD Specication Decit component of a Capability Decit Metric. T D Timeliness Decit component of a Capability Decit Metric. CD Coverage Decit component of a Capability Decit Metric. AD Overall Accuracy Decit used to compute a Capability Decit Metric. OM i Operational Metric or expected devices compromised for Lincoln Risk metric number i. P comp Probability a device is compromised given that an insecure condition is detected on it by an attacker and the attacker launches an exploit. S Terms that weight importance begin with S. functions represent poor security and low values represent good security. Capability Decit Metrics are indicated by CDM i, where i is the LR number from Table 1. Capability decit metrics are computed using measures of the Specication Decit SD, the Timeliness Decit T D, the Coverage Decit CD, and the overall Accuracy Decit AD. Operational metrics are indicated by OM i, where i is the LR number from Table 1. In addition, terms that begin with S are used to weight importance. We use capital letters and symbols such as W and to represent quantities that are, at least initially, dened and are free parameters. We use lower case letters and symbols such as w and δ to represent quantities that are measured and known. As shown in Figure 9, the symbol delta (δ, ) is used to indicate the interval between sampling times for periodic sampling or the average sampling interval for non-periodic sampling. The symbol δ or δ d is used for defender sampling and or a is used for attacker sampling. The letter w is used to represent opportunity windows or durations of dierent types of insecure conditions. For example, w i is the window of opportunity for an attacker or the duration that insecure condition i is 22
39 present. In addition, W t is the target duration or or the minimum duration of an insecure condition that a defender should always detect and W m is the measurement interval over which metrics are computed. 23
40 This page intentionally left blank.
41 10. MODELING DEFENDER AND ATTACKER SCANNING Modeling the adversarial interaction between defenders and attackers requires a mathematical model of how attackers and defenders scan for insecure conditions. The initial insecure conditions scanned for are shown in Table 1 and include unauthorized devices, unauthorized software, software miscongurations, and software vulnerabilities. The following sections describe how to model four approaches to scanning for insecure conditions. These are 1) instantaneous scanning where an insecure condition is discovered immediately, 2) periodic scanning where every security condition is examined periodically with a given sampling interval, 3) Poisson sampling where the sampling interval has a Poisson distribution with a given mean value, and 4) Pareto sampling where the sampling interval has a long-tailed Pareto distribution with a given mean. These span a wide range of sampling strategies that might be used by attackers or defenders. In each section we describe what type of adversary or defender this type of sampling might represent. We also derive two equations. One computes the probability that an attacker detects an insecure condition with a duration or window of vulnerability w when using an average sampling interval of. The other computes the probability that a defender misses an insecure condition of duration w when using an average sampling interval of δ. These formulas and this analysis forms a foundation that is used to develop both capability decit and operational metrics. Following the analysis of each of the four sampling regimes, a summary contrasts and compares them INSTANTANEOUS SCANNING Instantaneous scanning occurs when a security condition is detected immediately as soon as it occurs. For example, for LR-1, a defender could detect an unauthorized device as soon as it is attached to a network if switches implement Network Access Control (NAC) approaches (e.g., [41]) that allow only specic devices to be attached to a network. New unauthorized software could also be detected immediately for LR-2 by a defender if software installation and maintenance was centralized and users were not allowed to install software. On the attacker side, new devices could be detected immediately on a local area network for LR-1 if malware installed on a local host monitors ARP or DHCP trac to detect a recently-connected device being assigned an IP address. This type of detection isn't actually scanning, but is event-driven. With instantaneous sampling, we will normally assume that the probability of an attacker detecting an insecure condition is 1 and the probability of a defender missing a security condition is 0 for all security condition durations PERIODIC SCANNING Periodic scanning is illustrated in Figure 10. The horizontal axis in this gure represents time, and there is a vertical line or impulse whenever a specic security condition is sampled. As can be seen, sampling occurs periodically every 10 weeks. Periodic sampling occurs when attackers or defenders sample each potentially insecure condition periodically with a xed sampling interval and an initial sampling time that can be considered uniformly distributed over the measurement 25
42 Figure 10. Periodic sampling used to detect insecure conditions. interval compared to the onset or oset of insecure conditions. Figure 8 illustrates attacker and defender interactions where both use periodic scanning. For periodic sampling, the attacker sampling interval is initially unknown, so we assume a given sampling interval a that can be used to vary the diculty of obtaining a good low operational metric score. A small sampling interval represents a fast aggressive attacker and a large sampling interval represents a slower more stealthy attacker. The defender scan interval is usually obtained from cooperative defenders and is known. It is denoted by δ d and both attacker and defender scan intervals are measured in seconds. Although Figure 8 illustrates sequential scanning, we will assume devices or other security conditions are not scanned in any particular sequential order. The only key assumption is that each device is examined every a seconds by the attacker and every δ d seconds by the defender. The simple model of periodic scanning can closely model many types of defender and attacker activity observed on the Internet. Periodic scanning is a good model for many defender scans that are run daily or weekly to detect insecure conditions. Periodic scanning is also a good model for many worms that nd new victims by randomly or sequentially scanning IP addresses. These have been been widely analyzed and modeled (e.g., [8, 42]) and are still common (e.g., [9, 21, 33]). Worms are typically characterized by their scan rate specied as IP addresses scanned per second. This rate often varies as a function of the time and of the geographic location or IP address range. Variation is caused by many factors including the number of compromised computers contributing to a scan, a preference for local or remote scanning, a preference or aversion for certain languages or countries, and the time of day as it aects the number of computers that are on at any time. Periodic scanning where the scan interval varies with time and with the IP address range of the scanned network is generally a good model for worm-like scanning. It can model slow and stealthy scans with long scan intervals and rapid scans with short intervals. Periodic scanning is also a good model for scans performed by inside attacks that are launched from a computer inside a network boundary. Such scans often explore the whole IP address space of a local network, and they may be rapid or slow and stealthy to avoid discovery. 26
43 Even though attackers do not launch client-side attacks directly against target computers, client-side attacks can also be modeled as an attacker performing periodic scanning of victim hosts. In a client-side attack, an attacker either inserts malware on legitimate web servers or directs a user using , social media, or other approaches to browse to a malicious web site with embedded malware. Alternatively, an attacker can trick a user into downloading malicious content that will run an exploit when the application required to open the content runs. In either case, when a user clicks on the infected web page or opens the infected le, malicious content is executed that exploits vulnerabilities in the browser or in helper applications used to display images, play movies, edit documents, or perform other functions. In the common case of malware on a web site, the attacker sampling interval is the average interval between visits of malicious web sites for a user. Compromising hosts using malware on web sites can be extremely eective because there are so many helper applications and so many vulnerabilities in these applications and browsers. As an example of the extent of this problem, the Google Safe Browsing Initiative detected more than 1.6 billion unique web pages with malicious content from Dec 2006 to April 2011 [35]. A recent study of a residential network with 20,000 hosts also found that after two weeks roughly 20% of these hosts had connected to one or more web sites found to contain malware by the Google Safe Browsing Initiative [21] and roughly 3% of these hosts became infected with malware. Although browsing patterns for individual users are complex (e.g., [19]), periodic scanning where the scan interval varies with time and IP address is a simple approach to model client-side attack attempts on hosts. Periodic sampling is also a reasonable model of spear-phishing attacks where a user is sent a carefully crafted designed to entice them to open an attachment or visit a malicious web site. Here the attacker sample interval is the interval between receiving spear-phishing s. Actual attacker sampling intervals are dicult to determine because most attackers attempt to be stealthy and avoid detection. Our strategy is to initially set the attacker sampling interval a to be large (e.g., slow sampling) to make it easier to obtain good low metric scores for motivational purposes. As time progresses and the network becomes more secure, the attack sampling interval should be lowered to values that are near actual values. Although actual values will never be known exactly because all attacks will never be detected, they can be estimated. For client-side attacks they can be estimated by examining the rate at which hosts visit black-listed web sites or download known malicious content. For server-side attacks, they can be estimated by examining trac directed at monitored servers. Malicious intent might be determined from the source IP address or content. Rates also might be estimated from data collected by client honey nets (e.g., [35]) or by from analysis of recent worms (e.g., [33, 42]). Periodic scanning with a time varying sample interval can also be used to model defender scans. Here, the actual sampling interval is known exactly. If defenders detect security conditions instantaneously, this can be modeled as periodic sampling with a sampling interval of zero. If there is a delay between the beginning of the insecure condition and detection, this can also be modeled as periodic sampling, but with a sampling interval equal to the delay. If scans occur weekly or monthly, as sometimes occurs for software vulnerability scans, the sampling interval is set to the time between examining each device which would be a week or month for this example. In addition to the sampling interval, defenders are characterized by the time it takes to process and eliminate 27
44 Figure 11. Probability of detecting a security condition of duration w by periodic scanning with a sampling interval of. a security condition from a network. Since devices can be compromised during processing, small processing times are desired. Two important attacker and defender characteristics required to estimate risk and capability are the probability that an attacker detects an insecure condition for operational metrics and the probability that a defender misses a security condition for capability decit metrics. If we specify the duration of a security condition by w and assume periodic sampling with a sampling interval of δ for a specic security condition, then the probability that the condition is detected is given by P detect = min(1, w/δ). This can be seen by considering an insecure condition with a duration that is much smaller than the sampling interval. As noted above, we assume that the starting time of an insecure condition is random and uniformly distributed relative to sampling times. Consider the illustration in Figure 10 and the regions in this gure where an insecure condition could start and be detected. When w is small, these regions will be of length w and occur immediately before each sampling time. The probability of detection will thus be the region length divided by the sampling interval. As w increases, the fraction of the space between samples lled by the region where the insecure condition is detection will increase until w reaches δ. When this occurs, the insecure condition is always detected because the condition is always sampled at least once. The detection function is shown in Figure 11. It is drawn as a function of w/δ because w normally varies across dierent insecure conditions and normalizing by δ makes it possible to use this one curve for 28
45 Figure 12. Probability of missing a condition of duration w by scanning with a sampling interval of δ. all predened attacker sampling intervals. As described, the curve increases from zero for very short duration conditions to 1.0 when the duration of the condition is equal to the sampling interval and then stays at 1.0 as the condition duration increases. To be more specic, the probability that an attacker detects a condition i, present for duration w i is P detect (i) = min(1, w i / a ). (1) To characterize defenders using periodic scanning, we rst specify the shortest duration insecure condition that the defender must detect accurately and denote this minimum target duration as W t. This normally should be shorter than the attacker sampling interval and than most normally occurring insecure conditions. We need to compute the probability that a defender using a scan interval δ misses the shortest duration security condition of interest. The probability that a defender misses a security condition with a target duration w i when using a sampling interval of δ d is 1 minus the detection formula in Eq. 1 but with defender notation, or P miss = 1 min(1, W t /δ d ) = max(0, 1 W t /δ d ). (2) This function is plotted in Figure 12. It is drawn as a function of δ/w because because the defender varies the sampling interval δ to obtain good detection while the target duration w is xed. Normalizing by w makes it possible to use this one curve for all predened target durations. This function is zero when the defender sampling interval is less than the target duration because the defender is then guaranteed to detect the condition. It then gradually rises to 1 as the sampling 29
46 Figure 13. Poisson sampling used to detect insecure conditions. interval increases. The increase is not linear because the horizontal x axis in Figure 12 is δ/w but the miss probability is a function of the inverse of this ratio POISSON SCANNING A Poisson process (e.g., [7]) has often been used to model users arriving to perform tasks of dierent durations. In our use of a Poisson process, users would be attackers or defenders arriving to detect insecure conditions, or users browsing web sites and being compromised by client-side attacks. This model assumes security conditions are sampled continuously and the intervals between samples are independent of one another. Specically, the interval between samples δ is assumed to have an exponential distribution with scale parameter λ, p(δ) = 1 λ exp δ λ. This model has historically been applied to telephone call arrivals at a switchboard. A Poisson process also accurately models some aspects of Internet trac. For example, user-initiated remote-login and le-transfer sessions are well modeled as Poisson processes with hourly rates that vary with time [32]. Start times of user-initiated navigation bursts or tightly-spaced sequences of web pages downloaded by the same web client also are also well modeled using a homogeneous Poisson process where the time interval between bursts is caused by users reading web content before exploring other web pages [31]. Poisson sampling is illustrated in Figure 13. Once again, the horizontal axis represents time, and there is a vertical line or impulse whenever a security condition is sampled. As can be seen, there is more variability in the interarrival times than with periodic sampling. In this example, the scale parameter λ, which is the mean inter arrival time, is 10 weeks. Although the average interarrival time is 10, intervals vary according to the exponential distribution above. Variability is not too extreme and, for an exponential distribution with scale parameter λ, the standard deviation of intervals is λ and 95% of intervals will be between zero and roughly 3λ. In a Poisson process, the probability of missing an insecure condition of length w is the probability that no sample occurs in interval w. Because intervals are independent and exponential, 30
47 Figure 14. Probability of detecting a condition of duration w by Poisson scanning with an average sampling interval of λ. this can be expressed as The probability of detection is one minus this or P miss = exp w/λ. (3) P detect = 1 exp w/λ. (4) This detection curve is plotted in Figure 14. As in Figure 11, this curve increases from zero when the insecure condition duration is small relative to the average sampling interval to 1 when the insecure condition duration is large relative to the average sampling interval. Instead of rising linearly to 1 when the insecure condition is equal in duration to the sampling interval, the rise is gradual and exponential with Poisson sampling. The Poisson detection plot is thus a smoothed version of the detection plot obtained with periodic sampling. Accurate detection is only achieved when the insecure condition duration is 3 to 5 times the average sampling interval instead of equal to the sampling interval as with periodic sampling PARETO SAMPLING Measurements of web trac have demonstrated that interarrival times for web browsing from individual browser clients exhibit self-similar bursty behavior that is not well modeled by a periodic or Poisson process (e.g., [2, 32]). Users browsing web sites and being exposed to client-side attacks may thus be more accurately modeled using a heavy-tailed distribution. As in [2], we model the inter 31
48 Figure 15. Pareto sampling used to detect insecure conditions. arrival time between a single client visiting a web page, downloading all the content on that page, and then visiting again as heavy-tailed Pareto distribution. This distribution has two parameters. The minimum interarrival time is denoted as x m and the Pareto index is denoted as a. The distribution of interarrival times δ is non-zero only for δ x m and is given by p(δ) = a xa m. As the interarrival δ a+1 time increases, this function falls o more slowly than a Gaussian or Poisson distribution. The mean of this distribution, m, is only dened if a > 1 and is specied by m = axm a 1. Pareto sampling is illustrated in Figure 15. As can be seen, there is much more variability in interarrival times than with Poisson or periodic sampling. In this example, the average interarrival time is 10 weeks, a is 1.5 as in [2], and the minimum duration is roughly 3.33 weeks. These interarrival times exhibit a bursty behavior where there are short bursts containing samples with relatively smaller interarrival times followed by much longer gaps. This type of bursty behavior can be observed if similar sample time plots are created over longer time scales and is often called self-similar behavior. The result is that the probability of long interarrival times falls o slowly only as an inverse power of the interarrival time. In a long measurement interval, there almost always will be a few longer duration interarrival times. We developed a closed-form solution to the probability that Pareto sampling detects a insecure condition present for duration w. This combines an equation when security condition durations are less than the minimum interarrival time with another equation when security conditions are greater than this time. It also assumes that a > 1, so the mean of the Pareto distribution is dened. First consider N sample times as in Figure 15 over a nite, but long measurement interval. When w is less than x m, start times for a security condition that will be detected will extend from a duration w before each sample time to the sample time. Because the minimum interval between two samples is x m, each security condition with duration less than x m will only be detected by one sample, and the same analysis used with periodic sampling can be applied. The total average duration for N samples is (N 1) m, where m is the mean interval. The total duration of time where a short security condition can start and be detected is (N 1) w. The probability of detecting a short security condition that begins uniformly randomly over the measurement interval 32
49 is thus P detect = (N 1) w (N 1) m = w m. This is the same linear equation used to calculate the probability of detection for periodic sampling except the xed interarrival interval for periodic sampling is replaced by the mean interarrival time and the equation is valid only when w x m. When the security condition duration is larger than x m, it can interact with more than one sample. Instead of computing the probability of detection, we can compute the probability that the large interval is missed by Pareto sampling. To be missed, the interarrival time between two samples must be greater than w. Again, considering N samples, we rst determine the expected number of samples with interarrival times greater than w denoted as N l. This will be the probability that the interarrival time δ is greater than w times N 1. For the Pareto distribution, this is N l = (N 1) P (δ > w) = (N 1) ( xm w )a. The total duration where a security condition of length w can start and not be detected will be N l times the average duration of intervals of length greater than w minus w because a security condition will be detected in the region of length w immediately before each sample. The average length of security conditions of length greater than w is m l = aw a 1 due to the self-similarity property of the Pareto distribution. The total average duration over the measurement interval where a security condition of length w will not be detected is thus N l (m l w) = (N 1) ( xm w )a ( aw a 1 w) = (N 1) ( xm w )a w a 1. The total expected duration of the measurement interval is N 1 times the average interarrival time or (N 1) m = (N 1) axm (a 1). The probability of missing a long security condition that begins uniformly randomly over the measurement interval is the ratio of these durations or P miss = (N 1) ( xm w )a w a 1 = 1 (N 1) axm (a 1) a ( xm w )a 1. The probability of detecting a long duration security condition is 1 minus this or P detect = 1 1 a ( xm w )a 1. Combining these two detection probabilities for small and large security condition durations results in the following formula P detect = { w m for w < x m 1 1 a ( xm w )a 1 for w x m. (5) The probability of missing a security condition is 1 minus this equation. Figure 16 shows this detection probability as a function of w/m when a = 1.5 using a linear x-axis scale as in Figure 11. As can be seen, the probability of detection increases much more slowly than with periodic or Poisson sampling. Even when the duration of the security condition is 10 times the average sample interval, the probability of detection is still slightly below 0.9. This is caused by the many long-duration intervals generated by Pareto sampling. A plot that shows the detection probability for Pareto sampling over a wider range of w/m is shown in Figure 17. In this gure, the x-axis uses a log scale and w/m ranges from 0.1 to 1,000. Here it can be seen that when security condition duration is 1,000 times the average sampling duration, the probability of detection is.988. The probability of detection is above 0.9 when the security condition duration is 15 times the average sampling interval. Pareto sampling is clearly more problematic for an attacker or defender. For the same eort, measured by the number of times tests are performed to detect an insecure condition, attackers and defenders are more likely to miss short duration insecure conditions. 33
50 Figure 16. Probability of detecting a condition of duration w by Pareto scanning with an average sampling interval of m and a = 1.5. Figure 17. Probability of detecting a condition of duration w by Pareto scanning with an average sampling interval of m and a = 1.5. The x-axis uses a log scale and ranges from 0.1 to 1,
51 Figure 18. Probability of detecting a condition of duration w by four dierent types of sampling COMPARISON OF FOUR TYPES OF SAMPLING Figure 18 shows the probability of detecting an insecure condition of duration w using the four types of sampling described above. Instantaneous sampling always has a probability of detection of 1. The detection probabilities for other types of sampling rise from zero when the insecure condition is much shorter than the sampling interval to equal or approach 1 when the insecure condition is much longer than the average sampling interval. Figure 19 shows the probability of missing an insecure condition of duration w using the four types of sampling described above. Instantaneous sampling always has a miss probability of 0. The mean sampling interval for periodic sampling only needs to be below the duration of the security condition for a miss probability of zero. For Poisson and Pareto interarrival times, the mean sampling interval has to be much less that the insecure condition duration for low miss probabilities. In the remainder of this report we will make the simplifying assumption that attackers and defenders scan periodically. Instantaneous scans will be modeled by periodic scans with a sampling interval equal to zero or the detection delay. This is a conservative, worse-case, assumption for attacker scans because the probability of detection curve in Figure 18 for periodic scanning is always greater than the probability of detection for Poisson and Pareto scanning. It is a reasonable assumption for defender scans because most defender scans are performed periodically. In situations where scanning diers from periodicity, the equations in this section for the other types of scanning should replace the simpler detection and miss probability equations derived for periodic scanning. 35
52 Figure 19. Probability of missing a condition of duration w by four dierent types of sampling. 36
53 11. USING PERIODIC SAMPLING ADVERSARY MODELS TO COMPUTE COMPROMISE PROBABILITIES To perform a theoretical analysis that provides some insight into the adversarial process, we can assume that insecure conditions are present for a known duration and use adversarial modeling to predict the probability of compromise for a device with an insecure condition as defender processing and sampling intervals vary and as attacker sampling intervals vary. In practice, the duration of insecure conditions needs to be measured and the number and duration of insecure conditions can vary substantially across devices. We will perform the analysis for a single device with one security condition and assume the device is compromised if it is discovered by the adversary before it is discovered by the defender or while it is being processed by the defender. To simplify the computation, we will assume that the defender sampling interval is smaller than the attacker sampling interval (δ d < a ), that the security condition duration is greater than the attacker sampling interval (w i > a ), and that all durations and times are known exactly. Figure 20. Event tree for a long-duration insecure condition. Under these assumptions, there are three events that can occur as shown in the event tree of Figure 20. Starting at the top of the tree when a new security condition occurs, there are two choices. If the attacker detects the security condition before the defender, this leads to state A on the right. If the defender detects the security condition rst, then the defender processes and then eliminates the security condition as shown on the left. If the attacker still does not detect the security condition during processing, this leads to state C and if the attacker detects the security condition during processing, this leads to state B. A device with a security condition is compromised in states A and B and not in state C. Figure 7 shows the sequence of events and notation for state C when the device is not compromised. The rst event that occurs along the time line is that the security condition begins. After a time interval of x d, the security condition is detected by the defender and processing begins. Processing is complete after another time interval of δ p, and 37
54 Figure 21. Joint distribution of the time it takes an attacker and defender to detect a security condition. then the security condition no longer exists. The nal event is the attacker who samples the device looking for the security condition after a time interval of x a after the security condition begins. Figure 21 shows the joint distribution of x a and x d, which is a rectangular region with a constant height where x a extends from 0 to a and x d extends from 0 to δ d. In this gure, the horizontal axis represents the time from when the security condition begins to the rst attacker sampling time and the vertical axis represents the time to the rst defender sampling time. The rectangle is wider than it is high because the attacker sampling interval is longer than the defender sampling interval. The distribution shown assumes that the attacker samples each device every 3 days and the defender samples each device every day. The rightmost dark diagonal line indicates the boundary between successful and failed attacks. In regions A and B, to the left, the attacker detects the insecure condition before the defender detects and processes it. In region C, the attacker fails to detect the insecure condition. The leftmost diagonal line indicates the boundary when the defender processing time is zero. If the attacker sampling time is much greater than the defender sampling time and the processing time is small, region C will be a large fraction of the rectangle and the probability that the attacker fails to detect the insecure condition will be high. It is possible to integrate the area to the left of the rightmost slanted line in Figure 21 to create a mathematical expression for the probability of compromise as a function of the processing time, defender sampling interval, and attacker sampling interval. If the attacker sampling interval is greater than the processing time, and both values are constant, then the probability of compromise 38
55 Figure 22. Probability of compromise as a function of defender sampling time. can be expressed as a function of the defender sampling interval as P compromise (δ d ) = 1 {δ p δ d + min(δ d, a δ p ) 2 } + max{0, δ d ( a δ p )}( a δ p ). a δ d 2 A plot of this function is shown in Figure 22 when the attacker sampling interval is 7 days and the processing time is 0 days (lower curve) or 2 days (upper curve). It can be seen that the minimum probability of compromise occurs when both the processing time and defender sampling times are minimum. Increasing the processing time increases the probability of compromise as does increasing the defender sampling interval. When the processing time approaches zero, the probability of compromise is determined primarily by the attacker sampling interval. It is half the ratio between the defender and attacker sample times or P compromise = 0.5δ d / a. This holds only if the attacker sampling interval is greater than the defender sampling interval. If the ratio of the attacker sampling interval to the defender sampling interval is 10 to 1, then the probability of compromise is.05. This increases to.25, when the ratio of attacker to defender sampling intervals drops to 2 to 1. When the defender sampling interval approaches zero, the probability of compromise is determined primarily by the processing time. As long as the processing time is less than say 90% of 39
56 the attacker sampling interval, the probability of compromise is roughly the processing time divided by the attacker sampling interval or P compromise = δ p / a. The probability of compromise thus increases linearly as the processing time increases. These limiting cases and the overall result demonstrate that both the attacker sampling interval and the processing time must be small relative to the attacker sampling interval to prevent attackers from exploiting insecure conditions. 40
57 12. COMBINING THE EFFECT OF MANY INDIVIDUAL INSECURE CONDITIONS When developing security metrics, it often happens that a device, software package, or other entity has many insecure conditions where the probability of successful compromise after discovery using each condition alone is known and less than 1.0. For example, a device may have many software packages, each with one or more vulnerabilities, as in LR-3, or the operating system on a device may have many miscongurations as in LR-4. In this situation, we would like to compute the overall probability of successful device compromise. There are many attack models that we could use to compute the probability of successful compromise. The model that we use in this report is an attacker who tries to exploit all vulnerabilities one at a time and stops only after success. This is simple and well dened, which is why we use it. When an attacker tries to exploit all vulnerabilities, the probability of a device not being compromised is the probability that exploits for all vulnerabilities fail. One minus this will then be the probability of compromise. We denote the probability of a successful compromise using vulnerability i as P success (i). Assuming that this probability is independent for each vulnerability, then the probability of all vulnerabilities failing is the product of all (1 P success (i)) terms. The probability of successfully compromising a device is one minus this product or P device_compromise = 1 (1 P success (i)). (6) i vulns We refer to this common computation as a complementary product and use this formula to model the eect of multiple vulnerabilities and miscongurations. The complementary product has more common-sense properties than other simple approaches to combining compromise probabilities as shown in Table 3. In this table, the probability of a successful compromise using only the single vulnerability i is represented by P i. The rst column of this table shows alternative formulas that can be used to combine compromise probabilities. The second column describes the attacker model that motivates each formula. The remaining columns indicate whether the formulas have four common-sense properties. Each row of this table corresponds to a dierent approach to combining compromise probabilities. The rst row uses the complementary product described above and represents an attacker who tries all exploits. The second row uses a simple average and represents an attacker who randomly tries one exploit. The third row uses a weighted average and represents an attacker who selects a single exploit, but the selection probability is weighted by the probability of compromise for each vulnerability. The nal row uses a max() function and represents an attacker who selects the single vulnerability with the highest probability of compromise. In the middle boxes of this table, indicates a property holds and indicates it does not. The bracketed examples in the tables represent compromise probabilities for vulnerabilities. As can be see, the complementary product 1 (1 P i ) that we use is the only combining formula that has all common sense properties listed in this table. All other methods fail one or more of the common-sense tests. 41
58 TABLE 3 Failure Probability Combination Formulas Combination Derived from an formula for attack model overall where the probability of attacker tries failure 1 (1 P i ) Pi /N all exploits single exploit at random ( ) P 2 i / Pi single exploit at random weighted by success max (P i ) single best exploit Adding a vulnerability does not improve device security Using a single vulnerability results in the compromise probability for that vulnerability {P } P Adding a vulnerability worsens device security unless the compromise probability is already 1.0 Worsening a vulnerability does not improve device security [1.0] vs. [1.0, 0.1] [0.5] vs. [0.5, 0.5] [1.0] vs. [1.0, 0.1] [0.5] vs. [0.5, 0.5] [1.0, 0.1] vs. [1.0, 0.2] [0.5] vs. [0.5, 0.5] 42
59 Using a complementary product assumes that the attacker has exploits for all vulnerabilities and isn't concerned about exposing potentially expensive-to-develop exploits that a defender may discover and then render ineective by creating eective defenses. It also assumes the attacker isn't concerned about being detected but is willing to try many new and old exploits that may be detected by recently updated intrusion detection or prevention systems. Other more complex attacker models that we plan to explore in the future include those that are more concerned about cost of exploit development, probability of success, and detection. Some examples include 1) an attacker concerned about detection and the cost of exploit development who tries to exploit only the single vulnerability with the highest probability of success or the rst few vulnerabilities with the highest probabilities of success, 2) an attacker concerned about detection who randomly tries to exploit one or a small number of vulnerabilities, 3) an attacker with a limited budget to develop exploits who uses only publicly available exploits available from organizations such as Metasploit [25], and 4) an attacker with a larger budget who illegally purchases vulnerabilities as is done ethically by the Tipping Point Zero Day Initiative TippingPoint [45]. 43
60 This page intentionally left blank.
61 13. CONSIDERING ERRORS CAUSED BY SAMPLING INSECURE CONDITION DURATIONS In the above analyses, we assume that the durations of insecure conditions are known exactly. In practice, these durations are determined by sampling performed by the defender. This sampling complicates the analysis and can introduce errors in metric computations. This section analyzes the errors caused by sampling. First, we demonstrate how to estimate the duration of an insecure condition by periodic defender sampling in a way that eliminates statistical bias. Second, we analyze the maximum error that occurs when estimating the probability that an attacker detects an insecure condition when attackers and defenders use periodic sampling. We show that estimation error is acceptable and less than 10% when the defender sampling interval is less than the minimum duration of insecure conditions of interest. First, we focus on estimating the duration of insecure conditions by periodic defender sampling. A key component of our analysis of periodic sampling is Equation 1 which shows that the probability that an attacker detects an insecure condition present for duration w using periodic sampling with a sampling interval is P detect = min (1, w/ ). (7) In practice, the insecure condition duration w is unknown and the attacker sampling interval is assumed to be known. When a defender estimates the insecure condition duration using instantaneous sampling, then this duration is known exactly and the formula can be computed accurately. When the defender estimates the duration using periodic sampling, errors are introduced because the estimated insecure condition duration ŵ is dierent than the true condition duration. Figure 23. Estimating the duration of insecure conditions using periodic sampling. Figure 23 illustrates the errors in measuring the start and end times of security conditions that can be caused by sampling. The horizontal axis in this gure represents time and the vertical lines represent times when the defender, using periodic sampling with a sampling interval of δ, tests 45
62 to nd the insecure condition. Two dierent insecure conditions are shown by the black rectangular regions. The X's show where sampling detected the insecure conditions. The condition on the left labeled Insecure Condition 1 is sampled three times and the condition on the right labeled Insecure Condition 2 is sampled ve times. As can be seen, the actual begin and end times of these security conditions are not detected accurately by sampling times. In Insecure Condition 1, the rst sample is relatively close to the beginning of the insecure condition but the last sample is relatively farther away from the end of the insecure condition. For Security Condition 2, the measurement error between the nearest sample time within the insecure condition and actual start and end times is greater for the start than for the end of the insecure condition. This measurement error ranges from 0 to δ and has an average of 0.5 δ assuming the start and end times of insecure conditions are uniformly distributed over a measurement interval. The rst sample time when a condition is detected is on the average.5 δ after the true insecure condition start time and the last sample time when a condition is detected is on the average.5 δ before the true end time. An unbiased estimate of the duration of an insecure condition is thus the number of defender samples that detect the condition times the sample interval or ŵ = NS detect δ, (8) where NS detect is the number of defender samples that detected the insecure condition. This estimate is shown by the intervals labeled w 1 and w 2 in Figure 23. Although the start and end times of the estimated regions are dierent from the true start and end times of the insecure conditions, the duration estimates that results are statistically unbiased. In some situations, defenders sample to detect the beginning of the insecure condition but know exactly when the insecure condition ends because they process the insecure condition and know exactly when it is eliminated. In this case, the insecure condition duration should be estimated using the rst sample time adjusted to eliminate bias and the actual end time as ŵ = (t true_end [t first_seen.5 δ]), (9) where t true_end is the known end time of the insecure condition and t first_seen is the time of the rst sample to detect the insecure condition. Now we focus on determining the error in estimating the probability that an attacker detects an insecure condition. The above formulas compensate for the average sampling bias in measuring the duration of insecure conditions. Even with zero bias, however, an expected error can be introduced when using the duration estimates in Eq. 8 to estimate the probability of detection of an insecure condition by an attacker because the duration estimates are processed nonlinearly as shown in Figure 11. It is important to determine when this error is so large that risk computed using the attacker probability of detection is no longer meaningful. Such an error analysis will enable us to specify how small the defender sampling interval δ needs to be relative to the security condition duration w to enable accurate risk estimation. 46
63 Following from above, the estimated probability of an attacker detecting and compromising a device is ( ˆP detect = min 1, ŵ ), (10) where ŵ is the estimated insecure condition determined by periodic defender sampling and calculated using Eq. 8, and is the attacker sampling interval. If we assume insecure conditions occur with start and end times that have a uniform distribution relative the measurement interval, then the ratio of ŵ and δ determines the number of times the defender will sample the condition. The defender will either sample the insecure condition w δ times or w δ 1 times, where this ceiling function x represents the smallest integer greater than or equal to x. The probabilities of sampling the insecure condition these number of times are listed in the following table. Probability w δ w δ + 1 w w δ δ # Times Defender Samples Insecure Condition w δ 1 w δ These probabilities and Eq. 8 lead to the expected estimated duration equations in second column of the table below. These expected durations and Eq. 10 lead to the probability of attacker detection equations in the third column of the table below. Probability Expected Duration Probability of Attacker Detection w δ w δ + 1 w ( δ δ min 1, w ) δ δ w ( δ w w ) ( ( δ δ 1 δ min 1, w ) ) δ 1 δ The expected value of the probability of attacker detection estimate can be computed from the equations in the above table as [ ] ( w w ) ( w δ ( w E ˆPdetect = δ + 1 min 1, + δ δ ) w ) ( ( w ) δ min 1, 1. δ δ δ ) The error in this estimate is the dierence between this expected value and the true probability of detection or [ ] ( Error = E ˆPdetect min 1, w ). This error equation is a complex function that depends on the ratio of the insecure condition duration and the defender sampling interval, and the ratio between the defender and attacker sampling intervals. By selecting the ratio between the defender and attacker sampling interval that 47
64 Figure 24. Maximum expected error in estimating the probability of attacker detection. maximizes this error for each value of the ratio between the insecure condition duration and the defender sampling interval, we created the plot of this maximum error shown in Figure 24. This graph indicates that risk estimation is unreliable when the defender sampling interval is greater than the duration of the insecure conditions. This is shown by the high error values near -1 in the region to the left of the value where w δ = 1 on the x axis. For example, if we test yearly for a condition that lasts one week, then w δ = which is much less than 1. In this example, the probability of our detecting the insecure condition is only.02. If we believe that the attacker is able to exploit this vulnerability once every two weeks, then the actual probability of compromise is 0.5 whereas our observation based estimate will be only.02 resulting in an error of This analysis demonstrates that the error in estimation attacker probability of detection is acceptable when the defender sampling interval is less than the minimum duration insecure condition of interest. It shows that the maximum error approaches zero towards the right of the graph when the defender sampling interval becomes small relative to the insecure device duration and the insecure condition is sampled many times. For the same example of a security condition that lasts 1 week, if we test every day, our maximum risk estimate error will be only a few percent. In addition, the maximum error, when the defender sampling interval is less than the minimum duration insecure condition of interest, is roughly 20% and this occurs only when the probability of attacker detection is near 1. This results in only a small underestimate of risk in the worst case when the attacker sampling interval is equal to the duration of the insecure condition. This analysis assumes the start and end times of a security condition are estimated using periodic sampling. If a defender detects the start time, begins processing the security condition, and knows the end time exactly, the maximum error reduced by a factor of 2. The maximum error 48
65 rate when the defender sampling interval is shorter than the minimum duration insecure condition of interest is thus less than 10% which is acceptable for most risk assessments. 49
66 This page intentionally left blank.
67 14. COMMON METRIC COMPONENTS AND OPTIONS Every new metric requires three components corresponding to the three stages of the metric maturity model described in Section 4. In the rst maturity stage, checklist metrics are developed. These specify the data, processes and capabilities required to assess risk from the associated attack type. In the second maturity stage, Capability Decit (CD) metrics are developed. These measure whether specications of security properties are available and whether the timeliness, coverage, and accuracy of measurements are sucient to compute accurate risk estimates in the third maturity stage. Until CD metrics are low enough, risk can not be estimated accurately in the third maturity stage. The overall value of a CD metric is a combination of its specication decit (SD) and accuracy decit (AD). The specication decit indicates whether all specications required to compute risk have been created. Examples are lists of authorized devices and authorized software as shown in the fourth column of Table 1. The accuracy decit is computed from two components. First, the timeliness decit (T D) measures both coverage or whether tests are performed over all relevant entities in the network and whether security conditions are scanned frequently enough to reliably detect the shortest duration security condition of interest. Second, the total testing error (T T E) measures the fraction of errors or misclassications for the security tool that performs the test assuming the test is timely and specications are accurate. The total testing error allows us to take into account the underlying accuracy of the approach used to perform security tests. It is an advanced feature that can be set to 0 if it can not be accurately estimated. For example, for CC-1, if unauthorized devices are detected using a MAC address as a unique identier, misclassications can occur for multiple virtual machines that use the same auto-generated MAC address. If the total testing error has been measured experimentally on a testbed with known characteristics, we use the measured value. If it is composed of multiple measurable components, we combine the error of each component using a complementary product. Without any information on the misclassication rate of an approach, for simplicity, we assume zero total testing error. We provide two options and two formula to compute the CD metric. A motivational option (CD-A) was developed to motivate system administrators to reduce the CD metric and a probabilistically rigorous option (CD-B) was developed to be more accurate under common probabilistic assumptions. In option CD-A, credit is provided for creating specications even when no tests are performed. In option CD-B no credit is provided until the overall accuracy is reduced. We will describe both options here, but present only option CD-A when describing individual metrics. In general, for a particular entity i (subnet, device,...), the CD metric is dened as a function of the specication decit and the accuracy decit. When using the motivational option CD-A we use the formula Option CD-A (Motivational): CDM (i) = SD (i) + 3 AD (i). (11) 4 51
68 TABLE 4 Two Options for Computing Capability Decit Metrics. The Default is CD-A. Options CD-A (Motivational) CD-B (Rigorous) Formula SD(i)+3 AD(i) 4 1 (1 SD (i)) (1 AD (i)) This formula is intended to motivate improvement by providing some credit for creating a speci- cation before sampling has begun. A system administrator can reduce the CD metric from 1.0 to.75 simply by creating specications for all security conditions. The CD metric then can only be reduced to zero if the AD is reduced to zero. The decision to weight the SD by 1 and the AD by 3 is reasonable because CD scores for option CD-A are similar to those for the more rigorous option CD-B when they are low, but a system administrator sees some change after the rst step of creating specications. For the more rigorously accurate option CD-B we use a complementary product to combine SD and AD which assumes that these terms represent the probability of a condition being specied and accurately detected and that these are independent. This leads to the following formula Option CD-B (Rigorous): CDM (i) = 1 (1 SD (i)) (1 AD (i)). (12) The two options for computing CD metrics are summarized in Table 4. The global CD metric is computed as a weighted average over entities such as subnets and devices as listed in column 2 of Table 1. To compute the global CD metric, we rst assign S entity (i) as the importance of given entity i and T Entities as the total importance across entities T Entities = i Entities S entity (i). The global CD metric is then the importance-weighted average of the per-entity Capability Decit Metric values CDM = 1 T Entities i Entities If all entities are weighted equally, this reduces to CDM = 1 N i Entities S entity (i) CDM entity (i). (13) CDM entity (i), (14) where N is the number of entities. As noted above, CD metrics vary from 0, the best possible score, to 1, the worst. 52
69 TABLE 5 Three Options for Computing Operational Metrics. The Default is OM-A. Option Equation OM-A: Basic i devices P detect (i), 1 OM-B: Asset Values T AV i devices AV (i) P detect (i), OM-C: Exploit Success Probability i devices P ExploitSuccess(i) P detect (i) Operational metrics measure the risk posed by the critical control's attack type based on insecure condition durations measured by the defender. Until capability is reasonably mature and the CD metric is small, the operational metric has no meaning. There are again a few options when computing the operational metric. The simplest computation (OM-A) occurs when we assume that all devices have equal asset values and any exploit launched against an insecure condition detected by an attacker is always successful. The operational metric is then give by Option OM-A (Basic): OM = i devices P detect (i), (15) where the sum is over all devices with insecure conditions that can be detected by the attacker and P detect is the probability of an attacker detecting the insecure condition(s) on the device. (The term P detect (i) has a more complex meaning when there are multiple vulnerabilities on a device and when some of these can not be exploited with probability 1). This equation represents the expected number of devices that are compromised by an attacker. For simplicity, this is the equation that we will use when presenting equations for individual metrics. If devices have dierent asset values we represent the asset values for device i as AV (i) and modify this equation to create option OM-B where Option OM-B (Asset Values): OM = 1 T AV i devices AV (i) P detect (i), (16) where the normalizing constant T AV is given by T AV = i devices AV (i). Finally, if we assume that the probability that an exploit launched by an attacker against a device with a detected insecure condition is not always successful at compromising the device, 53
70 we can specify a probability of compromise or exploit success for device i as P ExploitSuccess (i) and extend Eq. 15 to produce a third option OM-C where, Option OM-C (Exploit Success Probability): OM = i devices P ExploitSuccess (i) P detect (i). (17) This equation computes the probability that a device is successfully compromised as the probability of detecting the insecure condition(s) on the device times the probability that an exploit launched against the device is successful. The term P ExploitSuccess (i) can depend on the details of the insecure condition(s) on the device, on the diculty of exploiting these conditions, and on the attackers skill and competence. Options OM-B and OM-C can also be combined. The three operational metric options are summarized in Table 5. 54
71 15. LR-1 METRICS FOR ATTACKERS EXPLOITING UNAUTHORIZED DEVICES Table 6 summarizes the characteristics of LR-1 as extracted from Table 1. Capability decit metrics are computed for each subnet and attackers look for and exploit unauthorized devices such as servers, laptops, smart phones, and personal laptops. A defender must create specications consisting of an inventory of authorized devices for each subnet and must process and remove unauthorized devices when they are discovered. Finally, the data required to compute risk using the operational metric is a list of the rst and last seen times of unauthorized devices for each subnet. TABLE 6 Characteristics of LR-1 Metrics Entity with security condition Security condition exploited by attacker Specication that enables security condition test Data required by operational metric Subnet Unauthorized computer systems and laptops Authorized devices on each subnet List of rst and last seen times of unauthorized devices The attack model for LR-1 is the threat that Critical Control 1 in [38] is designed to mitigate. It is an attacker who scans a network either internally or externally looking for unauthorized software and is assumed to opportunistically compromise any unauthorized device discovered. This threat is illustrated in Figure 25 where it can be seen that unauthorized devices include recently installed test servers, uncongured switches, laptops that have been o the network for a long time and plugged in without being updated and patched, personal laptops that may be insecure, virtual machines (VMs), and personal devices such as smart phones or music players plugged into desktop computes. A common situation noted in [38] is for an uncongured and insecure server to be attached to a network in the afternoon and left on the network overnight before being congured and patched in the morning. Such servers are often compromised overnight by attackers scanning networks looking for insecure servers. Note that that LR-1 does does not consider devices that are deliberately installed for malicious purposes but rather devices that are benignly placed and then maliciously exploited. All components of the process shown in Figure 26 need to be in place to compute LR-1 metrics. This process begins with creating an inventory of authorized devices shown on the upper left for each subnet. All subnets in the network are continuously scanned by the network defender for new 55
72 Figure 25. LR-1 attack model. 56
73 Figure 26. Processing required to create LR-1 metrics. devices as shown on the bottom left. New devices that are discovered are compared to the list of authorized devices. Discovered devices that occur in the authorized inventory are allowed. They do not require any processing and do not aect metrics. Discovered unauthorized devices not in the authorized inventory are counted in the operational metric and passed to a remediation process that either authorizes the device or removes it. They are considered vulnerable to attack until removed from the network or authorized. The processing required for LR-1 maintains an up-to-date device inventory across all subnets that provides situation awareness of all authorized devices. This list of authorized devices is used by other metrics. The foundation for LR-1 metrics is an inventory of authorized and unauthorized devices. Figure 27 shows an example of such an inventory. Key aspects of this inventory are that it includes a unique identier for each device (combination of name, IP address, MAC address and subnet), its owner and role, its location, the date and time last seen by a scan, and status. In addition, there should be a scan history indicating when it was seen in the past and other information such as the type of device (e.g., is it a virtual machine, workstation,... ). For unauthorized devices the inventory should indicate when the device was rst seen, when processing began, and the time when processing was complete and the device was either removed from the network or authorized. If the exact end of processing time is not available, the inventory should include the last scan time when the unauthorized device was detected. These times are required to compute the LR-1 operational metric. Detailed instructions on creating an inventory that could support LR-1 are available in [29] LR-1 CHECKLIST Assessment of the LR-1 capability decit and operational metrics requires the following checklist items: Entities: All subnets within the enterprise must be identied and enumerated. 57
74 Figure 27. Example inventory of authorized and unauthorized devices for LR-1. Specication: An inventory of all authorized devices permitted on each subnet must be created and maintained. Monitoring: Each subnet must be continuously scanned to nd recently installed devices, to compare them to the inventory of authorized devices, and thus to detect and keep an inventory of unauthorized devices. Our analyses support many types of scanning including periodic scanning as well as instantaneous sampling as described in Section 10. Resolution process: A process must be in place to remove, isolate, or authorize any unauthorized devices detected and to maintain the the rst detection times and end of the processing times for all authorized devices in the inventory of unauthorized devices. Maintenance process: A process must be in place to add new authorized devices to the inventory and to de-authorize devices as they are removed from the inventory. In these checklist metric components we assume that the same technique (e.g., scanning or automatic detection of new MAC addresses) is used to detect all unauthorized devices on each subnet. Dierent subnets may be scanned at dierent rates or use dierent device discovery procedures. To dene a subnet, we rst dene a reachability group as a collection of IP addresses that are treated identically by rules in ltering devices. For example, hosts in a DMZ and normal user desktops may be in dierent reachability groups. We then dene subnets as collections of one or more reachability groups that use the same mechanism to discover unauthorized hosts and verify authorized hosts. We will perform a separate mathematical analysis to compute the probability of not detecting an unauthorized device present for a given length of time in each subnet. We will also determine coverage based on the number of subnets where unauthorized devices are detected. 58
75 15.2 LR-1 CAPABILITY DEFICIT METRIC Specication requirements for LR-1 as shown in Table 1 are that a per-subnet inventory of authorized devices is required. The specication decit is thus SD subnet (i) = 1 I inventory_specified (i), where I inventory_specified (i) is an indicator function that is 1 if a device inventory is available for subnet i and 0 otherwise. The timeliness decit for LR-1 is derived from both the sampling rate and coverage information. It is the probability that the defender misses an unauthorized device present for a minimum target duration window W t given a defender sampling interval δ d (i) in subnet i for all subnets where there is sampling and they are thus covered. Using Equation 2, this is given by T D subnet (i) = P miss (i) = max ( 0, 1 I covered (i) W t δ d (i) In this equation, the term I covered (i) is another indicator function that is 1 if subnet i is being scanned to discover devices and 0 otherwise. To simplify notation, for other metrics, we will express the timeliness decit as ( T D subnet (i) = P miss (i) = max 0, 1 W ) t, (18) δ d (i) where, by convention, a subnet that is not covered and not sampled will be assigned an innitely long sampling interval (δ d = ) with the result that Wt δ d = 0 and P miss (i) = 1 as when I covered (i) was used and set to 0. In this way the timeliness decit assesses both timeliness and coverage. The total testing error for LR-1 is an advanced feature that can be set to 0 as an assumption of accurate testing if no additional information on the accuracy of tests used to determine the presence of an unauthorized device is available. It can also be set based on 1) Actual tests performed by attaching unauthorized and authorized devices, 2) An an analysis of testing assumptions and how testing systems work, or 3) A subjective comparison between dierent testing methods. The accuracy decit is dened as the complementary product of the timeliness decit and the total testing error: ). AD subnet (i) = 1 (1 T D subnet (i)) (1 T T E subnet (i)). The total capability decit metric for each subnet can be computed using the default motivational option from Eq. 11 or the rigorous option from Eq. 12. Using the default motivational option results in CDM subnet (i) = SD subnet (i) + 3 AD subnet (i) 4. 59
76 To compute the overall capability decit network we can weight the importance of each subnet as shown in Eq. 13. If no other information is available on the importance of dierent subnets, we recommend the following weighting function: S subnet (i) = (# of assigned devices on i) This equation does not simply count the number of devices on a subnet, but is designed to prevent small subnets such as DMZs that contain a few servers from being assigned negligible importance. The constant value of 40 in the equation indicates that the value of a subnet without any devices is equivalent to that of 40 devices or roughly 20% of the value of a fully populated class C network. This value can be changed, if necessary. More complex subnet weightings are also possible given knowledge of the asset value of devices and the importance of each subnet in an enterprise. Given these or other weightings, the overall capability decit metric is computed as shown in Eq. 13 as CDM 1 = 1 T subnets i subnets S subnet (i) CDM subnet (i), (19) where T subnets = i subnets S subnet (i). This total capability decit metric determines whether the observe step of the OODA-like loop shown in Figure 4 is accurate enough to support accurate risk estimation and security improvements. This metric needs to be low enough (e.g., below 0.2) before operational metrics can be computed accurately. The target device duration (W t in Eq. 18) can be decreased over time for motivational purposes to make the capability decit easy to reduce to low values initially but then to lower the duration of the minimum duration insecure condition that must always be detected over time to improve security. This decrease needs to be performed consistently across all networks that use this metric to allow fair comparisons. The target duration used also needs to be noted explicitly whenever the metric is presented LR-1 OPERATIONAL METRIC Each identied unauthorized device i has a probability of being compromised based upon the time window it is present and available for compromise w i and the attacker scanning rate a. The operational metric is the expected number of compromised devices as described in Eq. 15: OM 1 ( a ) = i unauthorized devices P detect (i), (20) 60
77 where the probability of the attacker detecting and compromising device i is given as ( P detect (i) = min 1, w ) i a (21) as in Equation 1. This metric is aected by both the number of unauthorized devices being placed on the network and the eciency of their removal via the process in Figure 26. To motivate improvement in detecting and processing unauthorized devices, the attacker sampling interval a in Eq. 21 can be decreased over time to make it easier to initially achieve a lower score, but then to make the network more secure over time as part of the capability/maturity approach. This decrease again needs to be performed consistently across all networks that use this metric to allow fair comparisons. The attacker sampling interval used also needs to be noted explicitly whenever the metric is presented. 61
78 This page intentionally left blank.
79 16. LR-2 METRICS FOR ATTACKERS EXPLOITING UNAUTHORIZED SOFTWARE Table 7 summarizes the characteristics of LR-2 as extracted from Table 1. Capability decit metrics are computed for all authorized devices identied by LR-1. Attackers look for and exploit unauthorized software found on devices including desktop workstations, laptops, smart phones, and tablets. TABLE 7 Characteristics of LR-2 Metrics Entity with security condition Security condition exploited by attacker Specication that enables security condition test Data required by operational metric Device Unauthorized software Unauthorized and authorized software on each device List of rst and last seen times for each unauthorized software package on each device A defender must create specications consisting of lists of authorized and unauthorized software and process software packages using these lists when they are discovered. Lists of both authorized and unauthorized software are used because new software packages, not on the authorized list, are often discovered. If these discovered software packages are on the unauthorized list, they can be immediately classied as unauthorized instead of being put on a list of unclassied software for further analysis. The data required to compute risk using the operational metric is a list of the rst and last seen times of unauthorized software packages on each device. The attack model for LR-2 is the threat that Critical Control 2 in [38] is designed to mitigate. It expands the attacker model of LR-1 by including both server-side and client-side attacks. Serverside attacks shown on the left of Figure 28 consist of external or internal attackers who scan a network looking for unauthorized server software running on ports of a computer that can be reached from the attacker's location. Server software could include web-servers, database servers, servers, chat servers, and other type of server software. These attacks are similar to those in LR-1 except the attacker is looking for unauthorized servers instead of unauthorized devices. We assume that unauthorized server software is insecure and will be compromised if discovered. Client-side attacks shown in the right of Figure 28 have a few more stages and variations. As described above in Section 10.2, in a client-side attack, an attacker either inserts malware on legitimate web servers or directs a user using , social media, or other approaches to browse to 63
80 Figure 28. The LR-2 attack model includes server-side attacks (left) and client-side attacks (right). a malicious web site that contains embedded malware. Alternatively an attacker can coerce a user to download malicious content that will run an exploit when the application required to open the content runs. In either case, when a user clicks on the infected web page or opens the infected le, malicious content is executed that exploits vulnerabilities in the client browser or helper applications used to display images, play movies, edit documents, or perform other functions. This approach can be extremely eective because there are so many helper applications and so many vulnerabilities in these applications and browsers. As with server-side attacks, we will assume that unauthorized client software will be exploited and compromised if present on a device. As noted, unauthorized client software may include web browsers, components of web browsers, document readers, movie and image display software, and other client software. Metric computations used for LR-2 are more complex than in LR-1 because these two attack types have dierent attacker sampling rates. Note that LR-2 does does not consider software that is deliberately installed for malicious purposes but rather software that is benignly placed and then maliciously exploited. All components of the process shown in Figure 29 need to be in place to compute LR-2 metrics. This process begins on the upper left with creating lists of authorized software, unauthorized software, and exceptions. Software on all authorized devices is then continuously scanned and reported by software agents running on devices as shown on the bottom left. These agents periodically create a list of all software packages on devices. Observed software packages are compared to the lists of authorized and unauthorized software. Authorized software is allowed. Unauthorized software is counted in the operational metric and passed to a remediation process that either authorizes the software or removes it. A device is considered vulnerable to attack until its unauthorized software is removed or authorized. If software is not on the authorized or unauthorized list, it is logged and 64
81 Figure 29. Processing required to create LR-2 metrics. added to the unclassied software list for further analysis. This list needs to be analyzed frequently to keep it small. LR-2 processing maintains an up-to-date software inventory across all subnets that provides situation awareness of all software packages. This software list is used by other metrics. LR-2 requires a collection of software proles for each device that is used to build lists of authorized and unauthorized software. It is assumed that each device has a role or collection of roles that it serves within an organization. Performing these roles requires the software package or packages associated with each role. These software packages should thus be authorized for a device. For example, the upper table in Figure 30 lists the proles or roles for two dierent devices. The device named 1111xyab serves as a Windows XP administrator and needs a Flash Player plug-in for the Firefox browser. The device named 1122fred supports an Apache web server running under Gentoo Linux server software. The middle table in Figure 30 lists the software packages allowed for the Gentoo Linux server, for the Apache web server, and for the Firefox Flash plug-in. Software packages are named in this table using the Common Processing Enumeration (CPE) conventions [26, 46] but other naming standards could be used such as cryptographic hash values for program executables. The rst four rows of content in the middle table of Figure 30 list some of the authorized software for proles used by the device named 1122fred and the last row lists some of the authorized software for the Firefox/ash-plug-in prole used by the device labeled 1111xyab. The bottom table in Figure 30 indicates that Java plug-in software for Firefox browsers is unauthorized and that it enables a client-side attack. Software packages that are not needed should be unauthorized because they can be used by attackers to compromise a device or because they are restricted for policy reasons. Policies could include such restrictions as not allowing peer-to-peer le sharing or real-time video streaming. In the remainder of this description we focus on software that is unauthorized because it allows attackers 65
82 Figure 30. Device proles and inventories of authorized and unauthorized software required by LR-2. 66
83 Figure 31. Package classication owchart for LR-2. to compromise a host. We assume that the inventory contains information for each unauthorized software package that indicates whether it facilitates a client-side attack, a server-side attack, or whether it is restricted due to policy guidelines. The owchart in Figure 31 provides details of how packages could be classied as authorized, unauthorized, or added to the unclassied list. It allows an exception list to handle packages that are allowed because they serve an essential function and their security risk is acceptable. Software packages on the exception list are assumed to also be on the authorized and unauthorized list. The owchart shows when unauthorized software is detected (middle right), when authorized software is allowed (bottom left), and when software is added to the unclassied list (bottom right). The log of unclassied device proles and package names shown on the bottom right is used to generate the list of unclassied packages. Creating and maintaining the authorized and unauthorized software package lists and keeping the size of the unclassied list small can be supported by the process shown in Figure 32. The process begins by collecting reports from all device agents to obtain a comprehensive list of all software packages. Those packages that are vulnerable as noted in the National Vulnerability Database should be (explicitly) unauthorized. Other packages discovered by system observation need to be manually analyzed and compared to security and other policies to determine whether they belong 67
84 Figure 32. Process to create and maintain lists of authorized and unauthorized software. on the authorized or unauthorized lists. The automated creation of the list of unclassied packages shown in Figure 29 feeds the manual process of creating the authorized list essentially by answering the question does this package need to be installed on a device of a particular prole?. The automatic creation of an inconsistent list feeds the manual process of creating an exception list by answering the questions such as Why should this unauthorized package be permitted? Who is responsible? How long is it necessary? 16.1 LR-2 CHECKLIST Assessment of CC-2 capability decit and operational metrics requires the following checklist items: Entities: LR-1 should be implemented to provide an enumeration of authorized devices and an enumeration of all software packages on each device should be created using local software agents and CPE nomenclature. If LR-1 is not fully implemented, LR-2 may be used for those devices that have been specied as authorized by LR-1. Specication: A software prole should be created for each authorized system that lists the software authorized and often unauthorized for that system. Each known device/software package needs to be designated as authorized, unauthorized, or unclassied. Additionally, the attack type enabled by the unauthorized software should be specied as client-side or 68
85 server-side. Dierent treatment of the two attack types is required because they normally have dierent attacker sampling intervals. Monitoring: Each device is monitored by a local agent to generate a list of installed software packages. This is compared to the list of authorized, unauthorized, or unclassied software packages. Resolution process: A process exists to resolve discrepancies between observed and authorized software packages and either remove or authorize each observed unauthorized package. Maintenance process: A process exists to classify software as authorized or unauthorized as it is discovered and a process exists to ensure that currently authorized software should remain authorized (e.g., by analyzing software packages using information in the National Vulnerability Database). A list of exceptions should also be maintained for software packages and devices LR-2 CAPABILITY DEFICIT METRIC Specication requirements for LR-2 are that a prole of authorized and unauthorized software packages must exist for each device. The specication decit is thus SD device (i) = 1 I profiled (i), where I profiled (i) is an indicator function that is 1 if software proles exist for device i and 0 otherwise. The timeliness decit expresses the probability of missing a package present for minimum target duration window W t given a scan rate of δ d (i) as ( T D device (i) = P miss (i) = max 0, 1 W ) t. (22) δ d (i) The total testing error should ideally use a complementary product of two terms. The rst term is the probability that when a software package is on the authorized or unauthorized list and it is classied by a software agent, the agent makes a mistake in the classication. We will assume this is 0. It can also be measured as discussed above. The second term is the probability that a software package on a device is unclassied P unclassified (i) as measured by the fraction of unclassied software packages on a device. This term is motivated by considering the resultant accuracy of software package classication when all the unclassied software packages are unauthorized. This would incur an error similar to that caused when the agent accuracy for the rst term is equal to P unclassified (i). We will thus assume that the total testing error is given by T T E device (i) = P unclassified (i) = Fraction of Unclassied Software on Device i. 69
86 The accuracy decit is dened as the complementary product of the timeliness decit and the total testing error: AD device (i) = 1 (1 T D device (i)) (1 T T E device (i)). Computing the the capability decit metric for each device using the motivational option from Eq. 11 yields CDM device (i) = SD device(i) + 3 AD device (i) 4 For the purposes of computing the overall CDM, we can weight each device with a factor S device (i) and compute the overall capability decit metric using Eq. 13 as. CDM 2 = 1 T devices i devices S device (i) CDM device (i), (23) where T devices = i devices S device (i). As with LR-1, the overall capability decit metric needs to be low before operational metrics can be computed accurately and the target device duration (W t in Eq. 22) can be decreased over time to increase accuracy as overall system security increases LR-2 OPERATIONAL METRIC The operational metric assesses risk as the probability that a device will be compromised due to unauthorized software either via client-side or server-side attack. Risk computation is identical to that used in LR-1 when the windows of vulnerability or intervals when unauthorized software packages are present are non-overlapping and disjoint over time. We use some simplifying assumptions to calculate risk when there are many unauthorized software packages on a device with overlapping windows of vulnerability. This situation is illustrated in Figure 33. The horizontal axis of this gure represents the total extent of the measurement interval where risk is computed. The vertical axis represents types of unauthorized software. The upper half of Figure 33 represents unauthorized server software that provides services by opening network ports on a device. The only unauthorized server software shown is one software package labeled A that is present for a short time interval. As shown on the uppermost part of Figure 33 this one package simply creates an identical window 70
87 Figure 33. Combining vulnerability windows for unauthorized client and server software to assess risk. of vulnerability that is used to compute risk from server-side attacks. The lower half of the gure represents unauthorized software that provides client-side services. Here, there are two pieces of unauthorized software labeled B and C that have overlapping windows of vulnerability. Instead of treating each overlapping window and software package separately, we combine them to form one total window of vulnerability. This creates the single window of vulnerability shown on the bottom of Figure 33 that is used to compute the risk from client-side attacks. We combine windows of vulnerability for software packages for simplicity, because modern attackers generally exploit many vulnerabilities, and because and it is currently dicult to rate the exploitablity of dierent types of unauthorized software. Our core assumption is that the probability of host compromise with any single unauthorized software package is 1. Providing multiple unauthorized software packages to an attacker thus does not increase the probability of compromise, but it always remains at 1. To compute the operational metric, we introduce some new notation. The subscripts client and server indicate client-side and server-side attackers and the sample intervals for these two attack types are indicated by a,client and a,server. The probability of an attacker detecting windows where unauthorized software exists on client and server software are P detect,client (i) and P detect,server (i) and the windows where attackers can detect unauthorized software are w client (i) and w server (i) where overlapping windows are combined as shown in Figure 33. The resulting operational metric is the expected number of devices that will be compromised via server-side or client-side attacks due to the presence of unauthorized, hence vulnerable, software OM 2 ( a,client, a,server ) = i Profiled Devices P detect (i), (24) 71
88 where P detect (i) is dened by the complementary product P detect (i) = 1 (1 P detect,client (i)) (1 P detect,server (i)). (25) Using Equation 1, ( ) w client (i) P detect,client (i) = min 1,, a,client (i) and ( ) w server (i) P detect,server (i) = min 1,. a,server (i) As with LR-1, this metric is aected by both the number of unauthorized software packages and the eciency of their removal via the process in Figure 29. To motivate improvement in detecting and processing unauthorized software, the attacker sampling intervals ( a,client, a,server ) can also be decreased over time to make it easier to initially achieve a lower score, but then to make the network more secure over time as part of the capability/maturity approach. The client and server attacker sampling intervals used also need to be noted explicitly whenever the metric is presented. 72
89 17. LR-3 METRICS FOR KNOWN VULNERABILITIES The third Lincoln Risk metric concerns known vulnerabilities. Table 8 summarizes the characteristics of LR-3 as extracted from Table 1. Capability decit metrics are computed for an attacker who attempts to exploit known server-side or client-side vulnerabilities on each device in an enterprise. The adversary in this metric corresponds to the threat for Critical Control 10, Continuous Vulnerability Assessment and Remediation in [38]. TABLE 8 Characteristics of LR-3 Metrics Entity with security condition Security condition exploited by attacker Specication that enables security condition test Data required by operational metric Device Known software vulnerabilities List of known vulnerabilities on each device List of rst and last seen times and score for each vulnerability on each device We focus on two fundamental mechanisms to detect vulnerabilities. The rst is maintaining an inventory of software installed on each device, as in LR-2, and using a vulnerability database to lookup vulnerabilities from software package names. The second is to actively scan each device either remotely or locally using a collection of vulnerability signatures. From the standpoint of the metrics there are two important dierences between these mechanisms. The rst concerns the coverage of vulnerabilities. LR-2 provides a software inventory whose coverage tends to include all ocially installed packages even if a specic vulnerability signature does not exist. By contrast, signature based scanning might detect illicitly installed packages for which signatures exist. The second dierence is the speed with which updated vulnerability knowledge, via a database or signature set, leads to knowledge of vulnerability instance on the device base. In the case of the database, this knowledge is essentially instantaneous. In the case of the signature set, devices need to be rescanned. This said, direct scanning for vulnerabilities is often also necessary as some vulnerabilities are dependent upon run-time parameters and thus must be live tested as dierent instances of the same package have dierent vulnerability proles. The capability decit metric allows various forms of vulnerability detection and allows for fusion of multiple information channels. 73
90 17.1 LR-3 CHECKLIST Assessment of LR-3 capability decit and operational metrics requires the following checklist items: Entities: LR-1 and LR-2 must be implemented to provide an inventory of devices and software packages. The LR-2 database should be extended to specify which vulnerabilities should be tested for each authorized device of the LR-1 database and for which concern they are being tested (client-side versus server-side). Monitoring: A vulnerability scanning process must exist. Ideally, it should use both remote scanning and local agent-based data collection as well as the device software inventory of LR-2 to associate vulnerabilities to software packages using a vulnerability database. Resolution process: A vulnerability remediation process exists, such as patching or removing software. Maintenance process: A process exists to update the two data sources used for monitoring: the vulnerability signatures and the vulnerability database LR-3 CAPABILITY DEFICIT METRIC The specication decit SD device (i) = 1 I profiled (i) of LR-3 requires that each authorized device has a specied list of vulnerabilities for which it should be scanned. These should be specied using vulnerability assignments from the Common Vulnerability Enumeration (CVE) dictionary [34]. For a given device with a specication, we estimate the probability that each vulnerability will be missed due to timeliness, coverage or test error. LR-3 allows for multiple detection modalities, initially focusing on remote scanning and inventory-based discover using a vulnerability database. For each vulnerability test and detection modality, we compute the timeliness decit and testing error for that combination. We dene the indicator function I detectable,modality (j) which is 1 if vulnerability j is detectable via modality modality and 0 otherwise. As a concrete example, a client-side vulnerability in a browser is not typically detectable via remote scanning while it is detectable via a local agent. As such, the indicator function would have value 0 for remote scanning and value 1 for a local agent. The timeliness decit for a test j on device i is then given by T D modality (i, j) = P miss,modality (i, j) = [ ] W t min 0, 1 I detectable,modality (j). modality δ d (i) 74
91 In this equation, the min() function selects the modality with the lowest probability of miss. This could be remote scanning for some vulnerabilities and inventory-based analysis for others. The total testing error, in addressing inaccuracy and incompleteness, includes a term that models the failure to update security signatures/vulnerability information in the scanner used to detect vulnerabilities. For simplicity, if we assume that the measured misclassication error is zero, then the total testing error can be modeled as the probability of missing an update for each detection modality X as as in Equation 2: ( ) T T E X = max 0, 1 I detectable,x (j) Wt,update,X. δ update,x (i) In this equation, δ update,x (i) is the actual time between updating signature les for the vulnerability scanner and modality x while W t,update,x is the actual update interval for the vulnerability scanner. This term penalizes signature update intervals that are longer than the actual vendor signature update intervals and makes sure signatures exist for all vulnerabilities. It is similar to the total testing error term for LR-2 that penalizes sites where there are too many unclassied software packages. Finally, dierent vulnerabilities have dierent severity ratings and should be weighted accordingly. Ultimately, we would like to assign a weight S CVE (j) to vulnerability j as the probability that a device will fail to satisfy is specied function when it is exploited, where this includes loss of condentiality, integrity, and availability. To simplify metric application, we estimate these weights from the base metric score provided by the Common Vulnerability Scoring System (CVSS) [23]. The base CVSS score captures the characteristics of a vulnerability that are constant with time and across user environments and includes components that measure where an attacker needs to be located to exploit the vulnerability, the exploit complexity, the number of times the attacker needs to provide authentication, and the level of compromise provided. The base score combines scores for these components to produce a number ranging from 0 to 10. We analyzed the distribution of CVSS scores for 2009 and 2010 and found few low values below 4, even though vulnerabilities with these low scores should result in much lower probability of compromise compare to vulnerabilities with scores of 10. We thus applied a simple monotonic normalization to CVSS scores so they span a greater range and result in a value ranging from 0 to 1.0 that can be interpreted as a probability of compromise. We convert CVSS scores to probability of compromise using the following formula ( ) cvss(j) 2 s cve (j) =. 10 This normalization results in a roughly uniform distribution of probabilities from 0 to 1.0 based on the CVE scores from 2009 and This simple approach could be improved if more detailed information on vulnerabilities and exploits were available. 75
92 The accuracy decit is computed across tests as AD device (i) = 1 T CV E (i) j CVE(i) S CVE (j) min [1 (1 T D 3,X) (1 T T E 3,X )], x {modalities} where T CV E (i) = j CVE(i) S CVE (j). Note that the S CVE terms serves to focus attention on the most critical vulnerability and the min term selects the best means of detection LR-3 OPERATIONAL METRIC The Operational Metric assesses risk as the probability that a device will be compromised via client-side or server-side attack. To perform this computation we fuse remote and local vulnerability detection data concerning a device to form a set of beliefs about the collection of vulnerabilities on that device as illustrated in Figure 34. Figure 34. Vulnerability detection process for LR-3. 76
CONTINUOUS DIAGNOSTICS BEGINS WITH REDSEAL WHAT IS CDM? The continuous stream of high profile cybersecurity breaches demonstrates the need to move beyond purely periodic, compliance-based approaches toMore information
THE TOP 4 CONTROLS. www.tripwire.com/20criticalcontrols
THE TOP 4 CONTROLS www.tripwire.com/20criticalcontrols THE TOP 20 CRITICAL SECURITY CONTROLS ARE RATED IN SEVERITY BY THE NSA FROM VERY HIGH DOWN TO LOW. IN THIS MINI-GUIDE, WE RE GOING TO LOOK AT THEMore information
ADDING NETWORK INTELLIGENCE INTRODUCTION Vulnerability management is crucial to network security. Not only are known vulnerabilities propagating dramatically, but so is their severity and complexity. OrganizationsMore information
Critical Security Controls
Critical Security Controls Session 2: The Critical Controls v1.0 Chris Beal Chief Security Architect MCNC email@example.com @mcncsecurity on Twitter The Critical Security Controls The Critical SecurityMore information
Continuous Network Monitoring
Continuous Network Monitoring Eliminate periodic assessment processes that expose security and compliance programs to failure Continuous Network Monitoring Continuous network monitoring and assessmentMore information
How to Design and Maintain a Secure ICS Network
Whitepaper How to Design and Maintain a Secure ICS Network Support IEC 62443 Compliance with SilentDefense ICS Authors Daniel Trivellato, PhD - Product Manager Industrial Line Dennis Murphy, MSc - SeniorMore information
CDM Vulnerability Management (VUL) Capability
CDM Vulnerability Management (VUL) Capability Department of Homeland Security Office of Cybersecurity and Communications Federal Network Resilience Vulnerability Management Continuous Diagnostics and MitigationMore information
DEFENSE THROUGHOUT THE VULNERABILITY LIFE CYCLE WITH ALERT LOGIC THREAT AND Introduction > New security threats are emerging all the time, from new forms of malware and web application exploits that targetMore information
Vulnerability management lifecycle: defining vulnerability management
Framework for building a vulnerability management lifecycle program http://searchsecurity.techtarget.com/magazinecontent/framework-for-building-avulnerability-management-lifecycle-program August 2011 ByMore information
The Four-Step Guide to Understanding Cyber Risk
Lifecycle Solutions & Services The Four-Step Guide to Understanding Cyber Risk Identifying Cyber Risks and Addressing the Cyber Security Gap TABLE OF CONTENTS Introduction: A Real Danger It is estimatedMore information
WHITE PAPER ON SECURITY TESTING IN TELECOM NETWORK DATE OF RELEASE: 27 th July 2012 Table of Contents 1. Introduction... 2 2. Need for securing Telecom Networks... 3 3. Security Assessment Techniques...More information
SANS Top 20 Critical Controls for Effective Cyber Defense
WHITEPAPER SANS Top 20 Critical Controls for Cyber Defense SANS Top 20 Critical Controls for Effective Cyber Defense JANUARY 2014 SANS Top 20 Critical Controls for Effective Cyber Defense Summary In aMore information
001011 1100010110 0010110001 010110001 0110001011000 011000101100 010101010101APPLICATIO 0 010WIRELESS110001 10100MOBILE00010100111010 0010NETW110001100001 10101APPLICATION00010 00100101010WIRELESS110More information
Management (CSM) Capability
CDM Configuration Settings Management (CSM) Capability Department of Homeland Security National Cyber Security Division Federal Network Security Network & Infrastructure Security Table of Contents 1 PURPOSEMore information
: INCIDENT RESPONSE FIVE KEY RECOMMENDATIONS 1 FIVE KEY RECOMMENDATIONS During 2014, NTT Group supported response efforts for a variety of incidents. Review of these engagements revealed some observationsMore information
Looking at the SANS 20 Critical Security Controls
Looking at the SANS 20 Critical Security Controls Mapping the SANS 20 to NIST 800-53 to ISO 27002 by Brad C. Johnson The SANS 20 Overview SANS has created the 20 Critical Security Controls as a way ofMore information
The Emergence of Security Business Intelligence: Risk
The Emergence of Security Business Intelligence: Risk Management through Deep Analytics & Automation Mike Curtis Vice President of Technology Strategy December, 2011 Introduction As an industry we areMore information
PENETRATION TESTING GUIDE. www.tbgsecurity.com 1
PENETRATION TESTING GUIDE www.tbgsecurity.com 1 Table of Contents What is a... 3 What is the difference between Ethical Hacking and other types of hackers and testing I ve heard about?... 3 How does aMore information
Defending Against Data Beaches: Internal Controls for Cybersecurity
Defending Against Data Beaches: Internal Controls for Cybersecurity Presented by: Michael Walter, Managing Director and Chris Manning, Associate Director Protiviti Atlanta Office Agenda Defining CybersecurityMore information
SECURING YOUR SMALL BUSINESS. Principles of information security and risk management
SECURING YOUR SMALL BUSINESS Principles of information security and risk management The challenge Information is one of the most valuable assets of any organization public or private, large or small andMore information
Session 9: Changing Paradigms and Challenges Tools for Space Systems Cyber Situational Awareness
Session 9: Changing Paradigms and Challenges Tools for Space Systems Cyber Situational Awareness Wayne A. Wheeler The Aerospace Corporation GSAW 2015, Los Angeles, CA, March 2015 Agenda Emerging cyberMore information
DeltaV Cyber Security Solutions
TM DeltaV Cyber Security Solutions A Guide to Securing Your Process A long history of cyber security In pioneering the use of commercial off-the-shelf technology in process control, the DeltaV digitalMore information
PASTA Abstract. Process for Attack S imulation & Threat Assessment Abstract. VerSprite, LLC Copyright 2013
2013 PASTA Abstract Process for Attack S imulation & Threat Assessment Abstract VerSprite, LLC Copyright 2013 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -More information
Why Leaks Matter. Leak Detection and Mitigation as a Critical Element of Network Assurance. A publication of Lumeta Corporation www.lumeta.
Why Leaks Matter Leak Detection and Mitigation as a Critical Element of Network Assurance A publication of Lumeta Corporation www.lumeta.com Table of Contents Executive Summary Defining a Leak How LeaksMore information
Vulnerability Management
Vulnerability Management Buyer s Guide Buyer s Guide 01 Introduction 02 Key Components 03 Other Considerations About Rapid7 01 INTRODUCTION Exploiting weaknesses in browsers, operating systems and otherMore information
Symantec's Continuous Monitoring Solution
Preparing for FISMA 2.0 and Continuous Monitoring Requirements Symantec's Continuous Monitoring Solution White Paper: Preparing for FISMA 2.0 and Continuous Monitoring Requirements Contents Introduction............................................................................................More information
Secure Content Automation Protocol (SCAP): How it is increasingly used to automate enterprise security management activities
Secure Content Automation Protocol (SCAP): How it is increasingly used to automate enterprise security management activities Sean Barnum email@example.com September 2011 Overview What is SCAP? Why SCAP?More information
GFI White Paper PCI-DSS compliance and GFI Software products
White Paper PCI-DSS compliance and Software products The Payment Card Industry Data Standard () compliance is a set of specific security standards developed by the payment brands* to help promote the adoptionMore information
WHITE PAPER AUTOMATED, REAL-TIME RISK ANALYSIS AND REMEDIATION Table of Contents Executive Summary...3 Vulnerability Scanners Alone Are Not Enough...3 Real-Time Change Configuration Notification is theMore information
CyberNEXS Global Services
CyberNEXS Global Services CYBERSECURITY A cyber training, exercising, competition and certification product for maximizing the cyber skills of your workforce The Cyber Network EXercise System CyberNEXSMore information
End-user Security Analytics Strengthens Protection with ArcSight
Case Study for XY Bank End-user Security Analytics Strengthens Protection with ArcSight INTRODUCTION Detect and respond to advanced persistent threats (APT) in real-time with Nexthink End-user SecurityMore information
UF Risk IT Assessment Guidelines
Who Should Read This All risk assessment participants should read this document, most importantly, unit administration and IT workers. A robust risk assessment includes evaluation by all sectors of anMore information
Intrusion Detection and Cyber Security Monitoring of SCADA and DCS Networks
Intrusion Detection and Cyber Security Monitoring of SCADA and DCS Networks Dale Peterson Director, Network Security Practice Digital Bond, Inc. 1580 Sawgrass Corporate Parkway, Suite 130 Sunrise, FL 33323More information
Vulnerability Audit: Why a Vulnerability Scan Isn t Enough. White Paper
Vulnerability Audit: Why a Vulnerability Scan Isn t Enough White Paper May 10, 2005 TABLE OF CONTENTS Introduction: How Secure Are My Systems?... 3 Vulnerability: The Modern Meaning Of A Muddled Word...More information
Symantec Cyber Threat Analysis Program Program Overview. Symantec Cyber Threat Analysis Program Team
Symantec Cyber Threat Analysis Program Symantec Cyber Threat Analysis Program Team White Paper: Symantec Security Intelligence Services Symantec Cyber Threat Analysis Program Contents Overview...............................................................................................More information
Optimizing Network Vulnerability
SOLUTION BRIEF Adding Real-World Exposure Awareness to Vulnerability and Risk Management Optimizing Network Vulnerability Management Using RedSeal november 2011 WHITE PAPER RedSeal Networks, Inc. 3965More information
White Paper. Automating Your Code Review: Moving to a SaaS Model for Application Security
White Paper Automating Your Code Review: Moving to a SaaS Model for Application Security Contents Overview... 3 Executive Summary... 3 Code Review and Security Analysis Methods... 5 Source Code ReviewMore information
IT Risk Management: Guide to Software Risk Assessments and Audits
IT Risk Management: Guide to Software Risk Assessments and Audits Contents Overview... 3 Executive Summary... 3 Software: Today s Biggest Security Risk... 4 How Software Risk Enters the Enterprise... 5More information
CDM Hardware Asset Management (HWAM) Capability
CDM Hardware Asset Management (HWAM) Capability Department of Homeland Security Office of Cybersecurity and Communications Federal Network Resilience Table of Contents 1 PURPOSE AND SCOPE... 2 2 THREATMore information
Risk Calculation and Predictive Analytics: Optimizing Governance, Risk and Compliance.
Risk Calculation and Predictive Analytics: Optimizing Governance, Risk and Compliance. Prevari makes organizations safer by providing instrumentation for managing risks to information. Prevari solutionsMore information
Experience the commitment WHITE PAPER. Information Security Continuous Monitoring. Charting the Right Course. cgi.com 2014 CGI GROUP INC.
Experience the commitment WHITE PAPER Information Security Continuous Monitoring Charting the Right Course May 2014 cgi.com 2014 CGI GROUP INC. During the last few months of 2013, six federal agenciesMore information
THE 2014 THREAT DETECTION CHECKLIST. Six ways to tell a criminal from a customer.
THE 2014 THREAT DETECTION CHECKLIST Six ways to tell a criminal from a customer. Telling criminals from customers online isn t getting any easier. Attackers target the entire online user lifecycle fromMore information
The Next Generation Security Operations Center
The Next Generation Security Operations Center Vassil Barsakov Regional Manager, CEE & CIS RSA, the Security Division of EMC 1 Threats are Evolving Rapidly Criminals Petty criminals Unsophisticated OrganizedMore information
IMPROVING VULNERABILITY MANAGEMENT EFFECTIVENESS WITH APPLICATION SECURITY How runtime application security monitoring helps enterprises make smarter decisions on remediation 2 ABSTRACT Enterprises todayMore information
Critical Controls for Cyber Security. www.infogistic.com
Critical Controls for Cyber Security www.infogistic.com Understanding Risk Asset Threat Vulnerability Managing Risks Systematic Approach for Managing Risks Identify, characterize threats Assess the vulnerabilityMore information
Proactive Vulnerability Management Using Rapid7 NeXpose
WHITE PAPER Proactive Vulnerability Management Using Rapid7 NeXpose RAPID7 Corporate Headquarters 545 Boylston Street Boston, MA 02116 617.247.1717 www.rapid7.com Proactive Vulnerability Management UsingMore information
Protecting Your Organisation from Targeted Cyber Intrusion
Protecting Your Organisation from Targeted Cyber Intrusion How the 35 mitigations against targeted cyber intrusion published by Defence Signals Directorate can be implemented on the Microsoft technologyMore information
Review: McAfee Vulnerability Manager
Review: McAfee Vulnerability Manager S3KUR3, Inc. Communicating Complex Concepts in Simple Terms Tony Bradley, CISSP, Microsoft MVP September 2010 Threats and vulnerabilities are a way of life for IT admins.More information
CS 356 Lecture 25 and 26 Operating System Security. Spring 2013
CS 356 Lecture 25 and 26 Operating System Security Spring 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access ControlMore information
SECURITY. Risk & Compliance Services
SECURITY Risk & Compliance s V1 8/2010 Risk & Compliances s Risk & compliance services Summary Summary Trace3 offers a full and complete line of security assessment services designed to help you minimizeMore information
Presented by Evan Sylvester, CISSP
Presented by Evan Sylvester, CISSP Who Am I? Evan Sylvester FAST Information Security Officer MBA, Texas State University BBA in Management Information Systems at the University of Texas Certified InformationMore information
The Days of Feeling Vulnerable Are Over: Best Practices in Vulnerability Management
The Days of Feeling Vulnerable Are Over: Best Practices in Vulnerability Management An EiQ Networks White Paper The Need for Vulnerability Management Vulnerabilities are potential holes introduced by flawsMore information
Intelligent Vulnerability Management The Art of Prioritizing Remediation. Phone Conference
Intelligent Vulnerability Management The Art of Prioritizing Remediation An IANS Interactive Phone Conference SUMMARY OF FINDINGS F e b r u a ry 2010 Context Joel Scambray shared IANS point of view onMore information
Nessus Agents. October 2015
Nessus Agents October 2015 Table of Contents Introduction... 3 What Are Nessus Agents?... 3 Scanning... 4 Results... 6 Conclusion... 6 About Tenable Network Security... 6 2 Introduction Today s changingMore information
Integrated Network Vulnerability Scanning & Penetration Testing SAINTcorporation.com
SAINT Integrated Network Vulnerability Scanning and Penetration Testing www.saintcorporation.com Introduction While network vulnerability scanning is an important tool in proactive network security, penetrationMore information
Wasting Money on the Tools? Automating the Most Critical Security Controls. Mason Brown Director, The SANS Institute
Wasting Money on the Tools? Automating the Most Critical Security Controls Bonus: Gaining Support From Top Managers for Security Investments Mason Brown Director, The SANS Institute The Most Trusted NameMore information
What a Vulnerability Assessment Scanner Can t Tell You. Leveraging Network Context to Prioritize Remediation Efforts and Identify Options
White paper What a Vulnerability Assessment Scanner Can t Tell You Leveraging Network Context to Prioritize Remediation Efforts and Identify Options november 2011 WHITE PAPER RedSeal Networks, Inc. 3965More information
How Your Current IT Security System Might Be Leaving You Exposed TAKEAWAYS CHALLENGES WHITE PAPER
WHITE PAPER CHALLENGES Protecting company systems and data from costly hacker intrusions Finding tools and training to affordably and effectively enhance IT security Building More Secure Companies (andMore information
The Business Case for Security Information Management
The Essentials Series: Security Information Management The Business Case for Security Information Management sponsored by by Dan Sullivan Th e Business Case for Security Information Management... 1 UnMore information
Network and Host-based Vulnerability Assessment
Network and Host-based Vulnerability Assessment A guide for information systems and network security professionals 6600 Peachtree-Dunwoody Road 300 Embassy Row Atlanta, GA 30348 Tel: 678.443.6000 Toll-free:More information
Solving the CIO s Cybersecurity Dilemma: 20 Critical Controls for Effective Cyber Defense
Solving the CIO s Cybersecurity Dilemma: 20 Critical Controls for Effective Cyber Defense John M. Gilligan Information systems Security Association National Capital Chapter January 19, 2010 1 Topics BackgroundMore information
ForeScout CounterACT CONTINUOUS DIAGNOSTICS & MITIGATION (CDM)
ForeScout CounterACT CONTINUOUS DIAGNOSTICS & MITIGATION (CDM) CONTENT Introduction 2 Overview of Continuous Diagnostics & Mitigation (CDM) 2 CDM Requirements 2 1. Hardware Asset Management 3 2. SoftwareMore information
Application White Listing and Privilege Management: Picking Up Where Antivirus Leaves Off
Application White Listing and Privilege Management: Picking Up Where Antivirus Leaves Off Times have Changed & A/V Executives Agree An A/V product as your sole endpoint protection solution isn t enough.More information
Enterprise Cybersecurity Best Practices Part Number MAN-00363 Revision 006
Enterprise Cybersecurity Best Practices Part Number MAN-00363 Revision 006 April 2013 Hologic and the Hologic Logo are trademarks or registered trademarks of Hologic, Inc. Microsoft, Active Directory,More information
Penetration Test Report
Penetration Test Report Acme Test Company ACMEIT System 26 th November 2010 Executive Summary Info-Assure Ltd was engaged by Acme Test Company to perform an IT Health Check (ITHC) on the ACMEIT SystemMore information
Worldwide Security and Vulnerability Management 2009 2013 Forecast and 2008 Vendor Shares
EXCERPT Worldwide Security and Vulnerability Management 2009 2013 Forecast and 2008 Vendor Shares IN THIS EXCERPT Global Headquarters: 5 Speen Street Framingham, MA 01701 USA P.508.872.8200 F.508.935.4015More information
Cyber Security Metrics Dashboards & Analytics
Cyber Security Metrics Dashboards & Analytics Feb, 2014 Robert J. Michalsky Principal, Cyber Security NJVC, LLC Proprietary Data UNCLASSIFIED Agenda Healthcare Sector Threats Recent History Security MetricsMore information
Pragmatic Metrics for Building Security Dashboards
SESSION ID: GRC-W03 Pragmatic Metrics for Building Security Dashboards James Tarala Principal Consultant Enclave Security @isaudit Problem Statement What s measured improves. Peter Drucker In an era ofMore information
What is Penetration Testing?
White Paper What is Penetration Testing? An Introduction for IT Managers What Is Penetration Testing? Penetration testing is the process of identifying security gaps in your IT infrastructure by mimickingMore information
2012 Bit9 Cyber Security Research Report
2012 Bit9 Cyber Security Research Report Table of Contents Executive Summary Survey Participants Conclusion Appendix 3 4 10 11 Executive Summary According to the results of a recent survey conducted byMore information
What s Wrong with Information Security Today? You are looking in the wrong places for the wrong things.
What s Wrong with Information Security Today? You are looking in the wrong places for the wrong things. AGENDA Current State of Information Security Data Breach Statics Data Breach Case Studies Why currentMore information
The introduction covers the recent changes is security threats and the effect those changes have on how we protect systems.
1 Cyber-attacks frequently take advantage of software weaknesses unintentionally created during development. This presentation discusses some ways that improved acquisition practices can reduce the likelihoodMore information
Manage Vulnerabilities (VULN) Capability Data Sheet
Manage Vulnerabilities (VULN) Capability Data Sheet Desired State: - Software products installed on all devices are free of known vulnerabilities 1 - The list of known vulnerabilities is up-to-date DesiredMore information
Analyzing Security for Retailers An analysis of what retailers can do to improve their network security
Analyzing Security for Retailers An analysis of what retailers can do to improve their network security Clone Systems Business Security Intelligence Properly Secure Every Business Network Executive SummaryMore information
Whitepaper MODERN THREATS DRIVE DEMAND FOR NEW GENERATION TWO-FACTOR AUTHENTICATION
Whitepaper MODERN THREATS DRIVE DEMAND FOR NEW GENERATION TWO-FACTOR AUTHENTICATION A RECENT SURVEY SHOWS THAT 90% OF ALL COMPANIES HAD BEEN BREACHED IN THE LAST 12 MONTHS. THIS PARED WITH THE FACT THATMore information
State of Montana Montana Board of Crime Control. Agency IT Plan Fiscal Year 2012-2017
State of Montana Montana Board of Crime Control Agency IT Plan Fiscal Year 2012-2017 Prepared July 2012 Brooke Marshall, Executive Director Jerry Kozak, IT Manager Board of Crime Control 5 S Last ChanceMore information
Appalachian Regional Commission Evaluation Report. Table of Contents. Results of Evaluation... 1. Areas for Improvement... 2
Report No. 13-35 September 27, 2013 Appalachian Regional Commission Table of Contents Results of Evaluation... 1 Areas for Improvement... 2 Area for Improvement 1: The agency should implement ongoing scanningMore information
Addressing APTs and Modern Malware with Security Intelligence Date: September 2013 Author: Jon Oltsik, Senior Principal Analyst
ESG Brief Addressing APTs and Modern Malware with Security Intelligence Date: September 2013 Author: Jon Oltsik, Senior Principal Analyst Abstract: APTs first came on the scene in 2010, creating a waveMore information
External Supplier Control Requirements
External Supplier Control s Cyber Security For Suppliers Categorised as Low Cyber Risk 1. Asset Protection and System Configuration Barclays Data and the assets or systems storing or processing it mustMore information
Information Technology Risk Management
Find What Matters Information Technology Risk Management Control What Counts The Cyber-Security Discussion Series for Federal Government security experts... by Carson Associates your bridge to better ITMore information
CDM Software Asset Management (SWAM) Capability
CDM Software Asset Management (SWAM) Capability Department of Homeland Security Office of Cybersecurity and Communications Federal Network Resilience Table of Contents 1 PURPOSE AND SCOPE... 2 2 THREATMore information
Cyber Security. BDS PhantomWorks. Boeing Energy. Copyright 2011 Boeing. All rights reserved.
Cyber Security Automation of energy systems provides attack surfaces that previously did not exist Cyber attacks have matured from teenage hackers to organized crime to nation states Centralized controlMore information
National Endowment for the Arts Evaluation Report. Table of Contents. Results of Evaluation... 1. Areas for Improvement... 2. Exit Conference...
NEA OIG Report No. R-13-03 Table of Contents Results of Evaluation... 1 Areas for Improvement... 2 Area for Improvement 1: The agency should implement ongoing scanning to detect vulnerabilities... 2 AreaMore information
Cyber - Security and Investigations. Ingrid Beierly August 18, 2008
Cyber - Security and Investigations Ingrid Beierly August 18, 2008 Agenda Visa Cyber - Security and Investigations Today s Targets Recent Attack Patterns Hacking Statistics (removed) Top Merchant VulnerabilitiesMore information
Everything You Wanted to Know about DISA STIGs but were Afraid to Ask
Everything You Wanted to Know about DISA STIGs but were Afraid to Ask An EiQ Networks White Paper 2015 EiQ Networks, Inc. All Rights Reserved. EiQ, the EiQ logo, the SOCVue logo, SecureVue, ThreatVue,More information
The Importance of Cybersecurity Monitoring for Utilities
The Importance of Cybersecurity Monitoring for Utilities www.n-dimension.com Cybersecurity threats against energy companies, including utilities, have been increasing at an alarming rate. A comprehensiveMore information
Industrial Cyber Security Risk Manager. Proactively Monitor, Measure and Manage Cyber Security Risk
Industrial Cyber Security Risk Manager Proactively Monitor, Measure and Manage Cyber Security Risk With Today s Cyber Threats, How Secure is Your Control System? Today, industrial organizations are facedMore information
Data Privacy: The High Cost of Unprotected Sensitive Data 6 Step Data Privacy Protection Plan
WHITE PAPER Data Privacy: The High Cost of Unprotected Sensitive Data 6 Step Data Privacy Protection Plan Introduction to Data Privacy Today, organizations face a heightened threat landscape with dataMore information
Course Title: Penetration Testing: Network & Perimeter Testing
Course Title: Penetration Testing: Network & Perimeter Testing Page 1 of 7 Course Description: The Security Analyst Series from EC-Council Press is comprised of five books covering a broad base of topicsMore information
Enterprise Cybersecurity: Building an Effective Defense
Enterprise Cybersecurity: Building an Effective Defense Chris Williams Oct 29, 2015 14 Leidos 0224 1135 About the Presenter Chris Williams is an Enterprise Cybersecurity Architect at Leidos, Inc. He hasMore information
E-Guide. Sponsored By:
E-Guide Signature vs. anomaly-based behavior analysis News of successful network attacks has become so commonplace that they are almost no longer news. Hackers have broken into commercial sites to stealMore information
Top 20 Critical Security Controls
Top 20 Critical Security Controls July 2015 Contents Compliance Guide 01 02 03 04 Introduction 1 How Rapid7 Can Help 2 Rapid7 Solutions for the Critical Controls 3 About Rapid7 11 01 INTRODUCTION The NeedMore information
NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS Scope and Applicability: These Network and Certificate System Security Requirements (Requirements) apply to all publicly trusted Certification AuthoritiesMore information
Attack Intelligence: Why It Matters
Attack Intelligence: Why It Matters WHITE PAPER Core Security +1 617.399-6980 email@example.com www.coresecurity.com A Proactive Strategy Attacks against your organization are more prevalent than ever,More information
Christina Kormos National Agency Phone: (410)854-6094 Fax: (410)854-4661 firstname.lastname@example.com Lisa A. Gallagher (POC) Arca Systems, Inc. Phone: (410)309-1780 Fax: (410)309-1781 firstname.lastname@example.com USINGMore information
Integrated Threat & Security Management.
Integrated Threat & Security Management. SOLUTION OVERVIEW Vulnerability Assessment for Web Applications Fully Automated Web Crawling and Reporting Minimal Website Training or Learning Required Most AccurateMore information
Data- centric Security: A New Information Security Perimeter Date: March 2015 Author: Jon Oltsik, Senior Principal Analyst
ESG Solution Showcase Data- centric Security: A New Information Security Perimeter Date: March 2015 Author: Jon Oltsik, Senior Principal Analyst Abstract: Information security practices are in the midstMore information
Obtaining Enterprise Cybersituational
SESSION ID: SPO-R06A Obtaining Enterprise Cybersituational Awareness Eric J. Eifert Sr. Vice President Managed Security Services DarkMatter Agenda My Background Key components of the Cyber SituationalMore information
Reducing the cost and complexity of endpoint management
IBM Software Thought Leadership White Paper October 2014 Reducing the cost and complexity of endpoint management Discover how midsized organizations can improve endpoint security, patch compliance andMore information
AUTOMATED PENETRATION TESTING PRODUCTS Justification and Return on Investment (ROI) EXECUTIVE SUMMARY This paper will help you justify the need for an automated penetration testing product and demonstrateMore information