Keywords:

Security Information and Event Management (SIEM) systems provide the security analysts with a huge amount of alerts. Managing and analyzing such tremendous number of alerts is a challenging task for the security administrator. Alert correlation has been designed in order to alleviate this problem. Current alert correlation techniques provide the security administrator with a better description of the detected attack and a more concise view of the generated alerts. That way, it usually reduces the volume of alerts in order to support the administrator in tackling the amount of generated alerts. Unfortunately, none of these techniques consider neither the knowledge about the attacker's behavior nor the enforcement functionalities and the defense perimeter of the protected network (Firewalls, Proxies, Intrusion Detection Systems, etc). It is still challenging to first improve the knowledge about the attacker and second to identify the policy enforcement mechanisms that are capable to process generated alerts. Several authors have proposed different alert correlation methods and techniques. Although these approaches support the administrator in processing the huge number of generated alerts, they remain limited since these solutions do not provide us with more information about the attackers' behavior and the defender's capability in reacting to detected attacks. In this dissertation, we propose two novel alert correlation approaches. The first approach, which we call honeypot-based alert correlation, is based on the use of knowledge about attackers collected through honeypots. The second approach, which we call enforcement-based alert correlation, is based on a policy enforcement and defender capabilities' model.

iii RESUME iv

Résumé

