Using Correlation Detection for IMA-IDS Architecture Dequidt [email protected] El Kadhi [email protected] Daï ra [email protected]

1

Abstract The use of full mobility, the interaction and the collaboration of mobile agent to fulfil a global goal.

Keywords : Network, Security, Intrusion Detection System, Distributed Intrusions Detection, Correlation, Event Signialisation, On line Anaylis.

1

Introduction • Recall IMA IDS Architecture (OK) • Focus on Correlator agent (OK) • Difficulties with correlations – What is correlation (OK) – What to correlate ? (OK a ++) – Which model to use ? ∗ BNF syntaxe de signalisation (OK). ∗ How to signaler un event (OK). ∗ ==> Rules • Description/Language • ==> How to ensure the automatisation of correlation rules generation ? (Davide ..)

Paper Plan: • *1* Why Correlations? • *2* What to correlat ? (Events, Properties, (Positif and negatif facts and correlation). • *3* Computation model ???==> Examples then generalisation • *4* Results and future Work

2

Recall IMA-IDS

IMA-IDS is a global architecture for using intelligent and mobile agent for intrusion detection system. As described deeply in [BEKG03] this architecture aims to take advantages from agent mobility and cooperation. The most innovative fact is using a multi6detection models by combining signature analysis, behavior analysis and correlations event analysis. As presented by figure 1, IMA-IDS includes, in addition to the manager agent, three agent’s categories : 2

• Collector agent : this kind of agent will be cloned and distributed throughout the network. This agent patrols the network and collects all the events occurring in the host to which it is related. Notice that the goal is to have specialized collector agent. The idea is that the collector agent will be interested in a set of event categories. So many collector agents can run on the same host, depending on applied analysis. It is also possible to merge collector agent abilities in to a single agent. • Correlator agent : This is a particular agent that will hurry the specific information, called critical, and send it to the appropriate analyzer agent without passing through the manager agent. The default communication protocol is centralized. It supposes that a collector sends a kind of report to the manager agent. The manager will decide whether to dispatch data to the analyzer or not. This communication model is insufficient for online detection since some crucial events must be taken in to account by the analyzer as soon as they occur. That is why each correlator agent will use a set of rules that clearly specifies the crucial events, contexts and analyzer agents concerned by an urgent reporting event mechanism. In order to correctly classify events, correlator agents need a set of rules describing events and alerts dependency and successions. A crucial aspect here, is to notice that attacks detection have to carry on a possibly ’lack’ of information or events signalization. In addition, we mainly focus on giving an extra flexibility in the attack recognition by handling a set of messages equivalences. The idea here is to replace, in a signature attack for example, a specific event by either a correlated alerts or an equivalent event verifying a set of crucial properties. • Analyzer agent : Analyzer agents are the engines of our solution. Several kinds of analysis such as classical signature detection, anomaly detection and a new security protocol analysis based on abstract interpretation as introduced in [EK01] will be integrated. We are also working a behavior analyzer that will use a kind of statistical model to define what can be concerned as a "normal" system behavior is also being developed. • Manager agent : this agent gathers collected information and distributes it to analyzer agents. This communication process does not allow online analysis. For this reason correlator agents can decide to communicate directly with analyzer agents.

The administrator can distribute our IMA-IDS over any number of hosts in the network. Each host can receive any number of collector agents that monitor all events occurring in the host. All collector agents report their results to the manager agent that transmits them to the analyzer agents. The intelligence in our approach is attempted by communicating the critical events detected by the collector agents to the correlator agents. Notice that a critical event

3

Correlator  Agent

Collector Agent

6

6

-

? Analyser Agent

Manager Agent

?

  

?

Analyser Agent

Analyser Agent

? Analyser Agent

Figure 1: IMA-IDS Architecture is any event liable to be part of a scenario of attack. The correlator agents take charge of hurrying the critical events received from the collector agents and transmitting them to the concerned analyzer agents. This paper details the theoretical foundations of a ’new’ correlation concept between attacks, alerts and events.

3

Correlation Concept Definition

Let us first fix what elements are concerned by correlation. For us, correlation is defined by three elements : • Cause a effet :two aspects can be defined here. First one event can be a precondition or predecessor for another. By such rule, if an Event ’A’ becomes True, we can deduce than event ’B’ may occur later. Notice that this will not exclude other events than ’B’ to be verified. The second aspect is the ’negative’ Correlation. The idea is to say that when an event ’A’ occurs, it moves the local state of the system in a way that will prevent the occurrence of the event ’B’. Negative’ and ’Positive’ correlations rules will be used for both forward and backward deductions. The general rules format is the classical clause model. • scheduling :temporal restriction must be taking into account when expressing events occurrence order. This is more price than the previous rule. In fact A, B ⇒ C will be expressed in two exclusives rules. A; B ⇒ or B; A ⇒ c. Where ; is a conjunction ordered operator. • Deadline (D) and classification aspect : events or packets will be first sorted according to a deadline level. The deadline is defined by two parameters :

4

– Static fixed timeout(SFT) : based on an empirical study of existing logs, attacks, signatures (... to see) we will attribute a static timeout to each event (may be contextual one to be detailed to be studied) after which the event can be even classified as an attack (even if the leaving part of the signature is not verified) or discarded and saved in a History list. Notice that this timeout is a fixed one and cannot be modified from one analysis to another. – Flexibility rate (Fr):in order to adapt the analysis parameters to each network or case study we define a specific ’rate’ attached to the occurrence of the event in a specific rule. This suppose that the effective deadline is defined by :D = SF T × F r.

4

Correlation Model

After fixing correlation significance and aspect, let us know define the components and representation of an attack for us. An attack is defined as : • Action Plan : the intruder, has usually a final goal. So he will carry out a set of prearranged actions in order to fulfill it. The detection system, as an external observer [Aba97a, Aba97b] translates the action in observed events and states. • Crucial events : In the actions plan, some of them yield critical events from which the system consider that the alert can be raised even if the next signature events are not observed. We have to identify such point for each possibly attack plan. • Counter-measure : we have also to assign a set of counter-measures to each final attack plan goal. The major idea is to offer a set of guideline and advices to be suggested when the alert is raised. We have also to fix syntax and semantics of correlation rules that include all the previous defined aspect.

5

4.1

Syntax definition

The following table fix the BNF notion for our correlation detection system. AT T ACK EV EN T Crucial_Event Simple_Event Simple_Event Inf os DL ST AT E V alue Add_value RU LE Conj_Rule P rop_Rule Event_state Synchro_rule Env_Synchro Anti_Rule N eg_state

::= < State >∗ < Event >< State > ::= DL < Simple_event > | < Crucial_Event > ::= < #Simple_Event > ::= ∈E ::= ID_Event, T imeStamp, [Inf o]+ ::= IDInf o, V alueInf o ::= F r × F st ::= < Event >+ < P rop_Rul >∗ + < RU LE >∗ ::= v ∈ Authorised_V alue ::= Constraint_relation∗ ::= [< Conj_Rule >|< Synchro_Rule >|< Anti_Rule >] < P rop_Rul > ::= < Event_state >+ ⇒< State > ::= < Event.IDInf o Relat Event.IDInf o > | Event.IDInf o Relat V alue ::= Event, ::= < Env_synchro >+ >⇒< State > ::= Event; ::= < State >∗ ⇒< N eg_State > ::= < ¬Event >, |< ¬Event >

Note: , is used as conjonctio operator and ; as synchronisation operator.

4.2

Events signalization

Intrusion detection systems are in general divided into two groups according to the analyzed events. • Host Based IDS : blabla a mettre • Network Based IDS : blabla a mettre As previously described, our BNF is a generic representation language that can be applied to both kinds of messages. The event set E will be defined differently when using host based or network based events. The correlation computation process, is mainly the same. Some particularities have to be added. Such feature will be deeply presented later. 4.2.1

Event analysis for Network Based system

The global correlation process can be divided into 4 iterative steps : • Collecting events

6

• Preprocessing : this step aims to collect system observations. Observation can be packets, system logs, etc. After collecting, this information will be filtered in a recursive step. Data filtering depends on data type, protocol level · · ·.

IN T ERN AL_N ET W ORKS = < IP _ADDR > 192.168.0.2 < /IP _ADDR > < IP _ADDR_M AS This kind of preprocessing is defined by a DTD (Data Type Document) that etablishes the list of the field that compose a raw data (syslog parsing, packet sniffing, system event hooking, ...). In the exemple of the network filtering, the filter is composed of a few underlying filter that work together. This tree-like architecture is pretty relevant because it looks like the protocol network stack and the packet follow exactly the same way through these protocols. Figure (Network filtering). This preprocessing step leads us to a formal representation of events as described in our BNF syntax. • Events classification : this step will compute D (FST*RT) for each event also as an importance level/rate for each event depending on a set of rules (to be defined later it’s a kind of dynamic learning). • Correlator analysis : the analyzer has as inputs : – Recent observed events : immediate results of the previous step, – Deduced or correlated events and Alerts : this is the output of the correlator engine at the previous cycle The outputs of this step are : – Alerts : Based on the observed events and the previous system events, the Correlator engine can deduce alerts according to the encoded rules – Generated events and states : based on a set of correlation rules (described in our BNF syntax language), the engine will deduce events, and state. The idea here is to be able to (anticipate) on some events and state. This step will also lead to a set of expects events that will be considered as verified. 4.2.2

Properties definitions

Let us fix the semantic of Events, Info and Property rules. Any observed or deduced event is in fact described by : • ID_Event : this is just a unique event identifier that can be for example obtained by a unique Hash function. 7

• TimeStamp : this universal event observation time. Notice here that two different events can have the same observation timestamp since they are for example extracted or deduce from the same packet. • Info : each event is described by a set of information structured as following : – ID_Info : this is an identifier of the event characteristic, typically the name of the observed property. – Value_Info : the assigned value to the event characteristic. Property Rules (Prop_Rul) are used to express relations between different events or between information values for the same event.

4.3

Analysis Engine Processing

For instance the analysis process is divided into five steps : • Event generation : Recall that the engine will be embedded in the global IMA-IDS architecture, so the event signalization will be processed by the collector Agent in three steps. – raw data collection : this can be done by any classical sniffers on a specific protocol or format. – Preprocessing and filtering : depending on the analyzed protocol and the collected packets, data will be through a set of filtered through a set of ’tamis en français’. This step leads to a set of useful information for the next step. – Event and state generation : the goal here is to express in our BNF notation all the observed properties and events. Notice that this concern only observed events. • Correlator analysis : EN Vrac: ** Iteratif ** parametre de lancement ** traitement par cycle ** dans chaque cycle que l’on applique les regles. blablab descriptiona faire – Cycle Inputs : for each correlation cycle analysis we have, as inputs observed events (expressed in BNF notation) and any deduced states or events from the previous cycle. Notice that for the system initialization, initial states are used to formulate constraints about initial environments hypothesis. Of course, we also have a permanent access to the correlation rules as expressed in our BNF notation. – Cycle outputs : each correlation analysis leads to a new environment description by producing a new set of states and events. This set includes mainly the deduced and computes states/events according to the correlation rules. Of course the system will also thru any alerts or deduced attacks. 8

– to be added : Filtre selon DL pour eliminer (history) les events discarder (lifetime plus valide). 4.3.1

Analysis with partial information

One of our major goals is to manage to detect intrusion as soon as possible and with a high level of flexibility. Flexibility for us introduces two concepts : • Bi-directional deduction rules : the description rules are in general bidirectional. This is suppose that if the analysis process observe or deduce an event < E >, the deduced events will be flooded by adding any events in any rules having < E1 > as conclusion. Such deduction rules can be applied for conjunction and synchronization rules. When applied to synchronization rules, the order defined by the rule is also supposed to verified by the back deduced events. To be solved conflicted rules (with negation rules). Remember that the set of observed and deduced events must be coherent through all the analysis process. So when adding events in back deduction, we have to add a set of filtering rules (To be defined) that offer the possibility to solve correctly conflicted situation with no risk of combinatory explosion in event handling. Filtering rules are described section . • Deduction with lack of events : recall that some events are considered as crucial for the intrusion detection process. Our idea is to consider that an alert or a warning can be handled as soon as the crucial events (included in the attack dynamic signature description) becomes true. This suppose that previous needed events are supposed to be verified but not systematically observed by the analyzer. If a typical attack includes more that one crucial event, we have also to verify that the synchronization order (between those events) is also verified when deduced events.

AT T ACK EV 1 Rules R1 R2 R3 R4 R5 R6

::= < block >< ln − s >< unblock >< EV 1 > ::= # < P rint_P rocess_Carried_Out >< ln_s >< Rules > ::= < R1 >< R2 >< R3 >< R4 >< R5 >< R6 > ::= < P rint_P rocess_Carried_Out > .f ilename =< ln_s > .dst ::= < touch >; < lpr_s > [< touch > .f ilename =< lpr_s > .f ilename] ::= < lpr_s >; < block > [< lpr_s > .printer =< block > .printer] ::= < block >; < remove > ::= < remove >; < ln_s > [< remove > .f ilename =< ln_s > .f ilename] ::= < ln_s >; < unblock >

9

System observations

? Preprocessing for data filtering and format

? Event set description

Correlation analysis

Observed states

? m



Events

? Deducted/computed states

Figure 2: Correlation process

10



Alerts

5

Analysis process, Filtering rules

Some ideas: Keeping a kind of conflicted event list ((A, B,); (D, E)) (a and b in conflict and D, E in conflict), events until : • an observation or deduction rule, validate or deactivate one of the conflicted events, • after a timeout (to be defined) the conflicted events will be ignored. • suggestion: adding a time stamp of the conflict generation.

References [Aba97a]

M. Abadi. Secrecy by Typing in Security Protocols. In Proceedings of the Third International Symposium on Theoretical Aspects of Computer Software, 9 1997.

[Aba97b]

M. Abadi. Secrecy by Typing in Security Protocols. In Proceedings of the Third International Symposium on Theoretical Aspects of Computer Software, volume 128, pages 611–638. Springer Verlag, 1997.

[BEKG03] F. Barika, N. EL Kadhi, and K. Ghedira. Intelligent and mobile agent for intrusion detection system: Ima-ids. In 1st ICICT Conference, 9 2003. [EK01]

N. EL Kadhi. Automatic verification of confidentiality properties of cryptographic program. Networking Information System Journal, Hermes Editions, 6, 2001.

11