Раздел: Документация
0 ... 35 36 37 38 39 40 41 ... 73 adv hld.4.11c The high-level design shall justify that the TSF mechanisms are sufficient to implement the security functions identified in the high-level design. Evaluator action elements: adv hld.4.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. adv hld.4.2e The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements. ADVJHLD.5 Formal high-level design Dependencies: ADVFSP.4 Formal functional specification ADVRCR.3 Formal correspondence demonstration adv hld.4.1c The presentation of the high-level design shall be semiformal. adv hld.4.2c The high-level design shall be internally consistent. adv hld.4.3c The high-level design shall describe the structure of the TSF in terms of subsystems. adv hld.4.4c The high-level design shall describe the security functionality provided by each subsystem of the TSF. adv hld.4.5c The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. adv hld.4.6c The high-level design shall identify all interfaces to the subsystems of the TSF. adv hld.4.7c The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible. adv hld.4.8c The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing complete details of all effects, exceptions and error messages. adv hld.4.9c The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems. adv hld.4.1oc The high-level design shall justify that the identified means of achieving separation, including any protection mechanisms, are sufficient to ensure a clear and effective separation of TSp-enforcing from non-TSp-enforcing functions. Developer action elements: adv hld.5.1d The developer shall provide the high-level design of the TSF. Content and presentation of evidence elements: adv hld.5.1c The presentation of the high-level design shall be formal. adv hld.5.2c The high-level design shall be internally consistent. adv hld.5.3c The high-level design shall describe the structure of the TSF in terms of subsystems. adv hld.5.4c The high-level design shall describe the security functionality provided by each subsystem of the TSF. adv hld.5.5c The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. adv hld.5.6c The high-level design shall identify all interfaces to the subsystems of the TSF. adv hld.5.7c The high-level design shall identify which of the interfaces to the subsystems of the TSF are externally visible. adv hld.5.8c The high-level design shall describe the purpose and method of use of all interfaces to the subsystems of the TSF, providing complete details of all effects, exceptions and error messages. adv hld.5.9c The high-level design shall describe the separation of the TOE into TSP-enforcing and other subsystems. adv hld.5.10c The high-level design shall justify that the identified means of achieving separation, including any protection mechanisms, are sufficient to ensure a clear and effective separation of TSP-enforcing from non-TSP-enforcing functions. adv hld.5.11c The high-level design shall justify that the TSF mechanisms are sufficient to implement the security functions identified in the high-level design. Evaluator action elements: adv hld.5.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. adv hld.5.2e The evaluator shall determine that the high-level design is an accurate and complete instantiation of the TOE security functional requirements. 10.3 Implementation representation (ADV IMP) Objectives The description of the implementation representation in the form of source code, firmware, hardware drawings, etc. captures the detailed internal workings of the TSF in support of analysis. Component levelling The components in this family are levelled on the basis of the completeness and structure of the implementation representation provided. Application notes The implementation representation is used to express the notion of the least abstract representation of the TSF, specifically the one that is used to create the TSF itself without further design refinement. Source code that is then compiled or a hardware drawing that is used to build the actual hardware are examples of parts of an implementation representation. It is possible that evaluators may use the implementation representation to directly support other evaluation activities (e.g. vulnerability analysis, test coverage analysis, or identification of additional evaluator tests). It is expected that PP/ST authors will select a component that requires that the implementation is complete and comprehensive enough to address the needs of all other requirements included in the PP/ST. ADV IMP.1 Subset of the implementation of the TSF Application notes ADVIMP. 1.1D requires that the developer provide the implementation representation for a subset of the TSF. The intention is that access to at least a portion of the TSF will provide the evaluator with an opportunity to examine the implementation representation for those portions of the TOE where such an examination can add significantly to the understanding of, and assurance in, the mechanisms employed. Provision of a sample of the implementation representation will also allow the evaluator to sample the traceability evidence to gain assurance in the approach taken for refinement, and to assess the presentation of the implementation representation itself. ADVIMP.1.2E element defines a requirement that the evaluator determine that the least abstract TSF representation is an accurate and complete instantiation of the TOE security functional requirements. This provides a direct correspondence between the TOE security functional requirements and the least abstract TSF representation, in addition to the pairwise correspondences required by the ADVRCR family. It is expected that the evaluator will use the evidence provided in ADV RCR as an input to making this determination. The least abstract TSF representation for this component is an aggregate of the implementation representation that is provided and that portion of the low-level design for which no corresponding implementation representation is provided. Dependencies: ADVLLD.1 Descriptive low-level design 0 ... 35 36 37 38 39 40 41 ... 73
|
