Policy Based Design of Secure Distributed Collaboration Systems

1
Policy Based Design of Secure Distributed
Collaboration Systems
Tanvir Ahmed Department of Computer Science
University of Minnesota, Twin Cities

2
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.

3
Research Goal

• Derive 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
Coordination and Security Policies
Collaboration Environment
Collaboration Environment
Policy Driven Middleware
Shared Application and Resources
4
CSCW Systems

• 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.

5
Distributed Collaboration

Enterprise B
Enterprise A
Enterprise D
Enterprise C
6
Steps in Building a Collaboration
Design Tool

Collaboration Specification

• Analysis and Verification
• Model checking

• Derivation of Policy Templates
• Access control administrative policies

Execution Environment
7
Research Contributions

• A role-based specification model for CSCW
  systems.
• Security and coordination requirements.
• A verification methodology using finite-state
  based model checking.
• Model-checker SPIN.
• A design of policy-driven middleware for secure
  distributed collaboration.
• A proof-of-concept implementation.
• Build several experimental collaborations with
  various policies.

8
A Role-Based Model for CSCW

users
roles
objects
GradeSheet
Examiner
ExamPaper
Grader
AnswerBook
Student
9
(1) A Role-Based Collaboration Specification Model

10
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.

11
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

12
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.

13
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.

14
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 participants 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.

15
Example Course Activity Template
Activity Creation Role members and objects can be
assigned during creation of nested activities.
ActivityTemplate Course
Role reflection
Role Student
Role Assistant
Role Instructor
Dynamic role assignment
WhiteBoard
Joining role
ActivityTemplate Examination
Role Examinee
Role Examiner
Role Grader
Object parameters
ExamPaper
ActivityTemplate ExamSession
ExamPaper
Role Checker
AnswerBook
Role Candidate
16
Example Task-Flow Requirements
Examination
ExamSession
StartExam
Role Examinee
member(Examinee)
SetPaper
end
begin
Role Examiner
StartExam
ExamSession
Role Examinee
Activity
Task-flow dependency
LEGEND
17
Activity Template Specification

• Role Specifications
• Role Admission Constraints
• Role Validation Constraints
• Role Activation Constraints
• Role Operations
• Precondition specify coordination and
  synchronization policies.
• Action
• Grant permission
• Create Activity / Object
• Invoke method
• Generate Application Defined Event
• Nested Activity Templates

18
Role Membership Functions

• Pseudo-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 )

19
Event Model

• 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)
• 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.

20
Event-based Predicates

• Lists all the event of a specific type
  (EventName)
• Filtering an event list based on its attributes
• (EventName(invokerthisUser))
• 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
• (EventName(invokerthisUser)) 0
• True if the event is not previously generated by
  the user who is currently executing.
• EventName(last).invokerthisUser
• True if the last event is generated by the same
  user who is currently executing.

21
Role Admission Constraints

• Conditions that must be satisfied when a user is
  admitted to a role.
• ROLE Assistant
• ADMISSION_CONSTRAINTS
• members(Assistant) lt 1
• member(thisUser, Staff)
• !member(thisUser, Student)
• Role cardinality (maximum)
• Previous role membership
• Static separation of duties

22
Role Validation Constraints

• A users 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.

23
Precondition

• Condition that must be satisfied when an
  operation is executed.
• OPERATION ApproveInvoice
• PRECONDITION
• (PrepareInvoice.finish(invokerthisUser))
  0
• ACTION / Approve the invoice /
• Preconditions allow to specify
• Object based separation of duties
• Operational separation of duties
• Condition context-based based access control

24
Role Activation Constraints

• Condition that must be satisfied for execution of
  any operation.
• E.g., Minimum role cardinality
• ROLE CodeReviewer
• ACTIVATION_CONSTRAINTS
• member(thisRole)gt3
• (members(thisRole) n members(Developer)) gt 0
• (members(thisRole) n members(ProjectManager))
  gt 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.

25
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.

26
ExamSession Activity

• An instance of this activity is created by a
  student in the Examinee role.

ActivityTemplate ExamSession
ExamPaper
Role Checker
Role Candidate
AnswerBook
27
Example ExamSession Specification(1/2)

• ACTIVITY_TEMPLATE ExamSession (OWNER Grader,
• OBJECTS (ExamPaper exam),
• ASSIGNED_ROLES Candidate)
• TERMINATION_CONDITION (Checker.Grade.finish
  ) gt 0
• ROLE Checker
• ADMISSION_CONSTRAINTS
• members(thisRole) lt 2
• member(thisUser, parentActivity.Grade
  r)
• OPERATION Grade
• PRECONDITION (Candidate.Submit.finis
  h) 1
• ACTION GRANT ans.setGrade(data)
• OPERATION ApproveGrade
• PRECONDITION (Grade.finish) gt 0
• (Grade.finish(invokerthisUser) ) 0
• ACTION GRANT ans.approveGrade()
• ROLE Candidate

28
Example ExamSession Specification (2/2)

• ROLE Candidate
• ADMISSION_CONSTRAINTS
• member(thisUser, Examinee)
• member(thisUser, thisActivity.Creator)
• members(thisRole) lt 1
• ACTIVATION_CONSTRAINTS
• time gt DATE(Mar, 22, 2002, 800)
• time lt DATE(Mar, 22, 2002, 1100)
• OPERATION StartExam
• PRECONDITION (StartExam.start) 0
• ACTION ans new OBJECT(AnswerBook)
• GRANT
  exam.readPaper( )
• OPERATION Write .
• OPERATION Submit
• PRECONDITION (Write.finish) gt 0
• ACTION CHANGE_OWNER (ans, Checker)

29
Editor
30
Related Role Based Models

