massif - csp forum · 24/09/2012 · both ossim security directives and massif siem cep are based...

MAnagement of Security information and eventsin Service InFrastructures

MASSIFFP7-257475

D3.4.3 - Implementation of intra-layer eventfiltering, aggregation, correlation and

abstraction

Activity A3 Workpackage WP3.4

Due Date M24 Submission Date 2012-09-30

Main Author(s) Universidad Politécnica de Madrid (UPM)

Contributor(s) Vincenzo Gulisano (UPM), Ricardo Jiménez Peris (UPM)

Marta Patiño-Martínez (UPM), Valerio Vianello (UPM)

Version v1.0 Status Final

DisseminationLevel

PP Nature P

Keywords Correlation Engine, XSLT, XML, OSSIM

Reviewers Luigi Coppolino (Epsilon)

Alexander Goller (AlienVault)

Part of the SeventhFramework Programme

Funded by the EC - DG INFSO

MASSIF - FP7-257475

D3.4.3 - Implementation of intra-layer event filtering,

aggregation, correlation and abstraction

MASSIF - FP7-257475



MASSIF - FP7-257475



Version history

Rev Date Author Comments

V0.1 2012-06-18 Vincenzo Gulisano, RicardoJiménez Peris, Marta Patiño-Martínez, Valerio Vianello

First draft


Internal revision


Peer Review Version


Revised after peer review

V0.95 2012-09-18 Ricardo Jiménez Peris, Vale-rio Vianello, Valerio Formi-cola(CINI)

Final revision

V1.0 2012-09-24 Elsa Prieto (Atos) Final Review and Official Deliv-ery

©2012 MASSIF Consortium 2 / 35

MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Glossary of Acronyms

CEP Complex Event Processing

GET Generic Event Translation

JDK Java Development Kit

MASSIF MAnagement of Security information and events in Service InFrastructures

NIST National Institute of Standard and Technologies

OSSIM Open Source Security Information Management

PU Processing Unit

RFID Radio-frequency identification

SIEM Security Information and Event Management

SMB Server Message Block

TS Timestamp

UML Unified Modeling Language

XML Extensible Markup Language

XSL Extensible Stylesheet Language

XSLT Extensible Stylesheet Language Transformation


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Executive Summary

This deliverable presents the directive translator framework that takes care of intra-layer eventprocessing. The implementation of the directive translator framework follows the design de-scribed in the Deliverable D4.3.1 [The12f]. Rules for the intra-layer event processing are writtenin the security rule language of OSSIM. This rule language is written in XML. The security rulesare translated into complex event processing (CEP) queries in order to allow their deploymentin the MASSIF CEP engine. MASSIF CEP queries are also written in XML. Hence, the direc-tive translator framework relies on XSL Transformations (XSLT) to translate from the securitydirective language to the CEP query language.

OSSIM security directive rules are a forest of trees. Each tree represents a particular directivesecurity rule. The translation scheme takes each of these trees and translates them into a CEPquery. Each node of the tree represents a subrule. The translation scheme represents each subrulewith a subquery that has always the same structure. This subquery is then connected with theother subqueries in the same way as the corresponding nodes are connected in the tree. Theoutput of the global CEP query corresponds to the alarms generated by the complete securityrule.


Contents

1 Introduction 81.1 Guidelines Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Glossary adopted in this deliverable . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Prototype in a Nutshell 102.1 Purpose, Scope and Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 List of Components and their actual Release Number . . . . . . . . . . . . . . . . 102.3 Build Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Prototype Deployment 113.1 Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 How to Verify the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Prototype Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Architecture Prototype Design 134.1 Prototype Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Prototype Component Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 Dependency Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.4 API Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Prototype Implementation 165.1 The XSLT Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Translation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2.1 OSSIM Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.2 Translation Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.3 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 Conclusion 296.1 Self-evaluation and Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2 Roadmap for Future Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

A CEP Operator Icons 30


List of Figures

4.1 Correlation Engine Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Directive Translator Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 Security Rule Translation Sequence Diagram. . . . . . . . . . . . . . . . . . . . . 15

5.1 Translator: code snippet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Sample rule tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3 OSSIM XML directive - AVT-FEED Suspicious executable file transmission via

SMB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.4 Translation Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.5 OSSIM XML directive - Case Study. . . . . . . . . . . . . . . . . . . . . . . . . . 235.6 Case Study Scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.7 Case Study: Generic Event Translation Deployment. . . . . . . . . . . . . . . . . 245.8 Translated CEP Query - Case Study. . . . . . . . . . . . . . . . . . . . . . . . . . 27


