Jeremy Bluteau
email: jeremy.bluteau@inrialpes.fr-yohan.payan@imag.fr

Marie-Dominique Dubois

Sabine Coquillart

Edouard Gentaz

Yohan Payan

Vibrotactile guidance for trajectory following in Computer Aided Surgery

Most conventional computer-aided navigation systems assist the surgeon visually by tracking the position of an ancillary and by superposing this position into the 3D preoperative imaging exam. This paper aims at adding to such navigation systems a device that will guide the surgeon towards the target, following a complex preplanned ancillary trajectory. We propose to use tactile stimuli for such guidance, with the design of a vibrating belt. An experiment using a virtual surgery simulator in the case of skull base surgery is conducted with 9 naïve subjects, assessing the vibrotactile guidance effectiveness for complex trajectories. Comparisons between a visual guidance and a visual+tactile guidance are encouraging, supporting the relevance of such tactile guidance paradigm.

I. INTRODUCTION

Computer-Aided Surgery (CAS) has become an accepted way of assisting surgeons during complex surgical interventions. These navigation systems provide an on-line tracking of surgical tools (or "ancillaries", often tracked by stereo cameras and markers) which positions are superimposed into previously acquired medical investigation such as computer tomography (CT), magnetic resonance imaging (MRI) or ultrasound images (US). The use of imaging technologies leads to possible 3D reconstructions and preoperative planning, depending on the medical intervention.

Most conventional CAS systems inform the surgeon about the distance of the ancillary relative to anatomical structures as well as preplanned data (safety areas, tumor, predefined trajectory,...). This information is usually provided through visualization devices (a screen) located beside the operative field, two or three meters away fron the surgeon. Quite recent researches tried to improve this visual feedbacks by [START_REF] Bluteau | Évaluation des effets de l'ajout d'interfaces haptiques sur le suivi manuel de trajectoires[END_REF] simplifying the amount of guidance information or (2) using another perception channel. In the first class of improvements, some punction applications like kidney biopsies or computer assisted systems for pedicle screw insertion display visual guidance by aligning crosses [START_REF] Mozer | Computer-assisted access to the kidney[END_REF], [START_REF] Merloz | Computer-assisted spine surgery[END_REF]. These applications are restricted to straight trajectories. The second class of improvements propose to use another sensory channel for such guidance. Auditory channels have been extensively used, mainly because of their temporal efficiency [START_REF] Ng | Evaluation of a tactile display around the waist for physiological monitoring under different clinical workload conditions[END_REF]. However, their omnipresence as physiological variables alarms dissuades their use for on-line continuous guidance. Recently, researchers have tried to use a still non-overloaded sensory modality namely the tactile channel. Due to the large amount of sensitive receptors on the tongue, researchers have shown that guidance of surgical gestures such as biopsies or target hit can be achieved by electro-tactile stimulation of the tongue thanks to a Tongue Display Unit [START_REF] Vazquez-Buenosaires | Electrostimulation of the tongue as a passive surgical guiding system[END_REF], [START_REF] Robineau | Guiding the surgical gesture using an electro-tactile stimulus array on the tongue: A feasibility study[END_REF], [START_REF] Robineau | Etude d'un dispositif de guidage de geste chirurgical de ponction par stimulation lectrotactile linguale[END_REF]. Even if efficiency have been demonstrated, efforts on ergonomics, discomforts and pattern of information coding are still needed [START_REF] Robineau | Guiding the surgical gesture using an electro-tactile stimulus array on the tongue: A feasibility study[END_REF]. Other researches focused on the stimulation of the skin by vibrations. Vibrators can actually be placed on the dorsal face of the hand [START_REF] Brell | Fusion of vibrotactile signals used in a tactile display in computer aided surgery[END_REF], or mounted on a belt, worn on the abdomen, torso or forearm [START_REF] Ng | Evaluation of a tactile display around the waist for physiological monitoring under different clinical workload conditions[END_REF]. Brell et al. [START_REF] Brell | Fusion of vibrotactile signals used in a tactile display in computer aided surgery[END_REF] proposed a four vibrators tactile glove tracked by stereo cameras which indicates the correct position of the surgical tool. Results showed a less than 5 mm error to the target but problems of overshooting and oscillations during the trajectory following task. Ng et al. [START_REF] Ng | Evaluation of a tactile display around the waist for physiological monitoring under different clinical workload conditions[END_REF] demonstrated that tactile modality leads to higher reaction time compare to auditive stimulation but far lower reaction time compare to visual modality. Our project is more generally dedicated to a better characterization of the influence of these vibrotactile modalities onto the human performance during complex, online, and non straight trajectories following tasks. Since it is a surgical gesture that needs quite complex trajectories path to access the target, skull base surgery was choosed for our study.

II. MATERIAL AND METHODS

A. Vibrotactile feedbacks

The proposed solution is composed by vibrators, mounted on a belt worn by the participants around the abdomen. The control of vibration motors is provided by an USB controller card and relays (www.phidgets.com). Two design configurations were proposed, in order to experiment two different guidance paradigms. The first design (Belt1) is composed by 6 tiny vibrators (ø 6 mm) which can run with two vibration levels (≈5000 rpm and ≈2000 rpm). The activation of one of the 6 relays stands for the motor selection, the two last relays stand for the selection of the level of vibration (realized by adding resistors). The second design (Belt2) is composed by 8 vibrators whith a single level of vibration (≈5000 rpm). In that case, two mounting belts are used, each composed by four motors. The vibration motors of belts 1 and 2 are manually arranged around the abdomen of the subjects to fit their anatomy, depending on the guidance paradigm used (see below). For development purposes, not encapsulated motors are used and firmly mounted on the belt with the secure Velcro attachment. Of course, for a real use in a surgical environments, encapsulated sterilizable motors will have to be designed.

B. Guidance paradigms

Two guidance paradigms associated to the two belts use (Belt1 or 2) were proposed. Our objective was to evaluate whether participants were more efficiently guided by one belt or the other one, suggesting different mental spatial representations of the task. The level of vibration is given by the difference between the current tool orientation and the planned trajectory. If the difference is higher than half of the triggering threshold then the vibration level is high, else it is set to low. Two vibrators are placed at the back of the belt, standing for the pitch orientation of the tool. They are also sequentially activated but in parallel with the frontal vibrators. When the tool is perfectly aligned with the planned trajectory, no vibration is given to the user.

2) Guidance paradigm 2: This second guidance paradigm is based on the 8 vibrators of Belt2 (cf. figure 1,bottom). Two sets of four motors are located on the cardinal points of the two mounting belts. The higher belt stands for the proximal position of the tool (close to the hand of the surgeon), while the lower belt stands for the extremity of the tool (distal position). The activation of one of the four vibrators of each mounting belt is sequential but activation from the lower and the higher mounting belts is possible simultaneously. Activations are based on difference of the tool position and orientation to the theoretical trajectory, starting with a distance of 0.02 mm. The same yaw and pitch information are then possible.

3) Coding schemes: In addition, two schemes for direction coding are proposed, for both belts: demonstration coding, where the belt indicates the orientation to provide to the tool to be aligned with the theoritical planned trajectory; or correction coding, where the belt indicates the current alignment errors. Theses coding schemes are related in the literature as "direction coding" and "avoiding coding" [START_REF] Robineau | Etude d'un dispositif de guidage de geste chirurgical de ponction par stimulation lectrotactile linguale[END_REF].

C. Surgery simulator

To reproduce a situation similar to the actual skull base surgery and in order to quantitatively evaluate the tactile guidance, we decided to develop a virtual surgery simulator. Indeed, experiments on real anatomical pieces introduce a large amount of logistical and ethical problems (access to CT and MRI for the preoperative images, cadaver experiments). On the other hand, the uniqueness of those configurations that can not be validated by several experts or do not allow statistical analysis of large scale was not suitable for our purpose. Achieving a specific head phantom, dedicated to this experience revealed to be technically too complex and anatomically too simplistic regarding the structures to reproduce. Therefore, we used real anatomical data from a patient to build a simulator of the surgical gesture. This solution allowed us to repeat the experiment many times, with different trajectories, despite the lack of realism inherent in this type of simulators [START_REF] George | Review of temporal bone dissection teaching: how it was, is and will be[END_REF]. A general overview of the simulator is pictured in fig. 2. After registration of the preoperative data (CT and MRI), a 3D model of the patient's head based on iso surfaces generation was computed. This data set was used for the display of anatomical sections as in real computer-navigated surgery and was also used for the simulation rendering. This second role can be decomposed in two main parts: haptic rendering and visualization. Haptic force feedbacks were required for the realism of the simulation, otherwise the participants would not have been able to feel any contact with the virtual model, and therefore would not have been able to reproduce the surgery. Forces and contacts between virtual structures and surgical tools are restored to the user by a PHANToM Omni device (www.sensable.com). Stiffness values were linearly derived between 0 and 2 N from the voxels intensity of the preoperative CT exam. It is important to note here that two voxels with similar intensities rendered the same stiffness haptically. Even if these values were approximated, they allow real differences in the touch of differents structures such as bones, soft tissues, cavities, and vessels. During a real skull base surgery, the surgeon has to drill into the patient head bones. Simulating such interaction is still a complex issue [START_REF] George | Review of temporal bone dissection teaching: how it was, is and will be[END_REF] and has been solved by implementing the method proposed by [START_REF] Eriksson | A haptic and virtual reality skull bone surgery simulator[END_REF], [START_REF] Morris | Visuohaptic simulation of bone surgery for training and evaluation[END_REF]. We strongly encourage the reader to refer to [1, chap. 8] for implementation details.

