Transcript Slide 1

IS 2620: Developing Secure Systems
Assurance and Evaluation
Lecture 8
March 15, 2012
Reference

Matt Bishop Book

Chapters 18, 19, 21
Trust



Trustworthy entity has sufficient credible evidence
leading one to believe that the system will meet a set of
requirements
Trust is a measure of trustworthiness relying on the
evidence
Assurance is confidence that an entity meets its security
requirements based on evidence provided by the
application of assurance techniques

SDLC, Formal methods, design analysis, testing etc.
3
Relationships
P olicy
Statement of requirement s that explicit ly defines
t he security expect ations of the mechanism(s)
Assurance
P rovides just ification that the mechanism m eet s polic
t hrough assurance evidence and approvals based on
evidence
Mechanisms
Executable entities t hat are designed and implemented
t o meet t he requirements of the policy
Evaluation standards
Trusted Computer System Evaluation Criteria
Information Technology Security Evaluation Criteria
Common Criteria
4
Problem Sources (Neumann)
1.
2.
3.
4.
5.
6.
7.
8.
9.
Requirements definitions, omissions, and mistakes
System design flaws
Hardware implementation flaws, such as wiring and chip flaws
Software implementation errors, program bugs, and compiler
bugs
System use and operation errors and inadvertent mistakes
Willful system misuse
Hardware, communication, or other equipment malfunction
Environmental problems, natural causes, and acts of God
Evolution, maintenance, faulty upgrades, and decommissions
5
Types of Assurance




Policy assurance is evidence establishing security
requirements in policy is complete, consistent,
technically sound
Design assurance is evidence establishing design
sufficient to meet requirements of security policy
Implementation assurance is evidence establishing
implementation consistent with security requirements of
security policy
Operational assurance is evidence establishing system
sustains the security policy requirements during
installation, configuration, and day-to-day operation
6
Waterfall Life Cycle Model
Requirements
definition and
analysis
System and
software
design
Implementation
and unit
testing
7
Integration
and system
testing
Operation
and
maintenance
Other Models of
Software Development

Exploratory programming



Prototyping (Similar to Exploratory)



Develop working system quickly
No requirements or design specification, so low
assurance
Objective is to establish system requirements
Future iterations (after first) allow assurance
techniques
Formal transformation


Create formal specification
Very conducive to assurance methods
8
Models

System assembly from reusable components





Depends on whether components are trusted
Must assure connections, composition as well
Very complex, difficult to assure
This is common approach to building secure and
trusted systems
Extreme programming




Rapid prototyping and “best practices”
Project driven by business decisions
Requirements open until project complete
Components tested, integrated several times
9
Architectural considerations for
assurance

Determine the focus of control of security
enforcement mechanism



Centralized or Distributed




Operating system: focus is on data
Applications: more on operations/transactions
Distribute them among systems/components
Tradeoffs?
Generally easier to “assure” centralized system
Security mechanism may exist in any layer
10
Architectural considerations
Example: Four layer architecture

Application layer


Services/middleware layer



Support services for applications
Eg., DBMS, Object reference brokers
Operating system layer


Transaction control
Memory management, scheduling and process control
Hardware

Includes firmware
11
Trusted Computing Base
(Security an integral part)

Reference monitor (total mediation!)


Reference validation mechanism must be–
1.
2.
3.

Mediates all accesses to objects by subjects
Tamperproof
Never be bypassed
Small enough to be subject to analysis and testing
– the completeness can be assured
Security kernel

Hardware + software implementing a RM
12
Trusted Computing Base


TCB consists of all protection mechanisms
within a computer system that are responsible
for enforcing a security policy
TCB monitors four basic interactions





Process activation
Execution domain switching
Memory protection
I/O operation
A unified TCB may be too large

Create a security kernel
13
Techniques for Design
Assurance

Modularity & Layering





Different layers to capture different levels of abstraction




