Modeling Dynamic Role- based Access Constraints using UML Khaled Alghathbar George Mason University, USA and King Saud University, Riyadh, Saudi Arabia

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.


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.


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


5

Objective

There is a need for unified representations of security

features.


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.


7

SecurityPolicies

Software Development Life cycle

Modeling SecurityPolicies Using UML

UML

Our Goal


8

SecurityPolicies

Software Development Life cycle

Access controlpolicies

Design Phase

Our Focus


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.


10

Our Proposal

Modeling Dynamic Role-based Access Constraints using UML.


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.


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.


13

Advantages over other works:

• Enforcing dynamic access control and flow control policies.

• Constraints are written on object constraints language (OCL).


14

Example

Purchasing

Clerk

Supervisor

Record invoice arrival

Verify invoice validity

Authorize payment

Purchasing Officer


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


16

The proposed extension

• Security Policy Constraints (SPC).

• History Log.

• Business Task.

• Conflict Sets.


17

Security Policy Constraints (SPC)

SecurityPolicyConstraintAssociation

Relationship

ClassOperationAttribute

BehavioralFeatureStrucuralFeature Classifier

GeneralizableElementFeature Constraint

ModelElement+constraintElement

*

+constraint*

*

*

ConstraintRelationship

*

*

GeneralConstraint

The Core of UML


18


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


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


19

History Log

Alice Record Invoice_01

History_Log

ActionUser Operation Object

. .

.

. .

.

. .

.

History Log: It keeps in record all authorization requests.


20

Business Task

• A reference of related operations.• An essentials element to enforce

Separation of Duty and workflow policies.

• Example: BT={Record, verify, authorize}


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}


22

The interactions between elements

SPC

Conflicting User

History_Log

BusinessTask

Object

Conflicting Role Conflicting Operation

constraint

User


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


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


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.


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.


27

Questions

Thank you

Documents

Modeling Dynamic Role- based Access Constraints using UML Khaled Alghathbar George Mason University, USA and King Saud University, Riyadh, Saudi Arabia