520 likes | 664 Views
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
E N D
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 • Policy Correction • Future Work
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
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
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
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
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)
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
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)
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
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
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
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
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
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
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
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
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
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?
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
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!
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}
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?
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
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
Example • Specifications: • G p • X q • F r p p,r p,q r, q
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
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
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
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
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
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
Role Containment Heuristics Alice.friend includes Dave.friend? Alice.friend includes Ernie.friend? Fig. A Fig. B
Role Containment Heuristics Alice.friend includes Frank.friend?
Visualization • Present delegation chains through an intuitive display • Better explains counterexamples • Perform analysis using graphical notation • Appropriate for experts and non-experts
Visualization Query Initial Policy Counterexample
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
Policy Correction • Principle of Locality • Principle of Bounded Trust • Principle of Minimum Trust • Principle of Trust Centric Modification • Principle of Minimum Modification
Future Work • Comparison of analysis techniques • Datalog • Language containment • Symbolic model checking • Case study of policy maintenance framework • Guidelines for correcting policy
Conclusion • Framework for verifying security properties • Produces counterexamples • Prorated cost of analysis • Verify multiple properties within one run • Heuristics • Visualization technique
Summary • Motivation • Background Concepts • Policy Maintenance Framework • Modeling and Heuristics • Visualization • Policy Correction • Future Work
References • Reith, Niu, Winsborough. “Apply Model Checking to Security Analysis in Trust Management” SECOBAP, 2007.
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
Cyclic Dependencies Type II