Well defined independent modules
Simplifies and makes system more understandable
Data hiding
Easy to understand and analyze
Subsystem (memory management, I/O subsystem, credit-card
processing function)
Subcomponent (I/O management, I/O drivers)
Module: set of related functions and data structure
Use principles of secure design
14
Design meets requirements?

Techniques needed


Requirements tracing


To prevent requirements and functionality from being
discarded, forgotten, or ignored at lower levels of design
Process of identifying specific security requirements that
are met by parts of a description
Informal Correspondence

Process of showing that a specification is consistent with
an adjacent level of specification
15
Requirement mapping and informal
correspondence
Security Functional Requirements
External Functional Specification
Internal Design Specification
Requirement
Tracing
Implementation Code
16
Informal
Correspondence
Design meets requirements?

Informal arguments

Protection profiles



Security targets


Identifies mechanisms and provide justification
Formal methods: proof techniques


Define threats to systems and security objectives
Provide rationale (an argument)
Formal proof mechanisms are usually based on logic
(predicate calculus)
Review

When informal assurance technique is used



Reviews of guidelines
Conflict resolution methods
Completion procedures
17
Implementation considerations for
assurance


Modularity with minimal interfaces
Language choice



C vs. Java
Java
Configuration management tools

Control of the refinement and modification of
configuration items such as source code,
documentation etc.
18
Implementation meets Design?

Security testing

Functional testing (FT) (black box testing)


Structural testing (ST) (white box testing)


Testing of an entity to determine how well it meets its
specification
Testing based on an analysis of the code to develop test cases
Testing occurs at different times



Unit testing (usually ST): testing a code module before
integration
System testing (FT): on integrated modules
Security testing: product security



Security functional testing (against security issues)
Security structural testing (security implementation)
Security requirements testing
19
Code development and testing
Code
Unit test
Code
Test the test
On current build
Code
bugs
Integrate tested
test into automated
Test suite
Integrate
Build system
Build test suite
Execute system
Test on current Build
20
Operation and maintenance
assurance


Bugs in operational phase need fixing
Hot fix



Immediate fix
Bugs are serous and critical
Regular fix


Less serious bugs
Long term solution after a hot fix
21
Evaluation
Courtesy of Professors
Chris Clifton & Matt Bishop
22
What is Formal Evaluation?



Method to achieve Trust
 Not a guarantee of security
Evaluation methodology includes:
 Security requirements
 Assurance requirements showing how to establish
security requirements met
 Procedures to demonstrate system meets
requirements
 Metrics for results (level of trust)
Examples: TCSEC (Orange Book), ITSEC, CC
Formal Evaluation: Why?



Organizations require assurance
 Defense
 Telephone / Utilities
 “Mission Critical” systems
Formal verification of entire systems not feasible
Instead, organizations develop formal evaluation
methodologies
 Products passing evaluation are trusted
 Required to do business with the organization
Mutual Recognition
Arrangement
National Information Assurance partnership
(NIAP), in conjunction with the U.S. State
Department, negotiated a Recognition
Arrangement that:



Provides recognition of Common Criteria certificates by
24 nations (was 19 in 2005)
Eliminates need for costly security evaluations in more
than one country
Offers excellent global market opportunities for U.S. IT
industry
An Evolutionary Process
Two decades of research and development…
US-DOD
TCSEC
MSFR
Federal
Criteria
Common
Criteria
1990
1992
1993-98
US-NIST
1983-85
European
National/Regional
Initiatives
1989-93
Europe
Canada
ITSEC
Canadian
Initiatives
TCPEC
1991
1989-93
1993
ISO 15408
Common
Criteria
1999
Common Criteria: Origin
TCSEC


Known as Orange Book, DoD 5200.28-STD
Four trust rating divisions (classes)




D: Minimal protection
C (C1,C2): Discretionary protection
B (B1, B2, B3): Mandatory protection
A (A1): Highly-secure
TCSEC: The Original

Trusted Computer System Evaluation Criteria




Policy model based on Bell-LaPadula
Enforcement: Reference Validation Mechanism



