The
Common Criteria for Information Technology Security
Evaluation (abbreviated as
Common
Criteria or
CC) is an
international standard (
ISO/
IEC 15408) for
computer security certification.
It is currently in version 3.1.
Common Criteria is a framework in which computer system users can
specify their security
functional and
assurance requirements, vendors can then
implement and/or make claims about the security attributes
of their products, and testing laboratories can
evaluate
the products to determine if they actually meet the claims. In
other words, Common Criteria provides assurance that the process of
specification, implementation and evaluation of a computer security
product has been conducted in a rigorous and standard manner.
Key concepts
Common Criteria evaluations are performed on computer security
products and systems.
- Target Of Evaluation (TOE) - the product or
system that is the subject of the evaluation.
The evaluation serves to validate claims made about the target. To
be of practical use, the evaluation must verify the target's
security features. This is done through the following:
- Protection Profile
(PP) - a document, typically created by a user or user
community, which identifies security requirements for a class of
security devices (for example, smart
cards used to provide digital
signatures, or network firewalls)
relevant to that user for a particular purpose. Product vendors can
choose to implement products that comply with one or more PPs, and
have their products evaluated against those PPs. In such a case, a
PP may serve as a template for the product's ST (Security Target,
as defined below), or the authors of the ST will at least ensure
that all requirements in relevant PPs also appear in the target's
ST document. Customers looking for particular types of products can
focus on those certified against the PP that meets their
requirements.
- Security Target
(ST) - the document that identifies the security
properties of the target of evaluation. It may refer to
one or more PPs. The TOE is evaluated against the SFRs (see below)
established in its ST, no more and no less. This allows vendors to
tailor the evaluation to accurately match the intended capabilities
of their product. This means that a network firewall does not have
to meet the same functional requirements as a database management system, and that different
firewalls may in fact be evaluated against completely different
lists of requirements. The ST is usually published so that
potential customers may determine the specific security features
that have been certified by the evaluation.
- Security Functional Requirements (SFRs) -
specify individual security functions which may be
provided by a product. The Common Criteria presents a standard
catalogue of such functions. For example, an SFR may state
how a user acting a particular role might be authenticated. The list of SFRs can vary from
one evaluation to the next, even if two targets are the same type
of product. Although Common Criteria does not prescribe any SFRs to
be included in an ST, it identifies dependencies where the correct
operation of one function (such as the ability to limit access
according to roles) is dependent on another (such as the ability to
identify individual roles).
The evaluation process also tries to establish the level of
confidence that may be placed in the product's security features
through
quality assurance
processes:
- Security Assurance Requirements (SARs) -
descriptions of the measures taken during development and
evaluation of the product to assure compliance with the claimed
security functionality. For example, an evaluation may require that
all source code is kept in a change management system, or that full
functional testing is performed. The Common Criteria provides a
catalogue of these, and the requirements may vary from one
evaluation to the next. The requirements for particular targets or
types of products are documented in the ST and PP,
respectively.
- Evaluation
Assurance Level (EAL) - the numerical rating
describing the depth and rigor of an evaluation. Each EAL
corresponds to a package of security assurance requirements (SARs,
see above) which covers the complete development of a product, with
a given level of strictness. Common Criteria lists seven levels,
with EAL 1 being the most basic (and therefore cheapest to
implement and evaluate) and EAL 7 being the most stringent
(and most expensive). Normally, an ST or PP author will not select
assurance requirements individually but choose one of these
packages, possibly 'augmenting' requirements in a few areas with
requirements from a higher level. Higher EALs do not
necessarily imply "better security", they only mean that the
claimed security assurance of the TOE has been more extensively
validated.
So far, most PPs and most evaluated STs/certified products have
been for IT components (e.g., firewalls,
operating systems, smart cards).Common
Criteria certification is sometimes specified for IT procurement.
Other standards containing, e.g., interoperation, system
management, user training, supplement CC and other product
standards. Examples include the
ISO 17799
(Or more properly BS 7799-2, which is now
ISO/IEC 27002) or the German
IT-Grundschutz.
Details of cryptographic implementation within the TOE are outside
the scope of the CC. Instead, national standards, like
FIPS 140-2 give the specifications for
cryptographic modules, and various standards specify the
cryptographic algorithms in use.
History
CC originated out of three standards:
- ITSEC - The European
standard, developed in the early 1990s by France
, Germany
, the
Netherlands
and the UK
. It too was a unification of earlier work,
such as the two UK approaches (the CESG
UK
Evaluation Scheme aimed at the Defence/Intelligence market and the
DTI Green Book
aimed at commercial use), and was adopted by some other countries,
e.g. Australia.
- CTCPEC - The Canadian standard followed
from the US DoD standard, but avoided several problems and was used
jointly by evaluators from both the U.S. and Canada. The CTCPEC
standard was first published in May 1993.
- TCSEC - The United
States Department of Defense
DoD 5200.28 Std, called the Orange
Book and parts of the Rainbow
Series. The Orange Book originated from Computer
Security work including the Ware Report, done by the National
Security Agency
and the National Bureau of Standards (the NBS
eventually became NIST) in the
late 1970s and early 1980s. The central thesis of the Orange
Book follows from the work done by Dave Bell and Len Lapadula for a
set of protection mechanisms.
CC was produced by unifying these pre-existing standards,
predominantly so that companies selling computer products for the
government market (mainly for Defence or Intelligence use) would
only need to have them evaluated against one set of standards. The
CC was developed by the governments of Canada, France, Germany, the
Netherlands, the UK, and the U.S.
Testing organizations
All testing laboratories must comply with
ISO
17025, and certification bodies will normally be approved
against either ISO/IEC Guide 65 or BS EN 45011.
The compliance with
ISO 17025 is typically
demonstrated to a National approval authority:
Mutual recognition arrangement
As well as the Common Criteria standard, there is also a sub-treaty
level Common Criteria MRA (Mutual Recognition Arrangement), whereby
each party thereto recognizes evaluations against the Common
Criteria standard done by other parties. Originally signed in 1998
by Canada, France, Germany, the United Kingdom and the United
States, Australia and New Zealand joined 1999, followed by Finland,
Greece, Israel, Italy, the Netherlands, Norway and Spain in 2000.
The Arrangement has since been renamed
Common Criteria
Recognition Arrangement (
CCRA) and
membership continues to expand. Within the CCRA only
evaluations up to EAL 4 are mutually recognized (Including
augmentation with flaw remediation). The European countries within
the former ITSEC agreement typically recognize higher EALs as well.
Evaluations at EAL5 and above tend to involve the security
requirements of the host nation's government.
Issues
Requirements
Common Criteria is very generic; it does not directly provide a
list of product security requirements or features for specific
(classes of) products: this follows the approach taken by
ITSEC, but has been a source of debate to those used
to the more prescriptive approach of other earlier standards such
as
TCSEC and
FIPS
140-2.
Value of certification
If a product is Common Criteria certified, it does not necessarily
mean it is completely secure. For example, various
Microsoft Windows versions, including
Windows Server 2003 and
Windows XP,
have been
certified at EAL4+, but regular security patches for security
vulnerabilities are still published by Microsoft for these Windows
systems. This is possible because the process of obtaining a Common
Criteria certification allows a vendor to restrict the analysis to
certain security features and to make certain assumptions about the
operating environment and the strength of threats, if any, faced by
the product in that environment. In this case, the assumptions
include A.PEER:
Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints. The TOE is applicable to networked or distributed environments only if the entire network operates under the same constraints and resides within a single management domain. There are no security requirements that address the need to trust external systems or the communications links to such systems.
as contained in the
Controlled Access Protection Profile (CAPP) to which
their STs refer. Based on this and other assumptions, which are not
realistic for the common use of general-purpose operating systems,
the claimed security functions of the Windows products are
evaluated. Thus they should only be considered secure in the
assumed, specified circumstances, also known as the
evaluated
configuration, specified by Microsoft.
Whether you run Microsoft Windows in the precise evaluated
configuration or not, you should apply Microsoft's security patches
for the vulnerabilities in Windows as they continue to appear. If
any of these security vulnerabilities are exploitable in the
product's evaluated configuration, the product's Common Criteria
certification should be voluntarily withdrawn by the vendor.
Alternatively, the vendor should re-evaluate the product to include
application of patches to fix the security vulnerabilities within
the evaluated configuration. Failure by the vendor to take either
of these steps would result in involuntary withdrawal of the
product's certification by the certification body of the country in
which the product was evaluated.
The certified Microsoft Windows versions remain at EAL4+ without
including the application of any Microsoft security vulnerability
patches in their evaluated configuration. This shows both the
limitation and strength of an evaluated configuration.
Criticisms
In August 2007,
Government Computing News
columnist
William Jackson critically
examined Common Criteria methodology and its US implementation by
the Common Criteria Evaluation and Validation Scheme (CCEVS). In
the column executives from the security industry, researchers, and
representatives from the National Information Assurance Partnership
(NIAP) were interviewed. Objections outlined in the article
include:
- Evaluation is a costly process (often measured in hundreds of
thousands of US dollars) -- and the vendor's return on that
investment is not necessarily a more secure product
- Evaluation focuses primarily on assessing the evaluation
documentation, not on the actual security, technical correctness or
merits of the product itself. For U.S. evaluations, only at EAL5
and higher do experts from the National Security Agency participate
in the analysis; and only at EAL7 is code analysis required.
- The effort and time necessary to prepare evaluation evidence
and other evaluation-related documentation is so cumbersome that by
the time the work is completed, the product in evaluation is
generally obsolete
- Industry input, including that from organizations such as the
Common Criteria Vendor's
Forum, generally has little impact on the process as a
whole
In a 2006 research paper, computer specialist
David A. Wheeler suggested that the Common Criteria
process discriminates against Free and Open Source Software
(
FOSS)-centric organizations and development
models. Common Criteria assurance requirements tend to be inspired
by the traditional
waterfall
software development methodology. In contrast, much FOSS software
is produced using modern
agile paradigms. Although some
have argued that both paradigms do not align well, others have
attempted to reconcile both paradigms.
Alternative approaches
Throughout
the lifetime of CC, it has not been universally adopted even by the
creator nations, with, in particular, cryptographic approvals being
handled separately, such as by the Canadian / US implementation of
FIPS-140, and the CESG Assisted
Products Scheme (CAPS) in the
UK.
The UK has also produced a number of alternative schemes when the
timescales, costs and overheads of mutual recognition have been
found to be impeding the operation of the market:
- The
CESG System Evaluation
(SYSn) and Fast Track Approach
(FTA) schemes for assurance of government systems
rather than generic products and services, which have now been
merged into the CESG Tailored Assurance Service
(CTAS)
- The CESG Claims Tested Mark
(CCT Mark), which is aimed at handling less
exhaustive assurance requirements for products and services in a
cost and time efficient manner
See also
References
- Under Attack: Common Criteria has loads of critics, but is
it getting a bum rap Government Computer News, retrieved
2007-12-14
- Free-Libre / Open Source Software (FLOSS) and Software
Assurance
- Wäyrynen, J., Bodén, M., and Boström, G., Security
Engineering and eXtreme Programming: An Impossible
Marriage?
- Beznosov, Konstantin and Kruchten, Philippe, Towards Agile Security Assurance,
retrieved 2007-12-14
- CAPS: CESG Assisted Products Scheme
- Infosec Assurance and Certification Services
(IACS)
External links
Wikis
Quiz
Map
Search