Information Security
Principles & Applications
Topic 6: Security Policy Models
虞慧群
yhq@ecust.edu.cn
Introduction

Primary mission of information security is to ensure that
systems and contents stay the same.

If no threats, we could focus on improving systems,
resulting in vast improvements in ease of use and
usefulness.

Attacks on information systems are a daily occurrence.
Security Policy


Defines what it means for a system to be
secure
Formally: Partitions a system into



Set of secure (authorized) states
Set of non-secure (unauthorized) states
Secure system is one that


Starts in authorized state
Cannot enter unauthorized state
Secure System - Example
Unauthorized
states
A
B
C
Authorized
states

Is this Finite State Machine Secure?





A is start state ?
B is start state ?
C is start state ?
How can this be made secure if not?
Suppose A, B, and C are authorized states ?
D
Additional Definitions:


Security breach: system enters an unauthorized state
Let X be a set of entities, I be information.


I has confidentiality with respect to X if no member of X can obtain
information on I
I has integrity with respect to X if all members of X trust I




Trust I, its conveyance and protection (data integrity)
I maybe origin information or an identity (authentication)
I is a resource – its integrity implies it functions as it should
(assurance)
I has availability with respect to X if all members of X can access I

Time limits (quality of service)
Confidentiality Policy

Also known as information flow policy




Transfer of rights
Transfer of information without transfer of rights
Temporal context
Highly developed in Military/Government
Integrity Policy

Defines how information can be altered




Examples:



Entities allowed to alter data
Conditions under which data can be altered
Limits to change of data
Purchase over $1000 requires signature
Check over $10,000 must be approved by one person
and cashed by another
 Separation of duties : for preventing fraud
Highly developed in commercial world
Availability Policy



An availability policy describes what services
must be provided.
It may present parameters within which the
service will be accessible.
It may require a level of service.
Security Mechanism


Policy describes what is allowed and/or what
is not.
Mechanism


Example Policy: Students should not copy
homework.


An entity/procedure that enforces (part of) policy.
Mechanism: Disallow access to files owned by
other users.
Does mechanism enforce policy?
Security Model


Security Policy: What is/isn’t authorized
Problem: Policy specification often informal



Implicit vs. Explicit
Ambiguity
Security Model: Model that represents a
particular policy (policies)


Model must be explicit, unambiguous
Abstract details for analysis
High-Level Policy Languages

High-level: Independent of mechanisms



Constraints expressed independent of enforcement
mechanism
Constraints restrict entities, actions
Constraints expressed unambiguously


Requires a precise language, usually a mathematical,
logical, or programming-like language
Example: Domain-Type Enforcement Language



Subjects partitioned into domains
Objects partitioned into types
Each domain has a set of rights over each type
Example: Web Browser



Goal: restrict actions of Java programs that
are downloaded and executed under control
of web browser
Language specific to Java programs
Expresses constraints as conditions
restricting invocation of entities
Expressing Constraints

Entities are classes, methods



Operations



Class: set of objects that an access constraint
constrains
Method: set of ways an operation can be invoked
Instantiation: s creates instance of class c: s ├ c
Invocation: s1 executes object s2: s1 |→s2
Access constraints


deny(s op x) when b
when b is true, subject s cannot perform op on
(subject or class) x; empty s means all subjects
Sample Constraints


