In the nick of time: Proactive prevention of obligation violations

ProSec, ITU, May 2nd, 2016

Søren Debois Joint work with Thomas Hildebrandt & David Basin

Previously, at the ProSec End Seminar…

• We just saw how to construct models of emergency response procedures

• … and how to simulate those procedures collaboratively.

And now:

• Can we extract information from that model automatically?

• Is it possible for the emergency response to reach a dead-end?

Plan

• Security Policies

• Security Policies as DCR Graphs

• Enforcement of DCR Policies

Security Policies

Security Policies

• Formal specification of what behaviour is admitted of a “secure” system.

• In this talk, a target system is a anything that produces actions.

• In this talk, a security policy regulates what actions the target system exhibits.

Enforcement

• A security policy is preferably runtime enforceable.

• Run the system in parallel with an enforcement mechanism which somehow ensures the system takes only the admitted actions.

Types of system actions• Controllable

The enforcement mechanism may deny the system those actions. E.g., deny withdrawing money from an overdrawn account.

• Causable The enforcement mechanism may cause the system to take these actions.

• Uncontrollable The enforcement mechanism can do nothing about these actions. It can observe them when they happen, though.

System model

gvim $HOME/votl_test.otl

Controllable actions

Un-controllable actions

Causable actions

Example Policy• Hospitals much (a) document proper treatment and (b) preserve

patient confidentiality. Some achieve this by moving records to off-site storage after a patient’s release.

• Here is a more detailed policy:

1. Records must be deleted within 14 days of release.

2. Records must not be deleted if archival is pending.

3. Records must be archived for at least 8 years.

4. Records must not be deleted should the patient be re- admitted within the 14 days.

Provisions

• Property dependent on the present or the past.

• “Patient records must not be deleted unless they have been archived in off-site storage.”

Obligations

• Property depending on the future.

• “Patient records must be deleted within 14 days of the patient’s release from hospital.”

DCR Security Policies

A good match!

• Conditions, milestones directly model provisions.

• Responses directly model obligations.

• Easily analysable run-time state —the model is the run-time state! (no exponential blow-up in, say, translating LTL to Büchi)

1. Records must be deleted within 14 days of release.

2. Records must not be deleted if archival is pending.

3. Records must be archived for at least 8 years.

4. Records must not be deleted should the patient be re- admitted within the 14 days.

Enforcing security policies

Enforcing provisions

• Deny controllable actions if they do not conform to the policy.

Enforcing obligations

• Cause causable actions to prevent missing deadlines.

Is this policy always enforceable?

Is this policy always enforceable?

Depends on what is causable and controllable

Not every policy is enforceable

• Timelock: No matter what you do, time cannot advance.

• Even if I can cause and control both A and B, I cannot make the TS obey this policy.

• We have a sufficient condition for a policy to be enforceable.

• “If an event can be come pending, I can in any marking find a way to execute it.”

• Static approximation based on inspection of relations.

Static approximation• An event is busy if it may

eventually be pending.

• Spot the busy event(s)?

• An e inhibits f iff e —>* f or e —<> f.

• Look for cycles in the sub-graph of inhibitors.

• If no cycles and all inhibitors causable, we can enforce the event e.

Conclusions

Conclusions• Enforce obligations by causing things to happen

when a deadline approaches.

• Such enforcement not always possible:

• Depends on what actions are causable

• Depends on the policy itself

• Static approximation to enforceability.

Thank you!

Søren Debois Joint work with Thomas Hildebrandt & David Basin