Security Architecture and Design Chapter 4 Part 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