D. Trajectory planning

The trajectory used for this experiment was based on the planning defined by the surgeon, regarding the location of the tumor in relation to the surrounding anatomical structures of the patient's head. A specific application was developed to enable the surgeon to visualize a merged volume from CT and MRI data, and then to determine the theoretical trajectory from the entry point to the tumor. This work was done with an ENT surgeon from the Saint Etienne Hospital, France. The final trajectory used to evaluate our tactile guidance was composed by a series of 6 straight lines, passing dorsally to the left eye orbit, and was about 10 cm long.

E. Experiment evaluation

To evaluate the effects of tactile guidance, we designed an experiment based on the previously described surgery simulator, with different conditions.

1) Experimental conditions: The introduction of two tactile guidance paradigms (Belt1 and Belt2) and the fact that two coding schemes (Demonstration and Correction) exist led us to define four guidance conditions (Belt1-D, Belt1-C, Belt2-D, Belt2-C) and one control condition where no tactile guidance was given (Visual only). Within each of these conditions, participants had visual feedbacks on the screen of the navigation system, with the 2D display of the the sagittal, axial and coronal CT slices corresponding to their tool tip current position.

2) Experimental protocol: Since we proposed two tactile guidance paradigms, specific trainings were needed. Two experiments were therefore defined. The first one acted as a familiarization step and allowed us to determine for each subject his/her preferences regarding guidance paradigms and coding schemes. This first experiment was based on a simplified training software where the user had to follow the previously defined trajectory (c.f. § D) with visual indications of the localization of vibrations. After a familiarization phase with each conditions, the participant gave us his/her preference for a coding scheme for both belt types. Then the performance of the user was assessed in a within-subjects design involving three randomized 6 trials blocks. In the second experiment, we tested for the surgery task the effect of the best tactile guidance condition compared to the control condition. The same protocol was applied: a training phase was followed by a within-subjects performance assessment of two randomized 6 trials blocks.

3) Experimental measurements: To evaluate the performances of the participants during both experiments, the current position of the tool tip provided by the haptic device was recorded at 100 Hz. Four criterions were choosen: duration and mean velocity of the complete trial (from the beginning to the end of theoretical trajectory), mean error and maximum error (computed from distances between experimental and theoretical trajectories). During the second experiment, the trials were videotaped in order to determine the amount of time the participant spent looking at the navigation screen. This gave us another criterion which stands for the use of visual information during the task: the percentage of time spent looking at the navigation system screen.

4) Participants: Because of the busy schedule of surgeons and the duration of the complete experiment (about 2 h), we decided to test first beginners population (i.e. naïve subjects). Ten subjects accepted to participate (age: 30.3±4; only males). A subject was nevertheless excluded from the study because of a recording error. The present study was conducted in accordance with the Declaration of Helsinki and was approved by the local ethic committee. It was carried out with the understanding and the written consent of each participant which was obtained before the experiment.

III. RESULTS

A. Experiment 1

After the training phase, subjects had to choose a coding scheme (either demonstration or correction) for each belt type. None of the participants choose the Belt1 with a correction coding or the Belt2 with a demonstration coding. We had therefore only three conditions to test during the performance assessment: Belt1-D, Belt2-C and Visual Only. For each measured criterion (raw data are summed up in the table I), an ANalysis Of VAriance (ANOVA) in repeated measurements (3 conditions x 6 trials) was computed. The influence of the order was not significant (as expected by the experimental protocol design) except for the mean error. Further analysis of this last criterion was cancelled. For maximum error criterion, a significant effect (F (2, 16) = 11.0; p < .01) was found between conditions. Newmans-Keuls post-hocs tests detailed this effect by showing a significant difference between conditions Belt1-D and Belt2-C (p < .01); and a significant difference between conditions Belt1-D and Visual Only (p < .01). No significant difference was found between Belt2-C and Visual Only (p > .25). Concerning duration, the ANOVA revealed no significant effect between conditions (p > .25). Finally, dealing with mean velocity criterion, a significant effect was found (F (2, 16) = 5.54; p < .05) between conditions. Post hocs tests (Newmans-Keuls) revealed significant differences between Belt1-D and Visual Only. The present study examined whether vibrotactile guidance can bring beneficial clues to realize a complex task of trajectory following, as encountered in skull base surgery. The results from experiment 1 showed a strong difference between our two guidance paradigms. The Belt1 paradigm revealed to be significantly different from Belt2 and visual control conditions, with performances that tend to be lowered, suggesting a mismatch to the underlying mental representation. Belt2 paradigm showed equivalent performances as control condition. The lack of participants choosing Belt1-C or Belt2-D suggests a cognitive inadequacy between coding and guidance paradigm. The results of the second experiment on a simulated skull base surgery showed a significant reduction of spatial errors (mean and maximum errors), a decrease of mean velocity, a significant reduction of the need for visual feedbacks (percentage of time looking at the navigation screen) and no significant differences in the duration, for the tactile guidance condition as compared to the control condition. It seems therefore that the proposed tactile guidance, even after a short familiarization period, can efficiently provide the localization information that are usually brought by the navigation systems, as emphasized by the reduction of the time passed to look at visual localization information. The interest for skull base surgery, and more generally speaking for complex on-line trajectories following, can be important with the objective to reduce the distance errors and to let the surgeon focus his/her attention to the operative field. However, this research only focused on a comparison between tactile guidance and the usual way of performing skull base surgery. A confrontation to other visual guidance [START_REF] Mozer | Computer-assisted access to the kidney[END_REF] might precise the efficiency of such tactile guidance. We also need to investigate the target population (i.e. surgeons) to see if these promising results are confirmed. For information, preliminary results with one surgeon tend to confirm the positive effect of our tactile guidance. Other in situ experiments should also be conducted but the implementation implies further developments as concerns the tool tracking.

In conclusion, a surgery simulator was used to assess if a vibrotactile guidance could be implemented for complex trajectories following task. Two guidances paradigms were proposed based on two vibrotactile belts, showing significant differences in performances for naïve participants. Results seem to be very encouraging for an application in skull base surgery but further experiments need to be conducted on experts to be more specific about the effects of this tactile guidance in real operating conditions.

Fig. 1 .

 1 Fig. 1. The two proposed guidance paradigms. Top (configuration Belt1): the spatial representation of the tool is such as the tool is going from the back to the abdomen. Bottom (configuration Belt2): the spatial representation of the tool is surrounded by the two belts.1) Guidance paradigm 1: This guidance paradigm is composed by 4 frontal vibrators located on the anterior side of the Belt1, indicating side and horizontal changes (yaw) in the orientation of the tool. Each vibrator is activated sequentially, depending on the angles figured in fig.1(top).The level of vibration is given by the difference between the current tool orientation and the planned trajectory. If the difference is higher than half of the triggering threshold then the vibration level is high, else it is set to low. Two vibrators are placed at the back of the belt, standing for the pitch orientation of the tool. They are also sequentially activated but in parallel with the frontal vibrators. When the tool is perfectly aligned with the planned trajectory, no vibration is given to the user.2) Guidance paradigm 2: This second guidance paradigm is based on the 8 vibrators of Belt2 (cf. figure1, bottom). Two sets of four motors are located on the cardinal points of the two mounting belts. The higher belt stands for the proximal position of the tool (close to the hand of the surgeon), while the lower belt stands for the extremity of the tool (distal position). The activation of one of the four vibrators of each mounting belt is sequential but activation from the lower and the higher mounting belts is possible

Fig. 2 .

 2 Fig.2. Virtual skull base surgery simulator. From the preoperative data (CT and MRI), anatomical sections are displayed on a navigation system, and a 3D model of the patient is built. This model is haptically rendered by an haptic device (PHANToM Omni) placed below a computer screen where the simulation is visually rendered. The user sees on the screen the result of his co-located manipulation. The position of the haptic tool tip is sent to the navigation system to display the current anatomical slices to the user.

TABLE I SUMMARY

 I OF RAW DATA FOR EXPERIMENT 1.

	Condition	Belt1-D	Belt2-C	Visual only
	Duration (s)	29,06 ± 3,36	21,39 ± 4,79	22,89 ± 13,71
	Mean velocity (mm/s)	23,07 ± 4,37	29,67 ± 2,79	37,19 ± 1,82
	Mean error (mm)	4,80 ± 0,44	3,01 ± 0,16	2,90 ± 0,21
	Maximum distance (mm)	16,51 ± 1,69	10,83 ± 0,61	10,65 ± 1,23
	B. Experiment 2
	Similar ANOVAs in repeated measurements (2 conditions
	x 6 trials) were computed for each criterion (raw data are
	given in table II). The order effect was not significant (as
	expected) (all p > .25). All computed criterions, except
	duration (p > .25), revealed significant differences between
	tactile conditions (Belt1-D and Belt2-C groups with respec-
	tively 2 and 7 subjects) and Visual Only condition (mean
	velocity: F (1, 8) = 7.10; p < .05; mean error: F (1, 8) =
	6.72; p < .05; maximum distance: F (1, 8) = 7.87; p < .05
	and time looking navigation screen: F (1, 3) = 11.64; p <
	.05).

