Раздел: Документация
0 ... 4 5 6 7 8 9 10 ... 117 Component Component Identification Functional Elements Dependencies Figure 2.3 - Functional component structure 2.1.3.1 Component identification The component identification subclause provides descriptive information necessary to identify, categorise, register and cross-reference a component. The following is provided as part of every functional component: A unique name. The name reflects the purpose of the component. A short name. A unique short form of the functional component name. This short name serves as the principal reference name for the categorisation, registration and cross-referencing of the component. This short name reflects the class and family to which the component belongs and the component number within the family. A hierarchical-to list. A list of other components that this component is hierarchical to and for which this component can be used to satisfy dependencies to the listed components. 2.1.3.2 Functional elements A set of elements is provided for each component. Each element is individually defined and is self-contained. A functional element is a security functional requirement that if further divided would not yield a meaningful evaluation result. It is the smallest security functional requirement identified and recognised in ISO/IEC 15408. When building packages, PPs and/or STs, it is not permitted to select only one or more elements from a component. The complete set of elements of a component must be selected for inclusion in a PP, ST or package. A unique short form of the functional element name is provided. For example the requirement name FDPIFF.4.2 reads as follows: F - functional requirement, DP - class "User data protection", IFF - family "Information flow control functions", .4 - 4th component named "Partial elimination of illicit information flows", .2 - 2nd element of the component. 2.1.3.3 Dependencies Dependencies among functional components arise when a component is not self sufficient and relies upon the functionality of, or interaction with, another component for its own proper functioning. Each functional component provides a complete list of dependencies to other functional and assurance components. Some components may list "No dependencies". The components depended upon may in turn have dependencies on other components. The list provided in the components will be the direct dependencies. That is only references to the functional requirements that are required for this requirement to perform its job properly. The indirect dependencies, that is the dependencies that result from the depended upon components can be found in Annex A of this part of ISO/IEC 15408. It is noted that in some cases the dependency is optional in that a number of functional requirements are provided, where each one of them would be sufficient to satisfy the dependency (see for example FDPUIT.1). The dependency list identifies the minimum functional or assurance components needed to satisfy the security requirements associated with an identified component. Components that are hierarchical to the identified component may also be used to satisfy the dependency. The dependencies indicated in ISO/IEC 15408-2 are normative. They must be satisfied within a PP/ST. In specific situations the indicated dependencies might not be applicable. The PP/ST author, by providing the rationale why it is not applicable, may leave the depended upon component out of the package, PP or ST. 2.1.4 Permitted functional component operations The functional components used in the definition of the requirements in a PP, an ST or a functional package may be exactly as specified in clauses 3 to 13 of this part of ISO/IEC 15408, or they may be tailored to meet a specific security objective. However, selecting and tailoring these functional components is complicated by the fact that identified component dependencies must be considered. Thus, this tailoring is restricted to an approved set of operations. A list of permitted operations is included with each functional component. Not all operations are permitted on all functional components. The permitted operations are selected from the following set: -iteration: allows a component to be used more than once with varying operations, -assignment: allows the specification of an identified parameter, -selection: allows the specification of one or more elements from a list, -refinement: allows the addition of details. 2.1.4.1 Iteration Where necessary to cover different aspects of the same requirement (e.g. identification of more than one type of user), repetitive use of the same component from this part of ISO/IEC 15408 to cover each aspect is permitted. 2.1.4.2Assignment Some functional component elements contain parameters or variables that enable the PP/ST author to specify a policy or a set of values for incorporation into the PP or ST to meet a specific security objective. These elements clearly identify each parameter and constraint on values that may be assigned to that parameter. Any aspect of an element whose acceptable values can be unambiguously described or enumerated can be represented by a parameter. The parameter may be an attribute or rule that narrows the requirement to a specific value or range of values. For instance, based on a specified security objective, the functional component element may state that a given operation should be performed a number of times. In this case, the assignment would provide the number, or range of numbers, to be used in the parameter. 2.1.4.3Selection This is the operation of picking one or more items from a list in order to narrow the scope of a component element. 2.1.4.4Refinement For all functional component elements the PP/ST author is permitted to limit the set of acceptable implementations by specifying additional detail in order to meet a security objective. Refinement of an element consists of adding these technical details. Within a ST, the meanings of the terms subject and object might need to be explained for the TOE to be meaningful, and are therefore subject to refinement. Like the other operations, refinement does not levy any completely new requirements. It applies an elaboration, interpretation, or a special meaning to a requirement, rule, constant or condition based on security objectives. Refinement shall only further restrict the set of possible acceptable functions or mechanisms to implement the requirements, but never increase it. Refinement does not allow new requirements to be created, and therefore does not increase the list of dependencies associated with a component. The PP/ST author must be careful that the dependency needs of other requirements that depend on this requirement, are satisfied. 2.2 Component catalogue The grouping of the components in this part of ISO/IEC 15408 does not reflect any formal taxonomy. This part of ISO/IEC 15408 contains classes of families and components, which are rough groupings on the basis of related function or purpose, presented in alphabetic order. At the start of each class is an informative diagram that indicates the taxonomy of each class, indicating the families in each class and the components in each family. The diagram is a useful indicator of the hierarchical relationship that may exist between components. In the description of the functional components, a section identifies the dependencies between the component and any other components. 0 ... 4 5 6 7 8 9 10 ... 117
|