Les SIEMs (systèmes pour la Sécurité de l'Information et la Gestion des Evénements) sont les coeurs des centres opérationnels de la sécurité. Ils corrèlent un nombre important d'événements en provenance de différents capteurs (anti-virus, pare-feux, systèmes de détection d'intrusion, etc), et offrent des vues synthétiques pour la gestion des menaces ainsi que des rapports de sécurité. La gestion et l'analyse de ce grand nombre d'alertes est une tâche difficile pour l'administrateur de sécurité. La corrélation d'alertes a été conçue afin de remédier à ce problème. Des solutions de corrélation ont été développées pour obtenir une vue plus concise des alertes générées et une meilleure description de l'attaque détectée. Elles permettent de réduire considérablement le volume des alertes remontées afin de soutenir l'administrateur dans le traitement de ce grand nombre d'alertes. Malheureusement, ces techniques ne prennent pas en compte les connaissances sur le comportement de l'attaquant, les fonctionnalités de l'application et le périmètre de défense du réseau supervisé (pare-feu, serveurs mandataires, Systèmes de détection d'intrusions, etc). Dans cette thèse, nous proposons deux nouvelles approches de corrélation d'alertes. La première approche que nous appelons corrélation d'alertes basée sur les pots de miel utilise des connaissances sur les attaquants recueillies par le biais des pots de miel. La deuxième approche de corrélation est basée sur une modélisation des points d'application de politique de sécurité. v ACKNOWLEDGEMENT vi Acknowledgement I would like to express my sincerest gratitude and thanks to my supervisor Pr. Hervé Debar who provided support and guidance. I deeply appreciate his guidance

Chapter 1

Introduction S ecurity issues are becoming increasingly severe to organizations. Thus, it is vital to apply appropriate security measures in order to protect both users and organizations. Security mechanisms are deployed in a network in order to prevent attacks and to react to them when detected. In the literature, multiple security mechanisms have been designed to meet the needs of information systems security. These needs can be summarized by security properties such as availability, authentication, confidentiality, integrity and privacy.

The main impact of cyber attacks is financial. According to a joint study performed by Microsoft Digital Crimes Unit (DCU) and National University of Singapore [START_REF] Dcu | The Link between Pirated Software and Cybersecurity Beaches[END_REF], organizations spend around 500 billion US dollars dealing with security issues and data breaches due to malware. Indeed, this economic aspect represents one of attackers motivations. However, many other motivations exist, in particular accessing confidential data and stealing bank accounts. In recent decades, attackers have developed techniques and exploits that are increasingly sophisticated and complex. This makes both of intrusion detection and reaction difficult. In addition, considering the existing limitations of these systems (intrusion detection and reaction), the role of the security administrator is becoming more and more challenging.

Security Information and Event Management (SIEM) systems have been developed to assist the security administrator in achieving his role. SIEM combines two distinct aspects: Security Information Management (SIM) and Security Event Management (SEM) [2]. It focuses on:

• logs collection and normalization; • events analysis and correlation; • events aggregation and reporting. Tarala [3] shows that SIEM systems are able to provide the data required by organizations in order to maintain and improve their security policy. We now review basic definitions related to computer security (Section 1.1). Then, in Section 1.2, we give the problem statement, objective and contributions of this dissertation. Finally, the dissertation road-map is detailed in Section 1.3.

Basic Definitions

Research on alert correlation is a domain where many different related domains such as intrusion detection, intrusion response decision, security policy enforcement, are combined. For a better understanding, a consistent terminology is used along this dissertation. In this section, the basic definitions are given, most of them have been taken from [4]. The rest of the definitions can be found in the glossary of terms of this dissertation.

Information security is the protection of information and its critical elements based on three key factors: Confidentiality, Integrity and Availability (C, I, A) (Figure 1.1), as defined by the International Organization for Standardization (ISO) [5] :

• Confidentiality (C): it protects the data against unauthorized disclosure.

Only authorized users are allowed to access the information; • Integrity (I): it ensures the accuracy and the consistency of the data during its entire life-cycle. It also prevents from unauthorized modifications that can be brought to the information; • Availability (A): it ensures the authorized access to the data when this latter is needed.

Basic Definitions

.2 -Security properties as represented by the McCumber's cube. Source: [6]. This cube contains three blocks: the first block corresponds to the critical information characteristics (C, I, A), the second block corresponds to the information states, and the third block corresponds to the security measures.

• an attempt to gain unauthorized access to system services, resources, information, or; • an attempt to compromise the integrity of a system.

In an organization, identifying threats is usually based on discovering systems' vulnerabilities. Discovered vulnerabilities are generally referred by the MITRE organization 1 . It defines the Common Vulnerabilities and Exposures (CVEs) dictionary,2 , known as CVE-IDs. CVEs are common identifiers for publicly known informationsecurity vulnerabilities in publicly released software packages. In addition, known vulnerabilities are also collected in the Open Source Vulnerability Database (OS-VDB) 3 . OSVDB is an independent and open sourced web-based vulnerability which provides in-depth information about technical security information and vulnerabilities.

In addition to threats associated to system's vulnerabilities, threats can be associated with external and physical weaknesses of the information system. For instance, keeping critical servers in an insecure environment is a potential threat which can be exploited in order to have direct access to the server. To mitigate the effects of a given attack, one needs to implement security measures that are known as Countermeasures. Countermeasures are security actions required to:

• oppose an attack by eliminating or preventing it [4]; • minimize the harm caused by the attack.

In this dissertation, we assume that the implementation of a countermeasure always results into an update of the security policy's implementation. A Security Policy, as defined in [7], defines and constrains the activities of a data processing facility in order to maintain the security of systems and data. Security policies are enforced by Policy Enforcement Points (PEP). A PEP is a logical entity that enforces policies for admission control and decisions in response to a request from a user seeking to access a resource or a service on a computer or a network server. For instance, the "Authentication, Authorization, Accounting" (AAA) protocol, [START_REF] Glass | RFC 2977: Mobile IP Authentication, Authorization, and Accounting Requirements[END_REF], is implemented by PEPs such as access control systems (radius servers, network firewalls, application firewalls, etc).

Problem Statement, Objectives and Contributions

Problem Statement, Objectives and Contributions

This dissertation proposes two different alert correlation approaches allowing a more precise diagnosis of SIEM alerts. The first approach, called "honeypot-based alert correlation", is based on improving the content of these alerts by exploiting the knowledge about the attackers. This knowledge can be gathered using specific attack learning techniques which are the honeypots. Since honeypots are capable to interact with attackers, they expose the attacker capabilities and behavior. In addition, honeypots allow reassessment of vulnerabilities by providing information about attacks' impact.

The second approach, called "enforcement-based alert correlation", is based on the knowledge about policy enforcement capabilities deployed in the information system. This knowledge includes information about the defender capabilities which is deployed in the network to be protected from attacks.

In [START_REF] Tzu | The Art of War[END_REF], Chapter 3, the author states: "One who knows the enemy and knows himself will not be endangered in a hundred engagements. One who does not know the enemy but knows himself will sometimes be victorious. Sometimes meet with defeat. One who knows neither the enemy nor himself will invariably be defeated in every engagement."

Following this citation, the two proposed approaches are complementary, in the sense that the security administrator is able to improve network security by enhancing his knowledge about:

• the attackers: information about the attacker includes details about his behavior and the attack vectors and exploits. This information is convenient for the security administrator to rank the importance of threats exploited by attackers; • the defender: information about the defender include details about his capabilities in enforcing the security policy of the supervised information system. This information is convenient in order to identify the capacity of the defender to mitigate attacks and limit their impacts.

Problem statement :

Current Security Information and Event Management (SIEM) systems process a huge amount of security events without having a better knowledge neither about the attacker nor the defender capabilities.

CHAPT 1. INTRODUCTION

Thesis statement: Attack impact's evaluation and efficient response decision support could significantly benefit from a better knowledge about the attacker and the intrusion response capabilities deployed in the network. Improving our knowledge about the attacker allows a better understanding of alerts and then a more efficient alert correlation. Identifying the policy enforcement capabilitiesdeployed in the network -contributes to apply efficient response decision support.

In order to tackle this problem and validate the thesis statement, the objectives of this dissertation can be defined as follows:

• Objective 1 : designing and experimenting a novel alert correlation methodology which benefits from information collected by honeypots;

• Objective 2 : proposing an Alert Correlation methodology based on the proposed PEP's Responsibility Domain;

• Objective 3 : applying the proposed enforcement-based alert correlation approach on a real case study.

Contributions:

The proposed alert correlation approaches developed in this dissertation rely on existing data provided by both honeypots and the configurations of deployed PEPs.

In our "honeypot-based alert correlation" proposed approach, we study the application of attackers' information provided by honeypots in order to correlate alerts. Moreover, since information about attackers is not generally sufficient to improve response decision, we propose an "enforcement-based alert correlation" approach which is based on the policy enforcement capabilities deployed in the network. The contributions on this dissertation are detailed as follows:

• Identification of appropriate data that can be provided by honeypots and that can improve our knowledge about generated alerts (Objective 1); • Design of an alert enrichment process which properly improves the information raised in generated alerts and enhances alert correlation (Objective 1); • Identification of honeypot limitations in improving information about alerts and enhancing alert correlation (Objective 1); • Design of a PEP model which illustrates the role of a PEP in an intrusion response decision process. Our model is based on the proposed notion of Responsibility Domain of a PEP (Objective 2); • Development of an enforcement-based alert correlation approach based on the notion of responsibility domain of PEP (Objective 2) and the analysis of its application on the security patterns commonly used in security architecture 1.3. Dissertation road-map (Objective 3).

Dissertation road-map

This dissertation is organized as follows:

Chapter 2 -Computer Security, Intrusion Detection and Response Decision: a State Of the Art describes the state of the art in intrusion detection and response as well as alert representation, honeypot techniques and alert correlation. From the identified limitations of intrusion detection and alert correlation techniques, we propose two alert correlation approaches as introduced above: honeypot-based alert correlation and enforcement-based alert correlation.

Chapter 3 -Alert Correlation based on honeypots introduces the usability of honeypot datasets in order to improve information about generated alerts. In this chapter, we detail our honeypot-based alert correlation. We demonstrate how honeypots can be deployed in order to improve our knowledge about generated alerts. We then propose an alert enrichment process based on honeypot datasets. We detail our experimental results and discuss the different limitations related to the application of honeypots in our proposed alert correlation. Chapter 3 fulfils to Objective 1.

Chapter 4 -PEP Model formalizes the proposed PEP model. In this chapter, we show how responsibility domain of a PEP can be approximated. We also propose five approximation methods that can be applied in alert correlation. We evaluate these approximations and analyse their impact on alert correlation. Chapter 4 contributes to Objective 2

Chapter 5 -Enforcement-based alert correlation framework defines our proposed enforcement-based alert correlation approach. We investigate the application of the proposed PEP model in correlating alerts. Chapter 5 contributes to Objective 2 Chapter 6 -Applications and interpretations shows two use cases on single and multiple PEP environment and demonstrates the applicability of our model in real scenarios. Chapter 6 fulfils Objective 3 Chapter 7 -Conclusions and Perspectives concludes the dissertation with a summary of contributions and presents the perspectives for future work.

Introduction

S

ecurity Information and Event Management (SIEM) systems represent today an essential tool to meet the security requirements of complex networks. It supports security administrators in identifying, understanding and reacting to intrusions. Moreover, it contributes to maintaining and enforcing the security policy of the network. Thus, a SIEM strongly depends on Intrusion Detection Systems (IDS), Intrusion Response Systems (IRS) and Policy Enforcement Points (PEP). In this chapter, we review the most important areas of security research that are related to our proposed approaches. In Section 2.2, we first give an overview of computer security policy and policy enforcement. Then, Section 2.3 and Section 2.4 describe the different intrusion detection techniques: from traditional IDS to recent honeypot tools. Section 2.5 details the Intrusion Detection and Message Exchange Format (IDMEF) which allows a standard representation of security events and alerts generated by IDS and other security probes. In Section 2.6, we review existing alert correlation approaches. Finally, in Section 2.7, we briefly define Intrusion Response Systems.

Computer security policy and policy enforcement

Computer security policy

Implementing a security service and service arrangement can be complex [START_REF] Grance | Guide to Information Technology Security Services[END_REF]. The security services defined in Section 1.1 are characterized by their costs and risks.

There must be a trade-off between the security services and the organization's security objective. An organization deploys security services depending on the near-term costs and the long-term risks related to the system vulnerabilities and their evolution. The decision maker in this context should study the impact and risk of each potential threat and decide about the security policy to be deployed. Therefore, the security administrator, when defining a security policy, should be aware of several parameters and constraints. One of the most important constraints are the funding allocated to deploy the security policy, the technical and architectural obstacles, the organizational and personnel issues, etc. The ISO 27001 standard [7] specifies the requirements for establishing, implementing, maintaining 2.2. Computer security policy and policy enforcement

.1 -PDCA: Security policy life-cycle, source [7]. It represents the four steps (represented by colored circles) of the security life cycle that are: Plan (orange circle), Do (blue circle), Check (red circle) and Act (green circle).

and continually improving an information security management system within the context of the organization. It also includes requirements for the assessment and treatment of information security risks tailored to the needs of the organization. Thus, it formally specifies the design of an Information Security Management System (ISMS). It defines the most critical steps of the security policy life-cycle which are summarized in the so-called PDCA model shown in Figure 2.1. The PDCA model defines how information security requirements and expectations are processed in order to carry out managed information security. PDCA stands for:

• Plan (P): In this step, the security objectives are identified in accordance with the organization overall policies and objectives. The plan step is depicted by the orange circle in Figure 2.1; • Do (D): the security policy is implemented in this step following the previously defined objectives. The do step is depicted by the blue circle in Figure 2.1; • Check (C): it is important to continuously control the conformity of the implemented security policy with the organization's security objectives. In this step, the ISMS is audited and assessed. The check step is depicted by the red circle in Figure 2.1; • Act (A): this step includes both of the corrective and the preventive actions based on the results of the check step. The objective of the act action is to continuously preserve the security of the organization. The act step is depicted by the green circle in Figure 2.1.

CHAPT 2. COMPUTER SECURITY, IDS AND IRS: A STATE OF THE ART

In practice, the PDCA life cycle is established through the deployment of different techniques and mechanisms, known in general as policy enforcement.

Policy enforcement

Policy enforcement is the application of access control mechanisms. It fulfils the security policy objectives along its life-cycle as detailed in Figure 2.1. In particular, check and act actions ensure the security policy enforcement through setting up and updating configurations on Policy Enforcement Points (PEP).

The deployment of modern information systems and networks is strongly associated with Access Control technologies that are located at critical points of the network. Access control technologies are usually provided by Policy Enforcement Points (PEP). The term of PEP was introduced in [START_REF]eXtensible Access Control Markup Language (XACML)[END_REF] as an entity that performs access control by making decisions requests and enforcing authorization decisions made by the Policy Decision Point (PDP). Referring to the latest version of [START_REF]eXtensible Access Control Markup Language (XACML)[END_REF], a PEP comes in many forms. It can be part of a remote-access gateway, part of a web server or email user-agent, etc.

In [START_REF] Zaborovsky | Access Control Model and Algebra of Firewall Rules[END_REF], the PEP is defined as the most security critical component, which protects the resources and enforces the PDP's decision. Generally, the PDP and the PEP are combined to control access and enforce the security policy. According to [START_REF] Boutaba | Towards extensible policy enforcement points[END_REF], PEPs are defined as modules which reside on the managed devices and are responsible for installing and enforcing the Security Policy. "the Policy Decision Points (PDPs) process Access Control policies, along with other data such as network state information, and take policy decisions regarding what policies should be enforced and how this will happen. These policies are sent as configuration data to the appropriate Policy Enforcement Points (PEPs), which reside on the managed devices and are responsible for installing and enforcing them". In [START_REF] Hamed | Taxonomy of conflicts in network security policies[END_REF], authors define a PEP as a network entity which is responsible of controlling the traversal of packets across network segments.

In [START_REF] Betarte | ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies[END_REF], authors specifies that the logical level integration allows the enforcement of policies through a PEP (Policy Enforcement Point). Usually, in applications where multiple architecture is layered, the PEP is located between the presentation layer and the logical layer, intercepting the application requests, using the controls, and in case the application requests is authorized, it can be executed. As defined in Section 1.1, the PEP can be either a dedicated product (e.g., firewalls, intrusion detection systems), or embedded modules (e.g., patch modules, use of vlans) in larger products or systems. Since policy enforcement is usually distributed along the different communication layer of the system, we categorize the PEPs based on the communication layer on which it is able to enforce decisions:

• Network-level PEP: iptable, checkpoint, fortinet, snort;

• Application-level PEP: ModSecurity, anti viruses; The deployment of these PEPs enforces the security of the supervised system along its different communication layer. PEPs are deployed in a cooperative way in order to satisfy the security policy objectives.

Intrusion Detection System (IDS)

IDS Definition

Authors in [START_REF] Anderson | Computer Security Threat Monitoring and Surveillance[END_REF] and [START_REF] Denning | An Intrusion-Detection Model[END_REF] are the first researchers who tackled the problem of intrusion detection. They defined the foundations of intrusion detection systems. Intrusion detection has a critical role to preserve and control the safety of the organization.

In the literature, we may find different intrusion detection definition. Definition given in [START_REF] Bace | Intrusion Detection Systems[END_REF] is the most suitable one where IDS is defined as the process of monitoring the events occurring in a computer system or network and analyzing them for signs of intrusions, defined as attempts to compromise the confidentiality, integrity, availability, or to bypass the security mechanisms of a computer or network. Figure 2.2 represents a generic architecture of intrusion detection systems. It is composed of: a sensor, an analyzer, a response module, and a repository [19]. Once the sensor have collected recorded events from applications, systems and networks being monitored, it sends events to the analyzer and to the repository. The analyzer is then responsible of qualifying these events (malicious or not malicious). Consequently, it sends information about detected attacks to the Response Module which is in charge of reporting this received information mainly alerts to the human operators. An IDS can be either centralized or distributed. The former supposes that all monitoring, detection and reporting is controlled directly from a central location. The latter consists in using an agent-based approach for monitoring and detection, so the response decisions are made at the point of analysis. Henceforth, the main goals of these systems are to identify, preferably in real time, unauthorized use, misuse, and abuse of computer systems by both internal and external accesses. These automated systems are used in blending with the traditional mechanisms of security to yield better security for computer systems. In fact, it can be placed into the control points of the network, for example close to the router, or outside and/or inside the firewall.

IDS Taxonomy

Along years, researchers has been continuously developing new detection techniques and methods. There is a number of existing literature that survey IDS or propose taxonomies [START_REF] Denning | An Intrusion-Detection Model[END_REF][20][START_REF] Mukherjee | Network intrusion detection[END_REF][START_REF] Debar | Towards a taxonomy of intrusiondetection systems[END_REF][START_REF] Krügel | A survey on intrusion detection systems[END_REF][START_REF] Debar | A revised taxonomy for intrusion detection systems[END_REF][START_REF] Mukkamala | A comparative study of techniques for intrusion detection[END_REF][START_REF] Estevez-Tapiador | Anomaly detection methods in wired networks: a survey and taxonomy[END_REF][START_REF] Mishra | Intrusion detection in wireless ad hoc networks[END_REF][START_REF] Delgado | A taxonomy and catalog of runtime software-fault monitoring tools[END_REF][START_REF] Kabiri | Research on intrusion detection and response: A survey[END_REF][START_REF] Patcha | An overview of anomaly detection techniques: Existing solutions and latest technological trends[END_REF][START_REF] Garcia-Teodoro | Anomaly-based network intrusion detection: Techniques, systems and challenges[END_REF][START_REF] Xie | Anomaly detection in wireless sensor networks: A survey[END_REF]. In [START_REF] Debar | A revised taxonomy for intrusion detection systems[END_REF], authors reviews the existing IDS techniques. Figure 2.3 shows the proposed IDS taxonomy as it is proposed in [START_REF] Debar | A revised taxonomy for intrusion detection systems[END_REF]. The classification of intrusion detection system may be conditioned by the mechanisms of detection used (detection method), the behavior on detection, the nature of the analyzed information (audit source location), and the different operational modes where it is ran (usage frequency):

• Behaviour on detection: According to the kind of the intrusion, the IDS performs the appropriate detection methods. For more details about these types, the interested reader would refer to [START_REF] Denning | An Intrusion-Detection Model[END_REF] and [START_REF] Debar | A revised taxonomy for intrusion detection systems[END_REF]. In [START_REF] Debar | A revised taxonomy for intrusion detection systems[END_REF], authors specifies two types of IDSs. The first type is the passive IDSs which only generate alerts when detecting unexpected behavior. These systems do not contribute on attack mitigation since they do not interleave with these activities. The second type is the active IDSs which make possible countering ongoing attacks. Active IDSs are capable to act on the detected threat. • Audit source location: it refers to where an IDS look for intrusive behavior.

Three categories are discerned: host based, network based, and application based.

• Application-based IDS refers specific applications, using application's transaction logs as main sources of data. It monitors the interaction between user and application, which is not afforded by the other two categories of IDS. Moreover, this system allows the targeting of finer grained activities on the system. • Host based IDS monitors and process activities related to a software environment associated with a specific host. It looks also at the communications traffic in and out of a single computer. • Network-based IDS monitors the entire network environment. It uses audit trails of multiple hosts and network traffic as main sources of data to identify the intrusion signatures. It performs local analysis of the traffic, via the use of a set of single-purpose sensors placed at various points of the network, then reports attacks to a central management console. • Detection method: there are two well known approaches of intrusion detection: misuse detection and anomaly detection. In [START_REF] Ghorbani | Network Intrusion Detection and Prevention, ser. Advances in Informatio Security[END_REF], Chapter 2, authors review the existing detection approaches. Hereafter, we detail the most commonly used detection approaches:

• Misuse detection: is based on signatures of known attacks. It analyzes system activity and audit data stream, looking for events or sets of events that match predefined pattern of events. It relies on a database of attack signature knowledge. Therefore, IDSs using misuse detection are not capable to detect zero-day attacks for which the signatures are not yet published. Moreover, they do not take into account environmental characteristics of the supervised network. • Anomaly detection: is based on normal activity profile of a system (e.g., CPU usage, job execution time, system calls, etc). Any action that significantly deviates from the normal behavior is considered intrusive. Depending on the type of the analysis approach, various processing techniques are employed for analyzing data to perform the detection of harmful events as described in [START_REF] Kazienko | Intrusion Detection Systems (IDS) -Part 2: Classification, methods, techniques[END_REF]. Several anomaly detection approaches has been proposed in the literature such as [START_REF] Debar | A revised taxonomy for intrusion detection systems[END_REF][START_REF] Sundaram | An introduction to intrusion detection[END_REF][START_REF] Mchugh | Intrusion and intrusion detection[END_REF][START_REF] Jones | Computer system intrusion detection: A survey[END_REF]. In contrast to the misuse detection IDS, anomaly detection IDS are capable to detect zero-day attack. But, they require a definition of the legitimate system behavior. This latter CHAPT 2. COMPUTER SECURITY, IDS AND IRS: A STATE OF THE ART changes over time and makes the anomaly detection IDS obsolete.

IDS Issues

Although IDS provides us with several advantages to enforce existing security mechanisms, researchers in the field on intrusion detection has been continuously working on alleviating limitations of IDSs [START_REF] Mell | An Overview of Issues in Testing Intrusion Detection Systems[END_REF]. In fact, IDSs presents distinct drawbacks related to their detection techniques, attack knowledge, alerts reporting format, etc. One of the most critical IDSs limitations are the alert representation format, false positive rate, huge number of generated raw alerts, etc. Moreover, IDSs usually require frequent updates of their attack knowledge and detection techniques aiming at detecting new attacks and thus decreasing false negative. Thus, the deployment of an IDS, its configuration and its maintenance represents a costly and time consuming task. Hereafter, we detail the aforementioned drawbacks:

Alerts Representation

In [START_REF] Erlinger | Experiences implementing a common format for ids alerts[END_REF][START_REF] Kim | Intrusion alert normalization method using AWK scripts and attack name database[END_REF][START_REF] Bosch | Intrusion detection parameterization exchange data model[END_REF][START_REF] Park | Supporting interoperability to heterogeneous ids in secure networking framework[END_REF], authors highlight one of the major drawbacks of developed IDSs which is their reporting format. Both commercial (e.g. Corero

False Positives

Every IDS, independent of its detection technique, generates false positive and false negative alerts. False negative corresponds to non detected attacks and then to

Intrusion Detection System (IDS)

non generated alerts. However, false positive corresponds to non malicious behavior reported as malicious. Unless false negative is much more critical for a vendor of IDSs, false positive are more serious from a user's point of view, [START_REF] Ho | Statistical analysis of false positives and false negatives from real traffic with intrusion detection/prevention systems[END_REF]. In fact, an important number of false positive can hide real attacks and then makes the response decision faulty. For instance, due to false positive, a legitimate user can be blocked and then the service will no longer be available for him.

In [START_REF] Ho | Statistical analysis of false positives and false negatives from real traffic with intrusion detection/prevention systems[END_REF][START_REF] Abouabdalla | False positive reduction in intrusion detection system: A survey[END_REF][START_REF] Remi-Omosowon | Statistical analysis of snort alerts[END_REF][START_REF] Spathoulas | Reducing false positives in intrusion detection systems[END_REF][START_REF] Bakar | False positives reduction via intrusion alert quality framework[END_REF], authors examine the causes of false positive and how can be reduced.

In [START_REF] Ho | Statistical analysis of false positives and false negatives from real traffic with intrusion detection/prevention systems[END_REF][START_REF] Remi-Omosowon | Statistical analysis of snort alerts[END_REF], authors presents a study on statistical analysis of false positive and false negative from real traffic with IDSs. They propose techniques to identify false positive. They demonstrated that around 90% of false positive are using HTTP and are due to IDS's policy and not security issue. In [START_REF] Spathoulas | Reducing false positives in intrusion detection systems[END_REF], the notion of Usual False Positive was proposed in order to reduce false positive in an IDS. In the literature, several false positive reduction approaches has been developed such as [START_REF] Bakar | False positives reduction via intrusion alert quality framework[END_REF]. The existing approaches are based on data mining and artificial intelligence techniques, fuzzy logic, machine learning, etc. In our work, false positive reduction will not be addressed. As a consequence, our work will come on the top of these false positive techniques.

Duplicated Alerts

Duplicated alerts are an IDS issue similar to the false positive in the sense that they overwhelm the security operator when analyzing alerts. Multiplied alerts are due to the limited visibility of the IDS throughout the environment and its contextual parameters. For instance, IDSs do not generally aggregate same alerts related to a same attack. In [START_REF] Debar | Aggregation and correlation of intrusion-detection alerts[END_REF], authors explain the multiplied alerts by the fact that IDS do not take into account the context of the attack. They point out that an attack can cause multiplied alerts over a period of time and they propose a method which is able to eliminate duplicate alerts. In [START_REF] Hofmann | Online intrusion alert aggregation with generative data stream modeling[END_REF], authors proposes an alert aggregation technique based on a dynamic and probabilistic model of the current attack. A meta-alert model was proposed. They proved how their developed approach is able to achieve a reduction rate of up to 99,6%.

Information about Attacks

Another IDS issue which has been pointed in [START_REF] Debar | Aggregation and correlation of intrusion-detection alerts[END_REF] is the semantic of information provided by IDS in generated alerts. Usually, IDS alerts includes low level of information. These events often lack precise and concise information [START_REF] Ren | An online adaptive approach to alert correlation[END_REF]. This fact prevent the security operator from obtaining a consistent view of the ongoing attacks. In order to tackle such issue, alert enrichment techniques has been proposed. In [START_REF] Bakar | Towards implementing intrusion alert quality framework[END_REF], authors exposes the issues of alert's data quality in processing generated alerts. They propose an Intrusion Alert Quality Framework (IAQF) which is responsible of enriching alerts with quality criteria such as correctness, accuracy, reli-ability, etc. Unless this work attempts to enrich alerts, it was not able to complete knowledge about detected attack. Such knowledge can be gathered from honeypots. Honeypots techniques are detailed hereafter in section 2.4. Moreover, in order to tackle this issue in particular and IDS issues in general, Security Information and Event Management (SIEM) systems has been developed. It constitutes the central platform of modern security operating centres. They gather events from various sensors (intrusion detection systems, anti-virus, firewalls, etc.), correlate these events, and deliver synthetic views for threat handling and security reporting.

Honeypot

Honeypot Definition

Discovering and analysing attacker behavior allows better protecting the supervised network and choosing appropriate response decisions. Therefore, honeypots are valuable solution that has been designed to gather and analyze information about attackers.

In [START_REF] Sptizner | Honeypots: Tracking Hackers[END_REF], the author gives a classical definition of honeypots which affirm that a honeypot is an information system resource whose value lies in unauthorized or illicit use of that resource. In [START_REF] Dagon | HoneyStat: Local Worm Detection Using Honeypots[END_REF] and [START_REF] Pouget | Honeypot-based Forensics[END_REF], a honeypot consists in an environment where vulnerabilities have been deliberately introduced in order to observe attacks and intrusions and to facilitate in-depth analysis of attackers strategies. It provides its operators with intelligence about threats and network exploits. In recent years, honeypots are proved to be a relevant mean for collecting and analyzing information about attackers behavior. In [START_REF] Krasser | The Use of Honeynets to Increase Computer Network Security and User Awareness[END_REF], authors demonstrate how honeypots enable the security administrator to understand the attackers, their techniques, tactics, intentions, and motivations. Honeypots are non-production systems. In fact, they do not belong to any user in the network and do not impact publicly available services. Honeypots sensors interact with attackers in different ways, classified according to three types of interaction level as listed in [START_REF] Sptizner | Honeypots: Tracking Hackers[END_REF][START_REF] Mokube | Honeypots: Concepts, Approaches, and Challenges[END_REF].

Low-interaction Honeypot

It emulates the presence of different network services on a host rather than a complete system. In general, low-interaction honeypots are based on simple system processes and services. It allows monitoring attack attempts. Unless low-interaction honeypot are useful to detect new attack attempts, they are not capable to emulate more complex environment. HoneyD is an example of low-interaction honeypot [START_REF] Seifert | HoneyC -The low-interaction client honeypot[END_REF].

Honeypot

Medium-interaction Honeypot

It is a more sophisticated honeypot than low-interaction one but it is still not emulating a complete operating system like high-interaction honeypots. It emulated a collection of services and more complex operations. Thus, the attacker has more attack entry points. Nepenthens, [START_REF] Baecher | The Nepenthes Platform: An Efficient Approach to Collect Malware[END_REF] is an example of medium-interaction honeypots that deploys honeypot modules. It offers a large-scale malware collection. A recent evolution of medium-interaction honeypot research field is proposed in [START_REF] Leita | SGNET: a worldwide deployable framework to support the analysis of malware threat models[END_REF] and integrates different tools such as ScriptGen [START_REF] Leita | Automatic handling of protocol dependencies and reaction to 0-day attacks with ScriptGen based honeypots[END_REF], Argos [START_REF] Portokalidis | Argos: an emulator for fingerprinting zero-day attacks[END_REF] and Nepenthes [START_REF] Baecher | The Nepenthes Platform: An Efficient Approach to Collect Malware[END_REF].

In [START_REF] Leita | SGNET: a worldwide deployable framework to support the analysis of malware threat models[END_REF], authors propose a distributed system of honeypots in order to gather more details about attacker's activity against several victim machines and networks.

High-interaction Honeypot

Unlike low-interaction honeypot and medium-interaction honeypot, a high-interaction honeypot emulates a complete real system. It usually runs a full implementation of an Operating System and installed applications. It is able to ensure a real environment with which the attacker will interact. This technique gathers more details about the modus-operandi of attackers by allowing a high interactivity level with the attacker. It allows discovering the attacker behavior in order to gain root access in a machine. Capture C [62] is an example of high-interaction honeypot. Argos [START_REF] Portokalidis | Argos: an emulator for fingerprinting zero-day attacks[END_REF] and Minos [START_REF] Crandall | A Security Assessment of the Minos Architecture[END_REF] and are also other examples of high-level interaction honeypots.

Discussion

Honeypots are still being an active research topic because of their deployment differences and techniques. In Table 2.1, we summarize the pros and cons of these honeypot technologies (in the second and the third column on the table) and we give examples of each category (in the fourth column) and more details about the information collected by them (in the last column).

A common drawback of honeypots is that their field of view is limited and they only gather attacker's activity which interacts with them.

In [START_REF] Leita | Exploiting diverse observation perspectives to get insights on the malware landscape[END_REF], authors demonstrate how honeypot databases offer significant data to study malware propagation and to get a deeper understanding of their evolution. In this dissertation, we explore such information about the attacker behavior collected by selected honeypots. [69];

Classification : This class provides the name of the alert which usually depends on the deployed IDS product. It includes a reference associated to the alert.

The reference is an information which points to an external documentation detailing the alert.

Assessment : This class informs the security administrator about the analyzer's assessment of the event. For instance, it provides the impact of the detected attack, its confidence level, actions that should be taken in order to respond to the attack, etc.

IDMEF-Message

Alert Correlation

Alert Correlation Definition

In practice, IDSs are deployed in a distributed manner. Each single IDS has a limited scope in terms of capabilities and coverage. In fact, an intrusion detection sensor is not able to observe total information about an ongoing attack. This results in two issues:

• high number of generated alerts because of the multiple deployed IDSs. In addition, IDSs generate multiple alerts associated to the same root-cause. This issue prevents the administrator to prioritize the most critical alerts. • generated alerts include partial information about the ongoing attacks. This issue makes more challenging the enforcement policy decision in order to fill security policy objectives.

Alert correlation has been designed in order alleviate these IDSs issues. To satisfy this aim, it usually verifies the relationships that may exist between alerts following a correlation criteria. Alert correlation approaches have also been developed to improve the accuracy of alerts and attack understanding [START_REF] Chifflier | Intrusion detection systems correlation: a weapon of mass investigation[END_REF].

In the literature, we may find different correlation techniques. Hereafter, in paragraph 2.6.2, we categorize these techniques following our proposed taxonomy.

Alert Correlation Taxonomy

In [START_REF] Mustapha | Limitations of honeypot/honeynet databases to enhance alert correlation[END_REF] [START_REF] Templeton | A requires/provides model for computer attacks[END_REF] to model the conditions of an attack to occur and its steps. These latter are constructed once the attack conditions are satisfied. Hence, if some alerts are missed, the attack steps reconstruction remains incomplete. This limitation was addressed by the MIRADOR correlation method which does not require full satisfaction of all attack conditions, [START_REF] Cuppens | Managing alerts in a multi-intrusion detection environment[END_REF].

Discussion Rule-based alert correlation approaches explore the causality links between generated alerts. Therefore, the security administrator can adjust the response decision based on detected causality links. He also has the possibility to process rule-based correlated alerts more efficiently. In fact, it is possible to react to these correlated alerts based on the discovered intrusion objective. However, such correlation approaches do not refer to extra knowledge about defense capabilities deployed in the supervised system.

Scenario-based Alert Correlation

A single alert reflects often to an elementary step of an attack scenario. Consequently, various attack scenario templates are required to correlate those alerts. Modelling language such as LAMBDA (Language to Model a Database for Detection of Attacks), [START_REF] Cuppens | LAMBDA: A Language to Model a Database for Detection of Attacks[END_REF] and AdeLe (Attack Description Language) have been used for attack scenarios specification. In [START_REF] Cuppens | LAMBDA: A Language to Model a Database for Detection of Attacks[END_REF],

authors define a formal attack description language called LAMBDA. Respecting LAMBDA language, an attack is characterized by its pre-conditions (pre) and postconditions (post). Pre-conditions are the conditions satisfied by the computer system and which make the attack feasible. Post-conditions are the consequences of the successful execution of the attack. Using LAMBDA formalism, it is possible to discover ongoing attack scenarios. In fact, an attack scenario is a succession of elementary attacks which aim to achieve an intrusion objective. Two elementary attacks att 1 and att 2 belong to the same scenario if post(att 1 ) = pre(att 2 ). post(att 1 ) and pre(att 2 ) are respectively the post-conditions and pre-conditions of att 1 and att 2 . Similar to [START_REF] Cuppens | LAMBDA: A Language to Model a Database for Detection of Attacks[END_REF], in [START_REF] Kabiri | A Rule-Based Temporal Alert Correlation System[END_REF], authors propose to correlate alerts based on deduction rules. Furthermore, attack scenarios recognition techniques were developed like statistical Granger Causality Test, chronicles formalism and other machine learning techniques to enlarge the set of scenarios.

Discussion Within scenario-based alert correlation, alerts are correlated based on predefined scenarios. Thus, such correlation approaches are based on a priori knowledge about the attacker's behavior. Using techniques such as honeypots is a key fact in order to enhance these correlation techniques. In fact, as we explained in Section 2.4, attacker's behavior can be gathered through honeypots. Moreover, scenarios are predefined independent from the supervised system. Thus, such approach may not support the administrator in defining adequate intrusion response decision.

These aforementioned alert correlation techniques are essentially based on the information contained in the alert itself and on static databases including information about vulnerabilities such as the Common Vulnerabilities and Exposure CVE database, National Vulnerability Database, Open Source Vulnerability Database, etc.

Model-based Alert Correlation

This approach aims at supporting alert correlation at analysing security alerts with a view on the relevant context. M2D2, [START_REF] Morin | M2D2: A formal data model for ids alert correlation[END_REF], was the first attempt to offer a formal representation of sensor capabilities in order to decide whether an alert was false positive or not. This was enhanced by the proposed data model M4D4 [START_REF] Morin | Correlation of intrusion symptoms: An application of chronicles[END_REF][START_REF] Morin | M4D4: a Logical Framework to Support Alert Correlation in Intrusion Detection[END_REF], which covers contextual and topology information. This model is a shared model that is developed in order to process in a cooperative way while correlating alerts. It represents the different relationships among system entities and components to facilitate the correlation process by a cooperative analysis of heterogeneous information.

Discussion Model-based alert correlation are the first correlation techniques that explore additional information about the supervised network. Otherwise, neither information about the attacker's behavior nor the defenser's capability are taken into account when correlation alerts.

Discussion

In Table 2 Scenario-based alert correlation -alerts are correlated based on their pre-defined causality link -complex maintaining of defined scenarios -need for a prior knowledge on attack description LAMBDA [START_REF] Cuppens | LAMBDA: A Language to Model a Database for Detection of Attacks[END_REF] Model-based alert correlation -consideration of context information and external knowledge -complex to implement and maintain M2D2 and M4D4 [START_REF] Morin | M2D2: A formal data model for ids alert correlation[END_REF][START_REF] Morin | Correlation of intrusion symptoms: An application of chronicles[END_REF][START_REF] Morin | M4D4: a Logical Framework to Support Alert Correlation in Intrusion Detection[END_REF] In our work, we propose complementary approaches that tackle two main drawbacks of alert correlation techniques. The first drawback is the lack of information 2.7. Intrusion Response Systems (IRS) about the attacker behavior and the detected attack. The second drawback is the role of alert correlation in policy enforcement. To the best of our knowledge, no previous study has proposed solutions to alleviate these issues.

Intrusion Response Systems (IRS)

Intrusion response system represents the decision tool of an IDS, that takes actions to mitigate attacks and ensures safety in computing systems. It includes a set of countermeasures that aims to protect computer resources. Generally, when speaking about intrusion response, intrusion detection is automatically considered as it gives the main inputs for the response engine (attack type, time, etc.). Intrusion response decisions are actions, devices, procedures, or techniques that meet or oppose (i.e., counters) a threat, a vulnerability, or an attack by eliminating or preventing it, by minimizing the harm it can cause, or by discovering and reporting it so that corrective action can be taken [4]. The focus on the literature shows that several IRSs are developed recently. These systems are found to be lacking in one or more dimensions that make them unsuitable for protecting dynamic and complex distributed systems. Some of the commonly observed shortcomings are:

• the system may have a static mapping of symptoms from the detector to the response; • it may not take feedback into account for determining future responses; • it may assume perfect detectors with no missed and no false alarm; • or it may assume perfect success rate for a deployed response.

As we can point out, intrusion response decision is a challenging step to ensure the security of the supervised system. It comes on top of intrusion detection and alert correlation. Therefore, it is important to design appropriate correlation techniques that can improve the effectiveness of IRS.

Conclusion

Detection techniques have been extensively studied in the literature. Honeypot techniques are complimentary tool to intrusion detection. They have been developed in order to learn about the attacker's behavior. In our research, we assume that intrusion detection techniques are mature enough to satisfy the need of the security administrator in detecting attacks. We also assume that these IDSs generate ID-MEF alerts. Honeypot techniques are still an active research topic. Meanwhile, we assume that they are capable to provide us with appropriate knowledge about attackers' behavior. In this dissertation, we explore the knowledge gathered by honeypots.

Furthermore, we present a definition and a classification of alert correlation methods. We discuss the advantages and drawbacks of correlation techniques. These techniques should be improved by the consideration of attacker behavior knowledge and the policy enforcement capabilities of the supervised network. The next chapter will be focused on the application of honeypot datasets in alert correlation and how they can enhance the information about generated alerts.

E

xisting correlation techniques such as [START_REF] Ren | An online adaptive approach to alert correlation[END_REF][START_REF] Chifflier | Intrusion detection systems correlation: a weapon of mass investigation[END_REF][START_REF] Valdes | Probabilistic Alert Correlation[END_REF][START_REF] Templeton | A requires/provides model for computer attacks[END_REF][START_REF] Cuppens | Managing alerts in a multi-intrusion detection environment[END_REF][START_REF] Morin | M2D2: A formal data model for ids alert correlation[END_REF][START_REF] Morin | Correlation of intrusion symptoms: An application of chronicles[END_REF][START_REF] Morin | M4D4: a Logical Framework to Support Alert Correlation in Intrusion Detection[END_REF][START_REF] Cheung | Modeling multistep cyber attacks for scenario recognition[END_REF] are based on local alert datasets which include locally deployed IDS generated alerts.

The view over the local alert datasets is limited by functional and structural boundaries of the monitored system. In this context, alert correlation does not provide methods to determine if the alerts, locally detected, are part of more global threat phenomena. Thus, honeypot technology is a valuable instrumentation technique to automatically collect and learn information about server-based exploits and global threat phenomena. In this chapter, we describe a novel honeypot-based correlation approach capable of analyzing causality relationships between local alerts detected in the monitored system level and the global threat phenomena observed by honeypot sensor deployment. This approach is beneficial to reassess the attack severity and to re-evaluate the attack impact. In fact, analyzing information about the global threat phenomena attributed to the locally detected alerts apprise us of severity of the global threat phenomena, its propagation strategy, its capabilities, etc. Our approach takes advantage of the data collected by four honeypot databases to enrich our knowledge about alerts.

Framework Description

Recent works [START_REF] Leita | Exploiting diverse observation perspectives to get insights on the malware landscape[END_REF][START_REF] Comparetti | Using WOMBAT APIs on Real-World Tasks[END_REF][START_REF] Li | The research and design of honeypot system applied in the lan security[END_REF] have shown the usefulness of gathering experimental data to model and better understand the threats due to attackers. The deployment of honeypots in several locations of the IP space has underlined the fact that different blocks of addresses are attacked differently. Such in-depth information about global attack phenomena makes possible identification of the causality links with local detected attacks. Our honeypot-based alert correlation approach exploits the information provided by honeypot datasets in order to enhance correlation of local alerts. The most important step is the enrichment of local alerts by the information in honeypot datasets.

Framework workflow

In Figure 3.1, we describe the workflow of our honeypot-based alert correlation approach. The honeypot-based alert correlation process is composed of three main steps:

• Alert enrichment process: The objective of this step is to enrich the content of locally generated alerts by information about the attacker. The output of this step is an enriched alert denoted by Er_alert. This step will be detailed in Section 3.4; • Analyze Er_Alert: At this stage, the content of Er_alert is analyzed in order to reassess attack severity, re-evaluate attack impact and intrusion objective;

Information Sources

• Correlate Er_Alert: This step aims at correlating enriched alerts using existing alert correlation techniques. It is also possible to combine different correlation techniques as explained in Section 2.6.3. This step results in correlated alerts.

Begin Honeypot-based alert correlation

Local alert datasets

Honeypot datasets

Alert enrichment process

Analyze Er_Alert

Reassess attack severity

Re-evaluate attack impact

Re-evaluate intrusion objective

External information (CVE, Attack Type, Criticity, etc)

Correlated Alerts

Correlate Er_Alert

Enriched alert datasets {Er_Alert} Correlation features

Information Sources

The proposed honeypot-based correlation operates on heterogeneous security-related information gathered from two different views: local view and global view. Information in the local view comes from analyzers such as Intrusion Detection Systems (IDS), Firewalls, etc. They are deployed to report traces of malicious activity affecting the local network. For instance, IDSs monitor the activity of the network for the occurrence of malicious activities and generate alerts triggered by their signatures. From the alerts, we can retrieve the timestamp of the malicious activity, the source and target IP address, used port, etc. We call these attributes selectors.

Information in the global view comes from honeypot data. As we described in paragraph 2.4.1, the primary goal of a honeypot is the study of the attacker behavior while interacting with the sensor. The data collected through honeypot sensor

Local alert datasets

Honeypot datasets

Alert enrichment process

Categorization

Enriched alert datasets {Er_Alert}

Enrichment features includes information about malware behavior, propagation vectors used by malware, the propagation strategy, relationships between exploits, attacker's location, source and destination characterization, origin and relevance of zero-day attacks, etc [START_REF] Mokube | Honeypots: Concepts, Approaches, and Challenges[END_REF][START_REF] Leita | SGNET: a worldwide deployable framework to support the analysis of malware threat models[END_REF].

Collected additional information

Categorized information

Filtering

Alert Enrichment Process

In the context of honeypot-based alert correlation, we enrich our local knowledge about alerts with information about the global threat landscape. Hence, it is essential to define an alert enrichment strategy that improves the alert-related knowledge, especially with appropriate external information related to the occurrence of the exploit. Figure 3.2 describes an overview of the alert enrichment process. As shown in figure 3.2, we first collect information respecting appropriate enrichment features that are detailed hereafter. For instance, based on the originating source of the observed alert, we collect global knowledge about the tracked server and evaluate its security profile and evolution over time. After the enrichment is performed, we categorize the collected information following the defined categories presented later and we propose a filtering process which is composed of three types of filters: Tem-

Alert Enrichment Process

poral, Semantic and configuration filters. Each filter performs on a corresponding category of information.

The result of the enrichment process is an Er_alert which appends the elementary alert's information with additional information about the security state of the source, detected attack, in-depth information about corresponding exploits. We then analyze the relationship that may exist between the threat which has been reported on the specific server and the locally reported alerts.

The Er_alert is then processed to request for more general information based on a generalization strategy of the enrichment feature. In fact, honeypots have limited view on the threat landscape. The more honeypots are distributed, the more information about threats phenomena is gathered. Therefore, it is possible to request generalized information in order to gather more knowledge about the attacker's behavior. For instance, to analyze the environment of the originating source of the local threat, it is possible to request information about its localization; the classes of its IP address (class A, B or C).

Enrichment selectors

It is essential to analyze local alert selectors that must be considered in the enrichment process since we manipulate information from two different views: the local view and the global view.

At the local victim-side, Intrusion Detection Systems (IDS)s monitor the activity of the network for the occurrence of malicious activities and generate alerts of detected malicious activity including elementary information about the infection. Following the Intrusion Detection Message Exchange Format (IDMEF) [69], the alert is composed of several aggregate classes. The following aggregation classes can act as selectors for querying honeypot datasets:

Source: class includes the IP address of the originating source of the detected threat. As mentioned in paragraph 2.4.1, honeypot databases log information related to the source IP address of malicious activity.

DetectTime: represents the time when the attack was detected by the local analyzer. In honeypot databases, captured activities are usually timestamped and allow us to analyze the security evolution of the alert's originating source within a specific time window.

Classification: represents the alert semantic. For instance, Intrusion Detection Systems categorize alerts respecting a set of alert classification which inform us about the alert's type. This may be linked to the threat type detected by honeypot sensors.

Filtering Process

We propose to categorize the collected information aiming at simplifying the filtering processes. We define three major categories:

-Security Information: This category includes security-related information such as md5, type of the threat, security states of the originating sources, exploited vulnerabilities by the attacker, etc.

-Temporal Information : when detecting a malicious activity, honeypots' logged information is timestamped. Honeypot datasets' objects include temporal attributes about the detection and analysis time.

-Contextual Information : this category includes generic type of information: spatial information, whois information, generic information. This set of attributes allows us to build a more general picture about the environment of the object being analyzed.

The objective of the enrichment process is to increase the accuracy of the knowledge related to the alert. To fulfill this need, we set up 3 filters (as shown in figure 3.3). The objective of these filters is to eliminate data which is less likely to link the local alert to the corresponding global threat phenomena.

Temporal Filtering: Honeypot sensors track the activity of attackers and the evolution of the threat landscape referring to a time settings. Honeypot datasets include a timeline of events for each tracked source. This timeline is composed of different time spans defined by the first and last time (resp. t f irst_seen and t last_seen ) of the observed activity generated from tracked source. t f irst_seen and t last_seen are timestamps expressed by seconds. We denote by T_th IP addr = [t f irst_seen , t last_seen ] the time span of an observed threat on a specific source. Within the defined honeypot-based alert correlation approach, it is important to operate on time spans that are close to the DetectTime of the local alert. Obviously, it is not significant to attribute local alerts to a global threat which no longer exists. Therefore, we use sliding windows to avoid investigating the correlation of local alerts with old reported global threats. We denote by α = DetectTime -t last_seen the delay that exist between the last time of the last activity observed on a source and the detection time of the local alert. We expect α to be of the order of a day.

Semantic Filtering: As local alerts are usually generated by IDS systems referring to attacks' signature, global threat is also assigned to specific types of attack phenomena. By setting up a semantic filtering, we eliminate non-relevant global threat relatively to the classification of the local alert. The objective of semantic filter is to keep only threats that are highly likely causing the local alert.

The observed global threat is classified respecting a high level description of the threat defined by a threat_class. This classification is extremely helpful to characterize threats and the modus operandi of attackers behind them. Honeypot datasets use their own set of threat classes to characterize detected global threats. Therefore, the semantic filtering is able to compare the threat class against the alert type with the condition that the threat classes used by honeypots are based on the same dictionary of local alerts classification. The semantic filtering takes into account intermediate cross-references in order to map these different sets of threat classes and alert types.

Configuration Filtering: Cross-view correlation also takes into account the contextual knowledge of the monitored network. This knowledge is composed of topological and cartographic data. It represents hosts' characteristics, their interconnections, software products, their vulnerabilities, etc. As mentioned in [START_REF] Morin | M4D4: a Logical Framework to Support Alert Correlation in Intrusion Detection[END_REF], comparing the affected configuration of vulnerability with the actual set of products of a given host is valuable for alert correlation.

Experimentations and Evaluations

Alert enrichment is the most important step in our honeypot-based alert correlation.

It is responsible of enriching our knowledge about locally generated alerts with appropriate information gathered through honeypots. In this section, we detail the alert enrichment experimentation results. We then discuss these results and their impact on our honeypot-based alert correlation.

Local Information Source

Our analysis is conducted on real world alerts generated by a snort v2.8 NIDS sensor running on our University Network for 4 months. The University Network is composed of hundreds of machines. For the experiment, we use the latest version of the signature rule-sets available at the time of the experiment procedure which began on January 2012. During these 4 months, snort generated 183170 alerts originating by 2499 unique IP address source. We summarize these alerts in Table 3.1, sorted by their classification (detailed in the first column of the table). In the second column of the table, we give the number of generated alerts during these four month for each classification.

In the third column, we identify the number of unique IP source addresses in generated alerts. The two last columns show the number of filtered alerts and their corresponding unique IP source addresses. The alert enrichment experimentation is based on these filtered alerts. Several alerts have been filtered. In fact, in order to increase the performance of the enrichment process, we eliminate several alerts since snort IDS is known by its high rate of false positive as explained in Chapter 2. Hereafter, we consider classifications for which alerts have been filtered:

• Attempted reconnaissance alerts are usually preliminary intrusion steps aiming at collecting information about the network. Most of these alerts are, in general [START_REF] Remi-Omosowon | Statistical analysis of snort alerts[END_REF], alerts for normal network activity. In fact, such alerts are more significant if they are part of a global attack sequence. Therefore, we filter alerts whose IP source address is not present in other alerts having different signature. More than 99% of attempt-recon alerts have been filtered (ref. Table 3.1). • Misc-activity and Bad-unknown alerts include large number of ICMP alerts which can be considered as a Usual False Positive referring to [START_REF] Spathoulas | Reducing false positives in intrusion detection systems[END_REF]. These alerts are usually generated due to misconfigured hosts, topology of the network,

Experimentations and Evaluations

normal activity of network services, etc. As shown in Table 3.1, more than 99% of misc-activity and bad-unknown alerts have been filtered.

In the last line of the Table 3.1, we compute the number of alerts generated by our Snort sensor and the number of corresponding unique IP source address. We then aggregate the total number of filtered alerts, with its average referring to the totality of alerts. Finally, we give the number of corresponding filtered IP source address that will be considered during our experiments. Table 3.2 shows more detailed information about the exploited vulnerabilities, protocol and ports reported in the generated alerts. In the second column of Table 3.2, the signature used by the IDS while generating alerts. In the third column, we specify the corresponding vulnerabilities that are identified by their CVE reference1 . The fourth column specifies the protocol and port used by the detected exploits.

In the last column of the table, the number of generated alerts for each signature is given.

Experimental Honeypot Datasets

The experimentation uses four honeypot databases provided by Symantec in the context of the Vis-Sense Project. These datasets include information about malware characterization and security profile of suspicious web-based servers.

HARMUR datasets

HARMUR v1, the Historical ARchive of Malicious URLs, [START_REF] Leita | HARMUR: Storing and analyzing historic data on malicious domains[END_REF], is a security dataset that aims at exploring the dynamics of the security and contextual information associated to web-related threats. HARMUR extract several security information tracked web-based servers where hosted suspicious domains. It is possible to retrieve threats that were reported on the tracked server. Like SGNET, HARMUR's developers improve several functionalities of HARMUR and they developed the HARMUR v2.

SGNET datasets

SGNET v1, [START_REF] Leita | SGNET: a worldwide deployable framework to support the analysis of malware threat models[END_REF], is a distributed honeypot deployment which benefits from different tools, namely ScriptGen [START_REF] Leita | Automatic handling of protocol dependencies and reaction to 0-day attacks with ScriptGen based honeypots[END_REF], Argos [START_REF] Portokalidis | Argos: an emulator for fingerprinting zero-day attacks[END_REF] and Nepenthes [START_REF] Baecher | The Nepenthes Platform: An Efficient Approach to Collect Malware[END_REF]. It collects information about the malware propagation strategies as well as information providing as better understanding about global threat landscape. Recently, an enhanced version of SGNET has been developed and called SGNET v2. These honeypot databases have been developed initially within the WOMBAT project. A public API called WAPI (Wombat API) [START_REF] Zanero | The WOMBAT API: querying a global network of advanced honeypots[END_REF], has been developed in order to query information from advanced honeypot databases. Information col-

Experimentations and Evaluations

lected in these datasets is object oriented. The specification of the WAPI protocol relies on four different concepts: objects, attributes, methods and references. Aggregation of these concepts offer information on a security object (e.g. an IP address) that is generated by a set of different datasets (SGNET honeypots, HARMUR web servers, ...).

Experimental Results

In our experiments, the enrichment process operates alert attributes such as source address or port. For instance, based on the IP address of the alert's source, the alert enrichment process allows us to gather more details about potential root causes. Additional features would be considered within the enrichment process such as the hash of potentially detected malwares. During our experiments, we check if the originating source reported in our set of alerts has been analyzed by one of the honeypot sensors. We analyze the security evolution of alert's source and evaluate and quantify the threat phenomenon which infects the originating source of the local detected alert. 3.3 summarizes the results obtained during the alert enrichment process. In this table, we represent the number of alerts' IP source address having corresponding server object analyzed by one of the honeypot sensor. The primary step of the enrichment process is concentrated on the identification of the set of alerts that are systematically enriched. Based on the result shown in Table 3.3, we conclude that a high number of alerts' IP source address have not been analyzed by honeypot sensors. Thus, we conclude that many alerts will not be automatically enriched. Moreover, the examples in the experiment honeypot datasets which are linked to the alerts are difficult to explore in the context of our honeypot-based alert correlation. In Table 3.4, we detail the information gathered from each IP source address object found in the honeypot datasets.

Enrichment : As shown in Table 3.3, the enrichment process operates on a small set of originating sources. 5 IP source addresses out of 255 IP source addresses have been identified in the experiment honeypot datasets. Due to this reduced number of identified IP source addresses, the performance of the enrichment process is highly reduced. Knowledge about the originating source of the local alerts is not entirely enriched.

Categorization : Experiment honeypot datasets set temporal attributes for each object that are composed of last_seen, first_seen. Moreover, security information includes information about the threat reported in each source, their types, their rating, a link to a more detailed description about the threat, the security color of the hosted domains in the source (e.g. red color means that the domain is infected). In the case of the source identified in SGNET v1, all the attributes and references are missing.

Filtering : Temporal information is the main input for temporal filtering. Normally, this information is of the order of seconds, which is a sufficient granularity in the context of our alert enrichment process. Due to such information in the results, it does not allow the filtering process to be completely performed. A part from this, threat type values (e.g. Virus, Browser Exploit, Generic google safebrowsing) listed in Table 3.4 do not offer a standard representation of the threat type which avoid the semantic filtering to be automatically executed.

Honeypot Limitations in Alert Correlation

Four major limitations have been identified during the experiments. Two limitations are related to the characteristics of a honeypot sensor implementation. In addition, we identify two other limitations which are related to the design of a honeypot datasets data representation.

Coverage Limitations

When requesting the corresponding object of a specific originating source of a local alerts, around 95% of locally detected alerts do not have a corresponding originating source reference in the explored databases (as deduced from Table 3.3). The main cause of this result is explained by the interaction level of the honeypot sensors.

Even if honeypot sensors are able to interact with attackers and emulate network protocols, they would be unable to cover a large variety of activities like a real interaction between the attacker and the system. For instance, Web-Client Windows Media Player directory traversal via Content-Disposition attacks (cf. CVE from Table 3.2) require a high-interaction level with the attacker and this is not always realized.

Discussion The coverage limitation is also one of the IDS issues as discussed in Section 2.3. Each intrusion detection node has a limited view on the supervised network as shown in [START_REF] Porras | A mission-impact-based approach to infosec alarm correlation[END_REF]. This prevents alert correlation in general and knowledgebased alert correlation in particular of efficiently study the causality link between alerts and then correlate alerts.

Unfilled Attributes and references Limitations

An important number of threats have unfilled attributes such as the help attribute which contain details about the threat type, the vulnerabilities that can be exploited, etc. We conduct a statistical evaluation on 73699 threat objects from HARMUR datasets and we observe that over than 85% of these objects are not referenced to a content object [START_REF] Zanero | The WOMBAT API: querying a global network of advanced honeypots[END_REF]. This latter includes in-depth information related to the threat. This pitfall prevent us essentially from applying semantic and configuration filters described in 3.4.2. Moreover, from Table 3.4, due to the absence of temporal attributes; our temporal filtering is not capable to accomplish the filtering process.

During our enrichment process, we identify the problem of unfilled attributes of datasets' objects which does not guarantee the automatic reasoning and the continuity of the collection process.

Discussion Consistency of alerts' related information has been the subject of numerous researches in IDS and alert correlation. It has been shown that such related information is necessary for better alert correlation [START_REF] Morin | M4D4: a Logical Framework to Support Alert Correlation in Intrusion Detection[END_REF]. Several works have proposed data mining to tackle this problem [START_REF] Shin | Alert Correlation Analysis in Intrusion Detection[END_REF]. Unless these techniques have been proved to be efficient in enhancing alerts' content, it becomes more complex when it is jointly applied on both of alerts datasets and honeypots datasets. Moreover, it requires more processing time and effort. Therefore, it impacts the overall quality of our honeypot-based alert correlation.

3.6. Conclusion

Lack of Standard representation of honeypot data

During our experiments, we observe that information gathered about threats lacks a proper and standard representation. Unfortunately, this limitation makes difficult qualitative evaluation of the exploits and semantic filter. Within HARMUR threats object, each object has a generic threat type as phishing page, virus, browser exploit, etc. Such threat types do not provide clear understanding and in-depth details about the exploit and construct an obstacle for semantic filtering. For instance, even if honyepot datasets report a threat in a specific server, neither the threat type representation nor the help attribute allow us identifying if a causality relationship exist between the locally detected alert and this global threat phenomena.

Discussion We have shown in Section 2.3.3 the importance of security event's representation. In the literature, security databases such as CVE and OSVDB offer a standard representation of vulnerabilities. IDMEF is also a standard format for representing alerts. In our context, the use of standard representation and references allow the design of inference rules in order to facilitate the causality analysis between local and global events. In [START_REF] Cuppens | Alert Correlation in a Cooperative Intrusion Detection Framework[END_REF], the use of standard representation and references in security events allow authors developing a cooperative module for alert correlation.

Cross-references Limitations

Since honeypot databases lack of cooperation and coordination between them, it was a tedious task to request in-depth information of malware infection reported in a specific web-based server from SGNET that includes information about the malware characterization and behavior. For instance, it would be interesting to gather indepth information about a threat reported in HARMUR by requesting SGNET. In the context of our approach of honeypot-based alert correlation and enrichment, it is required that we take advantage of a complete global view of the threat phenomena such as the infected servers, their security evolution over time, characterization and specificity of exploits.

Conclusion

This chapter introduces an application of honeypot databases to enhance alert correlation techniques. We describe a honeypot-based alert correlation that aims at considering external security information collected through the deployment of honeypot sensors in order to enrich the local knowledge of detected intrusions with indepth details about the security profile of the originating source, exploits to which our network is exposed to, etc. We then analyze and explain experimental results and limitations encountered when dealing with the explored honeypot databases to ensure the honeypot-based alert correlation. Although honeypot technologies have proved to be a valuable mean to analyze the threat ecosystem, our experiments demonstrate several limitations of the deployment of current honeypot databases to improve alert correlation. For instance, the lack of precise information and standard representation do not ensure correlation analysis and automatic reasoning. This pitfall can be alleviated by conceiving a unified and standardized framework for honeypot data storage and representation. Assigning standard reference such as CVE to observed exploits and threats could be of a great interest while exploring honeypot databases. These suggestions would ensure that honeypot-based alert correlation is executed. It would make the navigation and the cross-references between these different honeypot databases easier. Honeypot techniques are still evolutionary and can be ameliorated to cover additional security analysis application. In the context of our honeypot-based alert correlation, it is important to ensure concise and complete information that offer to the security analyst a good understanding of threat landscape ecosystem to efficiently identify causality relationships between the local detected alerts and observed threat phenomena in the global view.

E

xisting correlation approaches such as [50, 71, 73-75, 78-80, 82]) operate independently of the security enforcement capabilities of the network. This is due to the lack of a unified model of policy enforcement mechanisms capabilities. In fact, modeling and identifying the enforcement coverage of each security policy enforcement mechanism is necessary to deploy it effectively when processing alerts and reacting to ongoing attacks. Policy Enforcement Points (PEP), once deployed and configured, are responsible to apply rules on specific requests. Intrusion response decisions and countermeasures are generally modifications that should be performed on PEP's configuration. Thus, it is important to easily identify the appropriate PEP to set up these modifications and produce the desired effect. In our work, we concentrate on this desired effect. If alerts are correlated based on these capabilities, it would be more efficient to process them. We propose to model these policy enforcement capabilities in order to not only have a good understanding of deployed policy enforcement capabilities but also tackle several issues in security policy management and intrusion detection. We represent this model by the PEP Responsibility Domain (RD(P EP )). The main objective of RD(P EP ) is to build a consistent view of the deployed policy enforcement capabilities that contribute in defining the appropriate response decision. We first give basic definitions that are mandatory to our PEP model. Then, we propose a definition of a Policy Enforcement Point Responsibility Domain RD(P EP ). Second, we expose several approximation approaches of the RD(PEP). Third, we evaluate the differences between these approximations. Finally, we describe the application of the proposed PEP model on two use cases.

Definitions and axioms

An essential step to be performed when modeling a concept is detailing the basic definitions and axioms. In this section, we enumerate the basic definitions and axioms that are used in our PEP model.

Definitions and axioms

Definitions

A PEP is a set of enforcement rules denoted by r 1 , r 2 , . . . , r m (m is the total number of rules applied by the PEP). In Equation 4.1, we give an algebraic representation characterizing a PEP.

P EP = {r j } j∈[1...m] (4.1)
A PEP is a security entity capable to apply on the received requests, the enforcement decisions represented by {d 1 , d 2 , d 3 , . . . , d p } (p is the total number of all decisions that can be applied by the PEP class such as AAA servers that can either authorize or refuse access for a specific service or entity [START_REF] Vollbrecht | RFC 2904: AAA Authorization Framework[END_REF].).

As defined in access control models [START_REF] Zaborovsky | Access Control Model and Algebra of Firewall Rules[END_REF][START_REF] Betarte | ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies[END_REF][START_REF] El Kalam | Organization Based Access Control[END_REF][START_REF] Samarati | Access Control: Policies, Models, and Mechanisms[END_REF][START_REF] Sandhu | Role-Based Access Control Models[END_REF][START_REF] Garcia Alfaro | MIRAGE: a management tool for the analysis and deployment of network security policies[END_REF], an access control rule r j has usually the following general form:

r j : {conditions} j -→ {decisions} j ∀j ∈ [1, . . . , m] r j : C j -→ D j ∀j ∈ [1, . . . , m]
In general, C j is a conjunctive set of condition attributes which we call Selectors and denote by

{S i } i∈[1...n]
. Hence, a rule r j is represented following Equation 4.2.

r j : ×s i i∈[1...n] -→ {d k } k∈[1...p] ∀j ∈ [1, . . . , m] (4.2)
s i (i ∈ [1 . . . n]
) are instantiation of selectors. In Section 4.3, we define and characterize these selectors.

Axioms

In the rest of this dissertation, the proposed PEP model and enforcement-based alert correlation approach are developed based on the following axioms:

• Axiom 1 The verification of false positive alerts is out of the scope of our work. In the literature, false positive reduction has been studied by many researchers. It is considered as a complex task. Therefore, we assume that our processed alerts are not false positives, are written following the IDMEF (Intrusion Detection and Message Exchange Format) standard described in [69] and are well formed. This axiom implies that all the IDMEF attributes are instantiated in the processed alerts. • Axiom 2 All considered PEPs have a finite set of rules. In practice, security administrators configure on each PEP a finite set of rules which apply the security policy guidelines. • Axiom 3 We ignore the default rule of the PEP. Usually, since the default rule includes the entire selectors' domains, it does not inform us about the configuration specification of the PEP. Thus, only configured rules with specific selectors' instantiations are taken into account.

• Axiom 4 We assume that all the selectors have finite domains. As a consequence, it becomes possible to decompose the selecotrs' domains. • Axiom 5 We also ignore the decision/action that can be applied by the PEP.

In fact, the PEP' enforcement decisions do not include information about the PEP's responsibility domain. This axiom limits the identification of modifications that should be performed on PEP's configuration and in particular decisions applied by the PEP. • Axiom 6 The definition of the Responsibility Domain should only consider the intrinsic characterization and deployment of the PEP. This axiom does not exclude taking into account common domain knowledge that is easily accessible from standard documents, public dictionnaries, etc.

Selector Characterizations

In this section, we define a basic notion of our proposed PEP model which is the selectors.

Selector Definition

The security policy enforcement is usually based on a set of decision/enforcement criteria known as "Selectors". Referring to axiom 4 listed in Section 4.2, selectors have finite domains. This latter is denoted by D(S). We denote by | D(S) | the cardinality of D(S).

Selector Type

Each selector has a defined Selector Type denoted by S T ype which we define in Equation 4.3.

S T ype = {(T ype(S), D(S))} (4.3)
T ype(S) represents the type of the Selector S. It can be for example integer, real, binary, string, timestamp, etc. For instance, the selector IP address (ip_addr) is an integer in [0, 2 32 -1]. We write its type as follow: ip_addr T ype = {integer, [0, 2 32 -1])}.

Selector Category

Each Selector has its role in a Security Policy and its significance. It can identify either the Source and the Target of the considered flow or the type of the interaction between them, mainly the Action. We define S Category the Selector Category.

We consider two categories that are:

• identST: This category of selectors enable us to identify the Source and the Target of an interaction flow. For example, the ip_src and ip_dst are examples of this category. LDAP selectors such as common name cn are example of identST selectors. • identA: This category of selectors identifies the type of interaction (Action) between the Source and the Target. For instance the port_src, the port_dst and the protocol are selectors that specify the type of the connection between the Source and the Target.

Selector Domain Decomposition

As defined in paragraph 4.3.1, D(S) represents the range of all the possible values which can be affected to Selector S. D(S) can be split into a finite number l of generalized sub-domains denoted by δ(S) (Eq 4.4). Those sub-domains are totally disjoint.

D(S) = k∈[1...l] δ k (S)
where

∀k, k ∈ [1 . . . l], δ k (S) ∩ δ k (S) = (4.4)
These sub-domains δ k (S) identifies specific ranges/elements of selector values. In our approach, we assume the these sub-domains are defined by the security administrator.

For example, the domain of selectors src_ip and dst_ip can be composed of different subset of IP addresses such as the subsets of an IP subnetwork range, as shown in Figure 4.1.

As another example, the domain of selectors src_port and dst_port can be composed of port categories such as privileged ports, registered ports and dynamic and/or private ports, as shown in Figure 4.2. Following Equation 4.4, the domain of ports is written as indicated in Equation 4.5. Such decomposition is defined in the RFC 6335 [START_REF] Cotton | Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry[END_REF].

D(src/dst_port) = k∈[1...

Selectors Combinability

A selector may have a different meaning and may impact the security policy when used in a combination with other selectors. Therefore, it should not be considered independently while instantiating the Security Policy Rules. Hereafter, we analyze and study the specific relations between selectors and their instantiations. In fact, there exist several functional constraints and ineffective and insignificant combinations. For instance: i) Selectors with S Category = identA have functional constraints such as mutually exclusive sets of values. For example, the protocol when it is set to udp, it implies the use of a valid sub-domain of D(port_src) and D(port_dst).

ii) Selectors with S Category = identST have several ineffective and insignificant combinations that may figure between this type of selectors. For example, the use of wildcard for both source and destination and combination between the same value for these selectors has no significance. We define the Selectors Combinability Boolean function which we denote by the SCombinability defined in Equation 4.6:

SCombinability : D(S j 1 ) × D(S j 2 ) × . . . × D(S jp ) -→ {T rue, F alse} < s j 1 , s j 2 , . . . , s jp > -→ {T rue, F alse} where j 1 , j 2 , . . . , j p ∈ [1 . . . n] (4.6)
This function verifies the combinability between instantiation of selectors (i.e. s j 1 , s j 2 , . . . , s jp ). It verifies the mutually exclusive values of selectors.

In [START_REF] Garcia Alfaro | Complete analysis of configuration rules to guarantee reliable network security policies[END_REF], authors represent a complete analysis of configuration rules aiming at ensuring reliable network security policies. The main objective of the work proposed in [START_REF] Garcia Alfaro | Complete analysis of configuration rules to guarantee reliable network security policies[END_REF] is the discovery and the removal of anomalies of configuration rules. This work is based on a prior knowledge about the network topology and architecture. However, in our axiom 6, we do not take into account this external knowledge in our proposed PEP model. Since we restrict our proposed model to intrinsic characterization of a PEP, we manually define combinable selector sub-domains. We suppose that, for each generalized sub-domain

δ k (S i ) (k ∈ [1 . . . l]) of a selector domain D(S i ) (i ∈ [1 . . . n]), we identify combinable sub-domains in D(S i ) (i ∈ [1 . . . n]).
We denote a combinable sub-domain of D S(i ) associated to a generalized sub-domain

δ k (S i ) (k ∈ [1 . . . l]) by D Comb_δ k (S i ) (S i
of D Comb_δ k (S i ) (S i ). for k ∈ [1 . . . l] and ∀i, i ∈ [1, . . . , n] D Comb_δ k (S i ) (S i ) = {δ k (S i ), k ∈ [1 . . . l ]} such that ∀ s i ∈ D Comb_δ k (S i ) (S i ) and s i ∈ δ k (S i ), SCombinability(s i , s i ) = T rue. (4.7)
In Figure 4.3, we give a representation of D Comb_δ k (S 1 ) (S 2 ) where we show how the combinability between two selectors S 1 and S 2 is defined. In this case, the sub-

domain δ k (S 1 ) of D(S 1 ) is combinable with δ k (S 2 ) and δ k (S 2 ) of D(S 2 ). Then we have D Comb_δ k (S 1 ) (S 2 ) = {δ k (S 2 ), δ k (S 2 )}.
In Figure 4.4, we show how the SCombinability is evaluated for three selectors S 1 , S 2 and S 3 . For an instance of selectors < s 1 , s 2 , s 3 >, we evaluate the intersection D Comb_δ k (S 1 ) (S 2 ) ∩D Comb_δ k (S 2 ) (S 3 ). In the example shown in Figure 4.4, we have

D Comb_δ k (S 1 ) (S 3 ) ∩D Comb_δ k (S 2 ) (S 3 ) = {δ k (S 3 )}.
For multiple selectors S 1 , S 2 , . . . and S n , in order to have combinable selectors, we should have

D Comb_δ k (S k 1 ) (S k 3 ) ∩D Comb_δ k (S k 2 ) (S k 3 ) = {∅} for all k 1 , k 2 , k 3 ∈ [1 . . . n].

Running Example

In order to illustrate our proposed PEP model, we first detail the running example shown in Figure 4 This example of a PEP can be represented as follow:

F irewall = {r j } j∈[1...11]
The configured rules shown in Table 4.1 are represented as follow:

r j : ×s i i∈[1...5] -→ {d k } k∈[1...2] ∀j ∈ [1, . . . , 11]
where:

S 1 = ip_src, S 2 = port_src, S 3 = ip_dst, S 4 = port_dst, S 5 = p d 1 = accept, d 2 = deny
We remind that selector's domain decomposition is defined by the security administrator as mentioned in section 4.3.2. Therefore, for the running example, the domain of ip source and destination selectors is extracted from the network topology and detailed as follow :

D(src/dst_ip) = k∈[1...3] δ k (src/dst_ip) δ 1 (src_ip) ∪ δ 2 (src_ip) ∪ δ 3 (src_ip) = [161.120.33.0/24] ∪ [140.192.37.0/24] ∪[2 32 -1] \ δ 1 (src_ip) ∪ δ 2 (src_ip)
The domain of port source and destination selectors is extracted from common domain knowledge which is the RFC 6335 [START_REF] Cotton | Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry[END_REF] and detailed as follow:

D(src/dst_port) = k∈[1...3] δ k (src/dst_port) = [0 . . . 1023] ∪ [1024 . . . 49151] ∪[49152 . . . 65535]
The domain of protocol selector is extracted from common domain knowledge which is the RFC 6335 [START_REF] Braden | Requirements for Internet Hosts -Communication Layers[END_REF] and detailed as follow:

D(p) = k∈[1...2] δ k (p) = {tcp} ∪ {udp}
In such example, the SCombinability function allows us evaluate the effectiveness of the configured firewall policy. For instance, a request (in this example, it is a network packet) could not contain the same ip source and destination. Hence, we have

D Comb_δ 1 (src_ip) (dst_ip) = D(dst_ip) \ δ 1 (dst_ip).
We also have all values of src_ip selector combinable with all dst_port selector's values. Then, we write

D Comb_δ k (src_ip) (dst_port) = D(dst_port) for all k ∈ [1, 2, 3].
SCombinability could inform us about rules that include same ip source and destination. These rules are not totally effectively and then are over estimated.

PEP class

We differentiate between PEPs based on the communication layer: Network-level PEP (iptables, juniper, checkpoint, snort . . . ), Application-level PEP (ModSecurity, Anti viruses, . . . ), Information-level PEP (MySQL, . . . ), Identity-Access Control PEP (LDAP, . . . ). Hereafter, we introduce the notion of a PEP class.

Definition 1 PEP class: It is a family of PEPs which share common functional characteristics and enforce the policy based on a common (sub)set of selectors.

Usually, attacks perform actions on a specific communication layer. A PEP class enables the security administrator to identify the capability of a PEP to respond to these attacks.

PEP class properties

Following the Definition As defined in Section 4.2.1, a configured rule has usually the following form:

r j : C j -→ D j ∀j ∈ [1, . . . , m] where: C i = {r i (S j ) = s ij , ∀i ∈ [1 . . . n]} D j ∈ {d 1 , d 2 , d 3 , . . . , d p }
For each request vector, the access control rule r i , ∀ i ∈ [1 . . . m] applies the decision D i when conditions on selectors C i are satisfied. A rule can apply several decisions such as denying and logging. Every rule r i defined in the configured PEP is responsible of enforcing the decision on the corresponding set of flows. It includes all the requests on which the rule's decision(s) may be applied and enforced. We denote it by RD(r i ).

We write the Responsibility Domain of a rule RD(r i ) as follow:

RD(r i ) = < C i >, ∀i ∈ [1 . . . m] = < s ij > j∈[1...n] , ∀i ∈ [1 . . . m] (4.10)
Since s ij ⊆ D(S j ), one rule may include multiple selectors combination. We define hereafter the RD(r i ) coverage.

Consequence 1 RD(r j ) Coverage: RD(r i ) Coverage is the number of all the selectors combination defined in the rule r. It is expressed in Equation 4.11.

| RD(r i ) | = j∈[1...n] | s ij | (

Characterization of relations between Responsibility Domain of rules

In [START_REF] Al-Shaer | Discovery of policy anomalies in distributed firewalls[END_REF], authors define five relations that may exist between rules. They demonstrate that these relations are unique and that can be applied to define the different conflicts and anomalies that may figure between rules.

We adopt these relationships and define them between Responsibility Domain of rules. Overlaps between rules result in overlaps between their Responsibility Domains. Hereafter, we detail the relationships that may exist between the Responsibility Domains of rules.

• RD(r 1 ) and RD(r 2 ) are Completely Disjoint (CD) and we write CD(RD(r 1 ), RD(r 2 )),

iff ∀j ∈ [1 . . . n], r 1 (S j ) r 2 (S j ) where ∈ {⊂, ⊃, =} (4.15)
• RD(r 1 ) and RD(r 2 ) are Exactly Matched (EM ) and we write EM (RD(r 1 ), RD(r 2 )),

iff ∀j ∈ [1 . . . n], r 1 (S j ) = r 2 (S j ) (4.16)
• RD(r 1 ) and RD(r 2 ) are Inclusively Matched (IM ) and we write IM (RD(r 1 ), RD(r 2 )), iff ∀j ∈ [1 . . . n], r 1 (S j ) ⊆ r 2 (S j ) and ∃j such that r 1 (S j ) = r 2 (S j ) (4.17)

• RD(r 1 ) and RD(r 2 ) are Partially Matched (P M ) and we write P M (RD(r 1 ), RD(r 2 )),iff

∃j , j ∈ [1 . . . n], r 1 (S j ) r 2 (S j ) r 1 (S j ) r 2 (S j ) where ∈ {⊂, ⊃, =} (4.18)
• RD(r 1 ) and RD(r 2 ) are Correlated (C) and we write C(RD(r 1 ), RD(r 2 )),iff ∀j ∈ [1 . . . n], r 1 (S j ) r 2 (S j ) and ∃ j , j ∈ [1 . . . n] such that r 1 (S j ) ⊂ r 2 (S j )

and r 1 (S j ) ⊃ r 2 (S j ) where ∈ {⊂, ⊃, =}

In [START_REF] Al-Shaer | Discovery of policy anomalies in distributed firewalls[END_REF], these relationships are used in order to detect conflicts which are a topic out of the scope of our work. Different from [START_REF] Al-Shaer | Discovery of policy anomalies in distributed firewalls[END_REF], these relationships are used in order to define approximation inferences that will be detailed in Section 4.7. Since we assume in axiom 4 the non availability of such knowledge, RD sup (P EP ) will not be identified in this work.

As policy enforcement is, in most cases, distributed along the different PEPs, it is important to model their enforcement coverage, RD(P EP ), in order to support the administrator in selecting the most appropriate ones. An appropriate PEP is a PEP which is able to process a considerable number of alerts while ensuring a low reaction cost. Thus, the definition and identification of an appropriate approximation of the RD(P EP ) must be well defined.

Hereafter, we first give an identification of RD inf (P EP ) and then detail several approximations of the RD(P EP ).

RD inf (P EP ) = i∈[1...m] RD(r i ) = i∈[1...m] < s ij > j∈[1...n] (4.21)
Running example : Based on the configuration table of the firewall, the RD inf (F irewall) will be written as follow: rb() :

RD inf (F irewall) = {< 140
U -→ U RD inf (P EP ) -→ RD rb_apprx 1 (P EP ) (4.23)
The first rule-based approximation RD rb_apprx 1 (P EP ) is the result of the application of the function rb(RD inf ) to all vectors of RD inf (P EP ).

sb() :

U -→ U RD inf (P EP ) -→ RD sb_apprx 1 (P EP ) (4.24)
The first selector-based approximation RD sb_apprx 1 (P EP ) is the result of the application of the function sb(RD inf ) to all vectors of RD inf (P EP ).

Responsibility Domain of PEP (RD(P EP ))

We respectively detail these functions: rb() and sb() in Sections 4.7.3.1 and 4.7.4.1.

gen() :

U -→ U < s j , j ∈ [1 . . . n] > -→< δ k j , j ∈ [1 . . . n] > (4.25)
This function, gen(), refers to a generalization process which considers the Selector Domain Partition defined in paragraph 4.3. For each selector instantiation, s j , gen() identifies the corresponding partition of s j . The resulting vector will be a tuple of these generalized partitions.

Rule-based approximations of RD(P EP )

First rb_approximation of RD(P EP )

RD rb_apprx 1 (P EP ) is the result of rb(RD inf (P EP )) which performs several inference operations as explained before.

Inference operations performed by rb() • If RD(r 1 ) and RD(r 2 ) are Completely Disjoint, we include both of these rules. In the approximation algorithm described below, this operation is represented by ←.

• If RD(r 1 ) and RD(r 2 ) are Exactly Matched , we keep only one rule since they represent the same Responsibility Domain.

• If RD(r 1 ) and RD(r 2 ) are Inclusively Matched , then:

∃ j ∈ [1 . . . n] such that r 1 (S j ) ⊂ r 2 (S j ) (4.26)
As shown in figure 4.7, in this relation, there is a rule with a larger Responsibility Domain. In our approximation, we only retain this rule. In the approximation algorithm described below, this operation is represented by ←. • If RD(r 1 ) and RD(r 2 ) are Partially Matched , then: RD(r k ) ← RD(r k ) + RD(r i )

∃ i ∈ [1 . . . n] such that r 1 (S i ) r 2 (S i ) (4.
13:

else if R = CD(RD(r k ), RD(r i )) & SCombinability(s j , j ∈ [1 . . . n]) = true then 14: RD(r k ) ← RD(r k ) + RD(r i ) 15: else if R = C(RD(r k ), RD(r i )) & SCombinability(s j , j ∈ [1 . . . n]) = true then 16: RD(r k ) ← RD(r k ) + RD(r i ) 17: else if R = EM (RD(r k ), RD(r i )) & SCombinability(s j , j ∈ [1 . . . n]) = true then 18: RD(r k ) ← RD(r i ) 19:
else 20:

RD rb_apprx 1 (P EP ) ← RD rb_apprx 1 (P EP ) + RD(r i ))

21:

k ← k + 1 22:
end if

23:

end for 24: end for 25: return RD rb_apprx 1 (P EP ) RD rb_apprx 1 (P EP ) Algorithm: RD rb_apprx 1 (P EP ) is a set of vectors RD(r k ) derived from RD inf (P EP ). Our approximation algorithm takes into account the relationships between rules and the constraints of combinability on selectors defined above. Algorithm 1 shows the different steps of the approximation algorithm. The RD rb_apprx 1 (P EP ) is first initialized by RD(r 1 ). Then, we iterate the RD inf (P EP ) to check the existence of the defined relationships between RD(r i ) and RD(r k ). For each discovered relationship, we append the RD rb_apprx 1 (P EP ) with the corresponding elementary RD. We denote R the discovered relationships between RD(r i ) and RD(r k ). VerifyR is a function which identifies the relationship that exists between two different Responsibility Domains. length(RD(P EP )) is the number of vectors in the responsibility domain.

Running example

In this paragraph, we detail the application of the first rbapproximation of RD(P EP ) on our running example. m = 9 represents the number of configured rules while ignoring the default rules. In Algorithm 2, we detail the application of Algorithm 1 and we indicate for each action the corresponding line number in algorithm 1. The result of RD rb_apprx 1 (F irewall) is represented in Equation 4.29:

RD rb_apprx 1 (F irewall) = {< *

Second rb_approximation of RD(P EP )

A drawback of the first approximation is that it closely depends, by construction, on the configuration of the PEP. This causes a limited view of the real enforcement coverage of the PEP, since we only consider the configured values of selectors in rules and their combinations. But, the enforcement coverage of the PEP may be larger than inspecting only specific values and it may be capable to control a larger range of values.

Our second approximation of RD(P EP ) relies on selector taxonomy defined in paragraph 4.3.1. The objective at this stage, is the relaxation of the estimated RD rb_apprx 1 (P EP ) in order to get more realistic view of the PEP's enforcement coverage.

We perform gen() function on the set of vectors of RD rb_apprx 1 (P EP ). For example, if the selector has a specific host IP address, then, we replace it with its corresponding sub-network. This operation is performed by the line 8 of the algorithm 3 where we identify the corresponding generalized domain δ k (S j ) such that r i (S j ) ⊂ δ k (S j ).

Hereafter, we detail the second approximation algorithm 3. We denote by m rb_apprx 1 the number of rules in RD rb_apprx 1 (P EP ).

Algorithm 3 RD rb_apprx 2 (P EP ) ← Approximation_RD(PEP)_2(RD rb_apprx 1 (P EP )) while r i (S j ) = D(S j ) and r i (S j ) = δ k (S j ) do 6:

identif y δ k (S j ) such that r i (S j ) ⊂ δ k (S j ) 7:

r i (S j ) ← δ k (S j ) 8:
end while

9:
end for 10: end for 11:

RD rb_apprx 2 (P EP ) ← i∈[1...m rb_apprx 1 ] r i (S j ), j ∈ [1 . . .

n]

12: return RD rb_apprx 2 (P EP ) Example We consider the example listed above: RD rb_apprx 1 (F irewall) and we perform the second approximation algorithm as detailed in Algorithm 4.

Algorithm 4 RD rb_apprx 2 (F irewall) ← Approximation_RD(Firewall)_2 (RD rb_apprx 1 (F irewall)) Input: RD rb_apprx 1 (F irewall) Output: RD rb_apprx 2 (F irewall) for i = 1 for j = 5: r 1 (S 1 ) = D(S 1 ) for j = 5: r 1 (S 2 ) = D(S ( 2)) for j = 6: r 1 (S 3 ) ⊂ δ 1 (S 3 ) = [161.120.33.0/24] 7: r 1 (S 3 ) ← δ 1 (S 3 ) for j = 6: r 1 (S 4 ) ⊂ δ 1 (S 4 ) = [0 . . . 1023] 7: r 1 (S 4 ) ← δ 1 (S 4 ) for j = 5: r 1 (S 5 ) = D(S 5 ) for i = 2 for j = 5: r 1 (S 1 ) = δ 2 (S 1 ) for j = 5: r 1 (S 2 ) = D(S ( 2)) for j = 5: r 1 (S 3 ) = D(S ( 3)) for j = 6: r 1 (S 4 ) ⊂ δ 1 (S 4 ) = [0 . . . 1023] 7: r 1 (S 4 ) ← δ 1 (S 4 ) for j = 5: r 1 (S 5 ) = δ 1 (S 5 ) for i = 3 for j = 5: r 1 (S 1 ) = δ 2 (S 1 ) for j = 5: r 1 (S 2 ) = D(S ( 2)) for j = 5: r 1 (S 3 ) = δ 1 (S 3 ) for j = 5: r 1 (S 4 ) = D(S ( 4)) for j = 5: r 1 (S 5 ) = δ 2 (S 5 ) 11: RD rb_apprx 2 (F irewall) ← i∈[1...m rb_apprx 1 ] r i (S j ), j ∈ [1 . . . n] return RD rb_apprx 2 (F irewall)

Responsibility Domain of PEP (RD(P EP ))

The result of RD rb_apprx 2 (F irewall) is represented in Equation 4.30: This approximation is based on the instantiated values for each selector along RD inf (P EP ) denoted as D sb_apprx 1 (S i ). We consider the set of all the valid selectors combinations where SCombinability(s j , j ∈ [1 . . . n]) = T rue. Algorithm 5 displays the different operations to build the first sb_approximation of RD(P EP ). Within this approach, the wildcard is taken into account but is processed differently following the verification of SCombinability function. In fact, if the administrator does not set a specific value for a selector S along the configuration of the PEP, we ignore this selector. In this case, the wildcard is used for all the vectors in RD inf (P EP ). Therefore, the dimension of the PEP will be decreased by one as described in Equation 4.31:

RD rb_apprx 2 (F irewall) = {< *
if ∃i such that S i = * ∀ j ∈ [1 . . . m] then Dim(P EP ) ← n -1 n ← n -1 (
for all j ∈ [2 . . . m] do 11: if r j (S i ) = D sb_apprx 1 (S i ) or (D sb_apprx 1 (S i ) ⊂ r j (S i ) and r j (S i ) = * ) then 12: D sb_apprx 1 (S i ) ← D sb_apprx 1 (S i ) + r j (S i ) 13:
else if r j (S i ) = * then 14:

D sb_apprx 1 (S i ) ← D sb_apprx 1 (S i ) + r j (S i ) 15: end if 16:
end for 17: end for 18:

RD sb_apprx 1 (P EP ) ← { × i=1...n D sb_apprx 1 (S i ), such that SCombinability(s i , i ∈ [1 . . . n]) = true} 19: return RD sb_apprx 1 (P EP )
Example We consider the example listed above: RD inf (F irewall) and we perform the third approximation algorithm. We notice that along all the rows of RD inf (F irewall), the wildcard is assigned to selector src_port. Therefore, the dimension of the Firewall is decreased by one. In Algorithm 6, we detail the application of Algorithm 5 for the first selector which is src_ip.

Responsibility Domain of PEP (RD(P

EP )) Algorithm 6 RD sb_apprx 1 (F irewall) ← Approximation_RD(Firewall)_3(RD inf (F irewall)) Input: RD inf (F irewall) Output: RD sb_apprx 1 (F irewall) 3: S 3 = src_port = * ∀ j ∈ [1 . . . 9] 4: then 5 ← 4 for all 6: i ∈ [1 . . . 4] do 7: D sb_apprx 1 (S i ) = r 1 (S i ) end for for i = 1 for j = 2 13: r 2 (S 1 ) = * 14: D sb_apprx 1 (S 1 ) ← D sb_apprx 1 (S 1 ) + * for j = 3 r 3 (S 1 ) ⊂ D sb_apprx 1 (S 1 )(1) for j = 4 r 4 (S 1 ) = D sb_apprx 1 (S 1 )(1) for j = 5 r 5 (S 1 ) ⊂ D sb_apprx 1 (S 1 )(1)
for j = 6 r 6 (S 1 ) = D sb_apprx 1 (S 1 )(1) for j = 7 r 7 (S 1 ) = D sb_apprx 1 (S 1 )(1) for j = 8 r 2 (S 1 ) = * for j = 9 r 9 (S 1 ) = D sb_apprx 1 (S 1 )(1)

18: RD sb_apprx 1 (F irewall) ← { × i=1...4 D sb_apprx 1 (S i ), such that SCombinability(s i , i ∈ [1 . . . 4]) = true} return 19: RD sb_apprx 1 (F irewall)
Hereafter in Equation 4.32, we detail the result of the different D sb_apprx 1 domains of the Firewall selectors.

The result of RD sb_apprx 1 (F irewall) is represented in Equation 4.33:

RD sb_apprx 1 (F irewall) = {D sb_apprx 1 (src_ip) × D sb_apprx 1 (dst_ip) ×D sb_apprx 1 (dst_port) × D sb_apprx 1 (p)

Qualitative Analysis: Approximation Accuracy metric

Use case

In this Section, we consider the Running Example defined in Section 4.4.

Identification of RD sup (F irewall):

As mentioned in the Definition 5, the RD sup of a deployed PEP includes the set of all possible vectors characterizing the flow that may pass through the PEP. We denote by D sup (S) the real domain of a Selector S.

It is identified by considering the topological information about the network. In Section 4.7, we identified the approximations of RD(F irewall) based on RD inf (F irewall). These approximations correspond to the case of Figure 4.9 (c).

D
Approximation Accuracy has been introduced in several mathematical theories such as approximation theory, rough set, fuzzy set, etc. In our approach, we propose to apply this metric in order to evaluate how accurate the approximations are regarding the real Responsibility Domain of the PEP. We adapt the Approximation Accuracy expression defined in Rough Set Theory [START_REF] Pawlak | Rough Sets[END_REF]. In [START_REF] Pawlak | Rough Sets[END_REF], the author define the Accuracy Approximation as a measure to express the quality of the approximation. In Equation 4.39, we define the Approximation Accuracy of RD apprx (P EP ) which we denote as Λ(RD apprx (P EP )) as:

Λ(RD apprx (P EP )) = |RDapprx(P EP )| |RDsup(P EP )| (4.39)
Obviously, 0 < Λ(RD inf (P EP )) ≤ Λ(RD apprx (P EP )) ≤ 1 for any RD apprx (P EP ). Following the definition of the approximation of the Responsibility Domain, it is more accurate when Λ(RD apprx (P EP )) is closer to 1. In Table 4.3, we evaluate this metric for the different approximations of the running example. Based on results shown in Table 4.3, the Approximation Accuracy of approximations RD sb_apprx 1 and RD sb_apprx 2 is 10 8 times bigger than the Λ(RD inf (P EP )). In this case, selector-based approximations are more appropriate than rule-based approximations.

Applications

The proposed PEP model can be used in several security applications. Hereafter, we detail some of these applications.

Policy anomalies detection

Security Policy anomalies are one of the most critical security issue in a network. Rule misconfiguration induce security policy conflicts either within a single policy (intra-policy conflicts) or between policies in different devices (inter-policy conflicts), [START_REF] Hamed | Taxonomy of conflicts in network security policies[END_REF]. In [START_REF] Hamed | Taxonomy of conflicts in network security policies[END_REF], authors present a taxonomy of security policy conflicts. The most common policy conflict occurs when different access control decisions are applied on the same flow.

Conflict detection can be considered as an easy task to cope with in an environment with a single PEP. However, it becomes a challenging task and error-prone in an environment with distributed PEP. Referring to our model, conflict detection can be defined as overlapping domains between different RD inf (P EP ) on which different decisions (d k 1 and d k 2 ∈ {d k } k∈[1...p] ) are applied. Our proposed PEP model is abstract enough to allow us to identify these overlapping domains between several PEPs. In Equation 4.40, we express the inter-PEP conflict detection process using our PEP model.

if RD inf (P EP 1 ) ∩ RD inf (P EP 2 ) = ⇒ if ∃ d k 1 , d k 2 ∈ [d 1 . . . d p ], such that d k 1 =

Intrusion Detection Assessment

Scenario-based IDS usually rely on attack signatures when generating alerts. Attack signatures allow IDSs examining the events monitored in the supervised network by providing attack description specification. Cuppens et Al. [START_REF] Cuppens | LAMBDA: A Language to Model a Database for Detection of Attacks[END_REF] define LAMBDA, an attack description language. In LAMBDA, an attack is a combination of actions with additional statements related to the supervised network. LAMBDA language specifies the pre-conditions that should be satisfied by the supervised network for an attack to be feasible [START_REF] Cuppens | LAMBDA: A Language to Model a Database for Detection of Attacks[END_REF]. It also specifies the post-conditions of an attack. Post-conditions are the effects of a successful execution of an attack. In Figure 4.10, we show an example of a LAMBDA attack description. Pre-conditions and post-conditions are a set of logical conditions respectively denoted by C pre and C post . From Figure 4.10, remote_access(A, H) is an example of a condition C pre . knows(A, use_serviceH, portmapper)) is an example of C post . In practice, pre and post conditions are elements that can be identified based on the attack signature and more specifically based on the exploited vulnerability1 . IDS relies on these signatures in order to detect attacks and generate alerts. Alerts are messages including information about the potential attack instantiation. Following the PEP function given in Equation 4.2 and the LAMBDA description language, we model network

. p IDS ], is the intrusion detection decision (generate alert or not)

that is applied by the netIDS. Note that post-conditions are considered to be one of the decisions taken by the netIDS. In fact, once an attack is detected, the netIDS identifies the real consequences of this attack by considering the attack signature allowing the detection of the attack and the properties of the supervised network. Using the model expressed in Equation 4.41, it becomes straightforward to evaluate the capability of the netIDS in detecting different attack scenarios. In fact, if ∃ C post ∈ D(post) such that C post ∈⊂ D(pre), then, it is possible to detect elementary attacks that potentially belong to a same attack scenario. Our model allows the security administrator to identify IDSs that are capable to collaborate in detecting attack scenarios. We note netIDS 1 and netIDS 2 two different IDSs and (D 1 (pre), D 1 (post)) and (D 2 (pre), D 2 (post)) their corresponding domains of pre-conditions and post-conditions. netIDS 1 and netIDS 2 are capable to collaborate in detecting attack scenarios if ∃ C post ∈ D 2 (post) such that C post ∈⊂ D 1 (pre).

Conclusion

We introduce a novel concept to model Policy Enforcement Point by their Responsibility Domain, RD(P EP ). We first characterize the P EP by the set of selectors. Then, we define the Responsibility Domain of a configured rule RD(r). We analyze the relationships that may exist between these domains and define a set of approximation inferences. Based on the different properties that exist between RD(r) and the characterization of selectors, we give different approximations of the RD(P EP ). We have shown that these approximations have different properties and multiple use cases. The advantage of our methodology to approximate RD(P EP ) is the performance in a 'blind manner'. Also, the consideration of the PEP configuration makes the approximations more useful for response decision.

Chapter 5

Enforcement-based Alert Correlation Framework

Definition and Framework Description

Definition and Objectives

Alerts are correlated if they share a common (set of) PEP(s) capable of applying a countermeasure on the flow corresponding to the alert. Definition 6 Enforcement-based Alert Correlation : Given a set of alerts and a set of deployed PEP, the Enforcement-based Alert Correlation groups alerts that can be processed by a common PEPs.

In Equation 5.1, we write the basic correlation inference used in our Enforcementbased Alert Correlation approach. A ec is intended to group one or more generated alerts together, to say "these alerts can be processed by the same PEP(s)".

A 1 ∈ RD(P EP 1 ) ∧ A 2 ∈ RD(P EP 1 ) ∧ . . . =⇒ A ec = (A 1 ,

Framework

The Policy Enforcement-based Alert Correlation Engine (PEACE) represented in Figure 5.1 and Figure 5.2 is the core of our framework. It is responsible of checking which alerts can be processed by a same set of PEP(s). The configurations of deployed PEPs are retrieved and sent to the RD-Approximator. This latter performs the proposed approximations on collected configurations. Approximations are stored in a centralized database which is RD_DB. PEACE is then able to process the received alerts {A 1 , A 2 , . . . , A nt }. n t is the number of alerts generated during a period of time t.

The PEACE framework provides the security administrator with a set of correlated alerts {A ec 1 , A ec 2 , . . . , A ec n a }, where n a ≤ n a .

Alignment Functions

The membership verification, A ∈ RD(P EP ), mentioned in Equation 5.1, requires that both A and RD(P EP ) are represented following the same multidimensional domain. However, on one hand, alerts are expressed in IDMEF. On the other hand, deployed PEPs are represented according to their PEP class domain as defined in Definition 1. These discrepancies between the IDMEF standard and PEP class expressions leads to semantic and syntactic differences which prevent us from easily computing the membership function defined in 5. Table 5.1 -Analogy between IDMEF attributes and selectors of three PEPs (Iptable, ModSecurity, LDAP) [port]

h h h h h h h h h h h h h h h h h h h IDMEF (

LDAP String

Thus, PEACE requires to align alert domains with the PEPs' Responsibility Domains. To meet this requirement, we propose some Alignment Functions. Two Alignment Function:

Table 5.2 -Analogy between IDMEF attributes and selectors of three PEPs (Iptable, ModSecurity, LDAP) h h h h h h h h h h h h h h h

Table 5.3 -Analogy between IDMEF attributes and selectors of three PEPs (Iptable, ModSecurity, LDAP) h h h h h h h h h h h h h h h h

• Projection: this operation extracts the selector S i directly from the IDMEF alert. For instance, based on Tables 5.1 and 5.2 and 5.3, projection function are performed on elements that are not written in bold or underlined. No additional operations are performed on the corresponding attribute. In this case, the attribute a j , j ∈ [1 . . . n idmef ] has the semantics of selector S i . • endo-Deduction: this function performs a first order inference in order to instantiate the appropriate attribute a j in the alert A as described in Equation 5.3. a j is of the same semantic of Selector S j , j ∈

[1 . . . n pep ]. if (a i = val 1 ∧ a i = val 2 ∧ . . .) =⇒ a j = val 3 (5.3)
val 1 and val 2 are respectively the information filled in attributes a i and a i . val 3 is the result of the inference which is the information of attribute a j .

From Tables 5.1, 5.2 and 5.3, elements that are in bold are to be used in endo-Deduction alignment function. • exo-Deduction: using the information of the alert and referring to an external knowledge (represented by the "Ext" component in Figure 5.3 such as the Geographical Location database, exo-Deduction operation infer the value of a corresponding attribute a j in the alert A . Like endo-Deduction, exo-Deduction is a set of first order inferences. This alignment function considers underlined elements in Table 5.1 such the GeoIP database. where Dim(RD idmef (P EP )) = n idmef (5.4) As discussed in Section 2.5, IDMEF has been conceived in order to ensure both of syntactic and semantic interoperability. Therefore, the application of previously described alignment operations becomes straightforward in the second option of alignment function.

* n cpep is the number of deployed class of PEPs.

Comparison between alignment options

Alignment is performed during the pre-correlation phase. In Table 5.4, we compare the two options while considering three important criteria: the execution of the In the rest of this work, we assume that both alerts and Responsibility Domains of deployed PEPs are presented in the same multi-dimensional domain. We will use the notation defined in Equation 5.5 to represent both alert and PEP responsibility domains.

A =< a 1 , a 2 , . . . , a n > RD(P EP ) = j∈[1...nr] < s j1 , s j2 , . . . , s jn > = j∈[1...nr] v j
where n r is the number of RD(PEP) rule vectors v j .

(5.5)

Membership function: Alert ∈ RD(PEP)

The membership function in Equation 5.1 is a fundamental step for our Enforcementbased Alert Correlation approach. Usually, a vector e =< e 1 , e 2 , . . . , e n > is included in an n-dimensional domain

D if ∃ d ∈ D such that ∀i ∈ [1 . . . n], e i = d i .
We call this property the membership of e in D.

In our context, exact membership means that the deployed PEP is able to implement a countermeasure rule which is capable to process the alert. Therefore, it is necessary to verify the membership function of the alert A within the RD(P EP ). We denote it γ(A, RD(P EP )).

Since the RD(P EP ) is a set of n r vector rules, we first define the membership of the alert within each Responsibility Domain of a rule vector v j (j ∈ [1 . . . n r ]) denoted by γ j (A, RD(v j )). In Equation 5.6, we define γ j (A, RD(v j )):

γ j (A, RD(v j )) = × i∈[1...n] verif (a i , v ji )
where ×is the multiplication operator of real set R.

and verif (a i , v ji ) = 1, if a i ⊆ v ji . 0, otherwise.
(

The membership of the Alert A within the RD(P EP ) means that there exist at least a rule vector v j whose the RD(v j ) covers all the selectors of the Alert. We define γ(A, RD(P EP )) in Equation 5.7.

γ(A, RD(P EP )) = j∈[1...nr] (γ j (A, RD(v j )))
where is the logical OR operator (

Note that:

γ(A, RD(P EP )) ∈ {0, 1} and we have:

         ifγ(A, RD(P EP )) = 1,
⇒ membership of the alert A in the RD(P EP ). ifγ j (A, RD(P EP )) = 0, ⇒ non-membership of the alert A in the RD(P EP ).

Enforcement-based alert correlation workflow

In this section, we detail in Figure 5.5 the enforcement-based alert correlation workflow. It exposes the different steps that should be executed in order to decide whether the PEP is able to process an alert A or not. The membership verification is the first step in this workflow. If the alert A does not fall in the responsibility domain of a PEP, then another PEP will be analyzed. If the alert A falls in the responsibility domain of a PEP, then the process "identify rules in Conf (P EP )" is executed. The objective of this process is to identify the potential rules that may be affected to implement the countermeasure. After identifying the potential configured rules that can process the alert, we analyze the possibilities of countermeasure implementation. Hereafter, the possibilities are described:

Enforcement-based alert correlation workflow

• Modify existing rule's decision; • Modify configured values for specific selectors in configured rules; • Create new rule in Conf (P EP ).

We may need external information, such as the vulnerability and the criticality of 87 CHAPT 5. ENFORCEMENT-BASED ALERT CORRELATION FRAMEWORK the attack, about the generated alerts when analyzing the response decision.

Conclusion

This chapter introduces a novel alert correlation approach which based on the responsibility domain of a PEP. Since it is performed on mutli-dimensional elements, we first study the representation requirements of alerts and responsibility domain. For this aim, we propose alignment functions which allow the representation of alerts and responsibility domain vectors in the same multi-dimensional space. We then define a membership function which allows the identification of PEP that can process generated alert. Finally, the workflow of the proposed alert correlation approach is detailed.

Introduction

I

n this chapter, we focus on studying the application of our enforcement-based alert correlation. We first apply our approach on a single PEP environment. We demonstrate how our alert correlation approach allows the identification of potential rules in order to react to attacks. We then examine the application of our approach on a multi-PEP environment using a real case scenario. We explain how our enforcement-based alert correlation is able to support the security administrator in response decision and countermeasure implementation.

Application of PEACE on a single PEP use case

In this section, we detail the application of our proposed alert correlation approach on a single PEP use case. Respecting Equation 5.5, we remind that both alerts and Responsibility Domains of deployed PEPs are presented in the same multidimensional domain. Hence, the membership function is performed on vectors with same dimension. The application on a single PEP use case assists the security administrator in identifying configured rules which will be modified in order to process correlated alerts. Hereafter, we study the application of the proposed responsibility domains of a PEP on our alert correlation.

Alert Correlation based on the RD inf (P EP )

As defined in Section 4.7, RD inf (P EP ) is composed of all the rule vectors configured in the deployed PEP. Verifying the membership of an alert within RD inf (P EP ) implies the identification (as shown in Equation 6.1) of the appropriate rule vector in the Conf selectors (P EP ), which is capable to implement the reaction decision. In such case, the reaction decision is generally a modification of the enforcement decision applied by the rule.

A ∈ RD inf (P EP ) ⇒ ∃ i ∈ [1 . . . n r ] \ ∀j ∈ [1 . . . n], a j ⊆ s ij (6.1)
Two alerts, A 1 =< a 11 , a 12 , . . . , a 1n > and A 2 =< a 21 , a 22 , . . . , a 2n >, are correlated based on RD inf (P EP ) when ∃ j 1 , j 2 ∈ [1 . . . n] \ a 1j ⊆ s ij 1 and a 2j ⊆ s ij 2 . There are two possible cases:

• Case 1: j 1 = j 2 . Then, both of the alerts are processed by the same rule r j 1 .

In this case, we define the Enforcement-based correlated alert as follow:

A ec = (A 1 , A 2 ), (r j 1 , RD inf (P EP ))
This correlated alert specifies the rule vector that will processes the correlated alerts A 1 and A 2 . • Case 2: j 1 = j 2 . Then, the two alerts can be processed by the same PEP but not by the same rule.

Correlating alerts using RD inf (P EP ) provides more than the verification of the capability of the PEP to process the correlated alerts, it also identifies the capability of each rule vector of RD inf (P EP ) in implementing a response decision. For instance, in the case of a firewall, in order to process an alert, it is possible to modify an accept to deny enforcement decision.

Alert Correlation based on Rule-based first approximation

As detailed in Chapter 4 , rule vectors of RD rb_apprx 1 (P EP ) are obtained by applying rb() inference functions on RD inf (P EP ). For instance, as shown in Equation 6.2, when two rule vectors RD(r 1 ) and RD(r 2 ) in RD inf (P EP ) are Partially Matched and combinable, we merge them in a single rule RD(r 1,2 ) vector in RD rb_apprx 1 (P EP ).

RD(r

This inference instantiates a generalized rule vector RD(r 1,2 ) which includes both of RD(r 1 ) and RD(r 2 ). RD rb_apprx 1 (P EP ) correlates alerts that partially share a common (sub)set of attributes. Thus, applying RD rb_apprx 1 (P EP ) in our alert correlation approach allows to correlate alerts which can be processed by modifying a common set of rules configured in the deployed PEP or defining new rules. For instance, the following alerts detailed in Equation 6.3 are correlated with RD(r 1,2 ). Since this latter is the result of merging RD(r 1 ) and RD(r 2 ), we conclude that both alerts A 1 and A 2 can be processed by rules r 1 and r 2 .

A

RD(r 1,2,3 ) includes additional rule vectors which are totally different from the input rule vectors. Thus, Enforcement-based Alert Correlation based on RD sb_apprx 1 (P EP ) correlates alerts which will not be necessary processed by a common set of configured rules.

Alert Correlation based on the generalized approximations

The gen() function is performed on both of rule-based and selector-based first approximations respectively denoted by RD rb_apprx 1 (P EP ) and RD sb_apprx 1 (P EP ). gen() consists in expanding the approximated Responsibility Domain of the PEP in order to have larger coverage of network flow vectors that may pass through the PEP. This fact leads to a higher number of alerts that fall in the responsibility domain of the considered PEP. For instance, applying gen() function on RD(r 1,2 ) listed in example 6.2 results in RD gen (r 1,2 ) defined in Equation 6.5:

RD gen (r 1,2 ) =< 140.192.37. * , * port , * ip , [1 . . . 1024], {tcp} > (6.5)
The evaluation of RD gen (r 1,2 )coverage shows that gen() function increases the coverage of RD(r 1,2 ) by (2 10 -3) times. On the one hand, this Coverage Increase (CI) explains how generalized approximations RD rb_apprx 2 (P EP ) or RD sb_apprx 2 (P EP ) allow us to correlated more alerts relative to the same PEP. On the other hand, correlated alerts will be processed by different countermeasure implementations. In this case, countermeasure implementations should be either modification of configured rule vectors or insertion of a new rule vector in the configuration of the PEP. Insertion of a new rule vector in a configuration of a PEP require a deep analysis and study in terms of conflict detection and policy validation.

Interpretations and Analysis

We further compare the application of the different Responsibility Domain approximations on Alert Correlation. Since our proposed PEP responsibility domain model is build following a bottom-up approach and in blind manner, there must be a tradeoff between correlation and the PEP responsibility domain approximation coverage. Table 6.1 depicts the advantages and drawbacks of each responsibility domain approximations in Enforcement-based Alert Correlation.

The ability to correlated alerts increases with the Coverage Increase since the more RD apprx (P EP ) is wider than RD inf (P EP ), the more we correlate alerts relative to the PEP.

Definition 7

We define the Coverage Increase (CI) of the RD approximations (RD apprx (P EP )), denoted by CI(RD apprx ), as the additional rule vectors generated by the approximation.

In Equation 6.6, we detail how CI is evaluated:

CI(RD apprx (P EP )) = |RDapprx(P EP )| |RD inf (P EP )| (6.6)
This metric is evaluated for the example described in 4.4. Table 6.2 includes the evaluations of this metric for the different approximations. In the second row of the Table 6.2, we give an evaluation of the cardinality of each approximations which is denoted by | (RD apprx (P EP ) |.

In the context of the running example, RD sb_apprx 1 and RD sb_apprx 2 have the same set of vectors. In fact, the configured values for selectors throughout the rules totally cover different partitions. Thus, in this case, the generalized function does not result in an additional number of elements as we assert from the second row of Table 6.2.

Based on the evaluation of the coverage increase shown in Table 6.2, the generalization function performed on responsibility domain approximations has an important effect on the coverage increase. In our running example, it multiplies the coverage increase by 10 5 comparing it to the first rule-based approximation. This fact increases the ability to correlate alerts. In this section, we demonstrate how our correlation approach helps the security administrator in implementing countermeasures. We explain how our alert correlation approach enables us identifying PEPs that are capable to process a group of correlated alerts. The question is: "Once the PEP is identified, is it possible to correlate alerts based on the configured rules in order to optimize the countermeasure implementations?" Since the responsibility domains approximations are build following a bottom up approach as described in Chapter 4, it is possible to identify configured rules that are to be modified in order to implement countermeasures. In our context, countermeasures are the modifications brought to the existing configuration of the PEP in order to mitigate detected attacks. These modifications includes for example expanding the value defined in a configured rule for a selector or a subset of selectors, merging two rules, etc. Once alerts are correlated by a specific responsibility domain of a PEP, it is essential to identify subsets of alerts which can be processed by common set of configured rules. Figure 6.1, shows an example of the application of our enforcement-based alert correlation in countermeasure implementations. We deal with a simple case of a PEP with three configured rules denoted by r 1 , r 2 and r 3 . These rules are represented by the circles having the orange colour in Figure 6.1. The responsibility domain approximation results on an RD(PEP) with two rule vectors: v 1 and v 2 . These rules are represented by the red circles. The set {A 1 , A 2 , A 3 , A 4 , A 5 } represents the correlated alerts. Alerts are represented by green circles. We note that alerts A 1 , A 2 and A 3 were correlated regarding rule vector v 1 . Meanwhile, only A 1 and A 2 can be processed by rule r 1 . Alert A 3 can be processed by r 2 .

RD(PEP)

A 1 A 4 A 5 A 1 A 2 A 2 4 5 A 3 A 4 A 5 v 1 v 2
r 2 r 1 r 3 This distribution result of correlated alerts regarding configured rules can be demonstrated by the coverage metric (CM) for a given alert A and a configured rule r. This metric, denoted by CM(A, r), is evaluated using the function δ(A, r) as defined in Equation 6.7. In the Equation 6.7, A k is a correlated alert with the RD(P EP ) and r p is a configured rule in Conf (P EP ). δ(A k , r p ) =< verif(a k1 , r p1 ), verif(a k2 , r p2 ), . . . , verif(a kn , r pn ) > =< verif(a ki , r pi ) > i∈[1,...,n] verif (a ki , r pi ) is the binary function defined in Equation 5.6 (6.7)

We define CM(A, r) in Equation 6.8.

CM(A k , r p ) = i∈[1...n] δ i (A k ,rp) n (6.8) CM(A k , r p ) is a binary variable.
In the rest of this section, we consider the example of two configured rules r 1 and r 2 whose their responsibility domains is defined as follow:

RD(

Discussion for a single alert

When a single alert A falls in a responsibility domain of a PEP, it is important to identify the appropriate configured rules which will be responsible to process this alert. The function CM(A k , r p ) defined in Equation 6.8 identifies common attributes between the alert and the configured rules. But, in order to implement the countermeasure, it is necessary to evaluate the modifications that should be made on the rule. Therefore, we define the modification rate denoted by M rp/A k in Equation 6.9.

M rp/A k = 1 -CM(A k , r p ) = 1 - i∈[1...n] δ i n (6.9) CM(A k , r p ) ∈ {0, 1} ⇒ M rp/A k ∈ {0, 1}
For example, we evaluate this metric using alert A 2 and rule r 1 .

M r 1 /A 2 = 1 -CM(A 2 , r 1 ) = 1 -4 5 = 1 5
The evaluation of M r 1 /A 2 shows that a modification of the single attribute (the destination port) in the configured rule r 1 allows to handle the alert A 2 .

In practice, it is important to set a modification rate threshold which we denote by T h M . T h M is the acceptance criteria of the modification rate M r 1 /A 2 . If M r 1 /A 2 < T h M , the identified configured rule could be considered in order to process the alert. Otherwise, if M r 1 /A 2 > T h M , the modification rate is unacceptable.

Discussion for two alerts

One of the advantages of our enforcement-based alert correlation is the possibility to identify if countermeasure implementations can be aggregated or not. When dealing with two alerts or more, aggregation of countermeasure implementation is important.

Therefore, we analyze the possibility of aggregating countermeasure implementation by evaluating the differences between the coverage metric for two alerts A 1 and A 2 referring to a single implemented rule r p . We propose the aggregation metric denoted by AM((A 1 , A 2 ), r p ). In Equation 6.10, we define how we can compute this aggregation metric:

AM((A 1 , A 2 ), r p ) = i∈[1...n]
δ(a 1i ,r pi )×δ(a 2i ,r pi ) n (6.10)

× in Equation 6.10 is the multiplication operator of the real set R. Therefore, if alerts can be both entirely processed by the rule r p (which means that δ(a 1i , r pi ) = δ(a 2i , r pi ) = 1, ∀i ∈ [1 . . . n] ), both of the alerts can be aggregated by the rule r p . Otherwise, it is important to set a tolerance threshold which we denote by T h AM . This threshold point out the tolerance of the security administrator in modifying configured rules.

If AM((A 1 , A 2 ), r p ) > T h AM , the identified configured rule could be considered in order to aggregated countermeasure for both og alerts A 1 and A 2 . Otherwise, if AM((A 1 , A 2 ), r p ) < T h M , the aggregation of countermeasure is not desirable. Figure 6.2 represents the workflow described above. When evaluating the aggregation metric of rules with which alerts were correlated, it is possible to have multiple rules that satisfy the condition of T h AM . In this case, the administrator should study the optimal response decision that will be implemented. Such This matter is out of the scope of our work and may require external knowledge.

Interpretation:

Our objective is to assist the security administrator in selecting which rules are potentially able to process a number of correlated alerts. As a consequence, we first provide the security administrator with a distribution of generated alerts based on the configured rules in a PEP. Then, we provide him with an evaluation of the modification rate (countermeasure implementation).

Application of PEACE in multi-PEP scenario

In this section, we analyze the application of our alert correlation approach in a real life use case where multiple PEPs are deployed. We accordingly deal with the Olympic Games security architecture which is composed of several commonly deployed security patterns. We first introduce the Olympic Games use case. We detail its security architecture and the different deployed PEPs and security patterns. Then, we discuss the application of our alert correlation approach on some of these patterns.

Application of PEACE in multi-PEP scenario

Alerts A

Case Study: Olympic Games

Olympic Games IT System is a complex and massive IT architecture deployed by large team of people. Its mission is to provide services and real time information for competitions of around 20 disciplines that span more than 60 competition and non-competition venues, involving more than 10.000 athletes, 20.000 members of the media and 70.000 volunteers. In general, the Olympic Games IT system requires about 10,000 computers, 1,000 servers, 20,000 desktop phones and 2,500 Intranet terminals. Olympic Games case study responds to the needs of improving the IT security of such critical system. This use case discusses the application of PEACE in an environment with multiple deployed PEP belonging to different classes and analyze all possible relationships between RD(P EP ) and their impact on the correlation. In Figure 6.3, we give a simplified overview of the Olympic Games system architecture. It is mainly composed of 3 core systems which are:

• Core Games System (CGS): a set of applications for assisting in the capture and management of data about people who will be attending the Games events and the staff supporting them (such as Volunteers, Electronic Staff Information

Analysis of relationships between multiple PEP Responsibility Domains

An intrusion response decision requires the identification of the PEP(s) that is (are) responsible of implementing appropriate countermeasures. In a complex environ- In this case, dim(I 3,4 ) < dim(min(RD(P EP 3 ), RD(P EP 4 ))).

• RD(P EP 2 ) and RD(P EP 1 ) are totally joint domains , iff

∀j ∈ [1, . . . , n 2 r ] and j ∈ [1, . . . , n 1 r ] and n 2 r < n 1 r such that < d 2 j i > ⊆ < d 1 j i >, ∀i ∈ [1 . . . n] (6.13)
In this case, dim(I 1,2 ) = dim(min(RD(P EP 1 ), RD(P EP 2 ))).

Common deployed security patterns description from Olympic Games use case

The Olympic Security Infrastructure is developed by Atos Company. Its main objective is to protect the IT infrastructure of the Olympic Games systems from any undesired and/or uncontrolled phenomena which can impact any parts of the result chain and associated services.

The SIEM infrastructure of Olympic Games IT system deal with a big challenge which is mainly due to the number of security event types (about 20,000), and the volume of generated events to be handled (around 11,000,000 alerts per day). However, the most critical aspect that a SIEM system faces in the Olympic Games is that those security events must be processed and reacted upon in real-time, [START_REF] Rieke | Security and Reliability Requirements for Advanced Security Event Management[END_REF].

The deployed security infrastructure of the Olympic Games IT system provides the administrators with defence-in-depth. In order to meet the requirements of such system, several PEPs are deployed such as firewalls, active directories, intrusion detection systems, etc. From Figure 6.3, we highlight several security patterns that are commonly used in complex security architecture such as the Olympic Games IT system. We only discuss common patterns based on network firewall technology. We distinguish three different security patterns that are detailed hereafter.

Security Pattern 1

In this security pattern as described in Figure 6.5, the IDS (IDS2) is placed in front of the first firewall (FW2) which is controlling access to the entire CGS. Usually, such IDS placement in the architecture allows the security administrator to inspect all the traffic -unfiltered-passing through the network levels. The internal CGS network is divided in two sub-networks with different criticality. To meet the security requirements of CGS_net1 and CGS_net2, two firewalls, respectively FW2 and FW7 are deployed in serial. Such configuration enforces access control to CGS_net2 which is more critical.

Security Pattern 2

In this security pattern shown in Figure 6.6, the frontal firewall FW2 enforces the security of two different zones: the DMZ and the internal CGS network. Both of firewalls FW7 and FW3 protect these two zones which have different security requirements. Moreover, FW7 and FW3 basically inspect filtered traffic coming from FW2. In such security pattern, the firewall FW2 includes rules with larger responsibility domain than those of FW7 and FW3.

Security Pattern 3

We observe that in the security pattern shown in Figure 6.7, the IDS is placed after the frontal Firewall FW1. Therefore, the inspected traffic is the traffic which has been already filtered by firewall FW1. In this case, the generated alerts correspond to suspicious flow which has been already allowed by the firewall FW1.

Application of Enforcement-based Alert Correlation on multi-PEPs environment: Discussions and analysis

In the following, we represent the set of generated alerts by A. A 1 and A 2 represent respectively the set of generated alerts by IDS 1 and IDS 2 respectively listed in pattern 3 and both of patterns 1 and 2. We discuss in this part the impact of the relationships between the responsibility domains of multiple PEPs and the IDS placement on our alert correlation approach. Due to the non-disclosure of PEPs configurations and generated alerts, we maintain representing the responsibility domains of PEP and the set of generated alerts by abstract circles. As explained before, these circles are an abstract representation of multi-dimensional domains.

First pattern: discussion and analysis

As we explained before, in the first pattern, the IDS 2 is placed before the frontend firewall F W 2 . As a consequence, the set of generated alerts A 2 corresponds to suspicious unfiltered traffic. Thus, A 2 set includes in our case vectors of both RD(F W 2 ) and RD(F W 7 ). Since the front-end firewall F W 2 inspects global traffic, it is responsible of applying rules related to wide value range of selectors. This explains the dimension of RD(F W 2 ) which covers an area almost equal to the network perimeter. The F W 7 inspects traffic related to specific traffic destined to a reduced zone in the supervised network. Thus, the implemented rules in F W 7 covers specific ranges of values for corresponding selectors. Therefore, the dimension of RD(F W 7 ) is much less than the network perimeter and RD(F W 2 ).

Enforcement-based Alert Correlation Advantages :

-Since the set of generated alerts A 2 are correlated based on RD(F W 2 ) and RD(F W 7 ), it then becomes straightforward to process these alerts. In fact, we easily identify the firewall that will be able to process generated alerts and implement corresponding countermeasures.

-Based on the first pattern, our alert correlation approach allows setting a defensein-depth strategy. The set I 2,7 enable us correlating alerts that can be processed by both firewalls RD(F W 2 ) and RD(F W 7 ). In such case, the security administrator can decide to enforce the intrusion response decision using both of the deployed firewalls.

Enforcement-based Alert Correlation Disadvantages :

-Since our alert correlation approach closely depends on the approximation of the firewalls and then their configurations, it is possible that some generated alerts will not be correlated. This set of alerts requires more investigation. In fact, ignoring the default rule deployed in the firewall and the topology knowledge leads to a subestimation of the responsibility domain of the firewall. As demonstrated in Chapter 4, this sub-estimation depends on the approximation accuracy of the responsibility domain. As we explained before, the second pattern differs from the first pattern by the existing of the DMZ zone which is protected by a third firewall F W 3 . In general, DMZ zone is composed of servers running critical publicly accessible services. As a consequence and in order to enforce the security of these services, the traffic destined to servers in DMZ zone is checked twice. Therefore, the RD(F W 3 ) is totally joint to the RD(F W 2 ). In such case, attacks against the DMZ zone servers can be mitigated either by the frontal firewall F W 2 , or by the DMZ firewall F W 3 , or when necessary by both of them. In terms of enforcement-based alert correlation, the totally joint relations between RD(F W 3 ) and RD(F W 2 ) induces that all the alerts which are correlated based on RD(F W 3 ) are immediately correlated based on RD(F W 2 ). In fact, in this case, we have I 2,3 = RD(F W 3 ).

Enforcement-based Alert Correlation advantages :

-Despite ignoring the network topology, we demonstrate the utility and applicability of our approach in the third pattern. In such case, our enforcement-based alert correlation supports the selection of proper PEP that are capable to process generated alerts.

Enforcement-based Alert Correlation disadvantages :

-Some of the correlated alerts based on the set I 2,3 cannot be effectively processed by the DMZ firewall F W 3 . In fact, it is possible that some of these alerts have to be only processed by the frontal firewall F W 2 . An important recommendation in this case is to first mitigate the attacks at the level of the frontal firewall. Then, investigations on countermeasures implementation have to be achieved in order to decide enforcing the policy at the DMZ firewall. As described before, in the third pattern, the IDS control filtered traffic by the firewall F W 1 . As a consequence, the set of the generated alerts A 1 is included in the responsibility domain of the frontal firewall F W 1 . Obviously, all the generated alerts are correlated based on RD(F W 1 ). Meanwhile, our enforcement-based alert correlation supports the administrator in identifying alerts that can be processed by the internal firewall F W 6 .

Role of enforcement-based alert correlation in countermeasure implementations in a multi-PEP environment

Based on the analysis of the different pattern listed above, we conclude that the role of our enforcement-based alert correlation approach in countermeasure implementations in a multi-PEP environment is a optimisation problem. In fact, in a multi-PEP environment, alerts should be correlated while optimising the countermeasure implementation. In a real case scenario like the olympic games use case, we deal with multiple alerts and several deployed PEP that are responsible of enforcing the policy in order to mitigate detected attacks.

In such context, alert correlation should minimize the cost of implementing response decision. This cost covers the different modifications that should be brought to the security policy in order to process with generated alerts. Mainly, this cost represents the number of configuration modifications resulting of countermeasure implementations. For instance, modifying PEP's configuration is a challenging task for several reasons: i) it is critical task to cope with because of related aspects such as conflict ii) it requires an in-depth analysis iii) it can be time consuming, etc. As a consequence, aggregate different countermeasures in order to process a number of alerts is a prominent solution. Hence, our enforcement-based alert correlation is able to support the security administrator in aggregating countermeasures in a multi-PEP environment.

Usually, we have:

A = {A 1 ,
)) = {A ec 1 , A ec 2 , . . . , A ec n a ec } = A ec (6.14)
We model our maximisation problem as indicated in Equation 6.15:

argmax(AM(A ec , RD inf (PEP)))) = {∀ A ec j | ∃ P EP k ∈ PEP : AM(A ec j , P EP k ) ≈ T h AM } (6.15)
AM(A ec , RD inf (PEP))) represents the overall aggregation metric of correlated alerts. It follows the definition of the function expressed in Equation 6.10. RD inf (PEP) is the set of the configurations of PEPs in PEP.

Our optimisation problem aims at correlating alerts while ensuring an optimal rate of countermeasure modifications while processing simultaneously a common group of correlated alerts.

Discussions and conclusion

This chapter presents the application of the enforcement-based alert correlation in a single-PEP environment and multi-PEP environment. Our approach is not only efficient to determine and select the PEP that is capable to process a group of correlated alerts. But also, it allows the identification of the configured rules that should be modified in order to implement a countermeasure. It allows the aggregation of response decision implementation. As detailed in Chapter 2, most of the existing alert correlation techniques are able to support the administrator in response decision by making the number of generated alerts manageable. These approaches are based on the alert's content independent from the environment. Model-based approach developed in [START_REF] Morin | M2D2: A formal data model for ids alert correlation[END_REF][START_REF] Morin | M4D4: a Logical Framework to Support Alert Correlation in Intrusion Detection[END_REF] is the only correlation method dealing with information about the supervised information system. However, it does not make easier the 6.5. Discussions and conclusion response decision process. The advantage of our approach, comparing it to existing approaches, is the identification of PEP capable to process correlated alerts. Moreover, it allows the selection of appropriate configured rules that should be modified in order to implement countermeasures. We provided an in-depth analysis of our correlation's role in response decision implementation. However, since we do not take into account the access control decision (axiom 3 in Chapter 4) when building the PEP's approximations, our approach is efficient in the sense that it allows the administrator to identify rules to be modified.

In order to decide about the modification of the identified rule's decision, external knowledge, such as the attack impact and the vulnerability, is required. In this dissertation, we suppose that such knowledge is not available. Therefore, we do not deeply examine the impact of the PEP's enforced access control decisions on the role of our enforcement-based alert correlation in response decision.

• Honeypot-based alert correlation (Chapter 3): This approach leverages the honeypot datasets in order to enhance alert correlation with knowledge about 'attackers'; • Enforcement-based alert correlation (Chapter 5): This approach deploys the knowledge about policy enforcement capabilities of the supervised network in order to enhance alert correlation with knowledge about the 'defender'.

Contributions

Honeypot-based alert correlation

The first proposed approach is related to the use of honeypot datasets in alert correlation as shown in Figure 7.1. In response to Objective 1, we have shown the usability

Honeypot-based alert correlation

Honeypot datasets generated alerts correlated alerts of information gathered through honeypots in improving alert's related information. This information includes more details about the attacker such as his behavior, his propagation vector, his location, etc. As shown in Figure 7.1, the honeypot-based alert correlation explores the honeypot datasets in order to correlate the generated alerts.

We propose an alert enrichment process that allows the collection of appropriate information related to the locally generated alerts. This enrichment process is mainly based on enrichment selectors such us the ip source of the alert and its classification. We propose three filtering processes in order to increase the accuracy of alert's related knowledge. The designed filters are: temporal, semantic and configuration filters.

Our experiments were conducted on four honeypot-datasets. Experimental results allow us identifying honeypots' limitations. These limitations avoid improving alert's related information and enhancing alert correlation. We identified four major limitations that are:

• coverage limitation: It prevents alert correlation from efficiently study the causality link between alerts and then correlate alerts; These limitations were an impediment for our honeypot-based alert correlaion. It would be preferable if the honeypot datasets include better quality of data. However, honeypots are still evolutionary and are being ameliorated to cover additional security application. But, in the context of our honeypot-based alert correlation, concise and complete information is required in order to enhance our knowledge about the information related to the alert.

Enforcement-based alert correlation

The second proposed approach is related to the use of policy enforcement capabilities in alert correlation as shown in Figure 7. responsibility domain of deployed PEP in order to correlate generated alerts. In this context, we first propose to model these capabilities referring to a proposed PEP model detailed in Chapter 4. We design a PEP model which illustrates the PEP's responsibility domain. Since the responsibility domain of the PEP is an abstraction of its capabilities in enforcing the security policy, we propose to approximate it by setting up to main approximations which are the rule-based approximations and the selector-based approximation. We study the coverage relationships between the different proposed approximations. The advantage of our methodology to approximate RD(P EP ) is the performance in a 'blind manner'. Also, the consideration of the PEP configuration makes the approximations more useful for response decision. However, it would be possible if we consider the external knowledge in order to build the approximations following a top down approach.

CHAPT 7. CONCLUSIONS AND PERSPECTIVES

We investigate the application of the proposed PEP model in correlating alerts. Thus, we detail the correlation approach based on this model in Chapter 5. Two applications has been analyzed: a single-PEP and a multi-PEP environment in Chapter 6. We propose the role of this approach in response decision support. We provided an in-depth analysis of our correlation's role in response decision implementation. However, since we do not take into account the access control decision when building the PEP's approximations, our approach is efficient in the sense that it allows the administrator to identify rules to be modified.

Perspectives

Perspectives

The final section of this dissertation opens new areas of research showing problems that remain unsolved and which can be addressed in future works: The generalization function defined in this case could be the choice of a higher level for a specific selector.

Select appropriate responsibility domain approximation

Define criteria and metrics which allow the identification of the appropriate approximation function to be applied. The proposed coverage increases metric allows evaluating the differences between approximations independent of the context. Since our proposed Responsibility Domain approximations are built following a bottom up approach, it is possible that the security administrator prefer one approximation rather than another based on the configuration and its coverage. However, expert knowledge is required in order to decide about the appropriate approximation. Thus including external knowledge such as network topology and routing information and analyze its impact on the proposed enforcement-based alert correlation approach. Using such external knowledge, the responsibility domain approximations can be built following a top down approach.

Identification of countermeasure implementations

Develop a methodology which automatically identifies the countermeasure to be implemented in order to process correlated alerts. We studied the role of the enforcement-based alert correlation in response decision support. We point out that it supports the security administrator in identifying configured rules that should be modified or should be configured. We also demonstrate how our proposed alert correlation can be considered as an optimization problem as defined in Section 6.4.5:

argmax(AM(A ec , RD inf (PEP)))) = {∀ A ec j | ∃ P EP k ∈ PEP : AM(A ec j , P EP k ) ≈ T h AM }
This optimization system allow us identifying the PEPs with a minimum modifications that should be brought to the configuration in order to process correlated alerts. However, since we ignore the access control decision applied by the PEP when enforcing security policy, our approach does not allow the identification of the concrete countermeasure implementation.

List of Figures

Glossary of Terms

Attack An attempt to gain unauthorized access to system services, resources, or information, or an attempt to compromise system integrity.

Botnet

A number of Internet computers that, although their owners are most time unaware of it, have been set up to forward transmissions (including spam or viruses) to other computers on the Internet. Countermeasure Actions, devices, procedures, or techniques that meet or oppose (i.e., counters) a threat, a vulnerability, or an attack by eliminating or preventing it, by minimizing the harm it can cause, or by discovering and reporting it so that corrective action can be taken.

Denial of Service

An attempt against the availability of a particular system. The main objective is to disrupt service and network availability by attempting to reduce a legitimate user's bandwidth, or preventing access to service or system.

Honey-pot

Systems or accounts used to lure the intruder into pursuing a decoy controlled environment directly of his own volition. Honey-pots are placed near assets requiring protection, are made attractive, and are fully instrumented for intrusion detection and back tracking.

Host-based intrusion detection system (HIDS)

IDSs which operate on information collected from within an individual computer system. This vantage point allows host-based IDSs to determine exactly which processes and user accounts are involved in a particular attack on the Operating System.

GLOSSARY OF TERMS

Infectious threats

It corresponds to viruses, worms, trojan horses and other similar threats.

Intrusion detection system (IDS)

Hardware or software product that gathers and analyzes information from various areas within a computer or a network to identify possible security breaches, which include both intrusions (attacks from outside the organizations) and misuse (attacks from within the organizations.)

Intrusion

prevention systemv(IPS)

Systems which can detect an intrusive activity and can also attempt to stop the activity, ideally before it reaches its targets.

Network-based intrusion detection systems (NIDS)

IDSs which detect attacks by capturing and analyzing network packets.

Policy Enforcement Point

Logical entity or place on a server that enforces policies for admission control and decisions in response to a request from a user wanting to access a resource on a computer or network server.

Risk

The level of impact on organizational operations (e.g., functions, image, or reputation), organizational assets, or individuals resulting from the operation of an information system given the potential impact of a threat and the likelihood of such threat occurring.

Security Policy

A set of criteria for the provision of security services. It defines and constrains the activities of a data processing facility in order to maintain a condition of security for systems and data.

Dans cette thèse, nous proposons deux approches différentes de corrélation d'alertes permettant d'avoir un diagnostic plus précis des alertes générées par les SIEMs. La première approche est basée sur les pots de miel. Son objectif est d'améliorer le contenu des alertes en exploitant la connaissance collectée par les pots de miels sur les attaquants. La deuxième approche est basée sur l'application de la politique de sécurité. Son objectif est de prendre en compte les moyens de mise en application de la politique de sécurité implémentés dans le réseau en corrélant les alertes. Énoncé de la problématique :

Les systèmes pour la Sécurité de l'Information et la Gestion des Evénements (SIEM) doivent traiter un nombre très important d'évènements de sécurité sans avoir la connaissance suffisante sur l'attaquant ni sur les moyens de défense.

Énoncé de la thèse:

L'évaluation de l'impact d'une attaque ainsi que l'aide à la décision prenant en compte la contremesure exigent une meilleure connaissance de l'attaquant ainsi que les moyens de défense déployés au sein du réseau. Améliorer notre connaissance sur l'attaquant nous permet de mieux comprendre les alertes. Identifier les moyens d'application de la politique de sécurité contribue à une décision de réponse plus efficace aux attaques.

Les objectifs de cette thèse sont:

• Objectif 1 : la conception et l'expérimentation d'une nouvelle méthodologie de corrélation d'alertes qui bénéficie d'informations collectées par les pots de miel;

• Objectif 2 : la conception et l'étude d'une méthodologie de corrélation d'alertes basée sur le modèle de domaine de responsabilité d'un PEP proposé;

• Objectif 3 : l'application des approches de corrélation proposées sur un cas d'étude de cas pratique.

A.1 État de l'art

Dans cette partie, nous passons en revue les travaux de recherche sur la sécurité des réseaux qui sont liés à nos approches développées dans cette thèse. Nous introduisons d'abords la notion de l'application de la politique de sécurité dans la sectionA. A.1.1 Application de la politique de sécurité L'application de la politique de sécurité est la mise en place et configuration des mécanismes de contrôle d'accès à travers la mise en place et la mise à jour des configurations des PEPs. Ces éléments de sécurité sont généralement déployés à des endroits critiques du réseau. Le terme PEP a été introduit au départ (cf. XACML [START_REF]eXtensible Access Control Markup Language (XACML)[END_REF]) comme une entité capable d'effectuer un contrôle d'accès en appliquant des décisions sur les requêtes. En se référant à la dernière version du [START_REF]eXtensible Access Control Markup Language (XACML)[END_REF], un PEP est présenté sous plusieurs formes. Il peut être une passerelle d'accès à distance, un serveur web ou un agent de boîtes à courrier électronique, etc. Plusieurs définitions du PEP ont été données [START_REF] Zaborovsky | Access Control Model and Algebra of Firewall Rules[END_REF][START_REF] Boutaba | Towards extensible policy enforcement points[END_REF][START_REF] Hamed | Taxonomy of conflicts in network security policies[END_REF][START_REF] Betarte | ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies[END_REF]. Nous pouvons conclure qu'un PEP peut être présenté sous la forme d'un produit dédié (comme par exemple les pare feux, les systèmes de détection d'intrusions, etc) ou d'un module intégré (par [19]. Généralement, les IDS génèrent des alertes lorsqu'ils détectent une attaque. Dans la littérature, nous pouvons trouver plusieurs approches de systèmes de détection d'intrusions. Plusieurs taxonomies ont été proposées [START_REF] Denning | An Intrusion-Detection Model[END_REF][20][START_REF] Mukherjee | Network intrusion detection[END_REF][START_REF] Debar | Towards a taxonomy of intrusiondetection systems[END_REF][START_REF] Krügel | A survey on intrusion detection systems[END_REF][START_REF] Debar | A revised taxonomy for intrusion detection systems[END_REF][START_REF] Mukkamala | A comparative study of techniques for intrusion detection[END_REF][START_REF] Estevez-Tapiador | Anomaly detection methods in wired networks: a survey and taxonomy[END_REF][START_REF] Mishra | Intrusion detection in wireless ad hoc networks[END_REF][START_REF] Delgado | A taxonomy and catalog of runtime software-fault monitoring tools[END_REF][START_REF] Kabiri | Research on intrusion detection and response: A survey[END_REF][START_REF] Patcha | An overview of anomaly detection techniques: Existing solutions and latest technological trends[END_REF][START_REF] Garcia-Teodoro | Anomaly-based network intrusion detection: Techniques, systems and challenges[END_REF][START_REF] Xie | Anomaly detection in wireless sensor networks: A survey[END_REF]. La classification des IDS est conditionnée par le mécanisme de détection utilisé, le comportement lors de la détection, la nature de l'information analysée, etc. Malgré les différents avantages que les IDS ont, ces derniers souffrent de quelques limitations à savoir le format des alertes générées, le taux de faux positifs, les alertes dupliquées et l'aspect incomplet des informations contenues dans les alertes. De nos jours, avec l'expansion des réseaux, une des limitations qui s'avère critique est l'augmentation du volume d'alertes générées.

A.1.3 Les pots de miel

Un pot de miel est un environnement où des vulnérabilités ont été délibéremment introduites pour attirer les attaquants et par la suite étudier leurs comportements [START_REF] Dagon | HoneyStat: Local Worm Detection Using Honeypots[END_REF][START_REF] Pouget | Honeypot-based Forensics[END_REF]. Ces environnements intéragissent avec l'attaquant de différentes manières.

Il existe des pots de miels avec une interaction minimale. Ces pots de miel imitent un service de base. Il existe aussi des pots de miel avec une interaction moyenne. Ils sont plus sophistiqués que la première catégorie. Ces pots de miel sont capable • Processus d'enrichissement d'alerte: L'objectif de cette étape est l'enrichissement du contenu des alertes générées localement par l'information sur l'attaquant. Le résultat de cette étape est une alerte enrichie notée Er_alert. Cette étape sera détaillée dans la section A.2.3; • Analyse de l'alerte enrichie (Er_Alert): À cette étape, le contenu de l'alerte enrichie Er_alert est analysé dans le but de ré-évaluer la sévérité de l'attaque, son impact et l'objectif de l'intrusion. • Corrélation des alertes enrichies: Cette étape a pour objectif la corrélation des rapport à un objet spécifique dans d'autres base de données. Dans le cadre de notre approche de corrélation et d'enrichissement d'alertes basée sur les pots de miel, il est nécessaire que nous profitions d'une vue complète et globale des phénomènes d'attaques telles que les serveurs infectés, l'évolution de leur sécurité au cours du temps, la caractérisation et la spécificité des exploits. Ces limitations présentent un blocage pour mieux explorer l'usage des pots de miels dans la corrélation d'alertes. Ainsi, nous développons dans la suite une nouvelle approche de corrélation d'alertes qui est basée sur l'application de la politique de sécurité.

A.3 Modèle de point d'application de politique (PEP)

Les approches de corrélation d'alertes existantes telles que [50, 71, 73-75, 78-80, 82] fonctionnent indépendamment des capacités d'application de politique de sécurité déployées dans le réseau. Cela est dû à l'absence d'un modèle unifié de points d'application de politique (PEP). Les PEPs, une fois déployés et configurés, sont responsables d'appliquer des règles sur des flux réseau spécifiques. Comme les décisions de réponses aux intrusions et les contre-mesures sont généralement des modifications qui doivent être apportées à la configuration de ces PEPs, il est important d'identifier facilement le PEP approprié. Si les alertes sont corrélées en se basant sur les capacités du PEP, leur traitement serait plus efficace. Dans cette section, nous détaillons le modèle du PEP que nous proposons. Ce modèle nous permet non seulement d'avoir une bonne compréhension des capacités d'application de politique déployé dans le réseau mais également d'apporter d'autres solutions aux problèmes de gestion de politique de sécurité et de détection d'intrusion.

A.3.1 Définitions et axiomes

Le PEP est une entité de sécurité capable d'appliquer sur les requêtes les décisions d'application de politique représentées par {d 1 , d 2 , d 3 , . . . , d p } (p est le nombre total de toutes les décisions qui peuvent être appliquées par le PEP). Le PEP est un ensemble de règles désignées par r 1 , r 2 , . . . , r m (m est le nombre total de règles appliquées par le PEP). Ci-dessous nous donnons une représentation algébrique caractérisant un PEP:

P EP = {r j } j∈[1...m]
Comme définie dans les modèles de contrôle d'accès [START_REF] Zaborovsky | Access Control Model and Algebra of Firewall Rules[END_REF][START_REF] Betarte | ACTkit: A Framework for the Definition and Enforcement of Role, Content and Context-based Access Control Policies[END_REF][START_REF] El Kalam | Organization Based Access Control[END_REF][START_REF] Samarati | Access Control: Policies, Models, and Mechanisms[END_REF][START_REF] Sandhu | Role-Based Access Control Models[END_REF][START_REF] Garcia Alfaro | MIRAGE: a management tool for the analysis and deployment of network security policies[END_REF], une règle de contrôle d'accès r j s'écrit généralement sous la forme suivante: La première approximation basée sur les règles RD rb_apprx 1 (P EP ) est le résultat de l'application de la fonction rb(RD inf ) sur tout les vecteurs du domaine RD inf (P EP ).

r j : {conditions} j -→

sb() :

U -→ U RD inf (P EP ) -→ RD sb_apprx 1 (P EP ) La première approximation basée sur les sélecteurs RD sb_apprx 1 (P EP ) est le résultat de l'application de la fonction sb(RD inf ) sur tout les vecteurs du domaine RD inf (P EP ).

gen() :

U -→ U < s j , j ∈ [1 . . . n] > -→< δ k j , j ∈ [1 . . . n] > La fonction gen() fait référence à un processus de généralisation des valeurs de sélecteurs suivant une décomposition de leurs domaines. Pour chaque valeur d'un sélecteur s j , gen() identifies une plage plus générique de la valeur s j .

PEACE Policy Enforcement-based

Alert Correlation Engine Les fonctions d'alignement montrées dans les deux figures A.5 et A.6 sont responsable d'alignement de format des alertes avec les domaines de responsabilité des PEPs. Dans l'option 1, ces fonctions d'alignement procèdent à l'alignement des alertes (écrites en IDMEF) avec chaque classe de PEP. Dans l'option 1, ces fonctions d'alignement procèdent à l'alignement de tous les domaines de responsabilité avec le même format des alertes qui est IDMEF. Les alertes sont corrélées selon les valeurs des sélecteurs généralisées -L'ensemble des alertes corrélées dépend de la partition des valeurs configurées des sélecteurs Dans le cas de plusieurs PEPs mis en place, nous avons conclus que dans un tel environnement, la corrélation est considérée comme un problème d'optimisation. En effet, les alertes doivent être corrélées tout en optimisant l'implémentation des contremesures. Dans ce contexte, la corrélation d'alertes doit minimiser le coût d'implémentation de la décision de réponse aux intrusions. Ce coût couvre les différentes modifications qui doivent être apportées à la politique de sécurité. Dans ce contexte, des travaux de sélections de contremesures ont été développés comme [START_REF] Granadillo | Individual Countermeasure Selection based on the Return On Response Investment Index[END_REF][START_REF] Granadillo | Combination Approach to Select Optimal Countermeasures based on the RORI Index[END_REF] A.5 Conclusions et travaux futurs L'objectif de cette thèse est de développer de nouvelles techniques de corrélation d'alertes pour aider le responsable de la sécurité des systèmes d'information (RSSI) dans le traitement du nombre très important des alertes générées. Deux approches de corrélation ont été développées:

• Corrélation d'alertes basée sur les pots de miel (Chapitre 3): Cette approche exploite les bases de données des pots de miel pour améliorer la corrélation d'alertes par la connaissance sur l'attaquant. Nos expériences ont été réalisées en se basant sur quatre bases de données de pots de miel. Elles nous ont permis d'identifier quatre limitations majeures pour améliorer la corrélation d'alertes; • Corrélation d'alertes basée sur l'application de politique (Chapitre 5): Cette approche exploite la connaissance sur les capacités de l'application de politique pour améliorer la corrélation d'alertes avec la connaissance sur la contremesure. Nous avons étudié l'application de cette approche sur des environnements à un seul PEP et à plusieurs PEPs. Cette étude a montré que cette approche joue un rôle dans l'implémentation de contremesures.

La première approche a contribué à l'identification des limites des pots de miel existants dans l'amélioration de la corrélation d'alertes. La deuxième approche a contribué à la démonstration de l'applicabilité des capacités de l'application de politique de sécurité mise en place dans le réseau dans la corrélation des alertes. Nous avons étudié l'application de l'approche sur des motifs d'architecture de sécurité qui sont communs à tout les réseaux étendus.

Les travaux futurs se concentreront à considérer d'autres types de PEPs, sélectionner l'approximation du domaine de responsabilité le plus approprié et identifier l'implémentation des contremesures.

1 CHAPTFigure 1 . 1 -

 111 Figure 1.1 -Core principles of computer security: Confidentiality, Integrity, Availability (C, I, A).

Figure 2 . 2 -

 22 Figure 2.2 -Basic intrusion detection system architecture, source [19]. It represents the main components of an IDS that are: a sensor, an analyzer, a response module, and a repository

Figure 2 . 3 -

 23 Figure 2.3 -Intrusion Detection taxonomy, source[START_REF] Debar | A revised taxonomy for intrusion detection systems[END_REF]. The categorization depends on the detection method, behavior on detection, detection paradigm, usage frequency.

Figure 2 . 4 -

 24 Figure 2.4 -IDMEF Alert model. It is composed of two major classes that are the alert class and the heartbeat class. The alert class includes information about the detected attack. The heartbeat class indicates information about the current analyzer's status to managers

Figure 3 . 1 -

 31 Figure 3.1 -Honeypot-based alert correlation workflow.

Figure 3 . 2 -

 32 Figure 3.2 -Alert Enrichment Process.

Figure 3 . 3 -

 33 Figure 3.3 -Filtering Processes.

Figure 4 . 1 -

 41 Figure 4.1 -Example of src/dst_ip selector taxonomy.

Figure 4 . 2 -

 42 Figure 4.2 -Example of src/dst_port selector taxonomy.

3 ]

 3 δ k (src/dst_port) = [0 . . . 1023] ∪ [1024 . . . 49151] ∪[49152 . . . 65535] (4.5)

Figure 4 . 3 -Figure 4 . 4 -

 4344 Figure 4.3 -Combinability between two selectors D(S 1 ) and D(S 2 ).

  .5. It represents a network with two zones (D1 and D2) connected to the Internet and protected by a F irewall.

Figure 4 . 5 -

 45 Figure 4.5 -Running Example: a network with two zones.

4. 4 .

 4 Running Example

Definition 2

 2 Responsibility Domain of a rule : It represents the Applicability Domain of the rule. It is the count of all the instantiated selectors combinations. It is based on the set of C i configured for each Selector of the PEP.

4 . 11 )( 4 . 12 )

 411412 Example Consider the following rule of a Network-level Firewall: r : src_ip = 140.192.37. * ∧src_port = * ∧ dst_ip = 161.120.33.40 ∧ dst_ip = 80 ∧ protocol = tcp → deny Its corresponding Responsibility Domain is: RD(r) =< 140.192.37. * , * , 161.120.33.40, 80, tcp > (4.13) and the coverage of RD(r) is: | RD(r) | =| 140.192.37. * |, | * |, | 161.120.33.40 |, | 80 |, | tcp |> = (2 8 -1) × (2 16 -1) × 1 × 1 × 1 (4.14) 4.6. Responsibility Domain (RD) of a PEP's rule RD(r)

Figure 4 . 7 -Definition 4 Following Definition 4 ,

 4744 Figure 4.7 -Relations between Responsibility Domains of two rules.

Figure 4 . 8 -

 48 Figure 4.8 -Overview of Responsibility Domain Approximations.

Figure 4 .

 4 Figure 4.8 represents an overview of the different steps and approximation functions.

8 :R 9 : 11 :

 8911 ← verif yR(RD(r i ), RD(r k )) if R = IM (RD(r k ), RD(r i )) & SCombinability(s j , j ∈ [1 . . . n]) = true then 10: RD(r k ) ← RD(r i ) else if R = P M (RD(r k ), RD(r i )) & SCombinability(s j , j ∈ [1 . . . n]) = true then 12:

D sb_apprx 1

 1 (src_ip) = {140.192.37. * , * . * . * . * } D sb_apprx 1 (dst_ip) = {161.120.33. * , * . * . * . * } D sb_apprx 1 (dst_port) = {21, 53, 80, * } D sb_apprx 1 (p) = {tcp, udp}

Figure 4 . 9 -

 49 Figure 4.9 -Relationships between the proposed approximations.

Figure 4 . 10 -

 410 Figure 4.10 -LAMBDA attack description: an example [76].

Contents 5 . 1

 51 Definition and Framework Description . . . . . . . . . . . . . . . 77 5.1.1 Definition and Objectives . . . . . . . . . . . . . . . . . 77 5.1.2 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.2 Alignment Functions . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.2.1 1 st option: From IDMEF to PEP class . . . . . . . . . . 82 5.2.2 2 nd option: from PEP class to IDMEF . . . . . . . . . . 84 5.2.3 Comparison between alignment options . . . . . . . . . . 84 5.3 Membership function: Alert ∈ RD(PEP) . . . . . . . . . . . . . 85 5.4 Enforcement-based alert correlation workflow . . . . . . . . . . . 86 5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3 .

 3 Tables 5.1 and 5.2 and 5.3 allows to align the IDMEF attributes and PEP selectors. In IDMEF standard, Source and Target classes contain respectively information about the possible source(s) and target(s) of the event(s) that generated an alert. Since Source and Target have almost the same aggregation classes and attributes, we restrict our comparison in Tables 5.1, 5.2 and 5.3 on the Source class.

Figure 5 . 2 -

 52 Figure 5.2 -PEACE Framework with alignment function option 2.

Figure 5 . 3 .Figure 5 . 3 -

 5353 Figure 5.3 -Alignment Function: 1 st option.

Figure 5 . 4 -

 54 Figure 5.4 -Alignment Function: 2 nd option.

5. 3 .

 3 Membership function: Alert ∈ RD(PEP)

Figure 5 . 5 -

 55 Figure 5.5 -Enforcement-based alert correlation workflow with one alert A.

Figure 6 . 1 -

 61 Figure 6.1 -Enforcement-based alert correlation and countermeasure implementation.

(

  ESI) system, etc). • Information Diffusion System (INFO): a set of applications that retrieve and distribute information related to, and supporting, of the Games. The information is provided by different sources e.g. Results system, interfaces with CGS, Weather provider etc. The information is processed and distributed to internal clients e.g. broadcasters, journalists, etc. It is also sent to external clients e.g. World News Press Agencies (WNPA), sports federations and governing bodies, and Internet Service Providers (ISPs). • Results System (RS): a set of applications for collecting real-time data during competitions (Timing & Scoring Systems) and distributing collected information to the INFO system (On Venue Results Systems).

Figure 6 . 3 -

 63 Figure 6.3 -Overview of Olympic Games System Architecture.

Figure 6 . 5 - 1 Figure 6 . 6 -

 65166 Figure 6.5 -First security architecture pattern: Pattern 1

Figure 6 . 7 -

 67 Figure 6.7 -Third security architecture pattern: Pattern 3.

6. 4 .Figure 6 . 8 -

 468 Figure 6.8 -Relationships between RD(PEP) deployed in pattern 1

6. 4 . 4 . 2 Figure 6 . 9 -

 44269 Figure 6.9 -Relationships between RD(PEP) deployed in pattern 2

Figure 6 . 10 -

 610 Figure 6.10 -Relationships between RD(PEP) deployed in pattern 3

Figure 7 . 1 -

 71 Figure 7.1 -Honeypot-based alert correlation.

7. 1 .

 1 Contributions• unfilled attributes and references limitations: It impacts the overall quality of our honeypot-based alert correlation by making challenging the collection of additional information; • lack of standard representation of data: It avoids the design of inference rules in order to facilitate the causality analysis between local and global events.; • cross-references limitation: It avoids cooperation between different honeypot datasets.

2 ,Figure 7 . 2 -

 272 Figure 7.2 -Enforcement-based alert correlation.

Figure 7 . 3 -

 73 Figure 7.3 -LDAP tree decomposition.

  qui s'appuie sur les PEPs déployés dans le réseau. Nous détaillons les contributions de cette thèse comme suit: • Identification des données appropriées fournies par les pots de miel afin d'enrichir nos connaissances sur les alertes générées (Objectif 1); • Conception d'un processus d'enrichissement d'alertes qui améliore, de façon adéquate, l'information relevée dans les alertes générées (Objectif 1); • Identification des limitations des pots de miel quant à la corrélation d'alertes (Objectif 1); • Conception d'un modèle de PEP illustrant le rôle d'un PEP dans un processus de décision prenant en compte la contremesure. Notre modèle est basé sur la notion de domaine de responsabilité d'un PEP (Objectif 2); • Développement d'une approche de corrélation d'alertes basée sur l'application de la notion de domaine de responsabilité d'un PEP (Objectif 2) et l'analyse de son application sur les architectures de sécurité couramment déployées dans un réseau. (Objectif 3).

Figure A. 1 -

 1 Figure A.1 -Architecture basique d'un système de détection d'intrusions selon [19].

Figure A. 2 -

 2 Figure A.2 -Processus de corrélation d'alertes basée sur les pots de miel.

Figure A. 4 -

 4 Figure A.4 -Vue d'ensemble des approximations du domaine de responsabilité.

Figure A. 6 -

 6 Figure A.6 -Structure de PEACE avec fonction d'alignement option 2.

Table 2 . 1 -

 21 Honeypot interaction levels. These levels that are lowinteraction, high-interaction and medium-interaction are represented in the raw of the table.

	Interaction level	Advantages Disadvantages	Examples	Collected In-formation
			-emulate specific
	Low-interaction honeypot	-implementa-simple tion -easy to use and maintain -low risk of penetration	services -lower interaction performance -no real interaction -limited scope of at-tacker's activity -detection of known attacks -detectable by ad-vanced attackers -capture only activ-ity that directly in-	Specter [65], Hon-eyD [57]	-limited to the level of emula-tion -time and date of the attack -protocol -source and des-tination IP ad-dress -source and des-tination ports
			teract with them
			-complex implemen-
		-full imple-	tation and maintain-		-	information
	High-interaction honeypot	mentation of an Operat-ing System -real inter-action with	ing -time-consuming to design -increased risk -capture only activ-	Honeynet [66], Ar-gos [61], Minos [63]	about attacker's haviour -possible infor-the be-mation about
		attacker	ity that directly in-		zero-day attacks
			teract with them
		-simulated
	Medium-interaction honeypot	services are more com-plicated -low risk of penetration -better interaction	-do not emulate a complete real Oper-ating System -capture only activ-ity that directly in-teract with them	nepenthes [58], mw-collect [67], honey-trap [68], SGNET [59]	-about information more complex attacks such as bot-nets, multi-step attacks, etc.
		performance

  .2, we summarize the advantages and drawbacks of each alert correlation method. Alert correlation methods are listed in the raws of Table2.2. Advantages and drawbacks are respectively listed in the second and third columns. We remind some examples of correlation technique developed in the literature in the last column of the table. In[START_REF] Mora-Gimeno | Security Alert Correlation Using Growing Neural Gas[END_REF], authors show that the combination of different alert correlation methods is beneficial for effective alert correlation. For instance, similarity-based correlation method could be improved by the knowledge-based correlation method, since this latter are able to correlate alerts based on their causality link.

	Table 2.2 -Advantages and drawbacks of alert correlation methods
	represented in the table's lines.
	Alert tion method correla-	Pros	Cons	Examples
	Similarity-based alert correlation	-easy to implement -no need for exter-nal knowledge	-unable to discover causality link between alerts	Probabilistic Alert Correla-tion [73]
		-alerts are corre-	-complex implemen-
		lated based on their	tation and maintain-	Managing
	Rule-based alert correlation	pre-defined causality link -dynamic attack	ing of inference rule -time-consuming to design inference rules	alerts in a multi-intrusion detection envi-
		scenario construc-	-need for expert	ronment [75]
		tion	knowledge

  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2 Framework Description . . . . . . . . . . . . . . . . . . . . . . . 30 3.3 Information Sources . . . . . . . . . . . . . . . . . . . . . . . . .

	Chapter 3
		Honeypot-based Alert
		Correlation approach
	Contents
	3.1 31
	3.4 Alert Enrichment Process . . . . . . . . . . . . . . . . . . . . . . 32
	3.4.1 Enrichment selectors . . . . . . . . . . . . . . . . . . . . 33
	3.4.2 Filtering Process . . . . . . . . . . . . . . . . . . . . . . 34
	3.5 Experimentations and Evaluations . . . . . . . . . . . . . . . . . 35
	3.5.1 Local Information Source . . . . . . . . . . . . . . . . . . 35
	3.5.2 Experimental Honeypot Datasets . . . . . . . . . . . . . 37
	3.5.2.1	HARMUR datasets . . . . . . . . . . . . . . . 37
	3.5.2.2	SGNET datasets . . . . . . . . . . . . . . . . . 37
	3.5.3 Experimental Results . . . . . . . . . . . . . . . . . . . . 39
	3.5.4 Honeypot Limitations in Alert Correlation . . . . . . . . 41
	3.5.4.1	Coverage Limitations . . . . . . . . . . . . . . 42
	3.5.4.2	Unfilled Attributes and references Limitations	42
	3.5.4.3	Lack of Standard representation of honeypot
		data . . . . . . . . . . . . . . . . . . . . . . . . 43
	3.5.4.4	Cross-references Limitations . . . . . . . . . . 43
	3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	3.1 Introduction

Table 3 .

 3

	Classification	Number alerts	of	Total Num-ber unique IP of sources	Number of filtered alerts	Number of filtered unique IP sources
	attempted-recon 156338		2198	870 (0,5%)	132 (6%)
	attempted-dos 1		1	1 (100%)	1 (100%)
	attempted-user 1540		28	1540 (100%)	28 (100%)
	misc-activity	839		174	23 (3%)	21 (12%)
	trojan-activity 3		3	3 (100%)	3 (100%)
	bad-unknown	22573		34	51 (0,2%)	9 (26,5%)
	unclassified	1876		61	1876 (100%)	61 (100%)
	Global	183170		2499	4364 (2,5%)	255 (10%)

1 -Classification of alerts generated by the local deployed IDS sensor. In this table, we identify the total number of unique IP sources for both unfiltered alerts and filtered alerts.

Table 3 . 2 -

 32 Summary of reported signatures, their vulnerabilities, protocols and ports.

	Classification Signature		CVE Refer-ence	Protocol and Port	Nb. of alerts
	attempted-recon	SNMP request tcp	CVE-2002-0012/0014	TCP:80	3
		SNMP tX/tcp request Agen-	CVE-2002-0013	TCP:80, 31337	2
		SCAN FIN/S-
		CAN	SYN	-	TCP	860
		FIN
	attempted-dos	DoS Teardrop attack	CVE-1999-0015	UDP	1
	attempted-user	MS-SQL probe response over-flow	CVE-2003-0903	UDP:55989, 4974 56538, 41376, 36845, 64439,	1335
		Web-Client
		Windows Media
		Player tory	direc-traversal	CVE-2003-0228	TCP:80	1
		via	Content-
		Disposition
		ICMP	PING
	misc-activity	CyberKit	2.2	-	ICMP	20
		Windows
		BAD-TRAFFIC tcp port 0 traffic	-	TCP:0	3
		BACKDOOR
	trojan-activity	typot	trojan	-	TCP:44086	3
		traffic
	bad-unknown	ICMP Quench	Source	-	ICMP	50
		DNS	SPOOF
		query response
		with TTL of	-	UDP:53	1
		1 min, and no
		authority

Table 3 .

 3 3 -Experimental Results using alert's IP source address. The results shown in this table are based on IP sources of filtered alerts detailed in table 3.1.

		Number of
	Classification	filtered IP source ad-	SGNET v1	SGNET v2	HARMUR v1	HARMUR v2
		dress
	attempted-recon	132	-	-	1 tX/TCP) (SNMP Agen-	-
	attempted-dos	1	-	-	-		-
	attempted-user	28	-	-	-		-
	misc-activity 21	-	-	-		-
	trojan-activity	3	-	-	-		-
	bad-unknown 9	1 (DNS SPOOF)	-	-		1 SPOOF) (DNS
					1	(tcp
	unclassified	61	-	-	portscan) & 1 (tcp portscan,tcp	1 portscan) (tcp
					portsweep)

Table 3 . 4 -

 34 Analysis of identified IP source address objects from Table3.3.

	Signature volved	in-	SNMP Agen-tX/TCP	DNS SPOOF	tcp portscan	tcp portsweep portscan & tcp	tcp portscan
	Number alerts	of	1	1		4	203 & 103 1
	Honeypot		HARMUR	SGNET	HARMUR	HARMUR	HARMUR	HARMUR
	Dataset		v1	v1	v2	v1	v1	v2
	Temporal Infor-
	mation:
	first_seen,
	last_seen at-	unfilled	unfilled unfilled	unfilled	unfilled	unfilled
	tributes
	Security Informa-
	tion:
	Number	of
	hosted	Do-	41	-	1	1	2	1
	mains
	Security	cur-	28 green, 8
	rent color of	grey, 4 or-	-	1 grey	1 green	2 orange	1 red
	hosted domains	ange & 1 red
	Number corresponding of threat objects	25	no threat	-	no threat 4	1
	Threats rating	14 unknown & 11 red	-	-	-	4 known un-	-
			Virus,
			Browser
	Type of the threat	Exploit, Generic	-	-	-	Virus	-
			google
			safebrowsing
	Number of sat-
	isfied content	missing	-	missing	missing	missing	missing
	reference
	number	of
	filled	help	13	-	-	-	4	-
	attribute
							Windows
	information about affected systems	Windows: 98, 95, XP, Me, 2003, 2000 NT,	-	-	-	XP, Vista, 2003, Server NT,	-
							2000
	40

  4.9.1 Policy anomalies detection . . . . . . . . . . . . . . . . . 73 4.9.2 Intrusion Detection Assessment . . . . . . . . . . . . . . 74 4.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

	4.1 Introduction

Table 4 . 1 -

 41 Configuration of Firewall in Figure 4.5.

		Source		Destination	Action
	Protocol Address	Port Address	Port Action
	1:tcp	140.192.37.*	*	161.120.33.40 80	deny
	2:tcp	*.*.*.*	*	161.120.33.40 80	accept
	3:tcp	140.192.37.20 *	*.*.*.*	80	deny
	4:tcp	140.192.37.*	*	*.*.*.*	80	accept
	5:tcp	140.192.37.30 *	*.*.*.*	21	deny
	6:tcp	140.192.37.*	*	*.*.*.*	21	accept
	7:tcp	140.192.37.*	*	161.120.33.40 21	accept
	8:tcp	*.*.*.*	*	*.*.*.*	*	deny
	9:udp	*.*.*.*	*	161.120.33.40 53	accept
	10:udp	140.192.37.*	*	161.120.33.*	*	accept
	11:udp	*.*.*.*	*	*.*.*.*	*	deny

Table 4 . 2 -

 42 1, each class of PEP is characterized by an identical core set of Selectors denoted by {S 1 , S 2 , S 3 , . . . , S n } where n is the total number of selectors characterizing the PEP class. n represents the Dimension of the PEP class defined in Equation 4.8. as shown in Equation 4.8.Figure 4.6 -Characterization of a PEP Class. Network-level Firewall common Selectors Domains. The types and domains of these selectors are shown in Table 4.2. The TCP flag selector is one of the optional selectors for a netFW class. The Decision set of the netFW class is reduced to either Accept (a), i.e. authorize the data flow or Deny (d), i.e. reject it. The dimension of the netFW class is defined as follow:

	Dim(P EP ) =| ({S j } j∈[1...n] ) |= n where | | is the cardinality of the set.	(4.8)

In some cases, as shown in figure

4

.6, we may have some optional selectors that are not mandatory to characterize the PEP Class. Optional selectors are not necessary 4.5. PEP class Example: The Network-level firewall class, denoted by netFW, commonly has a set of five selectors which are { IP source address, source port, IP destination address, destination port, protocol }.

  4.7.1 Definition of RD inf (P EP )The configuration matrix Conf selectors (P EP ) defined in equation 4.20 represents not only the configuration of the PEP but also the identification the RD inf (P EP ). RD inf (P EP ) is the union of the entire set of Responsibility Domains of configured rules in the PEP's instantiation.

	Conf selectors (P EP ) =
			S 1	S 2	...	Sn
	r 1 r 2 . . .	    	s 11 s 12 . . . s 1n s 21 s 22 . . . s 2n . . . . . . . . . . . .	    	(4.20)
	RD

rm s m1 s m2 . . . s mn inf (P EP ) is the union of Conf selectors (P EP ) rows. The definition of RD inf (P EP ) takes into account the entire set of the different combinations between selectors defined in configured rules.

  .192.37. * , * , 161.120.33.40, 80, tcp >, < * . * . * . * , * , 161.120.33.40, 80, tcp >, < 140.192.37.20, * , * . * . * . * , 80, tcp >, Our objective at this stage is to analyze different possibilities of a comprehensive and appropriate approximation of RD(P EP ) without loosing the specificities of the deployed PEP. The RD inf (P EP ) is considered as the unique starting point for all the approximations. Based on RD inf (P EP ), we define inferences operations to build different versions of approximated Responsibility Domain denoted as RD

	4.7.2 Objective of RD(P EP ) approximations and methodol-
	ogy
	rb()	RD rb_apprx 1	RD rb_apprx 2
	RD inf	gen()
	sb()	RD sb_apprx 1	RD sb_apprx 2
	< 140.192.37. * , * , * . * . * . * , 80, tcp >, < 140.192.37.30, * , * . * . * . * , 21, tcp >, < 140.192.37. (4.22)

* , * , * . * . * . * , 21, tcp >, < 140.192.37. * , * , 161.120.33.40, 21, tcp >, < * . * . * . * , * , 161.120.33.40, 53, udp >, < 140.192.37. * , * , 161.120.33. * , * , udp >} apprx (P EP ). These operations consider the relations between rules and characterizations of selectors, their combination properties. We detail them in the two next paragraphs. The different approximations that we propose can be split in two major categories: • Rule-based (rb) approximations: It is based on rules which are represented by the rows of the Conf selectors (P EP ) matrix. • Selector-based (sb) approximations: It is based on values affected to selectors across columns of the Conf selectors (P EP ) matrix.

  RD rb_apprx 1 (P EP ) ← Approximation_RD(PEP)_1(RD inf (P EP ))

	• Case of Correlated Responsibility Domains:
	If RD(r 1 ) and RD(r 2 ) are Correlated , then:
	∃ j , j ∈ [1 . . . n] such that r 1 (S j ) ⊂ r 2 (S j ) r 1 (S j ) ⊃ r 2 (S j )	(4.28)
	We merge these two Responsibility Domains while verifying the SCombin-
	ability function
	Algorithm 1
		27)
	As shown in figure 4.7, in this relation, the two rules have a common area. We
	merge these two Responsibility Domains while verifying the SCombinability
	function. In the approximation algorithm described below, this operation is
	represented by +. If the SCombinability function is not verified, we keep both
	Responsibility Domains.

1: Input: RD inf (P EP ) 2: Output: RD rb_apprx 1 (P EP ) /* first rb_approximation result of the RD(P EP ) */ 3: k = 1 4: RD(r 1 ) = RD(r 1 ) 5: RD rb_apprx 1 (P EP ) = {RD(r 1 )} 6: for all i ∈ [2 . . . m] do 7: for all k ∈ [1 . . . lentgh(RD rb_apprx 1 (P EP ))] do

  . * . * . * , * , 161.120.33. * , [0 . . . 1023], {tcp, udp} >, < 140.192.37. * , * , * . * . * . * , [0 . . . 1023], tcp >, < 140.192.37. * , * , 161.120.33. * , * , udp >} RD rb_apprx 2 (F irewall) has a dimension which represents most of the real enforcement coverage of the Firewall. The advantage of this second approximation is that it enables us to estimate the flow that may pass through the Firewall in a blind manner.

	(4.30)

4.7.4 Selector-based approximations of RD(P EP ) 4.7.4.1 First sb_approximation of RD(P EP )

  4.31)Algorithm 5 RD sb_apprx 1 (P EP ) ← Approximation_RD(PEP)_3(RD inf (P EP ))D sb_apprx 1 (S i ) = r 1 (S i ) 8: end for 9: for all i ∈ [1 . . . n] do

	4:	then n ← n -1
	5: end if
	6: for all i ∈ [1 . . . n] do
	7:
	10:

1: Input: RD inf (P EP ) 2: Output: RD sb_apprx 1 (P EP ) /* first sb_approximation result of the RD(P EP ) */ 3: if ∃i such that S i = * ∀ j ∈ [1 . . . m] then

  At this stage of approximations, we apply the generalization function, gen(), on D sb_apprx 1 (S j ) domains. As a consequence, we consider larger range of values for selectors referring to its domain decomposition. The application of gen() function results in a generalization of the selectors values.RD rb_apprx 1 (P EP ) ⊆ RD rb_apprx 2 (P EP ) ⇒ | RD rb_apprx 1 (P EP ) | | RD rb_apprx 2 (P EP ) | (4.35)RD rb_apprx 2 (P EP ) includes additional combination with values of a common generalized sub-domains δ k (S) for one selector. Thus, as shown in Equation4.35, the number of vectors, i.e. the cardinality of RD rb_apprx 1 (P EP ), is lower than the cardinality of RD rb_apprx 2 (P EP ).CHAPT 4. POLICY ENFORCEMENT POINT MODEL which is at least the RD rb_apprx 1 as shown in Figure4.9 (a).thenRD sb_apprx 1 (P EP ) ⊆ RD rb_apprx 2 (P EP )

	Proof:
		, if f or j, j ∈ [1 . . . n] with j = j , ∃k j , k j ∈ [1 . . . l j ] such that : such that δ k j = δ k j	(4.33)
		then × j=1...n	SCombinability (s j , j ∈ [1 . . . 5]) = T rue} D sb_apprx 1 (S j ) = × j=1...n δ k j
	4.7.4.2 Second sb_approximation of RD(P EP )
	RD sup	RD sb_apprx 2		RD sup	RD sb_apprx 2	RD sup	RD sb_apprx 2
						RD rb_apprx 2	RD sb_apprx 1
	RD rb_apprx 2	RD rb_apprx 1 RD inf	RD sb_apprx 1			RD rb_apprx 1 RD sb_apprx 1	RD rb_apprx 1 RD rb_apprx 2
						RD inf	RD inf
	(a) First Case			(b) Second Case	(c) Third Case
				j=1...n	D sb_apprx 2 (S j ), such that SCombinability(s j , j ∈
	[1 . . . n]) = true}
	8: return RD sb_apprx 2 (P EP )
	4.8 Analysis of RD(P EP ) Approximations and In-Proof:
	terpretations if ∀j ∈ [1 . . . n], ∃k j ∈ [1 . . . l j ] such that
	D sb_apprx 1 (S j ) ⊆ δ k j 4.8.1 RD(P EP ) Approximations Properties then × j=1...n D sb_apprx 1 (S j ) ⊆ × j=1...n δ k j

RD sb_apprx 2 (P EP ) ← { × j=1...n gen(D sb_apprx 1 (S j )), such that SCombinability(s j , j ∈ [1 . . . n]) = T rue} (4.34) Algorithm 7 RD sb_apprx 2 (P EP ) ← Approximation_RD(PEP)_2(RD sb_apprx 1 (P EP ))

1: Input: RD sb_apprx 1 (P EP ) 2: Output: RD sb_apprx 2 (P EP ) /* second sb_approximation result of the RD(P EP ) */ 3: for all j ∈ [1 . . . n] do 4:

identif y δ k (S j ) such that D sb_apprx1 (S j ) ⊂ δ k (S j )

5:

D sb_apprx 2 (S j ) ← δ k (S j ) 6: end for 7: RD sb_apprx 2 (P EP ) ← { × As explained above, all the approximations closely depends on the configuration of the deployed P EP . Therefore, as depicted in figure 4.9, several relations would exist between these approximations: 4.8. Analysis of RD(P EP ) Approximations and Interpretations • Totally Inclusive Approximations: Proof:

| RD rb_apprx 1 (P EP ) | = k∈[1...m rb_apprx1 ] | RD(r k ) | = k∈[1...m rb_apprx1 ] j∈[1...n] | s kj | ≤ k∈[1...m rb_apprx1 ] j∈[1...n] | gen(s kj ) | ≤ | RD rb_apprx 2 (P EP ) | RD rb_apprx

1 (P EP ) and RD sb_apprx 1 (P EP ) are also Inclusive domains because of the generation of additional selector values combinations when building RD sb_apprx 1 (P EP ). Thus, as shown in Equation 4.36, the cardinality of RD rb_apprx 1 (P EP ) is lower than the cardinality of RD sb_apprx 1 (P EP ). RD rb_apprx 1 (P EP ) ⊂ RD sb_apprx 1 (P EP ) ⇒ | RD rb_apprx 1 (P EP ) | | RD sb_apprx 1 (P EP ) | (4.36) Moreover, since the approximation RD sb_apprx 2 (P EP ) includes all the possible combinations between values of selectors generalized sub-domains, it will include RD rb_apprx 1 (P EP ), RD rb_apprx 2 (P EP ) and RD sb_apprx 1 (P EP ). Depending on the configured values s ij in Conf selectors (P EP ), it is possible that RD sb_apprx 1 (P EP ) is included in RD rb_apprx 2 (P EP ), Figure 4.9 (b) or RD rb_apprx 2 (P EP ) is included in RD sb_apprx 1 (P EP ), Figure 4.9 (c). thenRD sb_apprx 1 (P EP ) ⊆ RD rb_apprx 2 (P EP ) • Partially Joint Approximations: Both of RD rb_apprx 2 (P EP ) and RD sb_apprx 1 may have a common set of vectors

Table 4 . 3 -

 43 Evaluation of Approximation Accuracy Metric of the running exampleRD inf RD rb_apprx 1 RD rb_apprx 2 RD sb_apprx 1 RD sb_apprx 2

	sup (src_ip) = {140.192.37. * , 161.120.33. * , * . * . * . * }
	D sup (dst_ip) = {140.192.37. * , 161.120.33. * , * . * . * . * }	(4.37)
	D sup (p) =	{tcp, udp, icmp}
	RD (4.38)

sup (F irewall) = {D sup (src_ip) ×D sup (dst_ip) × D sup (p), such that : SCombinability (s j , j ∈ [1 . . . n]) = T rue}

  d k 2 and corresponds to common rules RD inf (P EP 1 ) ∩ RD inf (P EP 2 )

⇒ Conf lict(P EP 1 , P EP 2 ) = T rue (4.40) Conflict(P EP 1 , P EP 2 ) is a Boolean function which returns True if there is an interconflict between P EP 1 and P EP 2 . Otherwise, it returns False.

  A 2 , . . .), P EP 1 (5.1) A 1 and A 2 are two different alerts. RD(P EP 1 ) is the Responsibility Domain of the P EP 1 .A ec represents the Enforcement-based Correlated Alert. It is composed of two components. The first component includes the set of correlated alerts. The second component includes the PEP(s) that is (are) capable to process the correlated alerts.

PEACE Policy Enforcement-based Alert Correlation Engine

	Conf(PEP 1 ) Conf(PEP 1 ) Conf(PEP 2 ) Conf(PEP 2 )	…	…	Conf(PEP m ) Conf(PEP m )
			RD-Approximator RD-Approximator
	RD apprx (PEP 1 ) RD apprx (PEP 1 ) RD apprx (PEP 2 ) RD apprx (PEP 2 ) …	…	RD apprx (PEP m ) RD apprx (PEP m )
			Alignment Option 2
			RD_DB	RD(PEP 1 ), RD(PEP 2 ), …, RD(PEP m ) RD(PEP 1 ), RD_DB RD(PEP 2 ), …, RD(PEP m )
	A 1 , A 2 , … , A n t A 1 , A 2 , … , A n t	Alignment Option 1	PEACE Policy Enforcement-based	A ec	A ec 1 , A ec 1 , A ec 2 , … , A ec 2 , … , A ec n a	n a
			Alert Correlation Engine
	Figure 5.1 -PEACE Framework with alignment function option
	1.

  Alignment Functions we give the generic expression of Alignment Functions of the 1 st option. We denote it by align P EP . =< a 1 , a 2 , . . . , a n idmef > and A =< a 1 , a 2 , . . . , a npep > Dom(IDMEF ) is a multidimensional domain including the different attributes defined in the IDMEF standard. n idmef is the number of IDMEF attributes present in an alert A. Each attribute a i , i ∈ [1 . . . n pep ], follows the semantics of selector S i of the corresponding class of PEP. If the alignment function does not find in the IDMEF Alert A the necessary information to fill attributes a , they will be set as empty. Alignment Function is the composition of different elementary operations as shown in

							(5.2)
	IDMEF (Source class) Attribute	PEP iptable h h h Type Selector Type Selector ModSecurity Type Selector LDAP	Type
	Service
	ip_version	integer -	-	-	-	-		-
	iana_protocol_number integer -	-	-	-	-		-
	iana_protocol_name	string	-	-	-	-	-		-
							peername.ip
	port	integer -sport	integer	Remote-Port	integer	= mask] [%net-	ipv4 [	integer
							port]
	portlist	string	-	-	-	-	-		-
	protocol	string	-p	string -	-	-		-
	options are possible for Alignment Functions.
	5.2.1 1 st option: From IDMEF to PEP class

This option consists of aligning the received IDMEF alert with the PEP class. In this case, Alignment has to be performed on each received alert. In Equation

5

.2,

5.2.

align P EP : Dom(IDMEF ) -→ Dom(P EP )

A -→ A = align P EP (A)

where A

  5.2.2 2 nd option: from PEP class to IDMEFContrary to the 1 st option, Alignment Functions, in the 2 nd option, performs alignment operations in order to align the Responsibility Domains of PEPs with the IDMEF format as shown in Figure5.4. In Equation5.4, we give the expression of alignment function of the 2 nd option. We denote it by align IDMEF .

			align IDMEF
			Projection
	RD(PEP) n PEP		endo-Deduction	RD(PEP) n idmef
	r = < s 11 , s 12 , …, s 1n pep >	Ext	Exo-Deduction	r' = < s' 11 , s' 12 , …, s' 1n idmef >

Table 5 . 4 -

 54 Comparison between alignment options. The second option aligns Responsibility Domains of deployed classes of PEP. It is performed in an offline mode relative to the correlation process. The first option aligns each alert once received with each deployed class of PEP. Such online performance increases the delay of correlation execution. Based on this comparative table, we can easily figure out that the second alignment option presents more interesting advantages for correlation process. In fact, it presents the advantage of being less time consuming because it has less complexity and can even be performed offline and not during correlation.

	Criteria	Option 1 Option 2
	Process	Online	Offline
	Complexity	n cpep × n a	n cpep
	Time consuming	Yes	No
	alignment process, time consumption and complexity.

  1 ) =< 140.192.37. * , * port , * ip , 80, tcp > RD(r 2 ) =< 140.192.37.30, * port , * ip , 21, tcp >

	=⇒
	rb()

