policy based design of secure distributed collaboration systems tanvir ahmed department of computer...

Policy Based Design of Secure Distributed Collaboration Systems

Tanvir Ahmed

Department of Computer Science University of Minnesota, Twin Cities

2University of Minnesota, Twin CitiesTanvir Ahmed

Outline

1. Research goal and contributions.

2. Specification model for security and coordination requirements in distributed collaboration systems.

3. Verification methodology using model checking.

4. Design of a policy-driven middleware.

5. Experimentations, evaluations, & conclusions.


Research GoalDerive the runtime system for secure distributed CSCW (Computer Supported Cooperative Work) systems from their high level specifications of coordination and security requirements.

Coordination and Security Policies Policy

Driven Middleware

Coordination and Security Policies

CollaborationEnvironment

CollaborationEnvironment

Shared Application and Resources


CSCW SystemsWorkflow

• Asynchronous interactions

• Structured coordination• Execute enterprise-wide processes

• Office systems, Health-care systems

Groupware

• Real-time synchronous interactions

• Group-aware• Whiteboard systems, Conferencing tools

• Ad-hoc coordination

Attributes of emerging collaboration systems, e.g. Internet-wide virtual organizations.

• Span across multiple organizations and security domains.• Decentralized management of collaboration activities.• Formed by ad-hoc integration of users and shared resources.


Distributed Collaboration

Enterprise A

Enterprise C

Enterprise B

Enterprise D

Activities

Coordination /synchronization

SecurityRequirements


Steps in Building a Collaboration

Derivation of Policy Templates• Access control & administrative policies

Middleware• Generic managers enforcing the policies

Execution Environment

Collaboration Specification

Design Tool

Analysis and Verification•Model checking


Research Contributions1. A role-based specification model for CSCW systems.

• Security and coordination requirements.

2. A verification methodology using finite-state based model checking.

• Model-checker SPIN.

3. A design of policy-driven middleware for secure distributed collaboration.

• A proof-of-concept implementation.

• Build several experimental collaborations with various policies.


Examination Activity

A Role-Based Model for CSCW

ExamPaper

Examiner

Grader

Student

GradeSheet

AnswerBook

users roles objects


(1) A Role-Based Collaboration Specification Model


Research Problems in Policy Specification

• In CSCW, security policies are context-based.

– Context can be coordination state of the cooperating users.

• In distributed CSCW, no single organization, site, or user may be trusted with management of all aspects.

– Some of the users and organization may be trusted to mange specific policy aspects.

• Require a decentralized administration model for managing policies.

– Ownership of an object may need to change and objects may move from one domain to another.


Coordination Requirements• Participants in different roles (inter-role)

• Participants in the same role (intra-role)

– Independent participation• Members work independently

– Cooperative participation• Members coordinate:

– “Nurse-on-duty”

• Joint participation:

– Three bankers open a bank vault jointly.

• Hierarchical structuring of activities


Security Requirements• Role admission constraints.• Dynamic and context-based access control policies

– Requires a unified model for coordination and security

• Separation of duties (SOD)– Role based SOD, Object-based SOD, Operational

SOD, …• Confidentiality• Decentralized administration

– Role membership management.– Administrative trust for policy enforcement.


Collaboration Model (1/2)

Activity

• Defines how a group of users cooperates toward some common objectives by conducting their individual operations on a set of shared objects.

– An abstraction of a collaboration session.

– A large-scale collaboration may involve many activities, which may be nested hierarchically.

– A scope for objects, roles, operations, & events.

Activity Template

• Defines a reusable pattern for collaboration.

– An activity template is a collaboration specification.

• An XML schema defines the syntax of our specification model.


Collaboration Model (2/2) Role

• Defines a set of operations.

– Contains role constraints• Relations with other roles to control who can be a member.

Operation• Defines a participant’s privileges to perform actions on shared

objects or resources.

– Role operations must satisfy precondition.

Events• Execution of an operation generates events.

