June
2001
Common
Criteria
The standard to define, assess,
and
measure the security of ICT
products
The TNO-FEL Information Security Evaluation
Facility |
|
TNO Physics and Electronics
Laboratory P.O.Box 96864, 2509 JG The Hague, The
Netherlands |
The TNO-FEL Information Security
Evaluation Facility evaluatesthe security functionality of ICT products.
The
evaluations
are performed in accordance to the international standard Common Criteria for
Information Technology Security Evaluation.
No rights can be derived from the
TNO internet site. Copyright 2001 TNO.
For further information please
contact:
Measuring ICT
security
With the
explosive growth of ICT comes a growing need for secure ICT: that is, ICT that
lets you access vital data when you need it and ensures that this data can
neither be disclosed to nor changed by third parties without your permission.
Unfortunately, these properties of ICT systems (confidentiality, integrity and
availability) are very hard to assess for the typical consumer, and this need
has been traditionally fulfilled by third party assessment: an impartial testing
facility tests a product to determine whether it has certain security
properties. Until now there was no testing standard that was accepted world-wide
leading to every facility testing products in their own, usually secret, way.
This was not a problem if a testing facility disapproved a product as this
disapproval was usually based on a demonstrable vulnerability in the product.
However, when a testing facility approved a product, this approval was very hard
to interpret.
Customers of the product
wondered:
- Which security aspects of the
product were tested?
- How were these aspects
tested?
- Can I trust the testing
facility?
Developers of the product wondered:
- How can I design my product in
such a way that it easily passes testing?
- How can I be sure that my
customers trust the testing facility?
The questions asked by customers and
developers have been recognised internationally and various attempts have been
made to address them by formalising the testing process into formal evaluations.
Two attempts were made to do this:
- TCSEC: Trusted Computer Security
Evaluation Criteria or Orange Book / Rainbow Series by the US in the mid 80’s,
and
- ITSEC: Information Technology
Security Evaluation Criteria by the governments of France, Germany, the
Netherlands and the United Kingdom in the early 90’s
The TCSEC provided a couple
of levels (well-known is level C2) which required specific security
functionality (e.g. an operating system) that was suitable for a specific
environment. The ITSEC provided a couple of assurance levels where the
functionality of the product developer-defined. In the end both proved
unsatisfactory, and the initiatives were combined (together with those of
Australia, Canada and New Zealand) to produce the “Common Criteria for
Information Technology Security Evaluation” (or CC) which also adopted
as ISO/IEC 15408 (2000)
For customers and developers of ICT
products the Common Criteria provide a set of criteria and concrete frameworks
that address the questions in a way that the security aspects of ICT product can
be measured in a repeatable, reproducible, independent way with freedom from
bias of results.
Overview of
the Common Criteria
The Common
Criteria are a mean to define, assess, and measure the security aspects of
ICT products. The Common Criteria supports understanding question on
either 'what it does' (security functionality) and 'how sure you are of
that' (assurance). The Common Criteria are a world-wide standard that
provide: |
 |