This work was supported by Région Rhônes-alpes, Cluster ISLE, PPF "interaction multimodale", France.


Frédéric Cuppens

Nora Cuppens-Bouhlahia

Wael Kanoun

Yacine Bouzida

Aurélien Croissant

Nora Cuppens-Boulahia

Expression and deployment of reaction policies

published or not. The documents may come

Introduction

Intrusion Detection Systems (IDSs) are widely used to secure information systems, and became a primary component in modern security architecture solutions. Different intrusion detection techniques have been introduced and implemented in the governmental, academic and commercial information systems. Moreover, Intrusion Prevention Systems (IPSs) are highly used along with the IDSs to counter the detected threats. However, current intrusion prevention devices act only as conventional firewalls with the ability to block, terminate or redirect the traffic when the corresponding intrusion event is triggered. In other words, the intrusion response is statically associated with one (or several) intrusion event(s). Nevertheless, in [START_REF] Debar | Enabling automated threat response through the use of a dynamic security policy[END_REF] where the a contextual security policy have been defined, a policy reaction formalism was introduced. This reaction is performed globally allowing a global access control modification in an organization. However, the scalability remains an open issue that was not addressed in [START_REF] Debar | Enabling automated threat response through the use of a dynamic security policy[END_REF]. The threat context mechanism was implemented as a set of contextual rules that are triggered when the corresponding threat contexts become active. Only access control rules, i.e. permissions and prohibitions, were considered. We note that prohibitions and permissions are not appropriate to launch some actions, for instance shutting down a server immediately, or redirecting undesirable traffic (e.g syn-flooding packets)

On the other hand, the anti-correlation approach [START_REF] Cuppens | Anti-correlation as a criterion to select appropriate counter-measures in an intrusion detection framework[END_REF] allows an easiest manner to express the reaction activation along with the scalability consideration. However, the reaction within this approach is performed locally without taking into account the global framework where it is implemented. This issue motivated us to improve the contextual security policy not only by using the permissions and prohibitions, but also by focusing on obligations corresponding to actions that are inherent within the whole reaction policy framework. Another objective of our work is to combine in a coherent manner both approaches within a reaction workflow, taking into account different levels of reactions.

A system oriented taxonomy is presented in [START_REF] Stakhanova | A taxonomy of intrusion response systems[END_REF] with a classification into degree of automation and activity of triggered response. The automatic response is organized by ability to adjust, time of response, cooperation ability and response selection method. This taxonomy and others (not presented here due to space limitation) do not describe a thorough description of the response including the response strategy, duration, effectiveness and impact of the response. Toth and Kruegel [START_REF] Toth | Evaluating the impact of automated intrusion response mechanisms[END_REF] propose a cost sensitive approach that balances between intrusion damage and response cost in order to choose a response with the least impact. Lee et al. [START_REF] Lee | Toward cost-sensitive modeling for intrusion detection and response[END_REF] also discuss the need to consider the cost of intrusions damage, the cost of manual and automated response to an intrusion, and the operational cost, which measures constraints on time and computing resources.

In this paper, we propose an auto-adaptive model that starts from the security policy management of the monitored information system. The low level tools including intrusion detection and access control mechanisms that are implemented locally to monitor the information system, are configured according to the high level security specifications. Then, whenever it is necessary, some of the generated alerts are forwarded to the upper level , by crossing differ-ent levels of reaction. At the upper level, and accordingly to the detected threat, an evaluation of the current system state takes place. Consequently, either direct responses will launched or the whole security policy will be changed. We define three reaction levels; (1) low level reaction, (2) intermediate level reaction, and (3) high level reaction. Each level considers particular security requirements and deploys appropriate security components and mechanisms to react against the detected threats.

The rest of the paper is organized as the following. Section 2 presents the reaction requirements and the reaction policy expression. In particular, we develop our approach to manage the conflicts between the various operational, minimal constraints and contexts of threats. Section 3 describes the reaction deployment framework. Section 4 presents the architecture of the reaction workflow with the different reaction levels. Section 5 presents an illustrative VoIP use case. Finally, Section 6 presents future work and concludes the paper.

Reaction policy

We view a security policy as a set of requirements corresponding to permissions, prohibitions and obligations. In the security literature, it is generally considered that these requirements apply to users or processes (i.e. subjects) when they access to resources (i.e. objects) in order to execute services or programs (i.e. actions). The security policy includes requirements that apply in "normal" situations, i.e. when no intrusion occurs. We call this part the operational policy, and it typically includes access control requirements.

The reaction policy is another part of the policy which specifies security requirements that are activated when an intrusion is detected. It is a set of rules that specify what happens in case of violation (or attempt of violation) of some requirements of the operational security policy. According to these (attempts of) violations and their impacts on the target information system, new permissions, prohibitions or obligations are activated and pushed into the appropriate security components. For instance, if an intrusion occurs, and the alert diagnosis identifies the path of the attack or the targeted equipment pieces by this attack and used to reach the intrusion objectives, (1) some packet flows have to be rejected or at least redirected or, (2) some of the vulnerable equipment used by the attack have to be stopped or at least isolated to contain its spread in the whole system.

Our approach to specify the security policy is based on the an Organizational Based Access Control (OrBAC) model [START_REF] Cuppens | Modelling Contexts in the Or-BAC Model[END_REF]. In the remainder of this section, we shall first recall the basic principles of the OrBAC model, then we present how this model can be used to express the reaction policy. Finally we address the issue of security requirements conflicts.

The OrBAC model

The security policy specification is based on an expressive security model, the OrBAC model. One of the Or-BAC contributions is the abstraction of the traditional triples subject, action, object into role, activity, view . The entities subject, action and object are called concrete entities whereas the entities role, activity and view are called organizational entities. A view is a set of objects that possess the same security-related properties within an organization thus these objects are accessed in the same way. Abstracting them into a view avoids the need to write one rule for each of them. Another useful abstraction is that of action into activity. An activity (e.g. consult data) is considered as an operation which is implemented by some actions defined in the organization (e.g. read for a file and select for a database). This is why they can be grouped within the same activity for which we may define a single security rule. One of the main contributions of the OrBAC model is that it can model context that reduces the applicability of the rules to some specific circumstances [START_REF] Cuppens | Modelling Contexts in the Or-BAC Model[END_REF]. Thus, context is another organizational entity of the OrBAC model. The OrBAC model defines four predicates1 :

• empower: empower(s, r) means that subject s is empowered in role r.

• consider: consider(α, a) means that action α implements the activity a.

• use: use(o, v) means that object o is used in view v.

• hold: hold(s, α, o, c) means that context c is true between subject s, action α and object o.

Security requirements are specified in OrBAC by quintuples:

• SR(decision, role, activity, view, context) which specifies that the decision (i.e. permission, prohibition or obligation) is applied to a given role when requesting to perform a given activity on a given view in a given context. We call these organizational security rules. An example of such a security rule is:

-SR(permission, private host, open HT T P, to Internet, def ault) which corresponds to a filtering requirement specifying that hosts assigned to the role private host are permitted to open HTTP connection with the Internet in the default context (the default context is true every circumstance).

Another requirement may correspond to the following prohibition:

-SR(prohibition, any host, send IP packet, same source destination, def ault) where any host is a role assigned to every network host, send IP packet is the activity of sending IP packets, same source destination is a view that contains any IP packet with a source IP address equal to its destination IP address. This is actually a security requirement to protect the system against the Land attack.

As suggested in the RBAC model [START_REF] Sandhu | Role-based access control models[END_REF], the organizational entity role is associated with a hierarchy called sub role and security requirements are inherited through this hierarchy. In the OrBAC model, similar hierarchies to the three other organizational entities had been assigned: view, activity and context.

Using OrBAC to specify a reaction policy

The reaction policy corresponds to security requirements that are activated when intrusions occur. In OrBAC, this is modelled using special contexts called threat contexts. For this purpose, intrusion classes are associated with threat contexts. Threat contexts are activated when intrusions are detected, and are used to specify the reaction policy. The activation of these contexts leads to the instantiation of the policy rules in response to the considered threat. For instance, a Syn-flooding attack is reported by an alert with a classification reference equal to CVE-1999-0116, the target corresponds to some network Host and some Service. Then the synflooding context is specified as follows [START_REF] Debar | Enabling automated threat response through the use of a dynamic security policy[END_REF]:

-hold( , Service, Host, syn f looding) ←alert(T ime, Source, T arget, Classif ication), ref erence(Classif ication, CV E -1999 -0116 ), service(T arget, Service), hostname(T arget, Host). Notice that, since the intruder is spoofing (masquerading) its source address in a Syn-flooding attack, the subject corresponding to the threat origin is not instantiated in the hold predicate. When an attack occurs and a new alert is launched by the intrusion detection system, new hold facts are derived for threat context Ctx. Therefore, Ctx is then active and the security rules associated with this context are triggered to react to the intrusion.

Notice also that we need to define a process that maps the intrusion detection alerts onto the hold predicate. In the above syn f looding example, this mapping is voluntary simplified. As shown in [START_REF] Debar | Enabling automated threat response through the use of a dynamic security policy[END_REF], it is generally more complex because we need a mapping that has variable granularity, to take into account the different scope of different attacks. For example, a distributed denial-of-service on all areas of the network needs to be handled differently than a targeted brute-force password-guessing attack. By appro-priately defining the triples subject, action, object that are in the scope of a given threat context, it is possible to define such variable context granularity. As suggested in [START_REF] Debar | Enabling automated threat response through the use of a dynamic security policy[END_REF], a first form of reaction would be to update the access control policy by activating and deploying new permissions or prohibitions. For instance, a rule:

