Transcript Security Architecture & Models

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:
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 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 practices
3. Accepted ways of defining practices
and improving capability
4. 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. Access control models
2. Integrity models
3. 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/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
Subject A
Grant rights to B
Object B
Grant rights to B
Including grant right
Subject A
Subject C
Grant subset of Y on D
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