Transcript Document

CMSC 426-626:
Common Criteria for
Computer/IT Systems
Prof. Krishna Sivalingam
Oct 23, 2006
1
Common Criteria





Commoncriteria.org
Commoncriteriaportal.org
• Lists CC v3.1 (and older versions)
Originally released in 1998
An International Standards Organisation
(ISO) standard for security evaluation of
software products
IT product vendors use the CC as a
benchmark for product security
2
NIAP



National Information Assurance Partnership
(NIAP) is a joint venture between NIST
(nist.gov) and NSA (nsa.gov)
Goal: “increase the level of consumer trust in
information systems and networks” from
http://www.nsa.gov/ia/industry/niap.cfm
One service: Common Criteria Evaluation and
Validation Scheme (CCEVS) that “focuses on
meeting the security testing, evaluation, and
assessment needs of both IT products and
consumers.”
3
Security concepts and relationships
From CC Part 1 (of v3.1)
4
Evaluation concepts & relationships
From CC Part 1 (of v3.1)
5
CC Process




A user creates Packages or “Protection
Profile” for a desired security product
The PP describes the product’s protection
needs
Written by the user (e.g. government,
banking industry, vendor’s marketing group,
product inventor)
Describes security aspects needed in an IT
product
6
CC Protection profile (in Combined
Federal Criteria)

Rationale
•
•
•
•
•

Protection policy and
regulations
Information protection
philosophy
Expected threats
Environmental assumptions
Intended Use


Assurance
•
•
Profile-specific assurances
Profile-independent
assurances
Dependencies
•
•
Internal
External
Functionality
•
•
•
Security Features
Security Services
Available security
mechanisms
7
CC Protection Profile






Introduction
Product/System Family Description: Generic
description of family of products.
Product/System Family Security Environment –
intended use, environment of use, threats to
assets, organizational security policies, etc.
Security Objectives
IT Security Requirements – Functional and
Assurance
Rationale
8
What happens with PP?


A vendor develops an IT product based on
the requirements set in the PP
Vendor then prepares a “security target”
document that describes the security and
assurance aspects of the product.
• Can relate Security Target to Specs. In the
Protection Profile

Security Target can also be written
independent of a PP and sold along with the
IT product
9
CC Package

A package is a named set of security requirements.
A package is either
•
•
•

a functional package, containing only SFRs (Security
Functional Requirements) or
an assurance package, containing only SARs (Security
Assurace Requirements)
But, not both.
Examples of Assurance packages are the EALs
(Evaluation Assurance Level), than run from EAL1
(lowest) through EAL7 (highest)
•
EAL1 through EAL4 are most common
10
Security Target, contd.

From CC, part I:
“The Security Target begins with describing
the assets and the threats to those
assets. The Security Target then describes
the countermeasures (in the form of Security
Objectives) and demonstrates that these
countermeasures are sufficient to counter
these threats: if the countermeasures do
what they claim to do, the threats are
countered.”
11
Security Target (per Comb Fed Crit.)

Rationale
•
•
•
•
•

Implementation
fundamentals
Information protection
philosophy
Countered Threats
Environmental Assumptions
Intended Use


Assurance
•
•
Target-specific assurances
Target-independent
assurances
Dependencies
•
•
Internal
External
Functionality
•
•
•
Security features
Security services
Security mechanisms
selected
12
Security Target










Introduction: description of the target of evaluation (TOE) at three
different abstraction levels
Conformance: If the ST is conformant with any PPs or packages
Security problem definition: Threats, Assumptions, etc.
Security objectives:
Extended components definition: describes components not
described in Part 2 or Part 3 of CC document
Security requirements: Present security objectives in standard
requirements format
TOE Summary specifications: How functional requirements are
implemented and met and how assurance reqts. Are met
Rationale: Sec Objectives Rationale, Sec. Reqts. Rationale, TOE
Summary Spec. Rationale, etc.
Before and during evaluation, ST states “what is to be evaluated?”
After evaluation, ST states “what was evaluated?”
13
From CC Part 1 (of v3.1)
14
Classes in Common Criteria

Functionality (11)
•
•
•
•
•
Security audit (FAU)
Communications (FCO)
Crypto support (FCS)
User data protection (FDP)
Identification &
Authentication (FIA)
•
•
•
•
•
Sec. Mgmt (FMT)
Privacy (FPR)
Protection of trusted
security functions (FPT)
Resource utilization (FRU)
Trusted Path (FTP)
•
TOE Access (FTA)

Assurance (10)
•
•
•
•
•
Configuration Management
Delivery and operation
Development
Guidance documents
Life-cycle support
•
•
•
•
•
Testing
Vulnerability Assessment
Maintenance of Assurance
Protection profile evaluation
Security target evaluation
15
Classes

Classes are broken down into families, which are
broken down into components
16
Classes, contd.
17
Components
18
EAL Levels


EAL1: Functionally Tested
EAL2: Structurally Tested; Applicable to systems
with low-moderate assurance needs, but not
enough development record (e.g legacy systems)
•


Based on High-Level Design Analysis & Sec. Fn. Analysis
EAL3: Methodically Tested & Checked
•
Use of devt. Environment controls and config. Mgt
EAL4: Methodically Designed, Tested & Reviewed
•
•
•
Includes Low-level design, complete interface description,
and subset of implementation
Informal model of security policy
Windows 2000, XP, Red Hat Enterprise Linux (RHEL)
Version 4 Update 1 AS and Red Hat Enterprise Linux
(RHEL) Version 4 Update 1 WS
19
EAL Levels, contd.



EAL5: Semi-formally Designed and Tested
EAL6: Semi-formally Verified Design and
Tested
EAL7: Formally Verified Design and Tested
• Formal functional spec. and high-level design
• Implementation representation be used as testing
•
•
basis
Independent confirmation of developer’s test
results
Extremely high-risk situations and requires
substantial security engineering
20