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 monitors 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
  formUserID, 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 Bibas 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. Bibas 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