Раздел: Документация
0 ... 5 6 7 8 9 10 11 ... 20 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); 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. b)  4.2.2toe evaluation 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. 4.2.3operation 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. 4.3 Security concepts 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. 0 ... 5 6 7 8 9 10 11 ... 20
|
