Computer security principles and practice 3rd by williams stallings and brown ch13

Two fundamental computer security facts: Two fundamental computer security facts: All complex software systems have eventually revealed flaws or bugs that need to be fixed All complex

Chapter 13

Trusted Computing and Multilevel Security

Two fundamental computer

security facts:

Two fundamental computer

security facts:

All complex software systems have eventually

revealed flaws or bugs that need to be fixed

All complex software systems have eventually

revealed flaws or bugs that need to be fixed

It is extraordinarily difficult to build computer

hardware/software not vulnerable to security

attacks

It is extraordinarily difficult to build computer

hardware/software not vulnerable to security

attacks

Computer Security Models

design and implementation

formal security models

o Initially funded by US Department of Defense

very influential

Bell-LaPadula (BLP) Model

o Top secret > secret > confidential > restricted > unclassified

o Form a hierarchy and are referred to as security levels

The subject

is allowed both read and write access to the object

WRITE

The subject is allowed neither read nor write access to the object but may invoke the object for execution

• Subject can only read an object of less or equal security level

• Referred to as the simple security property (ss-property)

o No write down

• A subject can only write into an object of greater or equal security level

• Referred to as the *-property

flow of information

BLP Formal Description

(current access set b, access matrix M, level function f, hierarchy H)

ss-property: (Si, Oj, read) has fc(Si) ≥ fo(Oj).

(Si, Oj, write) has fc(Si) = fo(Oj)