-R3: permission(private host, open T CP, to hostObelix, def ault) might be replaced by a new one such as:

-R4: prohibition(any host, open T CP, to hostObelix, syn f looding). In the second case, a reaction requirement may be specified by means of obligations. We may actually consider two different kinds of obligations called server-side obligation and client-side obligation. A server-side obligation must be enforced by the security components controlled by the security server and generally corresponds to immediate obligations. R5 is an example of such rules expressed in the OrBAC model:

-R5: obligation(mail daemon, stop, mailserver, imap threat) Client side obligations generally correspond to obligations that might be enforced after some delay. Several papers have already investigated this problem and suggested models to specify obligation with deadlines [START_REF] Cuppens | Nomad: A Security Model with Non Atomic Actions and Deadlines[END_REF][START_REF] Gama | Obligation Policies: An Enforcement Platform[END_REF]. For instance, if there is an intrusion that attempts to corrupt an application server by a Trojan Horse intrusion, then this server must be quarantined by the administrator within a deadline of 10s. R6 provides a specification of this requirement:

-R6: deadline obligation(administrator, quarantine, application server, trojan horse threat, bef ore( 10)) where deadline obligation can be used to specify one more attribute that corresponds to the deadline condition bef ore [START_REF] Cuppens | LAMBDA: A Language to Model a Database for Detection of Attacks[END_REF].

Obligations with deadline are more complex to enforce than immediate obligation. So, to simplify both the expression and implementation, we shall only consider immediate server-side obligations in the remainder of this paper.

Security requirements interpretation

Concrete security rules that apply to triples subject, action, object are modelled using the predicate sr(decision, subject, action, object) and logically derived from organizational security rules by the general derivation rule: RG:

SR(Decision, R, V, A, C) ∧ empower(Subject, R)∧ consider(Action, A) ∧ use(Object, V )∧ hold(Subject, Action, Object, C)
→ sr(Decision, Subject, Action, Object) When the security policy contains both permissions, pro-hibitions and obligations, conflicts between security requirements are inevitable. We can actually consider three different types of conflicts: Contradiction: A contradiction occurs when it is possible to derive, for some subject, action and object, both sr(permission, s, a, o) and sr(prohibition, s, a, o). Dilemma: A dilemma occurs when it is possible to derive, for some subject, action and object, both sr(obligation, s, a, o) and sr(prohibition, s, a, o). Inability: An inability occurs when it is possible to derive, for some subject and object, both sr(obligation, s, a 1 , o) and sr(obligation, s, a 2 , o) and it is impossible to simultaneously execute both actions a 1 and a 2 . For example, a 1 is the action stop a server and a 2 is the action start a server.

However, the approach suggested in the OrBAC model [START_REF] Cuppens | High Level Conflict Management Strategies in Advanced Access Control Models[END_REF] does not include the detection of concrete permissions, prohibitions or obligations conflicts; but it provides means to detect and manage potential conflicts between organizational rules. The solution to manage contradictions and dilemmas actually differs from the one used to manage inabibility. Management of contradictions and dilemmas. A potential contradiction (resp. dilemma) exists between an organizational permission (resp. an organizational obligation) and an organizational prohibition if these two rules may possibly apply to the same subject, action and object. The approach used to manage such conflicts is based on the definition of separation constraints assigned to organizational entities. A separation constraint assigned to two roles specifies that a given subject cannot be empowered in these two roles. Separation constraints for activities, views and contexts are similarly defined.

Thus, a potential contradiction between two organizational security rules is defined as follows (potential dilemma is similarly defined): Definition:

Potential contradiction. Two security rules SR(permission, r 1 , a 1 , v 1 , c 1 ) and SR(prohibition, r 2 , a 2 , v 2 , c 2 ) are potentially conflicting if role r 1 , activity a 1 , view v 1 and context c 1 are respectively not separated from role r 2 , activity a 2 , view v 2 and context c 2 . Management of inability. Potential inability is managed using constraints assigned to activities called antinomic constraints. We say that two activities are antinomic if it is not possible to execute these two activities simultaneously. Of course, we can use antinomic constraints to manage inability because there is no inability between two organizational obligations if these obligations are associated with antinomic activities.

Combining separation and antinomic constraints, we can now detect every potential conflict. Priorities should be associated with such potentially conflicting security rules in order to avoid situations of real conflict. Prioritization of security rules must proceed as follows [START_REF] Cuppens | High Level Conflict Management Strategies in Advanced Access Control Models[END_REF]: (1) Detection of potentially conflicting rules, (2) Assignment of priority to potentially conflicting rules.

Notice that this process is tractable because each time a new potential conflict is detected, the administrator can decide to insert a new constraint or define a new priority. Notice also that this process must be performed off-line, i.e. before the security policy is actually deployed. We then obtain a set of partially ordered security rules SR(decision, role, activity, view, context, priority). Concrete security rules can be derived from the abstract security rules and are assigned with the same priority. It has been proved in previous works [START_REF] Cuppens | High Level Conflict Management Strategies in Advanced Access Control Models[END_REF] the following theorem. Theorem: If every potential conflict is solved, then no conflict can occur at the concrete level.

Strategies to manage conflicts

We observe that most of reaction requirements are in conflict with access control requirements, i.e. the access control policy may specify a permission whereas the reaction policy specifies a conflicting prohibition that applies when an intrusion is detected. For instance, HTTP is permitted when there is no intrusion but prohibited if an intrusion on the HTTP protocol is detected. These conflicts can be solved by manually assigning priorities between requirements as suggested in the previous section. However, it is easier to automatically solve these conflicts by assigning higher priority to the reaction requirement than to access control requirements. In fact, we consider three different types of activation contexts: threat, operational and minimal.

The operational contexts aim at describing traditional operational policy [START_REF] Cuppens | Modelling Contexts in the Or-BAC Model[END_REF]. They may correspond to temporal, geographical or provisional contexts (i.e. contexts that depend on the history of previous executed actions). Since access control requirements are associated with operational contexts whereas reaction requirements are associated with threat contexts, we actually consider that threat contexts have higher priority than operational contexts.

However, there are some security requirements such as availability requirements that must be preserved even if an intrusion occurs. For instance, the access to the email server must be preserved even if some intrusions occur. This is modelled as a minimal requirement. Minimal contexts then define high priority exceptions in the policy, describing minimal operational requirements that must apply even in case of characterized threat.

Therefore, we consider two parameters to manage conflicting situations called criticality and specificity. A criticality parameter is used to assess context priority between the three defined categories of contexts operational, threats and minimal. We define an operator Ł c to assess the level of criticality of contexts, so that if Ctx is a set of well formed contexts: L c : Ctx -→ {ope, threat, min} with ope < threat < min. We define the criticality relation as follows: c 1 < c c 2 ←→ L c1 < L c2 . We consider also a specificity parameter that deals with inheritance and context composition, hierarchical specificity context inheritance. For instance, we say that c 2 is more specific than c 1 if sub context(c 2 , c 1 ). We define specificity for contexts as follows: c1 ≤ s c 2 ←→ sub context(c 2 , c 1 ) and c 1 < s c 2 ←→ c 1 ≤ s c 2 ∧¬(c 1 = c 2 ). We have then defined two strategies to assess rule priorities in case of potential conflicts and prove that they are not conflicting strategies, that is we never obtain conflicting decisions when applying them (see [START_REF] Debar | Enabling automated threat response through the use of a dynamic security policy[END_REF]).

Deployment of the reaction workflow

In Section 2, we gave an overview of the OrBAC model and how to manage the different contexts for a mapping with the current threats and how to resolve the conflicts between the security rules according to the active threat contexts. Deploying the reaction policies within a comprehensive framework needs the definition of each module and its function within the framework. The workflow model must also provide an abstract and global view of the security policy. This is the purpose of the Policy Instantiation Engine (PIE) to manage the global security policy. The PIE will have to clearly separate the global policy from its implementation in the PEPs (Policy Enforcement Points). In particular, the conflicts are to be solved at the abstract level before generating PEPs configurations. The PIE activates threat contexts and extracts a new security policy using the threat information triggered by the ACEs (Alert Correlation Engine) [START_REF] Debar | Enabling automated threat response through the use of a dynamic security policy[END_REF]. Concrete security rules are then sent by the PIE to two different modules. The rules corresponding to permissions and prohibitions are sent to the PDP (Policy Decision Point) that dispatches the policy according to PEPs realms and capabilities, and translates the policy rules to PEP-specific scripted commands. Notice that these PEPs correspond to security components such as IDSs and firewalls. Rules corresponding to obligations, are sent to another component called RDP (Reaction Decision Point) that translates the corresponding rules, such as shutting down an HTTP server or redirecting an undesired traffic generated by the syn-flooding attack, into REP (Reaction Enforcement Points) capabilities.

Figure 1 presents the components of the reaction workflow with the different links and information exchange between these modules. We describe, in the following, the different modules and their functions and goals within the suggested reaction workflow deployment framework. The inputs, outputs, configurations and functions of the different modules are summarized in Table 1.