– Events are used to specify security and coordination policies.


Example: Course Activity Template

ExamPaper

ActivityTemplate ExamSession

ExamPaper

Role Checker Role Candidate

Role Assistant

Role ExamineeRole ExaminerRole Grader

AnswerBook

WhiteBoard

Role Instructor Role Student

ActivityTemplate Examination

ActivityTemplate Course

Dynamic role assignment

Role reflection

Object parameters

Activity Creation Role members and objects can be assigned during creation of nested activities.

Joining role


Example: Task-Flow Requirements

SetPaper

ExamSessionStartExam

ExamSession

#member(Examinee)

begin endRole Examiner

Role Examinee

LEGEND Activity Task-flow dependency

StartExam

Examination

Role Examinee


Activity Template Specification1. Role Specifications

– Role Admission Constraints

– Role Validation Constraints

– Role Activation Constraints

– Role Operations1. Precondition: specify coordination and synchronization policies.

2. Action:

• Grant permission

• Create Activity / Object

• Invoke method

• Generate Application Defined Event

2. Nested Activity Templates


Role Membership FunctionsPseudo-variables: thisUser

Membership functions:

Boolean function member( thisUser, RoleName ) E.g. member ( thisUser, Instructor )

List of current members in a role is given by:

members( RoleName )

Number of members in a list:

# members( RoleName )


Event Model1. System defined events:

– Generated implicitly by the system during execution of an operation or activity: opId & activityId

– Each event has two types: start & finish

• E.g., opId.start, opId.finish(Based on the model by Roberts & Verjus, IFIP 1977)

2. Application-defined events:

– Defend as part of the specification: appDefinedEventId

– Can import objects’ states as attribute values.

• All the events have two default attributes: invoker & time

• Event history is composed of all the generated events.


Event-based Predicates• Lists all the event of a specific type: (EventName)• Filtering an event list based on its attributes

– (EventName(invoker=thisUser))• Number of times the event has occurred #(EventName)• An index in the event list: EventName(index)• The last event of a specific type: EventName(last)

Event based Predicates: 1. #(EventName(invoker=thisUser)) = 0

– True if the event is not previously generated by the user who is currently executing.

2. EventName(last).invoker=thisUser– True if the last event is generated by the same user who is

currently executing.


Role Admission Constraints

• Conditions that must be satisfied when a user is admitted to a role.

ROLE Assistant

ADMISSION_CONSTRAINTS

#members(Assistant) < 1

& member(thisUser, Staff)

& !member(thisUser, Student)

1. Role cardinality (maximum)

2. Previous role membership

3. Static separation of duties


Role Validation Constraints• A user’s membership must be revoked when certain

conditions are not valid.

ROLE Accountant

VALIDATION_CONSTRAINTS !member(Manager)

- A member of the Manager role cannot join the Accountant role.

- After joining, if an accountant becomes a manager, his/her membership to Accountant role is revoked.


Precondition

• Condition that must be satisfied when an operation is executed.

