Security Architecture

Models

CISSP -Security Architecture & Models Slide: 1

 Trusted Path

• A trusted path is simply some mechanism that

provides confidence that the user is
communicating with what the user intended to
communicate with, ensuring that attackers can't
intercept or modify whatever information is being
communicated.
• As such it is trustworthy channels to assure users
that they really are working with the program or
system they intended to use/communicate with.
• The traditional example of an untrusted path is a
'fake login' program (e.g.: a program is written to
look like the login screen of a system, as in Login
spoofing). When users try to log in, the fake login
program can then capture user passwords for later
use.

CISSP -Security Architecture & Models Slide: 2

 Trust & Assurance

• Trust & Assurance

­ Trust: Level of protection provided by system,
e.g. the term “trust” in Trusted Computing Base.
­ Assurance: Degree of confidence that system
does it.

CISSP -Security Architecture & Models Slide: 3

 Access Control List

• With respect to a computer file system, an

access control list (ACL) is a list of
permissions attached to an object.
• An ACL specifies which users—or system
processes—are granted access to objects,
as well as what operations are allowed to
be performed on given objects.
• In a typical ACL, each entry in the list
specifies a subject, an object and an
operation. For example, the entry (Alice,
delete) on the ACL for file WXY gives Alice
permission to delete file WXY.

CISSP -Security Architecture & Models Slide: 4

 Protection Mechanisms (1)

• Protection mechanisms are built into a

computer system to support the
enforcement of security policies, e.g., to
control access to objects, such as memory,
machine code instructions, registers, or
other system resources.
• You use Active Protection mechanisms to
prevent access to an object if the access is
not authorized according to the sec policy.
• As an example, memory access to objects
at certain addresses may not be allowed by
a system.

CISSP -Security Architecture & Models Slide: 5

 Protection Mechanisms (2)

• Passive protection mechanisms are those

that prevent or detect unauthorized use of
the information associated with an object,
even if access to the object itself is not
prevented.
• As examples, passive protection
mechanisms use
­ cryptographic techniques to prevent
unauthorized disclosure of important
information (prevention) or
­ checksum techniques to detect unauthorized
alteration of information (detection).

CISSP -Security Architecture & Models Slide: 6

 OS Protection Controls

• OS is the only line of defense between

­ users, programs, applications, utilities, and
­ the low level OS functions that are the core
security features of the system.
• OS uses three security technologies
(concepts) to protect the system:
­ The Trusted Computing Base (TCB)
­ The Reference Monitor
­ The Security Kernel

CISSP -Security Architecture & Models Slide: 7

 TCB (1)

• The trusted computing base (TCB) of a

computer system is the set of all hardware,
firmware, software, and processes that are
critical to its security, in the sense that
bugs or vulnerabilities occurring inside the
TCB might jeopardize the security
properties of the entire system.
• TCB is defined as the total combination of
protection mechanisms for all the
hardware, software, firmware, and
processes that, combined, are responsible
for enforcing a security policy.
­ The reference monitor concept could be part of
the security policy which is to prevent
unauthorized access, e.g. to objects.
­ TCB usually implements the reference monitor.
CISSP -Security Architecture & Models Slide: 8
 TCB (2)

• With regard to the reference monitor

concept, TCB includes access control for
­ Process activation (a user is authorized?? to
activate a process)
­ Memory protection (a user process is
authorized?? to access memory of the superuser
process??)
­ I/O operations (a user is authorized to do that I/O
operation??)
of OS.

CISSP -Security Architecture & Models Slide: 9

 Reference Monitor (1)

• A reference monitor is an abstract machine

(logical access control concept), which
mediates all the access subjects have to
objects in order to
­ ensure that the subjects have the necessary
access rights and
­ protect the objects from unauthorized access
and destruction.
• It is the core of the TCB and is the most
commonly used approach to building
trusted computing systems.

CISSP -Security Architecture & Models Slide: 10

 Reference Monitor (2)

• Reference monitor enforces three system

requirements:
­ Provide isolation for the processes carrying out
the reference monitor (i.e., to control access),
and such separate processes must be
tamperproof -- Isolation
­ Mediate all access (every access attempt by a
subject to have the necessary access rights) and
access circumvention attempt must be
impossible -- Completeness
­ The module (carrying out the reference monitor)
must be small enough to be able to be tested
and verified in a complete manner -- Verifiable

CISSP -Security Architecture & Models Slide: 11

 Security Kernel

• The Security Kernel is the hardware,

firmware, software and process elements of
a TCB that implement the reference monitor
concept.

CISSP -Security Architecture & Models Slide: 12

 Mandatory Access Controls
• MACs (Mandatory Access Control) are
used for information systems with highly
sensitive data.
• MACs are considered a central policy
access control.
• The policy is centrally controlled by a
security policy administrator; users do not
have the ability to override the policy and,
for example, grant others access to files.
• Any operation by any subject on any object
will be tested against the set of
authorization rules (aka policy) to
determine if the operation is allowed.

