Peter R. Pietzuch
[email protected]
Building Secure Event
Processing Applications
Peter Pietzuch
Large-Scale Distributed Systems Group Department of Computing
Imperial College London
http://lsds.doc.ic.ac.uk
Department of Computing
Security in Event-Based Applications is a Mess!
•
Data flow policy
for the UK National Health Service (NHS)
Typical Software Systems in Hospitals
•
Independent systems coupled through event/message passing
A doctor uses an Exam Booking System to create an Exam request, which is processed by the Patient Admin System and then received by the Hospital Admission System
Exam Booking System Hospital Admission System Patient Admin System Exam request Payroll System
Security Threat Model
•
Incorrect event flows can result in harmful data disclosure
– Caused by unintended bugs, malicious code, poor third-party code, ...
1. Patient Admin System may leak sensitive Exam request 2. Payroll System may access sensitive Exam requests
3. Patient Admin System may expose Exam request to Payroll System Exam Booking System Hospital Admission System Patient Admin System Payroll System
Data Security in Event Processing
•
Guarantee data
confidentiality
and
integrity
end-to-end across
complex heterogeneous applications
– Most code in any event processing component can violate security policy
•
Preventing incorrect
external
event flows
– Boundary checks
– Firewalls
•
Preventing incorrect
internal
event flows
– Boundary checks
Adding a Safety Net to Event Processing
•
Key idea: Don’t prevent all bugs – just add a
safety net
Data-centric, End-to-End Security
Defence-in-Depth
Provide multiple levels of security
Use compartmentalisation
Data-centric Security
Track event propagation
Overview
•
Security in Event-based Applications
•
Data-centric, End-to-end Security
– Decentralised Event Flow Control (DEFC) Model
•
Secure Event-based Applications in Java
– DEFCon middleware
•
Case Study: SafeWeb for Secure Healthcare Applications
Data-centric,
Event Flow Control
•
Mandatory access control model from military security
[Bell73]– Information Flow Control (IFC) has been successfully applied to
• Operating systems (Asbestos, Histar, Flume)
• Programming languages (Jif)
•
1. Label
each event (part) with a
security label
– Preserve security labels as events propagate through system
•
2. Taint components
that were exposed to labelled events
– Add security labels to components– Constrain operations of labelled components on events
PAS PAS Data Patient data Patient data Data Exam request
DEFC Labels
•
Security labels consists of multiple security tags
•
Confidentiality tags S
– Protect confidentiality of event data
– Confidentiality tags are “sticky”
•
Integrity tags I
– Protect integrity of event data
– Integrity tags are “brittle”
•
Decentralised IFC
: anybody can create fresh tags [Myers00]
Data Patient data S:{patient77, NHS} Data Exam report I:{NHS}
DEFC Enforcement
Payroll System Patient Admin Exam Booking
S:{patient77, NHS} S:{}
log S:{patient77, NHS}
Component can output event if and only if:
Component can input event if and only if:
Data Patient data S:{patient77}
)
component
(
S
)
vent
e
(
S
⊆
)
vent
e
(
S
)
component
(
S
⊆
S:{patient77, NHS} Data Patient reportDEFC Privileges
•
Components have privileges to control labels
Clearance privilege + receive confidential events
• Allows components to add tag to their security label
Declassification privilege – make confidential events public
• Allows components to remove tag from their security label
Payroll System Patient Admin Exam Booking
S:{patient77} S:{} S:{patient77} can receive cannot receive confidential events patient77+ patient77+ patient77+ patient77- patient77+, patient77- cannot make can make confidential
Component Isolation
•
Requires strong isolation between components
– All communication between components must be labelled
– Must avoid any covert channels between components
•
Components must be prevented from tampering with labels
– Enforcement as part of OS, language runtime, middleware, …
Secure Event Processing
Applications in Java
Security in Financial Trading
•
Security requirements
– Investors should not learn about each others trading strategies
– Trading strategies should not leak to outside world
•
Performance constraints
– Rigid constraints on latency and throughput
Client Investor Monitor monitor match order Broker deal Stock Ticker tick Bank Investor Monitor Log
DEFCon: Decentralised Event Flow Control
•
DIFC Middleware for building event-based applications in Java
– All communication between DEFCon units through labelled events
– For performance reasons, units share single address space
•
How to achieve isolation between units?
1. Java can isolate units from outside world
2. No existing Java mechanism can prevent inter-unit communication
Bank Investor Client Monitor Client Investor
label check
✗ ✔?
[USENIX ATC’10]Units Only Exchange Immutable Data
•
Event messages consist of Java objects
•
Problem: how to deliver them to receiving units?
– Copy objects in event message slow
– Transfer references to shared objects can’t handle unit label change
•
Shared state between Java objects allows unrestricted
communication
– Solution: only allow immutable objects in event parts
Stock Update
Bank Investor Client Investor
ImmutableStock Stock update
S:{}
Class Library
Shared State in Java Language Runtime?
Bank Investor Client Investor
DEFCon
static fields native methods ~4000 ~2000OpenJDK 6
DEFCon Isolation Methodology
•
Goal
– Provide isolation between Java objects
– Secure potentially dangerous targets: static fields and native methods
•
Previous Java isolation approaches
– Do not support fast message passing between isolates (MVM)
– Use custom Class Libraries and/or JVMs (I-JVM)
– Require extensive analysis of Class Library (KaffeOS, Joe-E)
•
Our approach:
1. Identify potentially dangerous targets using static analysis
2. Modify runtime behaviour of targets using
aspect oriented programming (AOP) 3. White-list safe targets
Class Library
1. Static Analysis
Client Monitor Client Investor Bank InvestorDEFCon
reach
able
remov
ed
static fields native methods ~4000 ~2000 ~2000 ~900 ~1000OpenJDK 6
Class Library
2. AOP Runtime Injection
Client Monitor Client Investor Bank Investor
DEFCon
remov
ed
reach
able
JVM Native static fields native methods ~4000 ~2000 ~2000 ~900 ~1000 ~300transparent
duplication
security
checks
OpenJDK 6
Class Library
3. White-listing
Client Monitor Client Investor Bank InvestorDEFCon
remov
ed
reach
able
static fields native methods ~4000 ~2000 ~2000 ~900 ~1000transparent
duplication
security
checks
OpenJDK 6
Evaluation: Financial Trading with DEFCon
•
Trading platform using Pairs Trading strategy
– Synthetic traces on 6k stock symbols
– Prices set to
trigger deal every 10 ticks – Experiments on
dual Intel Xeon E5540 2.53GHz
•
Overhead of security mechanisms (labels and isolation)
– Measures performance in terms of:
Acceptable Reduction in Throughput
Low Impact on Latency
DEFCon Summary
•
What we achieved
– Middleware for writing DEFC-compliant event-based application in Java
– Added support for strong isolation to OpenJDK 6
• Required few days of manual work
• Easily applicable to new versions/different JDKs
•
Limitations of DEFCon
– Assumes knowledge of unit bytecode for static analysis
– Manual code auditing subject to human errors
SafeWeb for Secure
Healthcare Applications
Case Study: Secure NHS Applications
•
Eastern Cancer Registry and Information Centre (ECRIC)
– Collects histories of Cancer cases in the East of England
• Multi-disciplinary Teams (MDTs), hospitals, pathology labs, ...
– Provide new application to ensure data quality of collected data
• Users interact with web application
•
Data protection policy at ECRIC
1. Access to confidential data by external users should be static + oneway
ECRIC: Problem Scenario
•
Current best practices
– Limited exposure of collected data
– Expensive source code auditing
– Delayed time to deployment
•
Application constraints
– Event-based design: must be reactive to new data in database
– Has to integrate with existing IT environment
RubyTrack
•
Provides DEFC enforcement in Ruby web applications
– Variable-level taint-tracking of event data
– Takes advantage of Ruby’s meta programming features
• Isolation using Ruby’s safe levels
– Works with unmodified Ruby runtime
SafeWeb MDT Portal: Evaluation
•
Performance Impact
•
Increased Security
– Prevents all inspected common vulnerabilities from CVE database • Omitted Access Checks: eg missing checks
• Errors in Access Checks: eg missing special cases
• Inappropriate Access Checks: eg misunderstood policy
• Design errors: eg unexpected deviation from correct workflow
– Only small trusted code base (~4000 LoC) needs auditing Frontend 0 20 40 60 80 100 120 140 160 180 Backend 0 10 20 30 40 50 60 70 80 Processing times (ms) Authentication 87ms Privilege fetching 3ms Template rendering 63ms Label propagation 17ms Other 10ms Event processing 51ms Data (de)serialisation 20ms Label management 13ms
Conclusions
•
Avoiding all security bugs in event processing systems is hard
– Follow a “defence in depth” strategy and add a safety net
•
Decentralised Event Flow Control is a practical model
– Satisfies data-centric security requirements in today’s event-based apps
– Requires support for component isolation and sand-boxing
•
DEFCon middleware:
Event-based Java applications with DEFC
– Relies on methodology for adding efficient object isolation to Java– Low overhead for inter-isolate communication
•
SafeWeb:
Building secure healthcare applications
– DEFC can be added to real-world event-based applicationsAcknowledgements
•
SmartFlow
project (support by the UK EPSRC)
•
Imperial College, University of Cambridge, NHS
•
Jean Bacon, Dave Evans, Dave Eyers, Petr Hosek,
Matteo Migliavacca, Yiannis Papagiannis, Brian Shand
Thank You!
Peter Pietzuch