RD(r

1,2 ) =< 140.192.37. * , * port , * ip , {21, 80}, tcp >

  .2.3 Alert Correlation based on Selector-based first approximationAs detailed in Chapter 4, rule vectors of RD rb_apprx 1 (P EP ) are obtained by applying sb() function on RD inf (P EP ). The application of sb() function on RD inf (P EP ) consists on generating all the acceptable combinations between instantiated selector values. For instance, as shown in Equation6.4, the application of sb() function on RD r 1 , RD r 2 and RD r 3 results in RD(r 1,2,3 ) which is built of all the combinations between selector values defined in RD r 1 , RD r 2 and RD r 3 .RD(r1 ) =< 140.192.37. * , * port , * ip , 80, tcp > RD(r 2 ) =< 140.192.37.30, * port , * ip , 21, tcp > RD(r 3 ) =< 140.192.37.20, * port , * ip , 53, udp >

	=⇒ sb()	RD(r 1,2,3 ) = {140.192.37. * × * port × * ip
		×{21, 53, 80} × {tcp, udp}}

1 =< 140.192.37.140, 51000, 10.0.0.3, 80, {tcp} > A 2 =< 140.192.37.140, 4000, 10.0.0.5, 21, {tcp} > (6.3) 6

Table 6 . 1 -

 61 Application of Responsibility Domain approximations in PEACE: a comparative table. RD rb_apprx 1 (P EP ) rb(RD inf (P EP ))

	Approximated RD	Approximation function	impact on Alert Correlation
	RD inf (P EP )	-	Alerts are correlated using exist-ing configured rules.
			+ Countermeasure implementa-
			tion are immediately identified
			-Restricted view on the PEP re-
			sponsibility domain
			-Alerts that can be processed by
			injecting new rules are ignored
			Alerts are correlated by a set of
			combinations between configured
			rules
			+ Countermeasure implementa-
			tion implicates at least one con-
			figured rule modification
			-Alerts that can be processed by
			injecting new rules are ignored
			Alerts are correlated regarding
			all possible combination between
			configured values of selectors
			-Countermeasure implementa-
			tion require deep analysis of in-
			volved rules in processing corre-
			lated alerts
			-Alerts that can be processed by
			injecting new rules with different
			selectors values are ignored
	RD rb_apprx 2 (P EP ) gen(RD rb_apprx 1 (P EP ))	Alerts are correlated regarding generalized configured rules
			-The amount of correlated alerts
			depends on the distribution over
			partitions of configured selectors
			values
			Alerts are correlated regarding
	RD sb_apprx 2 (P EP ) gen(RD sb_apprx 1 (P EP ))	generalized configured selectors
			values
			-The amount of correlated alerts
			depends on the distribution over
			partitions of configured selectors
			values

