1 ISA 562 Internet Security Theory and Practice Integrity Policies Chapter 6 of Bishop ’ s book.

1

ISA 562 Internet Security

Theory and Practice

Integrity PoliciesChapter 6 of Bishop’s book

2

Overview Background Biba’s models

Strict Integrity Policy Low-Water-Mark Policy Combining Biba and BLP

Lipner’s model Clark-Wilson model

3

Background (1)Business tends to Focus on integrity rather

than confidentialitySubjects and objects may be labeled with integrity

levels I, where i1 ≤ i2 means i2 dominates i1.

Higher level = more trustworthy = higher integrity Subject: program on Windows CD (trusted) vs.

downloaded Java applet (untrusted) Object: system logs (trusted) vs email

attachment from unknown sender (untrusted)

4

Background (2)

Integrity policy vs. confidentiality policy Integrity levels ≠ security levels (they may overlap)

A General with secret clearance is trustedA company like GE is trusted but not normally allowed to

upload military secrets (unless they have a contract)

Information flows differently: Information is disclosed (flows down) when:

Read-up: a visitor (unclassified) reads personnel files (secret) Write-down: a cryptographer (secret) writes an activity log

(unclassified) Information is corrupted (flows up) when:

Read-down: IE (trusted) opens a file having a virus (untrusted) Write-up: a downloaded Java applet (untrusted) writes

something into Windows registry (trusted)

secret

unclassified

trusted

untrusted

5

Strict Integrity policy: The Biba Model

If BLP prevents information from flowing down (disclosed)

BLP-upside-down will prevent information from flowing up (getting corrupted)

High Integrity

Some integrity

Suspicious

Garbage

or dominat

e

information flow

Biba

6

Biba = BLP Upside-down BLP=read-down and write-up, Biba= read-up and write-down

Biba

High IntegritySome

integrity

Suspicious

Garbage

information flow

write

read

7

NotationS=Subjects, O=objects, I= integrity levelsi1 ≤ i2 says i2 dominates i1min(i1 , i2 ) is the lesser of i1 and i2

i (s), i (o) = integrity level of s S and o O.s r o says s can read os w o says s can write o, s x s’ says s can execute s’

8

Strict Integrity Policy (formal)

Biba’s ModelFor any s S and o O 1. s r o iff I (s) ≤ I (o) (read-up)2. s w o iff I (o) ≤ I (s) (write-down)3. s1 x s2 iff I (s2) ≤ I (s1) (execute-up)

execute is a special type of read Why? = execution does not corrupt code!

Can add compartments and discretionary controls to get full dual of BLP

9

Information FlowAn information transfer path is a sequence of

objects o1, ..., on+1 and corresponding sequence of subjects s1, ..., sn such that si r oi and si w oi+1 for all i, 1 ≤ i ≤ n. When si r oi information flows from oi to si

When si w oi information flows from si to oi+1

Thus information can flow from o1 to on+1 along this path by successive reads and writeso1 o2 o3

……

On+

1

s1 s2 s3Sn

On

read write information flow

10

Information Flow Result If there is any information transfer path

from o1 O to on+1 O, then strict integrity policy implies that i (on+1) ≤ i (o1) holds for all n 1. No object can be corrupted, either directly (write

up) or indirectly (first read down then write equal)

o1

o2

o3

On+

1

s1

s2

s3 ……

Sn

On

read write

high integrity

low integrity

11

Theorem: Information Flow(Theorem 6.1 from Bishop) If there is an

information transfer path from o1 O to

on+1 O, then strict integrity policy implies that i (on+1) ≤ i (o1) holds for all n 1.

Proof: By inductionFor n=1:Case 1: s1 r o1 and s1 w o2 then by definition,

i (on+1) ≤ i (o1)

Case 2: s1 w o1 and s2 r o2 Is this possible? No

12

Proof continued….The inductive case:Suppose the result is true for n:Want to prove for (n+1):By the inductive hypothesis, i (on) ≤ i (o1)

Need to show i (on+1) ≤ i (o1)

Do so by proving i (on+1) ≤ i (on)

Case 1: sn+1 r on+1 and sn+1 w on+2 then by definition, i (on+1) ≤ i (on) - we are done !

Case 2: sn+1 w on+1 or sn+1 r on+2

Is this possible? No

13


Strict Integrity policy Low-Water-Mark policy Combining Biba and BLP


14

Low Water Mark PolicyMotivation:

to relax strict integrity policy but still have the information flow claim valid

Two versions: Subject low-water-mark policy relaxes the

read by allowing subjects to read down Object low-water-mark policy relaxes the

write by allowing subjects to write up