Security policy management. This module describes two different data types. The first deals with the security objectives that are specified as a set of security states. The violated states are then derived using the security objectives defined within the security policy management. These security objectives are expressed using a predefined set of LAMBDA predicates (due to space limitation, we do not develop more this point in this paper) [START_REF] Cuppens | LAMBDA: A Language to Model a Database for Detection of Attacks[END_REF]. Such violated states are then used by different modules. In particular, the ACE uses these violated objectives in order to provide a global diagnosis of the current attack scenario performed by the attackers. The second data type deals with the policy definition where two kinds of security rules are distinguished:(1) permissions or/and prohibitions and (2) obligations. Notice that while the instantiated access control policy rules are pushed by the PIE to the PDP the obligations rules are pushed to the RDP.

System management. This module includes the operational context data and the topology information. The working hours context is an example of operational context data. These contexts may be combined with threat contexts (see section 2.4) and are used by the PIE to activate the right security rules. The information topology part describes the topology of the information system under monitoring such as information about network nodes (routers, servers, etc.), security components (IDSs, Firewalls, etc.) and so on. RDPs and PDPs use the topology information provided by the system management for appropriate reactions and PEPs and REPs components choice decisions.

Alert Correlation Engine (ACE). Generally, information produced by detection intrusion probes cannot be considered on their own. Indeed, this information actually comes from many sources and with different formats (ex: a Snort alert, a Netfilter firewall log, etc.). Moreover, there is a strong need for alerts volume reduction, semantics improvement and attacker recognition. Alert correlation, preceded by alert aggregation and fusion, aims at realizing these tasks, thus permitting false positives reduction and producing meta-alerts offering a better semantics and severity levels for more efficient analysis. The ACE constructs ongoing attack scenarios according to the alerts generated by the sensors. We use a semi-explicit ACE as suggested by CRIM (http://www.crim-platinum.org/). Note that other ACEs, such as that presented in [START_REF] Ning | Constructing Attack Scenarios Through Correlation of Intrusion Alerts[END_REF], may be also used within our workflow. This correlation engine uses a description of elementary attacks in the LAMBDA language [START_REF] Cuppens | LAMBDA: A Language to Model a Database for Detection of Attacks[END_REF] to construct ongoing scenarios according to the alerts generated by the sensors. The security objectives are defined in the policy management level and are taken into consideration by the ACE to detect any violations of these objectives. Notice that an explicit ACE can also be used. However, by contrast to a semi-explicit ACE, it cannot handle alerts generated by anomaly detection systems, which correspond to When it receives a policy instance, in our case an OrBAC concrete rule (permission or prohibition), a PDP has to map each policy instance onto concrete actions to enforce the policy on PEPs. A PDP thus has to be aware of its PEPs, so that it can translate first the rules into generic configurations, considering the kind of PEP (e.g. a firewall), and then the generic configurations into specific configurations, depending on the PEP implementation (e.g. a "Netfilter" firewall) [START_REF] Cuppens | A formal approach to specify and deploy a network security policy[END_REF]. Note that part of the decisional capability of the PDP relies on the fact that a given concrete policy rule may provide different actions on the PEPs. For instance, depending on the architecture of the information system, reconfiguring access to mail user accounts may be realized on the service itself, (e.g. pop3 service native configuration files) in the case of dedicated services, or at the infrastructure level (e.g. reconfiguration of Active Directory) in the case of federated services environment. A PDP should choose the most appropriate PEPs under its view relying on topology information made available.

Reaction Decision Point (RDP).

The RDP decides which reactions should be triggered according to the attack scenarios received from the ACE. It has all the topology information of the network it is charged to react on. It manages the obligation activations received from the PIE without conflicting with the minimal security policy. The obligations are expressed as OrBAC concrete rules. The reaction decision is taken by considering the topology information of the monitored system, the reaction obligations and the impact of the elected reactions [START_REF] Kanoun | Advanced reaction using risk assessment in intrusion detection systems[END_REF]. A diagnosis is also sent by the RDP to the PIE and handled at the high reaction level.

Policy Enforcement Point (PEP). The PEPs are the elements that enforce security policy decisions. They are fed with new policy instances that are translated and then sent by the PDP. Expressing new policies may have implications on different PEPs. For instance, an attack targeting a server may lead to a reaction which involves both the server (stopping the service) and a firewall (blocking the corresponding port). Each selected PEP for a policy instance is sent a configuration script considering both its type (for example IDS) and its implementation (such as Snort). In this architecture, we suggest not to create a distinction between PEP and sensors, but to consider that sensors are a special type of PEPs.

Reaction Enforcement Point (REP). This module launches the reactions either immediately or after receiving a reaction activation from the RDP. It can also activate an immediate reaction that might be embedded in the alert signature. In this case, an immediate reaction is directly activated and launched by the REP. We notice that a PEP and REP have two different functions and may be implemented in the same software of hardware device.

Reaction workflow architecture

Figure 1 presents the workflow deployment including the different modules. Three different reaction levels coping with the security requirements are determined in this framework; low level, mid level and high level reaction. In the following we describe the implementation and configuration of each level.

Low level reaction

We define low level reaction as the action that is possible to execute automatically just after an intrusion is detected. In the reaction policy, this corresponds to an obligation to immediately execute this action. We should note here that the reaction must be consistent with the minimal security policy. For example, if a service should be active for any circumstance then a reaction, which consists in stopping this service, should not be launched. Different immediate reactions may be activated. For example, the Snort IDS tool offers different manners to respond to an alert. The following signature is an example of such a reaction: alert tcp any any <> 192.168.1.0/24 80 (content: " bad.html"; msg: "Not for children!"; react:block). A security officer may either add a tcp-reset option specified directly in the corresponding rule or use the inline snort capability that is interfaced with iptables hence permitting to drop the packet. However, we argue that the inline option is more appropriate since it does not let the targeted party receive the malicious packet when a drop option is used. The DDoS [START_REF] Bouzida | Detecting and Reacting Against Distributed Denial of Service Attacks using Alert Correlation[END_REF] architecture is a good example of this situation when the agents are receiving the order to flood the victim and the reaction only consists in resetting the corresponding connection between the masters and the agents.

The REP and PEP are two modules involved in the low level reaction (Figure 2(a)). The PEP in this level detects the intrusion while the REP performs a direct reaction over the detected intrusion. In this case, the REP and PEP are implemented in the same device. For the snort rule example presented above, a reaction that consists in blocking a forbidden website is launched once the "bad.htm" content is seen. We notice that the low level reaction rules are configured by the different scripts issued from the PDP. However, whether a counter measure is effective at this level is not a shortcoming for the global security vision since the other two reaction types at the upper architecture levels look for an in-depth reaction.

Mid level reaction

The low reaction defines an appropriate reaction which is generally specified within a signature. At the mid level, intrusion alerts and the different immediate reaction information coming from the lower level are used as an input for aggregation, fusion and correlation functions CRIM in order to construct a local ongoing attack scenario that follows the steps of an attacker(s) and determine his objective(s). These functions are performed by the ACE (Figure 2(b)) using a semi-explicit correlation mechanism [START_REF] Cuppens | Alert Correlation in a Cooperative Intrusion Detection Framework[END_REF].

However, at the mid level, we do not push reactions corresponding to obligations explicitly specified in the reaction policy. Instead, anti-correlation [START_REF] Cuppens | Anti-correlation as a criterion to select appropriate counter-measures in an intrusion detection framework[END_REF] is used as a way to find automatically a set of counter measures in order to stop not elementary actions but the global attack scenario. Some correlation and fusion tools, implemented during the last decade, provide a set of counter measures that may be either activated automatically or let the administrator choose the appropriate ones for security agility considerations [START_REF] Petkac | Security agility in response to intrusion detection[END_REF].

Notice that a diagnosis is derived within this step for improving the reaction process. Activating an automatic or a manual response depends on the confidence level of the diagnosis and the automatic choice may be performed by measuring the impact of the corresponding reaction [START_REF] Kanoun | Advanced reaction using risk assessment in intrusion detection systems[END_REF].

High level reaction

The mid level reaction takes advantage of the low level reaction actions and the selected reactions to stop ongoing attack scenarios. However, these two reaction levels do not consider an in depth revision of the global security. This suggested the introduction of the high level reaction that aims to evolve the security policy of the monitored system according to the current threat. The first input data at this reaction level corresponds to the correlation and intermediate reaction alerts emanating from the intermediate reaction level. A global diagnosis is drawn using these input data. Using the global security policy and the different threat and operational contexts, contextual policy rules are applied when the corresponding contexts become active. Therefore three functions, should be performed at this level; activating contexts [START_REF] Debar | Enabling automated threat response through the use of a dynamic security policy[END_REF], triggering generic policy rules accordingly and producing a consistent set of rules to deploy while ensuring conflict resolution with the minimal security requirements. As a result of this level, a new security policy is redeployed as long as the threat or its consequences remain present. Figure 3 shows the different modules involved in the high level reaction mechanism. We note that the mid level only complies with the minimal security policy and the different counter measures are taken from the vision of the attack scenario issued from the short term level while the high level uses the global security policy and activates policy rules according to threat contexts.

VoIP use case

The case study we present is a VoIP framework that illustrates the effectiveness of our reaction process. The considered attacks are those targeting the SIP [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF] (Session Initiation Protocol) emerging protocol that has seen an increasing interest from academia and industrial communities. Many soft and hard SIP components are currently developed and widely used by Telco operators who are offering VoIP service mostly with little or no security issues. We give an example for reacting against attacks targeting ISP and VoIP infrastructures.

The architecture that we have used in our use case is the IMS [START_REF]The 3rd Generation Partnership Project[END_REF] framework. Many Telco operators are interested in IMS, and even some of them had deployed it.

The architecture (see Fig. 4) is composed of different SBCs (Session Border Controllers) that filter all the incoming traffic from Internet or legitimate clients. Since SBCs cannot filter all undesired traffic, VoIP intrusion detection system tools, such as that developed in [START_REF] Bouzida | Detecting anomalies in VoIP networks[END_REF], are deployed behind these SBCs to detect different attacks using some vulnerabilities of the SIP protocol. Other emerging VoIP IDSs [START_REF] Sengar | VoIP Intrusion Detection Through Interacting Protocol State Machines[END_REF], based on state machine analysis similar to previous works such as NetStat [START_REF] Vigna | Netstat: A network based intrusion detection system[END_REF], may be used as a complementary IDS in our framework. Since this tool is not made available, we only consider that presented in [START_REF] Bouzida | Detecting anomalies in VoIP networks[END_REF]. One of the attack scenarios we consider is described in Figure 5. Generally, an attacker has to perform several actions in order to achieve her goal. In our example, the attack scenario is composed of 3 elementary attacks. In the first step, the attacker tries to collect valid identities corresponding to legitimate clients in the operator database (HSS in our case). This attack may be omitted particularly for those identities that are present in the red lists. However this attack is tested in platforms of different operators and the experiments were successful [START_REF] Bouzida | Detecting anomalies in VoIP networks[END_REF]. The second step consists in guessing the password of the legitimate identity discovered during the first step. The attacker sends REGISTER messages with different passwords using a dictionary. The http-digest mechanism is followed and according to the answer, he may follow up his attack. Once the attacker has guessed the password he may either perform a denial of service against a server such as the P-CSCF, or against a client by sending an infinite loop of INVITE, BYE. Notice that the BYE request is sent when the OK response from the callee (i.e. the target client answers to the call) is received. This will keep the callee phone ringing and unavailable as long as the attacker have not ceased the last attack. However, there is no reaction that could be taken within the current IMS framework [START_REF]The 3rd Generation Partnership Project[END_REF].

Table 2 gives the mapping between the different logical modules we proposed in the previous sections and their We note that all the elementary attacks have been detected by the VoIP IDSs [START_REF] Bouzida | Detecting anomalies in VoIP networks[END_REF] used in our platform. These elementary attacks are collected by these IDSs and forwarded to the CRIM-ACE for building the corresponding attack scenario.

Using our approach, the reaction according to the three levels workflow is described as the following: Low level reaction. Once the directory scanning attack is detected, the VoIP IDS sends the alert to the CRIM engine and sends, in the mean time, a new reaction to the SBC that consists in adding a rule for decreasing the rate of the requests coming from (1) the IP address of the attacker if this attacker is a client of the our ISP or (2) the couple (IP address, the SIP Via field) when the requests originate from a foreign ISP. This is due to the IP and logical SIP URI spoofing reasons. Mid-level reaction. If the attacker does not stop at the first stage and continues towards the password guessing attack then the corresponding scenario is constructed thanks to the VoIP IDS alerts and the CRIM engine. At this stage, the RDP implemented aside the CRIM engine takes a reaction decision that consists in reconfiguring the P-CSCF in order to stop answering the requests originating from the attacker IP and logical addresses. The P-CSCF may stop forwarding these requests to the concerned servers and may log these requests for forensic analysis. One possible obligation rule corresponding to stop forwarding the requests by the P-CSCF is as follows: SR(obligation, P -CSCF, stop f orwarding, attacker, password guessing threat). High-level reaction. The attacker may have guessed the password and starts various attacks such as disturbing other legitimate clients by sending infinite INVITE requests followed by the BYE method every time the target client tries to answer. At this stage, the CRIM engine sends the whole detected attack scenario to the application server (AS) that plays the role of the PIE. The "DoS against a client" threat context is activated and the corresponding abstract OrBAC rules are generated. One possible abstract rule related to this context is: security rule(prohibition, attacker, request, any, dos client threat). The concrete rule derived from this OrBAC abstract rule consists in blacklisting the attacker at the edge SBC.

Conclusion

In this paper, we have presented a novel process for expressing reactions and the corresponding architecture that aim at reacting against threats using different levels. In the low level, reactions are configured a priori within the security components configuration for an immediate reaction. The mid level reaction tries to counter the ongoing attack scenario by launching an appropriate counter measure. Finally, the high level reaction is performed by using the contextual policy that builds upon the OrBAC formalism. The proposed approach is robust since the different security components are configured from a high level point of view and the reactions against the detected threats cross three levels for applying the best reaction issue. The use case example we have developed and tested within a real Telco operator demonstrates the effectiveness of our proposal within the new generation networks. The different attacks were successful against different operators' infrastructures and are detectable by the VoIP IDS. The different reactions applied at each level allowed decreasing the effects of the threat and stopping it at the last stage without the intervention of a human security officer. Our first future work consists in applying the different reactions in a transactional mode since in some situations conflicts may occur between the different reactions that are launched in the different levels. The other direction consists in considering novel attacks within this workflow for a better reaction.

  Mid level reaction loop.

Figure 2 .Figure 3 .

 23 Figure 2. Low and Mid levels reaction workflow.

Figure 4 .

 4 Figure 4. Framework architecture.

Figure 5 .

 5 Figure 5. VoIP attack scenario.

Table 1 . Functions of the different modules.

 1

			Policy Management		System Management
			Security Objectives	Policy definition			Context Data	Topology information
			RED Node
			Alerts		PIE	Global Access Control Policy Rules
		Implicit/Semi-
		Explicit		Alerts
		ACE			Reaction
			Alerts	RDP	obligations
				Reaction Activation		PDP
		Explicit
		ACE
						Configurations Scripts	Configurations Scripts	Configurations Scripts
				Reaction
				Activation
		Alerts			REP/PEP	PEP	(Anomaly) PEP
							New Alert/
							Diagnosis
			Figure 1. Reaction workflow deployment.
	Module Input	Output		Configuration	Function
	ACE	idmef messages	idmef messages	External	security	Verify and update information in idmef
					reference databases	messages for threat assessment.
	PIE	idmef messages	Policy rules		Policy and context	Activate threat contexts. Extract a new se-
					definitions	curity policy from the active contexts.
	RDP	idmef messages, set	Reaction activation			Reinforce the Immediate Reaction with an
		of local configura-	actions (scripts)			accurate diagnosis, an impact assessment
		tions					and a larger choice of possible reactions.
							Decide on the appropriate reaction and
							activate reactions according to the REP-
							specific.
	PDP	Policy rules	Config scripts	Policy to script	Segment the policy according to PEP
					translation rules	realms and capabilities, and translate the
							policy rules to PEP-specific scripted com-
							mands.
	REP	Reaction activation	Reaction actions			Launch the reaction orders received from
		actions					the RDP in the case of the short term reac-
							tion and from PEPs in the case of immedi-
							ate reaction.
	PEP	Config scripts	idmef messages			Apply the configuration script that imple-
							ments the security policy.
	new attacks. The correlated alerts are then sent to the PIE	policy instances (concrete rules) to deploy. As suggested
	for global reaction and to the RDP for appropriate decision	in section 2.3 conflict resolution is ensured at the abstract
	on the possible reaction instances.				level; i.e. the conflicts are detected and resolved by exam-
	Policy Instantiation Engine (PIE). The security policy is	ining abstract security rules and defining a partial order re-
	specified by a set of rules whose activation depends on con-	lationship between conflicting rules.
	textual data. Thus, a PIE has two major functions: (1) acti-
	vate contexts which (2) trigger re-evaluation of the security
	policy (abstract rules). The PIE manages conflict resolution
	at the policy evaluation level to produce a consistent set of

Policy Decision Point (PDP). It is the element where security policy decisions are made. Policies instantiated by the PIE according to threat contexts are transmitted to one or more PDPs.

Table 2 . Logical module and network compo- nent module mapping.

 2

	Logical modules	Network component
	PEP	VoIP IDS, SBC, P-CSCF
	REP	SBC,P-CSCF
	ACE	CRIM Correlation engine
	RDP	CRIM anti-correlation engine
	PDP	Application server
	PIE	Application server
	corresponding network components present in our use case
	framework.

In OrBAC, the organization is made explicit in every predicate but here, to simplify, the organization is left implicit since we consider always only one organization.

Acknowledgment

This work was partially supported by the European CELTIC ReD project. The authors would like to thank all the other partners for their participation and contribution.


Wael Kanoun
email: wael.kanoun@telecom-bretagne.eu

Nora Cuppens-Boulahia

Frédéric Cuppens
email: nora.cuppens@telecom-bretagne.eu

Automated Reaction based on Risk Analysis and Attackers Skills in Intrusion Detection Systems

Keywords: Intrusion detection system, attack scenario, countermeasure, risk analysis, potentiality, impact, skill and knowledge

Current intrusion detection systems go beyond the detection of attacks and provide reaction mechanisms to cope with detected attacks or at least reduce their effect. Previous research works have proposed methods to automatically select possible countermeasures capable of ending the detected attack. But actually, countermeasures have side effects, can be as harmful as the detected attack and not adapted to the attacker's actions. In this paper, we propose to improve the reaction selection process by giving means to (i) quantify the effectiveness and select the countermeasure that has the minimum negative side effect on the information system by adopting a risk assessment and analysis approach, and (ii) assess the skill and knowledge level of the attacker from a denfensive point of view.

Introduction

In intrusion detection approach, the primary objective is to detect and identify attacks, and then react to counter the detected attack to block it or to mitigate its impact on the Information System (IS). There are two different approaches for the reaction perspective: hot reaction [START_REF] Gombault | Selecting appropriate counter-measures in an intrusion detection framework[END_REF] and policy based reaction [START_REF] Debar | Enabling automated threat response through the use of a dynamic security policy[END_REF]11]. The first aims to launch a local action on the target machine to end a process, or on target network component to block a traffic, that are the cause of the launched alerts. The second acts on more general scope; it considers not only the threats reported in the alerts, but also constraints and objectives of the organization operating the IS and this by modifying the access control policy. Therefore a trade-off can be established between security objectives, operation objectives and constraints. Whatever the adopted approach, each countermeasure can have negative or positive side effects. The same countermeasure that was activated to end an attack can make the IS more vulnerable, expose it to other attacks, or even have an impact more disastrous than the attack itself. For example Firewall reconfiguration is effective against a DOS attack, but can be very harmful if valuable connections will be lost, therefore many questions emerge: Is it better to stand still? Or is the attack harmful enough to react? In this case, which countermeasure must be selected with minimum negative side effects? To answer these questions, we adopt a Risk Assessment and Analysis approach. This approach is already used to analyze and evaluate the risks that threaten organization assets. Our approach is to use the same approach to evaluate the effectiveness of each countermeasure in real time and improve the automated reaction mechanism. The first step of a risk analysis method is to collect data that describes the system state in real-time. The second step is analyzing them and finding the potential threats and their severity. The final step is to study the countermeasure effectiveness to eliminate these threats or reduce their severity: The goal is not always to block the attack, but to minimize the risk incurred by target information system. Therefore a risk assessment method is used to evaluate and quantify the risk of an attack and its countermeasures. The method is useful to decide when it is suitable to react, and which countermeasure should be activated. Another important aspect is the Attackers Skills and Knowledge level (SK Level). Such data is useful for the automated reaction process. If a novice script kiddie attacker is trying to establish a remote session, a simple TCP reset will be enough to eliminate the detected attack. Otherwise, in the case of an experienced attacker, the TCP reset can be ineffective and a firewall reconfiguration may be needed. Therefore assessing the SK Level make the reaction decision module more accurate and effective. We can assume that a Risk Assessment and Analysis approach combined with the assessment of the Attackers Skill and Knowledge level make the automated process of reaction and countermeasure selection more accurate, realistic, cost effective, and with minimum intervention of the human administrator. In section 2 our solution using risk analysis and skill and knowledge assessment approaches, and an implementaion is showed in section 3. In section 4 related works are presented. Finally section 5 concludes the paper.

