security policies n.
Skip this Video
Loading SlideShow in 5 Seconds..
Security Policies PowerPoint Presentation
Download Presentation
Security Policies

Loading in 2 Seconds...

play fullscreen
1 / 50

Security Policies - PowerPoint PPT Presentation

  • Uploaded on

Security Policies. 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. The First Access-Control Computing System.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Security Policies' - zonta

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
security policies1
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
the first access control computing system
The First Access-Control Computing System

James Ritty

salonkeeper in Dayton (Ohio)

invented the first cash register in 1879

„incorruptible cashier“

security policies in real life
Security Policies in Real Life


Access control


security in real life
Security in Real Life


Access control


access control
Access Control
  • Aspects of IT-security are
    • Confidentiality
    • Integrity
    • Accessability
  • Known (technical) security policies are restricted to confidentiality and integrity
analogy in access control
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)
analogy of organisational security
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
access control strategies
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
access control1
Access control
  • Active subjects:
    • e.g. processes, persons, groups ….
  • Passive objects:
    • e.g. data, memory banks, ...





Reference monitor

reference monitor
Reference Monitor













  • 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)
dynamic access control
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}

safety problem
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).
safety models and decidability
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
access control lists
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)
discretionary access control
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
mandatory access control
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)

chinese wall model bresher nash
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
chinese wall rules
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.
chinese wall definitions
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}
chinese wall security properties
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

bell lapadula model
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!
bell lapadula definitions
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



bell lapadula actions
Bell LaPadula - Actions


Security levels


Security levels

: subject

: object

bell la padula 1973
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
bell la padula 19731
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
bell la padula 19732
Bell/La Padula [1973]





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

basic security theorem
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.

modelling security critics on blp
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?)
critics on blp transquility
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
critics on blp system z maclean
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
system z definitions
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
implementation of blp critics on blp
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
blp conclusions
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

biba 1977
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
role based access control rbac
Role Based Access Control (RBAC)

user assignment

session roles

user‘s 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)






basic rules of rbac
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
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}







assigned perms

assigned users


subject user

subject‘s active roles (dynamic)




authorization in core rbac
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

hierarchy of roles
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}
limited role hierarchy
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(r1) Å authorized_perms(r2)





general role hierarchy
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)








separation of duty
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
static separation of duty
Static Separation of Duty






Billing clerk



  • SoD relations place constraints on assignments of users to roles
  • Membership in one role may inhibit membership in another role


static separation of duty1
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
dynamic separation of duty
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
rbac vs dac and mac
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
solaris 10 using rbac
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
rbac on a glance
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
usability and limitations
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