List of Tables

1.1 Guidelines concerning event processing covered by this deliverable . . . . . . . . . 9

5.1 Case Study: Schema Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2 Case Study: CEP alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

A.1 CEP Stateless Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30A.2 CEP Stateful Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31A.3 CEP Database Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32A.4 CEP Parallel Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.5 CEP Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33


Chapter 1

Introduction

One of the main requirements that MASSIF is addressing is how to simplify the management ofthe SIEM system. This is being achieved in different ways in MASSIF. On one hand, automatingand making transparent the scalability and elasticity of the system via the CEP (Complex EventProcessing) engine as described in [The11b], [The11c], [The12c]. On the other hand, by notforcing the administrators of components in charge of writing security rules to learn a newparadigm, complex event processing, by enabling them to write security rules as in former SIEMs.It is worth noting that, it will also be possible to write security rules using the CEP languagedirectly. To this end, Deliverable D3.1.6 [The12e] introduces a useful application that can beused to define security rules in CEP query language. This deliverable precisely addresses the lasttopic, how to enable writing intra-layer security rules in the same way as in non-scalable SIEMs.Since one additional goal of the MASSIF SIEM lies in having interoperability with OSSIM [Ali]and Prelude [Pre], we have started providing support for the OSSIM security directives, bydeveloping a translation framework that translates OSSIM security directives into CEP queries.

Both OSSIM security directives and MASSIF SIEM CEP are based on XML. Therefore, agood alternative for performing the translation using standard technology is the use of XSLT.OSSIM security directive rules are represented as a forest of trees. An individual directive securityrule is represented by one of such trees. A translation scheme has been designed to translateeach of these individual trees into a CEP query.

Each node of the tree represents a subrule. The translation scheme represents each subrulewith a subquery that has always the same structure. This subquery is then connected withthe other subqueries according the way the corresponding nodes are connected in the tree. Theoutput of the global CEP query generates the alarms that should be generated by the completesecurity rule.

1.1 Guidelines Analysis

The MASSIF CEP engine has been designed by taking into account the developing guidelinesas appeared in D2.1.1 [The11a]. In particular the Directive Translator framework provides theCEP engine with an easy way for deploying new security rule as recommended by the followingguideline extracted from [The11a]:


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Guideline Description

G.E.5. Pre-defined corre-lation rules and correlationrule wizard

The engine should be shipped with a set of predefined correlationrules to identify well-known attacks. However, it should alsosupport easy and intuitive creation of user-defined rules.

Table 1.1: Guidelines concerning event processing covered by this deliverable

The Directive Translator prototype has been developed according to the design principlespresented in the Deliverable D3.4.1 [The12f].

1.2 Glossary adopted in this deliverable

As agreed by the MASSIF Consortium, the main reference of security glossary is provided by theNational Institute of Standard and Technologies (NIST) in [Kis11]. Some other novel definitionswhich are not present in the considered NIST glossary such as Elasticity and Scalability wereconsidered from [BK10] and [GJPnM+12].


Chapter 2

Prototype in a Nutshell

2.1 Purpose, Scope and Functionality

The translation framework has as main purpose to ease the writing of security rules for securityexperts, that define the intra-layer correlation queries, by letting them to use an actual securitydirective language (in particular, the one from OSSIM) and not forcing them to learn a newparadigm to write security rules such as complex event processing. The translation frameworkscope is in the context of the CEP engine of the MASSIF SIEM and provides the functionalityto translate security directives written in the OSSIM directive language to MASSIF SIEM CEPqueries.

2.2 List of Components and their actual Release Number

This document describes the implementation of the Directive Translator, which has been releasedwith the version 1.0.

• MASSIF Directive Translator, version 1.0.

2.3 Build Procedure

The Directive Translator is implemented in JAVA with the use of Extensible Stylesheet LanguageTransformation (XSLT) [W3S], the translator was developed using the JDK 6. The apache Antlibrary [Apaa] was used to organize, compile and run the project. In particular, in order tobuild the prototype it is needed to invoke the custom Ant task called jar which also is set asdefault task. The jar task compiles all the classes of the project and it produces a self-containedand executable jar file. Indeed to compile the Directive Translator prototype the user may runindifferently 2.1 or 2.2 from the root folder of the project, where it is stored the build.xml file.

ant (2.1)

ant jar (2.2)


Chapter 3

Prototype Deployment

3.1 Pre-requisites

