1 / 52

Apply Model Checking to Security Analysis in Trust Management

Apply Model Checking to Security Analysis in Trust Management. Mark Reith, Jianwei Niu, William Winsborough CS 7123 Research Seminar 17 Sept 07. Overview. Motivation Background Concepts RT Language Model Checking Policy Maintenance Framework Modeling and Heuristics Visualization

curt
Download Presentation

Apply Model Checking to Security Analysis in Trust Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related