Modeling Dynamic Role-based Access Constraints
using UML
Khaled AlghathbarGeorge Mason University, USA
andKing Saud University, Riyadh,
Saudi Arabia
Duminda WijesekeraCenter for Secure Information Systems
George Mason University, USA
© Khaled Alghathbar
2
How to achieve a good security?
Security requirements of a software product need to receive attention throughout its development life cycle.
© Khaled Alghathbar
3
Why?
• Because the security requirements specified at early stages of the life cycle affect later stages and are likely to feature in the eventual product.
• Defects, if undetected, can propagate downstream*.
• Reduce cost + prevent faults
* P. T. Devanbu and S. Stubblebine. Software engineering for security: A roadmap. In A. Finkelstein, editor, The Future of Software Engineering. ACM Press, 2000.
© Khaled Alghathbar
4
However!
• “Non functional requirements are generally more difficult to express in a measurable way, making them more difficult to analyze. In particular, NFRs tends to be properties of system as a whole.”*.
• lack of tools that model security
• software engineers lack security expertise
* B. Nuseibeh and S. Easterbrook. Requirements engineering: A roadmap. In A. Finkelstein, editor, The Future of Software Engineering. ACM Press, 2000
© Khaled Alghathbar
5
Objective
There is a need for unified representations of security
features.
© Khaled Alghathbar
6
How to represent security
• UML extension Advantages:
– Unified design of systems and security policies.
– Modularity, and Reuse in policy representation.
– Leverage of existing standards-based tools for design and analysis.
© Khaled Alghathbar
7
SecurityPolicies
Software Development Life cycle
Modeling SecurityPolicies Using UML
UML
Our Goal
© Khaled Alghathbar
8
SecurityPolicies
Software Development Life cycle
Access controlpolicies
Design Phase
Our Focus
© Khaled Alghathbar
9
Access control policies
• Discretionary Access Control (DAC).
• Mandatory Access Control (MAC).
• Role-based Access control (RBAC).
• Static policies: – Manager Sign check.
• Dynamic policies:– Supervisor shall not write and sign the same check.
© Khaled Alghathbar
10
Our Proposal
Modeling Dynamic Role-based Access Constraints using UML.
© Khaled Alghathbar
11
Related Work (1)1. Lodderstedt et al.* propose a methodology to model
access control policies and integrate them into a model-driven software development process.
It is the most related work, but our metamodel allows the specification of more authorization policies.
2. Brose et al. ** extend UML to support the automatic generation of access control policies in order to configure a CORBA-based infrastructure
However, It does not model dynamic access control policies.
*T. Lodderstedt, D. Basin, J. Doser. “SecureUML: A UML-Based Modeling Language for Model-Driven Security”. In the proceedings of the 5th International Conference on the Unified Modeling Language, Dresden, Germany.
** G. Brose, M. Koch, K.-P. Löhr. “Integrating Access Control Design into the Software Development Process”. In the Proc. of the sixth biennial world conference on the Integrated Design and Process Technology (IDPT), Pasadena, CA. June 2002.
© Khaled Alghathbar
12
Related Work (2)3. Fernandez-Medina et al.* propose an extension to the
Use Case and Class models of UML. Also, they introduce a language Object Security constraint Language (OSCL).
4. Jurjens’s ** extends UML to integrate standard concepts from formal methods regarding multi-level secure system and security protocols.
However, 3 and 4 focus on database and multilevel security.
* E. Fernadez-Medina, M.G. Piattini, M.A Serrano. “Specification of Security Constraints in UML”. In the 35th International Carnahan Conference on Security Technology (ICCST), London, UK, October 2001.
* E. Fernandez-Medina, A. Martinez, C. Medina, And M. Piattini. “Integrating Multilevel Security in the Database Design Process”. In the Proc. of the sixth biennial world conference on the Integrated Design and Process Technology (IDPT), Pasadena, CA. June 2002.
** J. Jurjens. “Towards development of secure systems using UMLsec”. In the Proceedings of Fundamental Approaches to Software Engineering, 4th Internacional Conference, LNCS, pages 187-200. Springer, 2001.
© Khaled Alghathbar
13
Advantages over other works:
• Enforcing dynamic access control and flow control policies.
• Constraints are written on object constraints language (OCL).
© Khaled Alghathbar
14
Example
Purchasing
Clerk
Supervisor
Record invoice arrival
Verify invoice validity
Authorize payment
Purchasing Officer
© Khaled Alghathbar
15
Examples of access and flow control policies
Purchasing
Clerk
Supervisor
Record invoice arrival
Verify invoice validity
Authorize payment
Purchasing Officer
• Required Sequence of operations.
• Role Restriction.
• Dynamic Separation of Duty.
• Avoiding Conflicts.
Recordinvoice arrival
Authorizepayment
Clerk
Verifyinvoicesvalidity
Purchasing Officer supervisor
© Khaled Alghathbar
16
The proposed extension
• Security Policy Constraints (SPC).
• History Log.
• Business Task.
• Conflict Sets.
© Khaled Alghathbar
17
Security Policy Constraints (SPC)
SecurityPolicyConstraintAssociation
Relationship
ClassOperationAttribute
BehavioralFeatureStrucuralFeature Classifier
GeneralizableElementFeature Constraint
ModelElement+constraintElement
*
+constraint*
*
*
ConstraintRelationship
*
*
GeneralConstraint
The Core of UML
© Khaled Alghathbar
18
Security Policy Constraints (SPC)
History-based Separation of Dutyfrom paper 15 Simon
Operation Policy Constraint(s)
Authorize_payment Operation Sequence(Workflow)
Histroty_Log -> select (Action=(BusinessTask->select(Task="Purchasing”).Operation-> Prior(Operation=CurrentOperation)) AND Object=CurrentObject)->notEmpty
Security Policy Constraints (SPC)
Authorize_payment Role Restriction (User->select(user=CurrentUser)).role-> intersection (CurrentOperation.Allowedroles)-> size>0 AND (User->select(user=CurrentUser)).role-> intersection (CuurentOperation.Deniedroles)-> size=0
Authorize_paymentAvoiding
Conflicting User
((ConflictingUsers->select(UserName=CurrentUser))-> collect(users)->asSet())-> intersection((History_Log-> select ( Action= (BusinessTask->select(Task="Purchasing”).Operation-> Prior(Operation=CurrentOperation))AND Object= CurrentObject))-> collect(ActionUser))-> isEmpty
Example of SPC constraint
© Khaled Alghathbar
19
History Log
Alice Record Invoice_01
History_Log
ActionUser Operation Object
. .
.
. .
.
. .
.
History Log: It keeps in record all authorization requests.
© Khaled Alghathbar
20
Business Task
• A reference of related operations.• An essentials element to enforce
Separation of Duty and workflow policies.
• Example: BT={Record, verify, authorize}
© Khaled Alghathbar
21
Conflict Sets
• A reference of conflicting:• Users.• Roles.• Operations.
• It is essential to avoid conflict.
• An example conflicting roles: {Purchasing Manager, Account Payable
Manager } • An example conflicting operations: {writing checks, signing checks}
© Khaled Alghathbar
22
The interactions between elements
SPC
Conflicting User
History_Log
BusinessTask
Object
Conflicting Role Conflicting Operation
constraint
User
© Khaled Alghathbar
23
An Example of a Constraint in the SPC
• Required sequence of operations (Workflow policies)
Purchasing Officer SPC Histrory_LogUserRoles Invoice
Authorize Payment Request
Get User's Roles
Get Invoice's AllowedRoles and DeniedRoles
User's Roles
Invoice's AllowedRoles and DeniedRoles
Get Previous Operation's Record
Result
Perform Authorize Payment Operation
Deny Request {OR}
ConflictingUsers
Get User's Conflict
User's Conflict
Business_Task
Get the Prevoius Operation in the Task
Previous Operation in the Task
© Khaled Alghathbar
24
OCL Representation of the Required Sequence of Operations
constraints
Context Invoice::Authorize_Payment():Void
Pre: Historty_Log-> select(Action=(Business_Task select(Task="Purchasing”).Operation Prior (Operation=CurrentOperation)) AND Object=CurrentObject) notEmpty
© Khaled Alghathbar
25
RBAC Metamodel
MaxAllowedRolesMinAllowedRoles
User
MaxAllowedUsersMinAllowedUsers
Role Operation UserActionObject
History Log
OperationPolicyConstraint
Secuirty Policy Constraints
Constraint
* *
User Assignment*
*
AllowedRoles
**
DeniedRoles
1*
Inheritance
1 *
Logged Actions
*
1Constrainted
*
*Conflicting Roles Set
1
*
Constrainted
1
*
Constrtainted
*
*Conflicting User Set
**Conflicting Operation Set
Business Task
0..1*{ordered}consist of
*
*
GeneralConstraints
**related toRBAC Policies:•Dynamic separation of duty (DSOD)•Static separation of duty (SSOD)•Flow control and workflow: •Conflicts of User, Role and Operation: •Cardinality in Roles and User elements.
© Khaled Alghathbar
26
Conclusion• We proposed a Metamodel that allow designers
to:– Model access control policies (static and dynamic)– Model flow control policies.
Future Work• Integrating security policies on other phases of
the software lifecycle.• Providing a unified representations of security
policies.
© Khaled Alghathbar
27
Questions
Thank you
Top Related