The Directive Translator framework is a JAVA application which makes use of an XSLT proces-sor. Hence in order to build the framework the user needs to have installed on his machine theOracle JDK 6 or greater [Ora] and a processor such as the Saxon XSLT processor 8 or greater[Sax].

3.2 How to Verify the Installation

Once generated the executable jar file, the user can test the Directive Translator framework usingthe command line 3.1.

java − jar translator.jar test (3.1)

If the installation completes successfully, the command 3.1 prints a welcome message withthe version of the software and a command line usage example.

3.3 Licensing

The code of the Directive Translator framework is proprietary and owned by UPM. Access rightsto the MASSIF consortium are provided for using it during the project execution.

3.4 Prototype Usage

At this stage the Directive Translator framework is only available as a command line executableJAR file. Command 3.2 show how to use the JAR to translate the directive stored in the file


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



directive.xml into the CEP query that will be stored into the file cep_query.xml.

java − jar translator.jar translate directive.xml cep_query.xml (3.2)


Chapter 4

Architecture Prototype Design

4.1 Prototype Context

In the context of the MASSIF SIEM [The12g], the parallel Complex Event Processing engine isin charge of processing security events providing the MASSIF SIEM with a highly-scalable andelastic correlation engine. The internal architecture of the engine is depicted in figure 4.1.

Figure 4.1: Correlation Engine Context.


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



The main components showed in Figure 4.1 are :

• Processing Instance: processing nodes that continuously aggregate, correlate, filter andabstract events and produce output events.

• CEP Connectors: they are used for receiving tuples from theGenericEventDisseminationbus.

• Query Compiler: it converts a direct acyclic graph of operators representing a securityrule with no information about distribution, parallelization or deployment into a parallel-distributed continuous CEP query.

• Query Deployer: it is used to deploy a parallel-distributed query once subqueries havebeen assigned to sub-cluster and to each sub-cluster has been assigned a set of processingnode.

• Elastic Manager: it handles the processing nodes and monitors their status. The Elas-tic Manager periodically aggregate information on a per-cluster basis and based on thisdata it may decide to reconfigure the system either to balance the load, to provision ordecommission nodes

• Resource Manager: it manages online and offline resources. In particular it keeps apool of available nodes and it interacts with the Elastic Manager when nodes must beprovisioned or decommissioned.

This Deliverable describes the implementation of the Directive Translator framework whichis one of the core elements of the Query Compiler component of the MASSIF CEP [The12b].Through the translation framework MASSIF components, such as the Visualization Tool or theSecurity Event Modeling [The12g], are able to deploy, on the CEP engine, SIEM rules writtenwith a traditional security directive language. The other components and the interaction with theoverall MASSIF SIEM architecture are described in [The12g] , [The12b], [The12d] and [The12e].

4.2 Prototype Component Structure

Figure 4.2: Directive Translator Structure.

The Directive Translator framework has two main sub-components which are in charge ofthe main tasks executed during the translation of a security rule into a CEP query. As shown inFigure 4.2, these sub-components are the validator and the converter. The former is in chargeof parsing the security rule received as input and in order to check if the rule is well constructed


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



it validates the rule with one of the pre-defined XML schema. Once the input has been validated,the framework invokes the converter using the XLST related to that related XML schema. Fi-nally the converter generates the centralized CEP query which can be directly deployed with theQueryDeployer on one node or it can be parallelized and deployed on a distributed sub-cluster[The12b].

4.3 Dependency Graph

The UML sequence diagram of Figure 4.3 shows the interactions happening when a componentin charge of writing security rules (labeled as RuleDeployer in the diagram) uses the directivetranslator service. The communication starts with the RuleDeployer requesting the security ruletranslation service. The DirectiveTranslator first calls the V alidator, in order to identify whichis the language used for the security rule and check if the input rule is well formed, and then itinvokes the Converter to translate the security rule into a CEP query using the correspondingXSLT stylesheet. Finally the RuleDeployer could deploy the returned translated rule on theCEP by means of the QueryDeployer component [The12b].

Figure 4.3: Security Rule Translation Sequence Diagram.

4.4 API Information

The Directive Translator service interface has the following public method signature:

QueryCEP translateSecurityRule(Rule rule, Type type); (4.1)

Where QueryCEP is the object containing the XML defining to the CEP query, Rule isan object with the XML defining the security rule and Type is used to identify the type of thesecurity rule to be translated.


Chapter 5

Prototype Implementation

The version 1.0 of the Directive Translator framework supports only one XML schema and it isthe schema defined by OSSIM [Ali], one of the SIEMs taken into account by the project that isproduced and supported by one of the partners. In this chapter we detail the process used totranslate an OSSIM SIEM directive into a CEP query to be deployed on the MASSIF correlationengine.