Solution

To react against attacks, a fine and efficient diagnostic procedure to detect and identify the intrusions is needed. However, due to the limitation and unreliability of the intrusion detection probes like SNORT [8], only low-level events can be detected with high rates of false alarms. Therefore, to detect and recognize the current attack, an alerts correlation procedure is required for proper reaction. The correlation procedure recognizes relationships between alerts in order to associate these alerts into a more global intrusion scenario, and the intrusion objectives that violate the predefined organization security policies. There are many approaches that can be used for this purpose: implicit [START_REF] Lippmann | Using key string and neural networks to reduce false alarms and detect new attacks with sniffer-based intrusion detection systems[END_REF], explicit [START_REF] Huang | A large-scale distributed intrusion detection framework based on attack strategy analysis[END_REF][START_REF] Morin | Correlation of intrusion symptoms: an application of chronicles[END_REF] and semi-explicit [START_REF] Cuppens | Recognizing malicious intention in an intrusion detection process[END_REF][START_REF] Ning | Constructing attack scenarios through correlation of intrusion alerts[END_REF] correlations. The semi-explicit approach is based on the description of the elementary intrusions corresponding to the alerts. This approach then finds causal relationships between these elementary alerts and connects these elementary alerts when such a relationship exists. The correlation procedure then consists in building a scenario that corresponds to an attack graph of steps corresponding to the elementary intrusions.

