Rigorous Analysis of UML Access Control Policy Models
Transcript of Rigorous Analysis of UML Access Control Policy Models
![Page 1: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/1.jpg)
Rigorous Analysis of UML Access Control Policy Models
Wuliang Sun, Robert France and Indrakshi Ray
Computer Science Department
Colorado State University
Fort Collins, Colorado
![Page 2: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/2.jpg)
Security Policies
Security policies Expressed by different languages XACML, OWL/RDF, CIM/SPL, PONDER, UML
Errors in policy models Can cause security breaches that have
serious consequences
Correcting the errors once policies are deployed can be expensive
Need error detection before policies are deployed
![Page 3: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/3.jpg)
Motivation
We use UML (Unified Modeling Language) for policy specification
UML together with OCL can be used to provide a formal and graphical representation of security policies
UML is the de facto specification language used in the software industry
UML policy models can be transformed to code using existing technologies
![Page 4: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/4.jpg)
Motivation
Using UML (Unified Modeling Language) as a policy specification language
Challenge: few mature tools supporting rigorous analysis of UML models
Solution: Transform UML to Alloy for automated model analysis
![Page 5: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/5.jpg)
Approach
Rigorous analysis of UML access control policy models
Front-end: use UML to describe security policies
Back-end: use Alloy Analyzer to analyze the modeled properties
Transformation between UML and Alloy: obviate the need for security designers to understand the Alloy language
![Page 6: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/6.jpg)
6
Approach Overview
![Page 7: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/7.jpg)
7
Background: SUDA
Scenario-based UML Design Analysis (SUDA)
A design class model with operation specifications is transformed to a static model of behavior, called a snapshot model.
A snapshot is an object configuration that represents a state of the system at a particular time.
A snapshot transition describes the behavior of an operation in terms of its before and after effect on the system state.
![Page 8: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/8.jpg)
8
Background: Snapshot Model
Example of a snapshot model generated from a class model
UML Class Model UML Snapshot Model
![Page 9: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/9.jpg)
9
Background: Snapshot Model
Example of a snapshot model generated from a class model
UML Class Model UML Snapshot Model
![Page 10: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/10.jpg)
10
Background: Snapshot Model
Example of a snapshot model generated from a class model
UML Class Model UML Snapshot Model
![Page 11: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/11.jpg)
11
Background: Snapshot Model
Example of a snapshot model generated from a class model
UML Class Model UML Snapshot Model
![Page 12: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/12.jpg)
12
Background: Snapshot Model
Example of a snapshot model generated from a class model
UML Class Model UML Snapshot Model
![Page 13: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/13.jpg)
13
Background: SUDA
SUDA vs. Our approach
SUDA: is the given scenario supported by the UML class model?
Our approach: is there a scenario supported by the UML class model that starts in a specified valid state and ends in a specified invalid state?
![Page 14: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/14.jpg)
14
Approach Overview
![Page 15: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/15.jpg)
15
Background: Dynamic Analysis using Alloy
AlloyModel = signatures + facts + predicates
(operation specifications)
Facts: define constraints on the elements of the model
Predicates: probe model
Trace mechanism: specify a fact to associate the transitions triggered by operation invocations with states defined by signatures
![Page 16: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/16.jpg)
16
Snapshot Model to Alloy Model Transformation
Step 1: Transform each class that is part of Snapshot class to a signature in Alloy
sig Role{}
sig User{}
![Page 17: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/17.jpg)
17
Snapshot Model to Alloy Model Transformation
Step 2: Transform the Snapshot class to a Snapshot signature containing fields that specify the object configurations within a snapshot
sig Snapshot{
// Object fields
roles: set Role, users: set User,
// Link fields
ASSIGN: User set->set Role,
} {
// Linked objects must exist in the snapshot
ASSIGN=ASSIGN:>roles&users<: ASSIGN
}
![Page 18: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/18.jpg)
18
Snapshot Model to Alloy Model Transformation
Step 2: Transform the Snapshot class to a Snapshot signature containing fields that specify the object configurations within a snapshot
sig Snapshot{
// Object fields
roles: set Role, users: set User,
// Link fields
ASSIGN: User set->set Role,
} {
// Linked objects must exist in the snapshot
ASSIGN=ASSIGN:>roles&users<: ASSIGN
}
![Page 19: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/19.jpg)
19
Snapshot Model to Alloy Model Transformation
Step 2: Transform the Snapshot class to a Snapshot signature containing fields that specify the object configurations within a snapshot
sig Snapshot{
// Object fields
roles: set Role, users: set User,
// Link fields
ASSIGN: User set->set Role,
} {
// Linked objects must exist in the snapshot
ASSIGN=ASSIGN:>roles&users<: ASSIGN
}
![Page 20: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/20.jpg)
20
Snapshot Model to Alloy Model Transformation
Step 3: Transform each Transition specialization to a predicate in Alloy
pred AssignRole[disj before, after: Snapshot,
rPre, rPost: Role, uPre, uPost: User] {
// Precondition
rPre in before.roles
uPre in before.users
rPre not in uPre.(before.ASSIGN)
// Postcondition
rPost in after.roles
uPost in after.users
uPost.(after.ASSIGN) = uPre.(before.ASSIGN) +
rPost
// Unchanged object configuration
…..
}
![Page 21: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/21.jpg)
21
Snapshot Model to Alloy Model Transformation
Step 3: Transform each Transition specialization to a predicate in Alloy
pred AssignRole[disj before, after: Snapshot,
rPre, rPost: Role, uPre, uPost: User]{
// Precondition
rPre not in uPre.(before.ASSIGN)
…
// Postcondition
uPost.(after.ASSIGN) = uPre.(before.ASSIGN) +
rPost
…
// Unchanged object configuration
after.roles – rPost = before.roles – rPre
…
}
Context AssignRole inv:
uPre.ASSIGN->excludes(rPre)
…
…
uPost.ASSIGN =
uPre.ASSIGN->including(rPost)
…
…
after.roles->excluding(rPost)=
before.roles->excluding(rPre)
…
![Page 22: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/22.jpg)
22
Snapshot Model to Alloy Model Transformation
Step 4: Define a trace fact to associate transitions between two consecutive snapshots with operations
fact traces{
all before: Snapshot - SnapshotSequence/last | let after =
SnapshotSequence/next[before] | Some r: Role | some u: User |
AssignRole[before, after, r, r, u, u]
}
![Page 23: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/23.jpg)
23
Approach Overview
![Page 24: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/24.jpg)
24
Alloy Instance to UML Object Model Transformation
Alloy Instance
A Sequence of UML Object Models
![Page 25: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/25.jpg)
25
Research Goal
Analysis: check whether a system can move from a valid to an invalid state as result of a sequence of access control operation calls
If analysis uncovers such a sequence, then the designer uses the trace information output by the analysis to help find the source of the errors in the UML policy model
![Page 26: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/26.jpg)
26
Demonstration Case Study: LRBAC
Location-aware Role-based Access Control (LRBAC) Model
![Page 27: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/27.jpg)
27
Demonstration Case Study: LRBAC
Location-aware Role-based Access Control (LRBAC) Model
![Page 28: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/28.jpg)
28
Demonstration Case Study: LRBAC
Location-aware Role-based Access Control (LRBAC) Model
![Page 29: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/29.jpg)
29
Demonstration Case Study: LRBAC
Location-aware Role-based Access Control (LRBAC) Model
![Page 30: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/30.jpg)
30
Demonstration Case Study: LRBAC
Operation specifications in form of pre/post-conditions for DeleteRoleAssignLocation
// English specification: remove a location from a set of locations
// in which a role can be assigned
Context Role::DeleteRoleAssignLocation(l:Location)
Precondition: location l has been associated with the role
Postcondition: location l has been removed from a set of locations
// OCL specification: remove a location from a set of locations
// in which a role can be assigned
Context Role::DeleteRoleAssignLocation(l:Location)
Pre: self.AssignLoc->includes(l)
Post: self.AssignLoc=self.AssignLoc@pre->excluding(l)
![Page 31: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/31.jpg)
31
Demonstration Case Study: Specifying the Property-to-Verify
Valid and Invalid LRBAC Snapshot Patterns
Is there a sequence of operation invocations that takes the system from a valid state consisting of at least one user in a location to an invalid state in which the user is linked to a role that does not include the user’s location?
![Page 32: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/32.jpg)
32
Demonstration Case Study: Generating the LRBAC Snapshot Model
![Page 33: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/33.jpg)
33
Demonstration Case Study: Generating an LRBAC Alloy Model
pred Role_DeleteRoleAssignLocation[disj before,after :Snapshot,
rPre, rPost:Role, lPre, lPost:Location] {
// Precondition
Pre in rPre.(before.AssignLoc) …
// Postcondition
rPost.(after.AssignLoc) = rPre.(before.AssignLoc) – lPost…
// Unchanged parts of object configuration
after.roles - rPost = before.roles – rPre …
}
Role_DeleteRoleAssignLocation predicate generated from the class invariant
![Page 34: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/34.jpg)
34
Demonstration Case Study: Analyzing the Alloy Model
pred valid2invalid{
// Specify that the first snapshot is valid
let first = SnapshotSequence/first | …
all u:first.users | u.(first.UserAssign) = none and
u.(first.UserLoc) != none …
// Query whether there exists a path from a valid
// state to an invalid state
some s: Snapshot - first | …
l not in r.(s.AssignLoc) and
r in u.(s.UserAssign) and l in u.(s.UserLoc)
}
The verification predicate generated from the property-to-verify
Valid Snapshot
Invalid Snapshot
![Page 35: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/35.jpg)
35
Demonstration Case Study: Analyzing the Alloy Model
First Snapshot: Valid
Second Snapshot: Valid
![Page 36: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/36.jpg)
36
Demonstration Case Study: Analyzing the Alloy Model
Third Snapshot: Valid
Fourth Snapshot: Invalid
![Page 37: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/37.jpg)
37
Demonstration Case Study: Analyzing the Alloy Model
Constraint modification: a role can be removed from a set of roles associated with a location only if the role is not assigned to any users
Context Role::DeleteRoleAssignLocation(l:Location)
Pre: self.AssignLocincludes(l)
and self.UserAssignisEmpty()
Post: self.AssignLoc = self.AssignLoc@pre excluding(l)
![Page 38: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/38.jpg)
Conclusion and Future Work
Contribution Propose a general framework for, but not limited
to, security policy analysis
Address a usability issue: a usable verification tool needs to be integrated with the UML-based development processes and notations used by software developers
Future work Investigating how safety and liveness access
control properties can be analyzed using model-checking techniques at the back-end in a usable manner
*Acknowledgment: the work was supported by the National Science Foundation grant CCF-1018711.
![Page 39: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/39.jpg)
39
Background: Snapshot Model
Example of a snapshot model generated from a class model
UML Class Model UML Snapshot Model
![Page 40: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/40.jpg)
40
Background: Snapshot Model
// English specification: assign a role to a user
Context User::AssignRole(r:Role)
Precondition: role r is not assigned to the user
Postcondition: role r is assigned to the user
Operation specification for AssignRole(r:Role) in the original design class model:
// OCL specification: assign a role to a user
Context User::AssignRole(r:Role)
Pre: self.ASSIGN->excludes(r)
Post: self.ASSIGN = self.ASSIGN@pre->including(r)
![Page 41: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/41.jpg)
41
Background: Snapshot Model
Context AssignRole inv:
// Generated from precondition of User::AssignRole(r:Role)
// role r is not assigned to the user
uPre.ASSIGN->excludes(rPre) and …
// Generated from postcondition of User::AssignRole(r:Role)
// role r is assigned to the user
uPost.ASSIGN = uPre.ASSIGN->including(rPost) and …
// Unchanged parts of object configuration
after.roles->excluding(rPost)=before.roles->excluding(rPre)
…
Example of the specialized class invariant in a snapshot model generated from the operation specification in a design class model:
![Page 42: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/42.jpg)
42
Background: Snapshot Model
Context AssignRole inv:
// Generated from precondition of User::AssignRole(r:Role)
// role r is not assigned to the user
uPre.ASSIGN->excludes(rPre) and …
// Generated from postcondition of User::AssignRole(r:Role)
// role r is assigned to the user
uPost.ASSIGN = uPre.ASSIGN->including(rPost) and …
// Unchanged parts of object configuration
after.roles->excluding(rPost)=before.roles->excluding(rPre)
…
Example of the specialized class invariant in a snapshot model generated from the operation specification in a design class model:
![Page 43: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/43.jpg)
43
Background: Snapshot Model
Context AssignRole inv:
// Generated from precondition of User::AssignRole(r:Role)
// role r is not assigned to the user
uPre.ASSIGN->excludes(rPre) and …
// Generated from postcondition of User::AssignRole(r:Role)
// role r is assigned to the user
uPost.ASSIGN = uPre.ASSIGN->including(rPost) and …
// Unchanged parts of object configuration
after.roles->excluding(rPost)=before.roles->excluding(rPre)
…
Example of the specialized class invariant in a snapshot model generated from the operation specification in a design class model:
![Page 44: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/44.jpg)
44
Snapshot Model to Alloy Model Transformation
Step 2: Transform the Snapshot class to a Snapshot signature containing fields that specify the object configurations within a snapshot
sig Snapshot{
// Object fields
roles: set Role, users: set User,
// Link fields
ASSIGN: User set->set Role,
} {
// Linked objects must exist in the snapshot
ASSIGN=ASSIGN:>roles&users<: ASSIGN
}
![Page 45: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/45.jpg)
45
Demonstration Case Study: Generating the LRBAC Snapshot Model
Context Role_DeleteRoleAssignLocation inv:
// Generated from precondition of DeleteRoleAssignLocation
rPre.AssignLoc->includes(lPre)
…
// Generated from postcondition of DeleteRoleAssignLocation
rPost.AssignLoc=rPre.AssingLoc->excluding(lPost) and
…
// Unchanged parts of object configuration
after.roles->excluding(rPost)
=before.roles->excluding(rPre) and
...
Invariant for Role_DeleteRoleAssignLocation class generated from the specification of DeleteRoleAssignLocation operation
![Page 46: Rigorous Analysis of UML Access Control Policy Models](https://reader031.fdocuments.in/reader031/viewer/2022021306/6207471349d709492c2fcc22/html5/thumbnails/46.jpg)
46
Alloy Instance to UML Object Model Transformation
Alloy
Instance in
XML
Class
Model in
XMI
Step 1
Step 2
Object
Models in
XMI +Step 3