Downloaded program cannot access password
database file on UNIX system
Program’s class and methods for files:
class File {
public file(String name);
public String getfilename();
public char read();
….

Constraint:
deny(|→ file.read) when
(file.getfilename() == “/etc/passwd”)
Low-Level Policy Languages

Low-level: close to mechanisms


A set of inputs or arguments to commands that set, or
check, constraints on a system
Example: Tripwire: Flags what has changed


Configuration file specifies settings to be checked
History file keeps old (good) example
Confidentiality Policy

Also known as information flow policy



Integrity is secondary objective
Eg. Military mission date
Bell-LaPadula Model


Formally models military requirements
 Information has sensitivity levels or classification
 Subjects have clearance
 Subjects with clearance are allowed access
Multi-level access control or mandatory access control
Bell-LaPadula: Basics

Mandatory access control





Entities are assigned security levels
Subject has security clearance L(s) = ls
Object has security classification L(o) = lo
Simplest case: Security levels are arranged in a
linear order li < li+1
Example
Top secret > Secret > Confidential >Unclassified
“No Read Up”


Information is allowed to flow up, not down
Simple security property:

-
-
s can read o if and only if
 lo ≤ ls and
 s has read access to o
Combines mandatory (security levels) and
discretionary (permission required)
Prevents subjects from reading objects at higher
levels (No Read Up rule)
“No Write Down”


Information is allowed to flow up, not down
*property

-
-
s can write o if and only if
 ls ≤ lo and
 s has write access to o
Combines mandatory (security levels) and
discretionary (permission required)
Prevents subjects from writing to objects at lower
levels (No Write Down rule)
Example
security level
subject
object
Top Secret
Tamara
Personnel Files
Secret
Samuel
E-Mail Files
Confidential
Claire
Activity Logs
Unclassified
Ulaley
Telephone Lists
• Tamara can read which objects? And write?
• Claire cannot read which objects? And write?
• Ulaley can read which objects? And write?
Access Rules

Secure system:


One in which both the properties hold
Theorem: Let Σ be a system with secure
initial state σ0, T be a set of state
transformations


If every element of T follows rules, every state σi
secure
Proof - induction
Categories


Total order of classifications not flexible enough
 Alice cleared for missiles; Bob cleared for warheads; Both
cleared for targets
Solution: Categories
 Use set of compartments (from power set of compartments)
 Enforce “need to know” principle
 Security levels (security level, category set)



(Top Secret, {Nuc, Eur, Asi})
(Top Secret, {Nuc, Asi})
Combining with clearance:
 (L,C) dominates (L’,C’)  L’ ≤ L and C’  C
 Induces lattice of security levels
Lattice of categories
{Nuc, Eur, Us}


Examples of levels

(Top Secret, {Nuc,Asi}) dom
(Secret, {Nuc})

(Secret, {Nuc, Eur}) dom
(Confidential, {Nuc,Eur})

(Top Secret, {Nuc}) dom
(Confidential, {Eur})
{Nuc, Eur}
{Nuc}
{Nuc, Us}
{Eur}
Bounds




Greatest lower,
Lowest upper
glb of {X, Nuc, Us} & {X, Eur,
Us}?
lub of {X, Nuc, Us} & {X, Eur,
Us}?
{}
{Eur, Us}
{Us}
Access Rules

Simple Security Condition: S can read O if and only
if



*-Property: S can write O if and only if




S dominate O and
S has read access to O
O dom S and
S has write access to O
Secure system: One with above properties
Theorem: Let Σ be a system with secure initial state
σ0, T be a set of state transformations

If every element of T follows rules, every state σi secure
Problem: No write-down
Cleared subject can’t communicate to non-cleared subject
 Any write from li to lk, i > k, would violate *-property
 Subject at li can only write to li and above
 Any read from lk to li, i > k, would violate simple security
property
 Subject at lk can only read from lk and below
 Subject at level i can’t write something readable by
subject at k
 Not very practical
A solution: each subject has a maximum security level and
a current security level. A subject may decrease its
security level from maximum in order to communicate
with entities at lower security levels.
Integrity Policy Requirements
1.
2.
3.
4.
5.
Commercial requirements differ from military requirements in their
emphasis on preserving data integrity.
Users will not write their own programs, but will use existing
production programs and databases.
Programmers will develop and test programs on a nonproduction
system; if they need access to actual data, they will be given
production data via a special process, but will use it on their
development system.
A special process must be followed to install a program from the
development system onto the production system.
The special process in requirement 3 must be controlled and audited.
The managers and auditors must have access to both the system
state and the system logs that are generated.
Integrity Policy: Principles of
operation

These requirements induce principles of operation:
 Separation of Duty: Single person should not be allowed to carry
out all steps of a critical function
 Moving a program from Dev. to Prod. system
 Developer and Certifier (installer) of a program
 Authorizing checks and cashing it
 Separation of function
 Do not process production data on development system
 Auditing
 Emphasis on recovery and accountability
 Controlled/audited process for updating code on production
system
Biba’s Integrity Policy Model

Based on Bell-LaPadula (a mathematical dual of BL)


Subject, Objects
Integrity Levels with dominance relation
 Higher levels



more reliable/trustworthy
More accurate
Information transfer path:
Sequence of subjects, objects where


s i r oi
si w oi+1
Policies

Low-Water-Mark Policy




Ring Policy




sro
s w o  i(o) ≤ i(s)
s1 x s2  i(s2) ≤ i(s1)
allows any subject to read any object
(same as above)
s r o  i(s) ≤ i(o)
s w o  i(o) ≤ i(s)
s1 x s2  i(s2) ≤ i(s1)
(no read-down)
(no write-up)
Biba’s Model: Strict Integrity Policy (dual of Bell-LaPadula)




s w o  i(o) ≤ i(s)
prevents writing to higher level
s r o  i’(s) = min(i(s), i(o))
drops subject’s level
s1 x s2  i(s2) ≤ i(s1) prevents executing higher level objects
Theorem for each:

If there is an information transfer path from object o1 to object on+1, then the
enforcement of the policy requires that i(on+1) ≤ i(o1) for all n>1
Chinese Wall Model

Supports confidentiality and integrity, i.e. a hybrid policy



Information can’t flow between items in a Conflict of Interest set
Applicable to environment of stock exchange or investment house
Models conflict of interest


Objects: items of information related to a company
Company dataset (CD): contains objects related to a single
company


Written CD(O)
Conflict of interest class (COI): contains datasets of companies in
competition


Written COI(O)
Assume: each object belongs to exactly one COI class
Example
Bank COI Class
Bank of America
Gasoline Company COI Class
Shell Oil
Standard Oil
Union ’76
ARCO
a
Citibank
Bank of the
West
a
CW-Simple Security Property
(Read rule)

CW-Simple Security Property
 s can read o  one of the following holds
  o’  PR(s) such that CD(o’) = CD(o)
  o’, o’  PR(s)  COI(o’)  COI(o), or
 o has been “sanitized”
(o’  PR(s) indicates o’ has been previously read by s)
 Public information may belong to a CD
 As is publicly available, no conflicts of interest arise
 So, should not affect ability of analysts to read
 Typically, all sensitive data removed from such information
before it is released publicly (called sanitization)
Writing





Anthony, Susan work in the same trading
house
Anthony can read BankOfAmercia’s CD,
Susan can read Bank CitiBanks’s CD,
Both can read ARCO’s CD
If Anthony could write to Gas’ CD, Susan can
read it

Hence, indirectly, she can read information from
BankOfAmercia’s CD, a clear conflict of interest
CW-*-Property (Write rule)

CW-*- Property
 s can write o both of the following conditions hold.



The CW-simple security condition permits S to read O.

For all unsanitized objects o’, s can read o’  CD(o’) = CD(o)
Says that s can write to an object if all the (unsanitized)
objects it can read are in the same dataset
Anthony can read both CDs hence condition 1 is met
He can read unsanitized objects of BankOfAmercia, hence
condition 2 is false
 Hence Anthony can’t write to objects in ARCO’s CD.
Role Based Access Control
http://csrc.nist.gov/groups/SNS/rbac/


Access control in
organizations is
based on “roles
that individual
users take on as
part of the
organization”
A role is “is a
collection of
permissions”
RBAC

Access depends on function, not identity

Example: Allison is bookkeeper for Math Dept.
She has access to financial records. If she leaves
and Betty is hired as the new bookkeeper, Betty
now has access to those records. The role of
“bookkeeper” dictates access, not the identity of
the individual.
Advantages of RBAC

Allows Efficient Security Management






Administrative roles, Role hierarchy
Principle of least privilege allows minimizing damage
Separation of Duties constraints to prevent fraud
Allows grouping of objects
Policy-neutral - Provides generality
Encompasses DAC and MAC policies
RBAC
Users
Permission
Users
Permissions
u1
o1
u1
o1
o2
u2
o2
om
un
om
Manager
Senior
Administrator
Senior
Engineer
Administrator
Engineer
Employee
u2
Role
r
un
n+m
assignments
nm
assignments
(a)
(b)
RBAC (NIST Standard)
PA
UA
Users
Roles
Operations
Objects
Permissions
user_sessions
(one-to-many)
role_sessions
(many-to-many)
Sessions
An important difference from classical models is that
Subject in other models corresponds to a Session in RBAC
Core RBAC (relations)











Permissions = 2Operations x Objects
UA ⊆ Users x Roles
PA ⊆ Permissions x Roles
assigned_users: Roles  2Users
assigned_permissions: Roles  2Permissions
Op(p): set of operations associated with permission p
Ob(p): set of objects associated with permission p
user_sessions: Users  2Sessions
session_user: Sessions  Users
session_roles: Sessions  2Roles
 session_roles(s) = {r | (session_user(s), r)  UA)}
