Common Criteria
From MRL Wiki
ISO/IEC 15408 or The Common Criteria (CC) is an international standard for information technology security. It provides complete methodology for specifying security requirements, designing a security architecture, and verifying the security of a final product. However, CC does not provide a fixed set of product security requirements required to receive the certification. Instead, it is a task of consumers to determine these requirements specific to their needs.
The standard considers several topics out of scope:
- Administrative security measures and procedural controls
- Physical security
- Personnel security
- Use of evaluation results within a wider system assessment
- Qualities of specific cryptographic algorithm.
Contents |
[edit] Major Components
- Protection Profile (PP) - implementation-independent set of security requirements for a product that meets specific consumer needs. This set of specification will be relayed to developers and will serve as a foundation for Security Target.
- Security Target (ST) - implementation-dependent design that incorporates security mechanisms, features, and functions to satisfy requirements as introduced by PP. Consumers will need to choose which one of many possible STs best meets their needs and which one to develop into TOE.
- Target of Evaluation (TOE) - physical implementation of ST. TOE can be a product, system, or network and its associated administrator and user guidance documentation that is the subject of an evaluation.
[edit] Packages
Common Criteria defines a large array of packages. Packages are sets of components combined together to fullfil a specific security objective. They will be used as building blocks to assemble PPs and STs. Two types of packages exist:
- Security Functional Requirements (SFRs) - describe the security behavior expected of a TOE. SFRs are subdivided into 11 Classes, 67 Families, 138 Components, and 250 Elements:
- Security Audit (FAU) - full range of audit needs for small, stand-alone system or devices to large, complex distributed systems.
- Communication (FCO) - security function petraining to the transportation of information such as non-repudiation.
- Cryptographic Support (FCS) - applies to hardware, software, and firmware encryption. It focuses on cryptographic operation and key management, but does not discuss which encryption algorithms or key lengths are acceptable.
- User Data Protection (FDP) - defines a variety of requirements that protect user data.
- Identification and Authentication (FIA) - requirements for performing and managing user identification and authentication functions.
- Security Management (FMT) - requirements for managing TOE security functions and their attributes and data.
- Privacy Requirements (FPR) - protects users from having their identities discovered, misused, or associated with the use of TOE resources.
- Protection of the TOE Security Functions (FPT) - requirements for protecting TOE security functions and TOE security function data.
- Resource Utilization Requirements (FRU) - ensures availability of TOE resources for security functions.
- TOE Access (FTA) - defines different types of access requirements.
- Trusted path/channels FTP - requirements for trusted paths and trusted channels.
- Security Assurance Requirements (SARs) - define criteria for evaluating PPs, STs, and TOEs. SARs are subdivided into 10 Classes, 42 Families, and 93 Components.
- Protection Profile Evaluation (APE) - invoked after a PP has been developed to determine whether a PP is adequate, complete, correct, and consistent.
- Security Target Evaluation (ASE) - invoked after an ST has been developed to determine whether an ST is an adequate, complete, correct, and consistent interpretation of a PP.
- Configuration Management (ACM) - enforces a degree of formality on the development process to prevent the accidental or intentional introduction of security vulnerabilities into TOE.
- Delivary and Operation (ADO) - ensures that no security vulnerabilities are introduced into TOE during the delivery process.
- Development (ADV) - prevents accidental or intentional introduction of security vulnerabilities into TOE during the development process.
- Guidance Documents (AGD) - ensures that system administrators and users have the information they need to use a TOE in a secure fashion.
- Lifecycle Support (ALC) - evaluates the effectiveness of lifecycle processes and procedures used by the developer to prevent and detect the accidental or intentional introduction of security vulnerabilities into TOE.
- Test (ATE) - investigates four dimensions of testing.
- Vulnerability Assessments (AVA) - probes different avenues of potential vulnerabilities.
- Maintenance of Assurance (AMA) - ensures that security assurance is maintained between certification cycles.
[edit] CEM
The Common Methodology for Information Technology Security Evaluation (CEM) was created to provide guidance to evaluators on how to apply and interpet SARs so that evaluations are consistent and repeatable.
[edit] EAL
Evaluation Assurance Levels (EALs) is a grouping of assurance components that represens a point on the predefined assurance scale. The intent of EALs is to ensure that a TOE is not over or underprotected by balancing the level of assurance against cost, schedule, technical, and mission constraints. EALs range from 1 to 7, each progressive EAL adds new and higher assurance components as security objectives become more rigorous:
- EAL 1 - functionality tested, provides a minimum level of confidence in the correct operation of the TOE Security Functions (TSF). It is appropriate for environments where no serious security threats are anticipated.
- EAL 2 - structurally tested, provides a low to moderate level of confidence in the correct operation of the TSF. It is assigned to legacy systems that must be certified long after they were developed and, as a result, little design documentation exists.
- EAL 3 - methodically tested and checked, provides a moderate level of confidence in the correct operation of the TSF. EAL 3 represents a thorough investigation of the TOE and its development, starting at the design phase. Gray-box testing and evaluation are conducted against functions, interfaces, and guidance documents.
- EAL 4 - methodically designed, tested, and reviewed, provides a moderate to high level of confidence in the correct operation of the TSF. EAL 4 represents rigorous commercial development practices supplemented with proactive security engineering.
- EAL 5 - semiformally designed, tested, and reviewed, provides moderate to high level of confidence in the correct operation of the TSF. EAL 5 represents rigorous commercial development and specialized security engineering practices and techniques. EAL 5 is appropriate in environments where resistance to attackers with a moderate attack potential is needed.
- EAL 6 - semiformally verified design and tested, provides a high level of confidence in the correct operation of the TSF. EAL 6 is intended to be used in high-risk environments that must protect high-value assets from attackers with a high attack potential. EAL 6 requires the use of systematic security engineering practices and techniques.
- EAL 7 - formally verified design and tested, provides a very high level of confidence in the correct operation of the TSF. EAL 7 represents complete, independent, white-box testing that employs formal methods, similar to those in use by the safety engineering community. EAL 7 is intended to be used in extremely high-risk environments that must protect high-value assets.
[edit] MRA
Common Criteria received international recognition in 24 countries. Mutual Recognition Arrangement (MRA) was signed to recognize Common Criteria awards certified by any member of this agreement. MRA helped avoid the pitfalls of previous methodologies where a single product had to be certified repeatedly to receive approval in countries with their own product security certification methodologies.