many-to-many information flow policies
TRANSCRIPT
Many-to-Many Information Flow Policies
Paolo Baldan Università di Padova
Alessandro Beggiato IMT Lucca
Alberto Lluch Lafuente DTU
DisCoTec/COORDINATION 2017, Neuchâtel, 19-22 June 2017
Introduction
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:
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
INFOTAINMENTCONTROL
ENGINECONTROL
SCREENS
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
INFOTAINMENTCONTROL
ENGINECONTROL
SCREENS
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
INFOTAINMENTCONTROL
ENGINECONTROL
SCREENS
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
INFOTAINMENTCONTROL
ENGINECONTROL
SCREENS
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
INFOTAINMENTCONTROL
ENGINECONTROL
SCREENS
Plan for today: • Information flow and causality • Why collective/simultaneous flows? • Semantics of policies, by examples • Some results • Conclusion
Information flowand causality
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”
...
...
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
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
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
Our models are labelled event structures, which consist of:
H L
Our models are labelled event structures, which consist of:a set of security labels
disclose
read
Lrequest_secret
listen
ignore
Our models are labelled event structures, which consist of:a set of security labels
a set of eventsH
disclose
read
Lrequest_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 eventsH
disclose
read
Lrequest_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 eventsH
disclose
H
L
POLICY
read
Lrequest_secret
listen
ignore
Policies are hyper graphs on the labels
H
A model satisfies the policy if every direct causal dependency between different levels is justified by the policy.
disclose
H
L
POLICY
read
Lrequest_secret
listen
ignore
H
justified by
Policies are hyper graphs on the labels
unjustified!
A model satisfies the policy if every direct causal dependency between different levels is justified by the policy.
disclose
H
L
POLICY
read
Lrequest_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.
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)
l h
l
l h
System
h
lhhl
Even
t St
ruct
ure
Petri
Net
Tran
sitio
n Sy
stem
Trac
es 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)
l l
h
l l’
h
System Low view (only L)
Low view (L+H)
l l’
h
llh
Even
t St
ruct
ure
Petri
Net
Tran
sitio
n Sy
stem
Trac
es
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)
Why more than2 levels?
Sometimes you really need to disclose
Some information about passwords is always leaked in login systems
disclose
H
Sometimes you really need to disclose
D
readL
H
Leither you forbid this flow or you relax the policy
POLICY
H
L
disclose
H
readL
either you forbid this flow or you relax the policy
POLICY
Sometimes you really need to disclose
H
L
disclose
H
readL
H
L
D
POLICY
Disclosure from H to L is allowed through a declassifying level D
POLICY
✗
Sometimes you really need to disclose
H
Lcheck
disclose
H
Sometimes you really need to disclose
D
authorise
readL
H
L
D
POLICY
Disclosure from H to L is allowed through a declassifying level D
POLICY
Why “collective” flows?
disclose
H
H
L
D
POLICY
readL
Disclosure from H to L is allowed if it depends on declassifying level D
✗
You may not require H and D to coordinate
disclose
H
D
H
L
D
POLICYauthorise
readL
Disclosure from H to L is allowed if it depends on declassifying level D
✔
You may not require H and D to coordinate
Why “simultaneous” flows?
POLICY
disclose
H
D
H
L
D
readL
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
POLICY
disclose
H
D
H
L
D
record
readL
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
Semantics of policies, by examples
A
Flows allowed by a policy {A,B} E
B
A
E
B
POLICY
Ea
e
IDEA: A direct causality a e is allowed if …
A B
A
E
B
POLICY
Ea 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
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}
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}
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}
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
Dd
Flows allowed by a policy {A,B} {C,D}
Some results
Relating/Relaxing Policies
Relating/Relaxing Policies
…adding/relaxing flows
Relating/Relaxing Policies
…adding/relaxing flows
…splitting the required flow sources
A B
C
A B
C
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
The most restrictive policy for a model may not be unique
A CBa
cb
The model satisfies both policies.
None of the policies can be restricted for this model.
A B
POLICY
C
A B
POLICY
C
Example
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
Conclusion
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
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
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
Thanks!