CISSP -Security Architecture & Models Slide: 13

 An Example of MAC

• Every object is given a sensitivity

label (classification: Top secret, Top secret
Secret, Unclassified) and is
accessible only to users who are
cleared up to that particular level.
• MACs limit user access so that a
user at a lower level, say Secret
Unclassified cannot access
information labeled at a higher
level, say Secret.
• A user can be granted the secret
privilege and have access to
objects with this classification orUnclassified
lower as long as they have a
need to know.

CISSP -Security Architecture & Models Slide: 14

 Discretionary Access Controls (1)

• DAC (Discretionary Access Control) is a

kind of access control defined by TCSEC
as "a means of restricting access to
objects based on the identity of subjects
and/or groups to which they belong”.
• DAC is based on the subject’s identity to
access objects.
­ It is identity-based access control.

CISSP -Security Architecture & Models Slide: 15

 Discretionary Access Controls (2)

• The controls are discretionary in the sense

that a subject with a certain access
permission is capable of passing that
permission (perhaps indirectly) on to any
other subject (unless restrained by
mandatory access control)".
• The term is commonly used in contexts
that an object has an owner who can
transfer access to others.
­ The owner has discretion to assign access.
• DAC is used by Unix, NT, NetWare, Linux,
and Vines.

CISSP -Security Architecture & Models Slide: 16

 DACs and MACs
• Discretionary access control is commonly defined in
opposition to mandatory access control
­ Sometimes called non-discretionary access control.
• With MAC, the central policy by the organisation
controls overall access to objects. Subjects can’t
violate this policy, e.g., transfer access to others.
• With DAC, subjects can transfer access to others.
But this must not override the central policy
declared.
• A system can be said to implement both MAC and
DAC simultaneously, where DAC refers to one
category of access controls that subjects can
transfer among each other, and MAC refers to a
second category of access controls based on the
central policy that imposes constraints upon the
first, i.e.,
­ Transfer of access can be done as long as this does not
override the central policy.

CISSP -Security Architecture & Models Slide: 17

 TCSEC
• TCSEC (Trusted Computer System Evaluation
Criteria) is a United States Government
Department of Defense (DoD) standard that sets
basic requirements for assessing the effectiveness
of computer security controls built into a computer
system.
• TCSEC was used to evaluate, classify and select
computer systems being considered for the
processing, storage and retrieval of sensitive or
classified information.
• TCSEC, frequently referred to as the Orange Book,
is the centerpiece of the DoD Rainbow Series
publications.
• TCSEC was initially issued in 1983 and then
updated in 1985. TCSEC was replaced by the
Common Criteria international standard originally
published in 2005.
• TCSEC looks at the functionality, effectiveness,
and assurance of a system during its evaluation.
CISSP -Security Architecture & Models Slide: 18
 TCSEC
• TCSEC provides a graded
classification (rating) of
systems that is divided into
hierarchical divisions of
security levels:     
­ D - Minimal security
­ C - Discretionary protection
­ B - Mandatory protection
­ A - Verified protection
• The highest classification
level is level A, and it
represents the highest level
of security; level D then
represents the lowest level
of security.

CISSP -Security Architecture & Models Slide: 19

 TCSEC

• Each of the four divisions (D, C, B, A) has

one or more numbered classes, each of
which have a corresponding objective that
must be met for a system to achieve that
particular rating.
­ Classes were devised to address typical security
requirements (usually found in many
systems/products).

CISSP -Security Architecture & Models Slide: 20

 An Example of Functionality Class C1

• Objective -- It provides discretionary (need-

to-know) access control.

1 Identification and Authentication

1.1 The TOE shall identify and authenticate users.
This identification and authentication shall take
place prior to all other interactions between the T
OE and the user.
Other interactions shall only be possible after su
ccessful identification and authentication.
The authentication information shall be stored in
such a way that it can only be accessed by autho
rised users.

CISSP -Security Architecture & Models Slide: 21

 An Example of Functionality Class C1

2 Access Control
2.1 The TOE shall be able to distinguish and
administer access rights between each user and
the objects which are subject to the administration
of rights, on the basis of an individual user, or on
the basis of membership of a group of users, or
both.
It shall be possible to completely deny users or
user groups access to an object.
It shall not be possible for anyone who is not an
authorised user to grant or revoke access rights
to an object.

2.2 With each attempt by users or user groups to

access objects which are subject to the
administration of rights, the TOE shall verify the
validity of the request. Unauthorised access
attempts shall be rejected.
CISSP -Security Architecture & Models Slide: 22
 Four Divisions and Classes
