Security Policies

1. Security Policies

2. Security Policies • A security policy is a statement of what is and what is not allowed • A security mechanism is a method, tool, or procedure for enforcing a security policy • here we are talking mainly about security mechanisms

3. The First Access-Control Computing System James Ritty salonkeeper in Dayton (Ohio) invented the first cash register in 1879 „incorruptible cashier“

4. Security Policies in Real Life Objects Access control Subjects

5. Security in Real Life Objects Access control Subjects

6. Access Control • Aspects of IT-security are • Confidentiality • Integrity • Accessability • … • Known (technical) security policies are restricted to confidentiality and integrity

7. Analogy in Access Control • Completeness • Access control must not be circumvented • (e.g. there is only one entry to the building) • Correctness • Access control must be correctly implemented • (e.g. no other key fits incidentally into the lock) • Integrity • Access control must not be manipulated in an unauthorised way. (e.g. emergency alarm)

8. Analogy of Organisational Security • Multi-level security policies (MLS-policies) • Different levels of security • E.g. top secret, secret, confidential, public • Relating security levels • To subjects (persons) and objects (rooms or items) • Control • Access right is only granted if person has the appropriate authorization, i.e. security level

9. Access Control - Strategies • Discretionary access control: • Owner principle: owner decides about access control • Unix-systems • Mandatory access control: • Systemrules (MAC) decide about access • Systemrules govern owner principle • Examples: SE-VMS, Trusted Solaris • Role-based access control: • Access rights depend on the roles of subjects

10. Access control • Active subjects: • e.g. processes, persons, groups …. • Passive objects: • e.g. data, memory banks, ... Access control Objects Subjects Reference monitor

11. Reference Monitor M ... ... O ... ... ... ... R1..Rn S ... ... • Access control concept of an abstract machine • Access matrix M M : Sx O 2R • Access rights: e.g. read, write,execute • S may read O iff read  M(S, O)

12. Dynamic Access Control • Subjects, objects, and rules in M changes over the time: • Mt : St x Ot 2R • Example of a mono-operational system: • Create/delete object, create/delete subjects • Enter rights, delete rights: enter r into (s,o) : if s  St, o  Ot then Mt‘(s, o) = Mt(s, o)  {r}delete r from (s,o) : if s  St, o  Ot then Mt‘(s, o) = Mt(s, o) \ {r}

13. Safety - Problem • Let Kt = (Mt, Ot, St) be a system configuration and K0 be the initial configuration • Ktop Kt+1 : application of op transforms Kt into Kt+1 • Let Kt be a configuration with r  Mt(s, o). • Is there are sequence op1,.., opn that leaks r ? • Ktop1 Kt+1op2 ... opn Kt+n • and r  Mt+n(s, o) ? • A system is safe wrt. a right r iff it never leaks r (to s).

14. Safety - Models and Decidability • Mono-operational systems (Harrison, Ruzzo, Ullman 1976) • Rules: if a1 M(s1, o1) ... an M(sn, on) then op • Restricted expressiveness: E.g. Cannot grant owner special rights • Safety of a mono-operational system is decidable • General systems: • Rules: if a1 M(s1, o1) ... an M(sn, on) then op1 ... opm • Safety of a general system is undecidable • The set of unsafe systems is recursively enumerable

15. Access Control Lists • An access control list acl is a set of pairs (s, Rs) with s 2 S (subject) and Rsµ R (subset of rights). • acl(o) = { (si, Rsi) | 1 ≤ i ≤ n } :si may access o using any right of Rsi • Access control lists in practice • list of attributes for each file (inode) containing: • file control block, owner, length, generation- access- and modification dates, ACL • ACL in Unix: • subject clases: user, group, others • rights: r w x (i.e. read, write, execute)

16. Discretionary Access Control A means of restricting access to objects based on the identity of subjects or groups, or both, to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passingthat permission on to any other subject (DoD, TCSEC) • Owner of an object can arbitrarily grant access rights to other subjects • Problem of how to limit propagation of rights • Granted access rights can be granted again to other subjects • Problem of trojanian horses

