Computer Security
Integrity Policies
7/28/2017
1
Integrity Policies
Commercial requirement
• Users should not write their own programs
• Programmers will develop and test programs on a non
production system.
• A special process must be followed to install a program from
the development system onto the production system.
• This must be controlled and audited.
• Managers and auditors must have access to both the
system state and log state.
7/28/2017
2
Integrity Policies
Goals
•
Separation of duties
–
•
If two or more steps are required to perform a critical function at least two
people should perform the steps.
Separation of function
–
–
•
Developers do not develop new programs on production systems
Developers do not process production data on production systems
Auditing
–
–
7/28/2017
Commercial systems emphasize recovery and accountability
Auditing involves analyzing systems to determine what actions took place
and who was involved.
3
Biba Integrity model
Basically a dual of the Bell-LaPadula model.
We have a subject set S, an object set O, a set of
integrity levels I, and a relation  on I.
Let i : SO I return the integrity level,
Relations
•
•
•
7/28/2017
r : ability to read an object
w : ability to write an object
x : ability to execute a subject
4
Information transfer path
A Information transfer path is a sequence of
objects
o1, … , on+1
and a corresponding sequence of subject
s1, … , sn
such that sj r oj and sj w oj+1 for all i
7/28/2017
5
Low-Water-Mark Policy
1. s S can write to o O iff i (o)  i (s) .
2. If s S reads o O then i ’(s)= min(i (s) ,i (o)), where i ’(s) is the
integrity level of s after the read.
3. s1 S can execute s2 S iff i (s2)  i (s1) .
So
• write up is prevented (prevents implant of corrupted data)
• Integrity level drops on read access to lower level objects
(prevents contaminating the subject: relying on less trustworthy
data)
• execute up is prevented.
7/28/2017
6
Low-Water-Mark Policy
Theorem: If there is an information path from o1 O
to on+1 O , then enforcement of the low-water-mark
policy requires that i (on+1)  i (o1) for all i>n.
Proof
The integrity level cannot go up. Proof by induction.
7/28/2017
7
Low-Water-Mark Policy
Problem
The integrity level of a subject is non-increasing,
resulting in some subjects being eventually unable to
access certain objects.
7/28/2017
8
Ring Policy
This ignores indirect modifications and
focuses on direct modifications.
•
s S can write to o O iff i (o)  i (s) .
•
•
s S can read any o O.
s1S can execute s2 S iff i (s2)  i (s1) .
Difference: Subjects can read any object.
7/28/2017
9
Biba’s strict integrity Policy
1.
2.
3.
s S can write to o O iff i (o)  i (s) .
s S can read o O iff i (s)  i (o) .
s1 S can execute s2 S iff i (s2)  i (s 1) .
So
•
write up is prevented
•
read down is prevented (prevents relying on less trustworthy data)
•
execute up is prevented.
7/28/2017
10
Lipner’s Integrity Matrix Model
Combines BLP and Biba
Two basic Security levels
•
•
Audit Manager (AM): system and management functions
System Low (SL): any process can read info at this level.
Five categories
•
•
•
•
•
Development (D)
Production Code (PC)
Production Data (PD)
System Development (SD)
Software Tools (T)
7/28/2017
11
Lipner’s Integrity Matrix Model
Users
Ordinary users
Application Developers
System Programmers
System Managers & Auditors
System Controllers
Clearance levels
(SL, {PC,PD})
(SL, {D,T})
(SL, {SD,T})
(AM, {D,PC,PD,ST,T})
(SL, {D,PC,PD,ST,T}) and downgrade privileges.
Objects
Class
Development code/test data
(SL, {D,T})
Production Code
(SL, {PC})
Production Data
(SL, {PC,PD})
Software Tools
(SL,{T})
System Programs
(SL, {})
System programs in modification(SL,{SD,T})
System and Application logs
(AM, {appropriate categories})
7/28/2017
12
Lipner’s full Model
Users
Security clearance
Integrity clearance
Ordinary users
Application Developers
System Programmers
System Managers & Auditors
System Controllers
Repair
(SL, {SP})
(SL, {SD})
(SL, {SSD})
(AM, {D,PC,PD,ST,T})
(SL, {SP,SD}) & downgrade privileges
(SL, {SP})
(ISL, {IP})
(ISL,{ID})
(ISL,{ID})
(ISL,{IP,ID})
(ISP,{IP,ID})
(ISL,{IP})
Objects
Security level
Integrity level
Development code/test data
(SL, {SD})
Production Code
(SL, {SP})
Production Data
(SL, {SP})
Software Tools
(SL,{})
System Programs
(SL, {})
System programs in modification(SL,{SSD})
System and Application logs
(AM, {appropriate categories})
Repair
(SL, {SP})
(ISL,{IP})
(IO,{IP})
(ISL,{IP})
(IO,{ID})
(ISP,{IP,ID})
(ISL,{ID})
(ISL,{})
(ISL,{IP})
Three new integrity classifications: ISP (system program)  IO (operational)  ISL (system low)
Two integrity categories: ID (developers) IP (producers)
7/28/2017
13
Lipner’s full Model --- exercise
Users
Ordinary users
Application Developers
System Programmers
System Managers & Auditors
System Controllers
Repair
Security clearance
(SL, {SP})
(SL, {SD})
(SL, {SSD})
(AM, {D,PC,PD,ST,T})
(SL, {SP,SD}) & downgrade privileges
(SL, {SP})
Objects
Security level
Development code/test data
(SL, {SD})
Production Code
(SL, {SP})
Production Data
(SL, {SP})
Software Tools
(SL,{})
System Programs
(SL, {})
System programs in modification(SL,{SSD})
System and Application logs
(AM, {appropriate categories})
Repair
(SL, {SP})
Integrity clearance
(ISL, {IP})
(ISL,{ID})
(ISL,{ID})
(ISL,{IP,ID})
(ISP,{IP,ID})
(ISL,{IP})
Integrity level
(ISL,{IP})
(IO,{IP})
(ISL,{IP})
(IO,{ID})
(ISP,{IP,ID})
(ISL,{ID})
(ISL,{})
(ISL,{IP})
For read access: s(subject)  s(object) & i(subject)  i(object)
Controllers do not have read access to development code, or production code
For write access: s(subject)  s(object) & i(subject)  i(object)
Controllers do have read access to development code and production code
Who can help the controllers move development code to production code?
7/28/2017
14
Reminder:The Bell-LaPadula
model
ss-property:
(s,o,p) SOP satisfies the ss-property relative
to the security level f iff one of the following holds:
a.
p = e or p = a
b.
p = r or p = w and fc(s) dom fo(o).
Also DAC!
7/28/2017
15
Reminder: The Bell-LaPadula
model
Define b(s: p1,…,pn) to be the set of objects that s
has access to.
*-property:
For each sS the following hold:
a. b(s:a) ≠  [o b(s:a) [fc(o) dom fc(s)] ] (write-up)
b. b(s:w) ≠  [o b(s:w) [fc(o) = fc(s)] ] (equality for read)
c. b(s:r) ≠  [o b(s:r) [fc(s) dom fo(o)] ] (read-down)
Also DAC!
7/28/2017
16
Lipner’s Integrity Matrix Model
Lipner’s model combines Biba and Bell-LaPadula.
Bell-LaPadula model:
•
Simple security property
•
* property
For example:
an ordinary user can execute production code; if he needs to
alter production data, the *-property dictates that the data
be in (System Low, {Production Code, Production Data}).
7/28/2017
17
Lipner’s Integrity Matrix Model
Objects
Class
Development code/test data
(SL, {D,T})
Production code
(SL, {PC})
Production data
(SL, {PC,PD})
Software tools
(SL, {T})
System programs
(SL, {})
System programs in modification (SL, {SD,T})
System and application logs
(AM, {appropriate categories})
Logs are append only. By the *-property their class must dominate
those of the subjects that write to them
7/28/2017
18
The Clark-Wilson (CW) Model
This model addresses data integrity requirements for
commercial applications, e.g. bank transactions.
Integrity requirements are divided into,
• internal consistency: properties of the internal state
that can be enforced by the computer system.
• external consistency: the relation of the internal state to the real world:
enforced by means outside the system,
e.g. auditing.
7/28/2017
19
The CW Model
Integrity is enforced by,
• well formed transactions: data items can be
manipulated only by a specific set of programs;
users have access to programs rather than data
items.
• separation of duties: users have to collaborate to
manipulate data and collude to penetrate the
system.
7/28/2017
20
The CW Model
In the Clark-Wilson model,
• Subjects must be identified and authenticated,
• Objects can be manipulated only by a restricted set of
programs,
• Subjects can execute only a restricted set of programs,
• A proper audit log has to be maintained,
• The system must be certified to work properly.
7/28/2017
21
The CW Model
In the Clark-Wilson model,
• Subjects must be identified and authenticated,
• Objects can be manipulated only by a restricted set of
programs,
• Subjects can execute only a restricted set of programs,
• A proper audit log has to be maintained,
• The system must be certified to work properly.
7/28/2017
22
The CW Model
In the Clark-Wilson model
• Data items are called Constrained Data Items (CDIs),
• Data items not subject to integrity controls are Unconstrained Data Items
(UDIs),
• A set of integrity constraints constrain the values CDIs,
• CDIs can only be manipulated by Transformation Procedures (TPs)
• The integrity of a state is checked by Integrity Verification Procedure
(IVPs)
7/28/2017
23
The CW Model
Security procedures are defined by 5 Certification rules:
1.
2.
3.
4.
5.
Integrity Verification Procedures must ensure that all Constrained
Data Items are in a valid state when the IVP is run.
Transformation Procedures must transform valid CDIs into valid CDIs.
The “allowed” access relations must meet the requirements imposed
by the principle of separation of duty.
All TPs must write to an append-only CDI log.
Any TP that takes a UDI as input must either convert it into
a CDI or reject it.
7/28/2017
24
The CW Model
Integrity is enforced by the 4 Enforcement rules
1.
2.
3.
4.
The system must maintain and protect the certified relations:
(TPi:CDIa,CDIb, … ) and ensure that only Transformation Procedures
certified to run on a Constrained Data Item manipulate that CDI.
The system must maintain and protect the list of entries:
(User,TPi:CDIa,CDIb, … ) specifying the TPs that users can execute.
The system must authenticate each user requesting to execute a TP.
Only the certifier of a TP may modify the respective entities associated
with that TP. No certifier of a TP may have execute permission with
respect to that entity.
7/28/2017
25