Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Policy Based Design of Secure Distributed Collaboration Systems Tanvir Ahmed Department of Computer Science University of Minnesota, Twin Cities."— Presentation transcript:

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

2 1 University of Minnesota, Twin Cities Tanvir 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.

3 2 University of Minnesota, Twin Cities Tanvir Ahmed 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 Policy Driven Middleware Coordination and Security Policies Collaboration Environment Collaboration Environment Shared Application and Resources

4 3 University of Minnesota, Twin Cities Tanvir Ahmed CSCW Systems Workflow 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.

5 4 University of Minnesota, Twin Cities Tanvir Ahmed Distributed Collaboration Enterprise A Enterprise C Enterprise B Enterprise D Activities Coordination / synchronization Security Requirements

6 5 University of Minnesota, Twin Cities Tanvir Ahmed 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

7 6 University of Minnesota, Twin Cities Tanvir Ahmed Research Contributions 1.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.

8 7 University of Minnesota, Twin Cities Tanvir Ahmed Examination Activity A Role-Based Model for CSCW ExamPaper Examiner Grader Student GradeSheet AnswerBook users roles objects

9 8 University of Minnesota, Twin Cities Tanvir Ahmed (1) A Role-Based Collaboration Specification Model

10 9 University of Minnesota, Twin Cities Tanvir Ahmed 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 10 University of Minnesota, Twin Cities Tanvir Ahmed 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 11 University of Minnesota, Twin Cities Tanvir Ahmed 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 12 University of Minnesota, Twin Cities Tanvir Ahmed 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 13 University of Minnesota, Twin Cities Tanvir Ahmed 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.

15 14 University of Minnesota, Twin Cities Tanvir Ahmed Example: Course Activity Template ExamPaper ActivityTemplate ExamSession ExamPaper Role Checker Role Candidate Role Assistant Role Examinee Role Examiner Role 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

16 15 University of Minnesota, Twin Cities Tanvir Ahmed Example: Task-Flow Requirements SetPaper ExamSession StartExam ExamSession # member(Examinee) begin end Role Examiner Role Examinee LEGEND Activity Task-flow dependency StartExam Examination Role Examinee

17 16 University of Minnesota, Twin Cities Tanvir Ahmed Activity Template Specification 1.Role Specifications –Role Admission Constraints –Role Validation Constraints –Role Activation Constraints –Role Operations 1.Precondition: specify coordination and synchronization policies. 2.Action: Grant permission Create Activity / Object Invoke method Generate Application Defined Event 2.Nested Activity Templates

18 17 University of Minnesota, Twin Cities Tanvir Ahmed 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 18 University of Minnesota, Twin Cities Tanvir Ahmed Event Model 1.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.

20 19 University of Minnesota, Twin Cities Tanvir Ahmed 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.

21 20 University of Minnesota, Twin Cities Tanvir Ahmed 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

22 21 University of Minnesota, Twin Cities Tanvir Ahmed 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.

23 22 University of Minnesota, Twin Cities Tanvir Ahmed 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

24 23 University of Minnesota, Twin Cities Tanvir Ahmed 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.

25 24 University of Minnesota, Twin Cities Tanvir Ahmed 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 25 University of Minnesota, Twin Cities Tanvir Ahmed ExamSession Activity An instance of this activity is created by a student in the Examinee role. ActivityTemplate ExamSession ExamPaper AnswerBook Role CheckerRole Candidate

27 26 University of Minnesota, Twin Cities Tanvir Ahmed 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 { …

28 27 University of Minnesota, Twin Cities Tanvir Ahmed 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) } }

29 28 University of Minnesota, Twin Cities Tanvir Ahmed Editor

30 29 University of Minnesota, Twin Cities Tanvir Ahmed 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.

31 30 University of Minnesota, Twin Cities Tanvir Ahmed (2) Verification methodology using model checking

32 31 University of Minnesota, Twin Cities Tanvir Ahmed 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.

33 32 University of Minnesota, Twin Cities Tanvir Ahmed 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)

34 33 University of Minnesota, Twin Cities Tanvir Ahmed 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”.

35 34 University of Minnesota, Twin Cities Tanvir Ahmed 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 35 University of Minnesota, Twin Cities Tanvir Ahmed 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. I.Task Model II.Role Model III.Information Flow Model IV.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 36 University of Minnesota, Twin Cities Tanvir Ahmed 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 O2 t2 >= t1 O S1 t2 >= t1 S2

38 37 University of Minnesota, Twin Cities Tanvir Ahmed 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) )

39 38 University of Minnesota, Twin Cities Tanvir Ahmed Example Verification in Course Activity Initial 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 w r r r (3) Examinee B leaks to A (3) w r

40 39 University of Minnesota, Twin Cities Tanvir Ahmed 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.

41 40 University of Minnesota, Twin Cities Tanvir Ahmed 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 41 University of Minnesota, Twin Cities Tanvir Ahmed 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 42 University of Minnesota, Twin Cities Tanvir Ahmed (3) A Policy-Based Middleware for Distributed Collaboration

44 43 University of Minnesota, Twin Cities Tanvir Ahmed 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 44 University of Minnesota, Twin Cities Tanvir Ahmed 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