5.1 The XSLT Technology

XSLT (stands for Extensible Stylesheet Language Transformations) is a commonly adopted stylesheet language used to transform XML document into other kinds of documents. In more detail atransformation expressed in XSLT describes rules for transforming a source tree into a result tree.Firstly the XSLT processor reads and stores the input XML file as a tree of nodes then accordingto an XSL file, containing both the framework in which insert the data and the XSLT commands,it transforms the source tree in the final result tree. In the XSL file patterns and templates aredefined. The patterns are used to match element of the source tree and the templates are usedto create the corresponding part into the result tree. In constructing the result tree, elementsfrom the source tree can be filtered and reordered, and arbitrary structure can be added. Themost common XLST processors are:

• Saxon: it is a free processor written in Java, so it can be run on any operating system witha modern Java interpreter. Saxon now comes in two flavors: Saxon 6 which handles theXSLT 1.0 standard, and Saxon 9 which handles the newly emerging XSLT 2.0 and othernew XML standards [Sax].

• Xalan: it is part of the Apache XML Project. It has versions written in both Java andC++, both of them free. Generally Xalan is used with the Xerces XML parser, alsoavailable from the Apache XML Project [Apab].

• Xsltproc: it is written in C by Daniel Veillard. It is free, as part of the open source libxml2library from the Gnome development project [xsl].

Figure 5.1 shows a snippet of the XSL file used by the translator. In this snippet of the XSL fileare defined some global variables and the first XSLT template which matchs the root node of anOSSIM directive.


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



<!−− g l oba l v a r i a b l e s −−><xs l : v a r i ab l e name="d i r e c t i v e_ id">

<xs l : value−o f s e l e c t="d i r e c t i v e /@id" /></x s l : va r i ab l e ><xs l : v a r i ab l e name="d i r e c t i v e_p r i o r i t y">

<xs l : value−o f s e l e c t="d i r e c t i v e / @pr io r i ty " /></x s l : va r i ab l e ><xs l : v a r i ab l e name="directive_id_name">

d i r e c t i v e_ id</x s l : va r i ab l e ><xs l : v a r i ab l e name="direct ive_pr ior i ty_name">

d i r e c t i v e_p r i o r i t y</x s l : va r i ab l e ><xs l : v a r i ab l e name="stream_name">

senso r input</x s l : va r i ab l e >

<!−− d i r e c t i v e root node template−−>

<xs l : template match="d i r e c t i v e "><xs l : t ex t d i sab l e−output−escap ing="yes">

& l t ; b o r e a l i s&gt ;

</x s l : text><xs l : c a l l −template name="create s t ream">

<xs l : with−param name="inpu t s t r i n g"><xs l : value−o f s e l e c t="ru l e /@plugin_id"/></x s l : with−param><xs l : with−param name="inpu t s t r i n g2">input</x s l : with−param><xs l : with−param name="inpu t s t r i n g3"><xs l : copy−o f s e l e c t="$stream_name"/></x s l : with−param>

</x s l : c a l l −template><xs l : t ex t d i sab l e−output−escap ing="yes">

& l t ; input stream = "</x s l : text><xs l : copy−o f s e l e c t="$stream_name"/>"schema = "<x s l : copy−o f s e l e c t="$teststream_name"/>_schema"<x s l : t ex t d i sab l e−output−escap ing="yes">/&gt ;</ x s l : text><xs l : apply−templates s e l e c t="ru l e " /><xs l : t ex t d i sab l e−output−escap ing="yes">

& l t ; / b o r e a l i s&gt ;</ x s l : text>

</x s l : template>

Figure 5.1: Translator: code snippet.


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



5.2 Translation Process

We have introduced the OSSIM directive in the Deliverable D3.4.1 [The12f] and for a detaileddescription we refer to technical documents in [Ali]. Anyhow in order to make this Deliverableself contained we report the main characteristics of the OSSIM directives.

5.2.1 OSSIM Directives

OSSIM directives are defined in XML 1.0 and arranged in a forest of logical non-empty treesof rules. Each rule is defined as a predicate over input events. When the predicate of a rule issatisfied by one or a set of input events, we say that the rule fires.

An input event is used to evaluate only the predicates of active rules. At system initialization,only root rules are active. An inner rule becomes active as soon as its parent rule fires. Hence,rule predicates are sequentially evaluated from the root of the tree towards the leaves. As aresult, a path in the tree is a conjunction of predicates that must be satisfied in root-to-leavesorder; sibling nodes are used to define disjunctions of predicates.

