Security Evaluation Models and the CISSP
Most organizations these days want their information system to be managed as safely as possible. Security Evaluation is the basic step in achieving this goal for any organization, followed by Assurance and Information Security Certification. Security Evaluation is particularly important because of the rapidly changing environment of the information security system or the operation system.
It is an important part of the CISSP exam and comprises Section 3 of Domain 3 (Security Engineering).
Initially, there were three Security Evaluation Models:
- TCSEC or Trusted Computer System Evaluation Criteria: This is a standard set by DoD (United States Government Department of Defense) regarding basic needs to assess the effectiveness of security controls of companies, which are built into computer systems. It was used for evaluation, classification, and selection of computer systems which were considered to process, store and retrieve classified or sensitive data. It is often referred as the Orange Book and was issued initially in 1983 by NCSC (National Computer Security Center). TCSEC was first updated in 1985.
- ITSEC or Information Technology Security Evaluation Criteria: This is a structured criterion set to evaluate the security of computer systems as well as related products. It was established for the first time in May 1990 based on the work done in the UK, Netherlands, Germany, and France. Consequently, it was started first in these countries. In June 1991, an extensive international review was published (Version 1.2) for operational use in certification and evaluation systems of the Commission of the European Communities. ITSEC evaluation validity has been recognized by many European countries since 1990.
- CTCPEC or Canadian Trusted Computer Product Evaluation Criteria: This standard of computer security was published by the Communications Security Establishment in 1993 to offer an evaluation criterion to different IT products. It can be regarded as a combination of the TCSEC and ITSEC.
All the above three evaluation systems are to some extent obsolete or outdated and currently replaced by a more modern approach known as the Common Criteria model, which offers similarly-defined evaluation levels, implementation of evaluation concept target, as well as the document of Security Target.
The Common Criteria for Information Technology Security Evaluation (Common Criteria)
Common Criteria or CC was prepared predominantly by unifying the above-mentioned pre-existing standards (TCSEC, ITSEC, and CTCPEC) to make sure that companies selling computer-related products for government departments (particularly for use in Defense and Intelligence) may have a standard set to be evaluated against. The development of CC was done jointly by the governments of the UK, the U.S., the Netherlands, Germany, France, and Canada. It is taken as the international standard (ISO/IEC 15408) regarding computer security certification and currently running the revision 4 of version 3.1.
CC is more of a framework where users of the computer systems can state their requirements related to security functions and assurances, i.e. SFRs and SARs respectively by using the Protection Profiles or (PPs). Through PPs the vendors can actually make claims and/or implementations regarding their products’ security attributes. Moreover, evaluation of the products can be done through testing laboratories to determine whether the products are truly meeting the claims. In a real sense, CC provides the assurance that the specification process, its implementation, and evaluation of the products related to computer security have been carried out through rigorous and standard protocols in a repeatable way at a level corresponding or analogous to the target environment for actual use.
The Concept of CC
CC evaluations are done solely on computer security systems and products. The CC evaluation has the following key concepts.
TOE or the Target of Evaluation: This refers to the system or product that is to be evaluated or subject to evaluation. The evaluation process is meant to validate the claims made regarding the target system or product. This can be achieved through:
- PP or Protection Profile: It is a document, produced typically by a single user or a user community that identifies the security needs for any security device class (such as network firewalls or the smart cards used for digital signatures), which is applicable to that user for any definite purpose. The product vendors have the option to choose and implement products complying with one or more PPs. They can then evaluate their products against those chosen PPs. PP will serve as a template for the ST or Security Target of the product in such cases. The ST’s authors may also at least make sure that every requirement also appears in relevant PP’s targeted ST document. Thus, customers wanting particular product types can focus on products those are certified against the PP meeting their needs.
- ST or Security Target: This is the document to identify the target’s security properties for evaluation and it may claim one or more PP’s confirmation. The evaluation of the TOE is done against the Security Functional Requirements or SFRs, which are established in its ST. No more or less evaluation is carried out. Thus, vendors are allowed to tailor the process of evaluation for accurate matching of the proposed capabilities of the products. Moreover, it means that network firewalls do not need to meet the similar functional needs as the database management system. This facilitates various firewalls to be evaluated against entirely different lists of requirements. Usually, the ST is published, allowing potential customers to decide on the specific security features certified through the evaluation.
- SFRs or Security Functional Requirements: This specifies security functions for individuals that any product may provide. For such functions, a standard catalog is usually presented by the CC. For instance, how a user will act in any specific role that may be authenticated will be stated in the SFR. Even if there are two targets representing the same product type, the SFRs list can vary widely from one evaluation to the next. Even though SFRs are not prescribed by CC, it is still included in the ST as it helps to identify dependencies in cases when the right operation of one function (the ability to limit access as per roles) is dependent on another (the ability to identify roles of individuals).
The process of evaluation attempts to establish the confidence level which may be placed on the security features of the product by different processes of quality assurance:
- SARs or Security Assurance Requirements: This is the descriptions or detailing of the measures taken while developing and evaluating the product to ensure its compliance with the security functionality claimed. For instance, in an evaluation, it may be required that full functional testing is done, or every source code to be kept in a change management system. A catalog for these aspects is provided by the CC where the needs may vary between different evaluation processes. All the requirements for any specific product or target are respectively documented in the PP and ST.
- EAL or Evaluation Assurance Level: This is a numerical rating that describes the rigor of an evaluation process. Every EAL comprises of security assurance requirement (SARs) packages to cover the total process of a product development, with a given strictness level. There are seven levels listed in CC, the most basic being the EAL 1. It is also the cheapest level to implement and evaluate any product. Likewise, the EAL 7 is the most stringent and costliest level to implement. In general, authors of ST or PP do not individually select assurance requirements. Instead, they choose one for the whole package, perhaps ‘augmenting’ the needs of a few areas with that from a higher level. It is important to note that higher EALs not always necessarily imply “better security”. Higher levels only signify that the claimed TOE security assurance has been verified more extensively.
To date, most of the PPs and evaluated, certified products or STs are related to IT components (such as smart cards, operating systems or firewalls). CC certification is therefore often specified under IT procurement. There are however other product standards, including user training, system management, supplement CCs and interoperation.
It is to be noted that cryptographic implementation details within the TOE are not within the scope of the CC. National standards such as FIPS 140-2 give cryptographic module specifications. Similarly, there are other different standards in use specifying the cryptographic algorithms.
In recent times, cryptographic requirements are included by PP authors for evaluations of CC which typically would be covered through FIPS 140-2 evaluations. This broadens the bounds regarding the CC by scheme-specific interpretations.
EAL-based evaluations are getting phased out by a few national evaluation schemes and now only evaluate products that claim strict accordance with any approved PP. However, the U.S. government only allows evaluations which are based on PP, whereas Canadian government is currently working to phase out the EAL-based evaluations.
CC is regarded as the foundation for certification schemes driven by governments, and evaluations are typically conducted to be utilized by the agencies of the Federal Government and other critical infrastructures.
Moreover, CC allows comparison between independent security evaluation results by offering a common set of requirements related to IT product’s security functionality. It also provides assurance measures concerning these IT products at the time of security evaluation. The IT products can be implemented in software, firmware or hardware.
Network Security Evaluation Model Based on Cloud Computing
In recent times, cloud computing evolved as one of the most important innovations in the current models of computing. But, currently, the critical problem faced by cloud computing is the issue regarding security. At present, the network environment relies on a single terminal for checking malicious viruses such as Trojans. This process is increasingly considered unreliable. Thus, current evaluation processes are employing models that emphasize real-time evaluation of network risks in cloud computing. A cloud computing based network security evaluation builds on the hierarchical indicator system of quantitative measurement and unified evaluation knowledge and information base.
In Domain 3 of the CISSP exams there is a section named “Select controls and countermeasures based upon systems security evaluation models” that covers in detail the security evaluation models.