Semi-Explicit Correlation Definition Two LAMBDA models A and B are anticorrelated if the post-condition of A matches the pre-condition of B. This semiexplicit [START_REF] Cuppens | Recognizing malicious intention in an intrusion detection process[END_REF][START_REF] Ning | Constructing attack scenarios through correlation of intrusion alerts[END_REF] approach is more generic and flexible because only the elementary steps are defined as entities and not the whole attacks scenario. The LAMBDA [START_REF] Cuppens | Lambda: A language to model a database for detection of attacks[END_REF] language can be used to describe these elementary steps by defining their pre-conditions and post-conditions. Regarding reaction, it is also the most interesting because it provides a precise diagnosis of the ongoing intrusion scenario by construction the attack graph, predict the potential future steps and the intrusion objectives.

Using an approach similar to the one used to describe elementary intrusions, elementary countermeasures can be specified. In this case, anti-correlation [9] can be used to find the countermeasures capable of ending a detected scenario.

Anti-Correlation Definition Two LAMBDA models A and B are anti-correlated if the post-condition of A matches the pre-condition negation of B. The anticorrelation [9] approach is based upon finding the appropriate countermeasure that turn an elementary future step of an attack inexecutable due to preconditions value modifications. Therefore, using the anti-correlation approach, the administrator knows which countermeasures from a predefined library are capable of blocking the threat.

Risk Assessment Model

As explained in the previous section, the anti-correlation approach [9] can be used of generating a set of candidate countermeasre capable of ending the detected attack, but without assessing the impact of the detected attack nor these candidate countermeasure. Therefore, this reaction approach can be refined by combining it with the risk analysis model proposed in [START_REF] Kanoun | Advanced reaction using risk assessment in intrusion detection systems[END_REF]. This model is used to evaluate the Total Gravity Risk of the IS once an attack is detected and after the simulated execution of the candidate countermeasure. Only the countermeasures that reduce the Total Gravity Risk are kept and a new set of Risk Efficient Countermeasures (RISK EFF CM) is instantiated. The Total Risk Gravity can be assessed after evaluating the Potentiality (POT) and the Impact (Imp) of the detected attacks. The structure of the model is described in Figure 1.

