1. 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 10 th International Conference on Information Systems Security, Hyderabad, India funded by CASED, by the DFG under project FM-SecEng, and by TU Darmstadt

2. Richard Gay – ICISS, December 20, 2014 Dynamic Security Enforcement Enforcement as encapsulation Duties of an encapsulation 2 program (needs to be trusted) enforcement mechanism program (trustworthy) “encapsulation” intercept eventsdecide impose countermeasure PEP in XACML PIP+PDP in XACML

3. Richard Gay – ICISS, December 20, 2014 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 3  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]

4. Richard Gay – ICISS, December 20, 2014 4 Security in Distributed Programs File server 1File server 2 download file of Bank A download file of Bank B financial auditor checks for local enforcement checks for local enforcement

5. Richard Gay – ICISS, December 20, 2014 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 5 Service Automata Concept interceptor enforcerlocal policy target coordinator

6. Richard Gay – ICISS, December 20, 2014 CliSeAu concept cooperative enforcement modular architecture combination technique prototype (available for download) evaluation case study performance evaluation 6 Overview of Contributions 1234 a novel tool for dynamic enforcement of security in distributed Java programs

7. Richard Gay – ICISS, December 20, 2014 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 7 enforcer factory event factory interceptor enforcerlocal policy target coordinator

8. Richard Gay – ICISS, December 20, 2014 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 8 Java code of the capsule Java code of the program environment of the program decider JavaMOP Clara JavaMOP Clara SASI, JavaMop… SASI, JavaMop… Porscha, CoPilot… Porscha, CoPilot…

9. Richard Gay – ICISS, December 20, 2014 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 9 CliSeAu config policydistributed Java program

10. Richard Gay – ICISS, December 20, 2014 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 Related Approaches

11. Richard Gay – ICISS, December 20, 2014 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) 11

12. Richard Gay – ICISS, December 20, 2014 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) 12 Case Study: Enforcing Chinese Wall intercept eventsdecide impose countermeasure

13. Richard Gay – ICISS, December 20, 2014 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 Performance Evaluation

14. Richard Gay – ICISS, December 20, 2014 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 14 AnomicFTPDDRSSimpleFTPD local deciding2.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%)

15. Richard Gay – ICISS, December 20, 2014 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 15 http://www.mais.informatik.tu-darmstadt.de/CliSeAu

16. Richard Gay – ICISS, December 20, 2014 Appendix 16

17. Richard Gay – ICISS, December 20, 2014 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) 17 Cooperative Decentralized Enforcement

18. 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

19. Richard Gay – ICISS, December 20, 2014 CliSeAu’s approach  ECs cooperate by delegation  every EC can specify when to delegate and when to decide locally  delegation is non-blocking: 19 Cooperative Deciding

20. 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