Apply Model Checking to Security Analysis in Trust Management

1. Apply Model Checking to Security Analysis in Trust Management Mark Reith, Jianwei Niu, William Winsborough CS 7123 Research Seminar 17 Sept 07

2. Overview • Motivation • Background Concepts • RT Language • Model Checking • Policy Maintenance Framework • Modeling and Heuristics • Visualization • Policy Correction • Future Work

3. Motivation • Access control of information systems has never been more important… • Global distributed systems • Massive scaled software projects • Ecommerce • Problem: management of access control • Centralized vs. decentralized • Scalability issues

4. Motivation • Centralized access control • Security administrator sets user permissions • “Root Bottleneck” problem • Delegate administration permissions • Decentralized access control • Stakeholders collaborate & set permissions (no centralized authority) • Trust Management • Delegate user permissions and authority

5. Motivation • Trust management is concerned with: • Providing delegation of access control in a scalable manner (attributes vs. identity) • Using trusted (and possibly unknown) entities to specify the delegation in the form of policy • Reasoning about such delegation; i.e. can we ensure that certain security properties hold in spite of unknown entities

6. Motivation • Trust Management • Users collectively determine authorization • Global security policy that changes • Stakeholders want to ensure delegation occurs within security objectives • Security analysis determines if the policy always satisfies a given property • Despite changes to policy configuration

7. Motivation • Interesting security properties: • Will Alice always have access to a resource? (Availability) • Can Eve ever gain access to a resource? (Safety) • Can any user have access to both resources at the same time? (Mutual Exclusion) • Do users with access to one resource always have access to another resource? (Role Containment)

8. Motivation • Authoring an access control policy that reflect the author’s intentions is difficult • Authors are not necessarily security experts • Size/complexity of the policy • Analysis of security properties is not always tractable • Even if a policy fails to satisfy a property, no information as to why it failed

9. Motivation • Need tool support to assist in verifying that a given security policy satisfies a property • More importantly, need a means to show in which policy states a property fails • Provide intuition to author on how to correct • Who is this important to? • Policy authors (sec admin, resource owners) • Software engineers (design/test/evaluation)

10. Motivation • Seek to provide a lightweight approach such as model checking to analyze security properties • Highly automated • Established tool support • Accepted in software engineering for critical systems • Provides counterexamples when properties fail to hold

11. The Role-based Trust Management Policy Language

12. RT Language • Describes an access control policy as a set of policy statements • Statements introduce users into roles, where a role is set of a users that have access to a resource (similar to RBAC) • Each statement may either: • Introduce an entity (principal) into the policy • Describe how access or authority is delegated

13. Simple Member • Principal A introduces principal B into role A.r • Type I Syntax: A.r  B • A.r is a role • B is a principal • Read as “role A.r includes B” • Example: Alice.friend  Bob

14. Simple Inclusion • Principal A delegates membership of A.r to principal B • Type II Syntax: A.r  B.r • A.r and B.r are both roles • Read as “role A.r includes the membership of role B.r” • Example: Alice.friend  Bob.friend

15. Linked Inclusion • Principal A delegates membership of A.r to all principals in role B.r1 • Type III Syntax: A.r  B.r1.r2 • A.r is a role, and B.r1.r2 is a linking role • Read as “role A.r includes the membership characterized by the membership of B.r1” • Example: Alice.friend  Bob.family.friend

16. Intersection Inclusion • Principal A delegates membership of A.r to principals B and C • Type IV Syntax: A.r  B.r ∩ C.r • A.r, B.r and C.r are roles • Read as “role A.r includes the intersected membership of roles B.r and C.r” • Example: Alice.friend  Bob.friend ∩ Carl.friend

17. Dynamic Policies • Dynamic Policy - role owners may grant/revoke delegation and member inclusion at any time (PKI certificates) • Policy may change over time • Add new credentials (statements) to the policy • Define new roles • Redefine existing roles • Remove/expire statements

18. Dynamic Policies • The current set of statements is the “state” of the policy • All of the configurations of all of the possible statements is the state space

19. RT Security Analysis • Analysis to determine if security properties hold despite how the policy changes • For analysis purposes only, we place restrictions on what changes can be made • Restrictions represent a trusted and competent user • Restrict how roles may grow or shrink • Growth restrictions prevent new definitions of role • Shrink restrictions prevent definitions of a role to be removed

20. RT Security Analysis • Analysis question formed as a query • Three Forms – uses universal/existential quantification • Membership: A.r includes {D1, D2, …} • In reachable states, is it possible/necessary for Alice to get access to a resource? • Boundedness: {D1, D2, …} includes A.r • In reachable states, is it possible/necessary that the resource can be accessed by only Alice or Bob?

21. Queries • Inclusion: X.u includes A.r • In all reachable states, is every member of A.r also in X.u • Most interesting case because time complexity is coNEXP w.r.t. # of policy statements • Sistla et al. proved upper/lower bound to be EXPTIME