Potentiality P ot The major factor Potentiality P ot measures the probability of a given scenario to take place and achieve its objective with success. To evaluate P ot, we must first evaluate its minor factors: natural exposition Expo and dissuasive measures Diss and we have to take into account classification of the attack also. The minor factors can be evaluated after the appropriate audit clusters are calculated. These clusters are questions-tests that aim to evaluate the system state (active services, existent vulnerabilities, etc.). The value zero indicates that the studied scenario is impossible, and the value MAX VALUE indicates that the occurrence and the successful execution of the scenario are inevitable. --→ Imp is defined as a vector with three cells that correspond to the three fundamental security principles: Availability Avail, Confidentiality Conf and Integrity Integ. Therefore, with each Intrusion Objective, a vector --→ Imp is associated and should be evaluated. Actually, it is not possible to statically evaluate --→ Imp of a scenario (or more precisely the --→ Imp of the scenario's intrusion objective) directly because it depends on several dynamic elements. The impact depends on the importance of the target assets ---→ Class, and the impact reduction measures level -→ IR that are deployed on the system to reduce and limit the impact once the attack was successful.

Risk Gravity of an Attack Scenario or a Countermeasure Grav For each detected attack, the risk gravity must be evaluated to estimate the danger level of this attack. The risk is the combination of Potentiality and Impact using a predefined function f . An attack that occurs frequently with little impact may have the same risk level as another rare attack that have significant impact. If a scenario has P ot or Imp equal to zero, the scenario's gravity risk Grav will be null. To assess the risk Gravity of a candidate countermeasure CM u , the same function f is used to assess the risk as shown in the following equation:

G CMu = f (P ot = MAX VALUE, Imp = CM u .Impact) (1)
The use of MAX VALUE for the Pot parameter is justified by the fact that countermeasures, contrary to detected attack scenarii, do not have intrinsic potentiality. This can be explained by the fact that once a countermeasure is se-lected, it must be activated successfully in the IS and therefore its impact must be considered with maximum potentiality. For the attack scenarii, each one has a proper potentiality that must be combined with the attack scenario impact to deduce the risk gravity.

Total Risk Gravity T otal Grav and T otal Grav u In most situations, the correlation and reaction modules do not deal with one specific scenario. Instead, these modules have to take into account many candidate and even simultaneous scenarios. Therefore, before estimating the total gravity of risk, we must evaluate the gravity of risk of each scenario separately. Then we define the Total gravity as an ordered vector containing the values of gravity risk of each candidate scenario. An order relation can be defined between the different instances of --------→ T otal Grav using the lexicographic comparison. Therefore we are able to judge which graph has the highest risk gravity. We define also ---------→ T otal Grav u similarly to --------→ T otal Grav, where the difference is that ---------→ T otal Grav u is assessed with the new state of the information system after the simulated execution of the countermeasure CM u .

Risk Efficient Countermeasures Set Once for each countermeasure u, G CMu and ---------→ T otal Grav u are evaluated, -------------→ T otal Grav CM u can be evaluated :

-------------→ T otal Grav CM u = ---------→ T otal Grav u ∪ G CMu (2)
Now, only the countermeasures from Anticorrelated CM that decrease the total gravity risk are kept and a new set Risk Ef f CM is defined that contains only risk efficient countermeasures:

∀CM u ∈ Anticorrelated CM ; -------------→ T otal Grav CM u ≤ --------→ T otal Grav (3) ⇒ CM u ∈ Risk Eff CM

Skill and Knowledge Assessment

To react properly against a detected attack scenario, the choice of countermeasure depends on the attacker's skill and knowledge level. To end an attack executed by a novice, a simple close connection can be effective, which it is not the case when facing an expert attacker where a firewall configuration is needed. Therefore, the assessment of the Attacker's Skill and Knowledge Level would be very useful to tune our reaction model. In fact, it would be useless to activate a complex countermeasure against a beginner; or to activate a simple countermeasure against an expert attacker who can easily bypass it. Another point is that the attacker can have internal knowledge of the information system. For instance, a remote attacker that have the proper credentials and is able to connect from the first attempt, or an attacker that is able to predict the tcp sequence of a connection that uses a complex algorithm (and not use the standard tcp sequence number incrementation algorithm), must be taken in consideration that they have internal knowledge and/or high level of expertise.

SK Level Label

To assess the Attacker's Skill and Knowledge, a defensive point of view must be adopted. The only information of the attacker's action accessible by the target information system is the generated alerts for each executed step in the attack scenario. Each step is described with a specific language like LAMBDA [START_REF] Cuppens | Lambda: A language to model a database for detection of attacks[END_REF]. We propose to add a new label called SK Level (Skill and Knowledge level). For the attack actions, this label indicates the minimum level of skill and knowledge required to execute this action-step successfully. For the countermeasure, it indicates the value of this level that the attacker can not bypass once it is activated. This new label can have the values shown in Table 1. The correlation engine by determining the executed attack steps by an attacker, is capable of assessing the attacker's level of skill and knowledge Attacker SK Level. The first approach to evaluate Attacker SK Level can be done using the following equation:

Attacker SK Level = M ax i (SK Level i ) (4)
where SK Level i = Attack Step i .SK Level and Step i ∈ Executed Steps A possible method is to set honeypots [START_REF] Krasser | The use of honeynets to increase computer network security and user awareness[END_REF][START_REF] Yin | Honeypot and scan detection in intrusion detection system[END_REF] and redirect the attacker to execute his/her attack steps on them. This will be used to collect the maximum number eof xecuted steps to assess accurately his/her SK Level.

Once the Attacker SK Level had been assessed, only the countermeasures from Risk Eff CM such that the SK Level is higher than Attacker SK Level are kept, and a new set called SK Eff CM (See Figure .2) can be defined and instantiated countermeasures:

∀CM u ∈ Risk Eff CM; Attacker SK Level ≤ CM u .SK Level (5)
⇒ CM u ∈ SK Eff CM

Countermeasure Selection Procedure

Once the Risk Eff CM and SK Eff CM have been instantiated (See Figure 2), a clear automatic procedure can be applied to select the most appropriate countermeasure :

If SK EF F CM = ∅ Select(M in SK Level (CM u )) If Risk EF F CM = ∅ Select(M in Risk (CM u )) Select(None)
3 Implementation of the Solution CRIM (Correlation and Recognition of Malicious Intentions) [10] is a prototype that has been developed by Telecom Bretagne. It implements the fusion, semi explicit correlation and anti-correlation features using the LAMBDA language. It collects the generated alerts and aggregates them. Then CRIM visualizes the detected attacks in real time, the future steps that can be executed by the attacker using the semi-explicit correlation principle, and the candidate countermeasure using the anti-correlation principle. As a proof of concept, a new module has been created to validate our proposal briefly described in the previous sections. As shown in 3, this module is used to assess the Risk Gravity of the detected attack scenarii and the candidate countermeasures, then it instantiates the Risk Eff CM countermeasure set. A first version of this module has been developped, but no public version is yet released. Another module takes in charge of assessing the Attackers SK Level and compare it to the SK Level of the countermeasures that belong to the Risk Eff CM, then it instantiates the SK Eff CM set. Once the two sets are instantiated, the selection procedure can be applied to activate the most appropriate and effective countermeasure. Works has begun to develop a first version of the module.

The Figure 3 shows the output of the CRIM prototype corresponding to the detection of the Mitnick attack.The mitnick attack aims to gain remote illegal shell by causing a DoS to a legal machine and then "stealing" its preestablished tcp connection with the target machine. The attack graph generated by CRIM using the LAMBDA language [START_REF] Cuppens | Lambda: A language to model a database for detection of attacks[END_REF] is composed of four elementary steps . We suppose that the attacker was capable to execute successfully the first three steps. Therefore one final step remains before the attacker achieves his or her intrusion objective Illegal Remote Shell on a critical machine. Dark green circles represent elementary steps of the intrusion scenario, light yellow losanges correspond to candidate reaction and boxes are intrusion objectives.

The attacker has executed successfully the first three steps, and thus only one step remains. Therefore the potentiality and therefore the Total Risk Grav have high values (=4 ). In other hand, the Attacker's SK Level = Max(1,3,2) = 3.

There two candidate countermeasures are capable of reducing the total gravity risk from 4 to 1 (See Total Risk CMx in Figure 3, therefore the two countermeasures are in the Risk Eff CM. The Attacker's skill and knowledge level is three and that indicates the fact he or she is not a novice. Thererfore a block connection that has a SK Level = 2 could be not efficient and a firewall reconfiguration that has a SK Level = 3 is needed. Hence only the second countermeasure is in SK Eff CM and recommended to be launched.

Related Works

Intrusion detection systems with reaction capabilities like SNORT [8] already exist. SNORT offers reflex reaction when a given attack is detected like blocking packets, sending visible warning and logging. No advanced reasoning on the reaction consequence is conducted, and side effects could appear with devastating consequences. Many industrial solutions exist like IBM Internet Security [5] and Cisco Secure IDS [2]. These solutions are efficient in intrusion prevention and offer protection against well known attacks with the corresponding impact using . The main drawback is that there is no following up and no monitoring of the detected attacks to assess their risks and impacts in real time once they bypassed the security and prevention measures, dependably on the target organizations and assets. Another limitation is that these solutions handle vulnerabilities exploit without considering the complete scenarii. There are several Risk Assessment methods like EBIOS [7, 1], MARION [3], MEHARI [4], etc. These methods are used to manage system assets and evaluate the risk that threatens these assets; they are unfortunately abstract, informal and incompatible with intrusion detection and computer systems: Many elements and parameters are related to physical and nature disasters (fire, earthquake, failure, etc.). There are also elements that need redefinition to be compatible with the intrusion systems like potentiality and impact of a threat. As suggested in [START_REF] Sauvé | On the risk exposure and priority determination of changes in it service management[END_REF], the risk exposure can be evaluated in terms of business perspective by using financial metrics. Another problem is that these methods can not be used in real-time. Our goal is to evaluate the system and the available countermeasure actions in real-time to help the administrator to chose the best action, or to make the reaction process automatic with minimum human intervention.

A first version of the Risk Analysis module has been implemented, and current works is being conducted to develop the Skill and Knowledge Assessment module. Series of tests will be conducted to evaluate the effectiveness and the performance of these added First, the tests will handle classical attacks (e.g. Mitnick Attack, Password Guessing, etc.). In the future, attack and countermeasure will be modeled with LAMBDA models, and attacks simulations will be conducted for VoIP services: CRIM will control and supervise the VoIP services status, detect and recognize attacks in real time, then conduct a Risk analysis and Skill and Knowledge assessment to propose to the administrator, or to the automated reaction module, the most effective countermeasure. Intrusion detection systems aim to detect attacks, however such detecion is not quite useful without reaction. Against given attacks, there could be many possible countermeasres. Our approach will help administrators taking their decisions and selecting the proper countermeasure(s) by assessing the impact of the detected attacks and the candidate countermeasre. We are even conducting further researches and tests to turn the reaction selection and activation process fully automated. As we know, no similar approaches exists in the litterature.

Fig. 1 .

 1 Fig. 1. Risk Assessment structure

Fig. 2 .

 2 Fig. 2. Risk Eff CM and SK Eff CM sets

Fig. 3 .

 3 Fig. 3. CRIM output snapshot

Table 1 .

 1 SK Level label values

	SK Level	Skill Internal Knowledge
	0	Low	No
	1	Medium	No
	2	Medium	Yes
	3	High	No
	4	High	Yes

Attacker's SK Level and Skill and Knowledge Efficient Countermeasure Set We consider that an attacker capable of executing an attack step with high SK Level is an expert attacker and thus, a more sophisticated countermeasure is required. The Attackers Skill and Knowledge Level (SK Level) must be evaluated to refine the countermeasure selection. A first approach to assess the Attackers SK Level is to retrieve the SK Level maximum value among the successfully executed attack steps. The use of Max function could not be accurate enough and further advanced approaches must be explored. Once the Attackers SK Level is assessed, only the countermeasures that have a SK Level greater than the Attackers one will be kept. Hence, the selected countermeasure is adapted to the Attackers Level and a new set called Skill and Knowledge Efficient countermeasures (SK EFF CM) can be instantiated.