Common Criteria

Ravi Sandhu
Edited by
Duminda Wijesekera

1
Common Criteria: 1998-present
 TSEC retired in 2000, CC became de-
facto standard
 International unification
 CC v2.1 is ISO 15408
 Flexibility
 Separation of
 Functional requirements
 Assurance requirements
 Marginally successful so far
 v1 1996, v2 1998, widespread use ???
2
Common Criteria

3
Class, Family, Component,
Package

4
Security Functional Requirements
 Identification and authentication
 Cryptographic support,
 Security management,
 Protecting ToE access and security functions
 Communication,
 Privacy,
 Trusted paths,
 Channels,
 User data protection,
 Resource utilization
 Audit
 Forensic analysis
5
Security Assurance Requirements
 Life cycle support,
1. Pre requirements: Guidance documents
2. Requirements analysis for consistency and
completeness
3. Vulnerability analysis
4. Secure design
5. Development
6. Testing
 Functional, security specifications
 vulnerability
7. Delivery and operations
8. Maintenance
 Assurance maintenance
 Configuration management

6
CC Methodology
 ToE Security Policy (TSP): set of rules
regulating asset management, protection
and distributed in system
 ToE Security Function (TSF): HW+SW and
firmware used for the correct enforcement
of TSP
 Protection profile (PP): set of (security)
requirments
 Security target (ST): set of (security)
requirements to be used as a evaluation

7
CC Introductory: Section 1 of 8
 ST identification: precisely stated
information required to identify ST
 ST overview: narrative acceptable as
a a standalone description of the ST
 CC Conformance:
 Claim: a statement of conformance to
the CC.
 Part 2 conformance: if using only
functional requirements

8
CC Product/system description:
Section 2 of 8
 Describes the ToE,
 Boundaries
 Logical
 physical
 Scope of evaluation

9
CC Product/system family
environment: Section 3 of 8
 Assumptions of intended usage
 Threat and their agents
 Organizational security policy that
must be adhered to in providing
protection

10
CC Security objective: Section 4 of 8
 Objectives for the product/system:
Traceable to identified threats and/or
organizational policy
 Objectives for the environment: must
be traceable to threats
 not completely encountered by the
system and policies
 or assumptions not completely met by
the system
11
CC IT Security requirements: Section
5 of 8
 Functional security requirements:
from CC
 Security assurance requirements:
must be augmented by the author as
addendums to the EAL

12
CC Product/summary specification:
Section 6 of 8
 A statement of security function and
how these are met as functional
requirements
 A statement of assurance
requirements and how these are met
as

13
CC PP Claims: Section 7 of 8
 Claims of conformance

14
CC Rationale: Section 8 of 8
 Explains various aspects of CC
 Security objective rationale
 Security requirements rationale
 Summary specification rationale
 Rationale for not meeting all
dependencies
 PP claims rationale: explains the
differences between objectives,
requirements and conformance claims
15
Seven Levels of Evaluation
 EAL1: functionally tested
 EAL2: structurally tested
 EAL3: methodically tested and checked
 EAL4: methodically designed, tested and
reviewed
 EAL5: semi-formally designed and tested
 EAL6: semi-formally designed, verified and
tested
 EAL7: formaly verified, designed and tested
16
The evaluation process
 Controlled by C Evaluation
Methodology (CEM) and NIST
 Many labs are accredited by NIST and
charge a fee for evaluation
 Vendor selects a lab to evaluate the
PP
 The vendor and the lab negotiates the
process and a schedule and the lab
issues a rating
17
 Evaluation and testing
 Security must be designed in
 Security can be retrofitted
 Impractical except for simplest systems
Evaluation levels
 Black box

 Gray box

 White box

18
EAL, TSEC and ITSEC

19
Future of Testing
 Continues to evolve
 Quality of Protection (QoP): some
research efforts to measure security
qualitatively.

20
The SSE-CMM Model 1997-present
 System Security Capability Maturity
Model
 A process oriented model for
developing secure systems
 Capability models define
requirements for processes
 CC and its predecessors define
requirements for security

21
SSE-CMM Definitions
 Process capability: the range of
expected results by following the
process
 Process performance: a measure of
the actual results received
 Process maturity: the extent to which
a process is explicitly defined,
managed, measured, controlled and
effective

22
Process areas of SSE-CMM
 Administrator controls
 Assess impact
 Asses threat
 Asses vulnerability
 Build assurance arguments
 Coordinate security
 Monitor system security posture
 Provide security input
 Specify security needs
 Verify and validate security

23
Example: assessing threats
 Identify natural threats
 Identify human threats
 Identify threat units and measures
 Access threat agent capability
 Asses threat likelihood
 Monitor threats and their
characteristics

24
Five capability maturity levels
 Represents process maturity
1. Performed informally: base processes are
performed
2. Planned and tracked: has project-level
definition, planning and performance
verification
3. Well-defined: focused on defining, refining
a standard practice and coordinating
across organization
4. Continuously improving: organizational
capability and process effectiveness
improved.
25