When Role Models Have Flaws: Static Validation of Enterprise Security Policies Marco Pistoia T. J. Watson Research Center Hawthorne, New York [email protected]Stephen J. Fink IBM T. J. Watson Research Cen Hawthorne, New York [email protected]Robert J. Flynn Polytechnic University Brooklyn, New York [email protected]Eran Yahav IBM T. J. Watson Research Cen Hawthorne, New York [email protected]rnational Conference on Software Engineering – Minneapolis, MN, May
23
Embed
When Role Models Have Flaws: Static Validation of Enterprise Security Policies Marco Pistoia IBM T. J. Watson Research Center Hawthorne, New York [email protected].
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
International Conference on Software Engineering – Minneapolis, MN, May 2007
2
Role-Based Access Control Systems
• A role is a set of permissions that can be granted to users and/or groups of a computer system
• Each permission represents the right to perform a security-sensitive operation; it does not directly represent the right to access security-sensitive data or resources
• Examples of RBAC systems:– Java, Enterprise Edition (Java EE)– Microsoft .NET Common Language Runtime (CLR)
Permission to invokemethod setGradesPermission to invokemethod setGrades
Permission to invokemethod assignHomework
Permission to invokemethod assignHomework
Professor
User bob
User alice
3
Role Definition in Java EE
• Roles are application-specific
• They are defined in the deployment descriptors of an application’s components
• They can be used to restrict access to enterprise methods
• An RBAC policy P for a program p is sufficient if for any user u and for any execution e such that υ(u) ⇒ μ(me), e does not transition to an authorization error state; insufficient otherwise
• Insufficient policies can lead to stability problems
Roles Granted:Student
Role Required: Student
Role Required: Student or Assistantrun-as: Professor
Role Required: Professor Role Required: Professor
Component
Intercomponent call
Intracomponent call
InsufficientInsufficient
m0m0
m1m1 m2m2
m3m3 m4m4 m5m5
m6m6 m7m7
Role Required: Student Role Required: Student
InsufficientInsufficient
User: bob
13
Minimality
• An RBAC policy P sufficient for a program p is minimal if there exists no sufficient RBAC policy Q for p such that Q ≺ P
• Otherwise, P is redundant
• Redundant policies violate the Principle of Least Privilege
Roles Granted:Student, Assistant
Role Required: Student
Role Required: Student or Assistantrun-as: Professor
Component
Intercomponent call
Intracomponent call
RedundantRedundant
m0m0
m1m1 m2m2
m3m3 m4m4 m5m5
m6m6 m7m7
Role Required: Student
User: bob
14
Subversion
• An RBAC policy P is subversive if there exists any execution with P that transitions to an authorization error state under the base instrumentation, but not under the modified instrumentation
• Subversive policies violate the Principle of Least PrivilegeRoles Granted:Student
Role Required: Student
Role Required: Student or Assistantrun-as: Professor
Role Required: Professor
Component
Intercomponent call
Intracomponent call
SubversiveSubversive
m0m0
m1m1 m2m2
m3m3 m4m4 m5m5
m6m6 m7m7
Role Required: Student
User: bob
15
Analysis Domain
r1r1
r2,r3r2,r3
r4r4
r1,r5r1,r5
r1r1
r2,r3r2,r3
r4r4
r1,r5r1,r5
r1 r5
(r1 r5) (r2 r3)
r1 r5
r1 r5
r1 r5
r1 (r1 r5) (r2 r3) • μ : M → B(R) maps each
method to a disjunction of roles
• Our analysis computes conjunctions of disjunctions
• The analysis domain can be the set MCNF(R): role formulae in Monotone (no negation) Conjunctive Normal Form
– P abstractly sufficient ⇒ P sufficient– Potential false positives
Minimality Analysis• Iteratively remove one role from role assignments υ(u),
∀u∈U, and π(m), ∀m∈M, and verify whether the resulting RBAC policy is still abstractly sufficient
• Completeness Theorem– If an RBAC policy P is abstractly sufficient, and abstractly
sufficient policy Q : Q ≺ P, then P is redundant– Potential false negatives
Subversion Analysis• Repeat analysis disregarding distinction between inter-
and intra-component edges• Soundness Theorem:
– If P is abstractly sufficient, then it is not subversive– Potential false positives
18
Implementation
• ESPE is based on T. J. Watson Libraries for Analysis (WALA), specifically tailored to Java, EE applications
• WALA analyzes enterprise beans after deployment configuration, but before deployment– Less code Scalability– No analysis of container implementation Precision– No dependence on container vendor Portability
• WALA models several native methods• WALA models reflection by tracking objects to casts• http://wala.sourceforge.net
• All Java SE and Java EE libraries included in the analysis scope
• No false positives detected:– Java EE applications trigger the execution of libraries, but they themselves are shallow
– Calling patterns in Java EE programs that affect RBAC analysis are predominantly monomorphic
– Most enterprise beans map directly from the structure of an underlying relational database, and so do not utilize inheritance or linked structures
– Applications rarely store or manipulate EJB instances with complex heap data structures
– Although the underlying container utilizes complex libraries and data structures, the WALA analyzer truncates paths into the container, so container code does not pollute the application-level call graph
– Interactions with Java standard libraries are usually uninteresting for role analysis, since library methods are not restricted with roles
22
Conclusion
1. Defined theoretical foundation for RBAC consistency and policy validations
2. Introduced and implemented static analysis models
3. Static analyzer tailored to Java EE applications
4. Experimental results have shown zero false positives