Security Architecture and Design

Chapter 4Part 3

Pages 357 to 377

System Security Architecture

• How to build a “secure” system• Security Policy– Goals for the system– How sensitive information and resources are

managed and protected– Used to specify the system

Trusted Computer System Evaluation Criteria

• US Government• Requirement for a security architecture

Trusted Computing Base (TCB)

• Collection of hardware, operating system, software and firmware

• Must behave properly according to the security policy and not violate the trust of the system

• Trusted path of communications between the user and the programs and the TCB

TCB

• Always act in a safe and predictable manner• Cannot be compromised or tampered with • The OS ensures non-TCB processes and TCB

processes interact in a secure manner

TCB

• System goes through an evaluation process – Example: Orange Book evaluation criteria

Security Perimeter

• Boundary between processes and resources outside the TCB and the TCB

• Divides untrusted from trusted• Precise communication standards (interface)

Reference Monitor

• Mediates all accesses for subjects to objects• Ensures subjects have necessary access rights• Protects objects from unauthorized access• All access decision should be made by a

trusted, tamperproof component of the OS which works with the system kernel

Security Kernel

• Hardware, software, firmware that implements the Reference Monitor

• Invoked for every access• Tamperproof, tested and verified

Security Models

• Bell-LaPadula• Biba• Clark-Wilson

Security Models

• Start with security policy• Model is a framework that implements and

enforces the security policy• Mathematics proof that programming code

State Machine Model

• System state is secure• Only allowable state transitions into a secure

state• Verified by formal mathematics models• Boots into a secure state• Shuts down or fails into a secure state

Basic Security Theorem

• If a system is initialized in a secure state and allowed state transitions are secure, then every subsequent state will be secure no matter what inputs occur.

Formal Models

• Not popular for software development• Vendors are under pressure to get the product

to market• Used to develop systems that cannot allow

errors or security breaches– Air traffic control, spacecraft, military classified

systems, medical control systems

Bell-LaPadula

• 1970s by U.S. Military• Mathematical model of multilevel security

policy• Secure state• Rules of access• Only covers confidentiality

Bell-LaPadula

• Subject-object model• Subjects are assigned security labels

(confidential, secret, top-secret) and by domain (Iraq, Fighter Jet Contract, etc.)

• Objects are assigned security labels (confidential, secret, top-secret) and by domain (Iraq, Fighter Jet Contract, etc.)

Simple Security Rule

• A subject at a given security level cannot read data that resides at a higher security level.

• “No read up”

*-property

• Subject in a given security level cannot write information to a lower security level.

• “No write down”

Strong Star Property

• A subject that has read and write capabilities can only perform these capabilities at the same security level.

Mandatory Access Control

• All MAC systems are based on Bell-LaPadula

Biba Model

• Like Bell-LaPadula but for integrity• Prevents data from flowing to a higher

integrity level

*-integrity

• “no write up”• Can write data to an object at a higher

integrity level• Dirty data cannot be mixed with clean data

Simple integrity axiom

• “no read down”• A subject cannot read data from a lower

integrity level• Cannot be corrupted by lower integrity data• New York Times needs high quality sources of

information

Invocation Property

• A subject cannot request service (invoke) of higher integrity

Integrity

• Business need data integrity– Account balances

• Governments need confidentiality

Clark-Wilson Model

• Formal (mathematical) integrity model• Figure 4-23 on page 375• UDI – unconstrained data item– Does not require a high level of protection

Clark-Wilson Model

• CDI – constrained data item– User cannot modify directly

• TP – Transformation Procedure– User authenticates– Carries out procedure for the user

• IVP – Integrity verification procedures– Ensure integrity rules are being carried out

Clark-Wilson Model

• Well-formed transaction = series of operation which maintains the integrity

• Separation of duties – part of the model for certain transactions

Model

• Mathematical framework for integrity• The vendor provides the integrity rules to fit

the product requirements

Goals of Integrity Models

1. Prevent unauthorized users from making modifications

2. Prevent authorized users from making improper modifications (separation of duties)

3. Maintain internal and external consistency• Biba only addresses them first goal• Clark-Wilson addresses all three