Evaluation criteria are most useful in the context of the engineering processes and regulatory frameworks that are supportive of secure TOE development and evaluation. This subclause is provided for illustration and guidance purposes only and is not intended to constrain the analysis processes, development approaches, or evaluation schemes within which the CC might be employed.
The CC is applicable when IT is being used and there is concern about the ability of the IT element to safeguard assets. In order to show that the assets are secure, the security concerns must be addressed at all levels from the most abstract to the final IT implementation in its operational environment. These levels of representation, as described in the following subclauses, permit security problems and issues to be characterised and discussed but do not, of themselves, demonstrate that the final IT implementation actually exhibits the required security behaviour and can, therefore, be trusted.
The CC requires that certain levels of representation contain a rationale for the representation of the TOE at that level. That is, such a level must contain a reasoned and convincing argument that shows that it is in conformance with the higher level, and is itself complete, correct and internally consistent. Statements of rationale demonstrating conformance with the adjacent higher level representation contribute to the case for TOE correctness. Rationale directly demonstrating compliance with security objectives supports the case that the TOE is effective in countering the threats and enforcing the organisational security policy.
The CC layers the different levels of representation as described in Figure 4.5, which illustrates the means by which the security requirements and specifications might be derived when developing a PP or ST. All TOE security requirements ultimately arise from consideration of the purpose and context of the TOE. This chart is not intended to constrain the means by which PPs and STs are developed, but illustrates how the results of some analytic approaches relate to the content of PPs and STs.
Figure 4.5 - Derivation of requirements and specifications
The security environment includes all the laws, organisational security policies, customs, expertise and knowledge that are determined to be relevant. It thus defines the context in which the TOE is intended to be used. The security environment also includes the threats to security that are, or are held to be, present in the environment.
To establish the security environment, the PP or ST writer has to take into account:
a) the TOE physical environment which identifies all aspects of the TOE operating environment relevant to TOE security, including known physical and personnel security arrangements;
b) the assets requiring protection by the element of the TOE to which security requirements or policies will apply; this may include assets that are directly referred to, such as files and databases, as well as assets that are indirectly subject to security requirements, such as authorisation credentials and the IT implementation itself;
c) the TOE purpose, which would address the product type and the intended usage of the TOE.
Investigation of the security policies, threats and risks should permit the following security specific statements to be made about the TOE:
a) A statement of assumptions which are to be met by the environment of the TOE in order for the TOE to be considered secure. This statement can be accepted as axiomatic for the TOE evaluation.
b) A statement of threats to security of the assets would identify all the threats perceived by the security analysis as relevant to the TOE. The CC characterises a threat in terms of a threat agent, a presumed attack method, any vulnerabilities that are the foundation for the attack, and identification of the asset under attack. An assessment of risks to security would qualify each threat with an assessment of the likelihood of such a threat developing into an actual attack, the likelihood of such an attack proving successful, and the consequences of any damage that may result.
c) A statement of applicable organisational security policies would identify relevant policies and rules. For an IT system, such policies may be explicitly referenced, whereas for a general purpose IT product or product class, working assumptions about organisational security policy may need to be made.
The results of the analysis of the security environment could then be used to state the security objectives that counter the identified threats and address identified organisational security policies and assumptions. The security objectives should be consistent with the stated operational aim or product purpose of the TOE, and any knowledge about its physical environment.
The intent of determining security objectives is to address all of the security concerns and to declare which security aspects are either addressed directly by the TOE or by its environment. This categorisation is based on a process incorporating engineering judgement, security policy, economic factors and risk acceptance decisions.
The security objectives for the environment would be implemented within the IT domain, and by non-technical or procedural means.
Only the security objectives for the TOE and its IT environment are addressed by IT security requirements.
The IT security requirements are the refinement of the security objectives into a set of security requirements for the TOE and security requirements for the environment which, if met, will ensure that the TOE can meet its security objectives.
The CC presents security requirements under the distinct categories of functional requirements and assurance requirements.
The functional requirements are levied on those functions of the TOE that are specifically in support of IT security, and define the desired security behaviour. Part 2 defines the CC functional requirements. Examples of functional requirements include requirements for identification, authentication, security audit and non-repudiation of origin.
When the TOE contains security functions that are realised by a probabilistic or permutational mechanism (e.g. a password or hash function), the assurance requirements may specify that a minimum strength level consistent with the security objectives is to be claimed. In this case, the level specified will be one of the following SOF-basic, SOF-medium, SOF-high. Each such function will be required to meet that minimum level or at least an optionally defined specific metric.
The degree of assurance can be varied for a given set of functional requirements; therefore it is typically expressed in terms of increasing levels of rigour built with assurance components. Part 3 defines the CC assurance requirements and a scale of evaluation assurance levels (EALs) constructed using these components. The assurance requirements are levied on actions of the developer, on evidence produced and on the actions of the evaluator. Examples of assurance requirements include constraints on the rigour of the development process and requirements to search for and analyse the impact of potential security vulnerabilities.
Assurance that the security objectives are achieved by the selected security functions is derived from the following two factors:
a) confidence in the correctness of the implementation of the security functions, i.e., the assessment whether they are correctly implemented; and
b) confidence in the effectiveness of the security functions, i.e., the assessment whether they actually satisfy the stated security objectives.
Security requirements generally include both requirements for the presence of desired behaviour and requirements for the absence of undesired behaviour. It is normally possible to demonstrate, by use or testing, the presence of the desired behaviour. It is not always possible to perform a conclusive demonstration of absence of undesired behaviour. Testing, design review, and implementation review contribute significantly to reducing the risk that such undesired behaviour is present. The rationale statements provide further support to the claim that such undesired behaviour is absent.
The TOE summary specification provided in the ST defines the instantiation of the security requirements for the TOE. It provides a high-level definition of the security functions claimed to meet the functional requirements, and assurance measures taken to meet the assurance requirements.
The TOE implementation is the realisation of the TOE based on its security functional requirements and the TOE summary specification contained in the ST. TOE implementation is accomplished using a process of applying security and IT engineering skills and knowledge. The TOE will meet the security objectives if it correctly and effectively implements all the security requirements contained in the ST.