Your SlideShare is downloading. ×
Workflow Based Security Incident Management
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Workflow Based Security Incident Management

2,334
views

Published on

PCI Conference paper presentation, 2005

PCI Conference paper presentation, 2005

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,334
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
122
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Workflow Based Security Incident Management Meletis A. Belsis 1 , Alkis Simitsis 2 , Stefanos Gritzalis 1
      • (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
      • [email_address]
  • 2. Outline
    • Introduction
    • Incident Collection
    • ETL Workflows
    • System Architecture for the Incident Management
    • Conclusions
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 3. 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.
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 4. 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)
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 5. Background M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005 IODEF Incident Data Model
  • 6. 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
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 7. 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
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 8. Outline
    • Introduction
    • Incident Collection
    • ETL Workflows
    • System Architecture for the Incident Management
    • Conclusions
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 9. Incident Collection M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 10. 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’
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 11. 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
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 12. Outline
    • Introduction
    • Incident Collection
    • ETL Workflows
    • System Architecture for the Incident Management
    • Conclusions
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 13. ETL Workflows M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005 More informations can be found at: http://www.dblab.ntua.gr/~asimi/
  • 14. 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
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 15. Outline
    • Introduction
    • Incident Collection
    • ETL Workflows
    • System Architecture for the Incident Management
    • Conclusions
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 16. System Architecture
    • The system proposed, is based on the OMG’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
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005 www.dcs.fmph.uniba.sk
  • 17. 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 3 with a Common Secure Interoperability at level 0 in order to disallow privilege delegation.
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 18. System Architecture M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 19. Outline
    • Introduction
    • Incident Collection
    • ETL Workflows
    • System Architecture for the Incident Management
    • Conclusions
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 20. 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
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 21. 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
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005
  • 22.
    • Thank You!
    • Belsis Meletis
    M. Belsis, A. Simitsis, S. Gritzalis @ PCI'05, Volos, 13/11/2005