Governance Policies for Privacy Access and their Interactions ICFI-2005

1. Governance Policies for Privacy Access and their InteractionsICFI-2005 Waël Hassan1 & Luigi Logrippo2 1 University of Ottawa School of information technology and engineering 2Université de Québec en Outaouais Department of Computer Science & Engineering

2. Goal Detecting policy interactions in privacy governance policies How • By using formal models • Proposing a privacy model

3. Agenda • Policy Drivers • Convergence of control and policy systems • Requirements of new privacy models • Conflict detection using formal models • Delegation, separation, alloy • Proposed process based privacy model • Evaluation • Support of existing concepts • Advantages over existing models • Verification • Conclusion

4. Policy Model Drivers • Convergence of control and policy systems • From operational to rules of governance • Activity or trigger based to data based • Requirements of new privacy models • Release information based on purpose • Control flow of information • Ability to specify separation of concerns

5. Layers Process Level Functional Hierarchies (Roles) Actions Features Transactions

6. Conflicts in Enterprise Governance • Policies of Access to information can cause conflict depending on their scope • Logically contradicting policies will interact if their scope over lapped. • A subject roaming in multiple scopes can cause a rule conflict • A subject delegating authority of an object can cause a conflict • An object shared by multiple subjects can cause conflict • Policies of privacy access can interact if the reason (purpose) of access is conflicting

7. Roaming Delegation Shared Overlapping scope (PoliciesxRoles)

8. Examples • Rule: An employee cannot have access to both customers’ address and credit card information(Card Number, expiry date, PIN, and last 4 digits on the back of card) ; • Process • one of the tasks of issuing a new card (CreateAccount), includes the mailing of the credit card to the consumer. • (Process) CreateAccount:- (Step)LeaveTraceInSystem, (Process) CreateCard,(Process) MailCard. • Result • Interaction

9. Separation of concerns % • Rule: • No one person is allowed to create and delete accounts • (Process) CreditCardApp:- (Process) ReceiveCardApplication, (Process) CallCreditCheck,(Process) IssueCard, (Process) CreateAccount. • (Process) WithdrawApplication:- (Process) DeleteAccount, (Step) NotifyClient. In this instance Alloy was able to detect violations of such rule.

10. Delegation Interaction • Rule: Information collected for the purpose of credit verification should not be generally available to employees in loan processing Loan Processing Process includes Verify Credit • Employee delegates Role to manager

11. Process Based Governance Governance of organizations by specifying control of access (to information) by applyingpolicies to processes

12. Process Process Based Control • A business process is a unit that can be composed of steps and/or processes. • Steps in a process are sequential

13. Business Process In a business process environment it should be • Easy to tie purposes to actions • Possible to apply invariants for a complete structure • Easy to trace policy modifications

14. PPM Approach Supports • Flow of information (Bell Lapadula) • Separation of concerns (Chinese Wall)

15. Bell-Lapadula Intended for military applications, Flow Based • Security Clearances • Security Requirement A can access y iff • clearance of A > requirement of y A can forward access to y for B iff • clearance of B > requirement of y A y Level B X

16. Bell-Lapadula • Lattice based model Leq U Leq C • Partial-Order • Reflexive • Transitive • Anti-Symmetric S Leq Leq TS

17. Chinese Wall Originally intended for banking applications • Creates separation of concerns groups • Group A & Group B cannot share access to an object set {x,y,z} B A X Y z

18. CW / SOD - Separation of duties User Assigned Role • User Centric • Irreflexive • 2 conflicting users cannot collectively fill 2 roles in conflict. • Inherit conflict groups • Role Centric • Irreflexive • User cannot fill two conflicting Roles • Inherit conflict groups

19. Privacy Process Model Role Hierarchy Roles Process Hierarchy Processes Users Permissions Steps Operations Objects Permission Assignment

20. Two Variations • The process has all the properties and people are simply assigned to steps (activities) as per their roles • Steps retain properties and people are as assigned as per their roles User-Process User-Step Process Hierarchy Process Hierarchy Processes Processes Users Users Steps Steps

21. Privacy Process Model- User-Step Role Hierarchy Roles Process Hierarchy Processes Users Permissions Steps Operations Objects Permission Assignment Sequence

22. Privacy Process Model- User-Process Role Hierarchy Roles Process Hierarchy Processes Users Permission Assignment Permissions Steps Operations Objects Sequence