RD sb_apprx 1 (P EP ) sb(RD inf (P EP ))

  6.3. Role of enforcement-based alert correlation in countermeasure implementations in a single PEP environment Table 6.2 -Evaluation of Coverage Increase Metric of the running example RD inf RD rb_apprx 1 RD rb_apprx 2 RD sb_apprx 1 RD sb_apprx 2

	| (RD apprx (P EP ) |	2, 16 * 10 17 13, 5 * 10 19	7 * 10 24	21 * 10 24	21 * 10 24
	CI(RD apprx (P EP ))	1	6, 25 * 10 2	3, 25 * 10 7	9, 75 * 10 7	9, 75 * 10 7
	6.3 Role of enforcement-based alert correlation in
	countermeasure implementations in a single PEP
	environment

  r 1 ) =< 140.192.37. * , * port , * ip , 80, tcp > RD(r 2 ) =< 140.192.37.30, * port , * ip , 21, tcp > The corresponding rule vector v 1 ∈ RD(P EP ) for these two rules (referring to the generalization approximation algorithms 2 and 4 described in Sections 4.7.3.2 and 4.7.4.2) is: v 1 = RD gen (r 1,2 ) =< 140.192.37. * , * port , * ip , [1 . . . 1024], {tcp} > 6.3. Role of enforcement-based alert correlation in countermeasure implementations in a single PEP environmentWe consider two alerts defined as follow:Both A 1 and A 2 are in RD(v 1 ).

	A 1 =< 140.192.37.140, 51000, 10.0.0.3, 80, {tcp} >
	A 2 =< 140.192.37.30, 4000, 10.0.0.3, 53, {tcp} >

  6.4. Application of PEACE in multi-PEP scenario ment such as the Olympic Games IT system where an important number of PEPs are deployed, it is challenging to select the proper PEP(s) that is (are) capable to enforce the intrusion response decision. Moreover, in a defense-in-depth strategy, the intrusion response decision results in the participation of different PEPs. Thus, it is important to study the relationships that exist between multiple PEP responsibility domains. Two cases can be distinguished: disjoint domains and joint responsibility domains. Figure6.4 depicts these cases. It is important to remind that in our as-Joint responsibility domains:A responsibility domain is joint with another domain when it is partially (e.g. RD(P EP 3 ) and RD(P EP 4 )) or totally (e.g. RD(P EP 1 ) and RD(P EP 2 )) covered by this latter. We denote it RD(P EP 3 )∩ RD(P EP 4 ) = I 3,4 . Let's min(RD(P EP 3 ), RD(P EP 4 )) be the responsibility domain whose dimension is the minimum one. In our case, min(RD(P EP 3 ), RD(P EP 4 )) = RD(P EP 4 )• RD(P EP 3 ) and RD(P EP 4 ) are partially joint domains , iff

	Network Perimeter j i >, ∀i ∈ [1 . . . n] r ] and j ∈ [1, . . . , n 4 RD(PEP 1 ) RD(PEP 2 ) • ∃j ∈ [1, . . . , n 3 r ] such that < d 2 j i > ⊆ < d 1	(6.12)
	RD(PEP 3 )	RD(PEP 4 )
	Figure 6.4 -Possible relationships between PEPs Responsibility
	Domains.
	sumption, all the responsibility domains are aligned with the IDMEF format and
	have n dimensions. These high-dimensional domains are difficult to be geometri-
	cally represented. As a consequence, we restrain our representation to generic sets
	represented by circles 6.4.
	Let's also remind that responsibility domains of deployed p PEPs are expressed
	as follow:
	RD(P EP p ) = n is the IDMEF dimension. d p < d p ji > i∈[1...n] . n p r is the number of vectors in RD(P EP p ). j∈[1...n p r ] ji are the aligned dimension values of P EP p .
	• Disjoint responsibility domains : A responsibility domain is disjoint from
	another domain if their vectors are totally different.
	• RD(P EP 2 ) and RD(P EP 3 ) are Disjoint domains
	(we denote it RD(P EP 2 ) ∩ RD(P EP 3 ) = ∅ ) , iff
	∀j ∈ [1, . . . , n 2 r ], j ∈ [1, . . . , n 3 r ] and ∀i ∈ [1, . . . , n] such that < d 2 j i > = < d 3 j i >	(6.11)

  A 2 , . . . , A na } represents the set of generated alerts PEP = {P EP 1 , P EP 2 , . . . , P EP npep } represents the set of the deployed PEPs. We denote by RD((P EP )) the set of responsibility domains of PEPs in PEP. We note by Corr(A, RD((P EP ))) the correlation function which correlated alerts in A with responsibility domains in RD((P EP )). This function results in a subsets of enforcement-based correlated alerts A ec = {A ec 1, A ec 1, . . . , A ec n a ec } as shown in Equation6.14.

