Transcript CliSeAu: Securing Distributed Java Programs by Cooperative

Richard Gay – ICISS, December 20, 2014
10th International Conference on Information Systems Security, Hyderabad, India
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
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
“encapsulation”
program
(needs to be trusted)
program
(trustworthy)
enforcement mechanism
Duties of an encapsulation
intercept events
PEP in
XACML
decide
PIP+PDP
in XACML
impose
countermeasure
PEP in
XACML
Richard Gay – ICISS, December 20, 2014
3
Security in Distributed Programs
Related work (selected)
 SASI [Erlingsson, Schneider ‘99]
 Service Automata [Gay et al. ‘11]
 Security Automata [Schneider ’00]
 MFOTL enforcement [Basin et al. ‘10, ‘12]
 Edit Automata [Ligatti et al. ’02, ‘05, ‘09]
 Information-flow enforcement [e.g.,
 Polymer [Bauer et al. ’05, ‘09]
 JavaMOP [Rosu et al. ’07, ’12, ‘12]
Guernic ’07,…,Chudnov et al. ’14]
 Usage control [e.g.,
Pretschner et al. ‘13, ‘14]
Our goals
 dynamic enforcement for distributed Java programs
 system-wide security requirements
 decentralized to avoid bottlenecks and single points of failure
 effective
 efficient
Richard Gay – ICISS, December 20, 2014
4
Security in Distributed Programs
File server 1
File server 2
checks
for local
enforcement
checks
for local
enforcement
download
file of Bank A
download
file of Bank B
financial auditor
Richard Gay – ICISS, December 20, 2014
5
Service Automata Concept
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
interceptor
coordinator
enforcer
local policy
target
Remaining challenges
 a cooperative enforcement mechanism for Java programs
 a combination technique for the mechanism with a Java program
Richard Gay – ICISS, December 20, 2014
6
Overview of Contributions
CliSeAu
a novel tool for dynamic enforcement of security
in distributed Java programs
concept
cooperative
enforcement
prototype
modular
architecture
combination
technique
1
2
(available for
download)
evaluation
case
study
performance
evaluation
3
4
Richard Gay – ICISS, December 20, 2014
7
Architecture of Encapsulations
Basis: Service Automata concept [Gay et al., FAST‘11]
 inherits local policy and coordinator
event factory
 inherits modular architecture
interceptor
coordinator
enforcer
local policy
target
enforcer factory
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
Richard Gay – ICISS, December 20, 2014
8
Combining Capsules with Targets
Concept
SASI,
JavaMop…
 in-lining interception and imposition of countermeasures (left)
 placing decision-making into environment of program (right)
Java
code
of the
program
Java
code
of the
capsule
environment
of the
program
Porscha,
CoPilot…
decider
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
JavaMOP
Clara
Richard Gay – ICISS, December 20, 2014
9
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
config
CliSeAu
distributed Java program policy
Richard Gay – ICISS, December 20, 2014
Related Approaches
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
10
Richard Gay – ICISS, December 20, 2014
11
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)
Richard Gay – ICISS, December 20, 2014
12
Case Study: Enforcing Chinese Wall
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)
intercept events
decide
impose
countermeasure
Richard Gay – ICISS, December 20, 2014
Performance Evaluation
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
13
Richard Gay – ICISS, December 20, 2014
14
Performance Evaluation: Results
Performance overhead on a single file download
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%)
Performance overhead for multiple hops
in number of hops
 increase per hop: ≈1.35ms
overhead (ms)
 roughly linear increase
18
15
12
9
6
3
0
AnomicFTPD
Simple-ftpd
DRS
0
2
3
4 5 6 7
number of hops
8
9
10
Richard Gay – ICISS, December 20, 2014
15
CliSeAu: Securing Distributed Java Programs by
Cooperative Dynamic Enforcement
Our goals
 enforcement for distributed Java programs
 decentralized
 system-wide security requirements
 effective
 efficient
http://www.mais.informatik.tu-darmstadt.de/CliSeAu
Not in scope so far
 fault tolerance of CliSeAu
 network attacks on CliSeAu
Richard Gay – ICISS, December 20, 2014
Appendix
16
Richard Gay – ICISS, December 20, 2014
17
Cooperative Decentralized Enforcement
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)
Richard Gay – ICISS, December 20, 2014
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
18
Richard Gay – ICISS, December 20, 2014
Cooperative Deciding
CliSeAu’s approach
 ECs cooperate by delegation
 every EC can specify when to delegate and when to decide locally
 delegation is non-blocking:
19
Richard Gay – ICISS, December 20, 2014
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
20