Project topics and materials
Get Complete Project Material File(s) Now! »
Attack Graphs handling Concurrent Attacks
Braynov et al.: A coordinated attack graph is defined in [BJ03] as a possible sequence of concurrent actions executed by all observed attackers in the network. Graphs were generated based on the Partial Order Multiagent Planning algorithm (POMP) [BB01], which is a variant of Concurrent STRIPS. Figure 2.3 is a graph representing the symbolic link race attack modeled in Concurrent STRIPS in Section 2.2. POMP was the preferred representation of the planning community for several years. However, being a first-order logic language, Concurrent STRIPS language is not as much expressive as concurrent SC. Moreover, the performance of POMP is greatly affected by the ordering of agenda items / actions. Hence, heuristics were proposed through defining subgoals for each goal. However, finding subgoals in network attacks requires a high level of expertise, especially when goals can be reached by several paths.
Petri Nets: In [McD00], a new process model for penetration testing based on Petri nets paradigm was proposed. The proposed approach is to organize penetration testing according to an attack net. An attack net is a (disjunctivel) Petri net with a set P = fp0; pl; p2::::png of places representing interesting (e.g. control or knowledge of) states or modes of the security relevant entities of the system of interest. The attack net also has a set T = ft0; tl; t2; :::; tng of transitions that represent input events, commands, or data that cause one or more security relevant entities to change state. Places are connected to transitions and transitions are connected to places by directed arcs. The attack net has a set of tokens. Tokens move from place to place along the directed arcs to indicate the progress of the attack. If a token is at a place, then the attacker has gained control of the corresponding entity, in the state represented by the place. If place pi precedes place pj in the attack net, then the attack must achieve the control or knowledge represented by place pi before the control or knowledge represented by place pj is possible. Attack nets support cycles describing recursive, thus non monotonic, attacks. Figure 2.4 models a generic distributed denial of service attack on a single host. The first place, holding the single token, represents the attacker’s initial control of the attacking host. The first level of transitions are high-level abstractions of the actions taken to gain control of multiple accomplice hosts. The multiple places in the middle represent the attacker’s control of the accomplice hosts. The second level of transitions from these places represent the generation of spurious service requests by the accomplice hosts. The last place represents the condition where the victim host is flooded and cannot respond. The key features of attack nets are:
Modeling concurrency and attack progress with tokens
Modeling intermediate and final objectives as places
Modeling commands or inputs as transitions.
Attack Graphs restricted to Individual Attacks
We first distinguish between approaches based on logic languages to model attacks, as CRIM [CM02] which is based on LAMBDA, and approaches restricted to topology attacks description. Among these latter, we distinguish those which adopt non monoticity in their attack scenario elaboration, as Sheyner, et. al [SW04] and Kanoun et al. [KPD12], and those which adopts monoticity allowing them to be scalable as CAULDRON4, MulVAL5, Jajodia et al. [JNOB05], Ammann et. al. [AWK02], Ingols et al. [ILP06], Xie et al. [XCW+09].
We present here, a brief description of each of the attack graph generation work cited here above. CRIM: In [CM02], Cuppens and Miege suggested an approach to perform alert correlation based on the analysis of attack description specified in LAMBDA. The work is done within the MIRADOR project to design CRIM, a cooperative module for intrusion detection systems (IDS). This module implements functions to manage, cluster, merge and correlate alerts. The clustering and merging functions recognize alerts that correspond to the same occurrence of an attack and create a new alert that merge data contained in these various alerts. The central idea of the approach is to recognize whether executing a given attack can contribute to execute another attack. This idea is modeled by specifying possible logical links between the post-condition of an attack A and the pre-condition of an attack B. If such a link exists, then it is possible to correlate an occurrence of attack A with an occurrence of attack B. This is based on the assumption that the intruder has performed A as a step that enables him to perform B. In this work, an abstract attack graph is first generated in offline. This latter covers all possible attacks paths leading an attacker to one of the critical assets in the system. It is generated before running the system, and then attacks nodes are instantiated as corresponding alerts are observed online. MulVAL 6: MULVAL (Multihost, multistage Vulnerability Analysis) is a framework for modeling the interaction of software bugs with system and network configurations. Mul- VAL uses Datalog as its modeling language. The information in the vulnerability database provided by the bug-reporting community, the configuration information of each machine and the network, and other relevant information are all encoded as Datalog facts. The reasoning engine consists of a collection of Datalog rules that captures the operating system behavior and the interaction of various components in the network. Thus integrating information from the bug-reporting community and off-the-shelf scanning tools in the reasoning model is straightforward. Note that the exploit model is automatically extracted from the off-the-shelf vulnerability database and no human intervention is needed. The inputs to MulVAL’s analysis are:
Advisories: What vulnerabilities have been reported and do they exist on machines?
Host configuration: What software and services are running on hosts, and how are they configured?
Network configuration: How are network routers and firewalls configured?
Principals: Who are the users of the network?
Interaction: What is the model of how all these components interact?
Policy: What accesses do I want to permit?
Risk Management Methodologies
Clearly, a finite and limited budget is allocated in order to secure a system. Therefore, the expert must spend this budget wisely, and address optimally the potential threats of the monitored system. Risk management has traditionally been a manual analysis process during system design or through periodic reviews. For this purpose, the ISO standard 27005, part of the ISO 27000 series, [iso09], proposes an independent and general guidelines for information security risk management. This standard contains the general requirements for risk management of information systems. However, this standard does not propose a specific methodology to risk management for information systems. Instead, each organization should define (or adopt) a given risk management methodology, which must be compatible with the guidelines as proposed in this standard. First, we present the definitions of the risk-related terminology, as proposed by the standard ISO 27000:
information security preservation of confidentiality, integrity and availability of information.
threat: potential cause of an unwanted incident, which may result in harm to a system or organization.
incident: single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security. For instance, a complex attack scenario is an incident.
risk : combination of the probability of an event and its consequence.
Table of contents :
Abstract
Resumé
Acknowledgements
Remerciements
Contents
List of Figures
List of Tables
1 Introduction
1.1 Context
1.2 Problem Statement
1.3 Contribution
1.4 Outline of the dissertation
2 Preliminaries and State of the Art
2.1 Introduction
2.2 Attack Modeling Languages
2.2.1 LAMBDA
2.2.2 JIGSAW
2.2.3 Concurrent STRIPS
2.2.4 Discussion
2.3 Attack Graphs Generation
2.3.1 Attack Graphs handling Concurrent Attacks
2.3.2 Attack Graphs restricted to Individual Attacks
2.3.3 Discussion
2.4 Risk Management Methodologies
2.4.1 Context Establishment
2.4.2 Risk Assessment
2.4.3 Risk Treatment
2.4.4 Risk Acceptance
2.4.5 Discussion
2.5 Response Taxonomies
2.5.1 Wang et al.’s Taxonomy
2.5.2 Stakhanova et al.’s Taxonomy
2.5.3 Kanoun et al.’s Taxonomy
2.5.4 Discussion
2.6 Response Systems
2.6.1 Cost-aware Response Systems
2.6.2 Risk-aware Response Systems
2.6.3 Discussion
2.7 Conclusion
3 Graphs Generation for Simultaneous Attack Scenarios
3.1 Introduction
3.2 Coordination-aware Action Scheme for Attacks
3.2.1 Individual Attacks (IA)
3.2.2 Coordinated Attacks (CA)
3.2.3 CA with Load Accumulation (CALA)
3.2.4 CA with Load Distribution (CALD)
3.2.5 CA with Role Distribution (CARD)
3.3 Modeling Attack Graphs
3.3.1 Individual Attack Graphs (IAG)
3.3.2 Simultaneous Attacks Graphs (SAG)
3.4 Modeling Attacks with Situation Calculus
3.4.1 Situation Calculus (SC)
3.4.2 Individual Attacks
3.4.3 Coordinated Attacks
3.4.4 Simultaneous Attacks
3.5 Deriving Simultaneous Attack Scenarios in Situation Calculus
3.5.1 Simultaneous Attacks Planner (SAP)
3.5.2 Complexity and Performance of SAP
3.5.3 Enhanced SAP (eSAP)
3.6 Simultaneous Attacks Graph Generator (SAGG)
3.7 Implementation and Experimentation
3.8 Discussion
3.9 Conclusion
4 Risk Assessment for Simultaneous Attack Scenarios
4.1 Introduction
4.2 Risk-aware Simultaneous Attacks Graphs
4.3 Likelihood of an Attack
4.3.1 Game Theory and the Probability of Attacking
4.3.2 Return on Attack Investment (ROAI)
4.3.3 Coordination-aware Estimation of Payoffs
4.4 Likelihoods of Simultaneous Attack Scenarios
4.5 VoIP use Case
4.5.1 Attackers Profiles and Attack Goals Impact
4.5.2 Payoffs Estimation
4.5.3 Implementation and Experimentation
4.6 Impact Assessment of Attack Scenarios
4.7 Risk Assessment and Prioritization
4.7.1 Risk Assessment of Attack Scenarios
4.7.2 Example
4.7.3 Prioritizing Risky SAGs
4.8 Discussion
4.9 Conclusion
5 Dynamic Design and Co-simulation of Response Plans against Simultaneous Attacks
5.1 Introduction
5.2 New scheme for a Complex Response
5.2.1 Applicability-aware Anticorrelation for Elementary System Actions .
5.2.2 Applicability-aware Anticorelation for Complex System Actions
5.2.3 Complex Response
5.3 Modeling Responses with Situation Calculus (SC)
5.3.1 Elementary System Actions
5.3.2 Concurrent System Actions
5.3.3 Anticorrelation in Situation Calculus
5.4 Planning in Situation Calculus
5.4.1 Dynamic Response Co-Simulator
5.5 Experimentation
5.5.1 Use Case 1
5.5.2 Use Case 2
5.6 Optimal Response Plan Selection
5.6.1 Risk-aware Selection of Optimal Response
5.6.2 Example
5.7 Discussion
5.8 Conclusion
6 Conclusion
6.1 Our proposal
6.2 Discussion and Perspectives
6.2.1 Graph Generation
6.2.2 Risk Assessment
6.2.3 Response Generation
6.2.4 Overall Proposal Application
Bibliography