• The four divisions have seven sets of
evaluation criteria called classes (D, C1, C2,
B1, B2, B3 and A1).
• Each division expands the requirements of
the immediately prior division.
­ D is the lowest, C expands D, B expands C and A
expands B.
• Each class covers four aspects of
evaluation: Security Policy, Accountability,
Assurance and Documentation.

CISSP -Security Architecture & Models Slide: 23

 Divisions and Classes

CISSP -Security Architecture & Models Slide: 24

CISSP -Security Architecture & Models Slide: 25
 Evaluation Aspects

• Policy
­ The security policy must be explicit, well-defined
and enforced by the computer system.
­ Mandatory Security Policy (MAC type)
~ Enforces access control rules based directly on an
individual's clearance, authorization for the information
and the confidentiality level of the information being
sought.
­ Discretionary Security Policy (DAC type)
~ Enforces rules for controlling and limiting access based
on identified individuals who have been determined to
have a need-to-know for the information.

CISSP -Security Architecture & Models Slide: 26

 Evaluation Aspects

• Accountability - Individual accountability

regardless of policy must be enforced.
­ Identification -- The process used to recognize
an individual user.
­ Authentication -- The verification to ensure that
the individual is who he or she claims to be.
­ Auditing -- Audit information must be selectively
kept and protected so that actions affecting
security can be traced to the authenticated
individual.

CISSP -Security Architecture & Models Slide: 27

 Evaluation Aspects

• Assurance
­ The computer system must contain
hardware/software/firmware mechanisms that
can be independently evaluated to provide
sufficient assurance that the system enforces
the above requirements.
­ Life Cycle Assurance - Software, hardware, and
firmware must be able to be tested individually
to ensure that each component enforces the
security policy in an effective manner
throughout its lifetime.
­ Continuous Protection Assurance - The security
mechanisms and the system as a whole must
continuously perform predictably and acceptably
in different situations.

CISSP -Security Architecture & Models Slide: 28

 Evaluation Aspects

• Documentation
­ Includes test, design, and specification
documents, and user guides and manuals.

CISSP -Security Architecture & Models Slide: 29

 Rainbow Series
• The Rainbow Series (sometimes known as the
Rainbow Books) is a series of computer security
standards published by the United States
government in the 1980s and 1990s.
• They were originally published by the U.S.
Department of Defense Computer Security Center,
and then by the National Computer Security
Center.
• These standards describe a process of evaluation
for trusted systems.
• In some cases, U.S. government entities (as well
as private firms) would require formal validation of
computer technology using this process as part of
their procurement process.
• Many of these standards have influenced, and
have been superseded by, the Common Criteria.

CISSP -Security Architecture & Models Slide: 30

 Some of the Rainbow Book Series
(http://en.wikipedia.org/wiki/Rainbow_Series)

CISSP -Security Architecture & Models Slide: 31

 TNI

• The Trusted Network interpretation (TNI),

also called the Red Book, is used to extend
the Orange Book (single systems) to
networks which are many systems, each
with connectivity to the other one.
• TNI addresses local area network (LAN)
and wide area network (WAN) systems.
• TNI addresses many issues in determining
the security protection required for
different network environments.

CISSP -Security Architecture & Models Slide: 32

 TNI

• TNI addresses the following security

requirements for network environments:
­ Communication integrity
~ Authentication
~ Message integrity
~ Non-repudiation
­ DoS prevention
~ Continuity of operation
~ Network management
­ Compromise protection
~ Data confidentiality
~ Traffic flow confidentiality
~ Selective routing

CISSP -Security Architecture & Models Slide: 33

 TNI

• TNI rates the security level of:

­ the confidentiality and integrity of data and
operations within a network,
­ the network products themselves
as
­ None
­ C1- Minimum
­ C2- Fair
­ B2- Good
(similar to TCSEC with D, C, B, A)

CISSP -Security Architecture & Models Slide: 34

 ITSEC

• European countries created the Information

Technology Security Evaluation Criteria
(ITSEC) in an attempt to establish a single
standard for evaluating security of
computer systems.
• ITSEC was developed further from TCSEC.
• ITSEC is only used in Europe.
• ITSEC is Europe’s version of the Orange
Book.

CISSP -Security Architecture & Models Slide: 35

 ITSEC

• Similar to TCSEC, ITSEC also provides a

graded classification (rating) of systems
that is divided into security levels: E0, E1,
E2, … E6.  
­ The highest classification level is level E6, and it
represents the highest level of security; level E0
then represents the lowest level of security.
• Similar to TCSEC, ITSEC uses the concept
of classes to address typical security
requirements.
• Higher security levels roughly require more
classes/work to be implemented/done.

CISSP -Security Architecture & Models Slide: 36

 TOE and Security Target

• TOE is a Target of Evaluation –

product/system to be evaluated for a
classification/rating
• TOE defines a security target to be satisfied
by the TOE.
• A security target serves as both a
specification of the security enforcing
functions, against which the TOE will be
evaluated, and as a description relating the
TOE to the environment in which TOE will
operate.
• A security target may be presented as a
single document, or as multiple
documents.

CISSP -Security Architecture & Models Slide: 37

 Contents of a Security Target

• The required contents of a security target:

a) Either a System Security Policy or a Product
Rationale.
b) A specification of the required security
enforcing functions.
c) Required security mechanisms to implement
the functions (optional).
d) The claimed rating of the minimum strength of
mechanisms (basic, medium or high).
e) The target evaluation level (E1, E2, …., or E6)