The root rule has a special behavior as it is always active; i.e., its predicate is evaluated foreach input event. Once the root rule fires, a new tree instance is created and added to the forest;at this time, all children of the root rule become active.

A sample tree T is depicted in Figure 5.2. Rule 1, which is the root rule, is evaluated witheach input event. For each event that satisfies its predicate, a new instance of T , namely T ′, isadded to the forest and Rules 2.1 and 2.2 become active. If a new event satisfies, say, Rule 2.2of tree T ′, then Rule 3.2 and 3.3 within the same tree become active. Once the predicate of aleaf rule is satisfied, the tree instance is removed from the forest.

Each directive has an associated Risk factor which is used to evaluate the relevance of thealarm generated by the directive and that is defined as:

Risk = (Asset · Priority ·Reliablity)/25

• Asset (0-5) is an arbitrary value associated to resources that the directive is monitoring.

• Priority (0-5) is an arbitrary value that defines the importance of the attack (among allpossible attacks to the monitored system).

• Reliability (0-10) is an arbitrary value that defines the trustworthiness of the attack de-tection.

As rules along a path of the tree fire, the reliability value is increased. Any time the predi-cate of a rule is satisfied, an alarm is triggered (and presented to the final user) if the new Riskvalue is above a user-defined threshold. When predicates of rules on the same path are satisfied,and the final Risk value is above the user-defined threshold for all of them, a different alarm istriggered for each rule and it is marked with the respective Risk value. Clearly, directives shouldbe designed such that at least one node on any path has a Reliability value that causes Risk tocross the threshold; Otherwise, the directive might produce no output to the final user.


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Rule 1

Rule 2.2

Rule 3.3Rule 3.1 Rule 3.2

Rule 2.1

Figure 5.2: Sample rule tree.

5.2.2 Translation Algorithm

<d i r e c t i v e p r i o r i t y ="3" name="AVT−FEED exec f i l e t rans v ia SMB" id="37027"><ru l e name="AVT−FEED share a c c e s s " p ro to co l="ANY" s t i c ky="true "

plug in_sid ="537 ,2465 ,2466" plugin_id="1001"port_to="ANY" port_from="ANY" to="ANY" from="ANY"occurrence="1" r e l i a b i l i t y ="2" type="de t e c t o r">

<ru l e s ><ru l e name="AVT−FEED exec f i l e t rans v ia SMB" s t i c k y="true "

plug in_sid ="2009033 ,2009034 ,2009035" plugin_id="1001"port_to="ANY" port_from="ANY" to ="1:DST_IP" from="1:SRC_IP"occurrence="2" r e l i a b i l i t y ="+1" type="de t e c t o r " time_out="10"/>

</ru l e s ></ru le>

</d i r e c t i v e >

Figure 5.3: OSSIM XML directive - AVT-FEED Suspicious executable file transmission via SMB.

In Figure 5.3 is reported one of the predefined security rule available in the OSSIM SIEM.According with OSSIM formalism, a security rule always begins with a < directive > tag con-taining at least one child node of type rule. A rule can be a simple node (in this case it wouldbe the leaf of a tree) or a composed rule. Composed rules have a child node of type rules, and


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



this child node must have one or more child nodes of type node that in turn can be a simpleor composed node. Due to its cyclic structure, in order to translate an OSSIM directive into aMASSIF CEP query we defined the iterative algorithm presented in Figure 5.4.

1 i f ( node=="d i r e c t i v e ") {2 goto_rule_node ( ) ;3 }45 e l s e i f ( node=="ru l e ") {6 i f ( node=="f i r s t_ r u l e ") {7 create_f i l ter_1_box ( ) ;89 } e l s e {10 i f ( ex i s t_cons tan t_f i e l d s ){11 create_f i l ter_1_box ( ) ;12 }13 create_equi jo in_box ( ) ;14 }1516 create_aggr_box ( ) ;17 create_f i l ter_2_box ( ) ;18 create_map_box ( ) ;1920 i f ( exist_chi ld_node ) {21 create_map2_box ( ) ;22 create_temp_output_stream ( ) ;23 goto_rules_node ;24 } e l s e {25 create_output_stream ( ) ;26 }27 }2829 e l s e i f ( node=="ru l e s ") {30 goto_rule_node ( ) ;31 }

Figure 5.4: Translation Algorithm.