15

Subject Low Water Mark PolicyIdea: s can read down, but once it does, its integrity

level drops (so it cannot corrupt other objects)Example: After a machine reads emails infected

with worm, the machine is no longer trusted and isolated

Rules: For any s S and o O 1. s r o and s reads o implies i (s) = min(i (s), i (o))2. s w o iff i (o) ≤ i (s) (write-down)3. s x s2 iff i (s2) ≤ i (s1) (execute-up)

16

Object Low-Water-Mark PolicyIdea: s can write up, but the integrity level of

any object s writes will dropExample: After a virus is detected, whatever

files were written by the virus are no longer trusted and therefore are deleted

Rules: For any s S and o O 1. s r o iff i (s) ≤ i (o) (read-up)2. s w o and s writes o implies i (o) = min(i (s), i

(o))3. s x s2 iff i (s2) ≤ i (s1) (execute-up)

17

Information Flow ResultTheorem: With the subject/object low-water-

mark policy, the information flow result also holds i (on+1) ≤ i (o1) holds in the following cases:

read write

o1

o2s1

o1 o2s1

subject low-water-mark policy prevents s1 from corrupting o2

o1

o2

s1

o1 o2s1

object low-water-mark policy detects the corruption of o2

18

Problems With subject low-water-mark policy,

subjects’ integrity levels never increases After some actions, no subject will be able to

access objects at high integrity levels With object low-water-mark policy, objects

can be easily corrupted After some actions, all objects will be at the

lowest integrity level Implementation needs mechanisms to warn

subjects about corruption (of the subject itself or the object being written by it)

19




20

Combining Biba and BLP Important: security levels (BLP) and

integrity levels (Biba) are two different things

Whether they overlap one another depends on applications

When they do overlap, enforcement of BLP and Biba may conflict What if they are exactly the same?

See Exercise 3 in Bishop

21

Combining Biba and BLP (Cont’d)

What if they are exactly reversed? Secret and un-trusted: a downloaded software is

un-trusted and should not be read/executed by everyone

Unclassified and trusted: system binaries are trusted and can be executed by anyone

Then both rules and the levels are dual, so BLP and Biba work in the same way Read-down in BLP becomes read-up in Biba Write-up in BLP becomes write-down in Biba

22




23

Typical Commercial Requirements

1. Users do not write their own programs, but use existing production programs and databases.

2. Programmers develop and test programs on a non-production system; if they need access to production data, they are given data via a special process and can only use it on the development system.

3. A special process must be followed to transfer a program from the development system onto the production system.

4. The special process of requirement 3 must be controlled and audited.

5. The managers and auditors must have access to both the system state and system logs that are generated.

24

Lipner’s Lattice (BLP+Biba) A realistic example showing that BLP and Biba

can be combined to meet commercial requirements

How does it combine BLP and Biba? Uses disjoint sets of security levels and integrity levels BLP goes first, and adds in Biba only when necessary

25

The BLP Part 2 security clearances/classifications

AM (Audit Manager): system audit, management functions

SL (System Low): any process can read at this level

3 Security categories SP (Production): production code, data SD (Development): same as D SSD (System Development): same as old SD

Security level=(classification,category)

26

The Biba Part 3 integrity classifications

ISP (System Program): for system programs IO (Operational): production programs,

development software ISL (System Low): users get this on log in

2 integrity categories ID (Development): development entities IP (Production): production entities

Integrity level=(classification,category)

27

Subjects’ Levels at a Glance

Subjects Security Level Integrity Level

Ordinary users (SL, { SP }) (ISL, { IP })

Application developers

(SL, { SD }) (ISL, { ID })

System programmers

(SL, { SSD }) (ISL, { ID })

System managers and auditors

(AM, { SP, SD, SSD }) (ISL, { IP, ID})

System controllers (SL, { SP, SD }) and downgrade privilege

(ISP, { IP, ID})

Repair (SL, { SP }) (ISL, { IP })

28

Objects’ Levels at a Glance

Objects Security Level Integrity Level

Development code/test data

(SL, { SD }) (ISL, { IP} )

Production code (SL, { SP }) (IO, { IP })

Production data (SL, { SP }) (ISL, { IP })

Software tools (SL, ) (IO, { ID })

System programs (SL, ) (ISP, { IP, ID })

System programs in modification

(SL, { SSD }) (ISL, { ID })

System and application logs

(AM, { appropriate }) (ISL, )

Repair (SL, {SP}) (ISL, { IP })

29

The Lattice (Lipner’s Lattice)

S: RepairS: Production UsersO: Production Data

S: Application Programmers

