Transcript ISA 562 Internet Security Theory and Practice Integrity Policies

ISA 562 Internet Security
Theory and Practice
Integrity Policies
Chapter 6 of Bishop’s book
1
Overview


Background
Biba’s models





Strict Integrity Policy
Low-Water-Mark Policy
Combining Biba and BLP
Lipner’s model
Clark-Wilson model
2
Background (1)
Business tends to Focus on integrity rather than
confidentiality
Subjects 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)
3
Background (2)
Integrity policy vs. confidentiality policy

Integrity levels ≠ security levels (they may overlap)
A General with secret clearance is trusted
A 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:
secret


unclassified
trusted

untrusted
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)
4
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)
Biba
 or
dominate
information
flow
High Integrity
Some integrity
Suspicious
Garbage
5
Biba = BLP Upside-down


BLP=read-down and write-up,
Biba= read-up and write-down
Biba
information
flow
High Integrity
read
Some integrity
Suspicious
write
Garbage
6
Notation
S=Subjects, O=objects, I= integrity levels
i1 ≤ i2 says i2 dominates i1
min(i1 , i2 ) is the lesser of i1 and i2
i (s), i (o) = integrity level of s  S and o  O.
sro
says s can read o
swo
says s can write o,
s x s’
says s can execute s’
7
Strict Integrity Policy (formal)
Biba’s Model
For any s  S and o  O
1.
s r o iff I (s) ≤ I (o)
2.
s w o iff I (o) ≤ I (s)
3.
s1 x s2 iff I (s2) ≤ I (s1)



(read-up)
(write-down)
(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
8
Information Flow
An 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 writes
o1
o2
s1
o3
s2
read
On
s3
……
write
On+1
Sn
information flow
9
Information Flow Result

o1
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.

s1
No object can be corrupted, either directly (write up) or
indirectly (first read down then write equal)
high integrity
o2
s2
o3
s3
…… On
Sn
read
write
On+1
low integrity
10
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 induction
For 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
11
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
12
Overview


Background
Biba’s models





Strict Integrity policy
Low-Water-Mark policy
Combining Biba and BLP
Lipner’s model
Clark-Wilson model
13
Low Water Mark Policy
Motivation:
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
14
Subject Low Water Mark Policy
Idea: 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.
2.
3.
s r o and s reads o implies i (s) = min(i (s), i (o))
s w o iff i (o) ≤ i (s)
(write-down)
s x s2 iff i (s2) ≤ i (s1)
(execute-up)
15
Object Low-Water-Mark Policy
Idea: s can write up, but the integrity level of any
object s writes will drop
Example: 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.
2.
3.
s r o iff i (s) ≤ i (o)
(read-up)
s w o and s writes o implies i (o) = min(i (s), i (o))
s x s2 iff i (s2) ≤ i (s1)
(execute-up)
16
Information Flow Result
Theorem: With the subject/object low-water-mark
policy, the information flow result also holds
 i (on+1) ≤ i (o1) holds in the following cases:
subject low-water-mark policy
prevents s1 from corrupting o2
s1
o2
s1
o2
object low-water-mark policy
detects the corruption of o2
o1
o1
read
write
o2
o1
s1
o1
s1
o2
17
Problems

With subject low-water-mark policy, subjects’
integrity levels never increases


With object low-water-mark policy, objects can be
easily corrupted


After some actions, no subject will be able to access
objects at high integrity levels
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)
18
Overview


Background
Biba’s models





Strict Integrity policy
Low-Water-Mark policy
Combining Biba and BLP
Lipner’s model
Clark-Wilson model
19
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
20
Combining Biba and BLP (Cont’d)

What if they are exactly reversed?



Secret and un-trusted: a downloaded software is untrusted 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
21
Overview


Background
Biba’s models





Strict Integrity policy
Low-Water-Mark policy
Combining Biba and BLP
Lipner’s model
Clark-Wilson model
22
Typical Commercial Requirements
1.
2.
3.
4.
5.
Users do not write their own programs, but use existing
production programs and databases.
Programmers develop and test programs on a nonproduction 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.
A special process must be followed to transfer a program
from the development system onto the production
system.
The special process of requirement 3 must be controlled
and audited.
The managers and auditors must have access to both
the system state and system logs that are generated.
23
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
24
The BLP Part

2 security clearances/classifications



3 Security categories




AM (Audit Manager): system audit, management
functions
SL (System Low): any process can read at this level
SP (Production): production code, data
SD (Development): same as D
SSD (System Development): same as old SD
Security level=(classification,category)
25
The Biba Part

3 integrity classifications




2 integrity categories



ISP (System Program): for system programs
IO (Operational): production programs, development
software
ISL (System Low): users get this on log in
ID (Development): development entities
IP (Production): production entities
Integrity level=(classification,category)
26
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 (AM, { SP, SD, SSD })
auditors
(ISL, { IP, ID})
System controllers
(SL, { SP, SD }) and
downgrade privilege
(ISP, { IP, ID})
Repair
(SL, { SP })
(ISL, { IP })
27
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 })
28
The Lattice (Lipner’s Lattice)
Only 9 out of 192
labels are used
S:
O:
System Managers
Audit Trail
S:
S:
S:
O:
Repair
Production Users
Production Data
O:
Repair Code
S:
O:
LEGEND
S:
O:
System Control
Application
Programmers
Development
Code and Data
O:
Production Code
O:
System Programs
S:
O:
Subjects
Objects
System
Programmers
System Code in
Development
O:
Tools
29
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)
30
Overview


Background
Biba’s models





Strict Integrity policy
Low-Water-Mark policy
Combining Biba and BLP
Lipner’s model
Clark-Wilson model
31
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!
32
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
33
Elements of the model


Users
CDIs



Transformation Procedures
(like commands in Access Control Matrices, but for
debit, credit)
IVPs

Unconstrained Data Items
(data that don’t need integrity)
TPs


(data that need integrity)
UDIs

Active agents
Constrained Data Items
Integrity Verification Procedures
(run periodically to check integrity of CDIs)
34
How The Elements Interact
Verify integrity
Transform: valid  valid
IVPs
CDIs
USERS
TPs
UDIs
35
Enforcement Rules at a Glance
Certification Rules
CR1 IVPs verify CDI integrity
CR2 TPs preserve CDI integrity
CR3 Separation of duties for ER2
CR4 TPs write to log
CR5 TPs upgrade UDIs to CDIs
Enforcement Rules
ER1 CDIs changed only by authorized TP
ER2 TP run only by authorized users
ER3 Users are authenticated
ER4 Authorizations changed only by certifiers
36
Certification Rules 1,2,3
CR1
CR2
When any IVP is run, it must ensure all CDIs are in a
valid state
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
37
Certification Rules 4 and 5
CR4 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
38
Enforcement Rules 1 and 2
ER1 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
39
Enforcement Rules 3 and 4
ER3 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
40
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
41