The pseudo-code listed in Figure 5.4 is executed iteratively until that none of the if-conditionsof line 1, line 5 or line 29 is matched. The translation of an OSSIM security rule starts bymatching the if-condition on line 1 which marks the starting point of a a new CEP query. Thegoto_rule_node() function on line 2 and line 30 (such as the goto_rules_node() on line 23)are used to tell the parser to go looking for a rule (respectively rules) node among the childrenof the current node. The if-condition on line 6 is needed because the root rule of the tree mustbe translated in a different way from the rest of the rules defined in the directive. In fact theroot rule does not have the join operator because this operator is used to correlate a ProcessingUnit (PU) (as described in the Deliverable D3.4.1 [The12f] a PU is the translation of an OSSIMrule into CEP operators) with the parent PU and, by definition, the root rule does not have


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



any parent rule node. The if-condition on line 10 is used because in all the rules of a directive,but the root rule, the match conditions are classified as constant condition (which are defined inCEP language by means of a filter operator) or as conditions which depend on the previous PU(which are defined in CEP language by means of a equijoin operator). The if-condition on line20 is instead used to figure out if the current node is a leaf node, in this case the translator wouldgenerate the final output stream, or id the current rule is a composed rule, in this case the trans-lator go forward looking for the child nodes in the tree. Finally, the create functions (on lines7,11,13,16,17,18,21) are used to generate the CEP code related to the PU corresponding to theOSSIM rule while the create functions of lines 22,25 generate the CEP streams [The12d],[The12f].


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



5.3 Case Study

In order to show the translation of an OSSIM security rule into a MASSIF CEP query, we use anexample of attack taken from the Dam scenario [The11a]. The scenario describes a violation ofthe dam Control system followed by an attack which modifies the physical parameters collectedfrom the sensor devices in order to induce wrong evaluations on the on-going critical processesin the dam. We present the misuse case by means of a storyboard composed of the steps listedbelow:

• A regular but disgruntled dam employee - e.g. a surveillance person - swipes his badge toenter the Control Room.

• The employee accesses the Control Console machine in the Control Room by means ofstolen admin credentials

• The disgruntled employee attacks the system by modifying the measurement of one outof three physical sensors that are close to each other (each of them continuously sendsmeasurements to the dam monitoring and control system). One of the three sensors sendsdeviated/wrong values of physical parameters

The sequence of happenings described above can be effectively detected by MASSIF bycorrelating different kind of information related to the monitored scenario. Specifically:

• The anomalous sequence of accesses into the system should be detected and should bereported - e.g. by triggering an alert - at the edge of the SIEM, next to the monitoredscenario. This event should have low reliability as an administrator might have entered theroom along with a regular employee.

• The deviation of the measurements should also be monitored to detect anomalies intothe system and should be reported - e.g. by triggering an alert pertaining the physicaldomain: the rationale is that sensors that are close to each other should provide similarmeasurements.

• These events should be correlated to raise a meaningful alarm about very suspicious activitygoing on. The alarm should have greater reliability than the single events and alerts.

In terms of OSSIM security rules, we can describe the “signature“ of this attack as a directivemade by three rules as shown in Figure 5.5 and graphically represented in Figure 5.6.

In order to correlate such happenings we need to obtain three kinds of information:

• Someone without admin right has entered the control room.

• An anomalous sequence of physical-logical accesses has happened in the system.

• Different sensors measuring the same physical process have provided different measure-ments.


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



<d i r e c t i v e id ="500008" name="MassifDemo" p r i o r i t y="5"><ru l e type="de t e c t o r " name="RFID" from="ANY" to="ANY" port_from="ANY"

port_to="ANY" r e l i a b i l i t y ="0" occurrence="1" plugin_id="1100"plug in_sid="3" senso r="ANY" s t i c ky="true">

<ru l e s ><ru l e type="de t e c t o r " name="SP_AccessAnomaly" from="ANY" to="ANY"

port_from="ANY" port_to="ANY" r e l i a b i l i t y ="4" occurrence="1"time_out="300" plugin_id="1101" plugin_sid="1"senso r="ANY" s t i c k y="true">

<ru l e s ><ru l e type="de t e c t o r " name="SP_PhysiCo"

from="ANY" to="ANY" port_from="ANY"port_to="ANY" r e l i a b i l i t y ="8" occurrence="1"time_out="600" plugin_id="1102" plug in_sid="1"senso r="ANY" s t i c k y="true"/>



</d i r e c t i v e >

Figure 5.5: OSSIM XML directive - Case Study.