O: Development Code and Data

S: System Programmers

O: System Code in Development

O: Repair Code

O: System Programs

O: Production Code O: Tools

S: System ManagersO: Audit Trail

S: System Control

LEGEND

S: SubjectsO: Objects

LEGEND

S: SubjectsO: Objects

Only 9 out of 192 labels are used

30

What Does it Achieve? Ordinary users can execute (read)

production code but cannot alter it Ordinary users can alter and read

production data System managers need access to all logs

but cannot change levels of objects System controllers need to install code

(hence downgrade capability) Logs are append only, so must dominate

subjects writing them These meet stated requirements

(verify if you want)

31




32

Clark-Wilson Integrity Model Time-proven accounting practices are

extrapolated to computer world Integrity policy are given as high-level rules

Remember these are policy – no need to ask “how?”

Example: Bank Objective: today’s deposits - today’s withdrawals +

yesterday’s balance = today’s balance Policy level 1: transactions must meet this

objective Policy level 2: users execute only those

transactions Policy level 3: certifiers must ensure users do so Policy level 4: logs will monitor that certifiers are

doing their job!

33

Clark-Wilson Integrity Model (Cont’d)

The key contribution is that this hierarchical structure reduces the dependency on special trusted subjects Certifiers will enforce users to run only good

transactions, and logs will in turn monitor certifiers

But who will then monitor log auditors? Trust is always needed

34

Elements of the model Users Active agents CDIsConstrained Data Items

(data that need integrity) UDIs Unconstrained Data Items

(data that don’t need integrity) TPs Transformation Procedures

(like commands in Access Control Matrices, but for debit, credit)

IVPs Integrity Verification Procedures (run periodically to check integrity of CDIs)

35

How The Elements Interact

TPs

CDIs

USERS

UDIs

IVPs

Verify integrity

Transform: valid valid

36

Enforcement Rules at a GlanceCertification RulesCR1 IVPs verify CDI integrityCR2 TPs preserve CDI integrityCR3 Separation of duties for ER2CR4 TPs write to logCR5 TPs upgrade UDIs to CDIsEnforcement RulesER1 CDIs changed only by authorized TPER2 TP run only by authorized users ER3 Users are authenticatedER4 Authorizations changed only by certifiers

37

Certification Rules 1,2,3CR1 When any IVP is run, it must ensure all CDIs are in a

valid stateCR2 For some associated set of CDIs, a TP must transform

those CDIs in a valid state into a (possibly different) valid state

A relation certified associates a set of CDIs with a particular TP Say (before1,after1), (before2, after2) …(beforen, aftern)

Example: TP withdraw money, CDIs accounts, in bank example

CR3 The allowed relations must meet the requirements imposed by the principle of separation of duty (SoD)

SoD: The principle that says different duties that may result in compromising integrity must not be permitted to be executed by the same process, subject or entity

38

Certification Rules 4 and 5CR4 All TPs must append enough information to

reconstruct the operation to append-only CDI. Because the auditor needs to be able to

determine what happened during reviews of transactions

Like write-ahead logs in databases

CR5 Any TP that takes as input a UDI and (1): either rejects the UDI or (2): transforms it into a CDI. Example: In a bank, deposit amounts entered at

keyboard are UDIs. TPs must validate numbers (to make them a CDI) before using them; if validation fails, TP rejects UDI

39

Enforcement Rules 1 and 2ER1 The system must maintain the certified

relations and must ensure that only TPs are certified to run on a CDI manipulate that CDI.

ER2 The system must associate a user with each TP and set of CDIs. The TP may access those CDIs on behalf of the associated user. The TP cannot access that CDI on behalf of a user not associated with that TP and CDI.

System must maintain, enforce certified relation System must also maintain allowed relation,

which restricts access based on user ID

40

Enforcement Rules 3 and 4ER3 The system must authenticate each user

attempting to execute a TP Authentication not required before use of the

system, but is required before manipulation of CDIs

ER4 Only the certifier of a TP may change the list of entities associated with that TP. No certifier of a TP, or of an CDI associated with that TP, may ever have execute permission on the TP/CDI Enforces separation of duty with respect to

certified and allowed relations

41

Key Points Commercial world needs integrity Biba model

Dual of BLP (or BLP-upside-down) Integrity levels distinct from security levels Information flows differently

Can be combined with BLP Lipner’s lattice combines the two to meet

commercial requirements Clark-Wilson model

Accounting approaches ported to computer world Enforcement hierarchy reduces dependency on

trusts

1 ISA 562 Internet Security Theory and Practice Integrity Policies Chapter 6 of Bishop ’ s book.

Documents