Corr(A, RD((P EP )

  7.2.1 Application on other PEP classesExpand the application of the enforcement-based alert correlation to include other PEP classes: We conducted our analysis based on a single PEP class which is the network firewalls. Although this class is commonly used in networks, there exists other PEP that should be analyzed in order to apply our responsibility domain approximations. The integration of other PEP class allows the application of our alert correlation on heterogeneous security systems. In Tables 5.1, 5.2 and 5.3, we briefly introduce other PEP classes mainly ModSecurity and LDAP. Similar to network firewall such as iptable, ModSecurity PEP has five principle selectors that are: Remote-Address, Remote-port, Remote-user, hostname, Request-Body. LDAP's selectors are in general represented by string variables such as the common name (cn), the username, etc. In this case, it is possible to define a domain decomposition based on keywords or a hierarchy of values. For instance, LDAP attributes can be defined following a tree decomposition as shown in figure7.3.

  1.1 Core principles of computer security: Confidentiality, Integrity, Availability (C, I, A). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Security properties as represented by the McCumber's cube. Source: [6]. This cube contains three blocks: the first block corresponds to the critical information characteristics (C, I, A), the second block corresponds to the information states, and the third block corresponds to the security measures. . . . . . . . . . . . . . . . . . . . . . . . . . Basic intrusion detection system architecture, source [19]. It represents the main components of an IDS that are: a sensor, an analyzer, a response module, and a repository . . . . . . . . . . . . . . . . . . . 2.3 Intrusion Detection taxonomy, source [24]. The categorization depends on the detection method, behavior on detection, detection paradigm, usage frequency. . . . . . . . . . . . . . . . . . . . . . . . . 2.4 IDMEF Alert model. It is composed of two major classes that are the alert class and the heartbeat class. The alert class includes information about the detected attack. The heartbeat class indicates information about the current analyzer's status to managers . . . . . 3.1 Honeypot-based alert correlation workflow. . . . . . . . . . . . . . . . 3.2 Alert Enrichment Process. . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Filtering Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Example of src/dst_ip selector taxonomy. . . . . . . . . . . . . . . . 4.2 Example of src/dst_port selector taxonomy. . . . . . . . . . . . . . . 4.3 Combinability between two selectors D(S 1 ) and D(S 2 ). . . . . . . . . 4.4 Combinability between multiple selectors D(S 1 ), D(S 2 ) and D(S 3 ). . 4.5 Running Example: a network with two zones. . . . . . . . . . . . . .

2.1 PDCA: Security policy life-cycle, source

[7]

. It represents the four steps (represented by colored circles) of the security life cycle that are: Plan (orange circle), Do (blue circle), Check (red circle) and Act (green circle). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 4.6 Characterization of a PEP Class. . . . . . . . . . . . . . . . . . . . . 4.7 Relations between Responsibility Domains of two rules. . . . . . . . . 4.8 Overview of Responsibility Domain Approximations. . . . . . . . . .

  1.1. Puis, nous exposons les différentes techniques de détection d'intrusions dans la section A.1.2 et les techniques des pots de miel dans la section A.1.3. Ces techniques de détection d'intrusions générent de nombreuses alertes difficiles à gérer. C'est pour cette raison, la notion de corrélation d'alertes a été développée. Dans la section A.1.3, nous expliquons cette notion qui sera le coeur de cette thèse.

based alert correlation Local alert datasets Honeypot datasets Alert enrichment process Analyze Er_Alert Reassess attack severity Re-evaluate attack impact Re-evaluate intrusion objective

  A.2.1 Définition de l'approcheLa corrélation d'alertes basée sur les pots de miel que nous proposons consiste à exploiter l'information sur les attaquants collectée par les pots de miel pour améliorer la corrélation des alertes générées en local (par les IDSs déployés dans le réseau supervisé). Cette approche est capable d'analyser le lien de causalité entre les alertes détectées localement au niveau du système supervisé et les phénomènes d'attaque observés globalement au niveau des pots de miel. Elle est bénéfique pour ré-évaluer la gravité et l'impact de l'attaque. La figure A.2 présente le processus de corrélation d'alertes basée sur les pots de miel. Ce processus est principalement composé de trois étapes qui sont:

	Enriched alert Begin Honeypot-External information datasets {Er_Alert}
	(CVE, Attack Type,
	Criticity, etc)
	Correlation	Correlate
	features	Er_Alert
		Correlated Alerts

  En général, C j est un ensemble de conditions définies sur des attributs que nous appelons Sélecteurs et noté par {S i } i∈[1...n] . Par conséquent, une règle r j est représentée par: r j : ×s i i∈[1...n] -→ {d k } k∈[1...p] ∀j ∈ [1, . . . , m] s i (i ∈ [1 . . . n]) sont des instantiations de sélecteurs. Avant de détailler le modèle proposé, il est important de détailler nos hypothèses de modélisation: • Axiome 1 La vérification des faux positifs est en dehors du champ de notre travail. En plus, nous supposons que toutes les alertes sont écrites selon le standard IDMEF (Intrusion Detection and Message Exchange Format) décrit dans [69] • Axiome 2 Tous les PEP ont un ensemble fini de règles; • Axiome 3 Nous ignorons la règle par défaut appliquée par le PEP; • Axiome 4 Les domaines de tous les sélecteurs sont finis; • Axiome 5 Nous ignorons la décision qui peut être appliquée par le PEP; • Axiome 6 La définition du domaine de responsabilité d'un PEP doit dépendre seulement des caractéristiques intrinsèques au PEP. Nous détaillons ci-dessous la définition du domaine de responsabilité d'un PEP: Définition 1 Domaine de responsabilité d'un PEP: Chaque PEP, une fois mis en place dans un réseau, a un domaine d'applicabilité unique que nous appelons "Domaine de responsabilité". Nous le notons RD(P EP ). Ce domaine est une abstraction de l'implémentation et de la configuration d'un PEP et de ses capacités intrinsèques d'application de politique. RD(P EP ) est un domaine multidimensionnel borné. Dans la définition 2, nous détaillons ces bornes. Définition 2 RD inf (P EP ) est l'union de tout les domaines de responsabilité de règles configurées dans un PEP mis en place. RD sup (P EP ) considère les contraintes environnementales du PEP mis en place. L'identification de cette borne requiert une connaissance externe de la visiblité topologique du PEP. Suivant l'axiome 4, cette borne ne sera bas identifiée dans ce travail. A.3.2 Domaine de responsabilité d'un PEP Notre objectif est d'analyser les différentes possibilités d'une approximation appropriée d'un RD(P EP ) sans perdre les spécifités du PEP mis en place. Dans notre approche, nous considérons que la configuration du PEP déployé dans le réseau est le seul point de départ pour toutes les approximations. La configuration du PEP constitue RD inf (P EP ). En partant de RD inf (P EP ), nous définissons des opérations afin de construire les différentes approximations. Ces opérations prennent en compte les relations qui existent entre les règles, les caractéristiques des sélecteurs et leurs propriétés de combinaison. Les différentes approximations que nous proposons peuvent être divisées en deux grandes catégories: • Approximations basées sur les règles (opérateur rb()) • Approximations basées sur les sélecteurs (opérateur sb())

	rb()	RD rb_apprx 1	RD rb_apprx 2
	RD inf	gen()
	sb()	RD sb_apprx 1	RD sb_apprx 2

{decisions} j ∀j ∈ [1, . . . , m] r j : C j -→ D j ∀j ∈ [1, . . . , m]

  Figure A.5 -Structure de PEACE avec fonction d'alignement option 1.

		Conf(PEP 1 )	Conf(PEP 2 )	…	Conf(PEP m )
				RD-Approximator
		RD apprx (PEP 1 )		RD apprx (PEP 2 )	…	RD apprx (PEP m )
				RD_DB	RD(PEP 1 ), RD(PEP 2 ), …, RD(PEP m )
	A 1 , A 2 , … , A n t	Alignment Option 1					A ec	1 , A ec	2 , … , A ec	n a
	Conf(PEP 1 )	Conf(PEP 2 )	…	Conf(PEP m )
			RD-Approximator
		RD apprx (PEP 1 )	RD apprx (PEP 2 )	…	RD apprx (PEP m )
			Alignment Option 2
			RD_DB	RD(PEP 1 ), RD(PEP 2 ), …, RD(PEP m )
	A 1 , A 2 , … , A n t	PEACE Policy Enforcement-based	A ec	1 , A ec	2 , … , A ec	n a
		Alert Correlation Engine

Table A . 3 -

 A3 Application des approximations de domaine de responsabilité dans PEACE: un tableau comparatif. Une vue restreinte du domaine de responsabilité du PEP -Les alertes qui pourraient être traitées par l'introduction de nouvelles règles sont ignorées RD rb_apprx 1 (P EP ) rb(RD inf (P EP )) Les alertes sont corrélées par une combinaison de règles configurées + L'implémentation des contre mesures implique au moins une modification d'une règle configurée -Les alertes qui pourraient être traitées par l'introduction de nouvelles règles sont ignorées RD sb_apprx 1 (P EP ) sb(RD inf (P EP )) RD rb_apprx 2 (P EP ) gen(RD rb_apprx 1 (P EP )) Les alertes sont corrélées selon les règles configurées généralisées -L'ensemble des alertes corrélées dépend de la partition des valeurs configurées des sélecteurs RD sb_apprx 2 (P EP ) gen(RD sb_apprx 1 (P EP ))

	RD approximé	Fonction d'approximation	impact sur la corrélation d'alertes
	RD inf (P EP )	-	Les alertes sont corrélées selon les règles configurées.
			+ L'implémentation des contre mesures
			est immédiatement identifiée
			-Les alertes sont corrélées selon toutes
			les combinaisons possible entre les
			valeurs de sélecteurs configurées
			-L'implémentation des contre mesures
			requiert une analyse profonde des règles
			impliquées dans la corrélation d'alertes
			-Les alertes qui pourraient être
			traitées par l'introduction de nouvelles
			règles avec des valeurs différentes de
			sélecteurs sont ignorées

MITRE, http://www.mitre.org/

Common Vulnerability Exposure: CVE, http://www.cve.mitre.org/

Open Source Vulnerability Database: OSVDB, http://www.osvdb.org/

Corero: First Line of Defense, www.corero.com

Snort, www.snort.org

Log Correlation Engine: Best Practices, http://www.tenable.com/whitepapers/log-correlation-engine-best-practices

Common Vulnerability Exposure: CVE, http://www.cve.mitre.org/

Open Source Vulnerability Database: OSVDB, http://www.osvdb.org/

Yosra Ben Mustapha, Hervé Debar and Gregory Blanc, Policy Enforcement Point Model, 10th International Conference on Security and Privacy in Communication Networks,

August 2014,[START_REF] Mustapha | Policy Enforcement Point Model[END_REF]. 2 Yosra Ben Mustapha, Hervé Debar, Service Dependencies-Aware Policy Enforcement Framework based on Hierarchical Colored Petri Net, International Symposium on Security in Computing and Communications, Mysore, India, August 2013, [103].

Contributions: Les approches de corrélation d'alertes développées dans cette thèse s'appuyent sur les données fournies par les pots de miel et les configurations des PEPs déployés au sein du réseau. Dans notre approche "corrélation d'alertes basée sur les pots de miel", nous étudions les informations concernant les attaquants fournies par les pots de miel dans l'objectif de corréler les alertes. En plus, puisque les données sur les attaquants ne sont généralement pas suffisantes pour améliorer la prise de décision pour les intrusions, nous proposons une "approche de corrélation d'alertes basée sur l'application de la politique de sécurité"

Chapter 4

Policy Enforcement Point Model

Contents

Chapter 6

Applications and interpretations

Contents

Chapter 7

Conclusions and Perspectives

The open mind never acts: when we have done our utmost to arrive at a reasonable conclusion, we still -must close our minds for the moment with a snap, and act dogmatically on our conclusions.

I

In conclusion, we summarize how each of the research topics presented in the first chapter has been pursued, and the contributions which have resulted. Next, we reflect on how we can improve our contributions and provide new research directions. Throughout this thesis, our main objective was to propose novel alert correlation techniques to support the security administrator dealing with the tremendous number of alerts. Two correlation approaches are presented:

List of Tables 2.1 Honeypot interaction levels. These levels that are low-interaction, high-interaction and medium-interaction are represented in the raw of the Integrated information security oriented platform that offer the following services: Log management (log collection, storage, organization and retrieval); IT regulatory compliance (audit, validation or violation identification); Event correlation (normalization, fusion, verification, analysis); Active response (decision analysis, counter-measure response, prioritization); and Endpoint security (monitoring, updating, configuration).

Threat

A circumstance or event with the potential to adversely impact organizational operations (e.g., mission, functions, reputation), as well as organizational assets, individuals, other organizations, or even the Nation through unauthorized access, destruction, disclosure, modification of information, and/or denial of service.

Author's publications

Publications in international peer-reviewed journals

L

es failles de sécurité sont de plus en plus critiques pour les entreprises. Ainsi, les mesures de sécurité les plus appropriées sont indispensables pour assurer la sécurité des entreprises et de l'utilisateur. Des mécanismes de sécurité sont déployés dans les réseaux afin de prévenir les attaques et réagir contre elles lorsqu'elles sont détectées. Actuellement, les systèmes pour la Sécurité de l'Information et la Gestion des Evénements (connus en anglais par SIEM: Security Information and Event Management) sont au coeur des centres opérationnels de sécurité. Les SIEMs ont été développés pour assister le responsable de la sécurité des systèmes d'information (RSSI) dans la réalisation de ses responsabilités. Ils combinent deux aspects différents: le système de gestion de sécurité des données et le système de gestion des événements [2]. Les SIEMs se concentrent sur:

• la collection des journaux dévénements et leurs normalisations • l'analyse et la corrélation des événements en provenance de différents capteurs (anti-virus, pare-feux, systèmes de détection d'intrusion, etc) • l'aggrégation des événements et la création de rapports d'activité.

Les travaux de recherches sur les SIEMs se sont toujours concentrés sur la création de rapports d'attaques pour les entreprises dans le but de maintenir leur politique de sécurité à jour. La corrélation d'alertes représente le coeur des SIEMs. Toutefois, la plupart des travaux traitant ce sujet ne prennent en compte que les alertes générées par les sondes déployées dans le réseau. Ces techniques de corrélation ne considérent pas d'autres données telles que le comportement de l'attaquant, la capacité de réponses aux attaques, etc. Cependant, des recherches récentes sur la corrélation d'alertes (comme l'étude présentée [START_REF] Morin | M2D2: A formal data model for ids alert correlation[END_REF][START_REF] Morin | M4D4: a Logical Framework to Support Alert Correlation in Intrusion Detection[END_REF]) ont montré l'importance de ces données.