17. Mandatory Access Control • System grants access rights according to a system-wide policy • Examples (in this course): • Chinese-Wall • Bell/LaPadula • Biba A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e. clearance) of subjects to information of such sensitivity. (DoD, TCSEC)

18. Chinese-Wall Model (Bresher-Nash) • Banking example: • No use of insider knowledge • Previous actions of a subject determines (i.e. restricts) access rightsi.e. rights are continually decreasing • Rights are usually read, write, execute • Classify objects in different conflict classes • Classify subjects into different companies

19. Chinese-Wall Rules • Read-Access: • Only if no previous access to another object of the same conflict class but different company • Write-Access: • Only if all previous read-accesses are concerned with objects of the same company or unclassified objects.

20. Chinese – Wall (Definitions) • y(o) : company (owner) of an object o • x(o) : conflict class of object o • y0 : public objects • x0 : no possible conflicts • Nt: S x O  2R : Access historyNt(s, o) = {r1,..., rn} iff there is a time t‘ < t such that s has accessed o using rights {r1,..., rn}

21. Chinese-Wall: Security Properties • An access z to an object o  O is admissible for a subject s  S at time t iff z  Mt(s, o)   o‘ O: Nt(s, o‘)    (y(o‘)  y0  x(o) = x(o‘))  y(o) =y(o‘) • A subject s may write an object o at t iff • Write  Mt(s, o)   o‘ O: read  Nt(s, o‘)  y(o) =y(o‘)  y(o‘) = y0

22. Bell/LaPadula - Model • David Bell and Len LaPadula, 1973on initiative of US Air Force • Most famous and influential security model • Purposes: • Simple security mechanisms enabling verification • Confidentiality of information • Multi-level Security System (MLS) • Classification according to levels of confidentiality like: top secret, secret, confidential, public • Information cannot flow downward:i.e. from top secret to public ! • Static model: no change of security levels!

23. Bell LaPadula - Definitions • Fixed sets of subjects S and objects O • Lattice of security levels L, ≤ : • for each two security levels there aregreatest lower (glb) and least upper bounds (lub) • Assign security levels to subjets (clearances) and objects (classifications): sc : S  O  L • Access matrix M : Sx O 2R (as before) Top secret ≤ ≤ Secret B Secret A ≤ ≤ restricted ≤ public

24. Bell LaPadula - Actions Write Security levels Read Security levels : subject : object

25. Bell/La Padula [1973] Secure states • A state (sc, M) is read secure (simple security property or no read up):  s  S.  o  O :read M(s, o)  sc(o)  sc(s) • A state (sc, M) is write secure (* – property or no write down):  s  S.  o  O :write M(s, o)  sc(s)  sc(o) • A state (sc, M) is secure iff it is read secure and write secure

26. Bell/La Padula [1973] What is the underlying system (V, R, T, v0) ? • States V are sets of pairs (sc, M) of a security lattice sc and access matrix M • Set R of requests are operations to change M:i.e. grant or deny read or write access of some s 2 S to some o 2 O • State transition function T: (V x R)  V • v0 is the initial state

27. Bell/La Padula [1973] v0 vn vn+1 v1 A system (v0, R, T) is secure iff • v0 is state secure and • every state vn reachable from v0 by executing a finite sequence of requests from R is secure Verification of a secure system typically by induction on the number of state transitions

28. Basic Security Theorem A system (v0, R, T) is secure iff • v0, is a secure state • T has the property that for all states reachable from v0 via R:T( (sc, M), r) = (sc‘, M‘) implies for all s  S and o  O: • If read  M‘(s,o) and read  M(s,o) then sc‘(s)  sc‘(o) • If read  M(s,o) and sc‘(s) < sc‘(o) then read  M‘(s,o) • If write  M‘(s,o) and write  M(s,o) then sc‘(o)  sc‘(s) and • If write  M(s,o) and sc‘(o) < sc‘(s) then write  M‘(s,o) Proof by induction.

