Information Security Principles & Applications

Topic 6: Security Policy Models

虞慧群

[email protected]

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

information on

I

with respect to

X

if no member of

X

can obtain

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  Entities allowed to alter data   Conditions under which data can be altered Limits to change of data Examples:  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  An entity/procedure that enforces (part of) policy.

 Example Policy: Students should not copy homework.

 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  

Class

: set of objects that an access constraint constrains

Method

: set of ways an operation can be invoked Operations  

Instantiation

:

s

creates instance of class

c

:

s Invocation

:

s

1 executes object

s

2: s1 |→s2 ├

c

Access constraints  

deny

(

s op x

) when b when

b

is true, subject

s

cannot perform

op

(subject or class)

x

; empty

s

on 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) = l s

  Object has security classification

L

(

o

) =

l o

Simplest case: Security levels are arranged in a linear order

l i

<

l i

+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 

l o

≤

l s

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 

l s

≤

l o

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

Top Secret Secret Confidential Unclassified

subject

Tamara Samuel Claire Ulaley

object

Personnel Files E-Mail Files Activity Logs 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

  Examples of levels  (Top Secret, {Nuc,Asi})

dom

(Secret, {Nuc})   (Secret, {Nuc, Eur})

dom

(Confidential, {Nuc,Eur}) (Top Secret, {Nuc}) 

dom

(Confidential, {Eur}) Bounds  Greatest lower,    Lowest upper

glb

of {X, Nuc, Us} & {X, Eur, Us}?

lub

of {X, Nuc, Us} & {X, Eur, Us}?

{Nuc, Eur} {Nuc} {Nuc, Eur, Us} {Nuc, Us} {Eur} {} {Eur, Us} {Us}

Access Rules

   

Simple Security Condition

:

S

if  

S dominate O

and

S

has read access to

O

can read

O

if and only

*-Property

:  

S

can write

O O dom S

and

S

has write access to

O

if and only if 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

i l

 Subject at

i l

to

l k

,

i

>

k

, would violate *-property can only write to

i l

and above Any read from

l k

property to

i l

,

i

>

k

, would violate simple security  Subject at

l k

can only read from

l k

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 o

i s i

w o

i

+1

Policies

    Low-Water-Mark Policy    s w o s r o

s

1 x s  2 

i

(

o

) ≤

i

(

s

) prevents writing to higher level

i’

(

s

) =

min

(

i

(

s

),

i

(

o

)) 

i

(

s

2 ) ≤

i

(

s

1 drops subject’s level ) prevents executing higher level objects Ring Policy    s r o s w o

s

1 x s 2  

i

(

o

) ≤

i

(

s

2 )

i

≤ (

s i

( )

s

1 ) allows any subject to read any object (same as above) Biba’s Model: Strict Integrity Policy (dual of Bell-LaPadula)    s r o s w o

s

1 x s  2 

i

(

s

) ≤

i

(

o

) 

i

(

o

) ≤

i

(

s

2 )

i

≤ (

s i

( )

s

1 ) (no read-down) (no write-up) Theorem for each:  If there is an information transfer path from object

o

1 enforcement of the policy requires that

i

(

o

n+1 ) ≤

i

(

o

1 to object ) for all n>1

o

n+1 , then the

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

company (CD): contains objects related to a single  Written

CD

(

O

) 

Conflict of interest class

competition (COI): contains datasets of companies in  Written

COI

(

O

)  Assume: each object belongs to exactly one

COI

class

Example

Bank COI Class Bank of America a Citibank Bank of the West Gasoline Company COI Class Shell Oil Standard Oil Union ’ 76 ARCO 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 ’ o

 has been “sanitized”

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

Manager Senior Administrator Administrator Senior Engineer Engineer Employee Users u 1 u 2 Role

r

Permission o 1 Users u 1 o 2 u 2 u n o m u n n

+

m

assignments (a)

n



m

assignments (b)

Permissions o 1 o 2 o m

RBAC (NIST Standard)

Users UA Roles PA user_sessions (one-to-many) Sessions role_sessions (many-to-many) Operations Objects Permissions An important difference from classical models is that Subject in other models corresponds to a Session in RBAC

Core RBAC (relations)

           Permissions = 2 Operations x Objects UA ⊆ Users x Roles PA ⊆ Permissions x Roles

assigned_users

: Roles

assigned_permissions

 2 Users : Roles  2 Permissions

Op

(p): set of operations associated with permission p

Ob

(p): set of objects associated with permission p

user_sessions

: Users  2 Sessions

session_user

: Sessions  Users

session_roles

: Sessions  

session_roles

(

s

) = {

r

2 Roles | (session_user(

s

),

r

) 

avail_session_perms

: Sessions  2 Permissions UA)}

RBAC with General Role Hierarchy

RH (role hierarchy) Users UA Roles PA user_sessions (one-to-many) Sessions role_sessions (many-to-many) Operations Objects Permissions

RBAC with General Role Hierarchy

  

authorized_users

: Roles  2 Users

authorized_users

(

r

) = {

u

|

r

’ ≥

r

&(

r

’,

u

) 

UA

)

authorized_permissions authorized_permissions

: Roles (r) = {

p

 2 Permissions |

r

’ ≥

r

&(

p

,

r

’) 

PA

) RH ⊆ Roles x Roles is a partial order  called the inheritance relation  (

r

1 written as ≥. ≥

r

2 ) 

authorized_users

(

r

1 ) ⊆

authorized_permisssions

(

r

2 ) ⊆

authorized_users

(

r

2 ) &

authorized_permisssions

(

r

1 )

Example

Manager

p x e , p y

Senior Administrator

p a , p b

Administrator

p x , p y p x , p y p x , p y

Employee Senior Engineer

p x , p y

Engineer

authorized_users(Employee)?

authorized_users(Administrator)?

authorized_permissions(Employee)? authorized_permissions(Administrator)?

p 1 , p 2

Constrained RBAC

Static

Separation of Duty RH (role hierarchy) Users UA Roles user_sessions (one-to-many) Sessions PA Operations Objects Permissions

Dynamic

Separation of Duty

Static Separation of Duty

  

SSD

⊆ 2 Roles x N In absence of hierarchy  Collection of pairs (

RS

,

n

) where

RS for all

(

RS

,

n

) 

SSD

,

for all t

⊆

RS

: is a role set,

n

|

t

| ≥

n

 ∩

r



t assigned_users

(r)=  ≥ 2; 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

⊆ 2 Roles x N  Collection of pairs (

RS

,

n

) where

RS n

≥ 2; is a role set,    A user cannot activate

n

or more roles from RS Formally?? [HW3?] What if both SSD and DSD contains (

RS

,

n

)?

   Consider (

RS

,

n

) = ({

r

1 ,

r

2

, r

3 }, 2)?

If SSD – can

r

1 ,

r

2

and r

3 be assigned to

u

?

If DSD – can

r

1 ,

r

2

and r

3 be assigned to

u

?

M1

MAC using RBAC

HR H BLP M2 LW M1R Read Roles (same lattice) M2R Write Roles M1W (inverse lattice) M2W L LR HW • • • • • Transformation rules R = {L 1 R, L 2 R,…, L n R, L 1 W, L 2 W,…, L n W} Two separate hierarchies for {L 1 R, L 2 R,…, L n R} and { L 1 W, L 2 W,…, L n W} 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  Bell-LaPadula model  Integrity policies  Biba’s model  Hybrid policies   Chinese Wall model Role-Based Access Control (RBAC) Model