Раздел: Документация
0 ... 2 3 4 5 6 7 8 ... 73 Assurance component Component identification Application notes Objectives Assurance elements Dependencies Figure 2.2 - Assurance component structure The relationship between components within a family is highlighted using a bolding convention. Those parts of the requirements that are new, enhanced or modified beyond the requirements of the previous component within a hierarchy are bolded. The same bolding convention is also used for dependencies. 2.1.3.1Component identification The component identification subclause provides descriptive information necessary to identify, categorise, register, and reference a component. Every assurance component is assigned a unique name. The name provides descriptive information about the topics covered by the assurance component. Each assurance component is placed within the assurance family that shares its security objective. A unique short form ofthe assurance component name is also provided. This is the primary means used to reference the assurance component. The convention used is that the short form of the family name is used, followed by a period, and then a numeric character. The numeric characters for the components within each family are assigned sequentially, starting from 1. 2.1.3.2Objectives The objectives subclause of the assurance component, if present, contains specific objectives for the particular assurance component. For those assurance components that have this subclause, it presents the specific intent of the component and a more detailed explanation of the objectives. 2.1.3.3Application notes The application notes subclause of an assurance component, if present, contains additional information to facilitate the use of the component. 2.1.3.4Dependencies Dependencies among assurance components arise when a component is not self-sufficient, and relies upon the presence of another component. Each assurance component provides a complete list of dependencies to other assurance components. Some components may list "No dependencies", to indicate that no dependencies have been identified. The components depended upon may have dependencies on other components. The dependency list identifies the minimum set of assurance components which are relied upon. Components which are hierarchical to a component in the dependency list may also be used to satisfy the dependency. In specific situations the indicated dependencies might not be applicable. The PP/ST author, by providing rationale for why a given dependency is not applicable, may elect not to satisfy that dependency. 2.1.3.5Assurance elements A set of assurance elements is provided for each assurance component. An assurance element is a security requirement which, if further divided, would not yield a meaningful evaluation result. It is the smallest security requirement recognised in the standard. Each assurance element is identified as belonging to one of the three sets of assurance elements: a)Developer action elements: the activities that shall be performed by the developer. This set of actions is further qualified by evidential material referenced in the following set of elements. Requirements for developer actions are identified by appending the letter "D" to the element number. b)Content and presentation of evidence elements: the evidence required, what the evidence shall demonstrate, and what information the evidence shall convey. Requirements for content and presentation of evidence are identified by appending the letter "C" to the element number. c)Evaluator action elements: the activities that shall be performed by the evaluator. This set of actions explicitly includes confirmation that the requirements prescribed in the content and presentation of evidence elements have been met. It also includes explicit actions and analysis that shall be performed in addition to that already performed by the developer. Implicit evaluator actions are also to be performed as a result of developer action elements which are not covered by content and presentation of evidence reuirements. Requirements for evaluator actions are identified by appending the letter "E" to the element number. The developer actions and content and presentation of evidence define the assurance requirements that are used to represent a developers responsibilities in demonstrating assurance in the TOE security functions. By meeting these requirements, the developer can increase confidence that the TOE satisfies the functional and assurance requirements of a PP or ST. The evaluator actions define the evaluators responsibilities in the two aspects of evaluation. The first aspect is validation of the PP/ST, in accordance with the classes APE and ASE in clauses 4 and 5. The second aspect is verification of the TOEs conformance with its functional and assurance requirements. By demonstrating that the PP/ST is valid and that the requirements are met by the TOE, the evaluator can provide a basis for confidence that the TOE will meet its security objectives. The developer action elements, content and presentation of evidence elements, and explicit evaluator action elements, identify the evaluator effort that shall be expended in verifying the security claims made in the ST of the TOE. 2.1.4Assurance elements Each element represents a requirement to be met. These statements of requirements are intended to be clear, concise, and unambiguous. Therefore, there are no compound sentences: each separable requirement is stated as an individual element. The elements have been written using the normal dictionary meaning for the terms used, rather than using a number of predefined terms as shorthand which results in implicit requirements. Therefore, elements are written as explicit requirements, with no reserved terms. In contrast to ISO/IEC 15408-2, neither assignment nor selection operations are relevant for elements in this part of ISO/IEC 15408; however, refinements may be made to ISO/IEC 15408-3 elements as required. 2.1.5EAL structure Figure 2.3 illustrates the EALs and associated structure defined in this part of ISO/IEC 15408. Note that while the figure shows the contents of the assurance components, it is intended that this information would be included in an EAL by reference to the actual components defined in ISO/ IEC 15408. 2.1.5.1EAL name Each EAL is assigned a unique name. The name provides descriptive information about the intent of the EAL. A unique shortformofthe EAL name is also provided. This is the primary means used to reference the EAL. 2.1.5.2Objectives The objectives subclause of the EAL presents the intent of the EAL. 2.1.5.3Application notes The application notes subclause of the EAL, if present, contains information of particular interest to users of the EAL (e.g. PP and ST authors, designers of TOEs targeting this EAL, evaluators). The presentation is informal and covers, for example, warnings about limitations of use and areas where specific attention may be required. 0 ... 2 3 4 5 6 7 8 ... 73
|
