Раздел: Документация
0 ... 38 39 40 41 42 43 44 ... 73 Evaluator action elements: adv int.2.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. adv int.2.2e The evaluator shall determine that both the low-level design and the implementation representation are in compliance with the architectural description. ADV INT.3 Minimisation of complexity Application notes This component requires that the reference monitor property "simple enough to be analysed" is fully addressed. When this component is combined with the functional requirements FPT RVM.1 and FPTSEP.3, the reference monitor concept would be fully realised. Dependencies: ADVIMP.2 Implementation of the TSF ADV LLD.1 Descriptive low-level design Developer action elements: adv int.3.1d The developer shall design and structure the TSF in a modular fashion that avoids unnecessary interactions between the modules of the design. adv int.3.2d The developer shall provide an architectural description. adv int.3.3d The developer shall design and structure the TSF in a layered fashion that minimises mutual interactions between the layers of the design. adv int.3.4d The developer shall design and structure the TSF in such a way that minimises the complexity of the entire TSF. adv int.3.5d The developer shall design and structure the portions of the TSF that enforce any access control and/or information flow control policies such that they are simple enough to be analysed. adv int.3.6d The developer shall ensure that functions whose objectives are not relevant for the TSF are excluded from the TSF modules. Content and presentation of evidence elements: adv int.3.1c The architectural description shall identify the modules of the TSF and shall specify which portions of the TSF enforce the access control and/or information flow control policies. adv int.3.2c The architectural description shall describe the purpose, interface, parameters, and side-effects of each module of the TSF. adv int.3.3c The architectural description shall describe how the TSF design provides for largely independent modules that avoid unnecessary interactions. adv int.3.4c The architectural description shall describe the layering architecture. adv int.3.5c The architectural description shall show that mutual interactions have been minimised, and justify those that remain. adv int.3.6c The architectural description shall describe how the entire TSF has been structured to minimise complexity. adv int.3.7c The architectural description shall justify the inclusion of any non-TSP-enforcing modules in the TSF. Evaluator action elements: adv int.3.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. adv int.3.2e The evaluator shall determine that both the low-level design and the implementation representation are in compliance with the architectural description. adv int.3.3e The evaluator shall confirm that the portions of the TSF that enforce any access control and/or information flow control policies are simple enough to be analysed. 10.5 Low-level design (ADV LLD) Objectives The low-level design of a TOE provides a description of the internal workings of the TSF in terms of modules and their interrelationships and dependencies. The low-level design provides assurance that the TSF subsystems have been correctly and effectively refined. For each module of the TSF, the low-level design describes its purpose, function, interfaces, dependencies, and the implementation of any TSP-enforcing functions. Component levelling The components in this family are levelled on the basis of the degree of formalism required of the low-level design, and on the degree of detail required for the interface specifications. Application notes The term "TSP-enforcing module" refers to any module that must be relied upon for correct enforcement of the TSP. The term "security functionality" is used to represent the set of operations that a module performs in contribution to security functions implemented by the TOE. This distinction is made because modules do not necessarily relate to specific security functions. While a given module may correspond directly to a security function, or even multiple security functions, it is also possible that many modules must be combined to implement a single security function. The ADV LLD.*.6C elements require that the low-level design describe how each TSP-enforcing function is provided. The intent of this requirement is that the low-level design provide a description of how each module is expected to be implemented from a design perspective. The ADVLLD. *.2E elements within this family define a requirement that the evaluator determine that the low-level design 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 low-level design, in addition to the pairwise correspondences required by the ADV RCR family. It is expected that the evaluator will use the evidence provided in ADV RCR as an input to making this determination, and the requirement for completeness is intended to be relative to the level of abstraction of the low-level design. ADVLLD.2.9C introduces a requirement for a complete presentation for the interfaces to the modules. This will provide the necessary detail for supporting both thorough testing of the TOE (using components from ATEDPT), and the assessment of vulnerabilities. In the context of the level of formality of the low-level design, informal, semiformal and formal are considered to be hierarchical in nature. Thus, ADVLLD.1.1C may also be met with either a semiformal or formal low-level design, and ADVLLD.2.1C may also be met with a formal low-level design. 0 ... 38 39 40 41 42 43 44 ... 73
|
