1. Chapter 5: Confidentiality Policies
Overview
What is a confidentiality model
Goals of confidentiality model
Reading and writing information
Bell – LaPadula Model
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

2. Confidentiality Policy
Goal: prevent the unauthorized disclosure of information
Deals with information flow
Integrity incidental
Multi-level security models are best-known examples
Bell-LaPadula Model basis for many, or most, of these
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

3. Bell-LaPadula Model, Step 1
Security levels arranged in linear ordering
Top Secret: highest
Secret
Confidential
Unclassified: lowest
Levels consist of security clearance L(s)
Objects have security classification L(o)
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

4. Example security level subject object Top Secret Tamara
Personnel Files
Secret
Samuel
Files
Confidential
Claire
Activity Logs
Unclassified
Ulaley
Telephone Lists
Tamara can read all files
Claire cannot read Personnel or Files
Ulaley can only read Telephone Lists
11/9/2018
Introduction to Computer Security
©2004 Matt Bishop

5. Reading Information Information flows up, not down
“Reads up” disallowed, “reads down” allowed
Simple Security Condition (Step 1)
Subject s can read object o iff L(o) ≤ L(s) and s has permission to read o
Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)
Sometimes called “no reads up” rule
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

6. What IF
security level
subject
object
Top Secret
Tamara
Personnel Files
Secret
Samuel
Files
Confidential
Claire
Activity Logs
Unclassified
Ulaley
Telephone Lists
Tamara copies Personnel Files to the Activity Log AND then give Claire permission to read Personnel Files?
Tamara is writing from higher security level to lower security level
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

7. Writing Information Information flows up, not down *-Property (Step 1)
“Writes up” allowed, “writes down” disallowed
*-Property (Step 1)
Subject s can write object o iff L(s) ≤ L(o) and s has permission to write o
Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)
Sometimes called “no writes down” rule
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

8. Basic Security Theorem, Step 1
If a system is initially in a secure state, and every transition of the system satisfies the simple security condition,
step 1(NO read up), and
the *-property, step 1 (NO write down),
then every state of the system is secure
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

9. Bell-LaPadula Model, Step 2
Expand notion of security level to include categories
Category specifies need to know
Security level is (clearance, category set)
Examples
Categories: NUC, EUR and ASI
( Top Secret, { NUC, EUR, ASI } )
( Confidential, { EUR, ASI } )
( Secret, { NUC, ASI } )
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

10. Levels and Ordering Security levels partially ordered
Any pair of security levels may (or may not) be related by dom
“dominates” serves the role of “greater than” in step 1
“greater than” is a total ordering, though
Definition: Dominates
Security level (L,C) dom (L’, C’) if L’ ≤ L and C’ ⊆ C
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

11. Reading Information Information flows up, not down
“Reads up” disallowed, “reads down” allowed
Simple Security Condition (Step 2)
Subject s can read object o iff L(s) dom L(o) and s has permission to read o
Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)
Sometimes called “no reads up” rule
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

12. Writing Information Information flows up, not down *-Property (Step 2)
“Writes up” allowed, “writes down” disallowed
*-Property (Step 2)
Subject s can write object o iff L(o) dom L(s) and s has permission to write o
Note: combines mandatory control (relationship of security levels) and discretionary control (the required permission)
Sometimes called “no writes down” rule
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

13. Basic Security Theorem, Step 2
If a system is initially in a secure state, and every transition of the system satisfies the simple security condition, step 2, and the *-property, step 2, then every state of the system is secure
Proof: induct on the number of transitions
In actual Basic Security Theorem, discretionary access control treated as third property, and simple security property and *- property phrased to eliminate discretionary part of the definitions — but simpler to express the way done here.
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

14. Problem Colonel has (Secret, {NUC, EUR}) clearance
Major has (Secret, {EUR}) clearance
Major can talk to colonel (“write up” or “read down”)
Colonel cannot talk to major (“read up” or “write down”)
Clearly absurd!
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

15. Solution Define maximum, current levels for subjects Example
maxlevel(s) dom curlevel(s)
Example
Treat Major as an object (Colonel is writing to him/her)
Colonel has maxlevel (Secret, { NUC, EUR })
Colonel sets curlevel to (Secret, { EUR })
Now L(Major) dom curlevel(Colonel)
Colonel can write to Major without violating “no writes down”
Does L(s) mean curlevel(s) or maxlevel(s)?
Formally, we need a more precise notation
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

16. Key Points Confidentiality models restrict flow of information
Bell-LaPadula models multilevel security
Cornerstone of much work in computer security
Read – allows info flow from object to subject
{includes execute}
Write – allows info flow from subject to object
{includes append}
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

17. Chapter 6: Integrity Policies
Overview
Requirements
Biba’s models
Clark-Wilson model
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

18. Overview Requirements Biba’s model Clark-Wilson model
Very different than confidentiality policies
Biba’s model
Clark-Wilson model
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

19. Requirements of Policies
Users will not write their own programs, but will use existing production programs and databases.
Programmers will develop and test programs on a non-production 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.
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

20. Principles of Operation
The following principles of operation will meet the requirements
Separation of duty
Programmer, staging area, production: errors more likely to be discovered if 2 people
Separation of function
No development of production systems. Production runs are not done on development systems
Auditing
Analyze the system to determine who did what. Logs help with this.
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

21. Biba Integrity Model
Set of subjects S, objects O, integrity levels I, relation ≤  I  I holding when second dominates first
min: I  I  I returns lesser of integrity levels
i: S  O  I gives integrity level of entity
r: S  O means s  S can read o  O
w, x defined similarly
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

