The International Organization for Standardization (ISO) approved (in 1999) standard criteria to evaluate security within the computing industry in a document known as the Common Criteria (CC). A good reference for CC is the www.commoncriteria.org site.
Origins of the Common Criteria
The Common Criteria is the result of the international community's efforts to create criteria to evaluate IT security. In the United States, the Trusted Computer System Evaluation Criteria (TCSEC) was developed in the 1980s and was the basis for efforts in Europe and Canada. In addition, in 1990 ISO began to develop standard evaluation criteria of standardized security.
In 1991, the European Commission (after a joint development by France, Germany, the Netherlands, and the United Kingdom) published the Information Technology Security Evaluation Criteria (ITSEC) v 1.2. In 1993, a combination of ITSEC and TCSEC was created as the Canadian Computer Product Evaluation Criteria (CTCPEC) v 3.0. Shortly after, in the United States, the draft Federal Criteria for Information Technology Security v 1.0 was published as a combination of both North American and European efforts. Finally, in 1999 the ISO adopted a set of common criteria for security evaluation in the CC document that brought all these efforts together.
Common Criteria building blocks
The Common Criteria defines a set of security functional requirements that are grouped into classes. A class is the most general grouping, and all members of the class share security objectives although they may differ in emphasis. CC is also composed of assurance requirements, which in turn are grouped into classes.
The Common Criteria is intended as standard evaluation for security in products. Utilizing these criteria to describe an end-to-end security solution and using them for comparison is difficult because solutions do not use these terms uniformly and combine them in a complex way. However, CC provides a model for security evaluation and an acceptance as a standard security requirement definition. In addition, understanding these criteria may guide you through the selection of security solutions, implementations , and even requirement gathering.
Functional Requirements
The functional requirements are based on the specific requirements to support security, and they define the desired behavior. There are 11 classes of functional requirements that are further divided into families and component criteria. The 11 classes as described in the Common Criteria for Information Technology Security Evaluation documentation are as follows :
Communication: This class is concerned with assuring the identity and non- repudiation of parties in a communication or data exchange.
Component access: This class specifies the requirements for controlling the establishment of a user 's session such as session locking and access history.
Cryptographic support: This class provides support for the life-cycle management of cryptographic keys. In addition, it defines requirements for cryptographic key generation, distribution, access, and destruction.
Identification and authentication: This class specifies requirements for functions to establish and verify a user's identity, which is required to ensure that users are associated with the proper security attributes such as roles and groups.
Security management: This class specifies the management of several aspects such as management of data, security attributes (such as Access Control Lists), and security roles.
Privacy: This class describes the requirements used to satisfy the user's privacy needs and still provide the system flexibility for controls over the operation of the system. Users' privacy can span from complete anonymity to different degrees of accountability.
Protection of security functions: This class addresses the functional requirements related to the integrity and management of security functions and integrity of system data. This is very similar to the user data-protection requirements. The main difference is that the protection of security functions is focused on the system data rather than the user's.
Resource utilization: This class addresses the support for and the availability of required resources such as processing capability. For instance, fault tolerance and priority of services are addressed by this class.
Security audit: This class involves recognizing, recording, storing, and analyzing information related to security-relevant activities.
Trusted path or channel: This class addresses requirements for trusted communication paths between users and the system. These requirements include providing assurance that the user is communicating with the correct system. It also addresses requirements for trusted channel between the system and other systems such as third-party applications.
User data protection: This class specifies the requirements for security functions and policies to protect user data such as access control policies, stored data integrity, and data authentication.
Assurance Requirements
Assurance requirements specify that each operation (or function) needs to meet a minimum level or metric. For example, logging in to a system may require a high level of security. The security assurance requirements are grouped into eight classes. The eight classes as described in the Common Criteria for Information Technology Security Evaluation documentation are as follows:
Configuration management: This class addresses the means for establishing that the functional requirements and specifications are realized in the implementation of the system while controlling changes that occur during development.
Delivery and operation: This class addresses the requirements for correct delivery, installation, generation, and start-up of the system.
Development: This class defines requirements for the stepwise refinement down to the actual implementation of security functions and provides information to determine whether the functional requirements have been met.
Guidance documents: This class addresses the requirements for user and admininstrator guidance documentation.
Life-cycle support: This class addresses the discipline and control in the process of refinement of the system during development and maintenance phases. It includes development security and flaw remediation .
Tests: This class addresses the need to guarantee and verify that the security functional requirements are met. It includes independent tests and functional tests.
Vulnerability assessment: This class addresses the existence of exploitable covert channels, the possibility of misuse or incorrect configuration, and exploitable vulnerabilities (introduced during development and/or operation) of the system.
Assurance maintenance: This class addresses requirements that are aimed to assure the system continues to meet the security requirements after the system or its environment changes. These changes include the discovery of new threats, changes in user requirements, and correction of bugs .
Each of these assurance classes contains families, which share objectives. Each family contains a hierarchy of one or more components . However, the degree of assurance may change for a set of functional requirements. For example, the development process and requirement gathering for a solution impact the degree of severity of potential security vulnerabilities.
Also, the assurance level to which the security objectives are satisfied can be measured from the confidence level that the implementation of security functions is correct and that it actually satisfies the security objectives.