29. Modelling Security – Critics on BLP „When you pray to God, you do not expect an individual acknowledgement of each prayer before saying the next one“ unknown NSA scientist • What is the appropriate (formal) notion of security ? • Blind write-up: no response from writing (black hole) • Workstations following BLP: • Prevention of copy-paste mechanisms in OS • problems of setting colormaps in windows • licence servers (!) • Aggregation of data (appropriate security levels?) • …

30. Critics on BLP - Transquility Principle of transquility: subjects and objects may not change their security level once they have been initialized. • Strong transquility: • Security levels of subjects and objects do not change during their lifetime • Weak transquility: • Security levels of subjects and objects do not change in a way that violates the security policy

31. Critics on BLP - System Z (MacLean) • Problem: • BST is transparent with respect to the definition of secure states • E.g. declassify object before reading it • System Z (MacLean) • Same as BLP with additional function C : S  O  2S C(x) : all subjects who can change security level of x • Transistions T : (S x V x R)  V

32. System Z - Definitions A transition function T : (S x V x R)  V is transition secure iff T(s, (sc, M), r) = (sc‘, M‘) implies  x  S  O : sc(x)  sc‘(x)  s  C(x) A system (v0, R, T) is secure iff • v0 and all states reachable from v0 by a finite sequence of requests from R are secure • T is transition secure

33. Implementation of BLP - Critics on BLP • Polyinstantiations • problem of how to hide high-level objects • e.g. database entries • „cover stories“ • Covert channels high-level process signals information to low-level process by: • consumption of power, CPU, disk storage, availability of resources,… • randomized clocks, insertion of noise into images or power consumption, specialized scheduler, etc

34. BLP - Conclusions Frameworks forms a Boolean algebra • Bottom-element: BLP with tranquility, i.e. no security level can change • Top-element: no restrictions on changes of security levels • Possible to meet, join, or inverse policies Current starting point when designing mandatory access control

35. Biba [1977] • Aspect of security: Integrity • Classification according to levels of integrity • Requirements • Dual simple security property  s  S.  o  O :write M(s, o)  sc(o)  sc(s) • Dual * - property  s  S.  o  O :read M(s, o)  sc(s)  sc(o) • Biba is directly opposed to Bell/La Padula

36. Role Based Access Control (RBAC) user assignment session roles user‘s sessions Subjects(Sessions) • Roles as a central notion: • rights / permissions are grouped into roles • assignment of users to roles (static) • activation of roles for subjects (i.e. sessions, dynamic) Users Roles Permissions permission assignment

37. Basic Rules of RBAC Generalized RBAC model (Ferraiolo, Kuhn 1992) • Role assignment (static): • subject can execute transactions only if the subject is assigned to a role • Role authorization (dynamic): • a subject‘s active role must be authorized for the subject • Transaction authorization: • a subject can execute a transaction only if the transaction is authorized for the subject‘s active role

38. Core RBAC UA µ Users £ Roles assigned_users: Roles ! 2Users subject_user: Subjects ! Users subject_roles: Subjects ! 2Roles subject_roles(s) µ {r 2 Roles | (subject_users(s), r) 2 UA } PRMS = 2Ops £ Objects PA µ PRMS £ Roles assigned_perms: Roles ! 2PRMS assigned_perms(r) = {p 2 PRMS | (p,r) 2 PA} UA PA Permissions Users Roles Ops assigned perms assigned users PRMS subject user subject‘s active roles (dynamic) Objects Subjects (sessions)

39. Authorization in Core RBAC Role authorization: (active roles are always authorized) 8 s:Subjects, u:Users, r:Roles: r 2 subject_roles(s) Æ u = subject_user(s) ! u 2 assigned_users(r) with: access : Subjects £ Ops £ Objects ! Bool access(s, op, o) = true iff s can access o using operation op Object access authorization: (operation only if s has a role for it) 8 s:Subjects, op:Ops, o:Objects: access(s, op, o) !9 r:Roles, p:PRMS. r 2 subject_roles(s) Æ p 2 assigned_perms(r) Æ (op, o) 2 p