avail_session_perms: Sessions  2Permissions
RBAC with
General Role Hierarchy
RH
(role hierarchy)
PA
UA
Users
Roles
Operations
Objects
Permissions
user_sessions
(one-to-many)
role_sessions
(many-to-many)
Sessions
RBAC with
General Role Hierarchy

authorized_users: Roles 2Users
authorized_users(r) = {u | r’ ≥ r &(r’, u)  UA)

authorized_permissions: Roles 2Permissions
authorized_permissions (r) = {p | r’ ≥ r &(p, r’)  PA)

RH ⊆ Roles x Roles is a partial order


called the inheritance relation
written as ≥.
(r1 ≥ r2)  authorized_users(r1) ⊆ authorized_users(r2) &
authorized_permisssions(r2) ⊆ authorized_permisssions(r1)
Example
Manager
pxe, 5py
Senior
Administrator
pa, pb
e
p3x, e
p4y
Senior
Engineer
px,x py
e
p1x, e
p2y
Administrator
px, py
Engineer
Employee
p1, p2
authorized_users(Employee)?
authorized_users(Administrator)?
authorized_permissions(Employee)?
authorized_permissions(Administrator)?
Constrained RBAC
RH
(role hierarchy)
Static
Separation
of Duty
PA
UA
Users
Roles
Operations
Objects
Permissions
user_sessions
(one-to-many)
Sessions
Dynamic
Separation
of Duty
Static Separation of Duty