Résumé en français d'imiter un ensemble de services et d'effectuer des opérations plus complexes. La dernière catégorie des pots de miel est dite à interaction haute et sont capable d'imiter un système de communication réel. Cette dernière catégorie est capable d'intéragir d'une manière plus complète avec l'attaquant.

A.1.4 Corrélation d'alertes

La corrélation d'alertes a été conçue pour pallier les limitations des IDSs. Principalement, elle permet de réduire le nombre d'alertes générées par ces derniers. Dans la littérature, on trouve plusieurs approches de corrélation d'alertes que nous catégorisons de la manière suivante:

• Corrélation d'alertes basée sur la similarité: cette approche regroupe les alertes similaires selon un critère de corrélation.

Résumé en français

Local alert datasets

Honeypot datasets

Alert enrichment process

Categorization

Enriched alert datasets {Er_Alert}

Enrichment features Par exemple, selon la source de l'alerte générée, nous recueillons les connaissances globales sur le serveur analysé par les pots de miel. Ainsi, nous pouvons évaluer son profil de sécurité et son évolution au fil du temps. Une fois que cette collecte d'information est effectuée, nous catégorisons les données collectées selon une catégorisation bien définie dans cette thèse (information temporel, information sémantique, information contextuelle). Nous proposons aussi un processus de filtrage qui est composé par trois types de filtres: temporel, sémantique et filtre de configuration. Ces filtres permettent d'éliminer les données qui sont moins susceptibles de pouvoir lier l'alerte détectée en local avec les phénomènes de menaces globalement détectées.