ds-property: (Si, Oj, Ax) implies Ax ∈ M[Si

•

Ge

t access

2

•

Release access

3

•

Chang

e obje

ct level

4

•

Chang

e current level

5

•

Giv

e acce

ss permission

6

•

Rescind acce

ss permission

7

•

Create a

n object

•

Delete a group

of objectsBLP Rules

(b) A third file is added: f3: c1-s

Figure 13.2 Example of Use of BLP Concepts (page 1 of 3)

c1-t

c1-s — write c1-t — write c1-t — read

f2 f3

f4 exam

exam template

f4 exam c1-s — read

c1-s

(d) Carla, as student, is permitted acess to the exam: f4: c1-s

Figure 13.2 Example of Use of BLP Concepts (page 2 of 3)

(e) The answers given by Carla are only accessible for the teacher: f5: c1-t

Figure 13.2 Example of Use of BLP Concepts (page 3 of 3)

c1-t

f3 (comments

Figure 13.3 Multics Data Structures for MLS

Ls = segment security level

Lu = user security level

Limitations to the BLP Model

o MLS can work either for powers or for secrets but not readily for both

o This mutual exclusion excludes some interesting power and integrity centered technologies from being used effectively in BLP style MLS environments

• Cooperating conspirator problem in the presence of covert channels

o In the presence of shared resources the *-property may become unenforceable

o In essence, the BLP model effectively breaks down when (untrusted) low classified executable data are allowed to be executed by a high clearance (trusted) subject

Biba Integrity Model

• Strict integrity policy:

o Simple integrity: I(S) ≥ I(O)

o Integrity confinement: I(S) ≤ I(O)

o Invocation property: I(S1) ≥ I(S2)

High-integrity process

High-integrity file

write write

read

read

Low-integrity file Low-integrity process

Figure 13.4 Contamination With Simple Integrity Controls [GASS88]

disallowed

C1: IVP validates CDI state

C5: TPs validate UDI

E3: Users are authenticated

E2: Users authenticated for TP C3: Suitable separation of duty

C2: TPs preserve valid state

E4: Authorization lists changed only

by security officer

C4: TPs write to log E1: CDIs changed only by authorized TP CDI

CDI = constrained data item

IVP = integrity verification procedure

System in some state

Figure 13.5 Summary of Clark-Wilson System Integrity Rules [CLAR87]

CDI

CDI

log CDI USERS

CI 1

Set of all objects

(a) Example set

Conflict of interest classes

Company datasets Individual objects

(b) J ohn has access to Bank A and Oil A

Figure 13.6 Potential Flow of Information Between Two CIs

Table 13.1

Terminology Related

to

Trust

Audit file

Figure 13.7 Reference Monitor Concept

Security kernel databaseSubject: security clearance Object: security classification

Reference Monitor (policy)

Alice: RW Bob: W

Back-pocket file

(d)

Data file Bob

Alice

Program

Reference Monitor

Program

"CPE170KS"

Bob: RW

Alice: RW Bob: W

Back-pocket file

(b)

Figure 13.8 Trojan Horse and Secure Operating System

Data file Bob

Back-pocket file

(a)

Data file Bob

Back-pocket file

(c)

Data file Bob

Alice

Program

Reference Monitor

Program

"CPE170KS"

Bob: RW

Multilevel Security (MLS)

RFC 4949 defines multilevel security as follows:

“A mode of system operation wherein (a) two or more

security levels of information are allowed to be handled concurrently within the same system when some users having access to the system have neither a security clearance nor need-to-know for some of the data handled by the system and (b) separation of the users and the classified material on the basis, respectively, of clearance and classification level are dependent on operating system control.”

Table 13.2

RBAC Elements

Department Table - U Employee - R

Did Name Mgr Name Did Salary Eid

4 accts Cathy Andy 4 43K 2345

8 PR James Calvin 4 35K 5088

Cathy 4 48K 7712 James 8 55K 9664 Ziggy 8 67K 3054

(a) Classified by table

Did -U Name -U Mgr -R Name -U Did -U Salary -R Eid -U

4 accts Cathy Andy 4 43K 2345

8 PR James Calvin 4 35K 5088

Cathy 4 48K 7712 James 8 55K 9664 Ziggy 8 67K 3054

(b) Classified by column (attribute)

Figure 13.10 Approaches to Database Classification (page 1 of 2) Figure 13.9

Department Table Employee

Did Name Mgr Name Did Salary Eid

4 accts Cathy R Andy 4 43K 2345 U

8 PR James U Calvin 4 35K 5088 U

Cathy 4 48K 7712 U James 8 55K 9664 R Ziggy 8 67K 3054 R

(c) Classified by row (tuple)

Did Name Mgr Name Did Salary Eid

4 - U accts - U Cathy - R Andy - U 4 - U 43K - U 2345 - U

8 - U PR - U James -R Calvin - U 4 - U 35K - U 5088 - U

Cathy - U 4 - U 48K - U 7712 - U James - U 8 - U 55K - R 9664 - U Ziggy - U 8 - U 67K - R 3054 - U

(d) Classified by element

Figure 13.10 Approaches to Database Classification (page 2 of 2) Figure 13.9

Database Security

Read Access

• Easy if granularity is entire database or at table level

o If can query on restricted data can infer its existence

• SELECT Ename FROM Employee WHERE Salary > 50K

o Solution is to check access to all query data

o Null response indicates restricted/empty result

Database Security

Write Access

key that already exists in a higher level row:

o Can reject, but user knows row exists

o Can replace, compromises data integrity

o Polyinstantiation and insert multiple rows with same key, creates conflicting entries

Has 3 basic services:

o Motherboard, smart card, processor

o Working with approved hardware/software

o Generating and using crypto keys

Authenticated Boot Service

use

o At each stage digital signature associated with code is verified

o TPM keeps a tamper-evident log of the loading process

o Can then expand trust boundary to include additional hardware and application and utility software

o Confirms component is on the approved list, is digitally signed, and that serial number hasn’t been revoked.

Certification Service

others

o Can produce a digital certificate

o TPM is considered trustworthy

o Only the TPM possesses this TPM’s private key

o Hardware/OS configuration

o OS certifies application programs

o User has confidence in application configuration

Encryption Service

configuration

o Used to generate secret encryption key for every possible configuration of that machine

o Provide encryption key to application so that decryption can only be done by desired version of application running on desired version of the desired OS

o Encrypted data can be stored locally or transmitted to a peer application on a remote machine

Random number generator

Power detection

Execution engine

Volatile memory

Figure 13.11

Storage TPM

Figure 13.13 Decrypting a File Using a Protected Key

Protected symmetric key

Symmetric key

Decrypted file

User application (performs decryption)

Common Criteria for Information Technology Security

Evaluation

• Common Criteria (CC) for Information Technology and Security Evaluation

o ISO standards for security requirements and defining evaluation criteria

o Development using secure requirements

o Evaluation confirming meets requirements

o Operation in accordance with requirements

o NIST/NSA publishes lists of evaluated products

Target of evaluation (TOE)

• Refers to the part of product or

system subject to evaluation

Target of evaluation (TOE)

• Refers to the part of product or

system subject to evaluation

Assurance requirements

•Basis for gaining confidence that the claimed security measures are effective and implemented correctly

Table 13.3

CC Security Functional Requirements

Table 13.4

CC Security Assurance Requirements

Familyj

Familyk

Component Component Component

•

•

•

PACKAGES Reusable set of functional or assurance requirements.

Optional input to PP or ST

CLASSb

CLASSa

PROTECTION PROFILE possible input sources for PP

SECURITY TARGET possible input sources for ST Optional extended (non-CC)

security requirements

Figure 13.14 Organization and Construction of Common Criteria Requir ementsFigure 13.13

Security attributes

Security attributes

Security attributes

Security

Process Resource

TSF scope of control (TSC)

Object/

Information

Subject User

(TSP)

• Physical probing

Threats that must be addressed:

Security objectives

Security requirements

Protection Profile (PP)

Security Assurance

“Degree of confidence one has that the security controls operate correctly and protect the system as intended Assurance is not, however, an absolute guarantee that the measures work as intended.”

Se le

ct s ec uri ty fea tu re

s a nd fu nc tio ns

•

De term in

e t he re qu ire

d l ev els

of s ec uri

ty a ss ura nc e

Consumers

Consumers

•

Re sp on

d to se cu rit

y re qu ire me nts

•

In terp ret s tate me nts o

f as su ran ce re qu ire me nts

•

De term in

e a ss ura nc

e a pp roa ch es an

d l ev

el o

f eff ort

Developers

•

Use th

e a ss ura nc

e r eq uir em en ts as cri te ria wh en ev alu ati ng

se cu rit

y fe atu re

s a nd co ntro ls

or a th ird -p art

y

ev alu ati on te am

System architecture

• Addresses both the system development

phase and the system operations phase

System architecture

• Addresses both the system development

phase and the system operations phase

Design specification and verification

• Addresses the correctness of the system

design and implementation with respect to

the system security policy

Design specification and verification

• Addresses the correctness of the system

design and implementation with respect to

the system security policy

Covert channel analysis

• Attempts to identify any potential means for

bypassing security policy

Covert channel analysis

• Attempts to identify any potential means for

bypassing security policy

Trusted facility management

• Deals with system administration

Trusted facility management

• Deals with system administration

Trusted recovery

• Provides for correct operation of security

features after a system recovers from failures, crashes, or security incidents

Trusted recovery

• Provides for correct operation of security features after a system recovers from failures, crashes, or security incidents

Trusted distribution

• Ensures that protected hardware, firmware,

and software do not go through unauthorized modification during transit from the vendor to the customer

EAL 1: Functionally tested

EAL 2: Structurally tested

EAL 3: Methodically tested and checked

EAL 4: Methodically designed, tested, and reviewed

EAL 5: Semi-formally designed and tested

EAL 6: Semi-formally verified design and tested

EAL 7: Formally verified design and tested

Common Criteria Evaluation Assurance

Levels

Ensures security features work correctly and effectively and show no exploitable vulnerabilities

Performed in parallel with or after the development of the TOE

Higher levels entail: greater rigor, more time, more cost

Principle input: security target, evidence, actual TOE

Result: confirm security target is satisfied for TOE

Process relates security target to high-level design, low-level design, functional specification, source code implementation, and object code and hardware realization of the TOE

Process relates security target to high-level design, low-level design, functional specification, source code implementation, and object code and hardware realization of the TOE

Degree of rigor and depth of analysis are determined by assurance level desired

Evaluation

Final report is given to the certifiers for acceptance

Evaluation Parties and Phases

government agency in each country

Validation Scheme (CCEVS)

Phases

o Multilevel security for role-based access control

o Database security and multilevel security

trusted platform module

o Authenticated boot service

o Certification service

o Encryption service

o TPM functions

o Protected storage

technology security evaluation

o Requirements

o Profiles and targets

o Example of a protection profile

• The Bell-LaPadula model for computer security

o Computer security models

o Limitations to the BLP model

o Biba integrity model

o Clark-Wilson integrity model

o Chinese wall model

o Reference monitors

o Trojan horse defense