Verifying Security Policies using Host Attributes 34 th IFIP International Conference on Formal Techniques for Distributed Objects, Components and Systems Cornelius Diekmann 1 Stephan-A. Posselt 1 Heiko Niedermayer 1 Holger Kinkelin 1 Oliver Hanka 2 Georg Carle 1 1 2 Airbus Group Innovations FORTE, 2014, Verifying Security Policies Using Host Attributes 1/21
Fakulta t fu r Informatik Technische Universita t Mu nchen Example: Aircraft Cabin Data Network google image search FORTE, 2014, Verifying Security Policies Using Host Attributes: Example & Demo 2/21
Example: Aircraft Cabin Data Network Policy CC IFEsrv SAT C1 C2 IFE1 IFE2 WiFi P1 P2 Policy Access Control Matrix Network Connectivity Structure FORTE, 2014, Verifying Security Policies Using Host Attributes: Example & Demo 3/21
Example: Security Invariants as Host Attributes Crew Entertain CC! IFEsrv INET SAT POD INET C1 C2 IFE1 IFE2 WiFi! crew entertain P1 POD P2 FORTE, 2014, Verifying Security Policies Using Host Attributes: Example & Demo 4/21
Example: Security Invariants as Host Attributes Crew Entertain CC! IFEsrv master INET SAT POD INET C1 C2 IFE1 slave IFE2 slave WiFi! crew entertain P1 POD P2 FORTE, 2014, Verifying Security Policies Using Host Attributes: Example & Demo 4/21
Example: Security Invariants as Host Attributes Crew Entertain CC secret! IFEsrv declassify master INET SAT POD INET C1 secret C2 secret IFE1 confid. slave IFE2 confid. slave WiFi! crew entertain P1 POD P2 FORTE, 2014, Verifying Security Policies Using Host Attributes: Example & Demo 4/21
Big Picture: Verification Demo Formal verification Executable, no need for hand-crafted proofs FORTE, 2014, Verifying Security Policies Using Host Attributes: Example & Demo 5/21
Big Picture: Debugging Demo add coffee machine, connect it to IFE1 [invalid] inv1 :... [invalid] inv2 :... [valid] inv3 :... IFE1 Aircraft-Entertain 1 DomainMember POD2 Aircraft-Entertain-POD SatGW POD1 Aircraft-Entertain-INET Aircraft-Entertain-POD IFE2 WifiAccess Crew2 Aircraft-Entertain Aircraft-Entertain-POD trust: 1 Aircraft-Crew 1 2 DomainMember coffee IFEsrv Aircraft-Entertain 0!trusted! SecurityGatewayIN Crew1 Aircraft-Crew 2 CabinCoreSrv Aircraft-Crew trust: 1 2 FORTE, 2014, Verifying Security Policies Using Host Attributes: Example & Demo 6/21
Big Picture: Invariant Feedback Demo CC secret! IFEsrv declassify master INET SAT C1 secret C2 secret IFE1 confid. slave IFE2 confid. slave WiFi! crew.aircraft entertain.aircraft P1 POD P2 FORTE, 2014, Verifying Security Policies Using Host Attributes: Example & Demo 7/21
This Talk policy = security invariants security invariants = policy It s all about the security invariants! Scenario-Specific Knowledge Security Invariant Host Attribute Mapping + Generic Invariant Formal HOL Semantics Security Policy Directed Graph G =(hosts, allowed flows) Firewalls, ACL, etc FORTE, 2014, Verifying Security Policies Using Host Attributes: This Talk 8/21
Definitions Policy G = (V, E) directed graph G = (V set) ((V V) set) Host mapping P: V Ψ total function maps a host to an attribute FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 9/21
Definitions Policy G = (V, E) directed graph G = (V set) ((V V) set) Host mapping P: V Ψ total function maps a host to an attribute Security invariant template m: m(g, (V Ψ)) Predicate (total, Boolean-valued function) first argument: security policy second argument: host attribute mapping m(g, P) G fulfills the invariant specified by m and P FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 9/21
Example Label-based information flow security: Bell LaPadula model Security clearances, i. e. host attributes Ψ = {unclassified, confidential, secret, topsecret} Invariant template, i. e. no read-up and no write-down: m ( (V, E), P ) (s, r) E. P(s) P(r) FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 10/21
Example Label-based information flow security: Bell LaPadula model Security clearances, i. e. host attributes Ψ = {unclassified, confidential, secret, topsecret} Invariant template, i. e. no read-up and no write-down: m ( (V, E), P ) (s, r) E. P(s) P(r) Scenario-specific knowledge P(db1 ) = confidential all other hosts are unclassified P = (λh. if h = db 1 then confidential else unclassified) m(g, P) db 1 does not leak confidential information there is no non-reflexive outgoing edge from db1 FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 10/21
Security Invariants cont. Security strategy Information Flow Strategy (IFS) confidentiality Access Control Strategy (ACS) integrity, controlled access m must be either IFS or ACS Monotonicity Prohibiting more does not harm security m((v, E), P) and E E then m((v, E ), P) Composition Composability and modularity enabled by design m1 (G, P 1 ) m k (G, P k ) FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 11/21
Offending Flows If a security invariant is violated m(g, P) Flows F E responsible for the violation set offending flows ( G, P ) is the set of all such minimal F FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 12/21
Offending Flows If a security invariant is violated m(g, P) Flows F E responsible for the violation set offending flows ( G, P ) is the set of all such minimal F i.e. the set of all minimal sets which violate m set offending flows ( G, P ) = { F E m ( G, P ) m ( (V, E \ F), P ) (s, r) F. m ( (V, (E \ F ) {(s, r)}), P )} FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 12/21
Offending Flows If a security invariant is violated m(g, P) Flows F E responsible for the violation set offending flows ( G, P ) is the set of all such minimal F Example: m is that v 1 must not access v 3 transitively v 2 v 2 v 2 v 1 v 3 v 1 v 3 v 1 v 3 G {(v 1, v 2 )} {(v 2, v 3 )} set offending flows ( G, P ) = { {(v 1, v 2 )}, {(v 2, v 3 )} } FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 12/21
Example: Offending Flows for the Bell LaPadula Model Recall: m ( (V, E), P ) (s, r) E. P(s) P(r) set offending flows ( G, P ) = {{ {(s, r) E P(s) > P(r)} } if m(g, P) if m(g, P) Uniquely defined Can be computed in linear time This holds for all similar-structured security invariants FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 13/21
Analysis: Offending Flows Do the offending flows always exist? Theorem 1. For m monotonic, let G deny-all = (V, ). If m(g, P) then m ( G deny-all, P ) set offending flows(g, P) A security violation can be fixed by tightening the policy iff the invariant holds for the deny-all policy FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 14/21
Example: Policy Construction G all = (V, V V ) G max = (V, V V \ set offending flows ( G all, P ) ) Iterate this over all m i Sound for arbitrary m Complete for m similar to Bell LaPadula Gmax is the uniquely defined maximum policy FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 15/21
Who is responsible for a violation? A violation either happens at the sender or the receiver ACS initiator provokes an access control restriction IFS leak only occurs when the information reaches the unintended receiver Definition. For F set offending flows(g, P) { { s (s, r) F} if ACS offenders(f ) = { r (s, r) F} if IFS FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 16/21
Auto Completion of Host Mappings P is a total function V Ψ User-specified incomplete host mapping: P C V Ψ Default value: Ψ { ψ if (v, ψ) P C P(v) = else FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 17/21
Auto Completion of Host Mappings P is a total function V Ψ User-specified incomplete host mapping: P C V Ψ Default value: Ψ { ψ if (v, ψ) P C P(v) = else What is a secure? Everything forbidden? Barely usable! can never solve an existing security violation must never mask potential security risks! FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 17/21
Secure Auto Completion of Host Mappings Replacing the host attribute of any offenders by must guarantee that no security-relevant information is masked. Definition. is a secure default attribute if G P. F set offending flows ( G, P ). v offenders(f). m ( G, P v ) Secure and permissive = everything forbidden, security proof easy can be more permissive, e.g., Bell LaPadula = unclassified hosts can freely interact P C = (db 1, confidential) Security invariant for complete network restrictions only for interactions with db 1 FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 18/21
Example m(g, P) New host x P(x) = (P is not updated) Magic oracle P oracle (x) = ψ x is an attacker m(g, P oracle ) Is the security violation exposed without the oracle? If m(g, P oracle ) then m(g, P x ) Hence m(g, P) The security violation is never masked! FORTE, 2014, Verifying Security Policies Using Host Attributes: Formalization 19/21
Conclusion Monotonic Security Invariants Verify policy Fix security violations Construct policy Construct easily and end-user-friendly Fully machine-verified with Isabelle/HOL https://github.com/diekmann/topos = λ β Isabelle α FORTE, 2014, Verifying Security Policies Using Host Attributes: Conclusion 20/21
Thanks for your attention! Questions? FORTE, 2014, Verifying Security Policies Using Host Attributes: Thank You! 21/21
Backup Slides FORTE, 2014, Verifying Security Policies Using Host Attributes: Appendix 21/21
Example: Aircraft Cabin Data Network CC The Cabin Core Server (essential aircraft features). air conditioning, crew telecommunication... C1, C2 Two crew mobile devices. identify passenger calls, make announcements... IFEsrv The In-Flight Entertainment server. movies, Internet... IFE1, IFE2 Two In-Flight entertainment displays (thin client). Mounted at the back of seats Movies and Internet... Wifi A wifi hotspot. Internet access for passengers owned devices Sat A satellite uplink to the Internet. P1, P2 Two passenger owned devices. laptops, smartphones... FORTE, 2014, Verifying Security Policies Using Host Attributes: Appendix 21/21
Example: Security Invariants Invariant 1: Domain Hierarchy Different protection domains Devices may send to their own (sub-)domains entertain aircraft crew Trust level are available INET POD Invariant 2: Security Gateway Slave devices are bound to a master Master controls all communication to/between them. IFE displays (thin clients) are strictly bound to IFEsrv Invariant 3: Bell LaPadula Information flow restrictions secret crew communication confidential (< secret) passenger communication (privacy) FORTE, 2014, Verifying Security Policies Using Host Attributes: Appendix 21/21
Stateful Implementation C2 P2 C1 P1 IFE2 IFE1 CC Wifi IFEsrv SAT Cornelius Diekmann, Lars Hupel, and Georg Carle. Directed Security Policies: A Stateful Network Implementation. In ESSS, Singapore, May 2014. FORTE, 2014, Verifying Security Policies Using Host Attributes: Appendix 21/21
Bell LaPadula with Trust Prevent information leakage P(v).sc is v s security clearance P(v).trust m ( (V, E), P ) (s, r) E. { True P(s).sc P(r).sc if P(r).trust otherwise FORTE, 2014, Verifying Security Policies Using Host Attributes: Appendix 21/21
Domain Hierarchy Hierarchical structures Ψ = fully qualified domain names {a.b.c, b.c, c,...} is below or at the same hierarchy level a.b.c a.b.c a.b.c b.c a.b.c c Trust: Act as if were in higher hierarchy position Trust 1 = one position higher chop(a.b.c, 1) = a.c m ( (V, E), P ) (s, r) E. P(r).level chop ( P(s).level, P(s).trust ) FORTE, 2014, Verifying Security Policies Using Host Attributes: Appendix 21/21
Security Gateway Approve intra-domain communication between domain members by a central instance (security gateway) m ( (V, E), P ) (s, r) E, s r. table ( P(s), P(r) ) snd rcv rslt explanation sgw * Can send to the world. sgwa * memb sgw Can contact its security gateway. memb sgwa memb memb Must not communicate directly. May communicate via sgw(a). memb default No restrictions for direct access to outside world. Outgoing accesses are not within the invariant s scope. default sgw Not accessible from outside. default sgwa Accessible from outside. default memb Protected from outside world. default default No restrictions. FORTE, 2014, Verifying Security Policies Using Host Attributes: Appendix 21/21