Transcript ppt - Greek Cybercrime Center

ΚΕΝΤΡΟ ΜΕΛΕΤΩΝ ΑΣΦΑΛΕΙΑΣ
CENTER FOR SECURITY STUDIES
UKSIM-AMSS: 15th International Conference on Modelling and Simulation
Cambridge University (Emmanuel College), 10-12 April, UK.
Semantic Modeling & Monitoring for Real Time
Decision Making: Results and Next Steps
within the Greek Cyber Crime Centre of
Excellence (GCC)
Team
Presenter: Vasilis Tsoulkas, PhD, Systems Analysis.
Research Group:

Dimitris Kostopoulos,
MSc,
Software Analyst

George Leventakis,
PhD,
Security Risk Analyst

Prokopis Dogkaris,
PhD,
Security Policy Analyst

Vicky Politopoulou,
MSc,
Forensics Analyst
 Parts of this research implemented in cooperation with :
the IT Innovation Center, Southampton , UK.
2
Presentation Sections
● Motivation & Objectives – FP 7 funded - SERSCIS Proof
of Concept Architecture - successfully delivered to
the EC
● Semantic System Modeling Aspects
(The Dynamic Multi-Stakeholder Approach)
● Semantic Monitoring and Stream Reasoning Process
● Decision Support Tool Interfaces & Risk Analytics
● Next Steps within the Greek Cyber Crime Center of
Excellence (GCC).
3
Motivation and Objectives
● The FP7 Project addressed the problem of Dynamic
Modeling and Dynamic Risk Management in Critical
Infrastructures (Cis).
● Today’s
CIs are characterized by: Increased
Connectivity (between different Stakeholders) of
their Information and Data Processing Infrastructures
● ….for Increased Performance and Efficiency
● …but this situation introduces new challenges of
Cyber-Physical Threats and their Counter-Measures
4
Motivation and Objectives
3 main causes for increased CI vulnerabilities
1. Cyber-Attacks against interconnected Information &
Communication channels can disrupt Exchanged
Data flow and Integrity
2. Local Disruption in one Organization (stake holder)
generates problems elsewhere due to coupling and
dependencies (of data and networks).
3. Reduced Resilience against any cyber-disruptions due
to reduced excess capacity arising from the
exchanged data for increased efficiency requirements
5
Objectives
●
Implementation of Agile Service Oriented Technologies to
● compose ICT connections related to the critical
infrastructure
● monitor and manage ICT components against well-defined
dependability criteria
● adapt ICT connections in response to disruption or threats
●
validation of this approach in Proof of Concept Scenarios
from the air traffic sector (Airport-Collaborative Decision
Making (A-CDM) /EUROCONTROL)
6
EUROCONTROL / Airport-Collaborative Decision
Making – European Air Traffic Management System
Data
Exchange
Service accessible by a consumer (aircraft operator) through SLA
template consumer. The GH is responsible for coordination of
Ramp Services (catering, fuelling, cleaning, baggage handling)
GH: Is an Orchestrator of Ramp Services to have an aircraft ready
for its next flight
7
Some Air-Traffic Critical Parameters
8
Data quality and KPIs in A-CDM
● Data: Confidentiality, Integrity, Alarms, Data Display
● KPIs: Reflect the Quality of Service Delivery
● KPIs data properties: Is the Quality of Time Estimates
Accuracy
Predictability
Stability
● An SLA Architecture was developed with the following
KPIs & Parameters in the Airport Collaborative Decision
Making (A-CDM) context:
•
•
•
•
System Availability
Data Quality
Data timeliness, delivery deadlines
Confidentiality
9
Performance of
Service Providers & KPIs
● The GH performance is characterized by two KPIs:
TOBT (Target Off Block Time) i) accuracy and ii) stability;
i) TOBT accuracy parameter: It is derived by comparison with a
Ref. Value : Actual Ready Time (ARDT).
The Mean SQ. Deviation between TOBT & ARDT is computed for all flights
departing in a day.
ii) TOBT stability parameter : Measures how stable is the
predictor mechanism of the GH (estimates).
•
The two KPIs affect the number of take-offs outside a Slot
Tolerance Window (STW).
•
Another KPI for overall CDM performance evaluation: Average
Number of Slots / flight. (Ideally: One Slot/Flight)
10
Addressing the Modeling Challenge
for Machine Reasoning
For the Dynamic Multi-Stakeholder system we constructed :
4-levels of abstraction
1.
A core (ontology) structure: to model the System and its assets
subject to threats and protected by controls
2.
A dependability model: describing system independent: assets,
threats, controls using OWL classes and relationships. Security
expertise is encoded in this model.
3.
An abstract system model: describes system-specific threats and
controls. Extends the dependability model classes with security
knowledge.
4.
A concrete system model: provides a snapshot of the running
system and instances of the participating assets + contextualised
threats & controls.
Each level inherits from its predecessor (parent – child relation). The
final concrete model has simple structure and integrates
knowledge from: Abstract system model and Dependability model.
11
Brief Analysis of Ontology & Models
1.
The Semantic Ontology is constructed such that:
● Only OWL Classes are used for design-time modelling
● OWL Instances are used for modelling the Run – Time System
Composition
● Security expertise is added at design time in the OWL classes
2.
The Dependability model provides the first step to develop the
Abstract System Model which is a Design – Time Model of the
system that will be composed dynamically “On the Fly” (runtime).
3.
The Concrete Model Generator is connected to the monitoring
subsystem to create a model of the Running System (Current
System Composition).
12
Main Innovation of the Approach
● The
Modelling
Semantics
approach
Modelling
for
is
constructed
Machine
using
Reasoning
automated threat analysis and risk estimation when the
system is composed at Run-Time.
● The design – time Service Oriented Dynamic models
are abstract: They describe the structure but NOT the
composition of the system which is NOT KNOWN until
“Run-Time”.
13
Core System Domain Ontology
●
This basic system structure, determines what reasoning is used
Threat class
Description
Unauthorized
access
The service processes an unauthorised request Client AuthN + Client
from an attacker.
AuthZ
Unaccountable
access
Type of unauthorized access, designed to get Client AuthN + Client
the service without paying for it.
AuthZ
14
01/02/2013
Controls needed
Dependability System Model
(High Level View)
Threat impact is
described in terms of
the intended (or
unintended)
compromise
Threat activity may affect
the behaviour of the
asset, or controls on the
asset may reduce the
threat
threatens
1
Assets are sub-classed
to create generic and
system-specific
asset
types
Asset
affects
*
1
depends
on
Threat
*
protects
Control
Control presence is
determined by asset
behaviour
Threats are subclassed to create
generic and systemspecific threat types
blocks/
mitigates
Control rules define
which controls block
or mitigate the
compromise of the
threatened asset
Controls are subclassed to create
generic control types
only
15
Dependability System Model
(Controls & Threats)
Dependability
Model Logical
Asset Types &
Relationships
A generic model of dynamic, multi-stakeholder service-oriented systems
including generic threats and threat classification (control) rules
16
Threat Types & Threat Scenario
1.
2.
3.
4.
5.
Unauthorized Access (to the service)
Data traffic Snooping
Man in the Middle
Client Impersonation
Resource Failure
Unauthorized Data Update at Fuelling Service
17
Dependability Model Controls (sample )
●
Controls provide defences against generic Threats
Two broad categories :
●
proactive controls block a threat, against the protected asset;
●
reactive controls allow the effect of a threat on the asset to be
mitigated once the threat is carried out.
●
Mitigation and Blocking rules are of the form:
ThreatClass(?t)  AssetClass(?a)  threatens(?t,?a) 
ControlClass1(?c1)  protects(?c1, ?a)  …  ControlClassN(?cN) 
protects(?cN, ?a)

