Many-to-Many Information Flow Policies
0 likes683 views
The document discusses many-to-many information flow policies that regulate how data moves between multiple security domains, emphasizing the need for diagrams and causal dependencies to manage these flows. It explores the semantics of such policies, their restrictions, as well as the importance of coordination and declassification in information disclosure. The authors present results on policy satisfaction and propose extensions for existing one-to-one policies to more complex many-to-many policies.
![BNDC
(bisimulation-based NI)
RBNI
(structural NI)
SNNI
(trace-based NI)
[N. Busi, R. Gorrieri, “Structural non-interference in elementary and trace nets”, Mathematical Structures in Computer Science, 2009]
[N. Busi, R. Gorrieri, “A survey of non-interference with Petri nets”, Lectures on Concurrency and Petri Nets 2003]
[R. Focardi, R. Gorrieri, “A Classification of Security Properties”, Journal of Computer Security, 1995]
• no H→L dependencies
• no H-L conflicts
Some notions of non-interference (allow L→H only) for safe Petri nets
• no H→L dependencies
• no direct H-L conflicts
• no H→L dependencies
( this paper)](https://image.slidesharecdn.com/talk-coordination2017-170620230742/85/Many-to-Many-Information-Flow-Policies-23-320.jpg)
![Decidability for a class of event structures
Key ideas:
• Deciding FOL properties of a regular trace event structures is
decidable [Madhusudan, LICS 2013]
• Policy satisfaction can be encoded in FOL](https://image.slidesharecdn.com/talk-coordination2017-170620230742/85/Many-to-Many-Information-Flow-Policies-52-320.jpg)
Many-to-Many Information Flow Policies
- 1. Many-to-Many Information Flow Policies Paolo Baldan Università di Padova Alessandro Beggiato IMT Lucca Alberto Lluch Lafuente DTU albl@dtu.dk DisCoTec/COORDINATION 2017, Neuchâtel, 19-22 June 2017
- 2. Introduction
- 3. SECRET PUBLIC SECRET PUBLIC DECLASSIFIER MANAGEMENT PUBLIC FINANCIALMEDICAL Information flow policies regulate how information flows between several security domains. Such policies may be diagrams like:
- 4. SECRET PUBLIC SECRET PUBLIC DECLASSIFIER MANAGEMENT PUBLIC FINANCIALMEDICAL Sometimes one-to-one relations are not enough… Information flow policies regulate how information flows between several security domains. Such policies may be diagrams like: NETWORK ENGINE INFOTAINMENT CONTROL ENGINE CONTROL SCREENS
- 5. SECRET PUBLIC SECRET PUBLIC DECLASSIFIER MANAGEMENT PUBLIC FINANCIALMEDICAL Sometimes one-to-one relations are not enough… Information flow policies regulate how information flows between several security domains. Such policies may be diagrams like: For example, to admit only… • Paths ENGINE CONTROL→NET→ENGINE NETWORK ENGINE INFOTAINMENT CONTROL ENGINE CONTROL SCREENS
- 6. SECRET PUBLIC SECRET PUBLIC DECLASSIFIER MANAGEMENT PUBLIC FINANCIALMEDICAL Sometimes one-to-one relations are not enough… Information flow policies regulate how information flows between several security domains. Such policies may be diagrams like: For example, to admit only… • Paths ENGINE CONTROL→NET→ENGINE • Flows {SECRET,DECLASSIF.} → PUBLIC NETWORK ENGINE INFOTAINMENT CONTROL ENGINE CONTROL SCREENS
- 7. SECRET PUBLIC SECRET PUBLIC DECLASSIFIER MANAGEMENT PUBLIC FINANCIALMEDICAL Sometimes one-to-one relations are not enough… Information flow policies regulate how information flows between several security domains. Such policies may be diagrams like: For example, to admit only… • Paths ENGINE CONTROL→NET→ENGINE • Flows {SECRET,DECLASSIF.} → PUBLIC • Flows from {SECRET} → {PUB1,PUB2}NETWORK ENGINE INFOTAINMENT CONTROL ENGINE CONTROL SCREENS
- 8. SECRET PUBLIC SECRET PUBLIC DECLASSIFIER MANAGEMENT PUBLIC FINANCIALMEDICAL Sometimes one-to-one relations are not enough… For example, to admit only… • Paths ENGINE CONTROL→NET→ENGINE • Flows {SECRET,DECLASSIF.} → PUBLIC • Flows from {SECRET} → {PUB1,PUB2} What does this mean at all? How to regulate such flows? How to keep a visual/intuitive notation? Information flow policies regulate how information flows between several security domains. Such policies may be diagrams like: NETWORK ENGINE INFOTAINMENT CONTROL ENGINE CONTROL SCREENS
- 9. Plan for today: • Information flow and causality • Why collective/simultaneous flows? • Semantics of policies, by examples • Some results • Conclusion
- 11. Alice Bob Information flow and causal dependencies send(x); u := 0; if g(y) then z := f(y); recv(?y); INTUITION: “if b depends on a then there is some flow from a to b” ... ...
- 12. Alice Bob send(x); u := 0; if g(y) then z := f(y); recv(?y); INTUITION: “if b depends on a then there is some flow from a to b” communication flow ... ... Information flow and causal dependencies
- 13. Alice Bob send(x); u := 0; if g(y) then z := f(y); recv(?y); INTUITION: “if b depends on a then there is some flow from a to b” communication flow explicit data flow... ... Information flow and causal dependencies
- 14. Alice Bob send(x); u := 0; if g(y) then z := f(y); recv(?y); INTUITION: “if b depends on a then there is some flow from a to b” communication flow explicit data flow implicit data flow ... ... Information flow and causal dependencies
- 15. Our models are labelled event structures, which consist of:
- 16. H L Our models are labelled event structures, which consist of: a set of security labels
- 17. disclose read L request_secret listen ignore Our models are labelled event structures, which consist of: a set of security labels a set of events H
- 18. disclose read L request_secret listen ignore Our models are labelled event structures, which consist of: a relation modelling causality (reflexive, transitive) a set of security labels a set of events H
- 19. disclose read L request_secret listen ignore Our models are labelled event structures, which consist of: a relation modelling causality (reflexive, transitive) another relation modelling conflicts (irreflexive, symmetric, inherited through causality) a set of security labels a set of events H
- 20. disclose H L POLICY read L request_secret listen ignore Policies are hyper graphs on the labels H
- 21. A model satisfies the policy if every direct causal dependency between different levels is justified by the policy. disclose H L POLICY read L request_secret listen ignore H justified by Policies are hyper graphs on the labels unjustified!
- 22. A model satisfies the policy if every direct causal dependency between different levels is justified by the policy. disclose H L POLICY read L request_secret listen ignore H justified by Policies are hyper graphs on the labels unjustified! How does this relate to existing approaches? Just restricting to L→H there a huge families of possible semantics.
- 23. BNDC (bisimulation-based NI) RBNI (structural NI) SNNI (trace-based NI) [N. Busi, R. Gorrieri, “Structural non-interference in elementary and trace nets”, Mathematical Structures in Computer Science, 2009] [N. Busi, R. Gorrieri, “A survey of non-interference with Petri nets”, Lectures on Concurrency and Petri Nets 2003] [R. Focardi, R. Gorrieri, “A Classification of Security Properties”, Journal of Computer Security, 1995] • no H→L dependencies • no H-L conflicts Some notions of non-interference (allow L→H only) for safe Petri nets • no H→L dependencies • no direct H-L conflicts • no H→L dependencies ( this paper)
- 24. l h l l h System h lh hl Event Structure PetriNetTransition System Traces l l Low view (only L) l l l h l h l l l Low view (L+H) Observational NI can miss H→L dependencies (a resource transformed by H may be leaked to L)
- 25. l l h l l’ h System Low view (only L) Low view (L+H) l l’ h l lh Event Structure PetriNetTransition System Traces l l l l’ l l’ l l’ l l’ Observational NI miss some H-L conflicts (L may guess non occurrence of H-events)
- 27. Why more than 2 levels?
- 28. Sometimes you really need to disclose Some information about passwords is always leaked in login systems
- 29. disclose H Sometimes you really need to disclose D read L H Leither you forbid this flow or you relax the policy POLICY
- 30. H L disclose H read L either you forbid this flow or you relax the policy POLICY Sometimes you really need to disclose
- 31. H L disclose H read L H L D POLICY Disclosure from H to L is allowed through a declassifying level D POLICY ✗ Sometimes you really need to disclose
- 32. H L check disclose H Sometimes you really need to disclose D authorise read L H L D POLICY Disclosure from H to L is allowed through a declassifying level D POLICY
- 34. disclose H H L D POLICY read L Disclosure from H to L is allowed if it depends on declassifying level D ✗ You may not require H and D to coordinate
- 35. disclose H D H L D POLICY authorise read L Disclosure from H to L is allowed if it depends on declassifying level D ✔ You may not require H and D to coordinate
- 37. POLICY disclose H D H L D read L Disclosure from H to L is allowed if also D is influenced ✗ In some cases it would be ok for D to log the leaks
- 38. POLICY disclose H D H L D record read L Disclosure from H to L is allowed if also D is influenced ✔ In some cases it would be ok for D to log the leaks
- 39. Semantics of policies, by examples
- 40. A Flows allowed by a policy {A,B} E B A E B POLICY E a e IDEA: A direct causality a e is allowed if …
- 41. A B A E B POLICY E a b e IDEA: A direct causality a e is allowed if it occurs in a context like this INTUITION: Every time E listens to A, it also needs to listen to B. Flows allowed by a policy {A,B} E
- 42. B A E B POLICY E a A IDEA: A direct causality e a is allowed if … e Flows allowed by a policy E {A,B}
- 43. B A E B POLICY E INTUITION: Every time E talks to A, it also talks to B. B may have other “unrelated” causal or conflict dependencies. a b A IDEA: A direct causality e a is allowed if it occurs in a context like this • e Flows allowed by a policy E {A,B}
- 44. A D B POLICYC a c A IDEA: A direct causality a c is allowed if … C Flows allowed by a policy {A,B} {C,D}
- 45. B A D B POLICYC INTUITION: Every time A talks to B, it also talks to D and B also talks to C and D. a b c A IDEA: A direct causality a c is allowed if it occurs in a context like this • C D d Flows allowed by a policy {A,B} {C,D}
- 46. Some results
- 49. Relating/Relaxing Policies …adding/relaxing flows …splitting the required flow sources A B C A B C
- 50. Relating/Relaxing Policies …adding/relaxing flows …splitting the required flow sources …splitting the required flow targets A B C A B C A B C A B C
- 51. The most restrictive policy for a model may not be unique A CB a c b The model satisfies both policies. None of the policies can be restricted for this model. A B POLICY C A B POLICY C Example
- 52. Decidability for a class of event structures Key ideas: • Deciding FOL properties of a regular trace event structures is decidable [Madhusudan, LICS 2013] • Policy satisfaction can be encoded in FOL
- 53. Conclusion
- 54. What we have done: • Focus on causality-based information flows • Extend one-to-one policies (e.g. H→D→L,…) • to many-to-many policies (e.g. {H,D}→L, H→{L,D},…) • Study some semantic/decidability properties Concluding remarks
- 55. What we have done: • Focus on causality-based information flows • Extend one-to-one policies (e.g. H→D→L,…) • to many-to-many policies (e.g. {H,D}→L, H→{L,D},…) • Study some semantic/decidability properties What else is in the paper? • Additional coordination constraints on the flows: • directness • fairness • A case study and some application domains Concluding remarks
- 56. What we have done: • Focus on causality-based information flows • Extend one-to-one policies (e.g. H→D→L,…) • to many-to-many policies (e.g. {H,D}→L, H→{L,D},…) • Study some semantic/decidability properties What else is in the paper? • Additional coordination constraints on the flows: • directness • fairness • A case study and some application domains What we are doing: • More flexible “Causality Patterns” (see talk at ICE 2017) • Verification for safe Petri nets / Static analysis for programs • Consider the actual transfer of (the same) information Concluding remarks
- 57. Thanks!