U.S. Government security evaluation criteria
Used for evaluating commercial products
Every reference checked by compact, analyzable
body of code
Emphasis on Confidentiality
Metric: Seven trust levels:


D, C1, C2, B1, B2, B3, A1
D is “tried but failed”
TCSEC Class Assurances

C1: Discretionary Protection




C2: Controlled Access Protection


Identification
Authentication
Discretionary access control
Object reuse and auditing
B1: Labeled security protection


Mandatory access control on limited set of objects
Informal model of the security policy
TCSEC Class Assurances
(continued)

B2: Structured Protections






B3: Security Domains




Trusted path for login
Principle of Least Privilege
Formal model of Security Policy
Covert channel analysis
Configuration management
Full reference validation mechanism
Constraints on code development process
Documentation, testing requirements
A1: Verified Protection


Formal methods for analysis, verification
Trusted distribution
How is Evaluation Done?

Government-sponsored independent
evaluators


Application: Determine if government cares
Preliminary Technical Review




Discussion of process, schedules
Development Process
Technical Content, Requirements
Evaluation Phase
TCSEC: Evaluation Phase

Three phases

Design analysis




Test analysis
Final Review
Trained independent evaluation



Review of design based on documentation
Results presented to Technical Review Board
Must approve before next phase starts
Ratings Maintenance Program

Determines when updates trigger new evaluation
TCSEC: Problems

Based heavily on confidentiality



Did not address integrity, availability
Tied security and functionality
Base TCSEC geared to operating systems


TNI: Trusted Network Interpretation
TDI: Trusted Database management System
Interpretation
Later Standards


CTCPEC – Canada
ITSEC – European Standard









Did not define criteria
Levels correspond to strength of evaluation
Includes code evaluation, development methodology
requirements
Known vulnerability analysis
CISR: Commercial outgrowth of TCSEC
FC: Modernization of TCSEC
FIPS 140: Cryptographic module validation
Common Criteria: International Standard
SSE-CMM: Evaluates developer, not product
ITSEC: Levels

E1: Security target defined, tested


E2: Informal description of design




Structured approach to design
Design level vulnerability analysis
E5: Correspondence between design and code


Configuration control, distribution control
E3: Correspondence between code and security target
E4: Formal model of security policy


Must have informal architecture description
Source code vulnerability analysis
E6: Formal methods for architecture


Formal mapping of design to security policy
Mapping of executable to source code
ITSEC Problems:

No validation that security requirements made
sense



Product meets goals
But does this meet user expectations?
Inconsistency in evaluations

Not as formally defined as TCSEC




Replaced TCSEC, ITSEC
7 Evaluation Levels (functionally tested to
formally designed and tested)
Functional requirements, assurance
requirements and evaluation methodology
Functional and assurance requirements are
organized hierarchically into: class, family,
component, and, element. The components
may have dependencies.
PP/ST Framework
IT Security Requirements
The Common Criteria defines two types of IT
security requirements:
Functional Requirements
Assurance Requirements
- for defining security behavior
of the IT product or system:
• implemented requirements
become security functions
- for establishing confidence in
security functions:
• correctness of implementation
• effectiveness in satisfying
security objectives
Examples:
•Identification & Authentication
•Audit
•User Data Protection
•Cryptographic Support
Examples:
•Development
•Configuration Management
•Life Cycle Support
•Testing
•Vulnerability Analysis
Documentation

Part 1: Introduction and General Model
Part 2: Security Functional Requirements
Part 3: Security Assurance Requirements
CEM

Latest version: 3.1 (variations exist)

http://www.commoncriteriaportal.org/public/expert/index.php?menu=2



Class Decomposition
Class
Family
Components
Note:
Elements
Applicable to both functional and
assurance documents
CC Evaluation 1: Protection
Profile
Implementation independent,
domain-specific set of security
requirements





Narrative Overview
Product/System description
Security Environment (threats,
overall policies)
Security Objectives: System,
Environment
IT Security Requirements