Figure 5.6: Case Study Scenario.


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Figure 5.7: Case Study: Generic Event Translation Deployment.

In the specific case of the dam critical process control, the data used to obtain such informa-tion are:

• The logs generated by the RFID access system.

• The logs of a console access system.

• The measurements of physical devices.

The component of MASSIF in charge of collecting such very heterogeneous data is the GenericEvent Translation (GET) framework [The12g]; in particular, the framework gathers, parses,correlates and translates the data generated by the event sources above. For example considerthe following log generated by the RFID device:

surveillance enters 2012-09-06T14:04:37.675+02:00

It contains information about who activated the RFID device in the Control Room (”surveil-lance“); which action he/she performed (”enters”); when this event happened. This entry, togetherwith the “login“ logs and the measurements generated by the physical sensors are treated by theGET framework to evaluate the security happenings described above and to feed effectively theCEP with significant data.

Details about how such data are processed by the GET framework can be found in thedeliverable D3.4.4 - Implementation of cross-layer event filtering, aggregation, correlation andabstraction [The12a]. In Figure 5.7 is depicted a simplified representation of GET frameworkconfigured for this specific case study. Note that: (1) the SP_AccessAnomaly Security Probeis in charge of correlating the physical access to the Control room of the dam and the log-in


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



to the system Console; (2) the information excerpt from the Sensor data is correlated by theSP_PhysiCo Security Probe, which is in charge of detecting deviations in the physical parametersmeasured by the sensor devices. The GET framework generates three output streams: thestream generated by the Security Probe SP_AccessAnomaly conveys events reporting physicaland logical access incoherence; the stream generated by the Security Probe SP_PhysiCo conveysevents of anomalies in the physical parameters; the stream generated by the RFID source conveysevents of physical accesses to the Control room. The output events are translated and normalizedfollowing the generic OSSIM event schema in table 5.1.

Figure 5.8 shows the graph related to the CEP query, used to detect the described attack,that the Directive Translator framework generates starting from the OSSIM directive of Figure5.3. Samples of the events provided by the GET framework and consumed by the CEP engineare represented in the table 5.2.

It is worth noting that the reliability value (measuring the confidence in the alarm) increasesany time a rule of the directive is matched.


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Field Value

Timestamp Timestamp of the event

Plugin_ID ID of the source type1100 for the RFID sensor1101 for the SP_AccessAnomaly probe1102 for the SP_PhysiCo probe with a break

Plugin_SID Specific event identifierFor PID 1100:1: admin enters the room2: admin exits the room3: surveillance enters the room4: surveillance exits the room

For PID 1101:1: admin login after surveillance physical access2: admin login after admin physical access3: generic user login after surveillance physical access4: generic user login after admin physical access

For PID 1102:1: Deviation of physical parameters

Sensor IP address of the event sourceIP of the log generator in case of the RFID deviceIP of the SP_AccessAnomaly probeIP of the SP_PhysiCo probe

From and Port_from Source IP and Port

Null for the RFIDNull for the SP_AccessAnomaly probeNull for the SP_PhysiCo probe

To and Port_to Destination IP and Port.

Null for the RFIDNull for the SP_AccessAnomaly probeNull for the SP_PhysiCo probe

Table 5.1: Case Study: Schema Fields


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Figure 5.8: Translated CEP Query - Case Study.


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Messages coming from the GET Output Alarms

1346940277,1100,3,192.168.0.100,null,null,null,null Directive:MassifDemoRule: RFIDReliability: 0Timestamp: 1346940277

1346940451,1101,1,192.168.0.101,null,null,null,null Directive:MassifDemoRule: SP_AccessAnomalyReliability: 4Timestamp: 1346940451

1346940983,1102,1,192.168.0.102,null,null,null,null Directive:MassifDemoRule: SP_PhysiCoReliability: 8Timestamp: 1346940983

Table 5.2: Case Study: CEP alarms


Chapter 6

Conclusion

6.1 Self-evaluation and Assessment

This deliverable has successfully addressed the functionality envisioned in the DoW [The10] asa tool to write intra-layer security rules. The developed translation framework enables to writeintra-layer security rules in the OSSIM security directive language and translates them in theCEP queries understood by the MASSIF CEP engine that parallelizes them automatically toscale them. In this way, the security experts that have to write security rules do not have tolearn a new paradigm to write them and can stick to a regular security directive language suchas the one of OSSIM. Additionally, by supporting this language we also address in part theplanned integration with OSSIM by supporting its directive language and therefore enabling amore direct integration of the MASSIF CEP engine with OSSIM.

