Security Architecture & Models

“The security architecture of an information system is fundamental to enforcing an organization’s information security policy.”

Computer Architecture

CPU, control bus Memory:

cache, RAM, DRAM, ROM CPU:

Instruction cycle: fetch & execute Pipelining, CISC, RISC, Multi-tasking,

Multi-Processing I/O: programmed I/O, DMA, Interrupts

Software

Languages 1GL: machine language 2GL: Assembly language 3GL: FORTRAN, BASIC, PL/1, C, etc 4GL: NATURAL, FOCUS, SQL 5GL: Prolog, LISP, other AI languages

Open & Closed Systems Open:

Vendor independent Designed & written by “outsiders” Subject to review & evaluation by

outside parties not company insiders Closed

Vendor dependent Not typically compatible with other

systems

Distributed Architecture Migration from centralized to client/server

User is also admin, programmer & operator Desktops can contain sensitive, at risk, info Users might lack security awareness Desktop can provide avenue into “trusted”

networks Modems, PDAs, USB drives can be attached

easily Downloading from Internet can produce

disasters Desktops are hard to protect physically Lack of proper backup

Security mechanisms for Distributed Environments Email & upload/download policies Robust access controls (biometrics &/or 2

tier controls) GUIs to restrict access to “real” system File Encryption & cipher tools for email Users with limited “rights” Separation of processes into privileged &

non-privileged Lock desktops, enable tampering logging Enable remote logging Centralized backup

Protection Mechanisms Protection Domain: execution & memory

space assigned to each process Abstraction ie objects & OOP Security Labels: classification for access

control Security Modes: A system operates in

different modes with users having different rights depending on the security label the object being processed has

Rings or layers of security

OS kernel is usually inner most circle Processes & users are closer or

further from the center depending on classification and need

Recovery Procedures Should not provide opportunity for

violations of system’s security policy Fault-tolerant: computer system fails but

network continues to opperate Failsafe system: hardware or software

failure causes “controlled” shutdown Fail-soft or resilient: non-critical processing

is discontinued but network or computer continues in degraded mode

Failover: switching to duplicate systems in case of failure

Assurance

Degree of confidence in the satisfaction of security needs.

Following slides provide an overview of guidelines & standards that help evaluate security aspects of a system

Assurance: Evaluation Criteria

Trusted Computer Evaluation Criteria (TCSEC)

Basic control objectives are: security policy, assurance & accountability

Assurance levels are: D (minimal protection), C (discretionary), B (manditory), & A (Verified)

Assurance: Certification & Accreditation

Formal methods provide for an authority that takes responsibility for system security

Certification: comprhensive eval of system security

Accreditation: format declaration

Certification & Accreditation Responsibility (i.e. blame) requires Formal

methods Certification

Comprehensive eval of technical & non-technical security features

Accreditation Formal declaration by Designated Authority

stating that system is approved to opperate in particular security mode

Rechecked after defined period of time

U. S. Defense Accreditation Process

Phase 1: understand mission, environment, & architecture to determine security requirements

Phase 2: create SSAA an evolving, binding security agreement. SSAA becomes baseline security agreement

Phase 3: Validation: check compliance Phase 4: Post Accreditation

U. S. Defense Types of Accreditation

Site: evaluates a single site

Type: evaluates an app or system distributed to a number of locations

System: evaluates a major app or support system

Systems Security Engineering Capability Maturity Mdl

(SSE-CMM)

If you can guarantee process you can guarantee the product

1. Describes essential characteristics of security engineering process

2. Captures industry best practices3. Accepted ways of defining practices

and improving capability4. Provides measures of growth in

capability

SSE-CMM Security Engineering Process Areas

Administer security controls

Coordinate security

Assess impact & security risk

Monitor security posture

Assess threat Provide security input

Assess vulnerability Specify security needs

Build assurance argument

Verifiy & validate security

Information Security Models

Used to formalize security policy

Three types of models1. Access control models2. Integrity models3. Information flow models

Access control models Access Matrix

Access rights for subjects to objects Take-Grant Model

Directed graph to specify rights that a subject can take or grant from or to another subject

Bell-LaPadula Model Department of Defense Deals only with confidentiality not integrity or

availability

Access Matrix

Columns provide ACL for each object

Subject/Object

File: Income

File: Salaries

Process: Deductions

Print Server: A

Joe Read Read/Write Execute Write

Jane Read/Write Read None Write

Process: Check

Read Read Execute None

Program: Tax

Read/Write Read/Write Call Write

Directed Graph

Subject A

Subject A

Object B

Subject C

Subject/Object D

Grant rights to B

Grant rights to B

Including grant right

A has rights Y to D

Grant subset of Y on D

Bell-LaPadula Model

Simple Security Property Reading of info by subject of lower

sensitivity from object of higher not permitted

Writing of info by subject of higher to object of lower not permitted

Uses Access Matrix to specify discretionary access control

Integrity Models

Sometimes integrity is as or more important than confidentiality

Biba Integrity Model Clark-Wilson Integrity Model

Biba Integrity Model

Three Goals:1. Data is protected from modification

by unauthorized users2. Data is protected from unauthorized

modification by authorized users3. Data is internally & externally

consistent

Biba Integrity Model Axioms

High Integrity Level

Medium Integrity Level

Low Integrity Level

Read OK(simple integrity axiom)

subject

subject

InvokeNot ok

Write ok(integrity axiom)

Clark-Wilson Integrity Model Real world model Constrained data item (CDI):

object whose integrity is to be preserved Integrity Verification Procedure:

confirms that all CDIs are in valid states of integrity

Transformation Procedure: assures that well formed manipulations are used to change CDIs

Unconstrained data item

Information Flow Models

Based on a state machine Consists of objects, state transitions,

and flow policy Objects are constrained to flow only in

the directions permitted by the security policy

Confidential(Project X)

Confidential(Task 1, Project X)

Confidential(Task 2, Project X)

Unclassified

Confidential

Composition Theories Systems are usually built by combining

smaller systems Therefore must consider whether security

of component systems are maintained when combined into larger systems

Types of constructs Cascading: input to one sys is from another Feedback: loop one to second back to one Hookup: system that communicates with both

internal & external systems