CISSP -Security Architecture & Models Slide: 38

 System Security Policy

• The System Security Policy specifies the

set of laws, rules and practices that
regulate how sensitive information and
other resources are managed, protected
and distributed within a specific system --
TOE

CISSP -Security Architecture & Models Slide: 39

 Product Rationale

• The product rationale shall identify

­ the intended method of use for the product,
­ the intended environment for use of the product
and
­ the assumed threats within that environment.
• It shall include a summary of the product's
security features, and define all
assumptions about the environment and a
way in which the product will be used.
• It shall include personnel, physical,
procedural and IT security measures
required to support the product, and its
dependencies on system hardware,
software, and/or firmware not supplied as
part of the product.

CISSP -Security Architecture & Models Slide: 40

 Specification of Security Enforcing
Functions
• A security target shall include a
specification of the security enforcing
functions to be provided by the TOE.
• These functions may be stated explicitly
(defined by yourself), or by reference to
one or more predefined functionality
classes, or by reference to an accepted
standard that defines security functionality.
• Ten predefined classes are provided in the
annex A of ITSEC (version 1.2).
­ Some are classes from TCSEC.

CISSP -Security Architecture & Models Slide: 41

 Example Predefined Class F-C1

Objective
• Class F-C1 is derived from the functionality
requirements of the US TCSEC class C1. It
provides discretionary (need-to-know)
access control.

(Security enforcing functions may be

stated by reference to this predefined
functionality class.)

CISSP -Security Architecture & Models Slide: 42

 Predefined Class F-C1:
Identification and Authentication
• The TOE shall identify and authenticate
users.
• This identification and authentication shall
take place prior to all other interactions
between the TOE and the user.
• Other interactions shall only be possible
after successful identification and
authentication.
• The authentication information shall be
stored in such a way that it can only be
accessed by authorised users.

CISSP -Security Architecture & Models Slide: 43

 Predefined Class F-C1:
Access Control
• The TOE shall be able to distinguish and
administer access rights between each user and
the objects which are subject to the administration
of rights, on the basis of an individual user, or on
the basis of membership of a group of users, or
both.
• It shall be possible to completely deny users or
user groups access to an object.
• It shall not be possible for anyone who is not an
authorised user to grant or revoke access rights to
an object.
• With each attempt by users or user groups to
access objects which are subject to the
administration of rights, the TOE shall verify the
validity of the request.
• Unauthorised access attempts shall be rejected.
CISSP -Security Architecture & Models Slide: 44
 Required Security Mechanisms

• A security target may optionally claim the

use of particular security mechanisms.
• All security mechanisms shall be correlated
to its security enforcing functions, so that it
can be seen which mechanisms implement
which function
­ a mechanism may implement several functions,
and a function may be implemented through a
combination of several mechanisms.
~ E.g. a password selection mechanism may be required
to implement a function of identification &
authentication.

CISSP -Security Architecture & Models Slide: 45

 Claimed Rating of Minimum Strength of
Mechanisms
• A security target shall specify a claimed
rating of the minimum strength of the
security mechanisms of the TOE against
direct attack.
• This shall be one of the ratings: basic,
medium or high.
• The rating could be an overall value for all
the security mechanisms used.
• A password selection mechanism is an
example which needs such a claimed
rating.
­ The rating for this could be medium.

CISSP -Security Architecture & Models Slide: 46

 Target Evaluation Level

• A security target shall specify a target

evaluation level for evaluation of the TOE.
• This shall be one of the ratings: E1, E2, E3,
E4, E5 or E6 as defined earlier, E1 being the
lowest, E6 the highest.
• The sponsor for evaluation has to supply
the desired target evaluation level.

CISSP -Security Architecture & Models Slide: 47

 Target Evaluation Level Definition

Level E0
• This level represents inadequate assurance.
Level E1
• At this level there shall be a security target and an
informal description of the architectural design of
the TOE. Functional testing shall indicate that the
TOE satisfies its security target.
Level E2
• In addition to the requirements for level E1, there
shall be an informal description of the detailed
design. Evidence of functional testing shall be
evaluated. There shall be a configuration control
system and an approved distribution procedure.

CISSP -Security Architecture & Models Slide: 48

 Target Evaluation Level Definition