SSD ⊆2Roles x N
In absence of hierarchy


Collection of pairs (RS, n) where RS is a role set, n ≥ 2;
for all (RS, n)  SSD, for all t ⊆RS:
|t| ≥ n  ∩rt assigned_users(r)= 
In presence of hierarchy

Collection of pairs (RS, n) where RS is a role set, n ≥ 2;
for all (RS, n)  SSD, for all t ⊆RS:
|t| ≥ n  ∩rt authorized_uers(r)= 
Dynamic Separation of Duty

DSD ⊆2Roles x N




Collection of pairs (RS, n) where RS is a role set,
n ≥ 2;
A user cannot activate n or more roles from RS
Formally?? [HW3?]
What if both SSD and DSD contains (RS, n)?



Consider (RS, n) = ({r1, r2, r3}, 2)?
If SSD – can r1, r2 and r3 be assigned to u?
If DSD – can r1, r2 and r3 be assigned to u?
MAC using RBAC
M1
H
HR
LW
BLP
Read Roles
M1R (same lattice) M2R
Write Roles
M1W (inverse lattice) M2W
LR
HW
L
M2
Transformation rules
• R = {L1R, L2R,…, LnR, L1W, L2W,…, LnW}
• Two separate hierarchies for {L1R, L2R,…, LnR} and { L1W, L2W,…, LnW}
• Each user is assigned to exactly two roles: xR and LW
• Each session has exactly two roles yR and yW
• Permission (o, r) is assigned to xR iff (o, w) is assigned to xW)
RBAC’s Benefits
Summary

Policy describes what is allowed in a system.

Confidentiality policies


Integrity policies


Bell-LaPadula model
Biba’s model
Hybrid policies


Chinese Wall model
Role-Based Access Control (RBAC) Model