46 45 University of Minnesota, Twin Cities Tanvir Ahmed 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 {

47 46 University of Minnesota, Twin Cities Tanvir Ahmed Middleware Components and Services Role Definition Generic Role Manager Policy Module Activity Definition Generic Activity Manager Policy Module Object Definition Generic Object Manager Policy Module Middleware Components Collaboration Specification with Application Level Objects Middleware Services Name ServicePublic Key ServiceEvent Service

48 47 University of Minnesota, Twin Cities Tanvir Ahmed User Interaction Model User Coordination Interface (UCI) Role Manager Object Manager 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 Object Interface

49 48 University of Minnesota, Twin Cities Tanvir Ahmed 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 StudentInstructorAssistantExamination Course.chemistry Examiner Examinee GraderExamSession ExamPaper Examination.midterm Examiner Grader Instructor Instructor’s Protection Domain Object exam Managers

50 49 University of Minnesota, Twin Cities Tanvir Ahmed 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 50 University of Minnesota, Twin Cities Tanvir Ahmed 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 51 University of Minnesota, Twin Cities Tanvir Ahmed (4) Experimentations & Evaluations

53 52 University of Minnesota, Twin Cities Tanvir Ahmed 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.

54 53 University of Minnesota, Twin Cities Tanvir Ahmed 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 54 University of Minnesota, Twin Cities Tanvir Ahmed User Coordination Interface (UCI)

56 55 University of Minnesota, Twin Cities Tanvir Ahmed 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 56 University of Minnesota, Twin Cities Tanvir Ahmed 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 57 University of Minnesota, Twin Cities Tanvir Ahmed 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 58 University of Minnesota, Twin Cities Tanvir Ahmed Publications 1."Static Verification of Security Requirements in Role Based CSCW Systems", Tanvir Ahmed and Anand Tripathi. In 8 th 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 22 nd 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 59 University of Minnesota, Twin Cities Tanvir Ahmed Publications 5."Distributed Collaborations using Network Mobile Agents", Anand Tripathi, Tanvir Ahmed, Vineet Kakani, and Shremattie Jaman. In 2 nd International Symposium on Agent Systems and Applications/ 4 th 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

61 60 University of Minnesota, Twin Cities Tanvir Ahmed 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, "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 61 University of Minnesota, Twin Cities Tanvir Ahmed 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), (Journal). 3."Mobile Agent Programming in Ajanta", Anand Tripathi, Neeran Karnik, Manish Vora, Tanvir Ahmed, and Ram Singh. In Proceedings of the 19 th IEEE International Conference on Distributed Computing Systems (IEEE ICDCS 99)

63 62 University of Minnesota, Twin Cities Tanvir Ahmed

64 63 University of Minnesota, Twin Cities Tanvir Ahmed The End.

65 64 University of Minnesota, Twin Cities Tanvir Ahmed 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 65 University of Minnesota, Twin Cities Tanvir Ahmed 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 66 University of Minnesota, Twin Cities Tanvir Ahmed 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)

68 67 University of Minnesota, Twin Cities Tanvir Ahmed 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”.

69 68 University of Minnesota, Twin Cities Tanvir Ahmed RBAC Models (NIST’2000) Separation of Duties CONSTRAINTS Users Roles User Assignment Permission Assignment Session Permi ssions

70 69 University of Minnesota, Twin Cities Tanvir Ahmed 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 70 University of Minnesota, Twin Cities Tanvir Ahmed 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 71 University of Minnesota, Twin Cities Tanvir Ahmed Owner Assignment A2 R2R1 R0 A1 O1 R3R4 Outside Domain Owner Adm2 Creator Adm1 Owner R2 Creator R1 After event E, Owner R2 Owner R1 A2 R1 A1 R2 O1 R3R4Adm1 Before E After E R0 Adm2 Owner Hierarchies Object Type Activity Template Role LEGEND Own/Manage Activity Template

73 72 University of Minnesota, Twin Cities Tanvir Ahmed 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)

74 73 University of Minnesota, Twin Cities Tanvir Ahmed 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)

75 74 University of Minnesota, Twin Cities Tanvir Ahmed 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.

76 75 University of Minnesota, Twin Cities Tanvir Ahmed Entities Owned by Untrusted Users A2 R2R1 R0 A1 O1 R3R4 Outside Domain Owner Adm2 Creator Adm1 Owner R2 Creator R1 After event E, Owner R2 Owner R1 A2 R1 A1 R2 O1 R3R4Adm1 Before E After E R0 Adm2 Owner Hierarchies Object Type Activity Template Role LEGEND Member of Own/Manage Role Reflection Not Member of Assigned R0, R1, R2 Activity Template

77 76 University of Minnesota, Twin Cities Tanvir Ahmed 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.

78 77 University of Minnesota, Twin Cities Tanvir Ahmed 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 }

79 78 University of Minnesota, Twin Cities Tanvir Ahmed Relations Between Specification & Objects Control Space for Specification Object Space OPERATION, ROLE, ACTIVITY event Object ACTION Event Space for Condition Specification Shared Applications and Resources event PRE-CONDITION

80 79 University of Minnesota, Twin Cities Tanvir Ahmed 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 80 University of Minnesota, Twin Cities Tanvir Ahmed 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.


Download ppt "Policy Based Design of Secure Distributed Collaboration Systems Tanvir Ahmed Department of Computer Science University of Minnesota, Twin Cities."

Similar presentations


Ads by Google