Level E3
• In addition to the requirements for level E2,
the source code and/or hardware drawings
corresponding to the security mechanisms
shall be evaluated. Evidence of testing of
those mechanisms shall be evaluated.
Level E4
• In addition to the requirements for level E3,
there shall be an underlying formal model
of security policy supporting the security
target. The security enforcing functions,
the architectural design and the detailed
design shall be specified in a semiformal
style.

CISSP -Security Architecture & Models Slide: 49

 Target Evaluation Level Definition

Level E5
• In addition to the requirements for level E4,
there shall be a close correspondence
between the detailed design and the source
code and/or hardware drawings.
Level E6
• In addition to the requirements for level E5,
the security enforcing functions and the
architectural design shall be specified in a
formal style, consistent with the specified
underlying formal model of security policy.

CISSP -Security Architecture & Models Slide: 50

 Layout of Criteria to be Satisfied by a Level

• Construction - The Development Process

­ Phase 1 - Requirements
­ Phase 2 - Architectural Design
­ Phase 3 - Detailed Design
­ Phase 4 - Implementation
• Construction - The Development Environment
­ Aspect 1 - Configuration Control
­ Aspect 2 - Programming Languages and Compilers
­ Aspect 3 - Developers Security
• Operation - The Operational Documentation
­ Aspect 1 - User Documentation
­ Aspect 2 - Administration Documentation
• Operation - The Operational Environment
­ Aspect 1 - Delivery and Configuration
­ Aspect 2 - Start-up and Operation

CISSP -Security Architecture & Models Slide: 51

 Example: Phase 1 - Requirements

• The security target shall state the security

enforcing functions to be provided by the
TOE.
• In the case of a system, the security target
shall include a System Security Policy
(SSP) identifying the security objectives
and the threats to the system.
• In the case of a product, the security target
shall include a product rationale,
identifying the method of use for the
product, the intended environment and the
assumed threats within that environment.

CISSP -Security Architecture & Models Slide: 52

 Common Criteria (CC)

• TCSEC (the Orange Book) was used in the United

States and ITSEC was used in Europe.
• Common criteria is the approach to merging the
two together that could be used worldwide.
• It becomes an ISO standard, ISO/IEC 15408 with
three parts Part 1, Part 2 and Part 3.
• The concept of classes and evaluation levels (here
called evaluation assurance levels) is like TCSEC
and ITSEC.
• Evaluation assurance levels (EAL) consist of
EAL1, EAL2, …, EAL7, with EAL1 being the lowest
and EAL7 being the highest in security.

CISSP -Security Architecture & Models Slide: 53

 TOE

• TOE is a Target of Evaluation –

product/system to be evaluated for a
classification/rating.
• TOE defines a protection profile (PP) or
security target (ST) to be satisfied by the
TOE.

CISSP -Security Architecture & Models Slide: 54

 Protection Profile (PP)
• A PP contains a set of security requirements
either from the CC (taken from Part 2 and 3 of
the standard), or stated explicitly (extended
requirements defined by yourself).
• A PP may include an EAL.
• A PP permits the implementation independent
expression of security requirements for a set
of TOEs.
­ A DBMS PP could be applied for a variety of DBMS
systems available in the market, e.g., Oracle, SQL
Server, Sybase, etc.

CISSP -Security Architecture & Models Slide: 55

 Development of PP

ST -- Security Target Security requirements could be either taken from the CC

(Part 2 and 3 of the standard), or stated explicitly
CISSP -Security Architecture & Models (extended requirements defined by yourself). Slide: 56
 Security Target (ST)

• An ST contains a set of security

requirements that may be made by
reference to
­ a PP,
­ CC functional or assurance components (Part 2
and 3, respectively), or
­ stated explicitly (extended requirements).
• An ST permits the expression of security
requirements for a specific TOE.
­ E.g., ST for Sybase DBMS could define its
security requirements using the DBMS PP plus
their own additional security requirements.

CISSP -Security Architecture & Models Slide: 57

CISSP -Security Architecture & Models Slide: 58
 Security Functional Requirements and

Security Assurance Requirements

• TOE security functional
requirements could be defined using
standard classes in Part 2 (similar in
concept to the ten predefined classes in
ITSEC for defining security enforcing
functions).
• TOE security assurance requirements are
also provided as classes in Part 3 (that the
sponsor must satisfy for a desired EAL)
(similar in concept to Target Evaluation
Level in ITSEC).

CISSP -Security Architecture & Models Slide: 59

 EALs,
Classes,
Families,
Components
in Part 3

CISSP -Security Architecture & Models Slide: 60

 Certification versus Accreditation

• Certification
­ Technical evaluation of the security components
and their compliance perhaps to a predefined
standard for the purpose of accreditation.
­ Techniques used:
~ risk analysis, verification, testing, auditing
­ Indicate the good and bad points of security in a
system to be evaluated.
­ The evaluation for a system for a desired
EAL/Target Evaluation Level could be an
example of certification.

