Security Architecture &

Models
The security architecture of an information
system is fundamental to enforcing an
organizations 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:
2GL:
3GL:
4GL:
5GL:

machine language
Assembly language
FORTRAN, BASIC, PL/1, C, etc
NATURAL, FOCUS, SQL
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 systems 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

Accreditation

Comprehensive eval of technical & non-technical

security features
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)

1.

2.
3.

4.

If you can guarantee process you can

guarantee the product
Describes essential characteristics of
security engineering process
Captures industry best practices
Accepted ways of defining practices
and improving capability
Provides measures of growth in
capability

SSE-CMM Security Engineering

Process Areas
Administer security
controls
Assess impact &
security risk
Assess threat

Coordinate security

Assess vulnerability

Specify security needs

Build assurance
argument

Verifiy & validate

security

Monitor security
posture
Provide security input

Information Security Models

Used to formalize security policy

Three types of models

1.
2.
3.

Access control models

Integrity models
Information flow models

Access control models

Access Matrix

Take-Grant Model

Access rights for subjects to objects

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/Ob File:
ject
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
Grant rights to B

Subject A

Object B

Grant rights to B
Including grant right
Subject A

Subject C
A

ha
sr
igh
ts
Y

Grant subset of Y on D
to

Subject/Object 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 users
2. Data is protected from unauthorized
modification by authorized users
3. Data is internally & externally
consistent

Biba Integrity Model Axioms

High Integrity Level
Read OK
(simple integrity axiom)
Medium Integrity Level
Write ok
(integrity axiom)

Low Integrity Level

subject
Invoke
Not ok
subject

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

Unclassified

Confidential
(Task 2, Project X)

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