6.2 Roadmap for Future Releases

The goal of next release of the Directive Translator framework is support the translation ofsecurity rules defined with either formalism of Prelude or new language that could be introducedin the MASSIF SIEM.


Appendix A

CEP Operator Icons

The following tables list the icons used for the CEP operators in the Query Compiler and theCEP monitor interfaces.

Operator Icon

Filter

Map

Union

Table A.1: CEP Stateless Operators


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Operator Icon

Aggregate

Join

WaitFor

Table A.2: CEP Stateful Operators


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Operator Icon

Insert

Delete

Update

Select

Table A.3: CEP Database Operators


MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



Operator Icon

Semantic Router

Event Merger

Table A.4: CEP Parallel Operators

Operator Icon

Input Stream

Output Stream

Table A.5: CEP Streams


Bibliography

[Ali] AlienVault LLC. Alienvault technical documentation. http://alienvault.com/resources/documentation/.

[Apaa] Apache. The apache ant project. http://ant.apache.org/.

[Apab] Apache. The apache xalan project. http://xalan.apache.org/.

[BK10] M. Patiño-Martinez B. Kemme, R. Jimenez-Peris. Database replication. SynthesisLectures on Data Management 7. Morgan and Claypool Publishers, 2(1-153), 2010.

[GJPnM+12] Vincenzo Gulisano, Ricardo Jimenez-Peris, Marta Pati no Martinez, Claudio Sori-ente, and Patrick Valduriez. Streamcloud: An elastic and scalable data streamingsystem. IEEE Transactions on Parallel and Distributed Systems, 99(PrePrints),2012.

[Kis11] R. Kissel. Glossary of Key Information Security Terms. National Institute ofStandard and Technologie (NIST), 2011.

[Ora] Oracle. Java se. http://www.oracle.com/technetwork/java/javase/downloads/index.html.

[Pre] howpublished = http://www.prelude-ids.com/en/products/universal-siem/index.html Prelude, title = Prelude SIEM.

[Sax] Saxon. The xslt and xquery processor. http://saxon.sourceforge.net/.

[The10] The MASSIF Consortium. MASSIF Description of Work. Technical report, 2010.

[The11a] The MASSIF Consortium. Deliverable 2.1.1: Scenario Requirements. Technicalreport, 2011.

[The11b] The MASSIF Consortium. Deliverable 3.1.1: Event processing engine architecture.Technical report, 2011.

[The11c] The MASSIF Consortium. Deliverable 3.1.2: Design of the Distributed eventprocessing operators. Technical report, 2011.

[The12a] The MASSIF Consortium. D3.4.4 - Implementation of cross-layer event filtering,aggregation, correlation and abstraction. Technical report, 2012.

[The12b] The MASSIF Consortium. Deliverable 3.1.3: Event processing engine. Technicalreport, 2012.


http://alienvault.com/resources/documentation/

http://alienvault.com/resources/documentation/

http://ant.apache.org/

http://xalan.apache.org/

http://www.oracle.com/technetwork/java/javase/downloads/index.html

http://www.oracle.com/technetwork/java/javase/downloads/index.html

http://www.prelude-ids.com/en/products/universal-siem/index.html

http://www.prelude-ids.com/en/products/universal-siem/index.html

http://saxon.sourceforge.net/

MASSIF - FP7-257475



MASSIF - FP7-257475



MASSIF - FP7-257475



[The12c] The MASSIF Consortium. Deliverable 3.1.4: Design of elastic computing compo-nent. Technical report, 2012.

[The12d] The MASSIF Consortium. Deliverable 3.1.5: Distributed event processing opera-tors. Technical report, 2012.

[The12e] The MASSIF Consortium. Deliverable 3.1.6: Elastic event processing engine. Tech-nical report, 2012.

[The12f] The MASSIF Consortium. Deliverable 3.4.1: Design of intra-layer event filtering,aggregation, correlation and abstraction. Technical report, 2012.

[The12g] The MASSIF Consortium. MASSIF Architecture Document. Technical report,2012.

[W3S] W3Schools. Xslt tutorial. http://www.w3schools.com/xsl/.

[xsl] xsltproc. The xslt c library for gnome. http://xmlsoft.org/xslt/xsltproc2.html.


http://www.w3schools.com/xsl/

http://xmlsoft.org/xslt/xsltproc2.html

http://xmlsoft.org/xslt/xsltproc2.html

massif - csp forum · 24/09/2012 · both ossim security directives and massif siem cep are based...

Documents