- Why?
A framework for functionality
specification that
- allows consumers to
clearly specify their security problem;
- allows developers to
clearly specify their security solution;
- allows consumers to
compare various security solutions for their problem;
- What?
A framework for testing specification
that:
- allows consumers to
define how “sure” they want to know their product is
secure;
- allows developers to know
beforehand what deliverables they need to provide and what the content
of these deliverables should be;
- allows evaluators to
carry out testing in a well-defined way;
- allows evaluators to
unequivocally determine what a product is supposed to
do.
- How?
A set of criteria for testing
facilities (called evaluation facilities) to ensure that these
facilities can perform security testing under a clearly defined quality
system. |
What is an
evaluation?
In a
Common Criteria evaluation an ICT product is evaluated against an
internationally approved set of information security evaluation criteria. The
set of security evaluation criteria of the Common Criteria can be used to
evaluate all types of ICT products. Generally this means that for a specific ICT
product in a Common Criteria evaluation the following aspects are
checked:
- whether the requirements of the
product are defined correctly,
- whether the requirements are
implemented correctly and
- whether the development process
and documentation of the product fulfil certain requirements.
At the same time it provides
a concise set of possible security requirements for products to support the
definition of security functionality in a ICT product.
For Dutch readers we have a
Frequentlty Asked Quaestion list on evaluations? [Dutch FAQ]
Benefits
The Common Criteria offer several potential
advantages to both users and developers of ICT products.
For users the Common Criteria
provide means to compare products of several developers (by means of a so-called
Security Target). In addition, a framework is provided by which users can
specify their security needs in a way that developers can unambigiously
understand (by of a checklist for security requirements resulting in a
protection Profile). By using evaluated products a user has increased assurance
in the security functionality of its products, because an independent expert
opinion is given over the product according to an international recognised set
of criteria.
For developers the Common
Criteria provide means to show the world that he has a adequately secured
product (competitive product advantages). The Common Criteria provide guidance
on the exact information required, interpretation of security requirements and a
framework of specifying what its product provides in security terms. The
independent expert opinion of the product is given on pre-defined public
criteria that indicates how well-organises both the product and the development
process are.
Contents of the
standard
The
documents that together form the Common Criteria consist of three
parts:
- Part 1: Introduction and
General Model. This part is meant for people that have already a clue
about security evaluation. It introduces the general concepts and the format
of the Common Criteria. In this part is described how the Common Criteria are
set up and for who the Common Criteria are meant. It elaborates on the
definition of security functionality, assurance requirements and the
structures of Protection Profiles and Security Targets.
- Part 2: Security Functional
Requirements. This part is meant for users and developers. It establishes
a set of security functional components as a standard way of expressing the
security functional requirements for ICT products. The presented functional
components are to be used in Protection Profiles and Security
Targets.
- Part 3: Security Assurance
Requirements. This part is meant for developers. It defines the assurance
criteria which evaluators use to check fullfillment for developers and their
products. This part intrducuses seven evaluation assurance levels (EALs) that
define the Common Criteria scale for rating evaluation-gained assurance for
products.
Protection Profile and Security
Target
Protection
Profiles and Security Targets, known as PP and ST, are very essential elements
of the Common Criteria framework. When finalized the ST/PP documents are quite
similar. However, they serve different roles in the evaluation
process
- A Protection Profile is a
requirement. It defines a general security problem of a customer or
group of customers. Basically a Protection Profile states: "This is what I
need"
- A Security Target is a
specification. It defines a general solution of a developer for a
security problem . Basically a Security Target states: "This is what I have
built (or will build in the future)".
In the ideal world, a customer writes a
Protection Profile reflecting his security problem and sends this to the world.
One or more developers then produce Security Targets reflecting their solution
to that problem and send it to the customer. Based on this, the consumer selects
one of them and buys the system of that developer.
There exists Protection Profiles
for, for example Firewalls, Operating Systems and Signature Creation Devices.
More Protection Profiles can be found on the NIST registry of (evaluated)
Protection Profiles.
Remarks
The
Common Criteria for Information Technology Security (CC) version 2.1, August,
1999 has been adopted by the International Organization for Standardization
(ISO) as Information Technology - Security techniques - Evaluation criteria
for IT security (ISO 15408) in December 1999.
Besides this document other aspects
like Mutual Recognition (accepting evaluation results from other countries) and
Methodology (a framework for performing evaluations) are still
ongoing.
Download or
browse the current standard
new! The latest version of the
Common Criteria (2.1) is now available in HTML.
You are now able to browse through the common criteria. With permission
of Jim Williams, we present this mirror of the html-based version of the CC. In
case you find bugs, please let him know (jgwilliams@mindspring.com). The "CC
in HTML" is part of a larger effort to stimulate interest in support tools for
the Common Criteria by the US National Information Assurance Partnership (NIAP)
Common Criteria version
2.1 August 1999 |
PDF |
 |
Part 1:
Introduction and general model |
 |
|
Part 2:
Functional Requirements |
 |
|
Part 3:
Assurance Requirements |
 |
|
Common
Evaluation Methodology (CEM) |
Part 1:
Introduction and general model (version 0.6 Draft January
1997) |
 |
|
Part 2:
Evaluation methodology (version 1.0 August1999) |
 |
|
Supplement: Flaw
Remediation (ACL_FLR, version 0.95 Draft, June 2000) |
 |
|
Notes:
- This downloadable version of the
CC is equivallent to ISO 15408 of December 1999.
- The latest updates (interpretions)
on CC and CEM are now available.
- Common Criteria version
2.1
- Part 1 of the CC is meant for
customers and developers who want an initial and general overview of what
the CC comprises.
- Part 2 of the CC is meant for
developers of which are developing a ICT product which will be
evaluated.
- Part 3 of the CC is meant for
developers which are developing a ICT product, and which want to comply
their development process to the CC
- The CEM is guidance information
for evaluators, indication how to apply the requirements of the CC in an
evaluation.
- Part 1 of the CEM is under
public review and the CEM editorial board has this part under construction.
An update is not foreseen before the end of 2001.
- Part 2 of the CEM is meant for
evaluations on the assurance levels EAL1 - EAL4. The CEM editorial board
currently elaborates on a version that covers all assurance levels of the
CC, A soon as a new version is available this will be published on this
site.
- You will need Adobe Acrobat
Reader™ to view and print the documents. If you do not have Adobe Acrobat
Reader™ click here .
Related
links
- Protection Profiles, locations
of registered Protection Profiles