22. Intuition for Integrity Levels
The higher the level, the more confidence
That a program will execute correctly
Potentially detect problems with its inputs and stop executing
That data is accurate and/or reliable
Note relationship between integrity and trustworthiness
Important point: integrity levels are not security levels
Security levels limit information flow
Integrity levels limit the modification of information
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

23. Biba’s Model Similar to Bell-LaPadula model
s  S can read o  O iff i(s) ≤ i(o)
s  S can write to o  O iff i(o) ≤ i(s)
s1  S can execute s2  S iff i(s2) ≤ i(s1)
Rules1 and 2 imply both read and write allowed if i(s) = i(o)
Add compartments and discretionary controls to get full dual of Bell-LaPadula model
Information flow result holds
Different proof, though
Actually the “strict integrity model” of Biba’s set of models
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

24. LOCUS and Biba
Goal: prevent untrusted software from altering data or other software
Approach: make levels of trust explicit
credibility rating based on estimate of software’s trustworthiness (0 untrusted, n highly trusted)
trusted file systems contain software with a single credibility level
Process has risk level or highest credibility level at which process can execute
Must use run-untrusted command to run software at lower credibility level
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

25. Clark-Wilson Integrity Model
Transaction based (property of commercial systems) – in CW data is of particular focus – note difference from Biba
Integrity defined by a set of constraints
Data in a consistent or valid state when it satisfies these
Example: Bank
D today’s deposits, W withdrawals, YB yesterday’s balance, TB today’s balance
Integrity constraint: D + YB –W = TB
Two operations (D,W) in the transaction. Must maintain consistency.
Well-formed transaction move system from one consistent state to another
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

26. Separation of duty example
Issue: who examines, certifies transactions done correctly?
Invoice processing steps: purchase order / request to payment
If one person, may pay phony invoice
Two people: more secure: both make the same mistake or collude
Computer transaction similar constraints
Certifier and implementer must be different
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

27. CW - Entities CDIs: constrained data items
Data subject to integrity controls
UDIs: unconstrained data items
Data not subject to integrity controls
IVPs: integrity verification procedures
Procedures that test the CDIs conform to the integrity constraints
TPs: transaction procedures
Procedures that take the system from one valid state to another
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

28. Example Bank A/C balances are CDI Gifts at opening of A/C are UDI
Checking to ensure accounts are balanced is IVP
Deposit, withdraw, transfers are TP
Introduction to Computer Security
©2004 Matt Bishop
11/9/2018

29. Certification Rules 1 and 2
CR1 When any IVP is run, it must ensure all CDIs are in a valid state
CR2 For some associated set of CDIs, a TP must transform those CDIs in a valid state into a (possibly different) valid state
Defines relation certified that associates a set of CDIs with a particular TP
Example: TP balance, CDIs accounts, in bank example
(B,A1), (B,A2), …(B,An) are certified relations – (B, Ax) is the balance of account x
TP that works on investment portfolio would be invalid for the checking account – hence the need for enforcement rules
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

30. Enforcement Rules 1 and 2
ER1 The system must maintain the certified relations and must ensure that only TPs certified to run on a CDI manipulate that CDI.
Every one cannot balance customer accounts. Hence the need for a rule defining “who” is allowed.
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 restrict access based on user ID (allowed relation)
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

31. Users and Rules For valid relation define -- (user, TP, {CDI set})
Relations must be certified.
CR3 The allowed relations must meet the requirements imposed by the principle of separation of duty.
ER3 The system must authenticate each user attempting to execute a TP
Type of authentication undefined, and depends on the instantiation
Authentication not required before use of the system, but is required before manipulation of CDIs (requires using TPs)
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

32. Logging All systems need to maintain logs – root cause analysis.
CR4 All TPs must append enough information to reconstruct the operation to an append-only CDI.
This CDI is the log
Auditor needs to be able to determine what happened during reviews of transactions
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

33. Handling Untrusted Input
ATM check deposit capture is UDI. Must be validated, before updating the account.
CR5 Any TP that takes as input a UDI may perform only valid transformations, or no transformations, for all possible values of the UDI. The transformation either rejects the UDI or transforms it into a CDI.
In bank, numbers entered at keyboard are UDIs, so cannot be input to TPs. TPs must validate numbers (to make them a CDI) before using them; if validation fails, TP rejects UDI
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

34. Separation of Duty In Model
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 entity associated with that TP, may ever have execute permission with respect to that entity.
Enforces separation of duty with respect to certified and allowed relations
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

35. Comparison With Requirements
Users can’t certify TPs - CR5 and ER4 enforce this. All users cannot create certified TP – cannot write programs that access production DB.
Procedural, so model doesn’t directly cover it; but special process corresponds to using TP
No technical controls can prevent programmer from developing program on production system; usual control is to delete software tools
TP does the installation on production system, trusted personnel do certification
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

36. Comparison With Requirements
4. CR4 provides logging; ER3 authenticates trusted personnel doing installation; CR5, ER4 control installation procedure
New program UDI before certification, CDI (and TP) after
Log is CDI, so appropriate TP can provide managers, auditors access
Access to state handled similarly
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

37. Comparison to Biba Biba attaches integrity rules. CW sort of similar
No notion of certification rules; trusted subjects ensure actions obey rules
Untrusted data examined before being made trusted
Clark-Wilson
Explicit requirements that actions must meet
Trusted entity must certify method to upgrade untrusted data (and not certify the data itself)
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004

38. Key Points Integrity policies deal with trust
As trust is hard to quantify, these policies are hard to evaluate completely
Look for assumptions and trusted users to find possible weak points in their implementation
Biba based on multilevel integrity
Clark-Wilson focuses on separation of duty and transactions
Introduction to Computer Security
©2004 Matt Bishop
November 1, 2004