Dynamic Design and Co-simulation of Response Plans against Simultaneous Attacks

Get Complete Project Material File(s) Now! »

Kanoun et al.’s Taxonomy

In [KSCB+13], Kanoun et al. propose to go beyond Stakhanova et al.’s taxonomy and propose risk-aware response models. By adopting a risk-sensitive response, they can meet the most important requirements (i.e. proactive, adaptable and cost-sensitive). If we examine the definition of risk (see Section 2.4), it is always a combination of the likelihood of the threat with its impact. Therefore, a risk assessment approach supposes that the threat has not yet been observed. Consequently, a risk-aware response system is proactive.
Moreover, it is also cost-sensitive, because the impact is the second element of the risk. Furthermore, a real-time risk assessment ensures that the response system is adaptable, as the risk evaluation depends mainly on the system state, and the attack progress. Finally, the risk acceptance must guarantee that the residual risks are explicitly accepted by the organization.
On the other hand, Kanoun et al. also consider the deactivation of the response. Response actions are often temporary measures which are activated and deployed to counter a detected threat. Therefore, a response once activated should be at certain time deactivated, if possible. Existing taxonomies and response systems do not take into account the deactivation phase in the response procedure. Thus, response actions (or systems) cannot be classified with respect to their effectiveness, lifetime, defeasibility, etc. which are relevant properties for the deactivation phase. Therefore, Kanoun et al.’s present a temporal taxonomy, which is relevant to the deactivation phase of the response. This taxonomy, presented in Figure 2.9, distinguishes two major classes of responses: one-shot (e.g. closing a connection) and sustainable (e.g. patching software, blocking a machine, suspending an account, etc.). Contrarily to a one-shot response, a sustainable response has a lifetime which sustains for a period of time (which may tend to infinite) and its effectiveness is not limited to a single attack occurrence. Therefore, the activation of a sustainable response can be effective against future attack occurrences, until this response is deactivated. Sustainable responses were then classified into: defeasible and indefeasible responses. Unlike a defeasible response, an indefeasible response cannot be deactivated, or its deactivation requires exceptional effort. Examples of this class include: deleting an account, patching an OS, patching a software, etc..

Coordination-aware Action Scheme for Attacks

In order to formally describe all types of attacks, we model system’s state in terms of predicates. And we consider three disjoint sets of predicates:
The set 􀀀 of system-related predicates: it includes predicates that describe the evolution of system’s state. Attributes of a system-related predicate are always system assets, e.g. is_on(Server).
Two disjoint sets A and B of attacker-related predicates: they include predicates that describe the evolution of the attacker’s state. The subject of an attacker-related predicate is always an attackerID which is a unique way of identifying an attacker. A is the set of predicates describing the attacker’s privilege relatively to the system assets, e.g. is_registered(AttackerID; SIP_Server). B is the set of predicates describing the knowledge gained by an attacker after exploiting a particular characteristic of the system, e.g. knows(AttackerID; is_on(User)).
We model attacks by the generic Definition 1 specifying: the subject(s) performing the action, the action’s object(s) and six different subsets of A, B and 􀀀. These attack patterns are interpreted by the action precondition and postcondition. The precondition is a conjunction of one logic condition on the required number of participating subjects, and three logic conditions on the action’s predicates (in AX, BX and 􀀀X) to be satisfied in order to start executing this action. The postcondition is a conjunction of three logic conditions on the action’s predicates (in A0 X, B0X , and 􀀀0 X) that become true after executing it. When several subjects participate in an action, we denote them by coordinated subjects. Besides, we adopt the most pessimistic hypothesis from the defender point of view: We assume that if there is knowledge that should be acquired by all coordinated subjects in the action’s precondition, it is sufficient that one of the subjects has this knowledge, to consider that all of the others have it. Actually, we are based on the fact that knowledge can be shared between coordinated subjects. Hence, every predicate in BX needs to be fulfilled by only one of the subjects. Similarly, for the knowledge gained after the action’s execution, we consider that each coordinated subject fulfills all the predicates in B 0 X.

READ  A Divided, Quiet Black Community

Coordinated Attacks (CA)

A CA is an action made of joint individual actions executed by several collaborating attackers. Hence, the subject is a Group of Coordinating Attackers GCA = fattackerID1; :::; attackerIDog. Here, we need to specify which attacker of the group fulfills which predicate of the CA subsets. Thus, we distinguish three types of CAs depending on the type of collaboration between the attackers: (a) CA with Load Accumulation (CALA), (b) CA with load distribution (CALD), and (c) CA with Role Distribution (CARD). Figure 3.1 clarifies ourattacks classification. The attack patterns of each type differ in, (i) the attackers’ required number, (ii) the A-related conditions, and (iii) the A0-related conditions. Therefore, we will only consider these three distinguishing patterns.

CA with Load Accumulation (CALA)

CALA is a CA that is beyond the capability of a single attacking source, and for which attackers accumulate their capacities offering a distributed and simultaneous execution of this action. Definition 2 describes the distinguishing terms of a CALA_X. Although every attacker of the GCA group executes exactly the same individual action, the overlapping of all the individual effects leads to a compromised state. Consequently, each attacker fulfills all attacker-related predicates in the ACALA_X set. And after a CALA is executed, all attackers gain the same system privileges 0. Additionally, CALA_X needs a minimum number minCALA_X of coordinating attackers to be successful. This number is striclty greater than one, and can be estimated based on the characteristics of the attack target (i.e. objects).

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

GET THE COMPLETE PROJECT

Related Posts