Meletis Belsis - Workflow based Incident Management Model

Workflow Based Security
Incident Management
Meletis A. Belsis1
, Alkis Simitsis2
, Stefanos Gritzalis1
(1) University of the Aegean
Dept. of Information and Communication Systems Eng.
meletis_belsis@yahoo.com, sgritz@aegean.gr
(2) National Technical University of Athens
Dept. of Electrical and Computer Engineering
asimi@dbnet.ece.ntua.gr

M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005 2
Outline
 Introduction
 Incident Collection
 ETL Workflows
 System Architecture for the Incident Management
 Conclusions

Introduction
A Security incident is some set of events that involve an attack
or series of attacks at one or more sites (John D. Howard)
 Security incidents are not an one step process
 a security incident is some set of events
 involves an attack or a series of attacks
 at one or more sites
 may involve one or more criminals
 may take place in different tide
 may take place from different geographical locations
 Storing such incident information is an invaluable tool to users,
administrators and managers.

Background
 Today many incident databases exist
 Most of them follow the Balkanised Model
 Examples of such include the
 IBM’s VuLDA
 NIST ICAT
 Ohio University IDB
 Many efforts have been made to form a central approach to
incident information storage
 CERT/CC
 Europe S3000
 Open Vulnerability and Assessment Language (OVAL)
 Cerias Incident Response Database (CIRDB)
 Incident Object Description and Exchange Format (IODEF)

Background
IODEFIODEF Incident Data ModelIncident Data Model

Motivation
 Current incident databases use different schemas and format.
 Today experts and law enforcement units require the complete
picture of an incident before taking decisions.
 Unfortunately forcing experts around the world to a use common
structure is difficult if possible at all.
 What is needed is an infrastructure that can collect and integrate
information from different incident databases
 Delivering such a structure incorporates providing solutions to
a number of problems
 gathering
 export snapshots/differentials
 transportation
 transformations
 cleaning issues
 efficient loading

Contributions
 We employ advance database techniques to tackle the
problem of designing a centralized incident DBMS
 We identify the main problems that are underlying the
population of a central incident database
 We propose a method based on ETL workflows for the
incremental maintenance of such a centralized
database
 We present a framework for incident correlation in
order to keep track of a full attack that its component
incidents are stored in different databases

Outline
 Introduction
 ETL Workflows
 Conclusions

Incident Collection

Incident Collection
 In terms of the transformation tasks, there are two
main classes of problems
 conflicts and problems at the schema level
 data level transformations (i.e., at the instance level)
 More specifically
 Naming conflicts
 homonyms
 synonyms
 Structural conflicts
 Data formatting
 String Problems
 ‘Hewlett Packard’ vs. ‘HP’ vs. ‘Hioulet Pakard’

Incident Collection
 A problem
 the time window for the population of the centralized
database is rather too small to repeat the same job
more than once
 ... a solution
 instead of extracting, transforming, and loading all the
data, we are interested only to those incident records
that have been changed during the last execution of the
process
 this means that we are interested only to the incident
data that are
 newly inserted
 updated
 deleted

Outline
 Introduction
 ETL Workflows
 Conclusions

ETL Workflows
 μαζί με το σχήμα λες τα εξής:
In this figure we abstractly describe the general framework for
ETL workflows.
In the left side, we can observe the original data stores (Sources)
that are involved in the overall process. Typically, data sources
are relational databases and files.
The data from these sources are extracted by specialized
routines or tools, which provide either complete snapshots or
differentials of the data sources.
Then, these data are propagated to the data staging area (DSA)
where they are transformed and cleaned before being loaded into
the data warehouse. Intermediate results, again in the form of
(mostly) files or relational tables are part of the data staging area.
The central database DW is depicted in the right part of figure
and comprises the target data stores. The loading of the central
warehouse is performed from the loading activities depicted in
the right side before the DW data store.

ETL Workflows
More informations can be found at:
http://www.dblab.ntua.gr/~asimi/

ETL Workflows
 Extraction-Transformation-Loading (ETL) tools
 can be used to facilitate the population of a centralized
incident database from several different incident DBs
 are pieces of software responsible for the extraction of data
from several sources, their cleansing, their customization,
their transformation in order to fit business needs, and finally,
their loading into a central DB
 their most prominent tasks include
 the identification of relevant information at the source side
 the extraction of this information
 the transportation of this information to the Data Staging Area
(DSA), where all the transformations take place
 the transformation, (i.e., customization and integration) of the
information coming from multiple sources into a common format
 the cleaning of the resulting data set, on the basis of database
and business rules
 the propagation and loading of the data to a central DB

Outline
 Introduction
 ETL Workflows
 Conclusions

System Architecture
 The system proposed, is based on the
OMG’s CORBAOMG’s CORBA architecture.
 CORBA allows for the addition of new
services on demand.
 CORBA is transperent from client
applications, OS, and platform.
 Registered law enforcement units will
be able to access incident information
through the WEB
 Data are going to be collected from
CSIRT databases on a daily basis www.dcs.fmph.uniba.skwww.dcs.fmph.uniba.sk

System Architecture
 Incident data are protected
during transit using the
CORBA’s Security Service
Protocol (SECP) using the SSL
protocol
 The final Corba’s security API
will provide Security at level 3level 3
with a Common SecureCommon Secure
Interoperability at level 0Interoperability at level 0 in order
to disallow privilege delegation.

System Architecture

Outline
 Introduction
 ETL Workflows
 Conclusions

Conclusions
 This research delivers a framework for automated
incident information collection.
 The collection and correlation of incident related data
is vital
 Incident data collected from different sources need to
be cleaned and homogenized before a centrally
stored.
 We try to minimize the time window between the
appearance of an incident and its worldwide
publication.
 Automated correlation of incident information will allow
law enforcement units to pursuit the criminals

Future Work
 Select an incident structure able to store information
received from diverse databases
 Currently we review two potential candidates :IODEF
and IDM.
 Optimization of the ETL process to enable incident
information correlation during the collection process
 Correlation of information stored on the central
database using data mining techniques
 Allow the public community to securely access
incident information using database personalized
views

Thank You!

Meletis Belsis - Workflow based Incident Management Model

More Related Content

Similar to Meletis Belsis - Workflow based Incident Management Model

More from Meletis Belsis MPhil/MRes/BSc

Recently uploaded

Meletis Belsis - Workflow based Incident Management Model