richard gay – iciss, december 20, 2014 cliseau:securing distributed java programs by cooperative...

Richard Gay – ICISS, December 20, 2014

CliSeAu: Securing Distributed Java Programs by Cooperative Dynamic Enforcement

Richard Gay, Jinwei Hu, Heiko Mantel

Modeling and Analysis of Information Systems (MAIS), TU Darmstadt, Germany

10th International Conference on Information Systems Security, Hyderabad, India

funded by CASED, by the DFG under project FM-SecEng, and by TU Darmstadt

Richard Gay – ICISS, December 20, 2014 2

Dynamic Security Enforcement

Enforcement as encapsulation

Duties of an encapsulation

program(needs to be trusted)

enforcement mechanism

program(trustworthy)

“encapsulation”

intercept events decide imposecountermeasure

PEP in XACML

PEP in XACML

PIP+PDP in XACML


Security in Distributed Programs

Related work (selected) SASI [Erlingsson, Schneider ‘99] Security Automata [Schneider ’00] Edit Automata [Ligatti et al. ’02, ‘05, ‘09] Polymer [Bauer et al. ’05, ‘09] JavaMOP [Rosu et al. ’07, ’12, ‘12]

Our goals dynamic enforcement for distributed Java programs system-wide security requirements decentralized to avoid bottlenecks and single points of failure effective efficient

Service Automata [Gay et al. ‘11] MFOTL enforcement [Basin et al. ‘10, ‘12] Information-flow enforcement [e.g.,

Guernic ’07,…,Chudnov et al. ’14] Usage control [e.g.,

Pretschner et al. ‘13, ‘14]


Security in Distributed Programs

File server 1 File server 2

downloadfile of Bank A

downloadfile of Bank B

financial auditor

checksfor localenforcement

checksfor local

enforcement


Concept [Gay et al., FAST‘11]

encapsulate each component of distributed target program encapsulations can coordinate the enforcement with each other formalized in CSP

Modular architecture

Remaining challenges a cooperative enforcement mechanism for Java programs a combination technique for the mechanism with a Java program

Service Automata Concept

interceptor

enforcer local policy

target

coordinator


CliSeAu

concept

cooperativeenforcement

modulararchitecture

combinationtechnique

prototype

(available fordownload)

evaluation

casestudy

performanceevaluation

Overview of Contributions

1 2 3 4

a novel tool for dynamic enforcement of securityin distributed Java programs


Architecture of Encapsulations

Basis: Service Automata concept [Gay et al., FAST‘11]

inherits local policy and coordinator inherits modular architecture

Novel augmentation of CliSeAu event factory: abstracts security-irrelevant details of actions enforcer factory: refines decisions to concrete countermeasures design patterns (strategy, factory): integrate parametric components IPC: connects “left part” and “right part” benefits:

local policy less dependent on technical peculiarities of target decision-making can be placed into separate process than target

enforcer factory

event factory

interceptor

enforcer local policy

target

coordinator


Combining Capsules with Targets

Concept in-lining interception and imposition of countermeasures (left) placing decision-making into environment of program (right)

Key technologies used AspectJ for instrumentation of target programs’ bytecode TCP/IP sockets for communication within & between ECs key-value configuration files for selection of target and policy

Java codeof the

capsule

Java codeof the

program

environment of the

program

decider

JavaMOPClara

SASI,JavaMop…

Porscha,CoPilot…


CliSeAu

Goal automated encapsulation of a given distributed Java program flexibility in the choice of the program and the security policy

CliSeAu’s approach configuration determines target program and security policy each distributed component is encapsulated

CliSeAuconfig

policydistributed Java program


Enforcement for non-distributed Java programs JavaMOP [Rosu et al.]

based on AspectJ focus on efficiency; no abstraction

Polymer abstraction concept, for policy composition

Enforcement in distributed programs LGI/Moses [Minsky et al.]

program’s network interaction DiAna [Agha et al.]

piggy-backing, possibly delayed [KelbertPretschner ‘13+’14]

focus on usage control formal model for decentralized enforcement

Related Approaches


Case Study: Enforcing Chinese Wall

Goals evidence whether CliSeAu can be applied

to third-party programs evidence for possibility to re-use CliSeAu config parts basis for performance evaluation

Application scenario distributed file storage system Chinese Wall security policy 3 different Java file servers as target programs sound, decentralized enforcement

(even in case of simultaneous downloads)


Instantiation of CliSeAu intercepted events:

method calls underlying file downloads program-level, not API-level

deciding, cooperative & decentralized assigning actions to responsible ECs

via hash code of (user, COI) delegating the decision-making to the responsible EC

imposed countermeasures: suppress policy-violating downloads (2 of 3 targets) replace return value of method (1 of 3 target)

Case Study: Enforcing Chinese Wall

intercept events decide imposecountermeasure


Goals determine basic runtime overhead of CliSeAu determine effect of cooperation on runtime overhead

Experimental setup 3 different Java file servers for each: 10 file servers on a Linux machine downloading files of size 10KB overhead measured in FTP client,

averaged over 2500 experiments enforcement of Chinese Wall security policy

Performance Evaluation


Performance Evaluation: Results

Performance overhead on a single file download

Performance overhead for multiple hops roughly linear increase

in number of hops increase per hop: ≈1.35ms

AnomicFTPD DRS SimpleFTPD

local deciding 2.72ms (1.3%) 2.80ms (3.8%) 1.67ms (4.2%)

coordinated deciding (2 hops)

5.23ms (2.6%) 5.62ms (6.8%) 4.68ms (11.7%)

0 2 3 4 5 6 7 8 9 100369

121518

AnomicFTPDSimple-ftpdDRS

number of hops

ov

erh

ea

d (

ms

)


CliSeAu: Securing Distributed Java Programs by Cooperative Dynamic Enforcement

Our goals

enforcement for distributed Java programs

decentralized

system-wide security requirements

effective

efficient

Not in scope so far fault tolerance of CliSeAu network attacks on CliSeAu

http://www.mais.informatik.tu-darmstadt.de/CliSeAu


Appendix


Dynamic enforcement in distributed systems feasible:

intercepting individually at each agent of the distributed system imposing countermeasures individually at the agents

not feasible in general deciding at the agent that tried to perform an action ( soundness) deciding about all at a single agent ( performance)

Cooperative Decentralized Enforcement


Cooperative Enforcement

Goals for the enforcement capsules (ECs) capability of local deciding

deciding about events of the program it encapsulates to reduce communication overhead

capability of cooperative deciding requesting support by other ECs supporting other ECs in decision-making to enable sound decisions even when a single EC

does not have sufficient information

Challenges enabling cooperative deciding when needed

and local deciding when possible enabling sound decision-making for system-wide policies

without excessive synchronization


CliSeAu’s approach ECs cooperate by delegation every EC can specify when to delegate and when to decide locally delegation is non-blocking:

Cooperative Deciding


Architecture of Encapsulations

Goals for the enforcement capsules (ECs) support for cooperative decentralized deciding abstraction from security-irrelevant actions

(in the example: browsing server directories) abstraction from security-irrelevant details of actions

(in the example: download size) modular architecture

Challenge enabling flexibility in the supported programs and the security policies

while providing much fixed structure to simplify instantiation

richard gay – iciss, december 20, 2014 cliseau:securing distributed java programs by cooperative...

Documents