1. Security Models and Architecture
CISSP Exam Preparation
Bernie Eydt

2. Overview Basic concepts The Models Bell-LaPadula (BLP) Biba
Clark-Wilson
Chinese Wall
Systems Evaluation

3. Basic Concepts

4. Terminology
Trusted Computing Base (TCB) – combination of protection mechanisms within a computer system
Subjects / Objects
Subjects are active (e.g., users / programs)
Objects are passive (e.g., files)
Reference Monitor – abstract machine that mediates subject access to objects
Security Kernel – core element of TCB that enforces the reference monitor’s security policy

5. Types of Access Control
Discretionary Access Control (DAC) – data owners can create and modify matrix of subject / object relationships (e.g., ACLs)
Mandatory Access Control (MAC) – “insecure” transactions prohibited regardless of DAC
Cannot enforce MAC rules with DAC security kernel
Someone with read access to a file can copy it and build a new “insecure” DAC matrix because he will be an owner of the new file.

6. Information Flow Models
Pour cement over a PC and you have a secure system
In reality, there are state transitions
Key is to ensure transitions are secure
Models provide rules for how information flows from state to state.
Information flow models do not address covert channels
Trojan horses
Requesting system resources to learn about other users

7. Access Control Models

8. Models Bell-LaPadula Biba Clark-Wilson Chinese Wall
Good brief summary on Harris p.247

9. Bell-LaPadula (BLP) Model
BLP is formal (mathematical) description of mandatory access control
Three properties:
ds-property (discretionary security)
ss-property (simple security – no “read down”)
*-property (star property – no “write down”)
A secure system satisfies all of these properties
BLP includes mathematical proof that if a system is secure and a transition satisfies all of the properties, then the system will remain secure.

10. Bell-LaPadula Model (Continued)
Honeywell Multics kernel was only true implementation of BLP, but it never took hold
DOD information security requirements currently achieved via discretionary access control and segregation of systems rather than BLP-compliant computers

11. Biba Model
Similar to BLP but focus is on integrity, not confidentiality
Result is to turn the BLP model upside down
High integrity subjects cannot read lower integrity objects (no “read down”)
Subjects cannot move low integrity data to high-integrity environment (no “write up”)
McLean notes that ability to flip models essentially renders their assurance properties useless

12. Clark-Wilson Model
Reviews distinction between military and commercial policy
Military policy focus on confidentiality
Commercial policy focus on integrity
Mandatory commercial controls typically involve who gets to do what type of transaction rather than who sees what (Example: cut a check above a certain dollar amount)

13. Clark-Wilson Model (Continued)
Two types of objects:
Constrained Data Items (CDIs)
Unconstrained Data Items (UDIs)
Two types of transactions on CDIs in model
Integrity Verification Procedures (IVPs)
Transformation Procedures (TPs)
IVPs certify that TPs on CDIs result in valid state
All TPs must be certified to result in valid transformation

14. Clark-Wilson Model (Continued)
System maintains list of valid relations of the form: {UserID, TP, CDI/UDI}
Only permitted manipulation of CDI is via an authorized TP
If a TP takes a UDI as an input, then it must result in a proper CDI or the TP will be rejected
Additional requirements
Auditing: TPs must write to an append-only CDI (log)
Separation of duties

15. Clark-Wilson versus Biba
In Biba’s model, UDI to CDI conversion is performed by trusted subject only (e.g., a security officer), but this is problematic for data entry function.
In Clark-Wilson, TPs are specified for particular users and functions. Biba’s model does not offer this level of granularity.

16. Chinese Wall Focus is on conflicts of interest.
Principle: Users should not access the confidential information of both a client organization and one or more of its competitors.
How it works
Users have no “wall” initially.
Once any given file is accessed, files with competitor information become inaccessible.
Unlike other models, access control rules change with user behavior

17. Systems Evaluation

18. Trusted Computer System Evaluation (TCSEC)
Criteria published in the Orange Book
Officially replaced by Common Criteria
Four Levels
A Verified protection A1 Verified design
B Mandatory protection B1 Labeled Security B2 Structured Protection B3 Security Domains
C Discretionary protection C1 Discretionary security C2 Controlled access
D Minimal security

19. Information Technology Security Evaluation Criteria (ITSEC)
Used primarily in Europe
Target of Evaluation (TOE) is either product or system
Two ratings
Functionality rating (F1 to F10)
Assurance Rating (E0 to E6)
Rough mapping exists between TCSEC and ITSEC (see Harris p.260)

20. Common Criteria
ISO standard evaluation criteria that combines several different criteria, including TCSEC and ITSEC
Participating governments recognize Common Criteria certifications awarded in other nations
Seven Evaluation Assurance Levels (EAL 1-7)
Utilize protection profiles (see Harris p.262)

21. Common Criteria – Evaluation Assurance Levels
Evaluation Assurance Levels - Overview
Define a scale for measuring the criteria for the evaluation of PPs (Protection Profiles) and STs (Security Targets)
Constructed using components from the assurance families
Organization
Seven hierarchically ordered EALs in a uniformly increasing scale of assurance
Bullet Slides
On bullet slides without photos or graphs, text is centered on slide.
Subtitles are 28 pt. Arial.

22. CC EALs - Reference Level Short Title US TCSEC EAL 7
Formally verified design and tested A1
EAL 6
Semi-formally verified design and tested B3
EAL 5
Semi-formally designed and tested B2
EAL 4
Methodically designed, tested and reviewed B1 C2
EAL 3
Methodically tested and checked
EAL 2
Structurally tested C1
EAL 1
Functionally tested
Higher Assurance
Lower Assurance

23. CC EALs – Summary 1-3 EAL 1 - Functionally tested
“Applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious”
EAL 2 - Structurally tested
“Applicable where developers or users require a low to moderate level of independently assured security”
EAL 3 - Methodically tested and checked
“Applicable where the requirement is for a moderate level of independently assured security”

24. CC EALs – Summary 4-5
EAL 4 - Methodically designed, tested and reviewed
“Applicable where developers or users require a moderate to high level of independently assured security”
EAL 5 - Semi-formally designed and tested
“Applicable where the requirement is for a high level of independently assured security”

25. CC EALs – Summary 6-7 EAL 6 - Semi-formally verified design and tested
“Applicable to the development of specialised TOEs (Targets of Evaluation), for high risk situations ”
EAL 7 - Formally verified design and tested
“Applicable to the development of security TOEs for application in extremely high risk situations

26. CC EALs - Web References
Common Criteria.org Web Site
Main page
Formal specification document
Introductory overviews
introductory_overviews/index.html