CISSP -Security Architecture & Models Slide: 61

 Certification versus Accreditation

• Accreditation
­ Formal acceptance of a system’s overall security
by management
­ When the certification information (document) is
presented to management (perhaps by an
auditor), it is up to management to ask the
proper security related questions, review reports
and findings, and decide upon the acceptance of
the safeguards and if any corrective actions are
required.
• Change Control
­ Major changes to the system being evaluated
should initiate recertification and
reaccreditation.

CISSP -Security Architecture & Models Slide: 62

 DIACAP & DITSCAP

• DIACAP (The Department of Defense

Information Assurance Certification and
Accreditation Process) is a process defined
by the United States Department of Defense
(DoD) for certification and accreditation of
an Automated Information System (AIS)
that will maintain the Information
Assurance (IA) posture of the Defense
Information Infrastructure (DII) throughout
the system's life cycle.
• DIACAP replaced the former process,
known as DITSCAP (Department of Defense
Information Technology Security
Certification and Accreditation Process).
CISSP -Security Architecture & Models Slide: 63
 DIACAP

• DIACAP applies to the acquisition,

operation and sustainment of any DoD
system that collects, stores, transmits, or
processes unclassified or classified
information since December 1997.
• It identifies four phases:
­ System Definition
­ Verification
­ Validation
­ Re-Accreditation

CISSP -Security Architecture & Models Slide: 64

 NIACAP

• NIACAP (The National Information

Assurance Certification and Accreditation
Process) is the minimum-standard process
for the certification and accreditation of
computer and telecommunications systems
that handle U.S. national-security
information.
• NIACAP is derived from the Department of
Defense Certification and Accreditation
Process (DITSCAP).

CISSP -Security Architecture & Models Slide: 65

 Open versus Closed Systems
• Open Systems: Vendor-Independent
­ Architecture has been published
~ Allows third-party add-ons
­ Provides interoperability between products
~ Common standards provide interoperability
› Windows, Macs and Unix are open systems????
• Closed Systems: Vendor-Dependent
­ Architecture is secret, proprietary
~ Does not follow industry standard
­ Standard interfaces are not used
~ Can only communicate with similar systems
• Comparison between the two
­ Closed is more secure: (ISC)2
~ Fewer doorways, tools, people who understand it
­ Open is more secure: (Real)
~ More tools, people who understand:
› Back Doors can be found -- then closed

CISSP -Security Architecture & Models Slide: 66

 State Machine Models

• A finite state machine (FSM) or

finite state automaton (plural:
automata), or simply a state
machine, is a model of
behavior composed of a finite
number of states, transitions
between those states, and
actions.
• It is similar to a "flow graph"
where we can inspect the way
in which the logic runs when
certain conditions are met.
­ Close and open the door.

CISSP -Security Architecture & Models Slide: 67

 State Machines and Secure State

• A secure state is a term to describe where entities

in an computer system are divided into subjects
and objects, and it can be formally proven that
each state transition preserves security by moving
from one secure state to another secure state.
­ Access to objects by subjects must be authorized.
• The secure state is built on the concept of a state
machine with a set of allowable states in a system.
• A system state is defined to be "secure" if the only
permitted access modes of subjects to objects are
in accordance with a security policy, e.g., access
control policy.
• Maintaining the security of a state is performed
when the system ensures that subjects can only
access objects according to the security policy.

CISSP -Security Architecture & Models Slide: 68

 Access Control Policy for
Subjects to Objects

Subjects can’t be in other states than provided in the figure

above.

CISSP -Security Architecture & Models Slide: 69

 State Transitions and Secure States

• The state of a system is nothing more than a

snapshot of the system in one moment of time.
• There are many activities occurring in the system
that can alter this state, and when they occur we
get state transitions.
• We must identify all possible state transitions that
may occur in the system.
• If the developers of a state machine can validate
that the system starts up in a secure state, and any
state transitions that occur do not put the system
into an insecure state, then the system is said to
be operating in a secure state model.
­ E.g. State transitions do not allow a subject to access
objects in an unauthorized manner.

CISSP -Security Architecture & Models Slide: 70

 Bell-La Padula Model (1)

• The U.S. Military created the Bell-LaPadula

model in the 1970s when they were
concerned about the security of their time-
sharing mainframe systems.
• Security of these systems and leakage of
classified information were of utmost
importance; hence the model’s main goal
was to prevent secret information from
being accessed in an unauthorized manner.
• The Bell-La Padula Model is a state
machine model used for enforcing access
control in government and military
applications.

CISSP -Security Architecture & Models Slide: 71

 Bell-La Padula Model (2)

• The Bell-La Padula model focuses on data