23. Information flow • A part of standard procedures is delegating work to others. • Example: delegate meeting announcement to secretary • Using process model • Action delegate meeting, allowed in a process • Action meeting cancellation cannot be delegated

24. Separation of Concerns • In the banking industry, different groups may not share access to particular resources. • Using process model we can set rules to separate groups • Example: • No data that admission and scholarship share • Finance and Marketing share no information

25. Advantages of PPM • Captures context • Simplifies management (privacy)

26. Captures Context • As a part of credit application process (x,y,z,t), an employee A receives access to credit information in step z. • Using standard security model, A can download all credit information of all customers on file • When using a process model, • access is granted or revoked based on the sequence of operations. • Therefore, under the process model, an employee A will only have access If steps x & y have been performed • Access will be revoked after operation t is completed x y z t

27. Simplifies Management • Privacy is dependent on the application and not on the identity • An identity can have a role which is involved in several functions. However Its privileges are dependent on process. • Grouping policies per process reduces time and management policies that are based on roles. • Example: • Old • If rank is General, then grant access • If rank is secretary and name is Lise then grant access • New: • Secretary allow-access step 3 • General allow-access process change-direction

28. Implementation and Validation • A validation environment is provided by the language Alloy • A formal language based on set theory and first order predicate calculus • Model analyser • Consistency checker • Being developed at MIT

29. Alloy • Signatures or elements are the basic constructs of an Alloy model; • they are a cluster of relationships grouped in a class like structure. • Sig [abstract] enterprise { • root : CEO • }{ • [lone] root • } Enterprise Process • abstract sig process { • parent : lone process, • composedOf : set steps • } Policy abstract sig policy { attachedTo : lone process, permitted: role -> process, denied : role -> process Facts & Rules } no permitted & denied role.permitted in attachedTo role.denied in attachedTo }

30. Alloy Process

31. Translation Manual Translation Manual Manual Verification Manual Verification Alloy Meta Model ebXML XACML Alloy Policy Specification Architecture UML Model Verification

32. Pragmatic Goals • GUIs to formulate validated policies • Able to answer questions: • Given an enterprise model and a set of policies • Who can/cannot and under what circumstances • Given circumstances, who can/cannot? • Is there inconsistency ? • Is the system compliant to a set of Policies? • Automatic translation between • GUI representation • XACML representation • Formal representation (Alloy or other)

33. Conclusion & Future Work Privacy requires a native model; We were able to model system and detect basic interactions using a formal tool. We plan to use a process based model that attaches policies to processes which are composed of activities, We use Alloy as model analyzer to verify properties.

34. Thanks from Waël Hassan, Luigi Logrippo wael@ieee.org, luigi@uqo.ca

36. Extra • (Process) CreditCardApp:- (Process) ReceiveCardApplication, (Process) CallCreditCheck, (Process) IssueCard, (Process) CreateAccount. • (Process) CreateAccount:- (Step)LeaveTraceInSystem, (Process) CreateCard, (Process) MailCard. • (Process) DeleteAccount:- (Step)LeaveTraceInSystem, (Step)RemoveAccount. • (Process) WithdrawApplication:- (Process) DeleteAccount, (Step) NotifyClient.

37. Security • Basic:- • Identity  Access Right • An identity justifies an access-right • Example: given I am a wael, I can access my lab • Extended:- • Identity1, Identity2  Forwarding Right (object) • A right is owned and can be forwarded (delegated) • Example: given I am an assistant, • I own the right to access personal student file, • I can allow Jasmine access to my file • Combined:- • Identity1, Identity2 Concurrent Access(object) • Two subjects may be allowed to have concurrent access to an object

38. Privacy • Basic:- • Purpose Access-Right (Identity) • A purpose justifies access-right • Example: To update student profile, • Jo-Anne needs to have access to accepted student application data • Extended:- • Step  Forwarding Right (Identity1, Identity2) • A step which can be owned by a person in a process suggests a right, and that right may be forwarded (delegated) iff the recipient has access to the process/step. • Example: given that Jo-Anne participates in the admissions procedure, • She is assigned access to activity open personal student file, • She can allow Jasmine (another officer) access to the same file as long as she has the authority and she is assigned to the process • Combined:- • Process1, Process2 Concurrent Access (object) • Two subjects participating in two processes may or not have concurrent access to certain objects.