Security Models and Architecture

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

22. CC EALs - Reference HigherAssurance LowerAssurance

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 • http://www.commoncriteria.org/index.html • Formal specification document • http://www.commoncriteria.org/cc/cc.html • Introductory overviews • http://www.commoncriteria.org/ introductory_overviews/index.html