confidentiality and controls access to
classified information.
• In this model, the entities in an information
system are divided into subjects and
objects.
• The notion of a "secure state" is applied.

CISSP -Security Architecture & Models Slide: 72

 Bell-La Padula Model (3)
Classification
• The model is a formal state
transition model of computer Top secret
security policy that
describes a set of access
control rules which use
security labels on objects
and clearances for subjects.
­ Security labels (or Secret
classifications) from Military
range from the most sensitive
(e.g."Top Secret"), down to the
least sensitive (e.g.,
"Unclassified" or "Public"), e.g.,
Top secret, Secret, Unclassified. Unclassified
­ Clearances for subjects mean
formal authorisation of a subject
to access objects.

CISSP -Security Architecture & Models Slide: 73

 Bell-La Padula Model (4)

• The classifications form a lattice for

access, which contains an upper and a
lower bound of authorized access.
­ For example, a user who has top secret
clearance can access top secret, secret, and
unclassified data.
­ Top secret is the upper bound and unclassified
is the lower bound.
• According to the model, the user’s
clearance is compared to the object’s
classification; if the clearance is higher or
equal to the object’s classification, then the
user can access the object (without
violating the security policy).
• Bell-La Padula is MAC.

CISSP -Security Architecture & Models Slide: 74

 Bell-La Padula Model (5)
• There are two main rules to enforce the
model
­ The Simple Security Property - a subject at a
given level may not read an object at a higher
level (no read-up).
­ The *-property (read "star"-property) - a subject at
a given level must not write to any object at a
lower level (no write-down). The *-property is also
known as the Confinement property.
Top secret

Secret

Unclassified

CISSP -Security Architecture & Models Slide: 75

 Multilevel Security
• Multilevel security (abbreviated as MLS) is the
application of a computer system to process
information with different sensitivities (i.e., at
different security classifications), permit
simultaneous access by users with different security
clearances and needs-to-know, and prevent users
from obtaining access to information for which they
lack authorization.
• MLS allows easy access to less-sensitive
information by higher-cleared (higher clearance)
individuals, and it allows higher-cleared individuals
to easily share sanitized documents with less-
cleared individuals.
­ A sanitized document is one that has been edited to remove
information that the less-cleared individual is not allowed to
see.
• Bell-La Padula Model is an example of the multilevel
security.

CISSP -Security Architecture & Models Slide: 76

 Biba Model

• Biba was created after Bell-La Padula.

• Biba addresses the integrity of data.
• In general the model was developed to
circumvent a weakness in the Bell-
LaPadula which only addresses data
confidentiality.

CISSP -Security Architecture & Models Slide: 77

 Biba Model
• To enforce the model, Biba provides two
main rules:
­ No write up - A user cannot write data to an
object at a higher integrity level
~ Users can only create content at or below their own
integrity level
­ No read down - A user cannot read data from a
lower integrity level
~ Users can only view content at or above their own
integrity level

CISSP -Security Architecture & Models Slide: 78

 Clark-Wilson Model
• The Clark-Wilson model is used to provide for
integrity of systems, but does so using an entirely
different approach from the Biba model:
­ Object access via trusted programs
­ Separation of duties
• Users cannot access and manipulate objects
directly, but instead must access an object
through a trusted program.
­ This provides a layer of protection between the user and
the object and further restricts the type of actions that can
take place on that object, which further protects the
objects’ integrity.
• Separation of duties divides an operation into
different parts and requires different users to
perform each part.
­ This makes it harder to do unauthorized changes on an
object because each person has separate duty clearly
defined.
CISSP -Security Architecture & Models Slide: 79
 Information Flow
• Information flow in an information Classification/Level
theoretical context is the transfer
of information from a variable x to
a variable y in a given process. Not Top secret
all flows may be desirable. For
example, a system shouldn't leak
any secret (partially or not) to
public observers.
• The security levels can be viewed
as a lattice with information
flowing only upwards in the lattice. Secret
• For example, considering two
security levels L and H (low and
high), if L <= H, flows
­ from L to L,
­ from H to H, and
­ from L to H would be allowed, while
flows from H to L would not. Unclassified

Information is accessible by individuals

with the assigned clearance
CISSP -Security Architecture & Models Slide: 80
 Threats to
Security Architectures & Models

CISSP -Security Architecture & Models Slide: 81

 Covert Channel

• A covert channel is a type of computer security

attack that creates a capability to transfer
information of objects between processes that are
not supposed to be allowed to communicate by the
computer security policy.
• A covert channel is a way for an entity to receive
information in an unauthorized manner.
• TCSEC uses this term to specifically refer to ways of
transferring information in a higher classification
compartment (level) to a lower classification.
• In a shared processing environment, it is difficult to
completely insulate one process from another to
reduce the effects one process can have on the
other. Thus the covert channel between the two
processes could possibly take place.

