Project topics and materials
Get Complete Project Material File(s) Now! »
Response Execution
The main limitation of previous approaches is the large number of countermeasures to be selected especially when the corresponding attack scenario is constituted of a large number of attack steps. The challenge in AIRSs is to select the optimal set of candidate responses in real time. There are two types of AIRSs according to the type of response execution [Shameli-Sendi et al. 2012]: burst and retroactive. Burst approaches present AIRSs that do not consider a mechanism to measure the risk index of the monitored host once the countermeasure has been applied. In this model, monitored system can apply a large set of responses, given a detected intrusion, while a subset of these responses may be enough to stop the attack. The major weakness of burst approaches is the high cost in system performance and quality of service. In other words, the only objective of such approaches is to mitigate the attack without considering the nominal system functional behaviors (e.g., performance, availability). For instance, when considering two responses against intrusion where the first is to filter the suspect host and the second is to block all the connected hosts. The second countermeasure causes availability loss and can be avoided when applying filtering suspect host is enough to mitigate the attack.
Retroactive approaches provide a feedback mechanism that measures the coun-termeasure effect based on the responses history. This approach was first pro-posed in [Mu and Li 2010]. The authors presented a response measure decision-making model that optimizes the generated responses set by avoiding unneces-sary responses and reducing the risk of false positive response. Existing works [Foo et al. 2005, Stakhanova et al. 2007b, Lee et al. 2002, Shameli-Sendi et al. 2013] propose approaches that rely on heuristics to reduce the size of candidate responses given a detected attack scenario. In order to limit the size of the system responses set, ADEPTS considers only the countermeasures that are applicable in the sites where the detected alert was generated. ADEPTS uses a graph of intrusion goals called I − Graph. It provides a semi-automated method called P ortableI − Graph (PIG) that determine the possible path of spread of the intrusion, appropriate services where to deploy the response, and appropriately choose the response. ADEPTS is not eval-uating the candidate system responses according to the response effect on the overall system. The proposed approach considers only the system response effect on the spe-cific service where it is deployed. The authors in [Stakhanova et al. 2007b] presented a retroactive AIRS based on a confidence level threshold; if the selected countermeasure mitigates the attack, its success factor is increased by one, and it is decreased by one on the contrary.
Prediction Ability
From the prediction ability point of view, AIRSs can be classified into two categories:
In reactive approaches, system responses are applied only after an intrusion objective is achieved. Most existing AIRSs use this approach (e.g., [Papadaki and Furnell 2006], [Strasburg et al. 2009]), although this approach is not useful in critical systems where high security is required. For instance, suppose that an attacker steals confidential and critical information. In this case, a reactive response is not useful since the confidential information has already been disclosed. In [Anuar et al. 2010], the authors present the drawbacks of using reactive approach, which are the following:
• System responses are applied after an intrusion detection, so the system remains in a vulnerable state until the reactive response is applied.
• It is difficult to return the system to the safety state.
• The attacker has a delay between intrusion detection and system response, this delay provides a window of opportunity for the attacker to be exploited.
• From the monitored system point of view, it is easier to maintain system in safe condition than returning it from an unhealthy state to the normal conditions.
• Systems are exposed to an important risk of damage, since responses are applied after an incident is detected.
Attack Description Languages
IDSs are responsible for detecting the occurrence of certain events in the monitored system. These events correspond to actions performed by the attacker, these actions being part of its attack strategy. An alert corresponding to the detection of a certain action contains information on involved machines (i.e., the action source and targeted hosts), and provides the name of the associated action. The amount and type of information transported by the alert are directly dependent on the detection technique used. These information do not provide actions semantics; trying to reason on such information is therefore very difficult. In order to reason on a set of alerts and draw conclusions from these observations, it is necessary to model the detectable actions to associate a semantic alerts. In the following, we present existing attack description languages, and we show how they are used.
CAML
This language is developed and used in [Cheung et al. 2003] as part of C orrelated Attack M odeling (CAM) project [CAM 2003]. The purpose was to define a high level language so that it can be used by different correlation modules. CAML permits to model the steps of intrusion scenarios. An action is represented by a CAML module and its links with other modules are expressed by the specification of a pre-condition and a post-condition field. CAML language is accompanied by a predicates library representing vocabulary allowing to describe system properties according to an action model. A CAML module consists of three sections:
• activity: specifies events list to observe in order to instantiate an action model represented by a module. CAML events are based on the IDMEF format [Debar et al. 2007].
• pre-condition: defines the system state required for the execution of the action. This field defines, in addition, required conditions of other events already observed. For instance, as shown in Figure 2.3, the pre-condition field require that r1 must be observed before r2.
• post-condition: defines a list of predicates and events inferred once activity and pre-condition fields was satisfied.
Figure 2.3 presents a modeling of action that execute locally a code allowing the attacker access to confidential information.
Table of contents :
1 Introduction
1.1 Motivation
1.2 Contributions
1.3 Organization of the dissertation
2 Automated System Response against Intrusion: State of the Art
2.1 Introduction
2.2 Intrusion Response System Definition
2.3 Automated Intrusion Response Systems (AIRSs)
2.3.1 Response Selection
2.3.2 Adjustment Ability
2.3.3 Response Execution
2.3.4 Prediction Ability
2.4 Attack Description Languages
2.4.1 CAML
2.4.2 ATiKi
2.4.3 ADeLe
2.4.4 LAMBDA
2.5 Conclusion
3 Introduction to the Argumentation Logic
3.1 Introduction
3.2 Motivation
3.3 Argumentation frameworks
3.3.1 Abstract Argumentation Framework (AAF)
3.3.2 Preference-based Argumentation Framework (PAF)
3.3.3 Value-based Argumentation Framework (V AF)
3.4 Related Work
3.4.1 Argumentation logic for firewall policy specification
3.4.2 Argumentation logic for access control
3.4.3 Argumentation logic for network security analysis
3.5 Conclusion
4 Context-aware Response against Intrusion Detection
4.1 Introduction
4.2 Modeling the intrusion processes
4.2.1 Modeling the attacker
4.2.2 Anticipating the attacker’s intentions
4.2.3 Intrusion Scenario
4.2.4 Modeling countermeasures
4.3 Argumented intrusion response against attacks
4.3.1 Constructing the set of arguments
4.3.2 Extending value-based argumentation frameworks
4.3.3 Managing contexts
4.3.4 Argumented and context aware reaction mechanism
4.3.5 Avoiding unexpected side effects of countermeasures
4.3.6 Architecture
4.4 Reaction process in an automotive context
4.4.1 Automotive system
4.4.2 Attack modeling
4.4.3 Response model
4.4.4 Rationales
4.4.5 Intrusion response selection
4.4.6 Performance evaluation
4.5 Conclusion
5 Multi-Criteria Recommender Tool for Supporting Intrusion Response System
5.1 Introduction
5.2 Related work
5.3 Multi-Criteria Decision Making module
5.3.1 Learning module
5.3.2 Recommending module
5.3.3 Security administrator interface
5.4 MCDM module integration
5.4.1 Prediction phase
5.4.2 System response generation phase
5.4.3 Recommendation phase
5.4.4 Matrix update phase
5.5 Application to the automotive case of study
5.5.1 Deployment scenario
5.5.2 Performance evaluation
5.6 Conclusion
6 Implementation and Evaluation
6.1 Introduction
6.2 CRIM
6.2.1 Features and architecture
6.2.2 Models
6.3 Implementation
6.3.1 Preferred extension generation
6.3.2 MCDM integration
6.3.3 Learning file
6.4 Evaluation
6.5 Conclusion
7 Conclusions and Perspectives
7.1 Contributions
7.2 Perspectives
7.2.1 Coordinated attack
7.2.2 Extending the formal model
7.2.3 The attacker’s point of view
8 Résumé en français
8.1 Introduction
8.2 Génération des scénarios d’attaques
8.2.1 Génération des scénarios d’attaques
8.2.2 Systèmes d’argumentation à base de valeurs étendue
8.2.3 Génération des contre-mesures sensibles au contexte
8.3 Approche multicritère pour la prise de décision
8.4 Application sur les systèmes automobiles
8.5 Implémentation et évaluation
8.5.1 CRIM
8.5.2 Evaluation
8.6 Conclusion
A CRIM modules Source Code
A.1 Generation of attack scenarios
A.2 Anti-correlation between models
A.3 Attack relation between countermeasures
B Glossary
List of Publications
Bibliography
