Upload
marjorie-welch
View
220
Download
0
Embed Size (px)
Citation preview
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
Overview Background Biba’s models
Strict Integrity policy Low-Water-Mark policy Combining Biba and BLP
Lipner’s model Clark-Wilson model
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
Overview Background Biba’s models
Strict Integrity policy Low-Water-Mark policy Combining Biba and BLP
Lipner’s model Clark-Wilson model
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
Overview Background Biba’s models
Strict Integrity policy Low-Water-Mark policy Combining Biba and BLP
Lipner’s model Clark-Wilson model
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
Overview Background Biba’s models
Strict Integrity policy Low-Water-Mark policy Combining Biba and BLP
Lipner’s model Clark-Wilson model
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