• NIST2000 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
• ARBAC02 (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.

31
(2) Verification methodology using model checking

32
Static Verification

• Correctness and consistency of a specification
• Reachability of Operations
• Task Flow
• Role Based Constraints
• Global properties related to security
  requirements
• Confidentiality and Information Flow
• Integrity and Access Leakage
• Safety property no rights can be leaked to
  unauthorized users.

33
Correctness of Global Properties

• Reachability of Operations Example,
• OPERATION Op1 PRECONDITION (Op2.finish) 1
  
• OPERATION Op2 PRECONDITION (Op1.finish) 1
• 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.ExamSessionmember(Examin
  ee)
• Role Based Constraints
• Example of inconsistent constraint
• ROLE B VALIDATION CONSTRAINTS ! member(A)
• ROLE C ADMISSION CONSTRAINTS member(A)
  member(B)

34
Global Security Requirements

• 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.
• 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.

35
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.

36
Challenges in Model Checking

• Problem 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.
• Task Model
• Role Model
• Information Flow Model
• 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.

37
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 gt 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 gt
  t1, then information flow from s1 to s2, i.e.,
  s1? s2.

38
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.

39
Example Verification in Course Activity
Initial user assignment Student (A, B),
Assistant (C,D), Instructor (E)
Activity Course
Assistant (C,D)
Instructor(E)
Student (A,B)
WhiteBoard
Activity Examination
Examinee(A,B)
Examiner(E)
Grader(C, D)
ExamPaper
40
Verification with Owner Assignment

• Administrative Trust an owner of an entity is
  trusted to enforce the entity specific policies.
• 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.
• 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.

41
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.

42
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)

43
(3) A Policy-Based Middleware for Distributed
Collaboration

44
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.

45
Recap Steps in Building a Collaboration
Design Tool

Collaboration Specification

• Analysis and Verification
• Model checking

• Derivation of Policy Templates
• Access control administrative policies

Execution Environment
46
Access Control Policy (ACP) Template
OBJECT ACTIVITY(Course, x).
ACTIVITY(Examination, y)
.OBJECT(ExamPaper, z)
OWNER x.Instructor
ENTRY
SUBJECT y.Examiner
PERMISSION setPaper
CONDITION ( ( y.Examiner.SetPaper.start) 0
)
ENTRY
.
47
Middleware Components and Services

Collaboration Specification with Application
Level Objects
Activity Definition
Object Definition
Policy Module
Policy Module
Generic Activity Manager
Generic Object Manager
Middleware Components
Name Service
Public Key Service
Event Service
Middleware Services
48
User Interaction Model

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

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

User Coordination Interface (UCI)
Role Manager
Object Manager
Object
49
Runtime Execution View
User Bs Coordination Interface (UCI)
User As Coordination Interface (UCI)
System
Convener
Conveners Protection Domain
Managers
Role Stub
Activity
Role
50
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

51
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

52
(4) Experimentations Evaluations

53
CSCW Applications

• Experiment with different collaborative systems
  and different security and coordination policies.
  
• Collaborative Document Authoring
• Collaborative Classroom
• Interactive Whiteboard Sharing
• Online Meeting (Audio only)
• Collaborative Notes Taking
• Note Four under-graduate students and two
  graduate students have experimented with CSCW
  environments.

54
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.

55
User Coordination Interface (UCI)
56
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

57
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.

58
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.

59
Publications

1. "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.

60
Publications

• "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)
• "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 )

61
Publications in Network Monitoring

1. "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.

62
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)

63
END

64
The End.

65
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.

66
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.

67
Verification Methodology

• Solutions Modify the specification.
• Student roles privileges on BulletinBoard are
  revoked during Examination activity.
• 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)

68
Global Security Requirements

• 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.
• 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.

69
RBAC Models (NIST2000)
Permission Assignment
User Assignment
Roles
Users
70
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

71
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.

72
Owner Assignment
Owner Hierarchies
Activity Template
Creator Adm1
A1
R2
R1
Owner R2
Creator R1 After event E, Owner R2
Outside Domain Owner Adm2
After E
Before E
Owner R1
LEGEND
73
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.ExamSessionmember(Exami
  nee)
• Converted To LTL expression

74
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

75
Correctness Verification

• Task model for coordination requirements
• Not concerned with requirements related to users
  presence.
• Path expressions are converted to LTL expression.
• 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.

76
Entities Owned by Untrusted Users
Owner Hierarchies
Activity Template
Creator Adm1
A1
R2
R1
Owner R2
Creator R1 After event E, Owner R2
Outside Domain Owner Adm2
After E
Before E
Owner R1
LEGEND
Member of
Role Reflection
Not Member of
77
Verification Methodology

• Goal is to determine safe assignments of
  administrative roles.
• Steps
• Determine potentially misbehaving entities based
  on trust domains assigned by the designer.
• 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.
• Find consequently misbehaving entities and assign
  owners that can be trusted for the specific
  policy aspect.

78
Access Control Policy (ACP) Template
.OBJECT(ExamPaper, z)
SUBJECT ACTIVITY_TEMPLATE y.ExamSession,
79
Relations Between Specification Objects
PRE-CONDITION

OPERATION, ROLE, ACTIVITY
Event Space for Condition Specification
event
ACTION
Control Space for Specification
Object Space
event
Shared Applications and Resources
Object
Object
80
Policy-Based Approach

• Decouples coordination and security aspects of a
  collaboration from the implementation of shared
  application resources.
• Collaboration systems evolve with changes in
  administrative policies and user experience.
• New devices, tools or artifacts may need to be
  integrated into a collaboration environment.
• Provides flexibility in designing a collaboration
  environment, as different policies can be easily
  plugged in.

81
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.