40. Hierarchy of Roles ≼µ Roles £ Roles: partial order on Roles (reflexive, transitive, antisymmetric) • r1≼ r2 says: • all permissions of r1 are also permissions of r2 : r1≼ r2! authorized_perms(r1) µ authorized_perms(r2) • all users of r2 are also users of r1 : r1≼ r2! authorized_users(r2) µ authorized_users(r1) • authorized_perms : Roles ! 2PRMS : authorized_perms(r) = {p 2 PRMS | r‘ ≼ r Æ (p, r‘) 2 PA} • authorized_users : Roles ! 2Users : authorized_users(r) = {u 2 Users | r ≼ r‘ Æ (u, r‘) 2 UA}

41. Limited Role Hierarchy • Role hierarchy is a tree • i.e. there is a single immediate descendent • no multiple inheritence from different roles • easy to implement • standard approach in commercial systems • connector_role: 8 r, r1, r22 Roles: r is a connector role of r1 and r2 iff r ≼ r1Æ r ≼ r2Æ r1≠ r Æ r2 ≠ r : authorized_perms(r) µ authorized_perms(r1) Å authorized_perms(r2) Employee Cashier Account executive

42. General Role Hierarchy • Role hierarchy is a acyclic directed graph • multiple inheritence from different roles • combiner_role: 8 r, r1, r22 Roles: r is a combiner role of r1 and r2 iff r1≼ r Æ r2≼ r Æ r1≠ r Æ r2 ≠ r : authorized_perms(r1) [ authorized_perms(r2) µ authorized_perms(r) Customer Employee Cashier Account executive Revisor Head

43. Separation of Duty • Fundamental principle in security systems • „two man rule“ • Critical operations are divided among two or more people • No single individual can compromise security

44. Static Separation of Duty Accountsreceivablesupervisor Billingsupervisor Cashiersupervisor SoD Accountsreceivableclerk Billing clerk Cashier Accountsreceivable • SoD relations place constraints on assignments of users to roles • Membership in one role may inhibit membership in another role Example:

45. Static Separation of Duty • Static separation of duty SSD µ (2Roles£ N) is a set of pairs (rs, n) with: • rs is a set of roles and n ≥ 2 and • 8 (rs, n) 2 SSD, 8 R µ rs: |R| ≥ n )År 2 Rauthorized_users(r) = ; • i.e. nobody has more than n-1 roles from a set rs of roles • Exercise: formalize bank example

46. Dynamic Separation of Duty • Dynamic separation of duty DSD µ (2Roles£ N) is a set of pairs (rs, n) with: • n ≥ 2 and |rs| ≥ n • 8 s 2 subjects, 8 rsub 2 2Roles:rsub µ rs Æ rsub µ subject_roles(s) ) |rsub| < n • i.e. nobody can activate simultanously more than n-1 roles from a set rs of roles • Exercise: formalize bank example

47. RBAC vs. DAC and MAC RBAC is by nature a non-discretionary approach but • RBAC can simulate DAC in a non-efficient way: • creating various roles and permissions for each (!) object • RBAC can emulate MAC in a straight-forward way: • security levels are encoded in role hierarchies

48. Solaris 10 Using RBAC • Different roles to model usual priviledges of root • su to activate a role: • Role account uses a special shell • Predefined roles: • All : commands without need of root permissions • Primary Administrator: basically equivalent to the root user. • System Administrator: junior level System Administrator role. • Operator: few discrete supplementary profiles to create a basic role. • Basic Solaris User: enables users to perform tasks that are not related to security. • Printer Management: dedicated to the single area of printer administration. • User defined roles using roleadd, rolemod, useradd

49. RBAC on a Glance • Mechanism to allow for an organization specific access control policy • roles as a collection of permissions associated with some functionality or affiliation • dynamic membership of users to roles • Separation of duties (static and dynamic) • hierachies on roles • Widely used in industry to formulate enterprise security policies • Defining role hierachies and permissions etc. is not trivial • Databases as typical applications

50. Usability and Limitations • Bell/La Padula • Confidentiality • Reference monitor assumptions • No covered channels • Problem of dynamically changing security levels • Biba • Integrity • Reference monitor assumptions • No covered channels • Problem of dynamically changing security levels • Noninterference • Confidentiality and integrity