MitigatedTreat(?t)
ThreatClass(?t)  AssetClass(?a)  threatens(?t,?a) 
ControlClass1(?c1)  protects(?c1, ?a)  …  ControlClassN(?cN) 
protects(?cN, ?a)
 BlockedTreat(?t)
18
Threat Block –
Mitigation Rule Explanation
ThreatClass(?t)  AssetClass(?a)  threatens(?t,?a) 
ControlClass1(?c1)  protects(?c1, ?a)  …  ControlClassN(?cN) 
protects(?cN, ?a)  MitigatedTreat(?t)
or
ThreatClass(?t)  AssetClass(?a)  threatens(?t,?a) 
ControlClass1(?c1)  protects(?c1, ?a)  …  ControlClassN(?cN) 
protects(?cN, ?a)  BlockedTreat(?t)
●
First line in each case finds a threat instance of a specific type
that threatens an asset instance of a specific type.
●
Second line looks for control instances of the right types to
protect the threatened asset against this type of threat.
●
Last line classifies the threat as either mitigated or blocked,
depending on the types of controls affording this protection
19
Control Class Explanation
Control classes provide:
● generic control types that can be included directly
in an abstract system model;
● descriptions of deployment actions: how to deploy
the control into the real system;
● descriptions of mitigation actions: how to operate
reactive controls to protect assets when a threat is
carried out against them.
20
Resource Software Malfunction
(Mild Error)
ProviderSpecified
Resource
threatens
blocks
Resource
Software
Malfunction
protects
Supplier
Software
Patching
● Threat
● a bug in PSResource software
causes it to repeatedly
produce faults
● Controls
● PSResource has Suplier
Software Patching: the
Supplier has a procedure to
maintain the software used by
the PSResource
●
ensures bug fixes are applied
promptly
● System specifics
● one subclass per PSResource
class
● one instance per PSResource
of each of the resulting classes
Abstract System Model of A-CDM
● It is a design-time model of the structure of the dynamic,
multi-stakeholder service-oriented system: Input for fully
automated run-time model generation and analysis
Tools.
It is composed dynamically at Run-Time.
22
Concrete System Model in the Overall
Architecture
● A run-time model of the system, including its current
composition, status and threat-related behaviours
(Current System Composition)
● It is Created automatically, and it is used to provide run-
time decision support
23
Classification / Estimation Blocks - Output
Concrete Model : Input for a) Threat Classification & b) Threat Likelihood Estimation
The output of these two tools provides:
•
A list of potential threats with classification
•
Estimates of the likelihood a threat is active or in-active
A description of each Threat with impact severity
• A list of controls to block or mitigate a threat and if these controls
are available in the system
•
24
Semantic Monitoring & Stream Reasoning
Process (Initial Prototype & Limitations)
This initial monitoring – reasoning process has 3-stages:
Starting point: Semantic model of the structure of the dynamical multi –
stakeholder system.
The model was “Abstract” based only on OWL Classes with “types of entities” but
NOT YET “Entity Instances”. These are only known at Run-Time. !!!
At Run-Time the Concrete System Model was Generated with OWL Instances
reflecting the System Composition.
Concrete Model generation used Status Monitoring Data from Run Time
Monitoring and Management Block
25
Some…..Limitations of this Approach
● Run – Time Concrete model reflects instantaneous
snap-shot of System Composition, Behavior & Status.
No past Information. !!
●
Threat Analysis depends on Current Concrete Model
and NOT on past Snap-Shots (History). !!
●
Threat activity is computed from current concrete
system model NOT on past Snap-Shots (History). !!
●
No Correlation between Activity and different threats
26
Some…… PoC Implementation
Limitations
● A complete set of monitoring data is needed to
generate the Concrete System Model Snap-shot with
Re-Generation of even static features of the model
each time. !!! The A-CDM PoC.
● This generation of the Complete - Concrete Model is
“Time Consuming”. Every new model is “out-dated” !!
missing intermediate “rapid changes information”.
• Non-Distinguishability between asset – compromises
(Behaviors) that produce the same instantaneous
monitoring data even for different Past Monitoring
data.
27
New Approach: Stream Reasoning
●
• Information arrives as a stream of “time-stamped” data
•
The Knowledge base can be continuously updated and reasoning
goals are continuously re-evaluated as new assertions arrive
•
Reasoning is implemented from a Finite – Time Window and not at
a Single Instant !!.
•
Research Efforts on Stream Reasoning is still at its First Steps and at
its Infancy.
28
3 basic – steps in Stream Reasoning
● Select: Relevant Data from Input Streams by using
Sampling Policies that probabilistically drop stream
elements to address bursty streams of data
(unpredictable peaks).
● Abstract: Sampled streams are input to Abstract block
to generate aggregate events by enforcing aggregate
events continuously.
Output is RDF streams (ρ, τ) with ρ – RDF triple and τ – time
stamp (logical arrival time of RDF statement. Use of C-SPARQL.
● Reason: RDF (Graph Streams) streams are injected into
background
knowledge
for
reasoning
Incremental implementation of RDF snapshots.
tasks.
29
Semantic Monitoring Block
Semantic Reasoning Block ….excluded
30
Semantic Monitoring Component
: DSMS - Behavior Analyser - Sequential
Detection
DSMS: Data Stream Management System : samples & filters monitoring data
generated by Service Monitoring and Management Components.
●
Usage of open-source CEP (Java - ESPER): Real Time engine that triggers
Listeners or Subscribers using a tailored Event Processing Language (EPL).
31
Behavior Analyser (BA)
● Processing
of multiple data streams from DSMS.
Produced Output is Graph Triples (RDF).
•
Decides how to convert raw monitoring data into
Semantic Assertions related to: Presence of Assets and
Behaviors.
● The monitoring framework generates 2 – types of Time
stamped RDF assertions:
(1) Presence or Absence of Assets (joining or leaving
the system)
(2) Assertions about Measurability, Presence or
Absence of Adverse Behavior of these Assets.
32
Behavior Analyser (BA)
● The BA is not only a Transcoder converting Monitoring
Events to RDF graphs.
● The BA decides about the type of Behaviors (Assets
and Services).
● Example: The BA is capable to determine if an Asset
is Overloaded or Underperforming using Monitoring
Data for Load and Performance (KPIs – SLA events).
33
Sequential (Behavior) Detection
 Well – Known Cumulative Sum (CUSUM) algorithm
from the sequential statistics literature.
 In general parametric models are used
 Change in the mean of the relevant stochastic
process
 We use: The non-parametric version of CUSUM
34
Sequential (Behavior) Detection
Mean
Value
Attack Initiation Time and Detection Delay
Test
Statistic
35
Non-parametric CUSUM:
Mathematical principles
Random Sequence
y n  ( y n 1  Z n )

T e s t S ta tis tic
y0  0
X

 m ax(0, x )
If We Define:
The max Continuous Increment up to time n.
Decision Making Rule:
0 : Normal Operation
1 : Attack Event: N is Threshold
36
DST – Tool Dynamic Interfaces
Scenario: Remote exploitation on Fuelling Services
GH
Service
Group
Fuelling
Host
PSR_InterruptedCommunication
X
scheduling
Airport NET
Remote exploit
Attacker
AttacK: Attacker on the AirportNet network
targets the Host of the Fuelling Service.
RKE: Remote Known Exploit
37
SERSCIS DST interface
(Logical Assets View)
38
DST interface (Physical Assets View)
39
DST interface - Assets Under Threat
40
DST interface
(Threats Involving Selected Asset)
41
DST interface (Threat Information and
Countermeasures Proposition - Zoom)
42
EU funded Project
GCC: A Cyber Crime Center of Excellence for Training,
Research and Education in Greece
43
Objectives
● To create a Greek Cyber Crime Centre of excellence
& develop a sustainable infrastructure for GCC.
● To mobilize the Greek constituency in the area of
cyber crime training, research, and education.
● To advance research in the area of cybercrime,
focusing particularly in areas dealing with
● cyber attacks,
● botnet research
● Intrusion detection systems
● Intrusion detection systems for Critical Infrastructures.
44
Work Packages
GCC Project (36 months)
Starting 1st January 2013
WP1: Management
WP2: Dissemination
WP3: Education and Training
WP4: Research
45
Work Packages
GCC Project
FORTH
(WP1)
Management
Website(pub./priv.)
(WP3)
Repository
(University, LEAs)
(WP4)
Research
(Disruptive
monitoring, Botnet
Detection tool)
AUTH
(WP3)
University
courses
(WP4)
Legal issues
SAFENET
(WP2)
Dissemination
Advisory Board
2CENTRE - CCUs
KEMEA
(WP3)
Training (LEAs,
Private/Public
sector)
(WP4)
(WP4)
Research
(legal
framework,
Policy)
Research
(Intrusion
Detection System
–Critical
infrastructure
taxonomies)
46
GCC
● A
CyberCrime Center of Excellence for Training,
Research and Education in Greece” .
● Funded under Prevention of and Fight against Crime
(ISEC)
Programme
of
European
Commission
Directorate-General for Home Affairs.
● GCC main objectives are to create a constituency of
Greek stakeholders in the area of Cyber Crime and to
mobilize
this
constituency
to
work
together
in
education and research areas.
47
Next Steps in the GCC framework
● Exploitation of sequential detection of a change using the
nonparametric CUSUM in the Behavioral Analyzer.
● Situational Awareness of the Operators using user friendly
Dynamic Support Tool (DST) interfaces
● Further
development
using
additional
detection
approaches (Sequential Probability Ratio Test, Different
Optimality Criteria such as: Lorden, Shiryaev - Roberts)
● Distributed Real Time Sequential Detection & Hypothesis
Testing for Intrusion Attacks
●
Some Application areas: Industrial CIs Protection, Network
Intrusion Detection Systems, Swarms & Networks of
cooperative UAVs.
48
Conclusions
● Implementation of an Intelligent Prototype Tool for the
Protection of Dynamic Multi Stakeholder SOA Critical
Infrastructures. Air-traffic Management Systems PoC.
●
Implemented: An Innovative core ontology model
which has been reinforced with rules and classes that
improve threat estimation and classification.
●
Implemented: Advanced Stream (RDF) Reasoning – and
Behavioral Analysis Algorithms.
● Sequential data analysis led us to Advanced Semantic
Stream Reasoning for Real –Time Processing.
● Implemented: Dynamic User Interfaces with Risk – Threat
Analytics in Real Time for A-CDM (Eurocontrol).
49
Questions – Discussion.
Thank you !
Contact Details:
Vasilis Tsoulkas
[email protected]
Dimitris Kostopoulos
[email protected]
George Leventakis
[email protected]
Prokopis Drogkaris
[email protected]
Viky Politopoulou
[email protected]
50