1. CMSC 426-626: Common Criteria for Computer/IT Systems
Prof. Krishna Sivalingam
Oct 23, 2006

2. Originally released in 1998
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

3. 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
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.”

4. Security concepts and relationships
From CC Part 1 (of v3.1)

5. Evaluation concepts & relationships
From CC Part 1 (of v3.1)

6. The PP describes the product’s protection needs
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

7. CC Protection profile (in Combined Federal Criteria)
Rationale
Protection policy and regulations
Information protection philosophy
Expected threats
Environmental assumptions
Intended Use
Functionality
Security Features
Security Services
Available security mechanisms
Assurance
Profile-specific assurances
Profile-independent assurances
Dependencies
Internal
External

8. 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

9. 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

10. 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

11. 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.”

12. Security Target (per Comb Fed Crit.)
Rationale
Implementation fundamentals
Information protection philosophy
Countered Threats
Environmental Assumptions
Intended Use
Functionality
Security features
Security services
Security mechanisms selected
Assurance
Target-specific assurances
Target-independent assurances
Dependencies
Internal
External

13. 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?”

14. From CC Part 1 (of v3.1)

15. 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

16. Classes
Classes are broken down into families, which are broken down into components

17. Classes, contd.

18. Components

19. 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

20. EAL5: Semi-formally Designed and Tested
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