Раздел: Документация
0 ... 33 34 35 36 37 38 39 ... 73 adv fsp.2.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. adv fsp.2.2e The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements. ADV FSP.3 Semiformal functional specification Dependencies: ADVRCR. 1 Informal correspondence demonstration Developer action elements: adv fsp.3.1d The developer shall provide a functional specification. Content and presentation of evidence elements: adv fsp.3.1c The functional specification shall describe the TSF and its external interfaces using a semiformal style, supported by informal, explanatory text where appropriate. adv fsp.3.2c The functional specification shall be internally consistent. adv fsp.3.3c The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing complete details of all effects, exceptions and error messages. adv fsp.3.4c The functional specification shall completely represent the TSF. adv fsp.3.5c The functional specification shall include rationale that the TSF is completely represented. Evaluator action elements: adv fsp.3.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. adv fsp.3.2e The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements. ADV FSP.4 Formal functional specification Dependencies: ADVRCR. 1 Informal correspondence demonstration Developer action elements: adv fsp.4.1d The developer shall provide a functional specification. Content and presentation of evidence elements: adv fsp.4.1c The functional specification shall describe the TSF and its external interfaces using a formal style, supported by informal, explanatory text where appropriate. adv fsp.4.2c The functional specification shall be internally consistent. adv fsp.4.3c The functional specification shall describe the purpose and method of use of all external TSF interfaces, providing complete details of all effects, exceptions and error messages. adv fsp.4.4c The functional specification shall completely represent the TSF. adv fsp.4.5c The functional specification shall include rationale that the TSF is completely represented. Evaluator action elements: adv fsp.4.1e The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. adv fsp.4.2e The evaluator shall determine that the functional specification is an accurate and complete instantiation of the TOE security functional requirements. 10.2 High-level design (ADVJHLD) Objectives The high-level design of a TOE provides a description of the TSF in terms of major structural units (i.e. subsystems) and relates these units to the functions that they provide. The high-level design requirements are intended to provide assurance that the TOE provides an architecture appropriate to implement the TOE security functional requirements. The high-level design refines the functional specification into subsystems. For each subsystem of the TSF, the high-level design describes its purpose and function, and identifies the security functions contained in the subsystem. The interrelationships of all subsystems are also defined in the high-level design. These interrelationships will be represented as external interfaces for data flow, control flow, etc., as appropriate. Component levelling The components in this family are levelled on the basis of the degree of formalism required of the high-level design, and on the degree of detail required for the interface specifications. Application notes The developer is expected to describe the design of the TSF in terms of subsystems. The term "subsystem" is used here to express the idea of decomposing the TSF into a relatively small number of parts. While the developer is not required to actually have "subsystems", the developer is expected to represent a similar level of decomposition. For example, a design may be similarly decomposed using "layers", "domains", or "servers". The term "security functionality" is used to represent the set of operations that a subsystem performs in contribution to security functions implemented by the TOE. This distinction is made because design constructs, such as subsystems and modules, do not necessarily relate to specific security functions. While a given subsystem may correspond directly to a security function, or even multiple security functions, it is also possible that many subsystems must be combined to implement a single security function. The term "TSP-enforcing subsystem" refers to a subsystem that contributes to the enforcement of the TSP, either directly or indirectly. The ADV HLD.*.2E elements within this family define a requirement that the evaluator determine that the high-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 high-level design, in addition to the pairwise correspondences required by the ADVRCR family. It is expected that the evaluator will use the evidence provided in ADVRCR as an input to making this determination, and the requirement for completeness is intended to be relative to the level of abstraction of the high-level design. ADVHLD.3.8C introduces a requirement for a complete presentation for the interfaces to the subsystems. This will provide the necessary detail for supporting both thorough testing of the TOE (using components from ATEDPT), and the assessment of vulnerabilities. 0 ... 33 34 35 36 37 38 39 ... 73
|
