Policy Languages and Enforcement

1. 4th IAPP Privacy Summit Policy Languages and Enforcement John Mitchell Stanford February 2004

2. PORTIA research project • Sensitive Information in a Wired World • Team • Stanford, Yale, Stevens, NYU, UNM, … • Topics • Privacy-preserving data mining • Policy languages and enforcement • Identity theft and identity privacy • Using trusted platforms • Contact: http://crypto.stanford.edu/portia/

3. Enterprise Access Control Policy When What Who Where Why Joe can open financials.xls on his laptop using wired SSL Resource Resource User Who Right What Constraint When Where

4. Distributed Access Control Policy Resource Policy Policy Resource Resource Protect distributed resources with distributed policy ID Policy at site A may govern resources at site B

5. Decentralized Policy Example EPub Alice Grants access to university students Trusts universities to certify students Trusts ABU to certify universities Alice is a student StateU ABU StateU is a university

6. Role-based Trust-management (RT) RT0: Decentralized Roles RTD: forSelective Use of Role memberships RTT : forSeparation of Duties RT1: Parameterized Roles RT2: Logical Objects RT1C: structured resources RT2C: structured resources RTT and RTD can be used (either together or separately) with any of the five base languages: RT0, RT1, RT2, RT1C, and RT2C

7. Policy Management Lifecycle Plan Improve Analyze Enforce Measure

8. Policy lifecycle issues • Requirements capture • What should the policy say? • Development • Adapt standard modules; build new ones; combine • Evaluation • Does the policy say what we want? • Analysis Testing Debugging • Compliance • Can the policy be enforced by info system? • Maintenance • Change as needed as requirements evolve

9. EPAL Concepts • Condition, ruling, obligations • If condition then outcome • Outcome = ruling  obligations • Ruling = { yes, no, don’t care} • Obligations: actions that must occur • Examples • If employee owns the file then yes • If anyone accesses data then don’t care and log the request

10. Policy language design space Permit / Deny Permit only Resolve contradiction Can be contradictory EPAL Ordered

11. EPAL order priority • Intuitive ? • Need to give exception before general case • Birds can fly • Penguins cannot fly • Efficiency • Cannot evaluate sub-policies in parallel • Scalability • How to combine separate sub-policies?

12. Unreachable If male then yes If female then no If manager then no Inapplicable If manager then yes If VP then no If male then no Ineffective If VP then {run} If manager then {run, jump} Redundant If manager then {run, jump} If VP then {run} Some examples A policy editor could detect these situations

13. Policy Combination Denied Denied Denied + = OK Permitted Permitted Permitted Denied Denied Denied + = ?? Permitted Permitted Permitted

14. Policy Language and Deduction • Specification • State policy succinctly and directly • Confident that policy captures intention • Enforcement • Deduction, proof of compliance • Manage policy lifecycle • Policy development tools • Safety and availability analysis

15. Policy lifecycle issues • Requirements capture • What should the policy say? • Development • Adapt standard modules; build new ones; combine • Evaluation • Does the policy say what we want? • Analysis Testing Debugging • Compliance • Can the policy be enforced by info system? • Maintenance • Change as needed as requirements evolve

16. Questions? • Policy development • What concepts are important? • Permissions? Denials? Obligations? Audit trail? • Enforcement • IT infrastructure vs Legal structure • End-to-end privacy infrastructure • Customer – Browser – Web site – Database • Outsourcing and institutional partnerships