CISSP -Security Architecture & Models Slide: 82

 Two Kinds of Covert Channels

• Storage channels - One process writes data

to a storage location and another process
directly, or indirectly, reads it.
• Timing channels – One process relays
information to another by modulating its
use of system resources
­ Accessing the hard drive
­ Using excessive CPU cycles
­ Head placement on hard drive track
• TCSEC requires analysis of storage
channels to classify a system of evaluation
as a B2 system and analysis of timing
channels is a requirement for a B3 system.
• ITSEC and Common criteria also require
the covert channel analysis.

CISSP -Security Architecture & Models Slide: 83

 Residual Information in Memory
(Object Reuse)
• When memory is allocated to a process it is
eventually deallocated when the service completes
its task, and may be reallocated to yet another
process and so on.
• It is quite possible and very probable that residual
information may remain when a section of memory
is reassigned to a new process after a previous
process is finished with it. This situation can lead
to an unauthorised access to the residual
information, .i.e., security violation.
• To mitigate this type of problem, the system must
ensure that memory is zeroed out or completely
overwritten before it can be accessed by any new
process.

CISSP -Security Architecture & Models Slide: 84

 Object Reuse

• The memory issue above is called “object

reuse” (residual information in memory)
which is defined as classes (security
requirements) in TCSEC, ITSEC, and
common criteria.
• The main concept is
­ In many TOEs there will be requirements to
ensure that resources such as main memory and
areas of disk storage can be reused while
preserving security.
~ Important data remaining in such resources should not
be accessible by unauthorised persons.

CISSP -Security Architecture & Models Slide: 85

 Input and Parameter Checking

• When data is inputted into a system, there is

a possibility that the data is outside the
proper value of the parameter.
• For example, if a field to be populated is one
requiring the entry of a phone number, the
system would expect to receive something
like (602)555-1234. What would happen
when a value of 555-5555-55555555-5555-
5555-5555 or a value of 10,000 bytes of code
is inputted into the system?
­ The system might crash (DoS), or worse
­ A buffer-overflow condition might exist that may
allow a savvy attacker to gain complete system
control.
• To mitigate, always perform input checking.

CISSP -Security Architecture & Models Slide: 86

 Backdoors

• Developers insert software mechanisms

that enable them to gain system access
without going through the access control
mechanism of the software.
• This piece of code is called “backdoors or
trapdoors”.
• Unfortunately, the developers forget to
remove the backdoors when the program
enters production mode.
• Now, anyone who discovers the backdoor
can easily gain unauthorized access.

CISSP -Security Architecture & Models Slide: 87

 Maintenance Hooks

• A special type of backdoor/trapdoor is

called a maintenance hook.
• Maintenance hooks are considered a
proper mechanism (piece of code) that the
system provides to quickly update and
improve operations during system
development.
• Maintenance hooks normally circumvent
the usual authorization check.
• Maintenance hooks are usually not defined
in the design specifications and frequently
allow system entry at unusual points.
• Unfortunately, they are occasionally
accidentally left in production systems
without removal.
CISSP -Security Architecture & Models Slide: 88
 Countermeasures to Backdoors and
Maintenance hooks
• Countermeasures to backdoors and
maintenance hooks include:
­ Perform code reviews and unit and integration
testing and always look out for backdoors.
­ Use a host intrusion detection system to detect
backdoors (for those well-known backdoors).
­ Use file integrity checkers to protect
configuration files and sensitive information
from being modified (by the backdoors).
­ Use strict access control mechanisms (e.g., not
to allow unauthorised users to install software
which implies to backdoors also).

CISSP -Security Architecture & Models Slide: 89

 Timing Issues and TOC/TOU
• Look at the process to start up a
system which has a series of steps to
do.
• Note the step for checking for
config.sys file.
• If there is no config.sys file, the
system will continue to boot. If there
is a config.sys file, the system will
load it into memory and begin to
process each instruction in the file
sequentially.
• There is a timing difference from
when the system checks to see if a
config.sys file exists and actually
accesses and opens the file.
• TOC/TOU (Time of check/Time of use)
attack could conceivably replace the
config.sys file with a different
config.sys file that could compromise
the system.

CISSP -Security Architecture & Models Slide: 90

 Race Conditions
• TOC/TOU attacks are also called Race Conditions.
• Programming flaws could lead to the race
condition problem.
• Take a look at an example: a script to rebuild an
access control list (ACL) from a database each
night to control who gets to access the payroll
system.
• One way to update the list would be to remove the
existing ACL, then go through all the entries in the
employee database to find out who has the special
payroll access flag on their account. Those who do
are added to the new ACL.
• Think of the timing between the list being removed
and the list coming back. This gap of time even
very short could mean that the payroll system is pr
obably wide open for anyone to use/access.

CISSP -Security Architecture & Models Slide: 91