Collected additional information Categorized information

Filtering

A.2.4 Expérimentations et évaluations

Les expériences menées dans cette partie sont basées sur quatre bases de données de pots de miel qui sont: SGNET v1 [START_REF] Leita | SGNET: a worldwide deployable framework to support the analysis of malware threat models[END_REF], SGNET v2, HARMUR v1 [START_REF] Leita | HARMUR: Storing and analyzing historic data on malicious domains[END_REF]

Source d'information globale

Les bases de données de pots de miel que nous avons utilisées dans nos expériences ont été fournies par le projet européen Vis-Sense. Elles comprennent des données caractérisant les menaces et le profil de sécurité des serveurs web suspicieux. La base de données HARMUR [START_REF] Leita | HARMUR: Storing and analyzing historic data on malicious domains[END_REF] contient des informations portant sur l'évolution de la sécurité et de l'information contextuelle associés aux menaces des serveurs web. La base de données SGNET [START_REF] Leita | SGNET: a worldwide deployable framework to support the analysis of malware threat models[END_REF] contient des informations sur les stratégies de propagation des logiciels malveillants. En effet, SGNET est un déploiement de pots Résumé en français de miel distribués implémentant différents outils, à savoir ScriptGen [START_REF] Leita | Automatic handling of protocol dependencies and reaction to 0-day attacks with ScriptGen based honeypots[END_REF], Argos [START_REF] Portokalidis | Argos: an emulator for fingerprinting zero-day attacks[END_REF] et Nepenthes [START_REF] Baecher | The Nepenthes Platform: An Efficient Approach to Collect Malware[END_REF].

Résultats expérimentaux

Dans