Functional requirements drawn
from CC set
Assurance level
Rationale for objectives and
requirements
CC Evaluation 2: Security
Target
Specific requirements
used to evaluate system



Narrative introduction
Environment
Security Objectives


Security Requirements




How met
Environment and system
Drawn from CC set
Mapping of Function to
Requirements
Claims of Conformance to
Protection Profile
Common Criteria:
Functional Requirements


314 page document
11 Classes



Security Audit, Communication, Cryptography, User
data protection, ID/authentication, Security
Management, Privacy, Protection of Security
Functions, Resource Utilization, Access, Trusted
paths
Several families per class
Lattice of components in a family
Class Example:
Communication

Non-repudiation of origin
1.
2.
Selective Proof. Capability to request verification
of origin
Enforced Proof. All communication includes
verifiable origin
Class Example: Privacy
1.
Pseudonymity
–
–
–
2.
Reversible Pseudonimity
•
3.
The TSF shall ensure that [assignment:
set of users and/or subjects] are unable
to determine the real user name bound
to [assignment: list of subjects and/or
operations and/or objects]
The TSF shall be able to provide
[assignment: number of aliases] aliases
of the real user name to [assignment:
list of subjects]
The TSF shall [selection: determine an
alias for a user, accept the alias from
the user] and verify that it conforms to
the [assignment: alias metric]
…
Alias Pseudonimity
1.
…
Common Criteria:
Assurance Requirements


231 page document
10 Classes



Protection Profile Evaluation, Security Target
Evaluation, Configuration management, Delivery
and operation, Development, Guidance, Life cycle,
Tests, Vulnerability assessment, Maintenance
Several families per class
Lattice of components in family
Common Criteria:
Evaluation Assurance Levels
1.
2.
3.
4.
5.
6.
7.
Functionally tested
Structurally tested
Methodically tested and checked
Methodically designed, tested, and reviewed
Semi-formally designed and tested
Semi-formally verified design and tested
Formally verified design and tested
Common Criteria:
Evaluation Process

National Authority authorizes evaluators



U.S.: NIST accredits commercial organizations
Fee charged for evaluation
Team of four to six evaluators



Develop work plan and clear with NIST
Evaluate Protection Profile first
If successful, can evaluate Security Target
Defining Requirements
ISO/IEC Standard 15408
Protection Profiles
 Operating Systems
Access Control
Identification
Authentication
Audit
Cryptography
A flexible, robust catalogue of
standardized IT security
requirements
(features and assurances)
 Database Systems
 Firewalls
 Smart Cards
 Applications
 Biometrics
 Routers
 VPNs
Consumer-driven security
requirements in specific
information technology areas
Industry Responds
Protection Profile
Security Targets
 CISCO Firewall
Firewall Security
Requirements
Consumer statement of IT security
requirements to industry in a
specific information technology area
Security
Features
and
Assurances
 Lucent Firewall
 Checkpoint Firewall
 Network Assoc. FW
Vendor statements of
security claims for their IT
products
Demonstrating Conformance
Private sector, accredited
security testing laboratories
conduct evaluations
IT Products
Security
Features
and
Assurances
Vendors bring IT products to
independent, impartial testing
facilities for security
evaluation
Common
Criteria
Testing Labs
Test
Reports
Test results submitted to
the National Information
Assurance Partnership
(NIAP) for post-evaluation
validation
Validating Test Results
Validation Body validates
laboratory’s test results
Test
Report
Common
Criteria
Validation
Body
Validation
Report
TM
National Information Assurance
Partnership
Common Criteria
Certificate
Laboratory submits
test report to Validation
Body
NIAP issues Validation
Report and Common
Criteria Certificate
Common Criteria:
Status

About 80 registered products (2005)




Only one at level 5
(Java Smart Card)
Several OS at 4
Likely many more not registered
223 Validated products (Oct, 2007)

Tenix Interactive Link Data Diode Device Version
2.1 at EAL 7+