22. Queries • Inclusion: X.u includes A.r • Fails if and only if a principal K is found to be a member of A.r but not X.u • This policy state is a counterexample!

23. Example • Initial Policy: <0> Alice.friend  Bob.friend <1> Bob.friend  Carl.friend <2> Bob.friend  Dave.family <3> Carl.friend  Ernie <4> Dave.family  Frank • Query: • Necessary that Alice’s friends include Ernie? • Possible that Alice’s friends include Gary? • Necessary that Alice’s friends are at most Ernie and Frank? At least Ernie and Frank? • Necessary that Alice’s friends are Carl’s friends? Restrictions: Growth = {Alice.friend} Shrink = {Alice.friend, Bob.friend, Carl.friend}

24. Example • Initial Policy: <0> Alice.friend  Bob.friend <1> Bob.friend  Carl.friend <2> Bob.friend  Dave.family <3> Carl.friend  Ernie <4> Dave.family  Frank • Query: • Necessary that Alice’s friends include Ernie? • Possible that Alice’s friends include Gary? • Necessary that Alice’s friends are at most Ernie and Frank? At least Ernie and Frank? • Necessary that Alice’s friends are Carl’s friends?

25. Model Checking

26. Background Info • Model Checking – formal method to verify properties in a given model through an exhaustive search of the model’s state space. • Given a model M, an initial state s and a property p: • Consider a finite state machine M with initial state s, then check every reachable state for property p • Model composed of next states (transitions) • Properties written as temporal logic formulas • Exhaustively test each state

27. Property Specification • Properties often expressed as temporal logic formulas such as Linear Temporal Logic (LTL) • Given property p (in Boolean logic) • G : p is true henceforth • X : p is true in next state • F : p is true in this state or future state

28. Example • Specifications: • G p • X q • F r p p,r p,q r, q

29. Limitations of MC • Models are approximations of real world systems; abstraction of details allows for tractable models • State explosion problem • Incorrect models or specifications may produce incorrect results • Only checks specifications provided; no guarantee that specification covers all properties that should be satisfied

30. Policy Maintenance Framework

31. Modeling Policies • Framework for Property Verification • Constructed a tool to translate from RT policy to a symbolic model checking tool (SMV) • Introduces conservative number of principals • Necessary to construct counterexamples • Conservative  exponential • Translates queries to specifications • Safety, availability, role containment, SoD

32. Modeling Policies • Advantages: • Produces counterexamples when policy fails to satisfy property • Verifies multiple specifications in one run • May find counterexamples early… • Don’t want to wait if policy is flawed! • Correct policies will take full theoretical time complexity based on policy size

33. Optimizations • Chain Reduction • Logical equivalence between states where membership of roles is equivalent • Initial Policy Reduction • Logical equivalence between a set of states that are reachable from each other

34. Optimizations • Principal Count • Some policy instances may require fewer than the conservative number of new principals • Policy Partitioning • Divide-n-conquer approach to partition policies into sub-policies • Use properties of sub-policies to prove your goal property

35. Role Containment Heuristics • Heuristic – technique that trades soundness for performance • Soundness is important in security • Trade completeness for performance • Desire a heuristic that always provides a sound answer, but may not always provide a solution • Acceptable answers: yes, no, undetermined

36. Role Containment Heuristics Alice.friend includes Dave.friend? Alice.friend includes Ernie.friend? Fig. A Fig. B

37. Alice.friend includes Bob.friend?

38. Alice.friend include Frank.friend?

39. Role Containment Heuristics Alice.friend includes Frank.friend?

40. Visualization • Present delegation chains through an intuitive display • Better explains counterexamples • Perform analysis using graphical notation • Appropriate for experts and non-experts

41. Visualization Query Initial Policy Counterexample

42. Policy Correction • Possible changes • Change restriction sets • Add/remove policy statements • Type II  Type IV statement • Add conditions to statements • Changing policy may • Break other properties • Increase/reduce analysis time

43. Policy Correction • Principle of Locality • Principle of Bounded Trust • Principle of Minimum Trust • Principle of Trust Centric Modification • Principle of Minimum Modification

44. Future Work • Comparison of analysis techniques • Datalog • Language containment • Symbolic model checking • Case study of policy maintenance framework • Guidelines for correcting policy

45. Conclusion • Framework for verifying security properties • Produces counterexamples • Prorated cost of analysis • Verify multiple properties within one run • Heuristics • Visualization technique

46. Summary • Motivation • Background Concepts • Policy Maintenance Framework • Modeling and Heuristics • Visualization • Policy Correction • Future Work

47. References • Reith, Niu, Winsborough. “Apply Model Checking to Security Analysis in Trust Management” SECOBAP, 2007.

48. Backup Slides

49. Cyclic Dependencies • SMV does not like cyclic dependencies • But cyclic dependencies are permitted in RT • Solution: unroll the dependency • Translate role dependency graph into an equivalent unrolled graph • May increase size of model, but doesn’t add any more states to check

50. Cyclic Dependencies Type II