OPERATION ApproveInvoice { PRECONDITION

#(PrepareInvoice.finish(invoker=thisUser)) = 0

ACTION /* Approve the invoice */

• Preconditions allow to specify– Object based separation of duties– Operational separation of duties– Condition & context-based based access control


Role Activation Constraints• Condition that must be satisfied for execution of any

operation.– E.g., Minimum role cardinality

ROLE CodeReviewer ACTIVATION_CONSTRAINTS

#member(thisRole)>=3& #(members(thisRole) ∩ members(Developer)) > 0& #(members(thisRole) ∩ members(ProjectManager)) > 0

To perform any operation in the CodeReviewer role:- A minimum of 3 members must be present in this role, and- It must have at least one member from each of the Developer and ProjectManager roles.


Meta Policy Specification• Meta Roles

– Creator role: the user initiating an activity instance or creating an object.

– Owner role is trusted to manage an activity, role, or object.• Membership rules for Owner roles:

(1) Template can specify a role as the owner of an activity, role, and object.

(2) Default rules for ownerships:– An activity, the owner of the parent activity is the owner. – A role, the activity owner is the default owner.– An object, the role that creates it is the owner.

• For the top activity, Creator is the Owner.

(3) “ChangeOwner” can change the owner of an object.


ExamSession Activity• An instance of this activity is created by a student in

the Examinee role.

ActivityTemplate ExamSession ExamPaper

AnswerBookRole Checker Role Candidate


Example: ExamSession Specification(1/2)

ACTIVITY_TEMPLATE ExamSession (OWNER Grader, OBJECTS (ExamPaper exam), ASSIGNED_ROLES Candidate)

{ TERMINATION_CONDITION # (Checker.Grade.finish) > 0 ROLE Checker {

ADMISSION_CONSTRAINTS #members(thisRole) < 2

& member(thisUser, parentActivity.Grader)OPERATION Grade { PRECONDITION # (Candidate.Submit.finish) = 1

ACTION GRANT ans.setGrade(data) }OPERATION ApproveGrade { PRECONDITION # (Grade.finish) > 0

& #(Grade.finish(invoker=thisUser) ) = 0 ACTION GRANT ans.approveGrade() }

} ROLE Candidate { …


Example: ExamSession Specification (2/2)

ROLE Candidate { ADMISSION_CONSTRAINTS

member(thisUser, Examinee) & member(thisUser, thisActivity.Creator) & #members(thisRole) < 1

ACTIVATION_CONSTRAINTS time > DATE(Mar, 22, 2002, 8:00)

& time < DATE(Mar, 22, 2002, 11:00) OPERATION StartExam {

PRECONDITION #(StartExam.start) = 0 ACTION {ans = new OBJECT(AnswerBook);

GRANT exam.readPaper( ) }OPERATION Write { …. }OPERATION Submit { PRECONDITION #(Write.finish) > 0

ACTION CHANGE_OWNER (ans, Checker) } }


Editor


Related Role Based Models• NIST`2000 RBAC (Role-Based Access Control) models

– Do not support role context.

• Context-based role models

– Domain (Lupu & Sloman `97), Team (Thomas `97)

• Verification of role constraints using logical expression

– Huang & Atluri `99; Bertino, Ferrari, & Atluri `97;

• Role based model for decentralized management

– ARBAC`02 (Oh & Sandhu `2002); Bacon, Moody, & Yao `2002;

• In contrast

• Roles are defined in the context of an activity.

• Roles has conditions associated with privileges.

• Integrated specification of administrative policies.


(2) Verification methodology using model checking


Static Verification

• Correctness and consistency of a specification:

1. Reachability of Operations

2. Task Flow

3. Role Based Constraints• Global properties related to security requirements:

4. Confidentiality and Information Flow

5. Integrity and Access Leakage• Safety property: no rights can be leaked to unauthorized users.


Correctness of Global Properties

1. Reachability of Operations: Example,OPERATION Op1 PRECONDITION #(Op2.finish) = 1 OPERATION Op2 PRECONDITION #(Op1.finish) = 1

2. Task Flow– Requirements are expressed in path expression constructs:

(Campbell and Habermann, 1974)• sequence(;), selection( () ) with a count (:n) restrictor • Example, Examination := Examiner.SetPaper;

Examinee.ExamSession:#member(Examinee)

3. Role Based Constraints– Example of inconsistent constraint:

ROLE B VALIDATION CONSTRAINTS ! member(A) ROLE C ADMISSION CONSTRAINTS member(A) & member(B)


Global Security Requirements

4. Confidentiality and Information Flow– RBAC is “policy neutral”: Information flow constraints can be

modeled by classifying roles.

– Condition based constraints

• “A participant of the examinee role cannot access the content of the exam paper before start of his/her own exam session”.

5. Integrity and Access Leakage– Express integrity policies to check unintentional leakage of access

rights.

• “A participant of the examinee role can only modify his/her answer book before end of his/her exam-session”.


Finite-State Based Model Checking

• Static verification using finite state based model checking using SPIN (Holzmann `97).

• Our collaboration specification in XML is manually converted to PROMELA verification language.– Additional components are added to verify properties

related to information flow and owner assignment.- The desired system property can be expressed in LTL using

temporal operators: always( ), eventually( ), and until(U).

• In SPIN, given a model of a system and a desired property of the system, – Provides a trace of a counter-example.


Challenges in Model CheckingProblem I: Search space explosion • Solution: Aspect specific verification

– Ignore properties, which are not in concern when verifying a specific property.

Problem II: Inter-dependent aspects of the verification requirements.• Solution: Verification methodology follows a precedence among the

properties it checks.I. Task ModelII. Role ModelIII. Information Flow ModelIV. Owner Assignment Model

Problem III: Need a bound on the number of participants for verification.• Solution: Estimate a number, lower bound, of participants per role

whose unique identities are to be modeled to verify a given set of requirements for a specification.


Verification Model for Confidentiality

• Rules for explicit information flow - (Denning

`82)

– Given objects o1, o2 and subject s, which has read permission on o1 at time t1 and write permission on o2 at time t2 with t2 >= t1, then information can flow from o1 to o2, I.e., o1 o2.

– Similarly, given o is an object and subject s1 has write permission on o at time t1 and subject s2 has read permission on o at time t2 with t2 >= t1, then information flow from s1 to s2, i.e., s1 s2.

O1 S O2read @t1 write@t2t2 >= t1

OS1write @t1 read @t2

t2 >= t1S2


Verification Model for Confidentiality

• Components for explicit information flow through storage channels are added.

• Verification of the requirement:“A participant of the examinee role cannot access the content of the exam paper before start of his/her own exam session”

• User A and B are initial member of Student role

• Specified by negating the fact that eventually user A knows the content of the ExamPaper without starting his/her ExamSession.

! (knowledge (A, ExamPaper) && ! Event(ExamSession_start, A) )


Example Verification in Course ActivityInitial user assignment: Student (A, B), Assistant (C,D), Instructor (E)

ExamPaper

Assistant (C,D)

Examinee(A,B)Examiner(E)Grader(C, D)

B’s ExamSession ExamPaper

Checker(C, D) Candidate(B)

AnswerBook

WhiteBoard

Instructor(E) Student (A,B)

Activity Examination

Activity Course

(1) Examiner leaks - Add fact !write(Examiner, ExamPaper, BulletinBoard)

(1)r

w

r

(2) Checker leaks – Add !write(Grader , ExamPaper, BulletinBoard)

(2)

w

wr r

r

(3) Examinee B leaks to A

(3)w

r


Verification with Owner Assignment

• Administrative Trust: an owner of an entity is trusted to enforce the entity specific policies.

1. Trusted Owner Model:• Owner of a role can view identities of the role participants.• Owner of an object can read/modify the object without

restriction.

2. Untrusted Owner Model:– Untrusted users in administrative roles may actively try to violate

sensitive security requirements.• By not enforcing role admission policies.• By manipulating causal dependency of the collaboration

policies under their control.


Verification with Untrusted Owner

• Problem 1: Identify roles that cannot be trusted to enforce policies related to specific entity of a specification.– Designer can verify a collaboration with different trust assignments.

• Problem 3: Identify the entities that can be owned by untrusted users: – Potentially misbehaving entities.

• Problem 4: Identify the entities, among these potentially misbehaving entities, that violate a specific requirement.– Consequently misbehaving entities.– If a sensitive requirement is violated, change the owners of the

consequently misbehaving entities.


Related Work• Formal methods are used to statically verify various types of

confidentiality properties.– Model oriented

• CSP (Communicating Sequential Process) (Schneider `96)– Property oriented

• Type systems (Denning & Denning `77, Millen `81)– Assumes verified program will run under trusted subjects.

• In decentralized administration, programs are type-checked based on:

• Assigned “trust” (Orbaek & Palsberg `97)• Labeling data (Myers & Liskov `2000)

– Execution environment is assumed to be entirely trusted.• Finite-state based model checking, SPIN, is used for

• Workflow process (Janssen et al. `98, Eshuis & Wieringa `2002)• Program analysis (Corbett et. Al., `2000)• Protocol verification (Maggi & Sisto `2002)


(3) A Policy-Based Middleware for Distributed Collaboration


Research Problems in Policy-Driven Middleware

• Development of a distributed execution model for collaboration systems.

• Derivation and distribution of policy modules related to management of -- objects, roles, and activities.

– Policies depend on the runtime events generated by users’ actions.

• Selection of administrators and hosts for proper enforcement of policies.


Recap: Steps in Building a Collaboration

Derivation of Policy Templates• Access control & administrative policies

Middleware• Generic managers enforcing the policies

Execution Environment

Collaboration Specification

Design Tool

Analysis and Verification•Model checking


Access Control Policy (ACP) Template

.OBJECT(ExamPaper, $z)

….

OBJECT = ACTIVITY(Course, $x). ACTIVITY(Examination, $y)

OWNER = $x.Instructor

ENTRY {SUBJECT = $y.Examiner

PERMISSION = setPaper

CONDITION = ( #( $y.Examiner.SetPaper.start) = 0 ) }

ENTRY {


Middleware Components and Services

Role Definition

GenericRole

Manager

PolicyModule

Activity Definition

GenericActivity Manager

PolicyModule

Object Definition

GenericObject

Manager

PolicyModule

Middleware Components

Collaboration Specification with Application Level Objects

Middleware Services

Name Service Public Key Service Event Service


User Interaction Model

UserCoordination

Interface(UCI) Role

Manager

ObjectManager

• User Authentication by role manager• Role membership certificates• Invocation of role operations by user

• Authentication of role manager by the object manager• Invocation of object operations on behalf of the user• Precondition check for dynamic access control

ObjectObjectInterface


Runtime Execution View

Convener

System

Activity Activity Template Role Role Stub

Course

Convener’s Protection Domain

User A’s Coordination Interface (UCI) User B’s Coordination Interface (UCI)

Object Type

Convener

Student Instructor Assistant Examination

Course.chemistry

Examiner

Examinee Grader ExamSession

ExamPaper

Examination.midterm

Examiner GraderInstructor

Instructor’s Protection Domain

Object

exam

Managers


Middleware Problems Addressed

• Secure distribution of policy modules.

• Construction of runtime managers.• Secure interactions among managers. (R. Kumar `2002)• Distributed role certification management.

• Secure event service

– Event are sent to valid subscribers and received from valid notifiers.

• Secure session management


Middleware: Related Work

• Other policy based approaches:

– COCA (Li & Muntz `98)

– DCWPL(Corts & Mishra `96)

• Cross organizational business process orchestration:

– WfMC (Workflow Management Coalition `96)

• Our Approach:

– Separation of security and coordination concerns from the design of collaboration objects.

• Our experience shows that some aspects of security are tightly coupled with coordination


(4) Experimentations & Evaluations


CSCW Applications

• Experiment with different collaborative systems and different security and coordination policies.

1. Collaborative Document Authoring

2. Collaborative Classroom

3. Interactive Whiteboard Sharing

4. Online Meeting (Audio only)

5. Collaborative Notes Taking

Note: Four under-graduate students and two graduate students have experimented with CSCW environments.


Evaluations• Activity templates with different coordination and security policies

for Whiteboard Sharing and Audio-based Conference. • Experimented with 5 policies:

– Moderator control• Attendee requests, Moderator grants, Attendee releases

– Grant access based on the order of the request.• Moderator Select:

– Moderator selects among the requesting participants• Moderator Revoke:

– Moderator can revoke and select the next participant

– Voting• All attendee votes to select the next participant

– Secure private sharing:• Attendees can creates secure private channels.


User Coordination Interface (UCI)


Expressiveness of Security Policies• Types of policies that can be expressed:

– Task based security policies– Separation of Duties (SOD): role-based, operational, object-based– Role admission constraints– Administrative RBAC– Confidentiality

• Types of policies that have limited support:– Identity-based Separation of Duties– Privacy– Chinese Wall Security policy– Delegation– Security policies based non application defined context.

• Types of policies that are not supported:– Obligation– Usage control


Conclusions

• Contributions of this thesis:

– A role based specification model for CSCW Systems for security and coordination policies.

• A role model for administrative security policies.

– A methodology for verification of security requirements in CSCW systems.

• Aspect specific verification models.

• Verification in the presence of untrusted users.

– A design of a policy driven middleware to manage the runtime execution environment.

• Policy module creation and distribution, distributed role management, event security.


Future Directions

• Specification and verification of security requirements in

– Clinical information systems.

– Adversarial collaboration (Cohen et. al. `2000)

• Security requirements and verification of policies in pervasive and ubiquitous computing environments.

• Construction of virtual organizations spanning different independent enterprises.

• Verification of confidential properties, such as noninterference, noninference, non-deducible etc. in collaborative settings.


Publications1. "Static Verification of Security Requirements in Role Based

CSCW Systems", Tanvir Ahmed and Anand Tripathi. In 8th ACM Symposium on Access Control Models and Technologies (ACM SACMAT 2003).

2. "Specification of Secure Distributed Collaboration Systems", Anand Tripathi, Tanvir Ahmed, and Richa Kumar. In IEEE International Symposium on Autonomous Distributed Systems (IEEE ISADS 2003).

3. "Design of a Policy-Driven Middleware for Secure Distributed Collaboration", Anand Tripathi, Tanvir Ahmed, Richa Kumar, and Shremattie Jaman. In 22nd IEEE International Conference on Distributed Computing Systems (IEEE ICDCS 2002).

4. "A Coordination Model for Secure Distributed Collaboration", Anand Tripathi, Tanvir Ahmed, Richa Kumar, and Shremattie Jaman. Process Coordination and Ubiquitous Computing, CRC Press, 2003.


Publications5. "Distributed Collaborations using Network Mobile Agents",

Anand Tripathi, Tanvir Ahmed, Vineet Kakani, and Shremattie Jaman. In 2nd

International Symposium on Agent Systems and Applications/ 4th International Symposium on Mobile Agents (ASA/MA'2000)

6. "Context-Based Secure Resource Access in Pervasive Computing Environments", Anand Tripathi, Tanvir Ahmed, Devdatta Kulkarni, Richa Kumar, and Komal Kashiramka. In 1st IEEE International Workshop on Pervasive Computing and Communications Security (IEEE PerSec'04).

Journal Publications Under Review/ Technical Reports• "Security Policies in Distributed CSCW and Workflow Systems", Tanvir

Ahmed and Anand Tripathi. Proceedings of IEEE.• "Verification of Security Policies in Distributed Management of

Collaboration Systems", Tanvir Ahmed and Anand Tripathi. ACM TISSEC.( www.cs.umn.edu/~tahmed/pub.htm )


Publications in Network Monitoring1. "Active Monitoring of Network Systems Using Mobile

Agents", A. Tripathi, T. Ahmed, S. Pathak, A. Pathak , M. Carney, M. Koka, P. Dokas. In Joint Internationl Conference on Wireless LANs and Home Networks (ICWLHN 2002) and Networking (ICN 2002)

2. "Paradigms for Mobile Agent-Based Active Monitoring", A. Tripathi, T. Ahmed, S. Pathak, M. Carney, P. Dokas. IEEE Network Operation and Management Symposium (NOMS 2002), 65-78, 2002.

3. "Multi-Agent Coordination in a Network Monitoring System", A. Tripathi, M. Koka, S. Karanth, A. Pathak, and T. Ahmed. Software Engineering for Large-Scale Multi-Agent Systems, 2002, LNCS.

4. "Robustness and Security in a Mobile-Agent based Network Monitoring System", Anand Tripathi, Muralidhar Koka, Sandeep Karanth, Ivan Osipkov, Harsha Talkad, Tanvir Ahmed, David Johnson, and Scott Dier. International Conference on Autonomic Computing, 2004.


Publications in Mobile Agents

1. "Experiences and Future Challenges in Mobile Agent Programming", Anand R. Tripathi, Tanvir Ahmed, Neeran M. Karnik, Microprocessors and Microsystems. 25, 2 (October 2001), 121 – 129 (Journal).

2. "Design of the Ajanta System for Mobile Agent Programming", Anand R. Tripathi, Neeran M. Karnik, Tanvir Ahmed, Ram D. Singh, Arvind Prakash, Vineet Kakani, Mukta Pathak, Journal of Systems and Software. 62, 2 (May 2002), 123-140 (Journal).

3. "Mobile Agent Programming in Ajanta", Anand Tripathi, Neeran Karnik, Manish Vora, Tanvir Ahmed, and Ram Singh. In Proceedings of the 19th IEEE International Conference on Distributed Computing Systems (IEEE ICDCS 99)


The End.


Existing Results in Verifying Safety Property

• The safety property of HRU (Harrison, Ruzzo, Ullman, 76) access matrix model is not decidable.

– Access control models have placed constraints on the access control structures to facilitate analysis of safety properties.

• E.g., Typed Access Matrix (Sandhu, 92)

– Other cases, users with administrative rights (e.g., create-subject) are trusted for not violating security properties.

• Safety of take-grant model is decidable in linear time in size of the initial graph.

– Take-grant model abstracts only information needed to answer questions related to safety.


Lesson Learned

• Specification:– Participants may coordinate on attributes of application level

objects.– Application defined events

– Objects may be shared after an activity is in progress: – Object container

– Automated invocation of operation facilitates interaction.– Reaction (Pervasive Environments)

– During the lifecycle of an object, we are able to assign an owner that can be trusted to enforce policies.

– Fine grain trust are assigned during verification.

• Middleware:– XML Schema facilitates introduction of new policy constructs.– XML based runtime data structure causes performance

degradation: optimization techniques are required.


Verification Methodology

• Solutions: Modify the specification.1. Student role’s privileges on BulletinBoard are revoked

during Examination activity.

2. Add a new role BulletinBoard-User in the Examination template and specify a “separation of duties” that an examinee has to leave this role during exam-session.• Define ExamStartTime and ExamJoinDuration to ensure a time

window when an examinee cannot submit the AnswerBook and cannot start an exam-session.

(Tanvir Ahmed and Anand Tripathi, ACM SACMAT 2003)


Global Security Requirements

4. Confidentiality and Information Flow– RBAC is “policy neutral”: Information flow constraints can be

modeled by classifying roles.

– Condition based constraints

• “A participant of the examinee role cannot access the content of the exam paper before start of his/her own exam session”.

5. Integrity and Access Leakage– Express integrity policies to check unintentional leakage of access

rights.

• “A participant of the examinee role can only modify his/her answer book before end of his/her exam-session”.


RBAC Models (NIST’2000)

Separation of Duties CONSTRAINTS

Users RolesUser

Assignment

Permission

Assignment

Session

Permissions


What is a Role?

• Reflects job functions performed in a company

– E.g. human resource manger, secretary

• Represent task competence

– E.g. physician, pharmacist

• Embody the authority and responsibility

– E.g. project supervisor

• Reflect specific duty assigned

– E.g. a duty physician, a shift manager


Why Role Based Model?

• A role is a collection of permissions.

• Security administration based on Role is simpler

– Users can be assigned or reassigned to roles to fit security needs.

– Can specify security constraints without knowing who will be in the role.


Owner Assignment

A2R2R1R0

A1

O1

R3 R4

Outside Domain Owner Adm2

Creator Adm1

Owner R2 Creator R1After event E,

Owner R2

Owner R1 A2

R1A1 R2

O1R3 R4

Adm1

Before EAfter E

R0

Adm2

Owner Hierarchies

Object TypeActivity Template RoleLEGEND Own/Manage

Activity Template


Model for Coordination Requirments

• Task model for coordination requirements– Not concerned with requirements related to users’

presence, e.g., intra-role coordination. – Example:

Examination := Examiner.SetPaper; Examinee.ExamSession:#member(Examinee)

Converted To LTL expression :

(Examiner.SetPaper.finish Examinee.ExamSession.start )

(Examination.start Examiner.SetPaper.start )

( count (ExamSession.finish, member(Examinee) )Examination.finish)


Verification Model for Role Constraints

• The presence of users in roles is modeled

– To reduce search space, a minimal number for initial user assignment is calculated based on cardinality of the roles and intra-role coordination constraints.

• In Course template, a minimal number is 4 with 2 in Student

– A correctness requirement that Grader role will eventually have user C as member, is expressed in LTL

member(C, Grader)


Correctness Verification

I. Task model for coordination requirements:– Not concerned with requirements related to users’ presence.

– Path expressions are converted to LTL expression.

II. Role Model:– The presence of users in roles is modeled.

– To reduce search space, a minimal number for initial user assignment is calculated.

• A requirement verified with a minimal number of participants is also valid for a larger number of participants.

• In Course template, a minimal number is 5 with 2 in Assistant and 2 in Student.


Entities Owned by Untrusted Users

A2R2R1R0

A1

O1

R3 R4

Outside Domain Owner Adm2

Creator Adm1

Owner R2 Creator R1After event E,

Owner R2

Owner R1 A2

R1A1 R2

O1R3 R4

Adm1

Before EAfter E

R0

Adm2

Owner Hierarchies

Object TypeActivity Template RoleLEGEND

Member of

Own/Manage

Role Reflection Not Member of

Assigned R0, R1, R2

Activity Template


Verification Methodology

• Goal is to determine safe assignments of administrative roles.

• Steps: 1. Determine potentially misbehaving entities based on trust domains

assigned by the designer.2. Within this list, model an entity in the inner most activity template

as misbehaving. – If a requirement is violated, the entity is consequently misbehaving.– If not, continue with the next potentially misbehaving entity.

– Concern of the verification model and the scope of the misbehaving entity suggest which requirements need to be verified.

3. Find consequently misbehaving entities and assign owners that can be trusted for the specific policy aspect.


Access Control Policy (ACP) Template

.OBJECT(ExamPaper, $z)

SUBJECT { ACTIVITY_TEMPLATE = $y.ExamSession,

OBJECT = ACTIVITY(Course, $x). ACTIVITY(Examination, $y)

OWNER = $x.Instructor

ENTRY {SUBJECT = $y.Examiner

PERMISSION = setPaper

CONDITION = ( #( $y.Examiner.SetPaper.start) = 0 ) }

ENTRY {

ROLE = Candidate }PERMISSION = readPaper }


Relations Between Specification & Objects

Control Space for Specification

Object Space

OPERATION, ROLE,

ACTIVITY

event

Object Object

ACTION

Event Space for Condition Specification

Shared Applications

and Resources

event

PRE-CONDITION


Objectives of Policy Verification

• User interactions follow coordination requirements.

• Roles do not have conflicting or inconsistent constraints.

• Confidential information cannot flow to unauthorized users.

• Any temporal or conditional constraints on accessing objects can be satisfied.

• The safety property that no rights can be leaked to unauthorized users.

policy based design of secure distributed collaboration systems tanvir ahmed department of computer...

Documents

twin citiestanvir ahmed1

twin citiestanvir ahmedsteps

design of policy

security domains

policy specificationin

policydriven middleware

coordination state

modelchecker spin