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
Top Related