Common Criteria Article Index for
Common 		Website Links For
Common 		 

Information About

Common Criteria
  CATEGORIES ABOUT COMMON CRITERIA
   
computer security procedures
   
evaluation
   
cissp
   
APPAREL
BABY
BEAUTY
BOOKS
CAR TOYS
CELL PHONES
DVD'S
ELECTRONICS
GOURMET FOOD
GROCERIES
HEALTH & PERSONAL
HOME & GARDEN
JEWELRY
MUSIC
MUSIC INSTRUMENTS
OFFICE PRODUCTS
SOFTWARE
SPORTING GOODS
TOOLS & HARDWARE
TOYS
VIDEO GAMES
SHOPPING HOME
MORE SHOPPING...




KEY CONCEPTS


Common Criteria defines a number of key concepts:
  • A Protection Profile ( PP ) is a document, typically created by a user or user community, which identifies security requirements relevant to that user. A PP effectively defines a class of security devices (for example, smartcards used to provide digital signatures).

  • A Security Target (ST) is a document, typically created by a system developer, that identifies the security capabilities of a particular product and which therefore forms the basis for evaluating that product. Optionally, an ST may claim conformance to one or more PPs; if so the evaluation will examine these claims.

  • The Target Of Evaluation (TOE) is simply the product described in the ST, about which the security claims are made.

  • Security Functional Requirements (SFRs) are descriptions of individual security functions which may be provided by a product. CC presents a standard catalogue of such functions, which are selected by the user or developer when writing STs and PPs. For instance, an SFR may state how a user acting a particular role might be authenticated. 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).

  • Security Assurance Requirements are descriptions of the measures taken during development of the product to assure compliance with the claimed security functionality (for instance, requiring that all source code is kept in a change management system, or that full functional testing is performed). Again, Common Criteria provides a catalogue of these, which are selected when writing a PP or ST.

  • An Evaluation Assurance Level ( EAL ) is a package of Assurance requirements 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 EAL levels ''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., Firewall s, Operating System s, Smart Card s).
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 handbuch.

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

The CC originated out of three standards -- ITSEC , a European standard, developed in the early 1990s by France, Germany, the Netherlands, the UK and also used by some other countries, e.g. Australia; TCSEC (also called the "Orange Book"), the US standard, and CTCPEC , the Canadian standard.

CC was produced by unifying these pre-existing standards, so that companies selling computer products 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 US.


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.


SOME THOUGHTS

So, if a product is ISO 15408 (Common Criteria) certified, does that mean it is very secure? Let's look at an example.

Microsoft Windows 2000 is an ISO 15408 certified product, but regular security patches for security vulnerabilities are still published by Microsoft for Windows 2000. This is possible because the process of getting an ISO 15408 certification allows a vendor to make certain assumptions about the operating environment and the strength of threats, if any, faced by the product in that environment. Based on these assumptions, the claimed security functions of the product are evaluated. Since Microsoft Windows 2000 has been ISO 15408 certified, it should only be considered secure in the assumed, specified circumstances, also known as the evaluated configuration, specified by Microsoft.

Whether you run Microsoft Windows 2000 in the precise evaluated configuration or not, you should apply Microsoft's security patches for the vulnerabilities in Windows 2000 as they continue to appear. If any of these security vulnerabilities are exploitable in the product's evaluated configuration, the product's ISO 15408 certification should be voluntarily withdrawn by the vendor. Alternatively, the vendor should re-evaluate the product to include application of the 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 ISO 15408 certification by the Certification Body of the country in which the product was evaluated.

Microsoft Windows 2000 remains an ISO 15408 certified product, without including the application of any Microsoft security vulnerability patches in its evaluated configuration. This shows both the limitation and strength of an evaluated configuration.


EXTERNAL LINKS