United Kingdom, Netherlands, France, Germany and Canada, unifying three stan- dards: the European standard ITSEC (Information Technology Security Evaluation Criteria), the Canadian standard CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) and the United States Government Department of Defense stan- dard TCSEC (Trusted Computer System Evaluation Criteria). CC provides tools for de ning a set of security requirements and for evaluating the security speci cation of a product or a system. These requirements are divided into two categories: security functional components and security assurance components. Functional components de ne functional requirements for the system-to-be. Assurance components help to guarantee that the chosen security requirements correspond to the measures selected and that they are correctly implemented. CC is currently in version 3.1 and is also an international standard (ISO/IEC 15408) related to IS security. However, being focused on IT security of products, CC is not completely aligned with our research scope, i.e. IS security (Section 1.4). The requirements proposed by the standard are product-oriented (i.e., adapted for an IT product like an operating system, a rewall, etc.) but not IS-oriented (i.e., adapted for a whole IS within an organisation) (Section
2.3 Security standards 29
1.5.2). Despite of this, CC is considered in this research work, because it is a major and well-known standard whose terminology and concepts are generally well accepted and represent the foundations for many ISSRM methods.
CC is based on three main concepts: • Protection pro le
A Protection Pro le (PP) is a set of security requirements aiming at reducing IT security risk in a given context. A PP is de ned from the user's viewpoint (iden- tifying the desired properties of a product). It is implementation-independent and meant to be reusable. A user can write his own PP or select an existing one in a catalog. A PP is composed of the speci c security requirements the user is expecting for the product. He can then provide this PP as speci cations to a developer or use it to evaluate and compare existing Commercial O-The-Shelf (COTS) products.
• Security target
A Security Target (ST) is a set of security requirements for a given product, generally from the developer's viewpoint. A ST is speci c to a given product or system. It is a means for a product editor to specify the security characteristics of his product. The ST may claim conformance to one or more PPs, and forms the basis for an evaluation.
• Target of Evaluation
The two preceding tools (PP and ST) are generally used to evaluate existing products or systems. In this case, the term Target of Evaluation (ToE) denotes the evaluated product or system.
CC is built around three main documents:
• Part 1: Introduction and general model [Com06a]
This part de nes the terminology, the general concepts and presents an overview of the underlying model for evaluation: evaluation of PP, ST and ToE. This part also provides the description of the content of a PP and of a ST.
• Part 2: Security functional components [Com06b]
This part de nes a collection of generic security functional requirements divided into classes, themselves broken down into families of components, which for ex- ample cover access control, identi cation, authentication, physical protection, etc. The developer selects the best adapted requirements for his product and instantiates them in the ST. CC also allows stating requirements for families of products within PP.
• Part 3: Security assurance components [Com06c]
This part de nes the assurance requirements, both for the development environ- ment and for the product itself, as well as the tasks for the evaluator. These assurance requirements are organised in classes, then in families of components, which cover functional speci cation and design descriptions, like testing, life cy- cle management, delivery procedures, security of the development environment,
vulnerability analysis, etc. Developers can either build up their own consistent assurance package or use one of the seven prede ned Evaluation Assurance Lev- els (EAL). EAL1 to EAL7 provide an increasing scale that balances the level of assurance obtained on the product security with the cost and feasibility of acquiring that degree of assurance. Each of these levels can be augmented with one or more additional components in order to meet speci c objectives.
The Common Evaluation Methodology [Com07] is a complementary document pre- senting the principles and processes whereby evaluations are conducted using CC. It describes the tasks to be carried out by an evaluator for checking each assurance requirement. CC proposes three dierent but complementary kinds of evaluation:
• PP evaluation: evaluating whether a PP is complete, consistent, technically sound, and hence suitable for use in developing a ST.
• ST evaluation: evaluating whether a ST meets the requirements of one or more PPs.
• ToE evaluation: evaluating if a ToE is conform to the security requirements of its associated ST.
The main advantage of an evaluation following the CC model is that every evalu- ation will be done based on the same reference. This leads to comparable and repro- ductible results. Typical products or systems (ToE) evaluated with CC are operating systems, network components (switch, hub, VPN, etc.) or security products ( rewall, IDS, authentication system, etc.). The current drawbacks of CC evaluations are the cost of the whole evaluation process including the eort and time necessary to prepare an evaluation and associated documentation.
2.4 Security risk management standards
This section presents standards dealing with security that are speci cally focused on RM activities. The ISO/IEC series of standard [ISO05b, ISO05c, ISO08] is focussed on this eld, as other national standards like NIST standards [SHF04, SGF02] and the German BSI standards [Bun05b]. We selected naturally the international standards of this eld, but also the NIST and BSI standards that are well known and used outside of the standard's country [ENI06].