Confidence in IT security can be gained through actions that may be taken during the processes of development, evaluation, and operation.
The CC does not mandate any specific development methodology or life cycle model. Figure 4.3 depicts underlying assumptions about the relationship between the security requirements and the TOE. The figure is used to provide a context for discussion and should not be construed as advocating a preference for one methodology (e.g. waterfall) over another (e.g. prototyping).
It is essential that the security requirements imposed on the IT development be effective in contributing to the security objectives of consumers. Unless suitable requirements are established at the start of the development process, the resulting end product, however well engineered, may not meet the objectives of its anticipated consumers.
Figure 4.3 - TOE development model
The process is based on the refinement of the security requirements into a TOE summary specification expressed in the security target. Each lower level of refinement represents a design decomposition with additional design detail. The least abstract representation is the TOE implementation itself.
The CC does not mandate a specific set of design representations. The CC requirement is that there should be sufficient design representations presented at a sufficient level of granularity to demonstrate where required:
a) that each refinement level is a complete instantiation of the higher levels (i.e. all TOE security functions, properties, and behaviour defined at the higher level of abstraction must be demonstrably present in the lower level);
b) that each refinement level is an accurate instantiation of the higher levels (i.e. there should be no TOE security functions, properties, and behaviour defined at the lower level of abstraction that are not required by the higher level).
The CC assurance criteria identify the design abstraction levels of functional specification, high-level design, low-level design, and implementation. Depending upon the assurance level specified, developers may be required to show how the development methodology meets the CC assurance requirements.
Figure 4.4 - TOE evaluation process
The TOE evaluation process as described in Figure 4.4 may be carried out in parallel with development, or it may follow. The principal inputs to TOE evaluation are:
a) the set of TOE evidence, which includes the evaluated ST as the basis for TOE evaluation;
b) the TOE for which the evaluation is required;
c) the evaluation criteria, methodology and scheme.
In addition, informative material (such as application notes of the CC) and the IT security expertise of the evaluator and the evaluation community are likely to be used as inputs to the evaluation.
The expected result of the evaluation process is a confirmation that the TOE satisfies its security requirements as stated in the ST with one or more reports documenting the evaluator findings about the TOE as determined by the evaluation criteria. These reports will be useful to actual and potential consumers of the product or system represented by the TOE as well as to the developer.
The degree of confidence gained through an evaluation depends on the assurance requirements (e.g. Evaluation Assurance Level) met.
Evaluation can lead to better IT security products in two ways. Evaluation is intended to identify errors or vulnerabilities in the TOE that the developer may correct, thereby reducing the probability of security failures in future operation. Also in preparing for the rigours of evaluation, the developer may take more care in TOE design and development. Therefore, the evaluation process can exert a strong, though indirect, positive effect on the initial requirements, the development process, the end product, and the operational environment.
Consumers may elect to use evaluated TOEs in their environments. Once a TOE is in operation, it is possible that previously unknown errors or vulnerabilities may surface or environmental assumptions may need to be revised. As a result of operation, feedback could be given that would require the developer to correct the TOE or redefine its security requirements or environmental assumptions. Such changes may require the TOE to be re-evaluated or the security of its operational environment to be strengthened. In some instances this may only require that the needed updates are evaluated in order to regain confidence in the TOE. Although the CC contains criteria to cover assurance maintenance, detailed procedures for re-evaluation, including reuse of evaluation results, are outside the scope of the CC.