Evaluating a PP-Configuration is required to demonstrate that the PP-Configuration is sound and consistent. These properties are necessary for the PP-Configuration to be suitable for use as the basis for writing an ST. The class is defined for the evaluation of a PP-Configuration composed of at least one PP and one other component (PPs and/or PP-Modules). The evaluation of PPs is addressed in class . The class defines the requirements for: Evaluating the PP-Modules in the framework of their PP-Modules Base(s) (components , , , or , or , and ). Evaluating the consistency of the combination of all the PPs and PP-Modules that belong to the PP-Configuration (see ). The process of evaluating a PP-Configuration relies on the previous evaluation of all the PPs referenced in the PP-Configuration, and on the evaluation of each PP-Module, iteratively. does not prescribe the order in which the PP-Modules are evaluated. A possible order is the following. Consider a PP-Configuration composed of a set of PPs: PP₁, … PP_n, and a set of PP-Modules: M₁, … M_k, where n ≥ 2 or k ≥ 1. presents the dependency structure of PPs and PP-Modules: PPs are standalone, i.e. they do not depend on other PPs or PP-Modules. If the PP-Configuration contains one or more PP-Modules, then a non-empty subset of these are based on PPs only (i.e. they do not depend on other PP-Modules). One possible evaluation order of such PP-Configuration consists of the following steps: evaluation of the union of PPs (the PPs are assumed already evaluated following requirements); if the PP-Configuration contains one or more PP-Modules, then follow the PP-Configuration's dependency structure from top (PPs) to bottom (PP-Modules) and evaluate all the components of each sub-set of PP-Modules, i.e. for each PP-Module: evaluate the PP-Module in the framework of its PP-Module Base (the elements of which have already been evaluated since the evaluation order meets the dependency structure) ; evaluate the PP-Module in the framework of all the PPs and already evaluated PP-Modules (contained in the same or previous subset of PP-Modules) . Due to the iterative nature of a PP-Configuration evaluation, it may be possible to mutualize the evaluation work to evaluate several configurations at the same time.

The evaluation methodology is based on 's. The objective of this family is to determine the validity of the conformance claim and conformance statement. A PP-Module cannot claim conformance to any PP, PP-Configuration, or another PP-Module. The objective of this sub-activity is to determine the validity of various conformance claims and of the conformance statement. These describe how the PP-Module conforms to the CC Part 2 and packages. A PP-Module cannot claim conformance to any PP, PP-Configuration, or another PP-Module. the PP-Module; the SFR and SAR package(s) that the PP-Module claims conformance to; the PP-Configuration. The developer shall provide a conformance claim. The developer shall provide a conformance statement. The conformance claim shall identify the CC edition to which the PP-Module claims conformance. The conformance claim shall describe the conformance of the PP-Module to CC Part 2 as either "CC Part 2 conformant" or "CC Part 2 extended". The conformance statement shall describe the conformance type required of any ST to the PP-Module (as part of a PP-Configuration) as one of exact, strict, or demonstrable. The conformance claim shall describe the conformance of the PP-Module to this document as either "CC Part 3 conformant" or "CC Part 3 extended". The conformance claim shall be consistent with the extended components definition. The conformance claim shall identify all functional packages to which the PP-Module claims conformance. The conformance claim shall describe any conformance of the PP-Module to a functional package as either package-conformant, package-augmented or package-tailored. The conformance claim shall identify all assurance packages to which the PP-Module claims conformance. The conformance claim shall describe any conformance of the PP-Module to an assurance package as either package-conformant or package-augmented. For exact conformance, the PP-Module's conformance statement shall contain an allowed-with statement that identifies the set of PPs and PP-Modules (exclusive of those PPs and PP-Modules that are included in the PP-Module Base) to which, in combination with the PP-Module under evaluation, exact conformance is allowed to be claimed. The conformance statement may identify the set of the CEM-derived Evaluation methods and Evaluation activities that shall be used with the PP-Module under evaluation. This list shall contain any Evaluation methods and Evaluation activities that are specified in the PP-Module but also any Evaluation methods and Evaluation activities specified in the PP-Module Base(s) and/or in the packages (if any) for which conformance is being claimed by the PP-Module under evaluation. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the conformance claim identifies the version of the CC to which the PP-Module claims conformance. The evaluator determines that the CC conformance claim identifies the version of the CC that was used to develop this PP-Module. This should include the version number of the CC and, unless the English version of the CC was used, the language of the version of the CC that was used. The evaluator shall check that the conformance claim states a claim of either "CC Part 2 conformant" or "CC Part 2 extended" for the PP-Module. The evaluator shall check that the PP-Module conformance statement states a claim of exact, strict or demonstrable conformance which describes the manner in which STs shall conform to the PP-Module (as part of a PP-Configuration). If the PP-Module states that strict conformance is required, STs shall conform to the PP-Module (as part of a PP-Configuration) in a strict manner. If the PP-Module states that demonstrable conformance is required, STs shall conform to the PP-Module (as part of a PP-Configuration) in a strict or demonstrable manner. If the PP-Module states that exact conformance is required, STs shall conform to the PP-Module (as part of a PP-Configuration) in an exact manner. In this case, the evaluator shall check that all of the PP-Module's referenced PP-Module Base(s) require exact conformance as well. The evaluator shall check that the conformance claim states a claim of either "CC Part 3 conformant" or "CC Part 3 extended" for the PP-Module. The evaluator shall examine the conformance claim for CC Part 2 and CC Part 3 to determine that it is consistent with the extended components definition. If the CC conformance claim contains CC Part 2 and/or CC Part 3 conformant, the evaluator determines that the extended components definition does not define functional/assurance components. If the CC conformance claim contains CC Part 2 and/or CC Part 3 extended, the evaluator determines that the extended components definition defines at least one extended functional/assurance component. The evaluator shall check, for each identified functional package, that the package definition is complete. If the PP-Module does not claim conformance to a functional package, this work unit is not applicable and therefore considered to be satisfied. For all functional packages that are not claimed by a component in the PP-Module's base, the evaluator determines that the package definition is conformant to the requirements from CC Part 1, Clause 9 "Packages" by checking that the functional package includes: A functional package identification, giving a unique name, version, date, sponsor, and the CC edition; A functional package overview, giving a narrative description of the security functionality; A component rationale that provides the rationale for selecting the functional components/requirements included in the package; If the package defines an SPD then: the package includes a security requirements rationale; the package includes a security objectives rationale if security objectives for the environment are defined; if the package is a direct rationale package, there are no security objectives for the TOE defined and the security requirements rationale maps directly to the SPD; If the package is not a direct rationale package, then security objectives for the TOE are defined, the security objectives rationale covers the objectives with respect to the SPD, and the security requirements rationale maps the requirements to the security objectives. one or more security components or requirements (the functional package SFRs); If extended components have been specified then the functional package includes an extended components definition. The evaluator shall check that, for each identified package, the conformance claim states a claim of either package-conformant, package-augmented or package-tailored. The evaluator determines that for all functional packages claimed by the PP-Module that are already claimed by one of the PPs or PP-Modules in its PP-Module Base(s), the PP-Module augments or tailors the functional package as it is instantiated in its PP-Module Base (in this case the PP-Module would claim the functional package as "Package Augmented" or "Package Tailored" (as appropriate)). Otherwise, the evaluator confirms that functional packages claimed by a PP-Module Base component are not claimed by the PP-Module. If the PP-Module does not claim conformance to a package, this work unit is not applicable and therefore considered to be satisfied. If the functional package conformance claim contains package-conformant, the evaluator determines that all assumptions, threats, OSPs, security objectives and SFRs included in the package are included in identical form by the PP-Module (including via its PP-Module Base). If the functional package conformance claim contains package-augmented, the evaluator determines that all assumptions, threats, OSPs, security objectives and SFRs included in the package are included in identical form by the PP-Module except that the PP-Module shall include additional selection items values for an at least one of the SFRs with existing selections in the package, and may also have one or more SFRs that are hierarchically higher than an SFR in the functional package. If the functional package conformance claim contains package-tailored, the evaluator determines that all assumptions, threats, OSPs, security objectives and SFRs included in the package are included in identical form by the PP-Module except that the PP-Module shall include additional selection values for at least one of the SFRs in the package, and may also have one or more SFRs that are hierarchically higher than an SFR in the functional package. The evaluator shall check, for each identified assurance package, that the package definition is complete. If the PP-Module does not claim conformance to an assurance package, this work unit is not applicable and therefore considered to be satisfied. If the assurance package is a reference to one of the assurance packages contained in CC Part 5 then this work unit is also considered to be satisfied. The evaluator determines that the package definition is conformant to the requirements from CC Part 1, Clause 9 "Packages" by checking that the assurance package includes: An assurance package identification, giving a unique name, version, date, sponsor, and the CC edition; An assurance package overview, giving a narrative description of the security functionality; One or more security components or requirements (the assurance package SARs) drawn from CC Part 3, extended assurance components or some combination of both; An assurance package shall not include an SPD or security objectives; If extended components have been specified then the assurance package includes an extended components definition. A security requirements rationale that provides the rationale for selecting the assurance components/requirements included in the package. The evaluator shall check that, for each identified assurance package, the conformance claim states a claim of either package-conformant or package-augmented. If the PP-Module does not claim conformance to an assurance package, this work unit is not applicable and therefore considered to be satisfied. If the assurance package conformance claim contains package-conformant, the evaluator determines that all constituent parts included in the assurance package are included in identical form by the PP-Module, without modification. If the assurance package conformance claim contains package-augmented, the evaluator determines that all constituent parts of the assurance package included in the PP-Module are identical to those given in the assurance package except that the PP-Module shall contain at least one additional SAR or one SAR that is hierarchically higher than those contained in the assurance package. The evaluator shall check the conformance statement of the PP-Module to determine that it contains an allowed-with statement that lists the set of other PPs and PP-Modules that can be specified in the components statement of a PP-Configuration that includes the PP-Module. The evaluator confirms that the listed PPs and PP-Modules are not part of any of the PP-Module Base sets. There is no further check other than existence of the list for the PP-Module's allowed-with statement. The evaluator shall check that, for each PP-Module Base for the PP-Module, all components in the PP-Module Base identify all other components of the PP-Module Base in their allow-with statements. This is an iterative operation, and it is important to note that the rule about a PP-Module not including any components in its PP-Module Base in its allowed-with statement holds for any PP-Module in the PP-Module Base. All PPs in a given PP-Module Base set will have to allow-with all other components (PPs and PP-Modules) in that PP-Module Base set. PPs and PP-Modules in one PP-Module Base set do not, however, have to express an allowed with relationship with components in any other PP-Module Base set, since two PP-Module Base sets will not simultaneously be specified in a PP-Configuration The evaluator shall check the conformance statement of the PP-Module under evaluation to confirm that: if any derived Evaluation Methods and Evaluation Activities are required by other items used with the PP-Module (e.g. a base PP), or required by other items to which the PP-Module claims conformance (e.g. packages), then these are all identified in the PP-Module under evaluation, along with any derived Evaluation Methods and Evaluation Activities that the PP-Module itself requires; the list of derived Evaluation Methods and Evaluation Activities is sufficiently structured and detailed to unambiguously identify and locate every member of the list; if there is any overlap in the scope of the identified Evaluation Methods and Evaluation Activities (i.e. where an overlay exists as described in CC Part 4) then the rationale for the resulting set of Evaluation Methods and Evaluation Activities is applicable to the TOE as described by the PP-Module under evaluation. The intention of this work unit is to ensure that when evaluating a TOE that claims conformance with the PP-Configuration that contains the PP-Module under evaluation then the correct Evaluation Methods and Evaluation Activities can be used. This means that identification in the PP-Module need not list individual Evaluation Activities where these are unambiguously included in a listed Evaluation Method. Similarly, where multiple Evaluation Methods or Evaluation Activities are included in a single document then it is sufficient to reference the document, provided this does lead to unambiguous identification of the Evaluation Methods and Evaluation Activities that apply to the PP-Module under evaluation. If a document lists multiple different Evaluation Methods applicable to different use cases then it would not be sufficient to reference the document: the relevant use cases would also have to be identified. The objective of this family is to determine the well-formedness and the consistency of the PP-Configuration. The objective of this sub-activity is to determine whether the PP-Configuration and its components are correctly identified. The objective of this sub-activity is also to determine the consistency of the PP-Configuration regarding the whole set of PP and PP-Modules. For the consistency analysis required by this activity, the application notes of the CEM, Section 10.8, is applicable to determine which parts of the PP-Module Base are to be re-evaluated during the evaluation of PP-Configuration. the PP-Configuration; the PPs and PP-Modules identified in the components statement. The developer shall provide the reference of the PP-Configuration. The developer shall provide a components statement. The developer shall provide a TOE overview. The developer shall provide a conformance claim. The developer shall provide a conformance statement within the conformance claim. The developer shall provide a consistency rationale. The developer shall provide a SAR statement. The developer shall provide the set of evaluation methods and/or activities that are applicable to the PP-Configuration. The PP-Configuration reference shall uniquely identify the PP-Configuration. The PP-Configuration components statement shall uniquely identify the PPs and PP-Modules that compose the PP-Configuration. For each PP-Module identified in the PP-Configuration components statement, the components statement shall include the PP-Module Base required by the identified PP-Module. If the PP-Module specifies alternative PP-Module Bases, only one of these PP-Module Bases shall be referred to in the PP-Configuration. For a multi-assurance PP-Configuration, the components statement shall describe the organization of the TSF in terms of the sub-TSFs defined in the PPs and PP-Modules defined in the PP-Configuration. The TOE overview shall identify the TOE type. The TOE overview shall describe the usage and major security features of the TOE. The TOE overview shall identify any non-TOE hardware/software/firmware available to the TOE. The conformance claim shall identify the CC edition(s) to which the PP-Configuration components claim conformance. The conformance claim shall describe the conformance of the PP-Configuration to CC Part 2 as either "CC Part 2 conformant" or "CC Part 2 extended". The conformance claim shall describe the conformance of the PP-Configuration to this document as either "CC Part 3 conformant" or "CC Part 3 extended". The conformance claim shall be consistent with the conformance claims of the PP-Configuration components. The conformance claim of a PP-Configuration shall include an assurance package conformance claim consisting of statements describing any conformance of the PP-Configuration to an assurance package as either package-conformant or package-augmented. The conformance statement shall specify the required conformance to the PP-Configuration as one of exact, strict, demonstrable, or it shall provide the list of conformance types that are required by each of the PP-Configuration components. For the exact conformance case, the allowed-with statement of the conformance statement of each PP included in the components statement of the PP-Configuration shall identify all the PP-Configuration components as being allowed to be used in combination with the PP in a PP-Configuration. For the exact conformance case, the allowed-with statement of the conformance statement of each PP-Module included in the components statement of the PP-Configuration shall identify all the PP-Configuration components that are not in the PP-Module Base(s) for that particular PP-Module as being allowed to be used in combination with the PP-Module in a PP-Configuration. For PP-Configurations that are not of exact conformance type (i.e. for PP-Configurations of strict or demonstrable conformance type), the conformance statement of a PP-Configuration may include an Evaluation methods and Evaluation activities reference statement that identifies the set of the CEM-derived Evaluation methods and Evaluation activities that are applicable to the PP-Configuration under evaluation. The consistency rationale shall demonstrate that the TOE type defined in the PP-Configuration is consistent with the TOE types defined in the PPs and PP-Modules that belong to the PP-Configuration components statement. The consistency rationale shall demonstrate that the union of all the SPDs, security objectives and security functional requirements defined in the PP-Configuration components is consistent. For a single-assurance PP-Configuration, the SAR statement shall define a single set of SARs that applies to the entire TOE. For strict and demonstrable conformance, the set of SARs shall include the SARs identified in each of the PP-Configuration components. For exact conformance, the set of SARs shall be identical to the set of SARs identified in each of the PP-Configuration components. For a multi-assurance PP-Configuration, the SAR statement shall define the global set of SARs that applies to the entire TOE and the SARs that apply to each sub-TSF. For strict and demonstrable conformance, the global assurance set of SARs shall include the set of common SARs among the PP-Configuration components, and each set of SARs that apply to a sub-TSF shall include those identified for the PP-Configuration components associated with that sub-TSF. For exact conformance, the global assurance set of SARs shall be the set of common SARs among the PP-Configuration components, and each set of SARs that apply to a sub-TSF shall be identical to those identified for the PP-Configuration components associated with that sub-TSF. The SAR statement of a PP-Configuration shall include an assurance rationale that demonstrates the consistency of the applicable set of SARs with those defined in the components of the PP-Configuration under evaluation and their associated Evaluation methods and Evaluation activities. For a multi-assurance PP-Configuration, the assurance rationale shall demonstrate: that the global set of SARs is consistent with the threats as defined in the SPDs of the PP-Configuration components, and that the global set of SARs and the sets of SARs for each sub-TSF are consistent with each other. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the PP-Configuration reference to determine that it uniquely identifies the PP-Configuration. The evaluator determines that the PP-Configuration reference identifies the PP-Configuration itself, so that it may be easily distinguished from other PPs, PP-Configurations and PP-Modules, and that it also uniquely identifies each version of the PP-Configuration, e.g. by including a version number and/or a date of publication. The PP-Configuration should have some referencing system that is capable of supporting unique references (e.g. use of numbers, letters or dates). The evaluator shall examine the PP-Configuration components statement to determine that it uniquely identifies the PPs and PP-Modules contained in the PP-Configuration. The evaluator shall check that if any of the PPs/PP-Modules in the PP-Configuration use the Direct Rationale Approach then all the PPs and PP-Modules in the PP-Configuration use the Direct Rationale approach. The evaluator shall check that if any of the PPs/PP-Modules in the PP-Configuration are of exact conformance type then all PPs/PP-Modules in the PP-Configuration are of exact conformance type. The PPs should have been certified and available for use in Security Targets. The evaluator shall check that the PP-Module Base of each PP-Module in the PP-Configuration is identified in the PP-Configuration's component statement. Where a PP-Module specifies alternative PP-Module Bases then only one of these PP-Module Bases must be referred to in the PP-Configuration. The evaluator shall check that the components statement provides a description of the TSF organisation in terms of the sub-TSFs defined by the PP-Configuration components. The evaluator shall check that the TOE overview identifies the TOE type. The evaluator shall examine the TOE overview to determine that it describes the usage and major security features of the TOE. The TOE overview should briefly (i.e. several paragraphs) describe the usage and major security features expected of the TOE. The TOE overview should enable consumers and potential TOE developers to quickly determine whether the PP-Configuration is of interest to them. The evaluator determines that the overview is clear enough for TOE developers and consumers, and sufficient to give them a general understanding of the intended usage and major security features of the TOE. The evaluator shall examine the TOE overview to determine that it identifies any non-TOE hardware/software/firmware available to the TOE. While some TOEs may run stand-alone, other TOEs (notably software TOEs) need additional hardware, software or firmware to operate. In this subclause of the PP-Configuration, the PP-Configuration author lists all hardware, software, and/or firmware that will be available for the TOE to run on. This identification should be detailed enough for potential consumers and TOE developers to determine whether their TOE may operate with the listed hardware, software and firmware. The evaluator shall check that the conformance claim identifies the CC edition(s) to which the PP-Configuration and its components claim conformance. The evaluator shall check that the conformance claim states a claim of either "CC Part 2 conformant" or "CC Part 2 extended" for the PP-Configuration. The evaluator shall check that the conformance claim states a claim of either "CC Part 3 conformant" or "CC Part 3 extended" for the PP-Configuration. The evaluator shall examine the PP-Configuration conformance claim to determine the compatibility between all CC versions that are related to the PP-Configuration and its components. CC versions used in a PP-Configuration and its components have to be compatible. If compatibility is not obvious, guidance from the certification scheme should be asked. The evaluator shall check that, for each identified assurance package, the conformance claim states a claim of either package-conformant or package-augmented. If the PP-Configuration does not claim conformance to an assurance package, this work unit is not applicable and therefore considered to be satisfied. If the assurance package conformance claim contains package-conformant, the evaluator determines that all constituent parts included in the assurance package are included in identical form by the PP-Configuration, without modification. If the assurance package conformance claim contains package-augmented, the evaluator determines that all constituent parts of the assurance package included in the PP-Configuration are identical to those given in the assurance package except that the PP-Configuration shall contain at least one additional SAR or one SAR that is hierarchically higher than those contained in the assurance package. The evaluator shall examine the PP-Configuration conformance statement to determine that it specifies the kind of conformance required: exact, strict, demonstrable, or a list of strict and demonstrable. If at least one of the PPs identified in the PP-Configuration components statement requires exact conformance, then the PP-Configuration conformance statement shall also require exact conformance. For the exact conformance case, for each PP listed in the PP-Configuration's components statement, the evaluator shall check the PP's conformance statement to determine that all PPs and PP-Modules specified in the PP-Configuration's components statement are listed as allowed to be used with that PP in a PP-Configuration. For the exact conformance case, through and together, the evaluator ensures that any pair of components listed in the PP-Configuration components statement allow to use any other through allow with statement in components' conformance statement or PP-module base identification. For the exact conformance case, for each PP-Module listed in the PP-Configuration's components statement, the evaluator shall check the PP-Module's conformance statement to determine that all the components of the PP-Configuration are listed as allowed to be used with that PP-Module in a PP-Configuration, with the exception that PP-Configuration components in the PP-Module Base do not have to appear in the PP-Module's allowed-with list. The evaluator shall check the conformance statement of the PP-Configuration under evaluation to confirm that: If any derived Evaluation Methods and Evaluation Activities are required by other items included in the PP-Configuration (e.g. a base PP or PP-Module), or required by other items to which the PP-Configuration claims conformance (e.g. packages), then these are all identified in the PP-Configuration under evaluation, along with any derived Evaluation Methods and Evaluation Activities that the PP-Configuration itself chooses to require; the list of derived Evaluation Methods and Evaluation Activities is sufficiently structured and detailed to unambiguously identify and locate every member of the list; if there is any overlap in the scope of the identified Evaluation Methods and Evaluation Activities (i.e. where an overlay exists as described in CC Part 4) then the rationale for the resulting set of Evaluation Methods and Evaluation Activities is applicable to the TOE as described by the PP-Configuration under evaluation. The intention of this work unit is to ensure that when evaluating a TOE that claims conformance with the PP-Configuration under evaluation then the correct Evaluation Methods and Evaluation Activities can be used. This means that identification in the PP-Configuration need not list individual Evaluation Activities where these are unambiguously included in a listed Evaluation Method. Similarly, where multiple Evaluation Methods or Evaluation Activities are included in a single document then it is sufficient to reference the document, provided this does lead to unambiguous identification of the Evaluation Methods and Evaluation Activities that apply to the PP-Configuration under evaluation. If a document lists multiple different Evaluation Methods applicable to different use cases then it would not be sufficient to reference the document: the relevant use cases would also have to be identified. Where exact conformance is required then the PP-Configuration is not permitted to define its own requirements for derived Evaluation Methods and Evaluation Activities: it can only use those required by the other items (e.g. a base PP or PP-Module) in the PP-Configuration. The evaluator shall examine the consistency rationale to determine that the TOE type defined in the PP-Configuration is consistent with the TOE types defined in the components of the PP-Configuration. The evaluator shall examine the PP-Configuration consistency rationale to determine that it demonstrates that the union of all the SPDs of the PPs and PP-Modules identified in the PP-Configuration's components statement is consistent. The evaluator shall examine the PP-Configuration consistency rationale to determine that it demonstrates that the union of all the security objectives of the PPs and PP-Modules identified in the PP-Configuration's components statement is consistent. If the PP-Configuration is a Direct Rationale PP-Configuration (as determined in ) then the TOE objectives are not required in the consistency analysis. The evaluator shall examine the PP-Configuration consistency rationale to determine that the union of all the security functional requirements of the PPs and PP-Modules identified in the PP-Configuration's components statement is consistent, i.e. no contradiction arises from the whole set of SFRs of the PP-Configuration and its components. The evaluator shall examine the PP-Configuration SAR statement to determine that it defines all applicable assurance requirements drawn from CC Part 3 and possibly extended. The set of SARs can refer to a well-defined SAR package, given in an external reference. For a strict or demonstrable conformance PP-Configuration, the evaluator shall check that the set of SARs is well-formed: it is closed by dependencies or the SAR statement provides a sound discarding rationale. For a strict or demonstrable conformance PP-Configuration, the evaluator shall check that the set of SARs of the PP-Configuration is consistent with respect to the SARs of each of the PPs and PP-Modules contained in the PP-Configuration: for any SAR component in each of the PPs and PP-Modules, the PP-Configuration provides either the same or a higher SAR component in the family hierarchy. If the SAR component in the PP/PP-Module is a refinement of a standard component, then the correspondent SAR component in the PP-Configuration has to include these refinements. If two PP-Configuration components refine the same SAR component, the evaluator shall check that the refinements are not contradictory and that the corresponding SAR component in the PP-Configuration meets both. For an exact conformance PP-Configuration, the evaluator shall check that the set of SARs is identical to those SARs identified in each of the PP-Configuration components. For a multi-assurance PP-Configuration, the evaluator shall check that the SAR statement defines all the applicable assurance requirements. The evaluator shall examine the SAR statement to determine that it defines the global set of SARs applying to the entire TOE and the SARs applying to each sub-TSF. For PP-Configurations of strict and/or demonstrable conformance, the evaluator shall examine the global set of SARs to ensure that it includes at least the set of SARs that are common to all the PP-Configuration components, and that any augmentation of this set is clearly identified. In most cases (and always in the exact conformance case), the global set of SARs can be built as the common set of SARs that apply to all of the sub-TSFs. However, as it is the case with STs in the general model, the PP-Configuration (of strict or demonstrable conformance type) can require additional or higher SARs compared to the original SARs in the PP-Configuration components. The evaluation of the PP-Configuration will ensure the consistency of the claim, similar to the general model for the compliance with two or more PPs defining different sets of SARs, and similar to the approach for a multi-assurance ST which can extend the sets of SARs defined in the PP-Configuration the ST claims conformance to. See CC Part 1, Clause 11.3.2.4, for further guidance and examples. For PP-Configurations of exact conformance, the evaluator shall examine the global set of SARs to ensure that it includes only the set of SARs that are common to all the PP-Configuration components. In the exact conformance case, the global set of SARs is built as the common set of SARs that apply to all of the sub-TSFs (with no augmentation or extension in the global set). See CC Part 1, Clause 11.3.2.4, for further guidance and examples. For PP-Configurations of strict and/or demonstrable conformance, the evaluator shall determine that each set of SARs that apply to a sub-TSF include those SARs associated with that sub-TSF's PP-Configuration components, but may include an augmentation of those SARs. See CC Part 1, Clause 11.3.2.4, for further guidance and examples. For PP-Configurations of exact conformance, the evaluator shall determine that each set of SARs that apply to a sub-TSF is identical those SARs associated with that sub-TSF's PP-Configuration components The evaluator shall check that the SAR statement of the PP-Configuration includes an assurance rationale. The evaluator shall examine the assurance rationale to determine that the set of applicable SARs is consistent with those defined in the components of the PP-Configuration under evaluation. The evaluator shall examine the assurance rationale to determine that the set of applicable SARs is consistent with the Evaluation Activities/Evaluation Methods associated with the PP-Configuration components. For a multi-assurance PP-Configuration, the evaluator shall examine the assurance rationale to determine that the global set of SARs is consistent with the threats defined in the SPDs of the PP-Configuration components. The evaluator shall check that the global set of SARs is consistent with all the sets of SARs for the sub-TSFs. The evaluator shall check that the PP-Configuration consisting of all the PPs and PP-Modules identified in the component statement is consistent. The evaluator shall check that the PP-Configuration and the PP-Configuration components are consistent. That is, the evaluator shall check that no contradiction arises from the whole set of PP-Configuration components. The evaluator can organise this work in many ways; the actual organisation may depend on the will to derive evaluation results for more than one PP-Configuration at a time. For instance, the evaluator can proceed in two steps as follows: assess the consistency of the PP-Configuration components; then proceed with the assessment of the PP-Configuration consistency incrementally, by adding one PP-Module at a time, following the PPs/PP-Modules dependency structure. An alternative is to proceed incrementally but mixing PPs and PP-Modules or to flatten/serialise the definition of the PP-Configuration (CC Part 1, Annex C), duplicating as required, and to assess the consistency of the whole set of elements. Any incremental consistency analysis step where C is a subset of the PP-Configuration and X is a PP or a PP-Module that has to be added to C consists of: assessing that the SPD, the objectives and the SFRs of X do not contradict the statements in C; the assumptions and objectives for the environment in X either are the same as in C or address security aspects that are out of the scope of C. If the PP-Configuration is a Direct Rationale PP-Configuration (as determined in ) then the TOE objectives are not required in the consistency analysis. Note that if X is a PP-Module, C contains its PP-Module Base and Evaluation of sub-activity has succeeded for X, then the consistency analysis step has to be performed with respect to the components of C that are not included in the PP-Module Base of X. Extended SFRs are requirements that are not based on components from CC Part 2 or this document, but which are based on extended components: components defined by the PP-Module author. Evaluation of the definition of extended functional components is necessary to determine that they are clear and unambiguous, and that they are necessary, i.e. they may not be clearly expressed using existing CC Part 2 or this document components. The objective of this sub-activity is to determine whether extended components have been clearly and unambiguously defined, and whether they are necessary, i.e. they may not be clearly expressed using existing CC Part 2 or CC Part 3 components. the PP-Module. The developer shall provide a statement of security requirements for the PP-Module. The developer shall provide an extended components definition for the PP-Module. The statement of security requirements shall identify all the extended security requirements. The extended components definition shall define an extended component for each extended security requirement. The extended components definition shall describe how each extended component is related to the existing CC series components, families, and classes. The extended components definition shall use the existing CC series components, families, classes, and methodology as a model for presentation. The extended components shall consist of measurable and objective elements such that conformance or nonconformance to these elements may be demonstrated The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that all security requirements in the statement of security requirements that are not identified as extended requirements are present in CC Part 2 or in CC Part 3. The evaluator shall check that the extended components definition defines an extended component for each extended security requirement. If the PP-Module does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. A single extended component may be used to define multiple iterations of an extended security requirement; it is not necessary to repeat this definition for each iteration. The evaluator shall examine the extended components definition to determine that it describes how each extended component fits into the existing CC components, families, and classes. If the PP-Module does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that each extended component is either: a member of an existing CC Part 2 or CC Part 3 family; or a member of a new family defined in the PP-Module. If the extended component is a member of an existing CC Part 2 or CC Part 3 family, the evaluator determines that the extended components definition adequately describes why the extended component should be a member of that family and how it relates to other components of that family. If the extended component is a member of a new family defined in the PP-Module, the evaluator confirms that the extended component is not appropriate for an existing family. If the PP-Module defines new families, the evaluator determines that each new family is either: a member of an existing CC Part 2 or CC Part 3 class; or a member of a new class defined in the PP-Module. If the family is a member of an existing CC Part 2 or CC Part 3 class, the evaluator determines that the extended components definition adequately describes why the family should be a member of that class and how it relates to other families in that class. If the family is a member of a new class defined in the PP-Module, the evaluator confirms that the family is not appropriate for an existing class. The evaluator shall examine the extended components definition to determine that each definition of an extended component identifies all applicable dependencies of that component. If the PP-Module does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator confirms that no applicable dependencies have been overlooked by the PP-Module author. The evaluator shall examine the extended components definition to determine that each extended functional component uses the existing CC Part 2 components as a model for presentation. If the PP-Module does not contain extended SFRs, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the extended functional component is consistent with CC Part 2, 7.1.4, Component structure. If the extended functional component uses operations, the evaluator determines that the extended functional component is consistent with CC Part 1, 8.2, Operations. If the extended functional component is hierarchical to an existing functional component, the evaluator determines that the extended functional component is consistent with CC Part 2, Introduction. The evaluator shall examine the extended components definition to determine that each definition of a new functional family uses the existing CC functional families as a model for presentation. If the PP-Module does not define new functional families, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new functional families are defined consistent with CC Part 2, 7.1.3, Family structure. The evaluator shall examine the extended components definition to determine that each definition of a new functional class uses the existing CC functional classes as a model for presentation. If the PP-Module does not define new functional classes, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new functional classes are defined consistent with CC Part 2, 7.1.2, Class structure The evaluator shall examine the extended components definition to determine that each definition of an extended assurance component uses the existing CC Part 3 components as a model for presentation. If the PP-Module does not contain extended SARs, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the extended assurance component definition is consistent with CC Part 3, 6.4, Assurance component structure. If the extended assurance component uses operations, the evaluator determines that the extended assurance component is consistent with CC Part 1, 8.2, Operations. If the extended assurance component is hierarchical to an existing assurance component, the evaluator determines that the extended assurance component is consistent with CC Part 3, 6.4, Assurance component structure. The evaluator shall examine the extended components definition to determine that, for each defined extended assurance component, applicable methodology has been provided. If the PP-Module does not contain extended SARs, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that, for each evaluator action element of each extended SAR, one or more work units are provided and that successfully performing all work units for a given evaluator action element will demonstrate that the element has been achieved. The evaluator shall examine the extended components definition to determine that each definition of a new assurance family uses the existing CC assurance families as a model for presentation. If the PP-Module does not define new assurance families, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new assurance families are defined consistent with CC Part 3, 6.3, Assurance family structure. The evaluator shall examine the extended components definition to determine that each definition of a new assurance class uses the existing CC assurance classes as a model for presentation. If the PP-Module does not define new assurance classes, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new assurance classes are defined consistent with CC Part 3, 6.2, Assurance class structure. The evaluator shall examine the extended components definition to determine that each element in each extended component is measurable and states objective evaluation requirements, such that conformance or nonconformance can be demonstrated. If the PP-Module does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that elements of extended functional components are stated in such a way that they are testable, and traceable through the appropriate TSF representations. The evaluator also determines that elements of extended assurance components avoid the need for subjective evaluator judgement. The evaluator is reminded that whilst being measurable and objective is appropriate for all evaluation criteria, it is acknowledged that no formal method exists to prove such properties. Therefore, the existing CC functional and assurance components are to be used as a model for determining what constitutes conformance to this requirement. The evaluator shall confirm that no extended component may be clearly expressed using existing components. The evaluator shall examine the extended components definition to determine that each extended component may not be clearly expressed using existing components. If the PP-Module does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator should take components from CC Part 2 and CC Part 3, other extended components that have been defined in the PP-Module, combinations of these components, and possible operations on these components into account when making this determination. The evaluator is reminded that the role of this work unit is to preclude unnecessary duplication of components, that is, components that may be clearly expressed by using other components. The evaluator should not undertake an exhaustive search of all possible combinations of components including operations in an attempt to find a way to express the extended component by using existing components. The objective of this family is to describe the TOE in a narrative way. The evaluation of the PP-Module introduction is required to demonstrate that the PP-Module is correctly identified, and that the PP-Module reference and TOE overview are consistent with each other. The objective of this sub-activity is to determine whether the PP-Module is correctly identified, and whether the PP-Module Base and TOE overview are consistent with each other. All actions of hold. the PP-Module; its PP-Module Base. The developer shall provide a PP-Module introduction. The PP-Module introduction shall contain a PP-Module reference, the identification of the PP-Module Base(s) and a TOE overview. The PP-Module reference shall uniquely identify the PP-Module. The identification of the PP-Module Base shall consist of a list of at least one PP and possibly other PPs and PP-Modules on which the PP-Module depends. The identification of the PP-Module Base(s) shall describe the dependency structure of the PP-Module Base(s). The PP-Module introduction shall contain as many TOE overviews as alternative PP-Module Bases. The TOE overview shall summarize the usage and major security features of the TOE. The TOE overview shall identify the TOE type. The TOE overview shall identify any non-TOE hardware/software/firmware available to the TOE. The TOE overview shall describe the differences of the TOE with regard to the TOEs defined in the PP-Module Base(s). The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the PP-Module introduction identifies the PP-Module Base(s) on which the PP-Module relies. The evaluator shall check that the PP-Module introduction contains a PP-Module reference and a TOE overview. The evaluator shall examine the PP-Module reference to determine that it uniquely identifies the PP-Module. The evaluator determines that the PP-Module reference identifies the PP-Module itself, so that it may be easily distinguished from other PP-Modules, and that it also uniquely identifies each version of the PP-Module, e.g. by including a version number and/or a date of publication. The PP-Module should have some referencing system that is capable of supporting unique references (e.g. use of numbers, letters or dates). The evaluator shall examine the PP-Module Base identification to determine that it includes a list of PPs and PP-Modules B_i of the following shape: B₁ … AND … B_n with n≥ 1 The evaluator shall check that the set {B₁ … B_n} contains one or more PPs. For a PP-Module that allows to be used with alternative PP-Module Bases, the evaluator shall examine the PP-Module Base identification to determine that it includes multiple alternative lists of references that uniquely identify the sets S_i of PPs and PP-Modules on which the PP-Module may depend. The list of alternative PP-Module Bases has the following form: S₁ … OR … S_k with k≥ 1 The evaluator shall examine the PP-Module Base identification to determine that it describes the dependency structure of the PPs and PP-Modules that compose the PP-Module Base. Given the definition of a PP-Module Base B_i, the evaluator shall check that a PP-Module Base cannot consist solely of a PP-Module, and every PP-Module identifies its PP-Module Base. The evaluator shall check that the PP-Module Base {B₁ … B_n} is a closed set, that is, for any PP-Module B_i, its own PP-Module Base belongs to the set {B₁ … B_n}. For a PP-Module that allows to be used with alternative PP-Module Bases, the evaluator shall check that each of those define a closed set of PPs and PP-Modules. The evaluator ensures that if the PP-Module restricts the PP-Module Bases allowed for PP-Modules in the "being evaluated" PP-Module's PP-Module Base, those restrictions are stated in the introduction and are consistent for the depended-upon PP-Module's definition of allowed PP-Module Bases. The evaluator shall check that the PP-Module introduction contains as many TOE overviews as alternative PP-Module Bases. The statement of the TOE overview in a PP-Module may be given by reference when it is the same as in its PP-Module Base, i.e. when there is no addition. If the TOE overview is not affected by the choice of alternative PP-Module Bases anywhere in the set of PP-Module Bases for the PP-Module, then a separate TOE description is not required and instead a note should be included to that effect. The evaluator shall examine the TOE overview to determine that it describes the usage and major security features of the TOE. The TOE overview should briefly (i.e. several paragraphs) describe the usage and major security features expected of the TOE. The TOE overview should enable consumers and potential TOE developers to quickly determine whether the PP-Module is of interest to them. The evaluator determines that the overview is clear enough for TOE developers and consumers, and sufficient to give them a general understanding of the intended usage and major security features of the TOE. The evaluator shall check that the TOE overview identifies the TOE type. The evaluator shall examine the TOE overview to determine that it identifies any non-TOE hardware/software/firmware available to the TOE. While some TOEs may run stand-alone, other TOEs (notably software TOEs) need additional hardware, software or firmware to operate. In this subclause of the PP-Module, the PP-Module author lists all hardware, software, and/or firmware that will be available for the TOE to run on. This identification should be detailed enough for potential consumers and TOE developers to determine whether their TOE may operate with the listed hardware, software and firmware. The evaluator shall check that the TOE overview identifies the differences introduced by the PP-Module with respect to the TOE overview of its PP-Module Base(s). The objective of this family is to determine the consistency of the PP-Module and to state the correspondence between the PP-Module and its PP-Module Base(s). The objective of this sub-activity is to determine the consistency of the PP-Module regarding its PP-Module Base. the PP-Module; its PP-Module Base. The developer shall provide a consistency rationale of the PP-Module for each of the alternative PP-Module Bases identified in the PP-Module introduction. The developer shall provide an assurance rationale of the PP-Module for each of the alternative PP-Module Bases identified in the PP-Module introduction. The consistency rationale shall demonstrate that the TOE type of the PP-Module and the TOE types of its PP-Module Base(s) are consistent. The consistency rationale shall identify the assets of the PP-Module's SPD that also belong to some of its PP-Module Bases and amongst them those for which the PP-Module and the PP-Module Base define different security problems. The consistency rationale shall demonstrate that: the statement of the security problem definition is consistent with the statement of the security problem definition of its PP-Module Base(s); the statement of the security problem definition is consistent with the statement of the security problem definition of any functional package for which conformance is being claimed. The consistency rationale shall demonstrate that: the security objectives definition is consistent with the security objectives of its PP-Module Base(s); the security objectives definition is consistent with the security objectives of any functional package for which conformance is being claimed. The consistency rationale shall demonstrate that: the security functional requirements definition is consistent with the security functional requirements of its PP-Modules Base(s); the security functional requirements definition is consistent with the security functional requirements of any functional package for which conformance is being claimed. The assurance rationale shall demonstrate the internal consistency of the set of security assurance requirements of the PP-Module with regard to its security problem definition. The assurance rationale shall demonstrate the consistency of the set of security assurance requirements of the PP-Module with regard to the security assurance requirements of the PP-Module Base(s). The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. If the PP-Module specifies alternative PP-Module Bases, the evaluator shall perform this action for each consistency rationale. The evaluator shall examine the consistency rationale to determine that the TOE type of the PP-Module is consistent with all the TOE types of the PP-Module Base(s). The relation between the types may be simple: a PP-Module may consider a TOE that provides additional security functionality, or more complex: a TOE that provides a given security functionality in a specific way. The evaluator shall check that the consistency rationale contains the set of assets shared between the PP-Module and PP-Module Base(s), and that this set is unambiguous and complete. The evaluator shall check that the consistency rationale contains the subset of shared assets that hold different security properties and/or are subject to different threat agents or threat scenarios, and that this subset is unambiguous and complete. If there is no shared asset, then this work unit is considered satisfied. The evaluator shall examine the PP-Module consistency rationale to determine that it demonstrates that the statement of security problem definition of the PP-Module is consistent with the statements of security problem definition stated in its PP-Module Base(s). In particular, the evaluator examines the consistency rationale to determine that: the statements of threats, assumptions and OSPs in the PP-Module do not contradict those drawn from any functional packages to which it claims conformance; the statement of assumptions in the PP-Module addresses aspects out of scope of any functional packages to which it claims conformance, in which case, the addition of elements is allowed. The evaluator shall examine the PP-Module consistency rationale to determine that it demonstrates that the statement of security problem definition of the PP-Module is consistent with the statements of security problem definition stated in any of the functional packages for which conformance is being claimed. In particular, the evaluator examines the consistency rationale to determine that: the statements of threats, assumptions and OSPs in the PP-Module do not contradict those from the PP-Module Base; the statement of assumptions in the PP-Module addresses aspects out of scope of the PP-Module Base, in which case, the addition of elements is allowed. For all the assets that are shared between the PP-Module and a base PP or PP-Module, the evaluator shall determine that all the differences in the security problem definitions are justified. For instance, the asset resides in different locations or at different times or is subject to different operational environment conditions. In particular, the evaluator examines the consistency rationale to determine that: the statements of security objectives for the TOE and the security objectives for the operational environment the PP-Module do not contradict those drawn from any functional packages to which it claims conformance; the statement of security objectives for the operational environment in the PP-Module addresses aspects out of scope of any functional packages to which it claims conformance, in which case, the addition of elements is allowed. The evaluator shall examine the PP-Module consistency rationale to determine that it demonstrates that the statement of security objectives of the PP-Module is consistent with the statement of security objectives of its PP-Module Base. The evaluator shall examine the PP-Module consistency rationale to determine that it demonstrates that the statement of security objectives of the PP-Module is consistent with the statement of security objectives of any functional package for which conformance is being claimed. Where the PP-Module and its PP-Module Base use the Direct Rationale approach then this work unit is trivially satisfied for the TOE objectives (because these are not included under the Direct Rationale approach). If any of the PP-Module or its PP-Module Base use the Direct Rationale approach then the PP-Module and all elements of its PP-Module Base must use the Direct Rationale approach, otherwise the evaluator action related to this work unit is assigned a fail verdict. In particular, the evaluator examines the consistency rationale to determine that: the statements of the security objectives for the TOE and the security objectives for the operational environment in the PP-Module do not contradict those from the PP-Module Base; the statement of the security objectives for the operational environment in the PP-Module addresses aspects out of scope of the PP-Module Base, in which case, the addition of elements is allowed. The evaluator shall examine the consistency rationale to determine that the statement of security requirements of the PP-Module is consistent with the statement of security requirements of its PP-Module Base, i.e. the SFRs of the PP-Module either complete or refine the SFRs of the PP-Module Base and no contradiction arises from the whole set of SFRs of the PP-Module and the PP-Module Base. The evaluator shall examine the consistency rationale to determine that the statement of security requirements of the PP-Module is consistent with the statement of security requirements of any functional package for which conformance is being claimed, i.e. the SFRs of the PP-Module either complete or refine the SFRs of the claimed functional packages and no contradiction arises from the whole set of SFRs of the PP-Module and those of the functional packages for which conformance is claimed. The evaluator shall examine the assurance rationale to determine that the set of security assurance requirements of the PP-Module is consistent with regard to the threat model defined in the PP-Module. An example of an inconsistency between SARs and the SPD would be to consider highly skilled threat agents together with a low level that cannot consider these threat agents by definition. The evaluator shall examine the assurance rationale to determine that the set of security assurance requirements of the PP-Module is consistent with regard to all the sets of SARs defined in its PP-Module Base. The evaluator shall examine the assurance rationale to determine that the set of SARs defined in the PP-Module does not undermine the security that is expected for the assets that are shared between the PP-Module and its PP-Module Base (if shared assets exist). The security objectives are a concise statement of the intended response to the security problem defined through the family. Evaluation of the security objectives is required to demonstrate that the security objectives adequately and completely address the security problem definition and that the division of this problem between the TOE and its operational environment is clearly defined. The components in this family are levelled on whether they prescribe only security objectives for the operational environment (see ), or also security objectives for the TOE (see ). If the PP-Configuration does not use the Direct Rationale approach (as determined in ) then this sub-activity can be considered satisfied. The developer shall provide a statement of security objectives for the operational environment of the PP-Module. The developer shall provide a security objectives rationale for the operational environment of the PP-Module. The statement of security objectives shall describe the security objectives for the operational environment. The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective, and assumptions upheld by that security objective. The security objectives rationale shall demonstrate that the security objectives for the operational environment uphold all assumptions. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security objectives defines the security objectives for the operational environment. The evaluator checks that the security objectives for the operational environment are identified. The evaluator shall check that the security objectives requirements rationale traces the security objectives for the operational environment back to threats countered by that security objective, to OSPs enforced by that security objective, and to assumptions upheld by that security objective. Each security objective for the operational environment may trace back to threats, OSPs, assumptions, or a combination of threats, OSPs and/or assumptions, but it must trace back to at least one threat, OSP or assumption. Failure to trace implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the operational environment has no useful purpose. There is no prescribed location where this tracing element of the rationale must be placed: for example, the relevant parts may be located under each threat, OSP and assumption in order to help make the security argument clearer and easier to read. The evaluator shall examine the security objectives rationale to determine that for each assumption for the operational environment it contains an appropriate justification that the security objectives for the operational environment are suitable to uphold that assumption. If no security objectives for the operational environment trace back to the assumption, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an assumption about the operational environment of the TOE demonstrates that the security objectives are sufficient: if all security objectives for the operational environment that trace back to that assumption are achieved, the operational environment upholds the assumption. The evaluator also determines that each security objective for the operational environment that traces back to an assumption about the operational environment of the TOE is necessary: when the security objective is achieved it actually contributes to the operational environment upholding the assumption. Note that simply listing in the security objectives rationale the security objectives for the operational environment associated with each assumption may be a part of a justification, but does not constitute a justification by itself. A descriptive justification is required, although in simple cases this justification may be as minimal as "Security Objective X directly upholds Assumption Y". The objective of this sub-activity is to determine whether the security objectives adequately and completely address the security problem definition and that the division of this problem between the TOE and its operational environment is clearly defined. the PP-Module. The developer shall provide a statement of security objectives for the PP-Module. The developer shall provide a security objectives rationale for the PP-Module. The statement of security objectives shall describe the security objectives for the TOE and the security objectives for the operational environment. The security objectives rationale shall trace each security objective for the TOE back to threats countered by that security objective and OSPs enforced by that security objective. The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective, and assumptions upheld by that security objective. The security objectives rationale shall demonstrate that the security objectives counter all threats. The security objectives rationale shall demonstrate that the security objectives enforce all OSPs. The security objectives rationale shall demonstrate that the security objectives for the operational environment uphold all assumptions. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security objectives defines the security objectives for the TOE and the security objectives for the operational environment. The evaluator checks that both categories of security objectives are clearly identified and separated from the other category. The evaluator shall check that the security objectives rationale traces all security objectives for the TOE back to threats countered by the objectives and/or OSPs enforced by the objectives. Each security objective for the TOE may trace back to threats or OSPs, or a combination of threats and OSPs, but it must trace back to at least one threat or OSP. Optional requirements may require Threats/OSPs to be specified, and security objectives associated with these SPD elements are also covered by this work unit. Failure to trace implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the TOE has no useful purpose. The evaluator shall check that the security objectives rationale traces the security objectives for the operational environment back to threats countered by that security objective, to OSPs enforced by that security objective, and to assumptions upheld by that security objective. Each security objective for the operational environment may trace back to threats, OSPs, assumptions, or a combination of threats, OSPs and/or assumptions, but it must trace back to at least one threat, OSP or assumption. Failure to trace implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the operational environment has no useful purpose. The evaluator shall examine the security objectives rationale to determine that it justifies for each threat that the security objectives are suitable to counter that threat. If no security objectives trace back to the threat, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for a threat shows whether the threat is removed, diminished or mitigated. The evaluator determines that the justification for a threat demonstrates that the security objectives are sufficient: if all security objectives that trace back to the threat are achieved, the threat is removed, sufficiently diminished, or the effects of the threat are sufficiently mitigated. Note that the tracings from security objectives to threats provided in the security objectives rationale may be part of a justification, but do not constitute a justification by themselves. Even in the case that a security objective is merely a statement reflecting the intent to prevent a particular threat from being realised, a justification is required, but this justification may be as minimal as "Security Objective X directly counters Threat Y". The evaluator also determines that each security objective that traces back to a threat is necessary: when the security objective is achieved it actually contributes to the removal, diminishing or mitigation of that threat. The evaluator shall examine the security objectives rationale to determine that for each OSP it justifies that the security objectives are suitable to enforce that OSP. If no security objectives trace back to the OSP, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an OSP demonstrates that the security objectives are sufficient: if all security objectives that trace back to that OSP are achieved, the OSP is enforced. The evaluator also determines that each security objective that traces back to an OSP is necessary: when the security objective is achieved it actually contributes to the enforcement of the OSP. Note that the tracings from security objectives to OSPs provided in the security objectives rationale may be part of a justification, but do not constitute a justification by themselves. In the case that a security objective is merely a statement reflecting the intent to enforce a particular OSP, a justification is required, but this justification may be as minimal as "Security Objective X directly enforces OSP Y". The evaluator shall examine the security objectives rationale to determine that for each assumption for the operational environment it contains an appropriate justification that the security objectives for the operational environment are suitable to uphold that assumption. If no security objectives for the operational environment trace back to the assumption, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an assumption about the operational environment of the TOE demonstrates that the security objectives are sufficient: if all security objectives for the operational environment that trace back to that assumption are achieved, the operational environment upholds the assumption. The evaluator also determines that each security objective for the operational environment that traces back to an assumption about the operational environment of the TOE is necessary: when the security objective is achieved it actually contributes to the operational environment upholding the assumption. Note that the tracings from security objectives for the operational environment to assumptions provided in the security objectives rationale may be a part of a justification, but do not constitute a justification by themselves. Even in the case that a security objective of the operational environment is merely a restatement of an assumption, a justification is required, but this justification may be as minimal as "Security Objective X directly upholds Assumption Y". The SFRs form a clear, unambiguous and well-defined description of the expected security behaviour of the TOE. The SARs form a clear, unambiguous and well-defined description of the expected activities that will be undertaken to gain assurance in the TOE. Evaluation of the security requirements is required to ensure that they are clear, unambiguous and well-defined. The components in this family are levelled on whether the SFRs are derived from SPD (see ), or whether the SFRs are derived from the security objectives for the TOE (see .). The objective of this sub-activity is to determine whether the SFRs and SARs are clear, unambiguous and well-defined, whether they are internally consistent, and whether the SFRs counter the threats and implement the organisational security policies of the TOE. the PP-Module. The developer shall provide a statement of security requirements for the PP-Module. The developer shall provide a security requirements rationale for the PP-Module. The statement of security requirements shall describe the SFRs and SARs (the SARs that apply to the PP-Module may be explicitly stated, or inherited from the PP-Module Base(s)). All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined. The statement of security requirements shall identify all operations on the security requirements. All operations shall be performed correctly. Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied. The security requirements rationale shall trace each SFR back to the threats countered by that SFR and the OSPs enforced by that SFR. The security requirements rationale shall demonstrate that the SFRs (in conjunction with the security objectives for the environment) counter all the threats for the TOE. The security requirements rationale shall demonstrate that the SFRs (in conjunction with the security objectives for the environment) enforce all the OSPs for the TOE. The security requirements rationale shall explain why the SARs were chosen. The statement of security requirements shall be internally consistent. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security requirements describes the SFRs. The evaluator determines that each SFR is identified by one of the following means: by reference to an individual component in CC Part 2; by reference to an extended component in the extended components definition of the PP-Module Base; by reference to a security requirements package that the PP-Module claims to be conformant with; by reproduction in the PP-Module. It is not required to use the same means of identification for all SFRs. The evaluator shall check that the statement of security requirements describes the SARs. The evaluator determines that each SAR is identified by one of the following means: by reference to an individual component in CC Part 3; by reference to an extended component in the extended components definition of the PP-Module Base; by reference to a security requirements package that the PP-Module claims to be conformant with; by reproduction in the PP-Module. It is not required to use the same means of identification for all SARs. The evaluator shall examine the PP-Module to determine that all subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs are defined. The evaluator determines that the PP-Module defines all: (types of) subjects and objects that are used in the SFRs; (types of) security attributes of subjects, users, objects, information, sessions and/or resources, possible values that these attributes may take and any relations between these values (e.g. top_secret is "higher" than secret); (types of) operations that are used in the SFRs, including the effects of these operations; (types of) external entities in the SFRs; other terms that are introduced in the SFRs and/or SARs by completing operations, if these terms are not immediately clear, or are used outside their dictionary definition. The goal of this work unit is to ensure that the SFRs and SARs are well-defined and that no misunderstanding may occur due to the introduction of vague terms. This work unit should not be taken into extremes, by forcing the PP-Module author to define every single word. The general audience of a set of security requirements should be assumed to have a reasonable knowledge of IT, security and the CC series. All of the above may be presented in groups, classes, roles, types or other groupings or characterisations that allow easy understanding. The evaluator is reminded that these lists and definitions do not have to be part of the statement of security requirements, but may be placed (in part or in whole) in different subclauses. This can be especially applicable if the same terms are used in the rest of the PP-Module. The evaluator shall check that the statement of security requirements identifies all operations on the security requirements. The evaluator determines that all operations are identified in each SFR or SAR where such an operation is used. This includes both completed operations and uncompleted operations. Identification may be achieved by typographical distinctions, or by explicit identification in the surrounding text, or by any other distinctive means. If the PP-Module defines selection-based SFRs, the evaluator determines that the PP-Module clearly identifies the dependencies between the selection in an SFR and the selection-based SFR(s) to be included in the ST should that selection be chosen by the ST author. The evaluator shall examine the statement of security requirements to determine that all assignment operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all iteration operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all selection operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all refinement operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that each dependency of the security requirements is either satisfied, or that the security requirements rationale justifies the dependency not being satisfied. A dependency is satisfied by the inclusion of the relevant component (or one that is hierarchical to it) within the statement of security requirements. The component used to satisfy the dependency should, if necessary, be modified by operations to ensure that it actually satisfies that dependency. A justification that a dependency is not met should address either: why the dependency is not necessary or useful, in which case no further information is required; or that the dependency has been addressed by the operational environment of the TOE, in which case the justification should describe how the security objectives for the operational environment address this dependency. The evaluator ensures that if a functional package defines a dependency on another functional package, then that functional package is included in the PP-Module. If a functional package identifies dependencies on its requirements that need to be satisfied by the underlying PP-Module, the evaluator ensures that their analysis covers these dependencies as well. The evaluator shall check that the security requirements rationale traces each SFR back to the threats countered by that SFR and OSPs enforced by that SFR. The evaluator determines that each SFR is traced back to at least one threat or OSP for the TOE. Failure to trace implies that either the security requirements rationale is incomplete, the security objectives for the TOE are incomplete, or the SFR has no useful purpose. There is no prescribed location where this tracing element of the rationale must be placed: for example, the relevant parts may be located under each threat and OSP in order to help make the security argument clearer and easier to read. The evaluator shall examine the security requirements rationale to determine that for each threat it demonstrates that the SFRs are suitable to meet that threat. If no SFRs trace back to a threat, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for a threat shows whether the threat is removed, diminished or mitigated. The evaluator determines that the justification for a threat demonstrates that the SFRs are sufficient: if all SFRs that trace back to the threat are achieved then, in the context of any applicable OSPs and assumptions, the threat is removed, sufficiently diminished, or the effects of the threat are sufficiently mitigated. Note that simply listing in the security requirements rationale the SFRs associated with each threat may be part of a justification, but does not constitute a justification by itself. A descriptive justification is required, although in simple cases this justification may be as minimal as "SFR X directly counters Threat Y". The evaluator also determines that each SFR that traces back to a threat is necessary: when the SFR is implemented it actually contributes to the removal, diminishing or mitigation of that threat. The evaluator shall examine the security requirements rationale to determine that for each OSP it justifies that the SFRs are suitable to enforce that OSP. If no SFRs or security objectives for the operational environment trace back to the OSP, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an OSP demonstrates that the security objectives are sufficient: if all SFRs that trace back to that OSP are achieved then, in the context of any applicable assumptions, the OSP is enforced. The evaluator also determines that each SFR that traces back to an OSP is necessary: when the SFR is implemented it actually contributes to the enforcement of the OSP. Note that simply listing in the security requirements rationale the SFRs associated with each OSP may be part of a justification, but does not constitute a justification by itself. A descriptive justification is required, although in simple cases this justification may be as minimal as "SFR X directly enforces OSP Y". The evaluator shall check that the security requirements rationale explains why the SARs were chosen. The evaluator is reminded that any explanation is correct, as long as it is coherent and neither the SARs nor the explanation have obvious inconsistencies with the remainder of the PP-Module. An example of an obvious inconsistency between the SARs and the remainder of the PP-Module would be to have threat agents that are very capable, but an component that does not protect against these threat agents. The evaluator shall examine the statement of security requirements to determine that it is internally consistent. The evaluator determines that the combined set of all SFRs and SARs is internally consistent. With respect to optional requirements, the evaluator determines that: all optional requirements either trace to an SPD element that is itself not optional, or trace to an SPD element that is clearly associated with that optional SFR; all optional requirements are clearly identified as either: elective and therefore for inclusion purely at the discretion of the ST author (i.e. conformance to the PP-Module does not depend on their inclusion in the ST); or conditional and therefore required if a conformant TOE implements the functionality covered by the requirement. all optional requirements do not conflict with non-optional requirements (a capability cannot be both required and optional; however, a base capability can be required with enhancements to that capability being specified as optional). The evaluator determines that on all occasions where different security requirements apply to the same types of developer evidence, events, operations, data, tests to be performed etc. or to "all objects", "all subjects" etc., that these requirements do not conflict. Some possible conflicts are: an extended SAR specifying that the design of a certain cryptographic algorithm is to be kept secret, and another extended SAR specifying an open source review; specifying that subject identity is to be logged, specifying who has access to these logs, and specifying that some actions of subjects should be unobservable to other subjects. If the subject that should not be able to see an activity may access logs of this activity, these SFRs conflict; specifying deletion of information no longer needed, and specifying that a TOE may return to a previous state. If the information that is needed for the rollback to the previous state has been deleted, these requirements conflict; multiple iterations of , especially where some iterations cover the same subjects, objects, or operations. If one access control SFR allows a subject to perform an operation on an object, while another access control SFR does not allow this, these requirements conflict. The objective of this sub-activity is to determine whether the SFRs and SARs are clear, unambiguous and well-defined, whether they are internally consistent, and whether the SFRs meet the security objectives of the TOE. the PP-Module. The developer shall provide a statement of security requirements for the PP-Module. The developer shall provide a security requirements rationale for the PP-Module. The statement of security requirements shall describe the SFRs and SARs (the SARs that apply to the PP-Module may be explicitly stated, or inherited from the PP-Module Base(s)). All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined. The statement of security requirements shall identify all operations on the security requirements. All operations shall be performed correctly. Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied. The security requirements rationale shall trace each SFR back to the security objectives for the TOE enforced by that SFR. The security requirements rationale shall demonstrate that the SFRs meet all security objectives for the TOE. The security requirements rationale shall explain why the SARs were chosen. The statement of security requirements shall be internally consistent. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security requirements describes the SFRs. The evaluator determines that each SFR is identified by one of the following means: by reference to an individual component in CC Part 2; by reference to an extended component in the extended components definition of the PP-Module Base; by reference to an individual component in a security requirements package that the PP-Module claims to be conformant with; by reproduction in the PP-Module. It is not required to use the same means of identification for all SFRs. The evaluator shall check that the statement of security requirements describes the SARs. The evaluator determines that each SAR is identified by one of the following means: by reference to an individual component in CC Part 3; by reference to an extended component in the extended components definition of the PP-Module Base; by reference to an individual component in a security requirements package that the PP-Module claims to be conformant with; by reproduction in the PP-Module. It is not required to use the same means of identification for all SARs. Note that if optional requirements are defined by the PP-Module, there may be associated threats that are covered by this work unit. The evaluator shall examine the PP-Module to determine that all subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs are defined. The evaluator determines that the PP-Module defines all: (types of) subjects and objects that are used in the SFRs; (types of) security attributes of subjects, users, objects, information, sessions and/or resources, possible values that these attributes may take and any relations between these values (e.g. top_secret is "higher" than secret); (types of) operations that are used in the SFRs, including the effects of these operations; (types of) external entities in the SFRs; other terms that are introduced in the SFRs and/or SARs by completing operations, if these terms are not immediately clear, or are used outside their dictionary definition. The goal of this work unit is to ensure that the SFRs and SARs are well-defined and that no misunderstanding may occur due to the introduction of vague terms. This work unit should not be taken into extremes, by forcing the PP-Module author to define every single word. The general audience of a set of security requirements should be assumed to have a reasonable knowledge of IT, security and the CC series. All of the above may be presented in groups, classes, roles, types or other groupings or characterisations that allow easy understanding. The evaluator is reminded that these lists and definitions do not have to be part of the statement of security requirements, but may be placed (in part or in whole) in different subclauses. This may be especially applicable if the same terms are used in the rest of the PP-Module. The evaluator shall check that the statement of security requirements identifies all operations on the security requirements. The evaluator determines that all operations are identified in each SFR or SAR where such an operation is used. This includes both completed operations and uncompleted operations. Identification may be achieved by typographical distinctions, or by explicit identification in the surrounding text, or by any other distinctive means. If the PP-Module defines selection-based SFRs, the evaluator determines that the PP-Module clearly identifies the dependencies between the selection in an SFR and the selection-based SFR(s) to be included in the ST should that selection be chosen by the ST author. The evaluator shall examine the statement of security requirements to determine that all assignment operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all iteration operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all selection operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all refinement operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that each dependency of the security requirements is either satisfied, or that the security requirements rationale justifies the dependency not being satisfied. A dependency is satisfied by the inclusion of the relevant component (or one that is hierarchical to it) within the statement of security requirements. The component used to satisfy the dependency should, if necessary, be modified by operations to ensure that it actually satisfies that dependency. A justification that a dependency is not met should address either: why the dependency is not necessary or useful, in which case no further information is required; or that the dependency has been addressed by the operational environment of the TOE, in which case the justification should describe how the security objectives for the operational environment address this dependency. The evaluator ensures that if a functional package defines a dependency on another functional package, then that functional package is included in the PP-Module. If a functional package identifies dependencies on its requirements that need to be satisfied by the underlying PP-Module, the evaluator ensures that their analysis covers these dependencies as well. The evaluator shall check that the security requirements rationale traces each SFR back to the security objectives for the TOE. Optional requirements may require Threats/OSPs to be specified, and security objectives associated with these SPD elements are also covered by this work unit. The evaluator determines that each SFR is traced back to at least one security objective for the TOE. Failure to trace implies that either the security requirements rationale is incomplete, the security objectives for the TOE are incomplete, or the SFR has no useful purpose. The evaluator shall examine the security requirements rationale to determine that for each security objective for the TOE it justifies that the SFRs are suitable to meet that security objective for the TOE. If no SFRs trace back to the security objective for the TOE, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for a security objective for the TOE demonstrates that the SFRs are sufficient: if all SFRs that trace back to the objective are satisfied, the security objective for the TOE is achieved. If the SFRs that trace back to a security objective for the TOE have any uncompleted assignments, or uncompleted or restricted selections, the evaluator determines that for every conceivable completion or combination of completions of these operations, the security objective is still met. The evaluator also determines that each SFR that traces back to a security objective for the TOE is necessary: when the SFR is satisfied, it actually contributes to achieving the security objective. Note that the tracings from SFRs to security objectives for the TOE provided in the security requirements rationale may be a part of the justification, but do not constitute a justification by themselves. The evaluator shall check that the security requirements rationale explains why the SARs were chosen. The evaluator is reminded that any explanation is correct, as long as it is coherent and neither the SARs nor the explanation have obvious inconsistencies with the remainder of the PP-Module. An example of an obvious inconsistency between the SARs and the remainder of the PP-Module would be to have threat agents that are very capable, but an component that does not protect against these threat agents. The evaluator shall examine the statement of security requirements to determine that it is internally consistent. The evaluator determines that the combined set of all SFRs and SARs is internally consistent. With respect to optional requirements, the evaluator determines that: All optional requirements either trace to an SPD element that is itself not optional, or trace to an SPD element that is clearly associated with that optional SFR; All optional requirements are clearly identified as either: elective and therefore for inclusion purely at the discretion of the ST author (i.e. conformance to the PP-Module does not depend on their inclusion in the ST); or conditional and therefore required if a conformant TOE implements the functionality covered by the requirement. All optional requirements do not conflict with non-optional requirements (a capability cannot be both required and optional; however, a base capability can be required with enhancements to that capability being specified as optional). The evaluator determines that on all occasions where different security requirements apply to the same types of developer evidence, events, operations, data, tests to be performed etc. or to "all objects", "all subjects" etc., that these requirements do not conflict. Some possible conflicts are: an extended SAR specifying that the design of a certain cryptographic algorithm is to be kept secret, and another extended SAR specifying an open source review; specifying that subject identity is to be logged, specifying who has access to these logs, and specifying that some actions of subjects should be unobservable to other subjects. If the subject that should not be able to see an activity may access logs of this activity, these SFRs conflict; specifying deletion of information no longer needed, and specifying that a TOE may return to a previous state. If the information that is needed for the rollback to the previous state has been deleted, these requirements conflict; multiple iterations of , especially where some iterations cover the same subjects, objects, or operations. If one access control SFR allows a subject to perform an operation on an object, while another access control SFR does not allow this, these requirements conflict. This part of the PP-Module defines the security problem to be addressed by the TOE and the operational environment of the TOE. Evaluation of the security problem definition is required to demonstrate that the security problem intended to be addressed by the TOE and its operational environment, is clearly defined. The objective of this sub-activity is to determine that the security problem intended to be addressed by the PP-Module and its operational environment is clearly defined. the PP-Module. The developer shall provide a security problem definition. The security problem definition shall describe the threats. All threats shall be described in terms of a threat agent, an asset, and an adverse action. The security problem definition shall describe the OSPs. The security problem definition shall describe the assumptions about the operational environment of the TOE. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the security problem definition describes the threats. If all security objectives are derived from assumptions and/or OSPs only, the statement of threats need not be present in the PP-Module. In this case, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the security problem definition describes the threats that must be countered by the PP-Module and/or its operational environment. Note that if optional requirements are defined by the PP-Module, there may be associated threats that are covered by this work unit. The evaluator shall examine the security problem definition to determine that all threats are described in terms of a threat agent, an asset, and an adverse action. If all security objectives are derived from assumptions and OSPs only, the statement of threats need not be present in the PP-Module. In this case, this work unit is not applicable and therefore considered to be satisfied. Threat agents may be further described by aspects such as expertise, resource, opportunity, and motivation. The evaluator shall examine that the security problem definition describes the OSPs. If all security objectives are derived from assumptions and/or threats only, OSPs need not be present in the PP-Module. In this case, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that OSP statements are made in terms of rules or guidelines that must be followed by the TOE and/or its operational environment. The evaluator determines that each OSP is explained and/or interpreted in sufficient detail to make it clearly understandable; a clear presentation of policy statements is necessary to permit tracing security objectives to them. Note that if optional requirements are defined by the PP-Module, there may be associated OSPs that are covered by this work unit. The evaluator shall examine the security problem definition to determine that it describes the assumptions about the operational environment of the TOE. If there are no assumptions, this work unit is not applicable and is therefore considered to be satisfied. The evaluator determines that each assumption about the operational environment of the TOE is explained in sufficient detail to enable consumers to determine that their operational environment matches the assumption. If the assumptions are not clearly understood, the end result may be that the TOE is used in an operational environment in which it will not function in a secure manner. The class encompasses five families. These families specify assurance requirements that are designed to provide confidence that a composed TOE will operate securely when relying upon security functionality provided by previously evaluated software, firmware or hardware components. Composition involves taking two or more IT entities successfully evaluated against the CC series security assurance requirements packages (base components and dependent components, see Annex B) and combining them for use, with no further development of either IT entity. The development of additional IT entities is not included (entities that have not previously been the subject of a component evaluation). The composed TOE forms a new product that can be installed and integrated into any specific environment instance that meets the objectives for the environment. This approach does not provide an alternative approach for the evaluation of components. under provides a composed TOE integrator a method, which can be used as an alternative to other assurance levels specified in the CC series, to gain confidence in a TOE that is the combination of two or more successfully evaluated components without having to re-evaluate the composite TSF. The composed TOE integrator is referred to as "developer" throughout the class, with any references to the developer of the base or dependent components clarified as such. CAPs, as defined in CC Part 5 provide an assurance scale for composed TOEs. This assurance scale is required in addition to other assurance packages, for example the EALs, because to combine components evaluated against another assurance package and gain equivalent assurance in the resulting composed TOE, all SARs shall be applied to the composed TOE. Although reuse can be made of the component TOE evaluation results, there are often additional aspects of the components that have to be considered in the composed TOE, as described in B.3. Due to the different parties involved in a composed TOE evaluation activity it is generally not possible to gain all necessary evidence about these additional aspects of the components to apply the appropriate EAL. Hence, CAPs have been defined to address the issue of combining evaluated components and gaining a meaningful result. This is discussed further in Annex B. A dependent component-a B base component-b 1 (component-a) 2 (component-b) 3 (component-b) In a composed TOE it is generally the case that one component relies on the services provided by another component. The component requiring services is termed the dependent component and the component providing the services is termed the base component. This interaction and distinct is discussed further in Annex B. It is assumed to be the case that the developer of the dependent component is supporting the composed TOE evaluation in some manner (as developer, sponsor, or just cooperating and providing the necessary evaluation evidence from the dependent component evaluation) The components included in the CAP assurance packages should not be used as augmentations for component TOE evaluations, as this would provide no meaningful assurance for the component. The families within the class interact in a similar manner to the , and classes in a component TOE evaluation and hence leverage from the specification of requirements from those classes where applicable. There are however a few items specific to composed TOE evaluations. To determine how the components interact and identify any deviations from the evaluations of the components, the dependencies that the dependent component has upon the underlying base component are identified in . This reliance on the base component is specified in terms of the interfaces through which the dependent component makes calls for services in support of the dependent component SFRs. The interfaces, and at higher levels the supporting behaviour, provided by the base component in response to those service requests are analysed in . The family is based on the family, as at the simplest level the TSF of each component can be viewed as a subsystem of the composed TOE, with additional portions of each component seen as additional subsystems. Therefore, the interfaces between the components are seen as interactions between subsystems in a component TOE evaluation. It is possible that the interfaces and supporting behaviour descriptions provided for are incomplete. This is determined during the conduct of . The family takes the outputs of and and determines whether the components are being used in their evaluated configuration and identifies where any specifications are incomplete, which are then identified as inputs into testing () and vulnerability analysis () activities of the composed TOE. Testing of the composed TOE is performed to determine that the composed TOE exhibits the expected behaviour as determined by the composed TOE SFRs, and at higher levels demonstrates the compatibility of the interfaces between the components of the composed TOE. The vulnerability analysis of the composed TOE leverages from the outputs of the vulnerability analysis of the component evaluations. The composed TOE vulnerability analysis considers any residual vulnerabilities from the component evaluations to determine that the residual vulnerabilities are not applicable to the composed TOE. A search of publicly available information relating to the components is also performed to identify any issues reported in the components since the completion of the respective evaluations. The interaction between the families is depicted in below. This shows by solid arrowed lines where the evidence and understanding gained in one family feeds into the next activity and the dashed arrows identify where an activity explicitly traces back to the composed TOE SFRs, as described above.

Further discussion of the definition and interactions within composed TOEs is provided in Annex B. The goal of this activity is to determine whether the components can be integrated in a secure manner, as defined in the ST for the composed TOE. This is achieved through examination and testing of the interfaces between the components, supported by examination of the design of the components and the conduct of vulnerability analysis. The family identifies where the dependent component is reliant upon IT in its operational environment (satisfied by a base component in the composed TOE evaluation) in order to provide its own security services. This reliance is identified in terms of the interfaces expected by the dependent component to be provided by the base component. then determines which interfaces of the base component were considered (as TSFI) during the component evaluation of the base component. It should be noted that does not cover other evidence that may be needed to address the technical integration problem of composing components (e.g. descriptions of non-TSF interfaces of the operating system, rules for integration, etc.). This is outside the security assessment of the composition and is a functional composition issue. As part of the evaluator will perform testing of the composed TOE SFRs at the composed TOE interfaces and of the interfaces of the base component relied upon by the dependent component to confirm they operate as specified. The subset selected will consider the possible effects of changes to the configuration/use of the base component as used in the composed TOE. These changes are identified from the configuration of the base component determined during the base component evaluation. The developer will provide test evidence for each of the base component interfaces (the requirements for coverage are consistent with those applied to the evaluation of the base component). requires the evaluator to determine whether the appropriate assurance measures have been applied to the base component, and whether the base component is being used in its evaluated configuration. This includes determination of whether all security functionality required by the dependent component was within the TSF of the base component. The requirement may be met through the production of evidence that each of these is demonstrated to be upheld. This evidence may be in the form of the security target and a public report of the component evaluation (e.g. certification report). If, on the other hand, one of the above have not been upheld, then it may be possible that an argument can be made as to why the assurance gained during an original evaluation is unaffected. If this is not possible then additional evaluation evidence for those aspects of the base component not covered may have to be provided. This material is then assessed in . For example, it may be the case as described in the Interactions between entities (see CC Part 3, B.4, Interactions between composed IT entities) that the dependent component requires the base component to provide more security functionality in the composed TOE than included in the base component evaluation. This would be determined during the application of the and families. In this case the composition rationale evidence provided for would demonstrate that the assurance gained from the base component evaluation is unaffected. This may be achieved by means including: Performing a re-evaluation of the base component focusing on the evidence relating to the extended part of the TSF; Demonstrating that the extended part of the TSF cannot affect other portions of the TSF, and providing evidence that the extended part of the TSF provides the necessary security functionality. This family addresses the requirement to demonstrate that the base component can provide an appropriate level of assurance for use in composition. There is only a single component in this family. the composed ST; the composition rationale; the reliance information; the development information; unique identifier. The developer shall provide composition rationale for the base component. The composition rationale shall demonstrate that a level of assurance at least as high as that of the dependent component has been obtained for the support functionality of the base component, when the base component is configured as required to support the TSF of the dependent component. The evaluator shall confirm that the information meets all requirements for content and presentation of evidence. The evaluator shall examine the correspondence analysis with the development information and the reliance information to identify the interfaces that are relied upon by the dependent component which are not detailed in the development information. The evaluator's goal in this work unit is two-fold: to determine which interfaces relied upon by the dependent component have had the appropriate assurance measures applied; to determine that the assurance package applied to the base component during the base component evaluation contained either the same assurance requirements as those in the package applied to the dependent component during its' evaluation, or hierarchically higher assurance requirements. The evaluator may use the correspondence tracing in the development information developed during the activities (e.g. , , ) to help identify the interfaces identified in the reliance information that are not considered in the development information. The evaluator will record the SFR-enforcing interfaces described in the reliance information that are not included in the development information. These will provide input to work unit, helping to identify the portions of the base component in which further assurance is required. If both the base and dependent components were evaluated against the same assurance package, then the determination of whether the level of assurance in the portions within the base component evaluation is at least as high as that of the dependent component is trivial. If however, the assurance packages applied to the components during the component evaluations differ, the evaluator needs to determine that the assurance requirements applied to the base component are all hierarchically higher to the assurance requirements applied to the dependent component. The evaluator shall examine the composition rationale to determine, for those included base component interfaces on which the dependent TSF relies, whether the interface was considered during the evaluation of the base component. The ST, component public evaluation report (e.g. certification report) and guidance documents for the base component all provide information on the scope and boundary of the base component. The ST provides details of the logical scope and boundary of the composed TOE, allowing the evaluator to determine whether an interface relates to a portion of the product that was within the scope of the evaluation. The guidance documentation provides details of use of all interfaces for the composed TOE. Although the guidance documentation may include details of interfaces in the product that are not within the scope of the evaluation, any such interfaces should be identifiable, either from the scoping information in the ST or through a portion of the guidance that deals with the evaluated configuration. The public evaluation report may provide any additional constraints on the use of the composed TOE that are necessary. Therefore, the combination of these inputs allows the evaluator to determine whether an interface described in the composition rationale has the necessary assurance associated with it, or whether further assurance is required. The evaluator will record those interfaces of the base component for which additional assurance is required, for consideration during . The evaluator shall examine the composition rationale to determine that the necessary assurance measures have been applied to the base component. The evaluation verdicts, and resultant assurance, for the base component can be reused provided the same portions of the base component are used in the composed TOE and they are used in a consistent manner. In order to determine whether the necessary assurance measures have already been applied to the component, and the portions of the component for which assurance measures still need to be applied, the evaluator should use the output of the .*.2E action and the work units and . For those interfaces identified in the reliance information , but not discussed in , additional information is required. (Identified in .) For those interfaces used inconsistently in the composed TOE from the base component (difference between the information provided in and the impact of the differences in use need to be considered. (Identified in .*.2E.) For those interfaces identified in composition rationale for which no assurance has previously been gained, additional information is required. (Identified in .) For those interfaces consistently described in the reliance information, composition rationale and the development information, no further action is required as the results from the base component evaluation can be re-used. The interfaces of the base component reported to be required by the reliance information but not included in the development information indicate the portions of the base component where further assurance is required. The interfaces identify the entry points into the base component. For those interfaces included in both the development information and reliance information, the evaluator is to determine whether the interfaces are being used in the composed TOE in a manner that is consistent with the base component evaluation. The method of use of the interface will be considered during the activities to determine that the use of the interface is consistent in both the base component and the composed TOE. The remaining consideration is the determination of whether the configurations of the base component and the composed TOE are consistent. To determine this, the evaluator will consider the guidance documentation of each to ensure they are consistent (see further guidance below regarding consistent guidance documentation). Any deviation in the documentation will be further analysed by the evaluation to determine the possible effects. For those interfaces that are consistently described in the reliance information and development information, and for which the guidance is consistent for the base component and the composed TOE, the required level of assurance has been provided. The following text provides guidance on how to determine consistency between assurance gained in the base component, the evidence provided for the composed TOE, and the analysis performed by the evaluator in the instances where inconsistencies are identified. Development: The reliance information identifies the interfaces in the dependent component that are to be matched by the base component. If an interface identified in the reliance information is not identified in the development information, then the composition rationale is to provide a justification of how the base component provides the required interfaces. If an interface identified in the reliance information is identified in the development information, but there are inconsistencies between the descriptions, further analysis is required. The evaluator identifies the differences in use of the base component as considered in the base component evaluation and the composed TOE evaluation. The evaluator will devise testing to be performed (during the conduct of ) to test the interface. The patch status of the base and dependent components as used in the composed TOE should be compared to the patch status of the components during the component evaluations. If any patches have been applied to the components, the composition rationale is to include details of the patches, including any potential impact to the SFRs of the evaluated component. The evaluator should consider the details of the changes provided and verify the accuracy of the potential impact of the change on the component SFRs. The evaluator should then consider whether the changes made by the patch should be verified through testing, and will identify the necessary testing approach. The testing may take the form of repeating the applicable evaluator/developer testing performed for the component evaluation of the component or it may be necessary for the evaluator to devise new tests to confirm the modified component. If any of the individual components have been the subject of assurance continuity activities since the completion of the component evaluation, the evaluator will consider the changes assessed in the assurance continuity activities during the independent vulnerability analysis activity for the composed TOE (in ). Guidance: The guidance for the composed TOE is likely to make substantial reference out to the guidance for the individual components. The minimal guidance expected to be necessary is the identification of any ordering dependencies in the application of guidance for the dependent and base components, particularly during the preparation (installation) of the composed TOE. In addition to the application of the and families to the guidance for the composed TOE, it is necessary to analyse the consistency between the guidance for the components and the composed TOE, to identify any deviations. If the composed TOE guidance refers out to the base component and dependent component guidance, then the consideration for consistency is limited to consistency between the guidance documentation provided for each of the components (i.e. consistency between the base component guidance and the dependent component guidance). However, if additional guidance is provided for the composed TOE, to that provided for the components, greater analysis is required, as consistency is also required between the guidance documentation for the components and guidance documentation for the composed TOE. Consistent in this instance is understood to mean that either the guidance is the same or it places additional constraints on the operation of the individual components when combined, in a similar manner to refinement of functional/assurance components. With the information available (that used as input for or the development aspects discussed above) the evaluator may be able to determine all possible impacts of the deviation from the configuration of the base component specified in the component evaluation. However, for high EALs (where evaluation of the base component included requirements) it is possible that, unless detailed design abstractions for the base component are delivered as part of the development information for the composed TOE, the possible impacts of the modification to the guidance cannot be fully determined as the internals are unknown. In this case the evaluator will report the residual risk of the analysis. These residual risks are to be included in any public evaluation report for the composed TOE. The evaluator will note these variances in the guidance for input into evaluator independent testing activities . The guidance for the composed TOE may add to the guidance for the components, particularly in terms of installation and the ordering of installation steps for the base component in relation to the installation steps for the dependent component. The ordering of the steps for the installation of the individual components should not change, however they may need to be interleaved. The evaluator will examine this guidance to ensure that it still meets the requirement of the activity performed during the evaluations of the components. It may be the case that the reliance information identifies that interfaces of the base component, in addition to those identified as TSFIs of the base component, are relied upon by the dependent component are identified in the reliance information. It may be necessary for guidance to be provided for the use of any such additional interfaces in the base component. Provided the consumer of the composed TOE is to receive the guidance documentation for the base component, then the results of the and verdicts for the base component can be reused for those interfaces considered in the evaluation of the base component. However, for the additional interfaces relied upon by the dependent component, the evaluator will need to determine that the guidance documentation for the base component meets the requirements of and , as applied in the base component evaluations. For those interfaces considered during the base component evaluation, and therefore, for which assurance has already been gained, the evaluator will ensure that the guidance for the use of each interface for the composed TOE is consistent with that provided for the base component. To determine the guidance for the composed TOE is consistent with that for the base component, the evaluator should perform a mapping for each interface to the guidance provided for both the composed TOE and the base component. The evaluator then compares the guidance to determine consistency. Examples of additional constraints provided in composed TOE guidance that would be considered to be consistent with component guidance are (guidance for a component is given followed by an example of guidance for a composed TOE that would be considered to provide additional constraints): Component: The password length must be set to a minimum of 8 characters length, including alphabetic and numeric characters. Composed TOE: The password length must be set to a minimum of 10 characters in length, including alphabetic and numeric characters and at least one of the following special characters: ( ) { } ^ < > - _. It would only be acceptable to increase the password length to [integer > 8] characters while removing the mandate for the inclusion of both alphabetic and numeric characters for the composed TOE, if the same or a higher metric was achieved for the strength rating (taking into account the likelihood of the password being guessed). Component: The following services are to be disabled in the registry settings: WWW Publishing Service and ICDBReporter service. Composed TOE: The following services are to be disabled in the registry settings: Publishing Service, ICDBReporter service, Remote Procedure Call (RPC) Locator and Procedure Call (RPC) Service. Component: Select the following attributes to be included in the accounting log files: date, time, type of event, subject identity and success/failure. Composed TOE: Select the following attributes to be included in the accounting log files: date, time, type of event, subject identity, success/failure, event message and process thread. If the guidance for the composed TOE deviates (is not a refinement) from that provided for the base component, the evaluator will assess the potential risks of the modification to the guidance. The evaluator will use the information available (including that provided in the public domain, the architectural description of the base component in the public evaluation report (e.g. certification report), the context of the guidance from the remainder of the guidance documentation) to identify likely impact of the modification to the guidance on the SFRs of the composed TOE. If during the dependent component evaluation the trial installation used the base component to satisfy the environment requirements of the dependent component this work unit for the composed TOE is considered to be satisfied. If the base component was not used in satisfaction of the work unit during the dependent component evaluation, the evaluator will apply the user procedures provided for the composed TOE to prepare the composed TOE, in accordance with the guidance specified in . This will allow the evaluator to determine that the preparative guidance provided for the composed TOE is sufficient to prepare the composed TOE and its operational environment securely. Delivery: If there is a different delivery mechanism used for the delivery of the composed TOE (i.e. the components are not delivered to the consumer in accordance with the secure delivery procedures defined and assessed during the evaluation of the components), the delivery procedures for the composed TOE will require evaluation against the requirements applied during the components evaluations. The composed TOE may be delivered as an integrated product or may require the components to be delivered separately. If the components are delivered separately, the results of the delivery of the base component and dependent component are reused. The delivery of the base component is checked during the evaluator trial installation of the dependent component, using the specified guidance and checking the aspects of delivery that are the responsibility of the user, as described in the guidance documentation for the base component. If the composed TOE is delivered as a new entity, then the method of delivery of that entity must be considered in the composed TOE evaluation activities. The assessment of the delivery procedures for composed TOE items is to be performed in accordance with the methodology for as for any other [component] TOE, ensuring any additional items (e.g. additional guidance documents for the composed TOE) are considered in the delivery procedures. CM Capabilities: The unique identification of the composed TOE is considered during the application of Evaluation of sub-activity and the items from which that composed TOE is comprised are considered during the application of Evaluation of sub-activity . Although additional guidance may be produced for the composed TOE, the unique identification of this guidance (considered as part of the unique identification of the composed TOE during Evaluation of sub-activity ) is considered sufficient control of the guidance. The verdicts of the remaining (not considered above) activities can be reused from the base component evaluation, as no further development is performed during integration of the composed TOE. There are no additional considerations for development security as the integration is assumed to take place at either the consumer's site or, in the instance that the composed TOE is delivered as an integrated product, at the site of the dependent component developer. Control at the consumer's site is outside the consideration of the CC (all parts). No additional requirements or guidance are necessary if integration is at the same site as that for the dependent component, as all components are considered to be configuration items for the composed TOE, and should therefore be considered under the dependent component developer's security procedures anyway. Tools and techniques adopted during integration will be considered in the evidence provided by the dependent component developer. Any tools/techniques relevant to the base component will have been considered during the evaluation of the base component. For example, if the base component is delivered as source code and requires compilation by the consumer (e.g. dependent component developer who is performing integration) the compiler would have been specified and assessed, along with the appropriate arguments, during evaluation of the base component. There is no life-cycle definition applicable to the composed TOE, as no further development of items is taking place. The results of flaw remediation for a component are not applicable to the composed TOE. If flaw remediation is included in the assurance package for the composed TOE, then the requirements are to be applied during the composed TOE evaluation (as for any augmentation). Tests: The composed TOE will have been tested during the conduct of the activities for evaluation of the dependent component, as the configurations used for testing of the dependent component should have included the base component to satisfy the requirements for IT in the operational environment. If the base component was not used in the testing of the dependent component for the dependent component evaluation, or the configuration of either component varied from their evaluated configurations, then the developer testing performed for evaluation of the dependent component to satisfy is to be repeated on the composed TOE. This family requires that testing of composed TOE and testing of the base component, as used in the composed TOE, is performed. The components in this family are levelled on the basis of increasing rigour of interface testing and increasing rigour of the analysis of the sufficiency of the tests to demonstrate that the composed TSF operates in accordance with the reliance information and the composed TOE SFRs. There are two distinct aspects of testing associated with this family: testing of the interfaces between the base component and the dependent component, which the dependent component rely upon for enforcement of security functionality, to demonstrate their compatibility; testing of the composed TOE to demonstrate that the TOE behaves in accordance with the SFRs for the composed TOE. If the test configurations used during evaluation of the dependent component included use of the base component as a "platform" and the test analysis sufficiently demonstrates that the TSF behaves in accordance with the SFRs, the developer need perform no further testing of the composed TOE functionality. However, if the base component was not used in the testing of the dependent component, or the configuration of either component varied, then the developer is to perform testing of the composed TOE. This may take the form of repeating the dependent component developer testing of the dependent component, provided this adequately demonstrates the composed TOE TSF behaves in accordance with the SFRs. The developer is to provide evidence of testing the base component interfaces used in the composition. The operation of base component TSFIs would have been tested as part of the activities during evaluation of the base component. Therefore, provided the appropriate interfaces were included within the test sample of the base component evaluation and it was determined in that the base component is operating in accordance with the base component evaluated configuration, with all security functionality required by the dependent component included in the TSF, the evaluator action may be met through reuse of the base component verdicts. If this is not the case, the base component interfaces used relevant to the composition that are affected by any variations to the evaluated configuration and any additional security functionally will be tested to ensure they demonstrate the expected behaviour. The expected behaviour to be tested is that described in the evidence. The objective of this sub-activity is to determine whether the developer correctly performed and documented tests for each of the base component interfaces on which the dependent component relies. As part of this determination the evaluator repeats a sample of the tests performed by the developer and performs any additional tests required to ensure the expected behaviour of all composed TOE SFRs and interfaces of the base component relied upon by the dependent component is demonstrated. the composed TOE suitable for testing; the composed TOE testing evidence; the reliance information; the development information. The developer shall provide composed TOE test documentation. The developer shall provide base component interface test documentation. The developer shall provide the composed TOE for testing. The developer shall provide an equivalent set of resources to those that were used in the base component developer's functional testing of the base component. The composed TOE and base component interface test documentation shall consist of test plans, expected test results and actual test results. The test documentation from the developer execution of the composed TOE tests shall demonstrate that the TSF behaves as specified. The test documentation from the developer execution of the base component interface tests shall demonstrate that the base component interface relied upon by the dependent component behaves as specified. The base component shall be suitable for testing. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the composed TOE test documentation to determine that it consists of test plans, expected test results and actual test results. This work unit may be satisfied by provision of the test evidence from the evaluation of the dependent component if the base component was used to satisfy the requirements for IT in the operational environment of the dependent component. All work units necessary for the satisfaction of will be applied to determine: that the test documentation consists of test plans, expected test results, and actual test results; that the test documentation contains the information necessary to ensure the tests are repeatable; the level of developer effort that was applied to testing of the base component. The evaluator shall examine the base component interface test documentation to determine that it consists of test plans, expected test results and actual test results. This work unit may be satisfied by provision of the test evidence from the evaluation of the base component for those interfaces relied upon in the composed TOE by the dependent component are TSFIs of the successfully evaluated base component. The determination of whether the interfaces of the base component relied upon by the dependent component were in fact TSFIs of the evaluated base component is made during the activity. All work units necessary for the satisfaction of will be applied to determine: that the test documentation consist of test plans expected test results and actual test results; that the test documentation contains the information necessary to ensure the tests are repeatable; the level of developer effort that was applied to testing of the base component. The evaluator shall examine the test documentation to determine that the developer execution of the composed TOE tests shall demonstrate that the TSF behaves as specified. The evaluator should construct a mapping between the tests described in the test plan and the SFRs specified for the composed TOE to identify which SFRs have been tested by the developer. Guidance on this work unit can be found in: Subclause 15.2.1. Subclause 15.2.2. The outputs from the successful execution of the tests (as assessed for can be compared with the mapping to determine that the SFRs of the composed TOE, as tested by the developer, behave as expected. The evaluator shall examine the test documentation to determine that the developer execution of the base component interface tests shall demonstrate that the base component interfaces relied upon by the dependent component behave as specified. The evaluator should construct a mapping between the tests described in the test plan and the interfaces of the base component relied upon by the dependent component (as specified in the reliance information, examined under ) to identify which base component interfaces have been tested by the developer. Guidance on this work unit can be found in: Subclause 15.2.1. Subclause 15.2.2. The outputs from the successful execution of the tests (as assessed for can be compared with the mapping to determine that the interfaces of the base component, as tested by the developer, behave as expected. The evaluator shall examine the composed TOE to determine that it has been installed properly and is in a known state. To determine that the composed TOE has been installed properly and is in a known state the and work units will be applied to the TOE provided by the developer for testing. The evaluator shall examine the set of resources provided by the developer to determine that they are equivalent to the set of resources used by the base component developer to functionally test the base component. To determine that the set of resources provided are equivalent to those used to functionally test the base component as used in the composed TOE, the work unit will be applied. The evaluator shall execute a sample of test in the test documentation to verify the developer test results. The evaluator shall perform testing in accordance with , for a subset of the SFRs specified in the composed security target, to verify the developer test results. The evaluator will apply all work units necessary for the satisfaction of , reporting in the ETR for the composed TOE all analysis, results and verdicts as dictated by the associated work units. The evaluator shall test a subset of the TSF interfaces of the composed TOE to confirm that the composed TSF operates as specified. The evaluator shall perform testing in accordance with , for a subset of the SFRs specified in the composed security target, to confirm that the TSF operates as specified. The evaluator will apply all work units necessary for the satisfaction of , reporting in the ETR for the composed TOE all analysis, results and verdicts as dictated by the work units. When selecting interfaces of the TSF of the composed TOE to test, the evaluator should take into account any modifications to the components from the evaluated version or configuration. Modifications to the component from that evaluated may include patches introduced, a different configuration as a result of modified guidance documentation, reliance an additional portion of the component that was not within the TSF of the component. These modifications will have been identified during the activity. The objective of this sub-activity is to determine whether the developer correctly performed and documented tests for each of the base component interfaces on which the dependent component relies. As part of this determination the evaluator repeats a sample of the tests performed by the developer and performs any additional tests required to fully demonstrate the expected behaviour of the composed TOE and the interfaces of the base component relied upon by the dependent component. the composed TOE suitable for testing; the composed TOE testing evidence; the reliance information; the development information. The developer shall provide composed TOE test documentation. The developer shall provide base component interface test documentation. The developer shall provide the composed TOE for testing. The developer shall provide an equivalent set of resources to those that were used in the base component developer's functional testing of the base component. The composed TOE and base component interface test documentation shall consist of test plans, expected test results and actual test results. The test documentation from the developer execution of the composed TOE tests shall demonstrate that the TSF behaves as specified and is complete. The test documentation from the developer execution of the base component interface tests shall demonstrate that the base component interface relied upon by the dependent component behaves as specified and is complete. The base component shall be suitable for testing. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the composed TOE test documentation to determine that it consists of test plans, expected test results and actual test results. This work unit may be satisfied by provision of the test evidence from the evaluation of the dependent component if the base component was used to satisfy the requirements for IT in the operational environment of the dependent component. All work units necessary for the satisfaction of will be applied to determine: that the test documentation consist of test plans expected test results and actual test results; that the test documentation contains the information necessary to ensure the tests are repeatable; the level of developer effort that was applied to testing of the base component. The evaluator shall examine the base component interface test documentation to determine that it consists of test plans, expected test results and actual test results. This work unit may be satisfied by provision of the test evidence from the evaluation of the base component for those interfaces relied upon in the composed TOE by the dependent component are TSFIs of the successfully evaluated base component. The determination of whether the interfaces of the base component relied upon by the dependent component were in fact TSFIs of the evaluated base component is made during the activity. All work units necessary for the satisfaction of will be applied to determine: that the test documentation consists of test plans, expected test results, and actual test results; that the test documentation contains the information necessary to ensure the tests are repeatable; the level of developer effort that was applied to testing of the base component. The evaluator shall examine the test documentation to determine that it provides accurate correspondence between the tests in the test documentation relating to the testing of the composed TOE and the composed TOE SFRs in the composed TOE security target. A simple cross-table may be sufficient to show test correspondence. The identification of correspondence between the tests and SFRs presented in the test documentation has to be unambiguous. The evaluator shall examine the test documentation to determine that the developer execution of the composed TOE tests shall demonstrate that the TSF behaves as specified. Guidance on this work unit can be found in: Subclause 15.2.1. Subclause 15.2.2. The outputs from the successful execution of the tests (as assessed for can be compared with the mapping to determine that the SFRs of the composed TOE, as tested by the developer, behave as expected. The evaluator shall examine the test documentation to determine that it provides accurate correspondence between the tests in the test documentation relating to the testing of the base component interfaces relied upon by the dependent component and the interfaces specified in the reliance information. A simple cross-table may be sufficient to show test correspondence. The identification of correspondence between the tests and interfaces presented in the test documentation has to be unambiguous. The evaluator shall examine the test documentation to determine that the developer execution of the base component interface tests shall demonstrate that the base component interfaces relied upon by the dependent component behave as specified. Guidance on this work unit can be found in: Subclause 15.2.1. Subclause 15.2.2. The outputs from the successful execution of the tests (as assessed for can be compared with the mapping to determine that the interfaces of the base component, as tested by the developer, behave as expected. The evaluator shall examine the composed TOE to determine that it has been installed properly and is in a known state. To determine that the composed TOE has been installed properly and is in a known state the and work units will be applied to the TOE provided by the developer for testing. The evaluator shall examine the set of resources provided by the developer to determine that they are equivalent to the set of resources used by the base component developer to functionally test the base component. To determine that the set of resources provided are equivalent to those used to functionally test the base component as used in the composed TOE, the work unit will be applied. The evaluator shall execute a sample of test in the test documentation to verify the developer test results. The tests are to be selected and executed in accordance with , to demonstrate the correct behaviour of the SFRs specified in the composed TOE security target. The evaluator will apply all work units necessary for the satisfaction of , reporting in the ETR for the composed TOE all analysis, results and verdicts as dictated by the associated work units. The evaluator shall test a subset of the TSF interfaces of the composed TOE to confirm that the composed TSF operates as specified. The evaluator shall perform testing in accordance with , for a subset of the SFRs specified in the composed security target, to confirm that the TSF operates as specified. The evaluator will apply all work units necessary for the satisfaction of , reporting in the ETR for the composed TOE all analysis, results and verdicts as dictated by the work units. When selecting interfaces of the TSF of the composed TOE to test, the evaluator should take into account any modifications to the components from the evaluated version or configuration. Modifications to the component from that evaluated may include patches introduced, a different configuration as a result of modified guidance documentation, reliance an additional portion of the component that was not within the TSF of the component. These modifications will have been identified during the activity. The evaluator shall perform testing, in accordance with Evaluation of sub-activity , for a subset of the interfaces to the base component to confirm they operate as specified. The evaluator will apply all work units necessary for the satisfaction of , reporting in the ETR for the composed TOE all analysis, results and verdicts as dictated by the work units. When selecting interfaces of the base component to test, the evaluator should take into account any modifications to the base component from the evaluated version or configuration. In particular, the evaluator should consider the development of tests to demonstrate the correct behaviour of interfaces of the base component that were not considered during the evaluation of the base component. These additional interfaces and other modifications to the base component will have been identified during the activity. This family sets out requirements for a specification of the base component in increasing levels of detail. Such information is required to gain confidence that the appropriate security functionality is provided to support the requirements of the dependent component (as identified in the reliance information). The components are levelled on the basis of increasing amounts of detail about the interfaces provided, and how they are implemented. The TSF of the base component is often defined without knowledge of the dependencies of the possible applications with which it may by composed. The TSF of this base component is defined to include all parts of the base component that have to be relied upon for enforcement of the base component SFRs. This will include all parts of the base component required to implement the base component SFRs. The functional specification of the base component will describe the TSFI in terms of the interfaces the base component provides to allow an external entity to invoke operations of the TSF. This includes interfaces to the human user to permit interaction with the operation of the TSF invoking SFRs and also interfaces allowing an external IT entity to make calls into the TSF. The functional specification only provides a description of what the TSF provides at its interface and the means by which that TSF functionality are invoked. Therefore, the functional specification does not necessarily provide a complete interface specification of all possible interfaces available between an external entity and the base component. It does not include what the TSF expects/requires from the operational environment. The description of what a dependent component TSF relies upon of a base component is considered in and the development information evidence provides a response to the interfaces specified. The development information evidence includes a specification of the base component. This may be the evidence used during evaluation of the base component to satisfy the requirements, or may be another form of evidence produced by either the base component developer or the composed TOE developer. This specification of the base component is used during to gain confidence that the appropriate security functionality is provided to support the requirements of the dependent component. The level of detail required of this evidence increases to reflect the level of required assurance in the composed TOE. This is expected to broadly reflect the increasing confidence gained from the application of the assurance packages to the components. The evaluator determines that this description of the base component is consistent with the reliance information provided for the dependent component. The objective of this sub-activity is to determine that the appropriate security functionality is provided by the base component to support the dependent component. This is achieved through examination of the interfaces of the base component to determine that they are consistent with the interfaces specified in the reliance information; those required by the dependent component. The description of the interfaces into the base component is to be provided at a level of detail consistent with Evaluation of sub-activity although not all of the aspects necessary for satisfaction of Evaluation of sub-activity are required for Evaluation of sub-activity , as once the interface has been identified and the purpose described the remaining detail of the interface specification can be reused from evaluation of the base component. the composed ST; the development information; the reliance information. The developer shall provide development information for the base component. The development information shall describe the purpose of each interface of the base component used in the composed TOE. The development information shall show correspondence between the interfaces, used in the composed TOE, of the base component and the dependent component to support the TSF of the dependent component. The evaluator shall confirm that the information meets all requirements for content and presentation of evidence. The evaluator shall examine the development information to determine that it describes the purpose of each interface. The base component provides interfaces to support interaction with the dependent component in the provision of the dependent TSF. The purpose of each interface is to be described at the same level as the description of the interfaces to the dependent component TSF functionality, as would be provided between subsystems in . This description is to provide the reader with an understanding of how the base component provides the services required by the dependent component TSF. This work unit may be satisfied by the provision of the functional specification for the base component for those interfaces that are TSFIs of the base component. The evaluator shall examine the development information to determine the correspondence, between the interfaces of the base component and the interfaces on which the dependent component relies, is accurate. The correspondence between the interfaces of the base component and the interfaces on which the dependent component relies may take the form of a matrix or table. The interfaces that are relied upon by the dependent component are identified in the reliance information as examined during activity. There is, during this activity, no requirement to determine completeness of the coverage of interfaces that are relied upon by the dependent component, only that the correspondence is correct and ensuring that interfaces of the base component are mapped to interfaces required by the dependent component wherever possible. The completeness of the coverage is considered in activities. The evaluator shall determine that the interface description provided is consistent with the reliance information provided for the dependent component. The evaluator shall examine the development information and the reliance information to determine that the interfaces are described consistently. The evaluator's goal in this work unit is to determine that the interfaces described in the development information for the base component and the reliance information for the dependent component are represented consistently. The objective of this sub-activity is to determine that the appropriate security functionality is provided by the base component to support the dependent component. This is achieved through examination of the interfaces and associated security behaviour of the base component to determine that they are consistent with the interfaces specified in the reliance information; those required by the dependent component. the composed ST; the development information; reliance information. The developer shall provide development information for the base component. The development information shall describe the purpose and method of use of each interface of the base component used in the composed TOE. The development information shall provide a high-level description of the behaviour of the base component, which supports the enforcement of the dependent component SFRs. The development information shall show correspondence between the interfaces, used in the composed TOE, of the base component and the dependent component to support the TSF of the dependent component. The evaluator shall confirm that the information meets all requirements for content and presentation of evidence. The evaluator shall examine the development information to determine that it describes the purpose of each interface. The base component provides interfaces to support interaction with the dependent component in the provision of the dependent TSF. The purpose of each interface is to be described at the same level as the description of the interfaces to the dependent component TSF functionality, as would be provided between subsystems in . This description is to provide the reader with an understanding of how the base component provides the services required by the dependent component TSF. This work unit may be satisfied by the provision of the functional specification for the base component for those interfaces that are TSFIs of the base component. The evaluator shall examine the development information to determine that it describes the method of use for each interface. The method of use for an interface summarizes how the interface is manipulated in order to invoke the operations and obtain results associated with the interface. The evaluator should be able to determine from reading this material in the development information how to use each interface. This does not necessarily mean that there needs to be a separate method of use for each interface, as it may be possible to describe in general how APIs are invoked, for instance, and then identify each interface using that general style. This work unit may be satisfied by the provision of the functional specification for the base component for those interfaces that are TSFIs of the base component. The evaluator shall examine the development information to determine that it describes the behaviour of the base component that supports the enforcement of the dependent component SFRs. The dependent component invokes interfaces of the base component for the provision of services by the base component. For the interfaces of the base component that are invoked, the development information shall provide a high-level description of the associated security behaviour of the base component. The description of the base component security behaviour will outline how the base component provides the necessary service when the call to the interface is made. This description is to be at a level similar to that provided for . Therefore, the provision of the TOE design evidence from the base component evaluation would satisfy this work unit, where the interfaces invoked by the dependent component are TSFI of the base component. If the interfaces invoked by the dependent component are not TSFIs of the base component it is the associated security behaviour will not necessarily be described in the base component TOE design evidence. The evaluator shall examine the development information to determine the correspondence, between the interfaces of the base component and the interfaces on which the dependent component relies, is accurate. The correspondence between the interfaces of the base component and the interfaces on which the dependent component relies may take the form of a matrix or table. The interfaces that are relied upon by the dependent component are identified in the reliance information as examined during . There is, during this activity, no requirement to determine completeness of the coverage of interfaces that are relied upon by the dependent component, only that the correspondence is correct and ensuring that interfaces of the base component are mapped to interfaces required by the dependent component wherever possible. The completeness of the coverage is considered in activities. The evaluator shall determine that the interface description provided is consistent with the reliance information provided for the dependent component. The evaluator shall examine the development information and the reliance information to determine that the interfaces are described consistently. The evaluator's goal in this work unit is to determine that the interfaces described in the development information for the base component and the reliance information for the dependent component are represented consistently. The objective of this sub-activity is to determine that the appropriate security functionality is provided by the base component to support the dependent component. This is achieved through examination of the interfaces and associated security behaviour of the base component to determine that they are consistent with the interfaces specified in the reliance information; those required by the dependent component. In addition to the interface description, the subsystems of the base component that provide the security functionality required by the dependent component will be described to enable the evaluator to determine whether or not that interface formed part of the TSF of the base component. the composed ST; the development information; reliance information. The developer shall provide development information for the base component. The development information shall describe the purpose and method of use of each interface of the base component used in the composed TOE. The development information shall identify the subsystems of the base component that provide interfaces of the base component used in the composed TOE. The development information shall provide a high-level description of the behaviour of the base component subsystems, which support the enforcement of the dependent component SFRs. The development information shall provide a mapping from the interfaces to the subsystems of the base component. The development information shall show correspondence between the interfaces, used in the composed TOE, of the base component and the dependent component to support the TSF of the dependent component. The evaluator shall confirm that the information meets all requirements for content and presentation of evidence. The evaluator shall examine the development information to determine that it describes the purpose of each interface. The base component provides interfaces to support interaction with the dependent component in the provision of the dependent TSF. The purpose of each interface is to be described at the same level as the description of the interfaces to the dependent component TSF functionality, as would be provided between subsystems in . This description is to provide the reader with an understanding of how the base component provides the services required by the dependent component TSF. This work unit may be satisfied by the provision of the functional specification for the base component for those interfaces that are TSFIs of the base component. The evaluator shall examine the development information to determine that it describes the method of use for each interface. The method of use for an interface summarizes how the interface is manipulated in order to invoke the operations and obtain results associated with the interface. The evaluator should be able to determine from reading this material in the development information how to use each interface. This does not necessarily mean that there needs to be a separate method of use for each interface, as it may be possible to describe in general how APIs are invoked, for instance, and then identify each interface using that general style. This work unit may be satisfied by the provision of the functional specification for the base component for those interfaces that are TSFIs of the base component. The evaluator shall examine the development information to determine that all subsystems of the base component that provide interfaces to the dependent component are identified. For those interfaces that are considered to form part of the TSFI of the base component, the subsystems associated with the interface will be subsystems considered in the activity during the base component evaluation. The interfaces on which the dependent component relies that did not form part of the TSFI of the base component will map to subsystems outside of the base component TSF. The evaluator shall examine the development information to determine that it describes the behaviour of the base component subsystems that support the enforcement of the dependent component SFRs. The dependent component invokes interfaces of the base component for the provision of services by the base component. For the interfaces of the base component that are invoked, the development information shall provide a high-level description of the associated security behaviour of the base component. The description of the base component security behaviour will outline how the base component provides the necessary service when the call to the interface is made. This description is to be at a level similar to that provided for . Therefore, the provision of the TOE design evidence from the base component evaluation would satisfy this work unit, where the interfaces invoked by the dependent component are TSFI of the base component. If the interfaces invoked by the dependent component are not TSFIs of the base component it is the associated security behaviour will not necessarily be described in the base component TOE design evidence. The evaluator shall examine the development information to determine that the correspondence between the interfaces and subsystems of the base component is accurate. If the TOE design and functional specification evidence from the base component evaluation is available, this can be used to verify the accuracy of the correspondence between the interfaces and subsystems of the base component as used in the composed TOE. Those interfaces of the base component, which formed part of the base component TSFI will be described in the base component functional specification, and the associated subsystems will be described in the base component TOE design evidence. The tracing between the two will be provided in the base component TOE design evidence. If, however, the base component interface did not form part of the TSFI of the base component, the description of the subsystem behaviour provided in the development information will be used to verify the accuracy of the correspondence. The evaluator shall examine the development information to determine the correspondence, between the interfaces of the base component and the interfaces on which the dependent component relies, is accurate. The correspondence between the interfaces of the base component and the interfaces on which the dependent component relies may take the form of a matrix or table. The interfaces that are relied upon by the dependent component are identified in the reliance information as examined during . There is, during this activity, no requirement to determine completeness of the coverage of interfaces that are relied upon by the dependent component, only that the correspondence is correct and ensuring that interfaces of the base component are mapped to interfaces required by the dependent component wherever possible. The completeness of the coverage is considered in activities. The evaluator shall determine that the interface description provided is consistent with the reliance information provided for the dependent component. The evaluator shall examine the development information and the reliance information to determine that the interfaces are described consistently. The evaluator's goal in this work unit is to determine that the interfaces described in the development information for the base component and the reliance information for the dependent component are represented consistently. The purpose of this family is to provide evidence that describes the reliance that a dependent component has upon the base component. This information is useful to persons responsible for integrating the component with other evaluated IT components to form the composed TOE, and for providing insight into the security properties of the resulting composition. This provides a description of the interface between the dependent and base components of the composed TOE that may not have been analysed during evaluation of the individual components, as the interfaces were not TSFIs of the individual component TOEs. The components in this family are levelled according to the amount of detail provided in the description of the reliance by the dependent component upon the base component. The family considers the interactions between the components where the dependent component relies upon a service from the base component to support the operation of security functionality of the dependent component. The interfaces into these services of the base component may not have been considered during evaluation of the base component because the service in the base component was not considered security-relevant in the component evaluation, either because of the inherent purpose of the service (e.g. adjust type font) or because associated CC Part 2 SFRs are not being claimed in the base component's ST (e.g. the login interface when no SFRs are claimed). These interfaces into the base component are often viewed as functional interfaces in the evaluation of the base component, and are in addition to the security interfaces (TSFI) considered in the functional specification. In summary, the TSFIs described in the functional specification only include the calls made into a TSF by external entities and responses to those calls. Calls made by a TSF, which were not explicitly considered during evaluation of the components, are described by the reliance information provided to satisfy . The objectives of this sub-activity are to determine whether the developer's reliance evidence provides sufficient information to determine that the necessary functionality is available in the base component, and the means by which that functionality is invoked. These are provided in terms of a high-level description. A dependent component whose TSF interacts with the base component requires functionality provided by that base component (e.g., remote authentication, remote audit data storage). In these cases, those invoked services need to be described for those charged with configuring the composed TOE for end users. The rationale for requiring this documentation is to aid integrators of the composed TOE to determine what services in the base component can have adverse effects on the dependent component, and to provide information against which to determine the compatibility of the components when applying the family. the composed ST; the dependent component functional specification; the dependent component design; the dependent component architectural design; the reliance information. The developer shall provide reliance information of the dependent component. The reliance information shall describe the functionality of the base component hardware, firmware and/or software that is relied upon by the dependent component TSF. The reliance information shall describe all interactions through which the dependent component TSF requests services from the base component. The reliance information shall describe how the dependent TSF protects itself from interference and tampering by the base component. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check the reliance information to determine that it describes the functionality of the base dependent hardware, firmware and/or software that is relied upon by the dependent component TSF. The evaluator assesses the description of the security functionality that the dependent component TSF requires to be provided by the base component's hardware, firmware and software. The emphasis of this work unit is on the level of detail of this description, rather than on an assessment of the information's accuracy. (The assessment of the accuracy of the information is the focus of the next work unit.) This description of the base component's functionality need not be any more detailed than the level of the description of a component of the TSF, as would be provided in . The evaluator shall examine the reliance information to determine that it accurately reflects the objectives specified for the operational environment of the dependent component. The reliance information contains the description of the base component's security functionality relied upon by the dependent component. To ensure that the reliance information is consistent with the expectations of the operational environment of the dependent component, the evaluator compares the reliance information with the statement of objectives for the environment in the ST for the dependent component. For example, if the reliance information claims that the dependent component TSF relies upon the base component to store and protect audit data, yet other evaluation evidence (e.g. the dependent component design) makes it clear that the dependent component TSF itself is storing and protecting the audit data, this would indicate an inaccuracy. It should be noted that the objectives for the operational environment may include objectives that can be met by non-IT measures. While the services that the base component environment is expected to provide may be described in the description of IT objectives for the operational environment in the dependent component ST, it is not required that all such expectations on the environment be described in the reliance information. The evaluator shall examine the reliance information to determine that it describes all interactions between the dependent component and the base component, through which the dependent component TSF requests services from the base component. The dependent component TSF may request services of the base component that were not within the TSF of the base component (see CC Part 3, B.4, Interactions between composed IT entities). The interfaces to the base component's functionality are described at the same level as the description of the interfaces to the dependent component TSF functionality, as would be provided between subsystems in . The purpose of describing the interactions between the dependent component and the base component is to provide an understanding of how the dependent component TSF relies upon the base component for the provision of services to support the operation of security functionality of the dependent component. These interactions do not need to be characterised at the implementation level (e.g. parameters passed from one routine in a component to a routine in another component), but the data elements identified for a particular component that are going to be used by another component should be covered in this description. The statement should help the reader understand in general why the interaction is necessary. Accuracy and completeness of the interfaces is based on the security functionality that the TSF requires to be provided by the base component, as assessed in work units and . It should be possible to map all of the functionality described in the earlier work units to the interfaces identified in this work unit, and vice versa. An interface that does not correspond to described functionality would also indicate an inadequacy. The evaluator shall examine the reliance information to determine that it describes how the dependent TSF protects itself from interference and tampering by the base component. The description of how the dependent component protects itself from interference and tampering by the base component is to be provided at the same level of detail as necessary for . The objectives of this sub-activity are to determine whether the developer's reliance evidence provides sufficient information to determine that the necessary functionality is available in the base component, and the means by which that functionality is invoked. This is provided in terms of the interfaces between the dependent and base component and the return values from those interfaces called by the dependent component. A dependent component whose TSF interacts with the base component requires functionality provided by that base component (e.g., remote authentication, remote audit data storage). In these cases, those invoked services need to be described for those charged with configuring the composed TOE for end users. The rationale for requiring this documentation is to aid integrators of the composed TOE to determine what services in the base component can have adverse effects on the dependent component, and to provide information against which to determine the compatibility of the components when applying the Development evidence family. the composed ST; the dependent component functional specification; the dependent component design; the dependent component implementation representation; the dependent component architectural design; the reliance information. The developer shall provide reliance information of the dependent component. The reliance information shall describe the functionality of the base component hardware, firmware and/or software that is relied upon by the dependent component TSF. The reliance information shall describe all interactions through which the dependent component TSF requests services from the base component. The reliance information shall describe each interaction in terms of the interface used and the return values from those interfaces. The reliance information shall describe how the dependent TSF protects itself from interference and tampering by the base component. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check the reliance information to determine that it describes the functionality of the base dependent hardware, firmware and/or software that is relied upon by the dependent component TSF. The evaluator assesses the description of the security functionality that the dependent component TSF requires to be provided by the base component's hardware, firmware and software. The emphasis of this work unit is on the level of detail of this description, rather than on an assessment of the information's accuracy. (The assessment of the accuracy of the information is the focus of the next work unit.) This description of the base component's functionality need not be any more detailed than the level of the description of a component of the TSF, as would be provided in . The evaluator shall examine the reliance information to determine that it accurately reflects the objectives specified for the operational environment of the dependent component. The reliance information contains the description of the base component's security functionality relied upon by the dependent component. To ensure that the reliance information is consistent with the expectations of the operational environment of the dependent component, the evaluator compares the reliance information with the statement of objectives for the environment in the ST for the dependent component. For example, if the reliance information claims that the dependent component TSF relies upon the base component to store and protect audit data, yet other evaluation evidence (e.g. the dependent component design) makes it clear that the dependent component TSF itself is storing and protecting the audit data, this would indicate an inaccuracy. It should be noted that the objectives for the operational environment may include objectives that can be met by non-IT measures. While the services that the base component environment is expected to provide may be described in the description of IT objectives for the operational environment in the dependent component ST, it is not required that all such expectations on the environment be described in the reliance information. The evaluator shall examine the reliance information to determine that it describes all interactions between the dependent component and the base component, through which the dependent component TSF requests services from the base component. The dependent component TSF may request services of the base component that were not within the TSF of the base component (see CC Part 3, B.4, Interactions between composed IT entities). The interfaces to the base component's functionality are described at the same level as the description of the interfaces to the dependent component TSF functionality, as would be provided between subsystems in the . The purpose of describing the interactions between the dependent component and the base component is to provide an understanding of how the dependent component TSF relies upon the base component for the provision of services to support the operation of security functionality of the dependent component. These interactions do not need to be characterised at the implementation level (e.g. parameters passed from one routine in a component to a routine in another component), but the data elements identified for a particular component that are going to be used by another component should be covered in this description. The statement should help the reader understand in general why the interaction is necessary. Accuracy and completeness of the interfaces is based on the security functionality that the TSF requires to be provided by the base component, as assessed in work units and . It should be possible to map all of the functionality described in the earlier work units to the interfaces identified in this work unit, and vice versa. An interface that does not correspond to described functionality would also indicate an inadequacy. The reliance information shall describe each interaction in terms of the interface used and the return values from those interfaces. The identification of the interfaces used by the dependent component TSF when making services requests of the base component allows an integrator to determine whether the base component provides all the necessary corresponding interfaces. This understanding is further gained through the specification of the return values expected by the dependent component. The evaluator ensures that interfaces are described for each interaction specified (as analysed in ). The evaluator shall examine the reliance information to determine that it describes how the dependent TSF protects itself from interference and tampering by the base component. The description of how the dependent component protects itself from interference and tampering by the base component is to be provided at the same level of detail as necessary for . This family calls for an analysis of vulnerability information available in the public domain and of vulnerabilities that may be introduced as a result of the composition. The components in this family are levelled on the basis of increasing scrutiny of vulnerability information from the public domain and independent vulnerability analysis. The developer will provide details of any residual vulnerabilities reported during evaluation of the components. These may be gained from the component developers or evaluation reports for the components. These will be used as inputs into the evaluator's vulnerability analysis of the composed TOE in the operational environment. The operational environment of the composed TOE is examined to ensure that the assumptions and objectives for the component operational environment (specified in each component ST) are satisfied in the composed TOE. An initial analysis of the consistency of assumptions and objectives between the components and the composed TOE STs will have been performed during the conduct of the activities for the composed TOE. However, this analysis is revisited with the knowledge acquired during the , and the activities to ensure that, for example, assumptions of the dependent component that were addressed by the environment in the dependent component ST are not reintroduced as a result of composition (i.e. that the base component adequately addresses the assumptions of the dependent component ST in the composed TOE). A search by the evaluator for issues in each component will identify potential vulnerabilities reported in the public domain since completion of the evaluation of the components. Any potential vulnerabilities will then be subject to testing. If the base component used in the composed TOE has been the subject of assurance continuity activities since certification, the evaluator will consider during the composed TOE vulnerability analysis activities the changes made in base component. The objective of this sub-activity is to determine whether the composed TOE, in its operational environment, has easily exploitable vulnerabilities. The developer provides details of any residual vulnerabilities reported from evaluation of the components. The evaluator performs an analysis of the disposition the residual vulnerabilities reported and also performs a search of the public domain, to identify any new potential vulnerabilities in the components (i.e. those issues that have been reported in the public domain since evaluation of the base component). The evaluator then performs penetration testing to demonstrate that the potential vulnerabilities cannot be exploited in the TOE, in its operational environment, by an attacker with basic attack potential. See the application notes for Evaluation of sub-activity . the composed TOE suitable for testing; the composed ST; the composition rationale; the guidance documentation; information publicly available to support the identification of possible security vulnerabilities; residual vulnerabilities reported during evaluation of each component. The developer shall provide the composed TOE for testing. The composed TOE shall be suitable for testing. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the composed TOE to determine that it has been installed properly and is in a known state. To determine that the composed TOE has been installed properly and is in a known state the and work units will be applied to the composed TOE. If the assurance package includes a component from the family, then the evaluator may refer to the result of the work unit *-1 to demonstrate this has been satisfied. The evaluator shall examine the composed TOE configuration to determine that any assumptions and objectives in the STs the components relating to IT entities for are fulfilled by the other components. The STs for the component may include assumptions about other components that may use the component to which the ST relates, e.g. the ST for an operating system used as a base component may include an assumption that any applications loaded on the operating system do not run in privileged mode. These assumptions and objectives are to be fulfilled by other components in the composed TOE. The evaluator shall perform an analysis to determine that any residual vulnerabilities identified for the base and dependent components are not exploitable in the composed TOE in its operational environment. The evaluator shall examine the residual vulnerabilities from the base component evaluation to determine that they are not exploitable in the composed TOE in its operational environment. The list of vulnerabilities identified in the product during the evaluation of the base component, which were demonstrated to be non-exploitable in the base component, is to be used as an input into this activity. The evaluator will determine that the premise(s) on which a vulnerability was deemed to be non-exploitable is upheld in the composed TOE, or whether the combination has re-introduced the potential vulnerability. For example, if during evaluation of the base component it was assumed that a particular operating system service was disabled, which is enabled in the composed TOE evaluation, any potential vulnerabilities relating to that service previously scoped out should now be considered. Also, this list of known, non-exploitable vulnerabilities resulting from the evaluation of the base component should be considered in the light of any known, non-exploitable vulnerabilities for the other components (e.g. dependent component) within the composed TOE. This is to consider the case where a potential vulnerability that is non-exploitable in isolation is exploitable when integrated with an IT entity containing another potential vulnerability. The evaluator shall examine the residual vulnerabilities from the dependent component evaluation to determine that they are not exploitable in the composed TOE in its operational environment. The list of vulnerabilities identified in the product during the evaluation of the dependent component, which were demonstrated to be non-exploitable in the dependent component, is to be used as an input into this activity. The evaluator will determine that the premise(s) on which a vulnerability was deemed to be non-exploitable is upheld in the composed TOE, or whether the combination has re-introduced the potential vulnerability. For example, if during evaluation of the dependent component it was assumed that IT meeting the operational environment requirements would not return a certain value in response to a service request, which is provided by the base component in the composed TOE evaluation, any potential vulnerabilities relating to that return value previously scoped out should now be considered. Also, this list of known, non-exploitable vulnerabilities resulting from the evaluation of the dependent component should be considered in the light of any known, non-exploitable vulnerabilities for the other components (e.g. base component) within the composed TOE. This is to consider the case where a potential vulnerability that is non-exploitable in isolation is exploitable when integrated with an IT entity containing another potential vulnerability. The evaluator shall perform a search of public domain sources to identify possible vulnerabilities arising from use of the base and dependent components in the composed TOE operational environment. The evaluator shall examine the sources of information publicly available to support the identification of possible security vulnerabilities in the base component that have become known since the completion of evaluation of the base component. The evaluator will use the information in the public domain as described in to search for vulnerabilities in the base component. Those potential vulnerabilities that were publicly available prior to the evaluation of the base component do not have to be further investigated unless it is apparent to the evaluator that the attack potential required by an attacker to exploit the potential vulnerability has been significantly reduced. This may be through the introduction of some new technology since the base component evaluation that means the exploitation of the potential vulnerability has been simplified. The evaluator shall examine the sources of information publicly available to support the identification of possible security vulnerabilities in the dependent component that have become known since the completion of the dependent component evaluation. The evaluator will use the information in the public domain as described in to search for vulnerabilities in the dependent component. Those potential vulnerabilities that were publicly available prior to the evaluation of the dependent component do not have to be further investigated unless it is apparent to the evaluator that the attack potential required by an attacker to exploit the potential vulnerability has been significantly reduced. This may be through the introduction of some new technology since evaluation of the dependent component that means the exploitation of the potential vulnerability has been simplified. The evaluator shall record in the ETR the identified potential security vulnerabilities that are candidates for testing and applicable to the composed TOE in its operational environment. The ST, guidance documentation and functional specification are used to determine whether the vulnerabilities are relevant to the composed TOE in its operational environment. The evaluator records any reasons for exclusion of vulnerabilities from further consideration if the evaluator determines that the vulnerability is not applicable in the operational environment. Otherwise the evaluator records the potential vulnerability for further consideration. A list of potential vulnerabilities applicable to the composed TOE in its operational environment, which can be used as an input into penetration testing activities (i.e. ), shall be reported in the ETR by the evaluators. The evaluator shall conduct penetration testing, based on the identified vulnerabilities, to demonstrate that the composed TOE is resistant to attacks by an attacker with basic attack potential. The evaluator shall conduct penetration testing as detailed for . The evaluator will apply all work units necessary for the satisfaction of evaluator action , reporting in the ETR for the composed TOE all analysis and verdicts as dictated by the work units. The evaluator will also apply the work units for the evaluator action to determine that the composed TOE provided by the developer is suitable for testing. The objective of this sub-activity is to determine whether the composed TOE, in its operational environment, has vulnerabilities exploitable by attackers possessing basic attack potential. The developer provides an analysis of the disposition of any residual vulnerabilities reported for the components and of any vulnerabilities introduced through the combination of the base and dependent components. The evaluator performs a search of the public domain to identify any new potential vulnerabilities in the components (i.e. those issues that have been reported in the public domain since the completion of the evaluation of the components). The evaluator will also perform an independent vulnerability analysis of the composed TOE and penetration testing. See the application notes for Evaluation of sub-activity . the composed TOE suitable for testing; the composed ST; the composition rationale; the reliance information; the guidance documentation; information publicly available to support the identification of possible security vulnerabilities; residual vulnerabilities reported during evaluation of each component. The developer shall provide the composed TOE for testing. The composed TOE shall be suitable for testing. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the composed TOE to determine that it has been installed properly and is in a known state. To determine that the composed TOE has been installed properly and is in a known state the and work units will be applied to the composed TOE. If the assurance package includes family, then the evaluator may refer to the result of the work unit *-1 to demonstrate this has been satisfied. The evaluator shall examine the composed TOE configuration to determine that any assumptions and objectives in the STs the components relating to IT entities for are fulfilled by the other components. The STs for the component may include assumptions about other components that may use the component to which the ST relates, e.g. the ST for an operating system used as a base component may include an assumption that any applications loaded on the operating system do not run in privileged mode. These assumptions and objectives are to be fulfilled by other components in the composed TOE. The evaluator shall perform an analysis to determine that any residual vulnerabilities identified for the base and dependent components are not exploitable in the composed TOE in its operational environment. The evaluator shall examine the residual vulnerabilities from the base component evaluation to determine that they are not exploitable in the composed TOE in its operational environment. The list of vulnerabilities identified in the product during the evaluation of the base component, which were demonstrated to be non-exploitable in the base component, is to be used as an input into this activity. The evaluator will determine that the premise(s) on which a vulnerability was deemed to be non-exploitable is upheld in the composed TOE, or whether the combination has re-introduced the potential vulnerability. For example, if during evaluation of the base component it was assumed that a particular operating system service was disabled, which is enabled in the composed TOE evaluation, any potential vulnerabilities relating to that service previously scoped out should now be considered. Also, this list of known, non-exploitable vulnerabilities resulting from the evaluation of the base component should be considered in the light of any known, non-exploitable vulnerabilities for the other components (e.g. dependent component) within the composed TOE. This is to consider the case where a potential vulnerability that is non-exploitable in isolation is exploitable when integrated with an IT entity containing another potential vulnerability. The evaluator shall examine the residual vulnerabilities from the dependent component evaluation to determine that they are not exploitable in the composed TOE in its operational environment. The list of vulnerabilities identified in the product during the evaluation of the dependent component, which were demonstrated to be non-exploitable in the dependent component, is to be used as an input into this activity. The evaluator will determine that the premise(s) on which a vulnerability was deemed to be non-exploitable is upheld in the composed TOE, or whether the combination has re-introduced the potential vulnerability. For example, if during evaluation of the dependent component it was assumed that IT meeting the operational environment requirements would not return a certain value in response to a service request, which is provided by the base component in the composed TOE evaluation, any potential vulnerabilities relating to that return value previously scoped out should now be considered. Also, this list of known, non-exploitable vulnerabilities resulting from the evaluation of the dependent component should be considered in the light of any known, non-exploitable vulnerabilities for the other components (e.g. base component) within the composed TOE. This is to consider the case where a potential vulnerability that is non-exploitable in isolation is exploitable when integrated with an IT entity containing another potential vulnerability. The evaluator shall perform a search of public domain sources to identify possible vulnerabilities arising from use of the base and dependent components in the composed TOE operational environment. The evaluator shall examine the sources of information publicly available to support the identification of possible security vulnerabilities in the base component that have become known since the completion of the base component evaluation. The evaluator will use the information in the public domain as described in to search for vulnerabilities in the base component. Those potential vulnerabilities that were publicly available prior to the evaluation of the base component do not have to be further investigated unless it is apparent to the evaluator that the attack potential required by an attacker to exploit the potential vulnerability has been significantly reduced. This may be through the introduction of some new technology since the base component evaluation that means the exploitation of the potential vulnerability has been simplified. The evaluator shall examine the sources of information publicly available to support the identification of possible security vulnerabilities in the dependent component that have become known since the completion of the dependent component evaluation. The evaluator will use the information in the public domain as described in to search for vulnerabilities in the dependent component. Those potential vulnerabilities that were publicly available prior to the evaluation of the dependent component do not have to be further investigated unless it is apparent to the evaluator that the attack potential required by an attacker to exploit the potential vulnerability has been significantly reduced. This may be through the introduction of some new technology since evaluation of the dependent component that means the exploitation of the potential vulnerability has been simplified. The evaluator shall record in the ETR the identified potential security vulnerabilities that are candidates for testing and applicable to the composed TOE in its operational environment. The ST, guidance documentation and functional specification are used to determine whether the vulnerabilities are relevant to the composed TOE in its operational environment. The evaluator records any reasons for exclusion of vulnerabilities from further consideration if the evaluator determines that the vulnerability is not applicable in the operational environment. Otherwise, the evaluator records the potential vulnerability for further consideration. A list of potential vulnerabilities applicable to the composed TOE in its operational environment, which can be used as an input into penetration testing activities , shall be reported in the ETR by the evaluators. The evaluator shall perform an independent vulnerability analysis of the composed TOE, using the guidance documentation, reliance information and composition rationale to identify potential vulnerabilities in the composed TOE. The evaluator shall conduct a search of the composed TOE ST, guidance documentation, reliance information and composition rationale to identify possible security vulnerabilities in the composed TOE. The consideration of the components of the composed TOE in the independent evaluator vulnerability analysis will take a slightly different form to that documented in for a component evaluation, as it will not necessarily consider all layers of design abstraction relevant to the assurance package. These will have already been considered during the evaluation of the components, but the evidence may not be available for the composed TOE evaluation. However, the general approach described in the work units associated with is applicable and should form the basis of the evaluator's search for potential vulnerabilities in the composed TOE. A vulnerability analysis of the individual components used in the composed TOE will have already been performed during evaluation of the individual components. The focus of the vulnerability analysis during the composed TOE evaluation is to identify any vulnerabilities introduced as a result of the integration of the components or due to any changes in the use of the components between the evaluated component configuration to the composed TOE configuration. The evaluator will use the understanding of the component's construction as detailed in the reliance information for the dependent component, and the development information and composition rationale for the base component, together with the dependent component design information. This information will allow the evaluator to gain an understanding of how the base component and dependent component interact and identify potential vulnerabilities that may be introduced as a result of this interaction. The evaluator will consider any new guidance provided for the installation, start-up and operation of the composed TOE to identify any potential vulnerabilities introduced through this revised guidance. If any of the individual components have been through assurance continuity activities since the completion of the component evaluation, the evaluator will consider the patch(es) in the independent vulnerability analysis. Information related to the change provided in a public report of the assurance continuity activities (e.g. Maintenance Report) will be the main source of input material of the change. This will be supplemented by any updates to the guidance documentation resulting from the change and any information regarding the change available in the public domain, e.g. vendor website. Any risks identified due to the lack of evidence to establish the full impact of any patches or deviations in the configuration of a component from the evaluated configuration are to be documented in the evaluator's vulnerability analysis. The evaluator shall conduct penetration testing, based on the identified vulnerabilities, to demonstrate that the composed TOE is resistant to attacks by an attacker with basic attack potential. The evaluator shall conduct penetration testing as detailed for . The evaluator will apply all work units necessary for the satisfaction of evaluator action , reporting in the ETR for the composed TOE all analysis and verdicts as dictated by the work units. The evaluator will also apply the work units for the evaluator action to determine that the composed TOE provided by the developer is suitable for testing. The objective of this sub-activity is to determine whether the composed TOE, in its operational environment, has vulnerabilities exploitable by attackers possessing Enhanced-Basic attack potential. The developer provides an analysis of the disposition of any residual vulnerabilities reported for the components and of any vulnerabilities introduced through the combination of the base and dependent components. The evaluator performs a search of the public domain to identify any new potential vulnerabilities in the components (i.e. those issues that have been reported in the public domain since the completion of the component evaluations). The evaluator will also perform an independent vulnerability analysis of the composed TOE and penetration testing. See the application notes for Evaluation of sub-activity . the composed TOE suitable for testing; the composed ST; the composition rationale; the reliance information; the guidance documentation; information publicly available to support the identification of possible security vulnerabilities; residual vulnerabilities reported during evaluation of each component. The developer shall provide the composed TOE for testing. The composed TOE shall be suitable for testing. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the composed TOE to determine that it has been installed properly and is in a known state. To determine that the composed TOE has been installed properly and is in a known state the and work units will be applied to the composed TOE. If the assurance package includes family, then the evaluator may refer to the result of the work unit *-1 to demonstrate this has been satisfied. The evaluator shall examine the composed TOE configuration to determine that any assumptions and objectives in the STs the components relating to IT entities for are fulfilled by the other components. The STs for the component may include assumptions about other components that may use the component to which the ST relates, e.g. the ST for an operating system used as a base component may include an assumption that any applications loaded on the operating system do not run in privileged mode. These assumptions and objectives are to be fulfilled by other components in the composed TOE. The evaluator shall perform an analysis to determine that any residual vulnerabilities identified for the base and dependent components are not exploitable in the composed TOE in its operational environment. The evaluator shall examine the residual vulnerabilities from the base component evaluation to determine that they are not exploitable in the composed TOE in its operational environment. The list of vulnerabilities identified in the product during the evaluation of the base component, which were demonstrated to be non-exploitable in the base component, is to be used as an input into this activity. The evaluator will determine that the premise(s) on which a vulnerability was deemed to be non-exploitable is upheld in the composed TOE, or whether the combination has re-introduced the potential vulnerability. For example, if during evaluation of the base component it was assumed that a particular operating system service was disabled, which is enabled in the composed TOE evaluation, any potential vulnerabilities relating to that service previously scoped out should now be considered. Also, this list of known, non-exploitable vulnerabilities resulting from the evaluation of the base component should be considered in the light of any known, non-exploitable vulnerabilities for the other components (e.g. dependent component) within the composed TOE. This is to consider the case where a potential vulnerability that is non-exploitable in isolation is exploitable when integrated with an IT entity containing another potential vulnerability. The evaluator shall examine the residual vulnerabilities from the dependent component evaluation to determine that they are not exploitable in the composed TOE in its operational environment. The list of vulnerabilities identified in the product during the evaluation of the dependent component, which were demonstrated to be non-exploitable in the dependent component, is to be used as an input into this activity. The evaluator will determine that the premise(s) on which a vulnerability was deemed to be non-exploitable is upheld in the composed TOE, or whether the combination has re-introduced the potential vulnerability. For example, if during evaluation of the dependent component it was assumed that IT meeting the operational environment requirements would not return a certain value in response to a service request, which is provided by the base component in the composed TOE evaluation, any potential vulnerabilities relating to that return value previously scoped out should now be considered. Also, this list of known, non-exploitable vulnerabilities resulting from the evaluation of the dependent component should be considered in the light of any known, non-exploitable vulnerabilities for the other components (e.g. base component) within the composed TOE. This is to consider the case where a potential vulnerability that is non-exploitable in isolation is exploitable when integrated with an IT entity containing another potential vulnerability. The evaluator shall perform a search of public domain sources to identify possible vulnerabilities arising from use of the base and dependent components in the composed TOE operational environment. The evaluator shall examine the sources of information publicly available to support the identification of possible security vulnerabilities in the base component that have become known since the completion of the base component evaluation. The evaluator will use the information in the public domain as described in to search for vulnerabilities in the base component. Those potential vulnerabilities that were publicly available prior to the evaluation of the base component do not have to be further investigated unless it is apparent to the evaluator that the attack potential required by an attacker to exploit the potential vulnerability has been significantly reduced. This may be through the introduction of some new technology since the base component evaluation that means the exploitation of the potential vulnerability has been simplified. The evaluator shall examine the sources of information publicly available to support the identification of possible security vulnerabilities in the dependent component that have become known since completion of the dependent component evaluation. The evaluator will use the information in the public domain as described in to search for vulnerabilities in the dependent component. Those potential vulnerabilities that were publicly available prior to the evaluation of the dependent component do not have to be further investigated unless it is apparent to the evaluator that the attack potential required by an attacker to exploit the potential vulnerability has been significantly reduced. This may be through the introduction of some new technology since evaluation of the dependent component that means the exploitation of the potential vulnerability has been simplified. The evaluator shall record in the ETR the identified potential security vulnerabilities that are candidates for testing and applicable to the composed TOE in its operational environment. The ST, guidance documentation and functional specification are used to determine whether the vulnerabilities are relevant to the composed TOE in its operational environment. The evaluator records any reasons for exclusion of vulnerabilities from further consideration if the evaluator determines that the vulnerability is not applicable in the operational environment. Otherwise, the evaluator records the potential vulnerability for further consideration. A list of potential vulnerabilities applicable to the composed TOE in its operational environment, which can be used as an input into penetration testing activities , shall be reported in the ETR by the evaluators. The evaluator shall perform an independent vulnerability analysis of the composed TOE, using the guidance documentation, reliance information and composition rationale to identify potential vulnerabilities in the composed TOE. The evaluator shall conduct a search of the composed TOE ST, guidance documentation, reliance information and composition rationale to identify possible security vulnerabilities in the composed TOE. The consideration of the components in the independent evaluator vulnerability analysis will take a slightly different form to that documented in for a component evaluation, as it will not necessarily consider all layers of design abstraction relevant to the assurance package. These will have already been considered during the evaluation of the base component, but the evidence may not be available for the composed TOE evaluation. However, the general approach described in the work units associated with is applicable and should form the basis of the evaluator's search for potential vulnerabilities in the composed TOE. A vulnerability analysis of the individual components used in the composed TOE will have already been performed during evaluation of the components. The focus of the vulnerability analysis during the composed TOE evaluation is to identify any vulnerabilities introduced as a result of the integration of the components or due to any changes in the use of the components between the configuration of the component determined during the component evaluation and the composed TOE configuration. The evaluator will use the understanding of the component's construction as detailed in the reliance information for the dependent component, and the composition rationale and development information for the base component, together with the dependent component design information. This information will allow the evaluator to gain an understanding of how the base component and dependent component interact. The evaluator will consider any new guidance provided for the installation, start-up and operation of the composed TOE to identify any potential vulnerabilities introduced through this revised guidance. If any of the individual components have been through assurance continuity activities since the completion of the component evaluation, the evaluator will consider the patch in the independent vulnerability analysis. Information related to the change provided in a public report of the assurance continuity activities (e.g. Maintenance Report). This will be supplemented by any updates to the guidance documentation resulting from the change and any information regarding the change available in the public domain, e.g. vendor website. Any risks identified due to the lack of evidence to establish the full impact of any patches or deviations in the configuration of a component from the evaluated configuration are to be documented in the evaluator's vulnerability analysis. The evaluator shall conduct penetration testing, based on the identified vulnerabilities, to demonstrate that the composed TOE is resistant to attacks by an attacker with Enhanced-Basic attack potential. The evaluator shall conduct penetration testing as detailed for . The evaluator will apply all work units necessary for the satisfaction of evaluator action , reporting in the ETR for the composed TOE all analysis and verdicts as dictated by the work units. The evaluator will also apply the work units for the evaluator action to determine that the composed TOE provided by the developer is suitable for testing. The requirements of the Development class provide information about the TOE. The knowledge obtained by this information is used as the basis for conducting vulnerability analysis and testing upon the TOE, as described in the and classes. The Development class encompasses seven families of requirements for structuring and representing the TSF at various levels and varying forms of abstraction. These families include: requirements for the description (at the various levels of abstraction) of the design and implementation of the SFRs (, , and ). requirements for the description of the architecture-oriented features of domain separation, TSF self-protection and non-bypassability of the security functionality (). requirements for a security policy model and for correspondence mappings between security policy model and the functional specification (). requirements on the internal structure of the TSF, which covers aspects such as modularity, layering, and minimization of complexity (). When documenting the security functionality of a TOE, there are two properties that need to be demonstrated. The first property is that the security functionality works correctly, i.e. it performs as specified. The second property, and one that is arguably harder to demonstrate, is that the TOE cannot be used in a way such that the security functionality can be corrupted or bypassed. These two properties require somewhat different approaches in analysis, and so the families in are structured to support these different approaches. The families , , , and deal with the first property: the specification of the security functionality. The families and deal with the second property: the specification of the design of the TOE demonstrating the security functionality cannot be corrupted or bypassed. It should be noted that both properties need to be realized: the more confidence one has that the properties are satisfied, the more trustworthy the TOE is. The TSF of a composite product are represented at various levels of abstraction in the families of the development class . The family determines whether the requirements on the dependent component, imposed by the related base componen, are fulfilled in a composite product. Due to the distribution of the TSF of a composite product to various levels in the families of the class , this family is not represented in . The components in the families are designed so that more assurance can be gained as the components hierarchically increase. The paradigm for the families targeted at the first property is one of design decomposition. At the highest level, there is a functional specification of the TSF in terms of its interfaces (describing what the TSF does in terms of requests to the TSF for services and resulting responses), decomposing the TSF into smaller units (dependent on the assurance desired and the complexity of the TOE) and describing how the TSF accomplishes its functions (to a level of detail commensurate with the assurance level), and showing the implementation of the TSF. A formal model of the security behaviour also may be given. All levels of decomposition are used in determining the completeness and accuracy of all other levels, ensuring that the levels are mutually supportive. The requirements for the various TSF representations are separated into different families, to allow the PP/ST author to specify which TSF representations are required. The level chosen will dictate the assurance desired/gained. indicates the relationships among the various TSF representations of the class, as well as their relationships with other classes. As the figure indicates, the and classes define the requirements for the correspondence between the SFRs and the security objectives for the TOE. Class also defines requirements for the correspondence between both the security objectives and SFRs, and for the TOE summary specification which explains how the TOE meets its SFRs. The activities of include the verification that the TSF that is tested under the and classes is in fact the one described by all of the decomposition levels. The requirements for all other correspondence shown in are defined in the class for the TOE. The family defines the requirements for formally modelling selected SFRs and providing correspondence between the functional specification and the formal model. Each assurance family specific to a TSF representation (i.e. , and ) defines requirements relating that TSF representation to the SFRs. All decompositions must accurately reflect all other decompositions (i.e. be mutually supportive); the developer supplies the tracings in the last .C elements of the components. Assurance relating to this factor is obtained during the analysis for each of the levels of decomposition by referring to other levels of decomposition (in a recursive fashion) while the analysis of a particular level of decomposition is being performed; the evaluator verifies the correspondence as part of the second E element. The understanding gained from these levels of decomposition form the basis of the functional and penetration testing efforts. The family is not represented in this figure, as it is related to the internal structure of the TSF, and is only indirectly related to the process of refinement of the TSF representations. Similarly, the family is not represented in the figure because it relates to the architectural soundness, rather than representation, of the TSF. Both and relate to the analysis of the property that the TOE cannot be made to circumvent or corrupt its security functionality. The TOE security functionality (TSF) consists of all parts of the TOE that shall be relied upon for enforcement of the SFRs. The TSF includes both functionality that directly enforces the SFRs, as well as functionality that, while not directly enforcing the SFRs, contributes to their enforcement in a more indirect manner, including functionality with the capability to cause the SFRs to be violated. This includes portions of the TOE that are invoked on start-up that are responsible for putting the TSF into its initial secure state. Several important concepts were used in the development of the components of the families. These concepts, while introduced briefly here, are explained more fully in the application notes for the families. One over-riding notion is that, as more information becomes available, greater assurance can be obtained that the security functionality is correctly implemented; cannot be corrupted; and cannot be bypassed. This is done through the verification that the documentation is correct and consistent with other documentation, and by providing information that can be used to ensure that the testing activities (both functional and penetration testing) are comprehensive. This is reflected in the levelling of the components of the families. In general, components are levelled based on the amount of information that is to be provided (and subsequently analysed). While not true for all TOEs, it is generally the case that the TSF is sufficiently complex that there are portions of the TSF that deserve more intense examination than other portions of the TSF. Determining those portions is unfortunately somewhat subjective, thus terminology and components have been defined such that as the level of assurance increases, the responsibility for determining what portions of the TSF need to be examined in detail shifts from the developer to the evaluator. To aid in expressing this concept, the following terminology is introduced. It should be noted that in the families of the class, this terminology is used when expressing SFR-related portions of the TOE (i.e. elements and work units embodied in the , , and families). While the general concept (that some portions of the TOE are more interesting than others) applies to other families, the criteria are expressed differently in order to obtain the assurance required. All portions of the TSF are security relevant, meaning that they must preserve the security of the TOE as expressed by the SFRs and requirements for domain separation and non-bypassability. One aspect of security relevance is the degree to which a portion of the TSF enforces a security requirement. Since different portions of the TOE play different roles (or no apparent role at all) in enforcing security requirements, this creates a continuum of SFR relevance: at one end of this continuum are portions of the TOE that are termed SFR-enforcing. Such portions play a direct role in implementing any SFR on the TOE. Such SFRs refer to any functionality provided by one of the SFRs contained in the ST. It should be noted that the definition of plays a role in for SFR-enforcing functionality is impossible to express quantitatively. For example, in the implementation of a Discretionary Access Control (DAC) mechanism, a very narrow view of SFR-enforcing can be the several lines of code that actually perform the check of a subject's attributes against the object's attributes. A broader view would include the software entity (e.g. C function) that contained the several lines of code. A broader view still would include callers of the C function, since they would be responsible for enforcing the decision returned by the attribute check. A still broader view would include any code in the call tree (or programming equivalent for the implementation language used) for that C function (e.g. a sort function that sorted access control list entries in a first-match algorithm implementation). At some point, the component is not so much enforcing the security policy but rather plays a supporting role; such components are termed SFR supporting. One of the characteristics of SFR-supporting functionality is that it is trusted to preserve the correctness of the SFR implementation by operating without error. Such functionality may be depended on by SFR-enforcing functionality, but the dependence is generally at a functional level; for example, memory management, buffer management, etc. Further down on the security relevance continuum is functionality termed SFR non-interfering. Such functionality has no role in implementing the SFRs and is likely part of the TSF because of its environment; for example, any code running in a privileged hardware mode on an operating system. It needs to be considered part of the TSF because, if compromised (or replaced by malicious code), it can compromise the correct operation of an SFR by virtue of its operating in the privileged hardware mode. An example of SFR non-interfering functionality can be a set of mathematical floating point operations implemented in kernel mode for speed considerations. The family provides for requirements and analysis of the TOE based on properties of domain separation, self-protection, and non-bypassability. These properties relate to the SFRs in that, if these properties are not present, it will likely lead to the failure of mechanisms implementing SFRs. Functionality and design relating to these properties is not considered a part of the continuum described above, but instead is treated separately due to its fundamentally different nature and analysis requirements. The difference in analysis of the implementation of SFRs (SFR-enforcing and SFR-supporting functionality) and the implementation of somewhat fundamental security properties of the TOE, which include the initialisation, self-protection, and non-bypassability concerns, is that the SFR-related functionality is more or less directly visible and relatively easy to test, while the above-mentioned properties require varying degrees of analysis on a much broader set of functionality. Further, the depth of analysis for such properties will vary depending on the design of the TOE. The families are constructed to address this by a separate family () devoted to analysis of the initialisation, self-protection, and non-bypassability requirements, while the other families are concerned with analysis of the functionality supporting SFRs. Even in cases where different descriptions are necessary for the multiple levels of abstraction, it is not absolutely necessary for each and every TSF representation to be in a separate document. Indeed, it may be the case that a single document meets the documentation requirements for more than one TSF representation, since it is the information about each of these TSF representations that is required, rather than the resulting document structure. In cases where multiple TSF representations are combined within a single document, the developer should indicate which portions of the documents meet which requirements. Three types of specification style are mandated by this class: informal, semiformal and formal. The functional specification and TOE design documentation are always written in either informal or semiformal style. A semiformal style reduces the ambiguity in these documents over an informal presentation. A formal specification may also be required in addition to the semi-formal presentation; the value is that a description of the TSF in more than one way will add increased assurance that the TSF has been completely and accurately specified. An informal specification is written as prose in natural language. Natural language is used here as meaning communication in any commonly spoken tongue (e.g. Spanish, German, French, English, Dutch). An informal specification is not subject to any notational or special restrictions other than those required as ordinary conventions for that language (e.g. grammar and syntax). While no notational restrictions apply, the informal specification is also required to provide defined meanings for terms that are used in a context other than that accepted by normal usage. The difference between semiformal and informal documents is only a matter of formatting or presentation: a semiformal notation includes, e.g. an explicit glossary of terms, a standardised presentation format. A semiformal specification is written to a standard presentation template. The presentation should use terms consistently if written in a natural language. The presentation may also use more structured languages/diagrams (e.g. data-flow diagrams, state transition diagrams, entity-relationship diagrams, data structure diagrams, and process or program structure diagrams). Whether based on diagrams or natural language, a set of conventions must be used in the presentation. The glossary explicitly identifies the words that are being used in a precise and constant manner; similarly, the standardised format implies that extreme care has been taken in methodically preparing the document in a manner that maximises clarity. It should be noted that fundamentally different portions of the TSF may have different semiformal notation conventions and presentation styles (as long as the number of different "semiformal notations" is small); this still conforms to the concept of a semiformal presentation. A formal specification is written in a notation based upon well-established mathematical concepts and is typically accompanied by supporting explanatory (informal) prose. These mathematical concepts are used to define the syntax and semantics of the notation and the proof rules that support logical reasoning. The syntactic and semantic rules supporting a formal notation should define how to recognize constructs unambiguously and determine their meaning. There needs to be evidence that it is impossible to derive contradictions, and all rules supporting the notation need to be defined or referenced. The purpose of the development activity is to assess the design documentation in terms of its adequacy to understand how the TSF meets the SFRs and how the implementation of these SFRs cannot be tampered with or bypassed. This understanding is achieved through examination of increasingly refined descriptions of the TSF design documentation. Design documentation consists of a functional specification (which describes the interfaces of the TSF), a TOE design description (which describes the architecture of the TSF in terms of how it works in order to perform the functions related to the SFRs being claimed), and an implementation description (a source code level description). In addition, there is a security architecture description (which describes the architectural properties of the TSF to explain how its security enforcement cannot be compromised or bypassed), an internal description (which describes how the TSF was constructed in a manner that encourages understandability), and a security policy model (which formally describes the security policies enforced by the TSF). CC requirements for design documentation are levelled by the amount, and detail of information provided, and the degree of formality of the presentation of the information. At lower levels, the most security-critical portions of the TSF are described with the most detail, while less security-critical portions of the TSF are merely summarized; added assurance is gained by increasing the amount of information about the most security-critical portions of the TSF, and increasing the details about the less security-critical portions. The most assurance is achieved when thorough details and information of all portions are provided. CC considers a document's degree of formality (that is, whether it is informal or semiformal) to be hierarchical. An informal document is one that is expressed in a natural language. The methodology does not dictate the specific language that must be used; that issue is left for the scheme. The following paragraphs differentiate the contents of the different informal documents. A functional specification provides a description of the purpose and method-of-use of interfaces to the TSF. For example, if an operating system presents the user with a means of self-identification, of creating files, of modifying or deleting files, of setting permissions defining what other users may access files, and of communicating with remote machines, its functional specification would contain descriptions of each of these and how they are realised through interactions with the externally-visible interfaces to the TSF. If there is also audit functionality that detects and record the occurrences of such events, descriptions of this audit functionality would also be expected to be part of the functional specification; while this functionality is technically not directly invoked by the user at the external interface, it certainly is affected by what occurs at the user's external interface. A design description is expressed in terms of logical divisions (subsystems or modules) that each provide a comprehensible service or function. For example, a firewall can be composed of subsystems that deal with packet filtering, with remote administration, with auditing, and with connection-level filtering. The design description of the firewall would describe the actions that are taken, in terms of what actions each subsystem takes when an incoming packet arrives at the firewall. The composite-specific work units defined in are intended to be integrated as refinements to the evaluation activities of the class listed in the following table. The other activities of the class do not require composite-specific work units. Assurance family Evaluation activity Evaluation work unit Composite-specific work unit If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable. The objective of this family is for the developer to provide a description of the security architecture of the TSF. This will allow analysis of the information that, when coupled with the other evidence presented for the TSF, will confirm the TSF achieves the desired properties. The security architecture descriptions support the implicit claim that security analysis of the TOE can be achieved by examining the TSF; without a sound architecture, the entire TOE functionality would have to be examined. This family contains only one component. The properties of self-protection, domain separation, and non-bypassability are distinct from security functionality expressed by CC Part 2 SFRs because self-protection and non-bypassability largely have no directly observable interface at the TSF. Rather, they are properties of the TSF that are achieved through the design of the TOE and TSF and enforced by the correct implementation of that design. The approach used in this family is for the developer to design and provide a TSF that exhibits the above-mentioned properties, and to provide evidence (in the form of documentation) that explains these properties of the TSF. This explanation is provided at the same level of detail as the description of the SFR-enforcing elements of the TOE in the TOE design document. The evaluator has the responsibility for looking at the evidence and, coupled with other evidence delivered for the TOE and TSF, determining that the properties are achieved. Specification of security functionality implementing the SFRs in and will not necessarily describe mechanisms employed in implementing self-protection and non-bypassability (e.g. memory management mechanisms). Therefore, the material needed to provide the assurance that these requirements are being achieved is better suited to a presentation separate from the design decomposition of the TSF as embodied in and . This is not to imply that the security architecture description called for by this component cannot reference or make use of the design decomposition material; but it is likely that much of the detail present in the decomposition documentation will not be relevant to the argument being provided for the security architecture description document. The description of architectural soundness can be thought of as a developer's vulnerability analysis, in that it provides the justification for why the TSF is sound and enforces all of its SFRs. Where the soundness is achieved through specific security mechanisms, these will be tested as part of the requirements; where the soundness is achieved solely through the architecture, the behaviour will be tested as part of the requirements. This family consists of requirements for a security architecture description that describes the self-protection, domain separation, non-bypassability principles, including a description of how these principles are supported by the parts of the TOE that are used for TSF initialisation. In case of a multi-assurance evaluation the properties of self-protection, domain separation, and non-bypassability may also be described for boundaries between the sub-TSF. Additional information on the security architecture properties of self-protection, domain separation, and non-bypassability can be found in A.1, : Supplementary material on security architectures. The objective of this sub-activity is to determine whether the TSF is structured such that it cannot be tampered with or bypassed, and whether TSFs that provide security domains isolate those domains from each other. The notions of self-protection, domain separation, and non-bypassability are distinct from security functionality expressed in CC Part 2 SFRs because self-protection and non-bypassability largely have no directly observable interface at the TSF. Rather, they are properties of the TSF that are achieved through the design of the TOE, and enforced by the correct implementation of that design. Also, the evaluation of these properties is less straight-forward than the evaluation of mechanisms; it is more difficult to check for the absence of functionality than for its presence. However, the determination that these properties are being satisfied is just as critical as the determination that the mechanisms are properly implemented. The overall approach used is that the developer provides a TSF that meets the above-mentioned properties, and provides evidence (in the form of documentation) that can be analysed to show that the properties are indeed met. The evaluator has the responsibility for looking at the evidence and, coupled with other evidence delivered for the TOE, determining that the properties are achieved. The work units can be characterised as those detailing with what information has to be provided, and those dealing with the actual analysis the evaluator performs. The security architecture description describes how domains are defined and how the TSF keeps them separate. It describes what prevents untrusted processes from getting to the TSF and modifying it. It describes what ensures that all resources under the TSF's control are adequately protected and that all actions related to the SFRs are mediated by the TSF. It explains any role the environment plays in any of these (e.g. presuming it gets correctly invoked by its underlying environment, how is its security functionality invoked?). In short, it explains how the TOE is considered to be providing any kind of security service. The analyses the evaluator performs must be done in the context of all of the development evidence provided for the TOE, at the level of detail the evidence is provided. At lower assurance levels, there should not be the expectation that, for example, TSF self-protection is completely analysed, because only high-level design representations will be available. The evaluator also needs to be sure to use information gleaned from other portions of their analysis (e.g., analysis of the TOE design) in making their assessments for the properties being examined in the following work units. the ST; the functional specification; the TOE design; the security architecture description; the implementation representation (if available); the operational user guidance. The developer shall design and implement the TOE so that the security features of the TSF cannot be bypassed. The developer shall design and implement the TSF so that it is able to protect itself from tampering by untrusted active entities. The developer shall provide a security architecture description of the TSF. The security architecture description shall be at a level of detail commensurate with the description of the SFR-enforcing abstractions described in the TOE design document. The security architecture description shall describe the security domains maintained by the TSF consistently with the SFRs. The security architecture description shall describe how the TSF initialisation process is secure. The security architecture description shall demonstrate that the TSF protects itself from tampering. The security architecture description shall demonstrate that the TSF prevents bypass of the SFR-enforcing functionality. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the security architecture description to determine that the information provided in the evidence is presented at a level of detail commensurate with the descriptions of the SFR-enforcing abstractions contained in the functional specification and TOE design document. With respect to the functional specification, the evaluator should ensure that the self-protection functionality described cover those effects that are evident at the TSFI. Such a description can include protection placed upon the executable images of the TSF, and protection placed on objects (e.g., files used by the TSF). The evaluator ensures that the functionality that can be invoked through the TSFI is described. If Evaluation of sub-activity or Evaluation of sub-activity is included, the evaluator ensures the security architecture description contains information on how any subsystems that contribute to TSF domain separation work. If Evaluation of sub-activity or higher is available, the evaluator ensures that the security architecture description also contains implementation-dependent information. For example, such a description can contain information pertaining to coding conventions for parameter checking that would prevent TSF compromises (e.g. buffer overflows), and information on stack management for call and return operations. The evaluator checks the descriptions of the mechanisms to ensure that the level of detail is such that there is little ambiguity between the description in the security architecture description and the implementation representation. The evaluator action related to this work unit is assigned a fail verdict if the security architecture description mentions any module, subsystem, or interface that is not described in the functional specification or TOE design document. The evaluator shall examine the security architecture description to determine that it describes the security domains maintained by the TSF. Security domains refer to environments supplied by the TSF for use by potentially-harmful entities; for example, a typical secure operating system supplies a set of resources (address space, per-process environment variables) for use by processes with limited access rights and security properties. The evaluator determines that the developer's description of the security domains takes into account all of the SFRs claimed by the TOE. For some TOEs such domains do not exist because all of the interactions available to users are severely constrained by the TSF. A packet-filter firewall is an example of such a TOE. Users on the LAN or WAN do not interact with the TOE, so there need be no security domains; there are only data structures maintained by the TSF to keep the users' packets separated. The evaluator ensures that any claim that there are no domains is supported by the evidence and that no such domains are, in fact, available. The evaluator shall examine the security architecture description to determine that the initialisation process preserves security. The information provided in the security architecture description relating to TSF initialisation is directed at the TOE components that are involved in bringing the TSF into an initial secure state (i.e. when all parts of the TSF are operational) when power-on or a reset is applied. This discussion in the security architecture description should list the system initialisation components and the processing that occurs in transitioning from the "down" state to the initial secure state. It is often the case that the components that perform this initialisation function are not accessible after the secure state is achieved; if this is the case then the security architecture description identifies the components and explains how they are not reachable by untrusted entities after the TSF has been established. In this respect, the property that needs to be preserved is that these components either: cannot be accessed by untrusted entities after the secure state is achieved, or; if they provide interfaces to untrusted entities, these TSFI cannot be used to tamper with the TSF. The TOE components related to TSF initialisation, then, are treated themselves as part of the TSF, and analysed from that perspective. It should be noted that even though these are treated as part of the TSF, it is likely that a justification (as allowed by ) can be made that they do not have to meet the internal structuring requirements of . The evaluator shall examine the security architecture description to determine that it contains information sufficient to support a determination that the TSF is able to protect itself from tampering by untrusted active entities. "Self-protection" refers to the ability of the TSF to protect itself from manipulation from external entities that may result in changes to the TSF. For TOEs that have dependencies on other IT entities, it is often the case that the TOE uses services supplied by the other IT entities in order to perform its functions. In such cases, the TSF alone does not protect itself because it depends on the other IT entities to provide some of the protection. For the purposes of the security architecture description, the notion of self-protection applies only to the services provided by the TSF through its TSFI, and not to services provided by underlying IT entities that it uses. Self-protection is typically achieved by a variety of means, ranging from physical and logical restrictions on access to the TOE; to hardware-based means (e.g. "execution rings" and memory management functionality); to software-based means (e.g. boundary checking of inputs on a trusted server). The evaluator determines that all such mechanisms are described. The evaluator determines that the design description covers how user input is handled by the TSF in such a way that the TSF does not subject itself to being corrupted by that user input. For example, the TSF can implement the notion of privilege and protect itself by using privileged-mode routines to handle user input. The TSF can make use of processor-based separation mechanisms such as privilege levels or rings. The TSF can implement software protection constructs or coding conventions that contribute to implementing separation of software domains, perhaps by delineating user address space from system address space. And the TSF might have reliance its environment to provide some support to the protection of the TSF. All of the mechanisms contributing to the domain separation functions are described. The evaluator should use knowledge gained from other evidence (functional specification, TOE design, TSF internals description, other parts of the security architecture description, or implementation representation, as included in the assurance package for the TOE) in determining if any functionality contributing to self-protection was described that is not present in the security architecture description. Accuracy of the description of the self-protection mechanisms is the property that the description faithfully describes what is implemented. The evaluator should use other evidence (functional specification, TOE design, TSF Internals documentation, other parts of the security architecture description, implementation representation, as included in the ST for the TOE) in determining whether there are discrepancies in any descriptions of the self-protection mechanisms. If is included in the assurance package for the TOE, the evaluator will choose a sample of the implementation representation; the evaluator should also ensure that the descriptions are accurate for the sample chosen. If an evaluator cannot understand how a certain self-protection mechanism works or can work in the system architecture, it can be the case that the description is not accurate. The evaluator shall examine the security architecture description to determine that it presents an analysis that adequately describes how the SFR-enforcing mechanisms cannot be bypassed. Non-bypassability is a property that the security functionality of the TSF (as specified by the SFRs) is always invoked. For example, if access control to files is specified as a capability of the TSF via an SFR, there must be no interfaces through which files can be accessed without invoking the TSF's access control mechanism (such as an interface through which a raw disk access takes place). Describing how the TSF mechanisms cannot be bypassed generally requires a systematic argument based on the TSF and the TSFIs. The description of how the TSF works (contained in the design decomposition evidence, such as the functional specification, TOE design documentation) - along with the information in the TSS - provides the background necessary for the evaluator to understand what resources are being protected and what security functions are being provided. The functional specification provides descriptions of the TSFIs through which the resources/functions are accessed. The evaluator assesses the description provided (and other information provided by the developer, such as the functional specification) to ensure that no available interface can be used to bypass the TSF. This means that every available interface must be either unrelated to the SFRs that are claimed in the ST (and does not interact with anything that is used to satisfy SFRs) or else uses the security functionality that is described in other development evidence in the manner described. For example, a game would likely be unrelated to the SFRs, so there must be an explanation of how it cannot affect security. Access to user data, however, is likely to be related to access control SFRs, so the explanation would describe how the security functionality works when invoked through the data-access interfaces. Such a description is needed for every available interface. An example of a description follows. Suppose the TSF provides file protection. Further suppose that although the "traditional" system call TSFIs for open, read, and write invoke the file protection mechanism described in the TOE design, there exists a TSFI that allows access to a batch job facility (creating batch jobs, deleting jobs, modifying unprocessed jobs). The evaluator should be able to determine from the vendor-provided description that this TSFI invokes the same protection mechanisms as do the "traditional" interfaces. This can be done, for example, by referencing the appropriate subclauses of the TOE design that discuss how the batch job facility TSFI achieves its security objectives. Using this same example, suppose there is a TSFI whose sole purpose is to display the time of day. The evaluator should determine that the description adequately argues that this TSFI is not capable of manipulating any protected resources and should not invoke any security functionality. Another example of bypass is when the TSF is supposed to maintain confidentiality of a cryptographic key (one is allowed to use it for cryptographic operations, but is not allowed to read/write it). If an attacker has direct physical access to the device, they might be able to examine side-channels such as the power usage of the device, the exact timing of the device, or even any electromagnetic emanations of the device and, from this, infer the key. If such side-channels may be present, the demonstration should address the mechanisms that prevent these side-channels from occurring, such as random internal clocks, dual-line technology. Verification of these mechanisms would be verified by a combination of purely design-based arguments and testing. For a final example using security functionality rather than a protected resource, consider an ST that contains , which requires that the TSF provides evidence of origination for information types specified in the ST. Suppose that the "information types" included all information that is sent by the TOE via e-mail. In this case, the evaluator should examine the description to ensure that all TSFI that can be invoked to send e-mail perform the "evidence of origination generation" function are detailed. The description can point to user guidance to show all places where e-mail can originate (e.g., e-mail program, notification from scripts/batch jobs) and then how each of these places invokes the evidence generation function. The evaluator should also ensure that the description is comprehensive, in that each interface is analysed with respect to the entire set of claimed SFRs. This may require the evaluator to examine supporting information (functional specification, TOE design, other parts of the security architecture description, operational user guidance, and perhaps even the implementation representation, as provided for the TOE) to determine that the description has correctly capture all aspects of an interface. The evaluator should consider what SFRs each TSFI can affect (from the description of the TSFI and its implementation in the supporting documentation), and then examine the description to determine whether it covers those aspects. The aim of this family is to determine whether the requirements on the dependent component, imposed by the related base component, are fulfilled in the composite product. This family contains only one component. The requirements on the dependent component, imposed by the related base component, can be formulated in the relevant base component-related user guidance, ETR for composite evaluation (in form of observations and recommendations) and report of the base component evaluation authority (e.g. in form of constraints and recommendations). The developer of the dependent component shall regard each of these sources, if available, and implement the dependent component in such a way that the applicable requirements are fulfilled. The composite product evaluator shall verify that all stipulations for the dependent component that are imposed by the base component and provided in its evaluation related documentation are fulfilled by the composite product, i.e. have been taken into account by the dependent component developer. The composite product evaluation sponsor shall ensure that the following is made available for the composite product evaluator: the base component-related user guidance, the base component-related ETR for composite evaluation prepared by the base component evaluator, the report of the base component evaluation authority, a rationale for secure composite product implementation including evidence prepared by the dependent component developer. The TSF of the composite product are represented at various levels of abstraction in the families of the development class . From experience, the appropriate levels of design representation for examining, whether the requirements of the base component are fulfilled by the composite product, are , and . In case that, these design representation levels are not available (e.g. due to the assurance package chosen is EAL1), the current family is not applicable (see the next paragraph for the reason). Due to the definition of the composite product the interface between its base component and dependent component is the internal one, hence, a functional specification as representation level is not appropriate for analysing the design compliance. Security architecture as assurance family is dedicated to ensure that integrative security services like domain separation, self-protection and non-bypassability properly work. It is impossible and not the sense of the composite evaluation to have an insight into the architectural internals of the related base component (it is a matter of the base component evaluation). In the context of the , the composite product evaluator shall: determine whether the dependent component uses services of the related base document within its own composite product ST to provide domain seitemtion, self-protection, non-bypassability and protected start-up; if no, there are no further composite activities for ; if yes, then the evaluator shall determine, whether the dependent component uses these services of the base component in an appropriate/secure way (please refer to the base component user guidance). As consistency of the composite product security policy has already been considered in the context of the ST in the assurance family , there is no necessity to consider non-contradictoriness of the security policy model () of the composite product and the security policy model of its related base component. The aim of this activity is to determine whether the requirements on the dependent component, imposed by the related base component, are fulfilled in the composite product. The requirements on the dependent component, imposed by the related base component, can be formulated in the relevant base component-related user guidance, ETR for composite evaluation (e.g. in form of observations and recommendations) and amendments to the base component evaluation as contained in the corresponding report of the base component evaluation authority (e.g. in form of further constraints, stipulations and recommendations). The developer of the dependent component shall regard each of these sources, if available, and implement the dependent component in such a way that the applicable requirements are appropriately implemented and accordingly fulfilled. The composite product evaluator shall verify that all the relevant requirements for the dependent component that are imposed by the base component and provided in its evaluation related documentation have been taken into account by the dependent component developer and are fulfilled by the composite product. The composite product evaluation sponsor shall ensure that the following is made available for the composite product evaluator: the base component-related user guidance; the base component-related ETR for composite evaluation prepared by the base component evaluator; the base component's report of the base component evaluation authority; a rationale for secure composite product implementation including evidence prepared by the dependent component developer. The TSF of the composite product are represented at various levels of abstraction in the families of the development class . From experience, the appropriate levels of design representation for examining, whether the requirements of the base component are fulfilled by the composite product, are the , security architecture and the implementation . In case that these design representation levels are not available (e.g. due to the assurance package chosen is EAL1), the current family is not applicable (see the next paragraph for the reason). Due to the definition of the composite product the interface between its base component and dependent component is the internal one, hence, a functional specification as representation level is not appropriate for analysing the design compliance. Security architecture as assurance family is dedicated to ensure that integrative security services like domain separation, self-protection and non-bypassability properly work. It is impossible and not the sense of the composite evaluation to have an insight into the architectural internals of the related base component (it is a matter of the base component evaluation). What the composite product evaluator shall do in the context of is: to determine whether the dependent component uses services of the related base component within its own composite product Security Target to provide domain separation, self-protection, non-bypassability and protected start-up; in the case of no, there are no further composite activities for ; in the case of yes, then: the evaluator shall determine whether the dependent component uses these services of the base component in an appropriate/secure way (please refer to the base component user guidance and further sources for requirements). As consistency of the composite product security policy has already been considered in the context of the Security Target in the assurance family , there is no necessity to consider non-contradictoriness of the security policy model of the composite product and the security policy model of its related base component. The developer shall provide a design compliance justification. The design compliance justification shall provide a rationale for design compliance – on an appropriate representation level – of how the requirements on the dependent component that are imposed by the related base component are fulfilled in the composite product. The evaluator shall confirm that the rationale for design compliance is complete, coherent, and internally consistent. The evaluator shall examine the rationale for design compliance to determine that all applicable requirements on the dependent component that are imposed by the base component are fulfilled by the composite product. In order to perform this work unit the evaluator shall use the rationale for design compliance as well as the TSF representation on the , and levels on the one side and the input of the base component in form of the base component-related user guidance, ETR for composite evaluation, and report of the base component evaluation authority on the other side. The evaluator shall analyse which base component requirements are applicable for the current composite product, based on the identified RP_SFR-MECH and RP_SFR-SERV (refer to ). The evaluator shall compare each of the applicable requirements with the actual specification and/or implementation of the composite product and determine, for each requirement, whether it is fulfilled. As a result, the evaluator confirms or disproves the rationale for design compliance. For example, the base component guidance may require the dependent component to perform a special start-up sequence testing the current state of the base component and initialising its self-protection mechanisms. Such information can be found in the description of security architecture of the composite product. As a second example, the base component guidance may require the dependent component to perform a DFA check on the DES operation, while the dependent component is implementing BAC in an e-passport MRTD. The will explain whether the base component guidance is followed up or not, and, in case that the requirements in the base component guidance are not followed, a corresponding reasoning will be provided. The arguments of the developer explain why a non-compliancy will not introduce vulnerabilities. The appropriate representation level , and/or , on which the analysis is being performed, can be chosen and mixed flexibly depending on the concrete composite product and the requirement in question. Where it is not self-explaining, the evaluator shall justify why the representation level chosen is appropriate. The evaluator activities in the context of this work unit can be spread over different single evaluation aspects (e.g. over and ). In this case the evaluator performs the partial activity in the context of the corresponding single evaluation aspect. Then the notation for this work unit shall be -TDS, -ARC and -IMP, respectively. If the assurance package chosen does not contain the families , or (e.g. EAL1), this work unit is not applicable. The result of this work unit shall be integrated to the result of / , / , and / (or the equivalent higher components if a higher assurance level is selected). This family levies requirements upon the functional specification, which describes the TSF interfaces (TSFIs). The TSFI consists of all means by which external entities (or subjects in the TOE but outside of the TSF) supply data to the TSF, receive data from the TSF or invoke services from the TSF. It does not describe how the TSF processes those service requests, nor does it describe the communication when the TSF invokes services from its operational environment; this information is addressed by the and families, respectively. This family provides assurance directly by allowing the evaluator to understand how the TSF meets the claimed SFRs. It also provides assurance indirectly, as input to other assurance families and classes: , where the description of the TSFIs may be used to gain better understanding of how the TSF is protected against corruption (i.e. subversion of self-protection or domain separation) and/or bypass; , where the description of the TSFIs is an important input for both developer and evaluator testing; , where the description of the TSFIs is used to search for vulnerabilities. The components in this family are levelled on the degree of detail required of the description of the TSFIs, and the degree of formalism required of the description of the TSFIs. Once the TSFIs are determined (see A.2.2 for guidance and examples of determining TSFI), they are described. At lower-level components, developers focus their documentation (and evaluators focus their analysis) on the more security-relevant aspects of the TOE. Three categories of TSFIs are defined, based upon the relevance the services available through them have to the SFRs being claimed: If a service available through an interface can be traced to one of the SFRs levied on the TSF, then that interface is termed SFR-enforcing. Note that it is possible that an interface may have various services and results, some of which may be SFR-enforcing and some of which may not. Interfaces to (or services available through an interface relating to) services that SFR-enforcing functionality depend upon, but need only to function correctly in order for the security policies of the TOE to be preserved, are termed SFR-supporting. Interfaces to services on which SFR-enforcing functionality has no dependence are termed SFR non-interfering. It should be noted that in order for an interface to be SFR-supporting or SFR non-interfering it must have no SFR-enforcing services or results. In contrast, an SFR-enforcing interface may have SFR-supporting services (for example, the ability to set the system clock may be an SFR-enforcing service of an interface, but if that same interface is used to display the system date that service may be only SFR-supporting). An example of a purely SFR-supporting interface is a system call interface that is used both by users and by a portion of the TSF that is running on behalf of users. As more information about the TSFIs becomes available, the greater the assurance that can be gained that the interfaces are correctly categorised/analysed. The requirements are structured such that, at the lowest level, the information required for SFR non-interfering interfaces is the minimum necessary in order for the evaluator to make this determination in an effective manner. At higher levels, more information becomes available so that the evaluator has greater confidence in the designation. The purpose in defining these labels (SFR-enforcing, SFR-supporting, and SFR-non-interfering) and for levying different requirements upon each (at the lower assurance components) is to provide a first approximation of where to focus the analysis and the evidence upon which that analysis is performed. If the developer's documentation of the TSF interfaces describes all of the interfaces to the degree specified in the requirements for the SFR-enforcing interfaces (i.e. if the documentation exceeds the requirements), there is no need for the developer to create new evidence to match the requirements. Similarly, because the labels are merely a means of differentiating the interface types within the requirements, there is no need for the developer to update the evidence solely to label the interfaces as SFR-enforcing, SFR-supporting, and SFR-non-interfering. The primary purpose of this labelling is to allow developers with less mature development methodologies (and associated artefacts, such as detailed interface and design documentation) to provide only the necessary evidence without undue cost. The last C element of each component within this family provides a direct correspondence between the SFRs and the functional specification, i.e. an indication of which interfaces are used to invoke each of the claimed SFRs. In the cases where the ST contains such functional requirements as CC Part 2, whose functionality may not manifest itself at the TSFIs, the functional specification and/or the tracing is expected to identify these SFRs; including them in the functional specification helps to ensure that they are not lost at lower levels of decomposition, where they will be relevant. The requirements define collections of details about TSFI to be provided. For the purposes of the requirements, interfaces are specified (in varying degrees of detail) in terms of their purpose, method of use, parameters, parameter descriptions, and error messages. The purpose of an interface is a high-level description of the general goal of the interface (e.g. process GUI commands, receive network packets, provide printer output, etc.). The interface's method of use describes how the interface is supposed to be used. This description should be built around the various interactions available at that interface. For instance, if the interface were a Unix command shell, ls, mv and cp would be interactions for that interface. For each interaction the method of use describes what the interaction does, both for behaviour seen at the interface (e.g. the programmer calling the API, the Windows users changing a setting in the registry, etc.) as well as behaviour at other interfaces (e.g. generating an audit record). Parameters are explicit inputs to and outputs from an interface that control the behaviour of that interface. For example, parameters are the arguments supplied to an API; the various fields in a packet for a given network protocol; the individual key values in the Windows Registry; the signals across a set of pins on a chip; the flags that can be set for the ls, etc. The parameters are "identified" with a simple list of what they are. A parameter description tells what the parameter is in some meaningful way. For instance, an acceptable parameter description for interface foo(i) would be "parameter i is an integer that indicates the number of users currently logged in to the system". A description such as "parameter i is an integer" is not an acceptable. The description of an interface's actions describes what the interface does. This is more detailed than the purpose in that, while the "purpose" reveals why one might want to use it, the "actions" reveals everything that it does. These actions can be related to the SFRs or not. In cases where the interface's action is not related to SFRs, its description is said to be summarized, meaning the description merely makes clear that it is indeed not SFR-related. The error message description identifies the condition that generated it, what the message is, and the meaning of any error codes. An error message is generated by the TSF to signify that a problem or irregularity of some degree has been encountered. The requirements in this family refer to different kinds of error messages: a "direct" error message is a security-relevant response through a specific TSFI invocation. an "indirect" error cannot be tied to a specific TSFI invocation because it results from system-wide conditions (e.g. resource exhaustion, connectivity interruptions, etc.). Error messages that are not security-relevant are also considered "indirect". "remaining" errors are any other errors, such as those that can be referenced within the code. For example, the use of condition-checking code that checks for conditions that would not logically occur (e.g. a final "else" after a list of "case" statements), would provide for generating a catch-all error message; in an operational TOE, these error messages should never be seen. An example functional specification is provided in A.2.4. Increasing assurance through increased completeness and accuracy in the interface specification is reflected in the documentation required from the developer as detailed in the various hierarchical components of this family. At , the only documentation required is a characterization of all TSFIs and a high-level description of SFR-enforcing and SFR-supporting TSFIs. To provide some assurance that the "important" aspects of the TSF have been correctly characterized at the TSFIs, the developer is required to provide the purpose and method of use, parameters for the SFR-enforcing and SFR-supporting TSFIs. At , the developer is required to provide the purpose, method of use, parameters, and parameter descriptions for all TSFIs. Additionally, for the SFR-enforcing TSFIs the developer shall describe the SFR-enforcing actions and direct error messages. At , the developer must now, in addition to the information required at , provide enough information about the SFR-supporting and SFR-non-interfering actions to show that they are not SFR-enforcing. Further, the developer must now document all of the direct error messages resulting from the invocation of SFR-enforcing TSFIs. At , all TSFIs, whether SFR-enforcing, SFR-supporting or SFR-non-interfering, must be described to the same degree, including all of the direct error messages. At Complete semi-formal functional specification with additional error information, the TSFIs descriptions also include error messages that do not result from an invocation of a TSFI. At Complete semi-formal functional specification with additional formal specification, in addition to the information required by , all remaining error messages are included. The developer must also provide a formal description of the TSFI. This provides an alternative view of the TSFI that may expose inconsistencies or incomplete specification. The objective of this sub-activity is to determine whether the developer has provided a high-level description of at least the SFR-enforcing and SFR-supporting TSFIs, in terms of descriptions of their parameters. There is no other required evidence that can be expected to be available to measure the accuracy of these descriptions; the evaluator merely ensures the descriptions seem plausible. the ST; the functional specification; the operational user guidance. The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs. The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supportingTSFI. The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI. The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering. The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the functional specification to determine that it states the purpose of each SFR-supporting and SFR-enforcing TSFI. The purpose of a TSFI is a general statement summarising the functionality provided by the interface. It is not intended to be a complete statement of the actions and results related to the interface, but rather a statement to help the reader understand in general what the interface is intended to be used for. The evaluator should not only determine that the purpose exists, but also that it accurately reflects the TSFI by taking into account other information about the interface, such as the description of the parameters; this can be done in association with other work units for this component. If an action available through an interface plays a role in enforcing any security policy on the TOE (that is, if one of the actions of the interface can be traced to one of the SFRs levied on the TSF), then that interface is SFR-enforcing. Such policies are not limited to the access control policies, but also refer to any functionality specified by one of the SFRs contained in the ST. Note that it is possible that an interface may have various actions and results, some of which may be SFR-enforcing and some of which may not. Interfaces to (or actions available through an interface relating to) actions that SFR-enforcing functionality depends on, but need only to function correctly in order for the security policies of the TOE to be preserved, are termed SFR supporting. Interfaces to actions on which SFR-enforcing functionality has no dependence are termed SFR non-interfering. It should be noted that in order for an interface to be SFR supporting or SFR non-interfering it must have no SFR-enforcing actions or results. In contrast, an SFR-enforcing interface may have SFR-supporting actions (for example, the ability to set the system clock may be an SFR-enforcing action of an interface, but if that same interface is used to display the system date that action may only be SFR supporting). An example of a purely SFR-supporting interface is a system call interface that is used both by untrusted users and by a portion of the TSF that is running in user mode. At this level, it is unlikely that a developer will have expended effort to label interfaces as SFR-enforcing and SFR-supporting. In the case that this has been done, the evaluator should verify to the extent that supporting documentation (e.g., operational user guidance) allows that this identification is correct. Note that this identification activity is necessary for several work units for this component. In the more likely case that the developer has not labelled the interfaces, the evaluator must perform their own identification of the interfaces first, and then determine whether the required information (for this work unit, the purpose) is present. Again, because of the lack of supporting evidence this identification will be difficult and have low assurance that all appropriate interfaces have been correctly identified, but nonetheless the evaluator examines other evidence available for the TOE to ensure as complete coverage as is possible. The evaluator shall examine the functional specification to determine that the method of use for each SFR-supporting and SFR-enforcing TSFI is given. See work unit for a discussion on the identification of SFR-supporting and SFR-enforcing TSFI. The method of use for a TSFI summarizes how the interface is manipulated in order to invoke the actions and obtain the results associated with the TSFI. The evaluator should be able to determine, from reading this material in the functional specification, how to use each interface. This does not necessarily mean that there needs to be a separate method of use for each TSFI, as it may be possible to describe in general how kernel calls are invoked, for instance, and then identify each interface using that general style. Different types of interfaces will require different method of use specifications. APIs, network protocol interfaces, system configuration parameters, and hardware bus interfaces all have very different methods of use, and this should be taken into account by the developer when developing the functional specification, as well as by the evaluator evaluating the functional specification. For administrative interfaces, whose functionality is documented as being inaccessible to untrusted users, the evaluator ensures that the method of making the functions inaccessible is described in the functional specification. It should be noted that this inaccessibility needs to be tested by the developer in their test suite. The evaluator shall examine the presentation of the TSFI to determine that it identifies all parameters associated with each SFR-enforcing and SFR-supporting TSFI. See work unit for a discussion on the identification of SFR-supporting and SFR-enforcing TSFI. The evaluator examines the functional specification to ensure that all of the parameters are described for identified TSFI. Parameters are explicit inputs or outputs to an interface that control the behaviour of that interface. For examples, parameters are the arguments supplied to an API; the various fields in packet for a given network protocol; the individual key values in the Windows Registry; the signals across a set of pins on a chip; etc. While difficult to obtain much assurance that all parameters for the applicable TSFI have been identified, the evaluator should also check other evidence provided for the evaluation (e.g., operational user guidance) to see if behaviour or additional parameters are described there but not in the functional specification. The evaluator shall examine the rationale provided by the developer for the implicit categorisation of interfaces as SFR-non-interfering to determine that it is accurate. In the case where the developer has provided adequate documentation to perform the analysis called for by the rest of the work units for this component without explicitly identifying SFR-enforcing and SFR-supporting interfaces, this work unit should be considered satisfied. This work unit is intended to apply to cases where the developer has not described a portion of the TSFI, claiming that it is SFR-non-interfering and therefore not subject to other requirements of this component. In such a case, the developer provides a rationale for this characterisation in sufficient detail such that the evaluator understands the rationale, the characteristics of the interfaces affected (e.g., their high-level function with respect to the TOE, such as "colour palette manipulation"), and that the claim that these are SFR-non-interfering is supported. Given the level of assurance the evaluator should not expect more detail than is provided for the SFR-enforcing or SFR-supporting interfaces, and in fact the detail should be much less. In most cases, individual interfaces should not need to be addressed in the developer-provided rationale subclause. The evaluator shall check that the tracing links the SFRs to the corresponding TSFIs. The tracing is provided by the developer to serve as a guide to which SFRs are related to which TSFIs. This tracing can be as simple as a table; it is used as input to the evaluator for use in the following work units, in which the evaluator verifies its completeness and accuracy. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. The evaluator shall examine the functional specification to determine that it is a complete instantiation of the SFRs. To ensure that all SFRs are covered by the functional specification, as well as the test coverage analysis, the evaluator may build upon the developer's tracing (see a map between the TOE security functional requirements and the TSFI). Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were covered by three different TSFI, it would be inadequate for the evaluator to map to TSFI A, B, and C and claim they had completed the work unit. Instead, the evaluator would map (rule 1) to TSFI A; (rule 2) to TSFI B; etc. It can also be the case that the interface is a wrapper interface (e.g., IOCTL), in which case the mapping would need to be specific to certain set of parameters for a given interface. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that they completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. It is also important to note that since the parameters associated with TSFIs must be fully specified, the evaluator should be able to determine if all aspects of an SFR appear to be implemented at the interface level. The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the SFRs. For each functional requirement in the ST that results in effects visible at the TSF boundary, the information in the associated TSFI for that requirement specifies the required functionality described by the requirement. For example, if the ST contains a requirement for access control lists, and the only TSFI that map to that requirement specify functionality for Unix-style protection bits, then the functional specification is not accurate with respect to the requirements. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that the evaluator completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. The objective of this sub-activity is to determine whether the developer has provided a description of the TSFIs in terms of their purpose, method of use, and parameters. In addition, the SFR-enforcing actions, results and error messages of each TSFI that is SFR-enforcing are also described. the ST; the functional specification; the TOE design. The evaluation evidence for this sub-activity that is used if included in the ST for the TOE is: the security architecture description; the operational user guidance. The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs. The functional specification shall completely represent the TSF. The functional specification shall describe the purpose and method of use for all TSFI. The functional specification shall identify and describe all parameters associated with each TSFI. For each SFR-enforcing TSFI, the functional specification shall describe the SFR-enforcing actions associated with the TSFI. For each SFR-enforcing TSFI, the functional specification shall describe direct error messages resulting from processing associated with the SFR-enforcing actions. The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the functional specification to determine that the TSF is fully represented. The identification of the TSFI is a necessary prerequisite to all other activities in this sub-activity. The TSF must be identified (done as part of the work units) in order to identify the TSFI. This activity can be done at a high level to ensure that no large groups of interfaces have been missed (network protocols, hardware interfaces, configuration files), or at a low level as the evaluation of the functional specification proceeds. In making an assessment for this work unit, the evaluator determines that all portions of the TSF are addressed in terms of the interfaces listed in the functional specification. All portions of the TSF should have a corresponding interface description, or if there are no corresponding interfaces for a portion of the TSF, the evaluator determines that that is acceptable. The evaluator shall examine the functional specification to determine that it states the purpose of each TSFI. The purpose of a TSFI is a general statement summarising the functionality provided by the interface. It is not intended to be a complete statement of the actions and results related to the interface, but rather a statement to help the reader understand in general what the interface is intended to be used for. The evaluator should not only determine that the purpose exists, but also that it accurately reflects the TSFI by taking into account other information about the interface, such as the description of actions and error messages. The evaluator shall examine the functional specification to determine that the method of use for each TSFI is given. The method of use for a TSFI summarizes how the interface is manipulated in order to invoke the actions and obtain the results associated with the TSFI. The evaluator should be able to determine, from reading this material in the functional specification, how to use each interface. This does not necessarily mean that there needs to be a separate method of use for each TSFI, as it may be possible to describe in general how kernel calls are invoked, for instance, and then identify each interface using that general style. Different types of interfaces will require different method of use specifications. APIs, network protocol interfaces, system configuration parameters, and hardware bus interfaces all have very different methods of use, and this should be taken into account by the developer when developing the functional specification, as well as by the evaluator evaluating the functional specification. For administrative interfaces, whose functionality is documented as being inaccessible to untrusted users, the evaluator ensures that the method of making the functions inaccessible is described in the functional specification. It should be noted that this inaccessibility needs to be tested by the developer in their test suite. The evaluator should not only determine that the set of method of use descriptions exist, but also that they accurately cover each TSFI. The evaluator shall examine the presentation of the TSFI to determine that it completely identifies all parameters associated with every TSFI. The evaluator examines the functional specification to ensure that all of the parameters are described for each TSFI. Parameters are explicit inputs or outputs to an interface that control the behaviour of that interface. For examples, parameters are the arguments supplied to an API; the various fields in packet for a given network protocol; the individual key values in the Windows Registry; the signals across a set of pins on a chip; etc. In order to determine that all of the parameters are present in the TSFI, the evaluator should examine the rest of the interface description (actions, error messages, etc.) to determine if the effects of the parameter are accounted for in the description. The evaluator should also check other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance, implementation representation) to see if behaviour or additional parameters are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes all parameters associated with every TSFI. Once all of the parameters have been identified, the evaluator needs to ensure that they are accurately described, and that the description of the parameters is complete. A parameter description tells what the parameter is in some meaningful way. For instance, the interface foo(i) can be described as having "parameter i which is an integer"; this is not an acceptable parameter description. A description such as "parameter i is an integer that indicates the number of users currently logged in to the system" is much more acceptable. In order to determine that the description of the parameters is complete, the evaluator should examine the rest of the interface description (purpose, method of use, actions, error messages, etc.) to determine if the descriptions of the parameter(s) are accounted for in the description. The evaluator should also check other evidence provided (e.g., TOE design, architectural design, operational user guidance, implementation representation) to see if behaviour or additional parameters are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes the SFR-enforcing actions associated with the SFR-enforcing TSFIs. If an action available through an interface can be traced to one of the SFRs levied on the TSF, then that interface is SFR-enforcing. Such policies are not limited to the access control policies, but also refer to any functionality specified by one of the SFRs contained in the ST. Note that it is possible that an interface may have various actions and results, some of which may be SFR-enforcing and some of which may not. The developer is not required to "label" interfaces as SFR-enforcing, and likewise is not required to identify actions available through an interface as SFR-enforcing. It is the evaluator's responsibility to examine the evidence provided by the developer and determine that the required information is present. In the case where the developer has identified the SFR-enforcing TSFI and SFR-enforcing actions available through those TSFI, the evaluator must judge completeness and accuracy based on other information supplied for the evaluation (e.g., TOE design, security architecture description, operational user guidance), and on the other information presented for the interfaces (parameters and parameter descriptions, error messages, etc.). In this case (where the developer has provided only the SFR-enforcing information for SFR-enforcing TSFI) the evaluator also ensures that no interfaces have been mis-categorised. This is done by examining other information supplied for the evaluation (e.g., TOE design, security architecture description, operational user guidance), and the other information presented for the interfaces (parameters and parameter descriptions, for example) not labelled as SFR-enforcing. In the case where the developer has provided the same level of information on all interfaces, the evaluator performs the same type of analysis mentioned in the previous paragraphs. The evaluator should determine which interfaces are SFR-enforcing and which are not, and subsequently ensure that the SFR-enforcing aspects of the SFR-enforcing actions are appropriately described. The SFR-enforcing actions are those that are visible at any external interface and that provide for the enforcement of the SFRs being claimed. For example, if audit requirements are included in the ST, then audit-related actions would be SFR-enforcing and therefore must be described, even if the result of that action is generally not visible through the invoked interface (as is often the case with audit, where a user action at one interface would produce an audit record visible at another interface). The level of description that is required is that sufficient for the reader to understand what role the TSFI actions play with respect to the SFR. The evaluator should keep in mind that the description should be detailed enough to support the generation (and assessment) of test cases against that interface. If the description is unclear or lacking detail such that meaningful testing cannot be conducted against the TSFI, it is likely that the description is inadequate. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes error messages that may result from SFR-enforcing actions associated with each SFR-enforcing TSFI. This work unit should be performed in conjunction with, or after, work unit in order to ensure the set of SFR-enforcing TSFI and SFR-enforcing actions is correctly identified. The developer may provide more information than is required (for example, all error messages associated with each interface), in which the case the evaluator should restrict their assessment of completeness and accuracy to only those that they determine to be associated with SFR-enforcing actions of SFR-enforcing TSFI. Errors can take many forms, depending on the interface being described. For an API, the interface itself may return an error code, set a global error condition, or set a certain parameter with an error code. For a configuration file, an incorrectly configured parameter may cause an error message to be written to a log file. For a hardware PCI card, an error condition may raise a signal on the bus, or trigger an exception condition to the CPU. Errors (and the associated error messages) come about through the invocation of an interface. The processing that occurs in response to the interface invocation may encounter error conditions, which trigger (through an implementation-specific mechanism) an error message to be generated. In some instances, this may be a return value from the interface itself; in other instances a global value may be set and checked after the invocation of an interface. It is likely that a TOE will have a number of low-level error messages that may result from fundamental resource conditions, such as "disk full" or "resource locked". While these error messages may map to a large number of TSFI, they can be used to detect instances where detail from an interface description has been omitted. For instance, a TSFI that produces a "disk full" message, but has no obvious description of why that TSFI should cause an access to the disk in its description of actions, can cause the evaluator to examine other evidence , related that TSFI to determine if the description is accurate. In order to determine that the description of the error messages of a TSFI is accurate and complete, the evaluator measures the interface description against the other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance), as well as other evidence available for that TSFI (parameters, analysis from work unit ). The evaluator shall check that the tracing links the SFRs to the corresponding TSFIs. The tracing is provided by the developer to serve as a guide to which SFRs are related to which TSFIs. This tracing can be as simple as a table; it is used as input to the evaluator for use in the following work units, in which the evaluator verifies its completeness and accuracy. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. The evaluator shall examine the functional specification to determine that it is a complete instantiation of the SFRs. To ensure that all SFRs are covered by the functional specification, as well as the test coverage analysis, the evaluator may build upon the developer's tracing (see a map between the TOE security functional requirements and the TSFI. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were covered by three different TSFI, it would be inadequate for the evaluator to map to TSFI A, B, and C and claim they had completed the work unit. Instead, the evaluator would map (rule 1) to TSFI A; (rule 2) to TSFI B; etc. It can also be the case that the interface is a wrapper interface (e.g., IOCTL), in which case the mapping would need to be specific to certain set of parameters for a given interface. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that they completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. It is also important to note that since the parameters, actions, and error messages associated with TSFIs must be fully specified, the evaluator should be able to determine if all aspects of an SFR appear to be implemented at the interface level. The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the SFRs. For each functional requirement in the ST that results in effects visible at the TSF boundary, the information in the associated TSFI for that requirement specifies the required functionality described by the requirement. For example, if the ST contains a requirement for access control lists, and the only TSFI that map to that requirement specify functionality for Unix-style protection bits, then the functional specification is not accurate with respect to the requirements. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that the evaluator completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. The objective of this sub-activity is to determine whether the developer has provided a description of the TSFIs in terms of their purpose, method of use, and parameters. In addition, the actions, results and error messages of each TSFI are also described sufficiently that it can be determined whether they are SFR-enforcing, with the SFR-enforcing TSFI being described in more detail than other TSFIs. the ST; the functional specification; the TOE design. The evaluation evidence for this sub-activity that is used if included in the ST for the TOE is: the security architecture description; the implementation representation; the TSF internals description; the operational user guidance. The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs. The functional specification shall completely represent the TSF. The functional specification shall describe the purpose and method of use for all TSFI. The functional specification shall identify and describe all parameters associated with each TSFI. For each SFR-enforcing TSFI, the functional specification shall describe the SFR-enforcing actions associated with the TSFI. For each SFR-enforcing TSFI, the functional specification shall describe direct error messages resulting from SFR-enforcing actions and exceptions associated with invocation of the TSFI. The functional specification shall summarize the SFR-supporting and SFR-non-interfering actions associated with each TSFI. The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the functional specification to determine that the TSF is fully represented. The identification of the TSFI is a necessary prerequisite to all other activities in this sub-activity. The TSF must be identified (done as part of the work units) in order to identify the TSFI. This activity can be done at a high level to ensure that no large groups of interfaces have been missed (network protocols, hardware interfaces, configuration files), or at a low level as the evaluation of the functional specification proceeds. In making an assessment for this work unit, the evaluator determines that all portions of the TSF are addressed in terms of the interfaces listed in the functional specification. All portions of the TSF should have a corresponding interface description, or if there are no corresponding interfaces for a portion of the TSF, the evaluator determines that that is acceptable. The evaluator shall examine the functional specification to determine that it states the purpose of each TSFI. The purpose of a TSFI is a general statement summarising the functionality provided by the interface. It is not intended to be a complete statement of the actions and results related to the interface, but rather a statement to help the reader understand in general what the interface is intended to be used for. The evaluator should not only determine that the purpose exists, but also that it accurately reflects the TSFI by taking into account other information about the interface, such as the description of actions and error messages. The evaluator shall examine the functional specification to determine that the method of use for each TSFI is given. The method of use for a TSFI summarizes how the interface is manipulated in order to invoke the actions and obtain the results associated with the TSFI. The evaluator should be able to determine, from reading this material in the functional specification, how to use each interface. This does not necessarily mean that there needs to be a separate method of use for each TSFI, as it may be possible to describe in general how kernel calls are invoked, for instance, and then identify each interface using that general style. Different types of interfaces will require different method of use specifications. APIs, network protocol interfaces, system configuration parameters, and hardware bus interfaces all have very different methods of use, and this should be taken into account by the developer when developing the functional specification, as well as by the evaluator evaluating the functional specification. For administrative interfaces whose functionality is documented as being inaccessible to untrusted users, the evaluator ensures that the method of making the functions inaccessible is described in the functional specification. It should be noted that this inaccessibility needs to be tested by the developer in their test suite. The evaluator should not only determine that the set of method of use descriptions exist, but also that they accurately cover each TSFI. The evaluator shall examine the presentation of the TSFI to determine that it completely identifies all parameters associated with every TSFI. The evaluator examines the functional specification to ensure that all of the parameters are described for each TSFI. Parameters are explicit inputs or outputs to an interface that control the behaviour of that interface. For examples, parameters are the arguments supplied to an API; the various fields in packet for a given network protocol; the individual key values in the Windows Registry; the signals across a set of pins on a chip; etc. In order to determine that all of the parameters are present in the TSFI, the evaluator should examine the rest of the interface description (actions, error messages, etc.) to determine if the effects of the parameter are accounted for in the description. The evaluator should also check other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance, implementation representation) to see if behaviour or additional parameters are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes all parameters associated with every TSFI. Once all of the parameters have been identified, the evaluator needs to ensure that they are accurately described, and that the description of the parameters is complete. A parameter description tells what the parameter is in some meaningful way. For instance, the interface foo(i) can be described as having "parameter i which is an integer"; this is not an acceptable parameter description. A description such as "parameter i is an integer that indicates the number of users currently logged in to the system" is much more acceptable. In order to determine that the description of the parameters is complete, the evaluator should examine the rest of the interface description (purpose, method of use, actions, error messages, etc.) to determine if the descriptions of the parameter(s) are accounted for in the description. The evaluator should also check other evidence provided (e.g., TOE design, architectural design, operational user guidance, implementation representation) to see if behaviour or additional parameters are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes the SFR-enforcing actions associated with the SFR-enforcing TSFIs. If an action available through an interface plays a role in enforcing any security policy on the TOE (that is, if one of the actions of the interface can be traced to one of the SFRs levied on the TSF), then that interface is SFR-enforcing. Such policies are not limited to the access control policies, but also refer to any functionality specified by one of the SFRs contained in the ST. Note that it is possible that an interface may have various actions and results, some of which may be SFR-enforcing and some of which may not. The developer is not required to "label" interfaces as SFR-enforcing, and likewise is not required to identify actions available through an interface as SFR-enforcing. It is the evaluator's responsibility to examine the evidence provided by the developer and determine that the required information is present. In the case where the developer has identified the SFR-enforcing TSFI and SFR-enforcing actions available through those TSFI, the evaluator must judge completeness and accuracy based on other information supplied for the evaluation (e.g., TOE design, security architecture description, operational user guidance), and on the other information presented for the interfaces (parameters and parameter descriptions, error messages, etc.). In this case (developer has provided only the SFR-enforcing information for SFR-enforcing TSFI) the evaluator also ensures that no interfaces have been mis-categorised. This is done by examining other information supplied for the evaluation (e.g., TOE design, security architecture description, operational user guidance), and the other information presented for the interfaces (parameters and parameter descriptions, for example) not labelled as SFR-enforcing. The analysis done for work units and are also used in making this determination. In the case where the developer has provided the same level of information on all interfaces, the evaluator performs the same type of analysis mentioned in the previous paragraphs. The evaluator should determine which interfaces are SFR-enforcing and which are not, and subsequently ensure that the SFR-enforcing aspects of the SFR-enforcing actions are appropriately described. Note that in this case, the evaluator should be able to perform the bulk of the work associated with work unit in the course of performing this SFR-enforcing analysis. The SFR-enforcing actions are those that are visible at any external interface and that provide for the enforcement of the SFRs being claimed. For example, if audit requirements are included in the ST, then audit-related actions would be SFR-enforcing and therefore must be described, even if the result of that action is generally not visible through the invoked interface (as is often the case with audit, where a user action at one interface would produce an audit record visible at another interface). The level of description that is required is that sufficient for the reader to understand what role the TSFI actions play with respect to the SFR. The evaluator should keep in mind that the description should be detailed enough to support the generation (and assessment) of test cases against that interface. If the description is unclear or lacking detail such that meaningful testing cannot be conducted against the TSFI, it is likely that the description is inadequate. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes error messages that may result from an invocation of each SFR-enforcing TSFI. This work unit should be performed in conjunction with, or after, work unit in order to ensure the set of SFR-enforcing TSFI is correctly identified. The evaluator should note that the requirement and associated work unit is that all direct error messages associated with an SFR-enforcing TSFI must be described, that are associated with SFR-enforcing actions. This is because at this level of assurance, the "extra" information provided by the error message descriptions should be used in determining whether all of the SFR-enforcing aspects of an interface have been appropriately described. For instance, if an error message associated with a TSFI (e.g., "access denied") indicated that an SFR-enforcing decision or action had taken place, but in the description of the SFR-enforcing actions there was no mention of that particular SFR-enforcing mechanism, then the description may not be complete. Errors can take many forms, depending on the interface being described. For an API, the interface itself may return an error code, set a global error condition, or set a certain parameter with an error code. For a configuration file, an incorrectly configured parameter may cause an error message to be written to a log file. For a hardware PCI card, an error condition may raise a signal on the bus, or trigger an exception condition to the CPU. Errors (and the associated error messages) come about through the invocation of an interface. The processing that occurs in response to the interface invocation may encounter error conditions, which trigger (through an implementation-specific mechanism) an error message to be generated. In some instances this may be a return value from the interface itself; in other instances a global value may be set and checked after the invocation of an interface. It is likely that a TOE will have a number of low-level error messages that may result from fundamental resource conditions, such as "disk full" or "resource locked". While these error messages may map to a large number of TSFI, they can be used to detect instances where detail from an interface description has been omitted. For instance, a TSFI that produces a "disk full" message, but has no obvious description of why that TSFI should cause an access to the disk in its description of actions, can cause the evaluator to examine other evidence , related that TSFI to determine if the description is accurate. In order to determine that the description of the error messages of a TSFI is accurate and complete, the evaluator measures the interface description against the other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance), as well as for other evidence supplied for that TSFI (description of SFR-enforcing actions, summary of SFR-supporting and SFR-non-interfering actions and results). The evaluator shall examine the presentation of the TSFI to determine that it summarizes the SFR-supporting and SFR-non-interfering actions associated with each TSFI. The purpose of this work unit is to supplement the details about the SFR-enforcing actions (provided in work unit ) with a summary of the remaining actions (i.e., those that are not SFR-enforcing). This covers all SFR-supporting and SFR-non-interfering actions, whether invokable through SFR-enforcing TSFI or through SFR-supporting or SFR-non-interfering TSFI. Such a summary about all SFR-supporting and SFR-non-interfering actions helps to provide a more complete picture of the functions provided by the TSF, and is to be used by the evaluator in determining whether an action or TSFI may have been mis-categorised. The information to be provided is more abstract than that required for SFR-enforcing actions. While it should still be detailed enough so that the reader can understand what the action does, the description does not have to be detailed enough to support writing tests against it, for instance. For the evaluator, the key is that the information must be sufficient to make a positive determination that the action is SFR-supporting or SFR-non-interfering. If that level of information is missing, the summary is insufficient and more information must be obtained. The evaluator shall check that the tracing links the SFRs to the corresponding TSFIs. The tracing is provided by the developer to serve as a guide to which SFRs are related to which TSFIs. This tracing can be as simple as a table; it is used as input to the evaluator for use in the following work units, in which the evaluator verifies its completeness and accuracy. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. The evaluator shall examine the functional specification to determine that it is a complete instantiation of the SFRs. To ensure that all SFRs are covered by the functional specification, as well as the test coverage analysis, the evaluator may build upon the developer's tracing (see a map between the TOE security functional requirements and the TSFI. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were covered by three different TSFI, it would be inadequate for the evaluator to map to TSFI A, B, and C and claim they had completed the work unit. Instead, the evaluator would map (rule 1) to TSFI A; (rule 2) to TSFI B; etc. It can also be the case that the interface is a wrapper interface (e.g., IOCTL), in which case the mapping would need to be specific to certain set of parameters for a given interface. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that they completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. It is also important to note that since the parameters, actions, and error messages associated with TSFIs must be fully specified, the evaluator should be able to determine if all aspects of an SFR appear to be implemented at the interface level. The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the SFRs. For each functional requirement in the ST that results in effects visible at the TSF boundary, the information in the associated TSFI for that requirement specifies the required functionality described by the requirement. For example, if the ST contains a requirement for access control lists, and the only TSFI that map to that requirement specify functionality for Unix-style protection bits, then the functional specification is not accurate with respect to the requirements. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that the evaluator completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. The objective of this sub-activity is to determine whether the developer has completely described all of the TSFI in a manner such that the evaluator is able to determine whether the TSFI are completely and accurately described, and appears to implement the security functional requirements of the ST. The functional specification describes the interfaces to the TSF (the TSFI) in a structured manner. Because of the dependency on Evaluation of sub-activity , the evaluator is expected to have identified the TSF prior to beginning work on this sub-activity. Without firm knowledge of what comprises the TSF, it is not possible to assess the completeness of the TSFI. In performing the various work units included in this family, the evaluator is asked to make assessments of accuracy and completeness of several factors (the TSFI itself, as well as the individual components (parameters, actions, error messages, etc.) of the TSFI). In doing this analysis, the evaluator is expected to use the documentation provided for the evaluation. This includes the ST, the TOE design, and may include other documentation such as the operational user guidance, security architecture description, and implementation representation. The documentation should be examined in an iterative fashion. The evaluator may read, for example, in the TOE design how a certain function is implemented, but see no way to invoke that function from the interface. This can cause the evaluator to question the completeness of a particular TSFI description, or whether an interface has been left out of the functional specification altogether. Describing analysis activities of this sort in the ETR is a key method in providing rationale that the work units have been performed appropriately. It should be recognised that there exist functional requirements whose functionality is manifested wholly or in part architecturally, rather than through a specific mechanism. An example of this is the implementation of mechanisms implementing the requirements. Such mechanisms typically are implemented to ensure a behaviour isn't present, which is difficult to test and typically is verified through analysis. In the cases where such functional requirements are included in the ST, it is expected that the evaluator recognise that there may be SFRs of this type that have no interfaces, and that this should not be considered a deficiency in the functional specification. the ST; the functional specification; the TOE design. The evaluation evidence for this sub-activity that is used if included in the ST for the TOE is: the security architecture description; the implementation representation; the TSF internals description; the operational user guidance. The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs. The functional specification shall completely represent the TSF. The functional specification shall describe the purpose and method of use for all TSFI. The functional specification shall identify and describe all parameters associated with each TSFI. The functional specification shall describe all actions associated with each TSFI. The functional specification shall describe all direct error messages that may result from an invocation of each TSFI. The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the functional specification to determine that the TSF is fully represented. The identification of the TSFI is a necessary prerequisite to all other activities in this sub-activity. The TSF must be identified (done as part of the work units) in order to identify the TSFI. This activity can be done at a high level to ensure that no large groups of interfaces have been missed (network protocols, hardware interfaces, configuration files), or at a low level as the evaluation of the functional specification proceeds. In making an assessment for this work unit, the evaluator determines that all portions of the TSF are addressed in terms of the interfaces listed in the functional specification. All portions of the TSF should have a corresponding interface description, or if there are no corresponding interfaces for a portion of the TSF, the evaluator determines that that is acceptable. The evaluator shall examine the functional specification to determine that it states the purpose of each TSFI. The purpose of a TSFI is a general statement summarising the functionality provided by the interface. It is not intended to be a complete statement of the actions and results related to the interface, but rather a statement to help the reader understand in general what the interface is intended to be used for. The evaluator should not only determine that the purpose exists, but also that it accurately reflects the TSFI by taking into account other information about the interface, such as the description of actions and error messages. The evaluator shall examine the functional specification to determine that the method of use for each TSFI is given. The method of use for a TSFI summarizes how the interface is manipulated in order to invoke the actions and obtain the results associated with the TSFI. The evaluator should be able to determine, from reading this material in the functional specification, how to use each interface. This does not necessarily mean that there needs to be a separate method of use for each TSFI, as it may be possible to describe in general how kernel calls are invoked, for instance, and then identify each interface using that general style. Different types of interfaces will require different method of use specifications. APIs, network protocol interfaces, system configuration parameters, and hardware bus interfaces all have very different methods of use, and this should be taken into account by the developer when developing the functional specification, as well as by the evaluator evaluating the functional specification. For administrative interfaces whose functionality is documented as being inaccessible to untrusted users, the evaluator ensures that the method of making the functions inaccessible is described in the functional specification. It should be noted that this inaccessibility needs to be tested by the developer in their test suite. The evaluator should not only determine that the set of method of use descriptions exist, but also that they accurately cover each TSFI. The evaluator shall examine the functional specification to determine the completeness of the TSFI The evaluator shall use the design documentation to identify the possible types of interfaces. The evaluator shall search the design documentation and the guidance documentation for potential TSFI not contained in the developer's documentation, thus indicating that the set of TSFI defined by the developer is incomplete. The evaluator shall examine the arguments presented by the developer that the TSFI is complete and check down to the lowest level of design or with the implementation representation that no additional TSFI exist. The evaluator shall examine the presentation of the TSFI to determine that it completely identifies all parameters associated with every TSFI. The evaluator examines the functional specification to ensure that all of the parameters are described for each TSFI. Parameters are explicit inputs or outputs to an interface that control the behaviour of that interface. For examples, parameters are the arguments supplied to an API; the various fields in packet for a given network protocol; the individual key values in the Windows Registry; the signals across a set of pins on a chip; etc. In order to determine that all of the parameters are present in the TSFI, the evaluator should examine the rest of the interface description (actions, error messages, etc.) to determine if the effects of the parameter are accounted for in the description. The evaluator should also check other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance, implementation representation) to see if behaviour or additional parameters are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes all parameters associated with every TSFI. Once all of the parameters have been identified, the evaluator needs to ensure that they are accurately described, and that the description of the parameters is complete. A parameter description tells what the parameter is in some meaningful way. For instance, the interface foo(i) can be described as having "parameter i which is an integer"; this is not an acceptable parameter description. A description such as "parameter i is an integer that indicates the number of users currently logged in to the system" is much more acceptable. In order to determine that the description of the parameters is complete, the evaluator should examine the rest of the interface description (purpose, method of use, actions, error messages, etc.) to determine if the descriptions of the parameter(s) are accounted for in the description. The evaluator should also check other evidence provided (e.g., TOE design, architectural design, operational user guidance, implementation representation) to see if behaviour or additional parameters are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes all actions associated with every TSFI. The evaluator checks to ensure that all of the actions are described. actions available through an interface describe what the interface does (as opposed to the TOE design, which describes how the actions are provided by the TSF). Actions of an interface describe functionality that can be invoked through the interface, and can be categorised as regular actions, and SFR-related actions. Regular actions are descriptions of what the interface does. The amount of information provided for this description is dependent on the complexity of the interface. The SFR-related actions are those that are visible at any external interface (for instance, audit activity caused by the invocation of an interface (assuming audit requirements are included in the ST) should be described, even though the result of that action is generally not visible through the invoked interface). Depending on the parameters of an interface, there may be many different actions able to be invoked through the interface (for instance, an API can have the first parameter be a "subcommand", and the following parameters be specific to that subcommand. The IOCTL API in some Unix systems is an example of such an interface). In order to determine that the description of the actions of a TSFI is complete, the evaluator should review the rest of the interface description (parameter descriptions, error messages, etc.) to determine if the actions described are accounted for. The evaluator should also analyse other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance, implementation representation) to see if there is evidence of actions that are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes all error messages resulting from an invocation of each TSFI. Errors can take many forms, depending on the interface being described. For an API, the interface itself may return an error code; set a global error condition, or set a certain parameter with an error code. For a configuration file, an incorrectly configured parameter may cause an error message to be written to a log file. For a hardware PCI card, an error condition may raise a signal on the bus, or trigger an exception condition to the CPU. Errors (and the associated error messages) come about through the invocation of an interface. The processing that occurs in response to the interface invocation may encounter error conditions, which trigger (through an implementation-specific mechanism) an error message to be generated. In some instances this may be a return value from the interface itself; in other instances a global value may be set and checked after the invocation of an interface. It is likely that a TOE will have a number of low-level error messages that may result from fundamental resource conditions, such as "disk full" or "resource locked". While these error messages may map to a large number of TSFI, they can be used to detect instances where detail from an interface description has been omitted. For instance, a TSFI that produces a "disk full" message, but has no obvious description of why that TSFI should cause an access to the disk in its description of actions, can cause the evaluator to examine other evidence , related that TSFI to determine if the description is complete and accurate. The evaluator determines that, for each TSFI, the exact set of error messages that can be returned on invoking that interface can be determined. The evaluator reviews the evidence provided for the interface to determine if the set of errors seems complete. They cross-check this information with other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance, implementation representation) to ensure that there are no errors steaming from processing mentioned that are not included in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes the meaning of all error messages resulting from an invocation of each TSFI. In order to determine accuracy, the evaluator must be able to understand meaning of the error. For example, if an interface returns a numeric code of 0, 1, or 2, the evaluator would not be able to understand the error if the functional specification only listed: "possible errors resulting from invocation of the foo() interface are 0, 1, or 2". Instead the evaluator checks to ensure that the errors are described such as: "possible errors resulting from invocation of the foo() interface are 0 (processing successful), 1 (file not found), or 2 (incorrect filename specification)". In order to determine that the description of the errors due to invoking a TSFI is complete, the evaluator examines the rest of the interface description (parameter descriptions, actions, etc.) to determine if potential error conditions that can be caused by using such an interface are accounted for. The evaluator also checks other evidence provided for the evaluation (e.g. TOE design, security architecture description, operational user guidance, implementation representation) to see if error processing related to the TSFI is described there but is not described in the functional specification. The evaluator shall check that the tracing links the SFRs to the corresponding TSFIs. The tracing is provided by the developer to serve as a guide to which SFRs are related to which TSFIs. This tracing can be as simple as a table; it is used as input to the evaluator for use in the following work units, in which the evaluator verifies its completeness and accuracy. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. The evaluator shall examine the functional specification to determine that it is a complete instantiation of the SFRs. To ensure that all SFRs are covered by the functional specification, as well as the test coverage analysis, the evaluator may build upon the developer's tracing (see a map between the TOE security functional requirements and the TSFI. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were covered by three different TSFI, it would be inadequate for the evaluator to map to TSFI A, B, and C and claim they had completed the work unit. Instead, the evaluator would map (rule 1) to TSFI A; (rule 2) to TSFI B; etc. It can also be the case that the interface is a wrapper interface (e.g., IOCTL), in which case the mapping would need to be specific to certain set of parameters for a given interface. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that they completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. It is also important to note that since the parameters, actions, and error messages associated with TSFIs must be fully specified, the evaluator should be able to determine if all aspects of an SFR appear to be implemented at the interface level. The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the SFRs. For each functional requirement in the ST that results in effects visible at the TSF boundary, the information in the associated TSFI for that requirement specifies the required functionality described by the requirement. For example, if the ST contains a requirement for access control lists, and the only TSFI that map to that requirement specify functionality for Unix-style protection bits, then the functional specification is not accurate with respect to the requirements. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that the evaluator completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. The objective of this sub-activity is to determine whether the developer has completely described all of the TSFI in a manner such that the evaluator is able to determine whether the TSFI are completely and accurately described, and appears to implement the security functional requirements of the ST. The completeness of the interfaces is judged based upon the implementation representation. the ST; the functional specification; the TOE design; the implementation representation. The evaluation evidence for this sub-activity that is used if included in the ST for the TOE is: the security architecture description; the TSF internals description; the formal security policy model; the operational user guidance. The developer shall provide a functional specification. The developer shall provide a tracing from the functional specification to the SFRs. The functional specification shall completely represent the TSF. The functional specification shall describe the TSFI using a semi-formal style. The functional specification shall describe the purpose and method of use for all TSFI. The functional specification shall identify and describe all parameters associated with each TSFI. The functional specification shall describe all actions associated with each TSFI. The functional specification shall describe all direct error messages that may result from an invocation of each TSFI. The functional specification shall describe all error messages that do not result from an invocation of a TSFI. The functional specification shall provide a rationale for each error message contained in the TSF implementation yet does not result from an invocation of a TSFI. The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the functional specification to determine that the TSF is fully represented. The identification of the TSFI is a necessary prerequisite to all other activities in this sub-activity. The TSF must be identified (done as part of work units) in order to identify the TSFI. This activity can be done at a high level to ensure that no large groups of interfaces have been missed (network protocols, hardware interfaces, configuration files), or at a low level as the evaluation of the functional specification proceeds. In making an assessment for this work unit, the evaluator determines that all portions of the TSF are addressed in terms of the interfaces listed in the functional specification. All portions of the TSF should have a corresponding interface description, or if there are no corresponding interfaces for a portion of the TSF, the evaluator determines that that is acceptable. The evaluator shall examine the functional specification to determine that it is presented using a semiformal style. A semi-formal presentation is characterised by a standardised format with a well-defined syntax that reduces ambiguity that may occur in informal presentations. Since the intent of the semi-formal format is to enhance the reader's ability to understand the presentation, use of certain structured presentation methods (pseudo-code, flow charts, block diagrams) are appropriate, though not required. For the purposes of this activity, the evaluator should ensure that the interface descriptions are formatted in a structured, consistent manner and use common terminology. A semiformal presentation of the interfaces also implies that the level of detail of the presentation for the interfaces is largely consistent across all TSFI. For the functional specification, it is acceptable to refer to external specifications for portions of the interface as long as those external specifications are themselves semiformal. The evaluator shall examine the functional specification to determine that it states the purpose of each TSFI. The purpose of a TSFI is a general statement summarising the functionality provided by the interface. It is not intended to be a complete statement of the actions and results related to the interface, but rather a statement to help the reader understand in general what the interface is intended to be used for. The evaluator should not only determine that the purpose exists, but also that it accurately reflects the TSFI by taking into account other information about the interface, such as the description of actions and error messages. The evaluator shall examine the functional specification to determine that the method of use for each TSFI is given. The method of use for a TSFI summarizes how the interface is manipulated in order to invoke the actions and obtain the results associated with the TSFI. The evaluator should be able to determine, from reading this material in the functional specification, how to use each interface. This does not necessarily mean that there needs to be a separate method of use for each TSFI, as it may be possible to describe in general how kernel calls are invoked, for instance, and then identify each interface using that general style. Different types of interfaces will require different method of use specifications. APIs, network protocol interfaces, system configuration parameters, and hardware bus interfaces all have very different methods of use, and this should be taken into account by the developer when developing the functional specification, as well as by the evaluator evaluating the functional specification. For administrative interfaces whose functionality is documented as being inaccessible to untrusted users, the evaluator ensures that the method of making the functions inaccessible is described in the functional specification. It should be noted that this inaccessibility needs to be tested by the developer in their test suite. The evaluator should not only determine that the set of method of use descriptions exist, but also that they accurately cover each TSFI. The evaluator shall examine the functional specification to determine the completeness of the TSFI The evaluator shall use the design documentation to identify the possible types of interfaces. The evaluator shall search the design documentation and the guidance documentation for potential TSFI not contained in the developer's documentation, thus indicating that the set of TSFI defined by the developer is incomplete. The evaluator shall examine the arguments presented by the developer that the TSFI is complete and check down to the lowest level of design or with the implementation representation that no additional TSFI exist. The evaluator shall examine the presentation of the TSFI to determine that it completely identifies all parameters associated with every TSFI. The evaluator examines the functional specification to ensure that all of the parameters are described for each TSFI. Parameters are explicit inputs or outputs to an interface that control the behaviour of that interface. For examples, parameters are the arguments supplied to an API; the various fields in packet for a given network protocol; the individual key values in the Windows Registry; the signals across a set of pins on a chip; etc. In order to determine that all of the parameters are present in the TSFI, the evaluator should examine the rest of the interface description (actions, error messages, etc.) to determine if the effects of the parameter are accounted for in the description. The evaluator should also check other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance, implementation representation) to see if behaviour or additional parameters are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes all parameters associated with every TSFI. Once all of the parameters have been identified, the evaluator needs to ensure that they are accurately described, and that the description of the parameters is complete. A parameter description tells what the parameter is in some meaningful way. For instance, the interface foo(i) can be described as having "parameter i which is an integer"; this is not an acceptable parameter description. A description such as "parameter i is an integer that indicates the number of users currently logged in to the system". is much more acceptable. In order to determine that the description of the parameters is complete, the evaluator should examine the rest of the interface description (purpose, method of use, actions, error messages, etc.) to determine if the descriptions of the parameter(s) are accounted for in the description. The evaluator should also check other evidence provided (e.g., TOE design, architectural design, operational user guidance, implementation representation) to see if behaviour or additional parameters are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes all actions associated with every TSFI. The evaluator checks to ensure that all of the actions are described. actions available through an interface describe what the interface does (as opposed to the TOE design, which describes how the actions are provided by the TSF). actions of an interface describe functionality that can be invoked through the interface, and can be categorised as regular actions, and SFR-related actions. Regular actions are descriptions of what the interface does. The amount of information provided for this description is dependent on the complexity of the interface. The SFR-related actions are those that are visible at any external interface (for instance, audit activity caused by the invocation of an interface (assuming audit requirements are included in the ST) should be described, even though the result of that action is generally not visible through the invoked interface). Depending on the parameters of an interface, there may be many different actions able to be invoked through the interface (for instance, an API might have the first parameter be a "subcommand", and the following parameters be specific to that subcommand. The IOCTL API in some Unix systems is an example of such an interface). In order to determine that the description of the actions of a TSFI is complete, the evaluator should review the rest of the interface description (parameter descriptions, error messages, etc.) to determine if the actions described are accounted for. The evaluator should also analyse other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance, implementation representation) to see if there is evidence of actions that are described there but not in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes all error messages resulting from an invocation of each TSFI. Errors can take many forms, depending on the interface being described. For an API, the interface itself may return an error code; set a global error condition, or set a certain parameter with an error code. For a configuration file, an incorrectly configured parameter may cause an error message to be written to a log file. For a hardware PCI card, an error condition may raise a signal on the bus, or trigger an exception condition to the CPU. Errors (and the associated error messages) come about through the invocation of an interface. The processing that occurs in response to the interface invocation may encounter error conditions, which trigger (through an implementation-specific mechanism) an error message to be generated. In some instances this may be a return value from the interface itself; in other instances a global value may be set and checked after the invocation of an interface. It is likely that a TOE will have a number of low-level error messages that may result from fundamental resource conditions, such as "disk full" or "resource locked". While these error messages may map to a large number of TSFI, they can be used to detect instances where detail from an interface description has been omitted. For instance, a TSFI that produces a "disk full" message, but has no obvious description of why that TSFI should cause an access to the disk in its description of actions, can cause the evaluator to examine other evidence , related that TSFI to determine if the description is complete and accurate. The evaluator determines that, for each TSFI, the exact set of error messages that can be returned on invoking that interface can be determined. The evaluator reviews the evidence provided for the interface to determine if the set of errors seems complete. They cross-check this information with other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance, implementation representation) to ensure that there are no errors steaming from processing mentioned that are not included in the functional specification. The evaluator shall examine the presentation of the TSFI to determine that it completely and accurately describes the meaning of all error messages resulting from an invocation of each TSFI. In order to determine accuracy, the evaluator must be able to understand meaning of the error. For example, if an interface returns a numeric code of 0, 1, or 2, the evaluator would not be able to understand the error if the functional specification only listed: "possible errors resulting from invocation of the foo() interface are 0, 1, or 2". Instead the evaluator checks to ensure that the errors are described such as: "possible errors resulting from invocation of the foo() interface are 0 (processing successful), 1 (file not found), or 2 (incorrect filename specification)". In order to determine that the description of the errors due to invoking a TSFI is complete, the evaluator examines the rest of the interface description (parameter descriptions, actions, etc.) to determine if potential error conditions that can be caused by using such an interface are accounted for. The evaluator also checks other evidence provided for the evaluation (e.g., TOE design, security architecture description, operational user guidance, implementation representation) to see if error processing related to the TSFI is described there but is not described in the functional specification. The evaluator shall examine the functional specification to determine that it completely and accurately describes all error messages that do not result from an invocation of any TSFI. This work unit complements work unit , which describes those error messages that result from an invocation of the TSFI. Taken together, these work units cover all error messages that can be generated by the TSF. The evaluator assesses the completeness and accuracy of the functional specification by comparing its contents to instances of error message generation within the implementation representation. Most of these error messages will have already been covered by work unit . The error messages related to this work unit are typically those that are not expected to be generated, but are constructed as a matter of good programming practises. For example, a case statement that defines actions resulting from each of a list of cases may end with a final else statement to apply to anything that cannot be expected; this practise ensures the TSF does not get into an undefined state. However, it is not expected that the path of execution would ever get to this else statement; therefore, any error message generation within this else statement would never be generated. Although it would not get generated, it must still be included in the functional specification. The evaluator shall examine the functional specification to determine that it provides a rationale for each error message contained in the TSF implementation yet does not result from an invocation of a TSFI. The evaluator ensures that every error message found under work unit contains a rationale describing why it cannot be invoked from the TSFI. As was described in the previous work unit, this rationale can be as straightforward as the fact that the error message in question is provided for completeness of execution logic and that it is never expected to be generated. The evaluator ensures that the rationale for each such error message is logical. The evaluator shall check that the tracing links the SFRs to the corresponding TSFIs. The tracing is provided by the developer to serve as a guide to which SFRs are related to which TSFIs. This tracing can be as simple as a table; it is used as input to the evaluator for use in the following work units, in which the evaluator verifies its completeness and accuracy. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. The evaluator shall examine the functional specification to determine that it is a complete instantiation of the SFRs. To ensure that all SFRs are covered by the functional specification, as well as the test coverage analysis, the evaluator may build upon the developer's tracing (see a map between the TOE security functional requirements and the TSFI. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were covered by three different TSFI, it would be inadequate for the evaluator to map to TSFI A, B, and C and claim they had completed the work unit. Instead, the evaluator would map (rule 1) to TSFI A; (rule 2) to TSFI B; etc. It can also be the case that the interface is a wrapper interface (e.g., IOCTL), in which case the mapping would need to be specific to certain set of parameters for a given interface. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that they completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. It is also important to note that since the parameters, actions, and error messages associated with TSFIs must be fully specified, the evaluator should be able to determine if all aspects of an SFR appear to be implemented at the interface level. The evaluator shall examine the functional specification to determine that it is an accurate instantiation of the SFRs. For each functional requirement in the ST that results in effects visible at the TSF boundary, the information in the associated TSFI for that requirement specifies the required functionality described by the requirement. For example, if the ST contains a requirement for access control lists, and the only TSFI that map to that requirement specify functionality for Unix-style protection bits, then the functional specification is not accurate with respect to the requirements. The evaluator must recognise that for requirements that have little or no manifestation at the TSF boundary (e.g., ) it is not expected that the evaluator completely map those requirements to the TSFI. The analysis for those requirements will be performed in the analysis for the when included in the ST. The developer shall provide a functional specification. The developer shall provide a formal presentation of the functional specification of the TSF. The developer shall provide a tracing from the functional specification to the SFRs. The functional specification shall completely represent the TSF. The functional specification shall describe the TSFI using a formal style. The functional specification shall describe the purpose and method of use for all TSFI. The functional specification shall identify and describe all parameters associated with each TSFI. The functional specification shall describe all actions associated with each TSFI. The functional specification shall describe all direct error messages that may result from an invocation of each TSFI. The functional specification shall describe all error messages contained in the TSF implementation representation. The functional specification shall provide a rationale for each error message contained in the TSF implementation that is not otherwise described in the functional specification justifying why it is not associated with a TSFI. The formal presentation of the functional specification of the TSF shall describe the TSFI using a formal style, supported by informal, explanatory text where appropriate. The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. The function of the family is for the developer to make available the implementation representation (and, at higher levels, the implementation itself) of the TOE in a form that can be analysed by the evaluator. The implementation representation is used in analysis activities for other families (analysing the TOE design, for instance) to demonstrate that the TOE conforms its design and to provide a basis for analysis in other areas of the evaluation (e.g. the search for vulnerabilities). The implementation representation is expected to be in a form that captures the detailed internal workings of the TSF. This may be software source code, firmware source code, hardware diagrams and/or IC hardware design language code or layout data. The components in this family are levelled on the amount of implementation that is mapped to the TOE design description. Source code or hardware diagrams and/or IC hardware design language code or layout data that are used to build the actual hardware are examples of parts of an implementation representation. It is important to note that while the implementation representation must be made available to the evaluator, this does not imply that the evaluator needs to possess that representation. For instance, the developer may require that the evaluator review the implementation representation at a site of the developer's choosing. The entire implementation representation is made available to ensure that analysis activities are not curtailed due to lack of information. This does not, however, imply that all of the representation is examined when the analysis activities are being performed. This is likely impractical in almost all cases, in addition to the fact that it most likely will not result in a higher-assurance TOE vs. targeted sampling of the implementation representation. The implementation representation is made available to allow analysis of other TOE design decompositions (e.g. functional specification, TOE design), and to gain confidence that the security functionality described at a higher level in the design actually appear to be implemented in the TOE. Conventions in some forms of the implementation representation may make it difficult or impossible to determine from just the implementation representation itself what the actual result of the compilation or run-time interpretation will be. For example, compiler directives for C language compilers will cause the compiler to exclude or include entire portions of the code. For this reason, it is important that such "extra" information or related tools (e.g. scripts, compilers, etc.) be provided so that the implementation representation can be accurately determined. The purpose of the mapping between the implementation representation and the TOE design description is to aid the evaluator's analysis. The internal workings of the TOE may be better understood when the TOE design is analysed with corresponding portions of the implementation representation. The mapping serves as an index into the implementation representation. At the lower component, only a subset of the implementation representation is mapped to the TOE design description. Because of the uncertainty of which portions of the implementation representation will need such a mapping, the developer may choose either to map the entire implementation representation beforehand, or to wait to see which portions of the implementation representation the evaluator requires to be mapped. The implementation representation is manipulated by the developer in a form that is suitable for transformation to the actual implementation. For instance, the developer may work with files containing source code, which is eventually compiled to become part of the TSF. The developer makes available the implementation representation in the form used by the developer, so that the evaluator may use automated techniques in the analysis. This also increases the confidence that the implementation representation examined is actually the one used in the production of the TSF (as opposed to the case where it is supplied in an alternate presentation format, such as a word processor document). It should be noted that other forms of the implementation representation may also be used by the developer; these forms are supplied as well. The overall goal is to supply the evaluator with the information that will maximize the effectiveness of the evaluator's analysis efforts. Some forms of the implementation representation may require additional information because they introduce significant barriers to understanding and analysis. Examples include "shrouded" source code or source code that has been obfuscated in other ways such that it prevents understanding and/or analysis. These forms of implementation representation typically result from the TOE developer taking a version of the implementation representation and running a shrouding or obfuscation program on it. While the shrouded representation is what is compiled and may be closer to the implementation (in terms of structure) than the original, un-shrouded representation, supplying such obfuscated code may cause significantly more time to be spent in analysis tasks involving the representation. When such forms of representation are created, the components require details on the shrouding tools/algorithms used so that the un-shrouded representation can be supplied, and the additional information can be used to gain confidence that the shrouding process does not compromise any security functionality. The objective of this sub-activity is to determine that the implementation representation made available by the developer is suitable for use in other analysis activities; suitability is judged by its conformance to the requirements for this component. The entire implementation representation is made available to ensure that analysis activities are not curtailed due to lack of information. This does not, however, imply that all of the representation is examined when the analysis activities are being performed. This is likely impractical in almost all cases, in addition to the fact that it most likely will not result in a higher-assurance TOE vs. targeted sampling of the implementation representation. For this sub-activity, this is even truer. It would not be productive for the evaluator to spend large amounts of time verifying the requirements for one portion of the implementation representation, and then use a different portion of the implementation representation in performing analysis for other work units. Therefore, the evaluator is encouraged to select the sample of the implementation representation from the areas of the TOE that will be of most interest during the analysis performed during work units from other families (e.g. , and ). the implementation representation; the documentation of the development tools, as resulting from ; TOE design description. The developer shall make available the implementation representation for the entire TSF. The developer shall provide a mapping between the TOE design description and the sample of the implementation representation. The implementation representation shall define the TSF to a level of detail such that the TSF may be generated without further design decisions. The implementation representation shall be in the form used by the development personnel. The mapping between the TOE design description and the sample of the implementation representation shall demonstrate their correspondence. The evaluator shall confirm that, for the selected sample of the implementation representation, the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the implementation representation defines the TSF to a level of detail such that the TSF can be generated without further design decisions. Source code or hardware diagrams and/or IC hardware design language code or layout data that are used to build the actual hardware are examples of parts of an implementation representation. The evaluator samples the implementation representation to gain confidence that it is at the appropriate level and not, for instance, a pseudo-code level which requires additional design decisions to be made. The evaluator is encouraged to perform a quick check when first looking at the implementation representation to assure themselves that the developer has supplied all the required information. However, the evaluator is also encouraged to perform the bulk of this check while working on other work units that call for examining the implementation; this will ensure the sample examined for this work unit is relevant. The evaluator shall check that the implementation representation is in the form used by development personnel. The implementation representation is manipulated by the developer in a form that is suitable for transformation to the actual implementation. For instance, the developer may work with files containing source code, which is eventually compiled to become part of the TSF. The developer makes available the implementation representation in the form they use, so that the evaluator may use automated techniques in the analysis. This also increases the confidence that the implementation representation examined is actually the one used in the production of the TSF (as opposed to the case where it is supplied in an alternate presentation format, such as a word processor document). It should be noted that other forms of the implementation representation may also be used by the developer; these forms are supplied as well. The overall goal is to supply the evaluator with the information that will maximise the evaluator's analysis efforts. The evaluator samples the implementation representation to gain confidence that it is the version that is usable by the developer. The sample is such that the evaluator has assurance that all areas of the implementation representation are in conformance with the requirement; however, a complete examination of the entire implementation representation is unnecessary. Conventions in some forms of the implementation representation may make it difficult or impossible to determine from just the implementation representation itself what the actual result of the compilation or run-time interpretation will be. For example, compiler directives for C language compilers will cause the compiler to exclude or include entire portions of the code. Some forms of the implementation representation may require additional information because they introduce significant barriers to understanding and analysis. Examples include shrouded source code or source code that has been obfuscated in other ways such that it prevents understanding and/or analysis. These forms of implementation representation typically result from by taking a version of the implementation representation that is used by the TOE developer and running a shrouding or obfuscation program on it. While the shrouded representation is what is compiled and may be closer to the implementation (in terms of structure) than the original, un-shrouded representation, supplying such obfuscated code may cause significantly more time to be spent in analysis tasks involving the representation. When such forms of representation are created, the components require details on the shrouding tools/algorithms used so that the un-shrouded representation can be supplied, and the additional information can be used to gain confidence that the shrouding process does not compromise any security mechanisms. The evaluator samples the implementation representation to gain confidence that all of the information needed to interpret the implementation representation has been supplied. Note that the tools are among those referenced by components. The evaluator is encouraged to perform a quick check when first looking at the implementation representation to assure themselves that the developer is on the right track. However, the evaluator is also encouraged to perform the bulk of this check while working on other work units that call for examining the implementation; this will ensure the sample examined for this work unit is relevant. The evaluator shall examine the mapping between the TOE design description and the sample of the implementation representation to determine that it is accurate. The evaluator augments the determination of existence (specified in work unit ) by verifying the accuracy of a portion of the implementation representation and the TOE design description. For parts of the TOE design description that are interesting, the evaluator would verify the implementation representation accurately reflects the description provided in the TOE design description. For example, the TOE design description can identify a login module that is used to identify and authenticate users. If user authentication is sufficiently significant, the evaluator would verify that the corresponding code in fact implements that service as described in the TOE design description. It can also be worthwhile to verify that the code accepts the parameters as described in the functional specification. It is worth pointing out the developer must choose whether to perform the mapping for the entire implementation representation, thereby guaranteeing that the chosen sample will be covered, or waiting for the sample to be chosen before performing the mapping. The first option is likely more work, but may be completed before the evaluation begins. The second option is less work, but will produce a suspension of evaluation activity while the necessary evidence is being produced. The objective of this sub-activity is to determine that the implementation representation made available by the developer is suitable for use in other analysis activities; suitability is judged by its conformance to the requirements for this component. The entire implementation representation is made available to ensure that analysis activities are not curtailed due to lack of information. This does not, however, imply that all of the representation is examined in detail when the analysis activities are being performed. This is likely impractical in almost all cases, in addition to the fact that it most likely will not result in a higher-assurance TOE. The new aspect for in comparison to is that the developer needs to demonstrate and the evaluator will confirm that the complete implementation representation is mapped to the TOE design description. This does, however, not imply that all other work units need an examination of the complete implementation representation. Aspects like appropriate level of detail and form of the implementation representation can be covered by sampling as for . the implementation representation; the documentation of the development tools, as resulting from ; the TOE design description. The developer shall make available the implementation representation for the entire TSF. The developer shall provide a mapping between the TOE design description and the entire implementation representation. The implementation representation shall define the TSF to a level of detail such that the TSF may be generated without further design decisions. The implementation representation shall be in the form used by the development personnel. The mapping between the TOE design description and the entire implementation representation shall demonstrate their correspondence. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the implementation representation defines the TSF to a level of detail such that the TSF can be generated without further design decisions. Source code or hardware diagrams and/or IC hardware design language code or layout data that are used to build the actual hardware are examples of parts of an implementation representation. The evaluator samples the implementation representation to gain confidence that it is at the appropriate level and not, for instance, a pseudo-code level which requires additional design decisions to be made. The evaluator is encouraged to perform a quick check when first looking at the implementation representation to assure themselves that the developer is on the right track. However, the evaluator is also encourage to perform the bulk of this check while working on other work units that call for examining the implementation; this will ensure the sample examined for this work unit is relevant. If the evaluator has the possibility to actually execute or witness the "built" procedure used to transfer the implementation representation into the actual implementation, and to compare the result to the TOE as delivered, this may provide an easier and at the same time more reliable check for this work unit (and possibly also for the following one). The evaluator shall check that the implementation representation is in the form used by development personnel. The implementation representation is manipulated by the developer in a form that is suitable for transformation to the actual implementation. For instance, the developer may work with files containing source code, which is eventually compiled to become part of the TSF. The developer makes available the implementation representation in the form they use, so that the evaluator may use automated techniques in the analysis. This also increases the confidence that the implementation representation examined is actually the one used in the production of the TSF (as opposed to the case where it is supplied in an alternate presentation format, such as a word processor document). It should be noted that other forms of the implementation representation may also be used by the developer; these forms are supplied as well. The overall goal is to supply the evaluator with the information that will maximise the evaluator's analysis efforts. The evaluator samples the implementation representation to gain confidence that it is the version that is usable by the developer. The sample is such that the evaluator has assurance that all areas of the implementation representation are in conformance with the requirement; however, a complete examination of the entire implementation representation is unnecessary. Conventions in some forms of the implementation representation may make it difficult or impossible to determine from just the implementation representation itself what the actual result of the compilation or run-time interpretation will be. For example, compiler directives for C language compilers will cause the compiler to exclude or include entire portions of the code. Some forms of the implementation representation may require additional information because they introduce significant barriers to understanding and analysis. Examples include shrouded source code or source code that has been obfuscated in other ways such that it prevents understanding and/or analysis. These forms of implementation representation typically result from by taking a version of the implementation representation that is used by the TOE developer and running a shrouding or obfuscation program on it. While the shrouded representation is what is compiled and may be closer to the implementation (in terms of structure) than the original, un-shrouded representation, supplying such obfuscated code may cause significantly more time to be spent in analysis tasks involving the representation. When such forms of representation are created, the components require details on the shrouding tools/algorithms used so that the un-shrouded representation can be supplied, and the additional information can be used to gain confidence that the shrouding process does not compromise any security mechanisms. The evaluator samples the implementation representation to gain confidence that all of the information needed to interpret the implementation representation has been supplied. Note that the tools are among those referenced by components. The evaluator is encouraged to perform a quick check when first looking at the implementation representation to assure themselves that the developer is on the right track. However, the evaluator is also encouraged to perform the bulk of this check while working on other work units that call for examining the implementation; this will ensure the sample examined for this work unit is relevant. The evaluator shall examine the mapping between the TOE design description and the entire implementation representation to determine that it is accurate. The evaluator augments the determination of existence (specified in work unit ) by verifying the accuracy of the implementation representation and the TOE design description. For those parts of TOE design description that are interesting, the evaluator would verify the implementation representation accurately reflects the description provided in the TOE design description. For example, the TOE design description can identify a login module that is used to identify and authenticate users. If user authentication is sufficiently significant, the evaluator would verify that the corresponding code in fact implements that service as described in the TOE design description. It can also be worthwhile to verify that the code accepts the parameters as described in the functional specification. Usually it will be expected that the evaluator considers at least the functionality required by the SFRs chosen in the ST and aspects described in the security architecture description as "interesting" in the sense discussed above. Note however that not all aspects of the security architecture are necessarily traceable to specific parts of the implementation representation. It is worth pointing out the developer must perform the mapping for the entire implementation representation, thereby guaranteeing that the chosen sample will be covered. The evaluator shall examine the mapping between the TOE design description and the entire implementation representation to determine that it is complete. Note that the completeness here is relevant in both directions: The complete TOE design needs to be covered by the implementation representation and all parts of the implementation representation needs to be mapped to a corresponding part of the TOE design. In order to confirm that the entire implementation representation is covered by the mapping the evaluator will not need to examine the content of every part of the implementation representation. If (in the case of a software TOE) the mapping is for example described by mapping each source code file to a module in the TOE design description, it will be sufficient if this mapping is plausible from the role of the source code file the evaluator can conclude from information like the naming of the source code files, their grouping in subdirectories or their grouping in "built" procedures. Note, that aspects of accuracy are covered by the preceding work unit. In order to confirm that the entire design description is covered by the implementation, the evaluator may either use a similar argument as in the other direction, i. e. that all modules contained in the TOE design description are mapped to parts of the implementation representation in a plausible way. In addition, if the evaluator has established in the preceding work unit that all SFRs and all applicable parts of the security architecture description are traceable to the implementation representation this may be seen as sufficient evidence that the mapping is complete. This family addresses the assessment of the internal structure of the TSF. A TSF whose internals are well-structured is easier to implement and less likely to contain flaws that can lead to vulnerabilities; it is also easier to maintain without the introduction of flaws. The components in this family are levelled on the basis of the amount of structure and minimization of complexity required. places requirements for well-structured internals on only selected parts of the TSF. This component is not included in an EAL because this component is viewed for use in special circumstances (e.g. the sponsor has a specific concern regarding a cryptographic module, which is isolated from the rest of the TSF) and would not be widely applicable. At the next level, the requirements for well-structured internals are placed on the entire TSF. Finally, minimization of complexity is introduced in the highest component. These requirements, when applied to the internal structure of the TSF, typically result in improvements that aid both the developer and the evaluator in understanding the TSF, and also provide the basis for designing and evaluating test suites. Further, improving understandability of the TSF should assist the developer in simplifying its maintainability. The requirements in this family are presented at a fairly abstract level. The wide variety of TOEs makes it impossible to codify anything more specific than "well-structured" or "minimum complexity". Judgements on structure and complexity are expected to be derived from the specific technologies used in the TOE. For example, software is likely to be considered well-structured if it exhibits the characteristics cited in the software engineering disciplines. The components within this family call for identifying the standards for measuring the characteristic of being well-structured and not overly-complex. The objective of this sub-activity is to determine whether the defined subset of the TSF is designed and structured such that the likelihood of flaws is reduced and that maintenance can be more readily performed without the introduction of flaws. The role of the internals description is to provide evidence of the structure of the design and implementation of the TSF. The structure of the design has two aspects: the constituent parts of the TSF and the procedures used to design the TSF. In cases where the TSF is designed in a manner consistent with the design represented by the (see ), the assessment of the TSF design is obvious. In cases where the design procedures (see ) are being followed, the assessment of the TSF design procedures is similarly obvious. In cases where the TSF is implemented using procedure-based software, this structure is assessed on the basis of its modularity; the modules identified in the internals description are the same as the modules identified in . A module consists of one or more source code files that cannot be decomposed into smaller compilable units. The use of the assignment in this component levies stricter constraints on the subset of the TSF that is explicitly identified in the assignment than on the remainder of the TSF. While the entire TSF is to be designed using good engineering principles and result in a well-structured TSF, only the specified subset is specifically analysed for this characteristic. The evaluator determines that the developer's application of coding standards result in a TSF that is understandable. The primary goal of this component is to ensure the TSF subset's implementation representation is understandable to facilitate maintenance and analysis (of both the developer and evaluator). the ST; the TOE design description; the implementation representation (if is part of the claimed assurance); the TSF internals description and justification; the documentation of the coding standards, as resulting from . The developer shall design and implement subset of the TSF such that it has well-structured internals. The developer shall provide an internals description and justification. The justification shall explain the characteristics used to judge the meaning of "well-structured". The TSF internals description shall demonstrate that the assigned subset of the TSF is well-structured. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the justification to determine that it identifies the basis for determining whether the TSF is well-structured. The evaluator verifies that the criteria for determining the characteristic of being well-structured are clearly defined in the justification. Acceptable criteria typically originate from industry standards for the technology discipline. For example, procedural software that executes linearly is traditionally viewed as well-structured if it adheres to software engineering programming practises, such as those defined in the IEEE Standard (IEEE Std 610.12-1990). For example, it would identify the criteria for the procedural software portions of the TSF subset: the process used for modular decomposition; coding standards used in the development of the implementation; a description of the maximum acceptable level of intermodule coupling exhibited by the TSF subset; a description of the minimum acceptable level of cohesion exhibited the modules of the TSF subset. For other types of technologies used in the TOE - such as non-procedural software (e.g. object-oriented programming), widespread commodity hardware (e.g. PC microprocessors), and special-purpose hardware (e.g. smart-card processors) - the evaluator should seek guidance from the evaluation authority for determining the adequacy of criteria for being "well-structured". The evaluator shall check the TSF internals description to determine that it identifies the assigned subset of the TSF. This subset may be identified in terms of the internals of the TSF at any layer of abstraction. For example, it may be in terms of the structural elements of the TSF as identified in the TOE design (e.g. the audit subsystem), or in terms of the implementation (e.g. encrypt.c and decrypt.c files, or the 6227 IC chip). It is insufficient to identify this subset in terms of the claimed SFRs (e.g. the portion of the TSF that provide anonymity as defined in ) because this does not indicate where to focus the analysis. The evaluator shall examine the TSF internals description to determine that it demonstrates that the assigned TSF subset is well-structured. The evaluator examines the internals description to ensure that it provides a sound explanation of how the TSF subset meets the criteria from For example, it would explain how the procedural software portions of the TSF subset meets the following: that there is a one-to-one correspondence between the modules identified in the TSF subset and the modules described in ; how the TSF design is a reflection of the modular decomposition process; a justification for all instances where the coding standards were not used or met; a justification for any coupling or cohesion outside the acceptable bounds. The evaluator shall perform an internals analysis on the assigned subset of the TSF. The evaluator shall determine that the TOE design for the assigned TSF subset is well-structured. The evaluator examines a sample of the TOE design to verify the accuracy of the justification. For example, a sample of the TOE design is analysed to determine its adherence to the design standards, etc. As with all areas where the evaluator performs activities on a subset the evaluator provides a justification of the sample size and scope The description of the TOE's decomposition into subsystems and modules will make the argument that the TSF subset is well-structured self-evident. Verification that the procedures for structuring the TSF (as examined in ) are being followed will make it self-evident that the TSF subset is well-structured. The evaluator shall determine that the assigned TSF subset is well-structured. If is not part of the claimed assurance, then this work unit is not applicable and is therefore considered to be satisfied. The evaluator examines a sample of the TSF subset to verify the accuracy of the internals description. For example, a sample of the procedural software portions of the TSF subset is analysed to determine its cohesion and coupling, its adherence to the coding standards, etc. As with all areas where the evaluator performs activities on a subset the evaluator provides a justification of the sample size and scope. The objective of this sub-activity is to determine whether the TSF is designed and structured such that the likelihood of flaws is reduced and that maintenance can be more readily performed without the introduction of flaws. The role of the internals description is to provide evidence of the structure of the design and implementation of the TSF. The structure of the design has two aspects: the constituent parts of the TSF and the procedures used to design the TSF. In cases where the TSF is designed in a manner consistent with the design represented by the (see ), the assessment of the TSF design is obvious. In cases where the design procedures (see ) are being followed, the assessment of the TSF design procedures is similarly obvious. In cases where the TSF is implemented using procedure-based software, this structure is assessed on the basis of its modularity; the modules identified in the internals description are the same as the modules identified in . A module consists of one or more source code files that cannot be decomposed into smaller compilable units. The primary goal of this component is to ensure the TSF's implementation representation is understandable to facilitate maintenance and analysis (of both the developer and evaluator). the modular design description; the implementation representation (if is part of the claimed assurance); the TSF internals description; the documentation of the coding standards, as resulting from . The developer shall design and implement the entire TSF such that it has well-structured internals. The developer shall provide an internals description and justification. The justification shall describe the characteristics used to judge the meaning of "well-structured". The TSF internals description shall demonstrate that the entire TSF is well-structured. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the justification to determine that it identifies the basis for determining whether the TSF is well-structured. The evaluator verifies that the criteria for determining the characteristic of being well-structured are clearly defined in the justification. Acceptable criteria typically originate from industry standards for the technology discipline. For example, procedural software that executes linearly is traditionally viewed as well-structured if it adheres to software engineering programming practises, such as those defined in the IEEE Standard (IEEE Std 610.12-1990). For example, it would identify the criteria for the procedural software portions of the TSF: the process used for modular decomposition; coding standards used in the development of the implementation; a description of the maximum acceptable level of intermodule coupling exhibited by the TSF; a description of the minimum acceptable level of cohesion exhibited the modules of the TSF. For other types of technologies used in the TOE - such as non-procedural software (e.g. object-oriented programming), widespread commodity hardware (e.g. PC microprocessors), and special-purpose hardware (e.g. smart-card processors) - the evaluation authority should be consulted for determining the adequacy of criteria for being "well-structured". The evaluator shall examine the TSF internals description to determine that it demonstrates that the TSF is well-structured. The evaluator examines the internals description to ensure that it provides a sound explanation of how the TSF meets the criteria from For example, it would explain how the procedural software portions of the TSF meet the following: that there is a one-to-one correspondence between the modules identified in the TSF and the modules described in the ; how the TSF design is a reflection of the modular decomposition process; a justification for all instances where the coding standards were not used or met; a justification for any coupling or cohesion outside the acceptable bounds. The evaluator shall perform an internals analysis on the TSF. The evaluator shall determine that the TOE design is well-structured. The evaluator examines the TOE design of a sample of the TSF to verify the accuracy of the justification. For example, a sample of the TOE design is analysed to determine its adherence to the design standards, etc. As with all areas where the evaluator performs activities on a subset the evaluator provides a justification of the sample size and scope The description of the TOE's decomposition into subsystems and modules will make the argument that the TSF subset is well-structured self-evident. Verification that the procedures for structuring the TSF (as examined in ) are being followed will make it self-evident that the TSF subset is well-structured. The evaluator shall determine that the TSF is well-structured. If is not part of the claimed assurance, then this work unit is not applicable and is therefore considered to be satisfied. The evaluator examines a sample of the TSF to verify the accuracy of the internals description. For example, a sample of the procedural software portions of the TSF is analysed to determine its cohesion and coupling, its adherence to the coding standards, etc. As with all areas where the evaluator performs activities on a subset the evaluator provides a justification of the sample size and scope. The objective of this sub-activity is to determine whether the TSF is designed and structured such that the likelihood of flaws is reduced and that maintenance can be more readily performed without the introduction of flaws. The role of the internals description is to provide evidence of the structure of the design and implementation of the TSF. The structure of the design has two aspects: the constituent parts of the TSF and the procedures used to design the TSF. In cases where the TSF is designed in a manner consistent with the design represented by the (see ), the assessment of the TSF design is obvious. In cases where the design procedures (see ) are being followed, the assessment of the TSF design procedures is similarly obvious. In cases where the TSF is implemented using procedure-based software, this structure is assessed on the basis of its modularity; the modules identified in the internals description are the same as the modules identified in . A module consists of one or more source code files that cannot be decomposed into smaller compilable units. The primary goal of this component is to ensure the TSF's implementation representation is understandable to facilitate maintenance and analysis (of both the developer and evaluator). the modular design description; the implementation representation (if is part of the claimed assurance); the TSF internals description; the documentation of the coding standards, as resulting from . The developer shall design and implement the entire TSF such that it has well-structured internals. The developer shall provide an internals description and justification. The justification shall describe the characteristics used to judge the meaning of "well-structured" and "complex". The TSF internals description shall demonstrate that the entire TSF is well-structured and is not overly complex. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the justification to determine that it identifies the basis for determining whether the TSF is "well-structured" and "not overly complex". The evaluator verifies that the criteria for determining the characteristic of being "well-structured" and "complex" are clearly defined in the justification. Acceptable criteria typically originate from industry standards for the technology discipline. For example, procedural software that executes linearly is traditionally viewed as well-structured if it adheres to software engineering programming practises, such as those defined in the IEEE Standard (IEEE Std 610.12-1990). For example, it would identify the criteria for the procedural software portions of the TSF: the process used for modular decomposition; coding standards used in the development of the implementation; a description of the maximum acceptable level of intermodule coupling exhibited by the TSF; a description of the minimum acceptable level of cohesion exhibited the modules of the TSF. Complexity can for example be measured in the number of decision points and logical paths of execution that code takes. Software engineering literature cites complexity as a negative characteristic of software because it impedes understanding of the logic and flow of the code. Another impediment to the understanding of code is the presence of code that is unnecessary, in that it is unused or redundant. Design complexity minimisation is a key characteristic of a reference validation mechanism, the purpose of which is to arrive at a TSF that is easily understood so that it can be completely analysed. See also CC Part 3, A.3 for additional information on TSF internals. The consideration in that annex and those made in the preceding paragraphs of this work unit are mainly derived from common knowledge about procedural software. For other types of technologies used in the TOE - such as non-procedural software (e.g. object-oriented programming), widespread commodity hardware (e.g. PC microprocessors), and special-purpose hardware (e.g. smart-card processors) - the evaluation authority should be consulted for determining the adequacy of criteria for being "well-structured" and "not overly complex". The evaluator is reminded to be open for plausible definitions given by the developer. If. for example, a smart card developer can justify that the metrics used to measure complexity are an industry standard in their field, this should usually be sufficient for acceptance of such metrics. The evaluator shall examine the TSF internals description to determine that it demonstrates that the TSF is well-structured and not overly complex. The evaluator examines the internals description to ensure that it provides a sound explanation of how the TSF meets the criteria from For example, it would explain how the procedural software portions of the TSF meet the following: that there is a one-to-one correspondence between the modules identified in the TSF and the modules described in the ; how the TSF design is a reflection of the modular decomposition process; a justification for all instances where the coding standards were not used or met; a justification for any coupling or cohesion outside the acceptable bounds; how the modular decomposition process reduces complexity. The evaluator shall perform an internals analysis on the entire TSF. The evaluator shall determine that the entire TOE design is well-structured and not overly complex. The evaluator examines the TOE design description of the TSF to verify the accuracy of the justification. For example, a sample of the TOE design is analysed to determine its adherence to the design standards, etc. As with all areas where the evaluator performs activities on a subset the evaluator provides a justification of the sample size and scope The description of the TOE's decomposition into subsystems and modules will make the argument that the TSF is well-structured self-evident. Verification that the procedures for structuring the TSF (as examined in ) are being followed will make it self-evident that the TSF is well-structured. Using the metrics defined by the developer for measuring the complexity of the design will show if the metrics is met. If the metrics is only defined for the implementation representation and not for the TOE design (note that adequateness of the metrics was considered already in work unit ), there may be no need for using the metrics in this work unit, the complexity-issue is then covered by the next work unit. The evaluator shall determine that the entire TSF is well-structured and not overly complex. If is not part of the claimed assurance, then this work unit is not applicable and is therefore considered to be satisfied. The evaluator examines a sample of the TSF to verify the accuracy of the internals description. For example, a sample of the procedural software portions of the TSF is analysed to determine its cohesion and coupling, its adherence to the coding standards, etc. As with all areas where the evaluator performs activities on a subset the evaluator provides a justification of the sample size and scope. Similarly, the evaluator applies the metric for complexity as defined by the developer and examined in work unit to either a sample of the implementation representation or the complete implementation representation (this may depend on the metric) and verifies that the metric is in fact met. The evaluator may only restrict their application of the metrics to a sample if the developer has provided the results of the application of the metrics for the entire TSF and the sampling serves as means to convince the evaluator that the application as done by the developer was correct (similar to the evaluator's sampling of functional testing already done by the developer). It is the objective of this family to provide additional assurance through the development of a formal representation of the TSF and its properties, as defined by the SFRs and the security objectives of the ST, further referred to as the formal model and the formal properties, respectively. It is expected to establish by means of a formal proof that these formal properties hold in the formal model and to establish by means of a correspondence rationale that the TOE functional specification preserves the formal properties proven for the formal model. A formal proof or semiformal demonstration of preservation of the formal properties in the formal or semiformal specification is expected if the latter exists ( or , respectively). This family contains only one component. Inadequacies in a TOE can result either from a failure in understanding the security requirements or from a flawed implementation of those security requirements. Defining the security requirements adequately to ensure their understanding may be problematic because the definition must be sufficiently precise to prevent undesired results or subtle flaws during the implementation of the TOE. Throughout the design, implementation, and review processes, a formal representation of the TSF and its properties may be used as precise design and implementation guidance, thereby providing increased assurance that the SFRs and the security objectives of the ST are satisfied by the TOE. The resulting guidance and the precision of the TSF representation and its properties, as defined by the SFRs and the security objectives of the ST, are significantly improved by defining the formal model and specifying the formal properties using a formal language and providing a formal proof that these formal properties hold in the formal model. The creation of a formal Security Policy Model (SPM) of the TSF must be complete with respect to the ST; such a model helps to identify and eliminate ambiguous, inconsistent, contradictory, or unenforceable elements and to avoid any misunderstanding on the scope. To this end, the evaluation must determine whether the formal model and the formal properties completely cover the ST and accept only STs and SPMs that match in scope. Once the TOE has been built, the formal model serves the evaluation effort by contributing to the evaluator's judgement of how well the developer has understood the TSF being implemented and whether there are inconsistencies between the formal properties as defined by the security objectives of the ST and the TOE design. The confidence gained by formally proving properties of the model is accompanied by confidence gained by defining a correspondence rationale between the formal model and the TOE functional specification (as defined for ). The correspondence rationale consists of a formal proof when mapping to formal aspects of the TOE functional specification and semiformal demonstration otherwise. A combination of different formal systems (modelling languages, tools, proof systems) can be used for different parts of the ST (SFRs & Security Objectives) and correspondence rationales. The objective of this sub-activity is to determine whether the formal model and its formal properties clearly and consistently represent the TSF and the TOE, as defined by the SFRs and the security objectives for the TOE of the ST. This activity applies to cases where the developer has provided a formal Security Policy Model (SPM) of the TSF. A formal security model is a formal representation of the essential aspects of security, i.e. the TSF and their relationship to the behaviour of the TOE. More specifically, the formal model is a formal representation of the TSF as defined by the complete set of SFRs described in the ST. The set of formal properties covers all the security objectives for the TOE. The creation of a formal Security Policy Model (SPM) of the TSF must be complete with respect to the ST; such a model helps to identify and eliminate ambiguous, inconsistent, contradictory, or unenforceable elements and to avoid any misunderstanding related to the scope. To this end, the evaluation must determine whether the formal model and the formal properties completely cover the ST and accept only STs and SPMs that match in scope. Once the TOE has been built, the formal model serves the evaluation effort by contributing to the evaluator's judgement of how well the developer has understood the TSF being implemented and whether there are inconsistencies between the formal properties as defined by the security objectives for the TOE of the ST and the TOE itself. The confidence gained by formally proving properties of the model is accompanied by confidence gained by defining a correspondence rationale between the formal model and the TSF functional specification (as defined for ). The correspondence rationale consists of a formal proof when mapping to formal aspects of the TSF functional specification and semiformal demonstration otherwise. A combination of different formal systems (modelling languages, tools, proof systems) can be used for different parts of the ST (SFRs & Security Objectives) and correspondence rationales. the ST; the functional specification; the formal model for the TSF and the supporting explanatory text (); the set of formal properties for the TOE and the supporting explanatory text (); the formal proof that the model satisfies the formal properties and the supporting explanatory text (); a correspondence rationale between the formal model and the functional specification (); a semiformal demonstration of correspondence between the formal model and any semiformal functional specification (); a formal proof of correspondence between the formal model and any formal functional specification (); all the tools used for the formal model, the formal properties, proofs and demonstrations (.7D). The developer shall provide a formal model for the TSF supported by explanatory text. The developer shall provide the set of formal properties for the TOE supported by explanatory text. The developer shall provide a formal proof that the model satisfies the formal properties supported by explanatory text. The developer shall provide a correspondence rationale between the formal model and the functional specification. The developer shall provide a semi-formal demonstration of correspondence between the formal model and any semi-formal functional specification. The developer shall provide a formal proof of correspondence between the formal model and any formal functional specification. The formal model, properties and proofs shall be defined using a well-founded mathematical theory. The explanatory text shall cover the entire formal model, formal properties and proofs, including instructions for reproducing the proofs and the correspondence rationale, and it shall provide a rationale for the modeling and verification choices. The formal model shall cover the complete set of SFRs that define the TSF. The formal properties shall cover the complete set of security objectives for the TOE. The formal proof shall show that the formal model satisfies all the formal properties and that the consistency of the underlying mathematical theory is preserved. The correspondence rationale shall show that the formal properties proven for the formal model hold for the functional specification. The semi-formal demonstration of correspondence shall show that the formal properties proven for the formal model hold for any semi-formal functional specification. The formal proof of correspondence shall show that the properties proven for the formal model hold for any formal functional specification. Any tool used to model or to prove the formal properties or the relationship between the formal model and the functional specification shall be well-defined and unambiguously identified and it shall be accompanied by documentation and a rationale of the tool's suitability and trustworthiness. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the formal model, the formal properties and the formal proofs to determine that their expression relies on a well-founded syntax and semantics. This work unit consists of verifying and ensuring the well-foundedness of the underlying mathematical concepts used for expressing the formal model and for proving its formal properties and formal correspondence to the FSP (if applicable). The evaluator identifies the mathematical concepts upon which the formal model, properties and proofs are based and gathers relevant scientific bibliography in the context of the evaluation, e.g. on the basis of the provided description of used tools and additional references. This literature research should facilitate the identification of "pitfalls" that would allow the introduction of paradoxes and/or fallacies. The evaluator confirms that the underlying mathematical concepts are well-founded. This work unit applies to all the different mathematical theories that are used to provide the formal model, properties and proofs. The evaluator shall examine the explanatory text to determine that it explains all parts of the formal model, properties and proofs including the unproven assertions, the chosen verification strategy and the instructions needed to reproduce the proofs and the correspondence rationale. This work unit consists in examining the explanatory text to determine that it describes all parts of the formal model for all parts of the TSF, the formal properties for all the security objectives for the TOE and the formal proofs, and that it justifies the adopted modelling and verification strategy. The explanatory text consists of supporting descriptions and clarifications, for example, the formal notation and its usage, or the formal/mathematical representation of the concepts. The explanatory text covers all the unproven assertions on which the formal model or the formal proof rely, and identifies all the formal model and formal proof elements which correspond to the security objectives concerning the TOE environment. The explanatory text is expected to provide sufficient details to enable the identification of all parts of the formal model and all the formal properties as well as the correct understanding of the formal model, the properties, the proofs and the reasoning behind the modelling and verification choices. The explanatory text is expected to support the correspondence between formal and natural language concepts and properties as stated in the ST and functional specification. Note: Comments included directly in the source code of the formal model or proofs can help but they do not exclude provision of the explanatory text itself and are instead complementary to the latter. The evaluator shall examine the formal model, the definition of the SFRs, and the explanatory text, to determine that the formal model covers the complete set of SFRs defined in the ST. In determining completeness of the formal model, the evaluator maps the elements of the SFRs to the formal model's elements. Omission of any SFR from the formal modelling leads to a fail verdict being assigned to this work unit. The evaluator shall examine the formal model, the definition of the SFRs and the explanatory text to determine that the formal model provides an accurate representation of the SFRs. This work unit consists in determining whether the formal model provides an accurate representation of the SFRs. The evaluator examines the SFRs, the formal model, and the explanatory text to establish the accuracy of the correspondence between the formal concepts and the definition of the SFRs. In determining accuracy, the evaluator verifies that the definition of the SFRs is reflected within the formal model and that the explanatory text describing each formal element in the model accurately addresses the concepts and the intent of the corresponding SFR. The evaluator also ensures that the formal model defines a representation of the TSF that is appropriate for the statement of the formal properties to be proven. The formal model aims to cover the entire set of SFRs, which goes beyond access and flow control policies stated by means of and components. All the SFRs defined in the ST are concerned, including, for example, non-repudiation, privacy or authentication SFRs. The formal model and the definition of the SFRs may use different abstractions. This does not affect the accuracy of the formal model if the formal properties are not affected. A TSF that is formally modelled on the basis of state transitions would include a definition of the states, identify the initial state(s), describe the necessary conditions to move from one state to the next, and characterize the secure state(s). In the presence of formal properties related to authentication, if SFRs state that access control is necessary to the granularity of a single individual, then a formal model describing the TSF behaviour in the context of controlling groups of users would not be accurate. The evaluator shall examine the formal properties, the security objectives for the TOE and the explanatory text to determine that the formal properties cover the complete set of security objectives for the TOE defined in the ST. In determining completeness of the formal properties, the evaluator maps the elements of the security objectives for the TOE to the elements of the formal properties' statements. Omission of any security objective from the formally proven properties of the TOE always leads to a fail verdict being assigned to this work unit. The evaluator shall examine the definition of the formal properties to determine that they accurately represent the security objectives for the TOE as given in the ST. This work unit consists in determining whether the formal properties provide an accurate representation of the security objectives for the TOE. The evaluator examines the definition of the security objectives for the TOE, the formal model, the formal properties, and the explanatory text to establish the accuracy of the correspondence between the formal and the informal concepts. The evaluator shall reproduce the formal proof by following the instructions provided by the developer as part of the explanatory text and confirm that the obtained results are identical. This work unit consists in determining that mathematical proof of the formal properties exists and is reproducible, that is, in verifying the formal proof itself, using the instructions and tools provided by the developer. The evaluator checks whether the explanatory text for the formal proof contains step-by-step instructions that are applicable and lead to results that are identical to those provided by the developer. The evaluator reproduces the formal proof using the formal model, the tools and the instructions supplied by the developer, and manually checks all the formal proofs provided on paper. The evaluator shall examine the formal proof to determine that the formal model satisfies all the formal properties and that the consistency of the underlying mathematical theory is preserved. This work unit consists in determining that mathematical proof exists that the formal model satisfies the entire set of formal properties and that a state which does not preserve the formal properties cannot be reached. The evaluator relies on the formal proof, the explanatory text and on the principles of the underlying formal theory and its implementation to determine that the consistency of the underlying mathematical theory is preserved. The evaluator checks whether the explanatory text contains sufficient details for understanding the formal proof and all the unproven assertions that are used to conduct the proof. The evaluator determines that none of the unproven assertions used in the proof invalidate the well-foundedness of the underlying formal theory. By doing this, the evaluator determines that the formal model enforces the formal properties and that the arguments used in the formal proof are valid and do not lead to contradictions. The evaluator shall examine the correspondence rationale to determine that all the formal properties proven to be satisfied by the formal model hold for the functional specification. This work unit consists in verifying that the functional specification reflects all the concepts and formal properties which are modelled and proven to hold in the formal model. The correspondence rationale provided by the developer is expected to provide tables, diagrams and/or explanatory text to describe the relationship between the entire functional specification and the formal model. The evaluator examines the correspondence rationale to determine whether there is sufficient evidence to conclude that the formal properties satisfied by the formal model hold in the functional specification. Establishing whether the abstraction used for modelling the TSF is relevant is an essential part of evaluating the rationale behind the preservation of the model's formal properties by the functional specification. Therefore, the evaluator shall examine the correspondence rationale to determine whether the abstraction level used for the formal model and properties is appropriate. This is particularly true in the context of in which case the evaluator must make a judgement regarding the abstraction relevance of the formal model without the support of formal proofs. If the functional specification does not contain a semiformal description, this work unit is not applicable and is therefore considered to be satisfied. Otherwise, the evaluator shall check that the semiformal demonstration of correspondence shows that the formal properties proven for the formal model hold in the semiformal functional specification. A semiformal demonstration of correspondence is one that results from a structured approach with a substantial degree of rigor (in terms of completeness and correctness), but is not as rigorous as a mathematical proof. Such a semiformal correspondence limits the subjective interpretations of its terms, and so it provides less ambiguity than would exist in an informal correspondence. The evaluator examines the semiformal proof of correspondence to determine whether there is sufficient evidence to conclude that the formal properties satisfied by the formal model hold in the semi-formal functional specification. To this end, the evaluator uses the tools provided by the developer. If the functional specification does not contain a formal description, this work unit is not applicable and is therefore considered to be satisfied. Otherwise, the evaluator shall verify that the formal proof of correspondence shows that the formal properties proven for the formal model hold in the formal functional specification. A formal proof of correspondence removes all subjective interpretations of its terms by enlisting well-established mathematical concepts to define the syntax and semantics of the formal notation and the proof rules that support logical reasoning. The evaluator examines the formal proof of correspondence to determine whether there is sufficient evidence to conclude that the formal properties satisfied by the formal model hold in the formal functional specification. To this end, the evaluator reproduces the formal correspondence proof by using the tools provided by the developer. For a paper proof, the evaluator verifies the proof manually. The evaluator shall examine whether an unambiguous identification of the tools used for formal modelling and proofs and semiformal demonstrations (if applicable) is provided by the developer and determine whether the presented results can be reproduced with the identified tools. The documentation of the tools is included in the evaluator's examination. The evaluator verifies that the tools versions and the environment in which they were used are unambiguously identified by the developer. The evaluator checks that the identified tools versions are not subject to known soundness problems. The evaluator checks whether the results obtained with the identified tools are identical to those provided by the developer. The evaluator shall determine the consistency of the analysis of the suitability and trustworthiness of the formal modelling, proof and demonstration tools. The evaluator shall ensure that the tools have a sound mathematical foundation. This work unit consists in examining the consistency of the rationale provided for the suitability and trustworthiness of the used tools. The evaluator determines whether the formal theory is consistent with its implementation in the tools. For example, it can be the case that there are slight deviations in the interpretations of certain syntax elements between the mathematical definition and the implementation in the tools. The evaluator examines the consistency of all the modelling and verification tools used. For example, the developer can use a modelling tool A for state-charts to express the semantics of the system and an interactive theorem prover B to verify its formal properties. In between, there is a translation from the output format of A to the representation used by/input format of B. In addition to examining the correctness of this twofold approach, the soundness of the mapping and translation from the output format of A to the representation used by/input format of B must be examined too. One can manually insert modelling errors to show that the formalism is indeed capable of detecting flaws. However, the capability to detect such flaws is necessary but not sufficient. The evaluator shall examine the documentation of the tools used for formal modelling and proofs and for semiformal demonstrations (if applicable) to determine that it unambiguously defines the meaning of all statements, all model- and proof-dependent options, as well as all conventions and directives used. The tools documentation should cover all statements used in the formal models, proofs and demonstrations, and for each such statement should provide a clear and unambiguous definition of the purpose and effect of that statement. This work should be performed in parallel with the evaluator's examination of the semiformal and formal models and specifications. The critical test is whether the evaluator can understand the source code of the semiformal or formal models, proofs and demonstrations (if applicable). For any identified tool, the evaluator checks whether: any terms, abbreviations and acronyms that are used in a context other than that accepted by normal usage are defined; the notation used provides rules to determine the meaning of syntactical valid constructs. For any identified tool used for formal modelling and proofs, the evaluator determines whether: its semantics is well-defined; it uses a formal syntax that provides rules to unambiguously recognise constructs; it supports logical reasoning using well-established mathematical concepts; it helps to prevent misuse and the introduction of contradictions by issuing warnings or hints, rejecting invalid constructions or providing specific instructions within the usage manual. The design description of a TOE provides both context for a description of the TSF, and a thorough description of the TSF. As assurance needs increase, the level of detail provided in the description also increases. As the size and complexity of the TSF increase, multiple levels of decomposition are appropriate. The design requirements are intended to provide information (commensurate with the given assurance level) so that a determination can be made that the SFRs are realized. The components in this family are levelled on the basis of the amount of information that is required to be presented with respect to the TSF, and on the degree of formalism required of the design description. The goal of design documentation is to provide sufficient information to determine the TSF boundary, and to describe how the TSF implements the SFRs. The amount and structure of the design documentation will depend on the complexity of the TOE and the number of SFRs; in general, a very complex TOE with a large number of SFRs will require more design documentation than a very simple TOE implementing only a few SFRs. Very complex TOEs will benefit (in terms of the assurance provided) from the production of differing levels of decomposition in describing the design, while very simple TOEs do not require both high-level and low-level descriptions of its implementation. This family uses two levels of decomposition: the subsystem and the module. A module is the most specific description of functionality: it is a description of the implementation. A developer should be able to implement the part of the TOE described by the module with no further design decisions. A subsystem is a description of the design of the TOE; it helps to provide a high-level description of what a portion of the TOE is doing and how. As such, a subsystem may be further divided into lower-level subsystems, or into modules. Very complex TOEs can require several levels of subsystems in order to adequately convey a useful description of how the TOE works. Very simple TOEs, in contrast, might not require a subsystem level of description; the module can clearly describe how the TOE works. The general approach adopted for design documentation is that, as the level of assurance increases, the emphasis of description shifts from the general (subsystem level) to more (module level) detail. In cases where a module-level of abstraction is appropriate because the TOE is simple enough to be described at the module level, yet the level of assurance calls for a subsystem level of description, the module-level description alone will suffice. For complex TOEs, however, this is not the case: an enormous amount of (module-level) detail would be incomprehensible without an accompanying subsystem level of description. This approach follows the general paradigm that providing additional detail about the implementation of the TSF will result in greater assurance that the SFRs are implemented correctly and provide information that can be used to demonstrate this in testing . In the requirements for this family, the term interface is used as the means of communication (between two subsystems or modules). It describes how the communication is invoked; this is similar to the details of TSFI (see ). The term interaction is used to identify the purpose for communication; it identifies why two subsystems or modules are communicating. The requirements define collections of details about subsystems and modules to be provided: The subsystems and modules are identified with a simple list of what they are. Subsystems and modules may be categorised (either implicitly or explicitly) as "SFR-enforcing", "SFR-supporting", or "SFR-non-interfering"; these terms are used the same as they are used in . A subsystem's behaviour is what it does. The behaviour may also be categorised as SFR-enforcing, SFR-supporting, or SFR-non-interfering. The behaviour of the subsystem is never categorised as more SFR-relevant than the category of the subsystem itself. For example, an SFR-enforcing subsystem can have SFR-enforcing behaviour as well as SFR-supporting or SFR-non-interfering behaviour. A behaviour summary of a subsystem is an overview of the actions it performs (e.g. "The TCP subsystem assembles IP datagrams into reliable byte streams"). A behaviour description of a subsystem is an explanation of everything it does. This description should be at a level of detail that one can readily determine whether the behaviour has any relevance to the enforcement of the SFRs. A description of interactions among or between subsystems or modules identifies the reason that subsystems or modules communicate and characterizes the information that is passed. It need not define the information to the same level of detail as an interface specification. For example, it would be sufficient to say "subsystem X requests a block of memory from the memory manager, which responds with the location of the allocated memory". A description of interfaces provides the details of how the interactions among modules are achieved. Rather than describing the reason the modules are communicating or the purpose of their communication (i.e. the description of interactions), the description of interfaces describes the details of how that communication is accomplished, in terms of the structure and contents of the messages, semaphores, internal process communications. The purpose describes how a module provides their functionality. It provides sufficient detail that no further design decisions are needed. The correspondence between the implementation representation that implements the module, and the purpose of the module should be readily apparent. A module is otherwise described in terms of whatever is identified in the element. Subsystems and modules, and "SFR-enforcing" are all further explained in greater detail in A.4, : Subsystems and Modules. the ST; the functional specification; security architecture description; the TOE design. The developer shall provide the design of the TOE. The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design. The design shall describe the structure of the TOE in terms of subsystems. The design shall identify all subsystems of the TSF. The design shall provide the behaviour summary of each SFR-supporting or SFR-non-interfering TSF subsystem. The design shall summarize the SFR-enforcing behaviour of the SFR-enforcing subsystems. The design shall provide a description of the interactions among SFR-enforcing subsystems of the TSF, and between the SFR-enforcing subsystems of the TSF and other subsystems of the TSF. The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE design to determine that the structure of the entire TOE is described in terms of subsystems. The evaluator ensures that all of the subsystems of the TOE are identified. This description of the TOE will be used as input to work unit , where the parts of the TOE that make up the TSF are identified. That is, this requirement is on the entire TOE rather than on only the TSF. The TOE (and TSF) may be described in multiple layers of abstraction (i.e. subsystems and modules). Depending upon the complexity of the TOE, its design may be described in terms of subsystems and modules, as described in CC Part 3, Annex A.4, . At this level of assurance, the decomposition only need be at the "subsystem" level. In performing this activity, the evaluator examines other evidence presented for the TOE (e.g., ST, operator user guidance) to determine that the description of the TOE in such evidence is consistent with the description contained in the TOE design. The evaluator shall examine the TOE design to determine that all subsystems of the TSF are identified. In work unit all of the subsystems of the TOE were identified, and a determination made that the non-TSF subsystems were correctly characterised. Building on that work, the subsystems that were not characterised as non-TSF subsystems should be precisely identified. The evaluator determines that, of the hardware and software installed and configured according to the guidance, each subsystem has been accounted for as either one that is part of the TSF, or one that is not. If TSFs are defined in terms of sub-TSFs for multi assurance the evaluator shall examine that the combination of all sub-TSF is consistent and does not omit relevant information for each sub-TSF considering the relevant decomposition level. The evaluator shall examine the TOE design to determine that each SFR-supporting or SFR-non-interfering subsystem of the TSF is described such that the evaluator can determine that the subsystem is SFR-supporting or SFR-non-interfering. SFR-supporting and SFR-non-interfering subsystems do not need to be described in detail as to how they function in the system. However, the evaluator makes a determination, based on the evidence provided by the developer, that the subsystems that do not have high-level descriptions are SFR-supporting or SFR-non-interfering. Note that if the developer provides a uniform level of detailed documentation then this work unit will be largely satisfied, since the point of categorising the subsystems is to allow the developer to provide less information for SFR-supporting and SFR-non-interfering subsystems than for SFR-enforcing subsystems. An SFR-supporting subsystem is one that is depended on by an SFR-enforcing subsystem in order to implement an SFR, but does not play as direct a role as an SFR-enforcing subsystem. An SFR-non-interfering subsystem is one that is not depended upon, in either a supporting or enforcing role, to implement an SFR. The evaluator shall examine the TOE design to determine that it provides a complete, accurate, and high-level summary of the SFR-enforcing behaviour of the SFR-enforcing subsystems. The developer may designate subsystems as SFR-enforcing, SFR-supporting, and SFR non-interfering, but these "tags" are used only to describe the amount and type of information the developer must provide, and can be used to limit the amount of information the developer has to develop if their engineering process does not produce the documentation required. Whether the subsystems have been categorised by the developer or not, it is the evaluator's responsibility to determine that the subsystems have the appropriate information for their role (SFR-enforcing, SFR-supporting, or SFR non- interfering) in the TOE, and to obtain the appropriate information from the developer should the developer fail to provide the required information for a particular subsystem. SFR-enforcing behaviour refers to how a subsystem provides the functionality that implements an SFR. The goal of evaluator's assessment is to give the evaluator with an understanding of the way each SFR-enforcing subsystem works. The information provided for the behaviour summary does not have to be as detailed as that provided by the behaviour description. For example, data structures or data items will likely not need to be described in detail. It is the evaluator's determination, however, with respect to what "high-level" means for a particular TOE, and the evaluator obtains enough information from the developer (even if it turns out to be equivalent to information provided for subsystem behaviour) to make a sound verdict for this work unit. The evaluator is cautioned, however, that "perfect" assurance is not a goal nor required by this work unit, so judgement will have to be exercised in determine the amount and composition of the evidence required to make a verdict on this work unit. To determine completeness and accuracy, the evaluator examines other information available (e.g., functional specification, security architecture description). Summaries of functionality in these documents should be consistent with what is provided for evidence for this work unit. The evaluator shall examine the TOE design to determine that interactions between the subsystems of the TSF are described. The goal of describing the interactions between the SFR-enforcing subsystems and other subsystems is to help provide the reader a better understanding of how the TSF performs it functions. These interactions do not need to be characterised at the implementation level (e.g., parameters passed from one routine in a subsystem to a routine in a different subsystem; global variables; hardware signals (e.g., interrupts) from a hardware subsystem to an interrupt-handling subsystem), but the data elements identified for a particular subsystem that are going to be used by another subsystem need to be covered in this discussion. Any control relationships between subsystems (e.g., a subsystem responsible for configuring a rule base for a firewall system and the subsystem that actually implements these rules) should also be described. The evaluators need to use their own judgement in assessing the completeness of the description. If the reason for an interaction is unclear, or if there are SFR-related interactions (discovered, for instance, in examining the descriptions of subsystem behaviour) that do not appear to be described, the evaluator ensures that this information is provided by the developer. However, if the evaluator can determine that interactions among a particular set of subsystems, while incompletely described by the developer, will not aid in understanding the overall functionality nor security functionality provided by the TSF, then the evaluator may choose to consider the description sufficient, and not pursue completeness for its own sake. The evaluator shall examine the TOE design to determine that it contains a complete and accurate mapping from the TSFI described in the functional specification to the subsystems of the TSF described in the TOE design. The subsystems described in the TOE design provide a description of how the TSF works at a detailed level for SFR-enforcing portions of the TSF, and at a higher level for other portions of the TSF. The TSFI provide a description of how the implementation is exercised. The evidence from the developer identifies the subsystem that is initially involved when an operation is requested at the TSFI, and identify the various subsystems that are primarily responsible for implementing the functionality. Note that a complete "call tree" for each TSFI is not required for this work unit. The evaluator assesses the completeness of the mapping by ensuring that all of the TSFI map to at least one subsystem. The verification of accuracy is more complex. The first aspect of accuracy is that each TSFI is mapped to a subsystem at the TSF boundary. This determination can be made by reviewing the subsystem description and interactions, and from this information determining its place in the architecture. The next aspect of accuracy is that the mapping makes sense. For instance, mapping a TSFI dealing with access control to a subsystem that checks passwords is not accurate. The evaluator should again use judgement in making this determination. The goal is that this information aids the evaluator in understanding the system and implementation of the SFRs, and ways in which entities at the TSF boundary can interact with the TSF. The bulk of the assessment of whether the SFRs are described accurately by the subsystems is performed in other work units. The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements. The evaluator shall examine the TOE security functional requirements and the TOE design, to determine that all ST security functional requirements are covered by the TOE design. The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were implemented in specific places within fifteen modules, it would be inadequate for the evaluator to map to one subsystem and claim the work unit had been completed. Instead, the evaluator would map (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A, behaviours x, p, and q; etc. The evaluator shall examine the TOE design to determine that it is an accurate instantiation of all security functional requirements. The evaluator ensures that each security requirement listed in the TOE security functional requirements subclause of the ST has a corresponding design description in the TOE design that accurately details how the TSF meets that requirement. This requires that the evaluator identify a collection of subsystems that are responsible for implementing a given functional requirement, and then examine those subsystems to understand how the requirement is implemented. Finally, the evaluator would assess whether the requirement was accurately implemented. As an example, if the ST requirements specified a role-based access control mechanism, the evaluator would first identify the subsystems that contribute to this mechanism's implementation. This can be done by in-depth knowledge or understanding of the TOE design or by work done in the previous work unit. Note that this trace is only to identify the subsystems, and is not the complete analysis. The next step would be to understand what mechanism the subsystems implemented. For instance, if the design described an implementation of access control based on UNIX-style protection bits, the design would not be an accurate instantiation of those access control requirements present in the ST example used above. If the evaluator cannot determine that the mechanism was accurately implemented because of a lack of detail, the evaluator would have to assess whether all of the SFR-enforcing subsystems have been identified, or if adequate detail had been provided for those subsystems. the ST; the functional specification; security architecture description; the TOE design. The developer shall provide the design of the TOE. The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design. The design shall describe the structure of the TOE in terms of subsystems. The design shall identify all subsystems of the TSF. The design shall provide the behaviour summary of each SFR non-interfering subsystem of the TSF. The design shall describe the SFR-enforcing behaviour of the SFR-enforcing subsystems. The design shall summarize the SFR-supporting and SFR-non-interfering behaviour of the SFR-enforcing subsystems. The design shall summarize the behaviour of the SFR-supporting subsystems. The design shall provide a description of the interactions among all subsystems of the TSF. The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE design to determine that the structure of the entire TOE is described in terms of subsystems. The evaluator ensures that all of the subsystems of the TOE are identified. This description of the TOE will be used as input to work unit , where the parts of the TOE that make up the TSF are identified. That is, this requirement is on the entire TOE rather than on only the TSF. The TOE (and TSF) may be described in multiple layers of abstraction (i.e. subsystems and modules). Depending upon the complexity of the TOE, its design may be described in terms of subsystems and modules, as described in CC Part 3, Annex A.4, . At this level of assurance, the decomposition only need be at the "subsystem" level. In performing this activity, the evaluator examines other evidence presented for the TOE (e.g., ST, operator user guidance) to determine that the description of the TOE in such evidence is consistent with the description contained in the TOE design. The evaluator shall examine the TOE design to determine that all subsystems of the TSF are identified. In work unit all of the subsystems of the TOE were identified, and a determination made that the non-TSF subsystems were correctly characterised. Building on that work, the subsystems that were not characterised as non-TSF subsystems should be precisely identified. The evaluator determines that, of the hardware and software installed and configured according to the guidance, each subsystem has been accounted for as either one that is part of the TSF, or one that is not. The evaluator shall examine the TOE design to determine that each SFR-non-interfering subsystem of the TSF is described such that the evaluator can determine that the subsystem is SFR-non-interfering. SFR-non-interfering subsystems do not need to be described in detail as to how they function in the system. However, the evaluator makes a determination, based on the evidence provided by the developer, that the subsystems that do not have detailed descriptions are SFR-non-interfering. Note that if the developer provides a uniform level of detailed documentation then this work unit will be largely satisfied, since the point of categorising the subsystems is to allow the developer to provide less information for SFR-non-interfering subsystems than for SFR-enforcing and SFR-supporting subsystems. An SFR-non-interfering subsystem is one on which the SFR-enforcing and SFR-supporting subsystems have no dependence; that is, they play no role in implementing SFR functionality. The evaluator shall examine the TOE design to determine that it provides a complete, accurate, and detailed description of the SFR-enforcing behaviour of the SFR-enforcing subsystems. The developer may designate subsystems as SFR-enforcing, SFR-supporting, and SFR non-interfering, but these "tags" are used only to describe the amount and type of information the developer must provide, and can be used to limit the amount of information the developer has to develop if their engineering process does not produce the documentation required. Whether the subsystems have been categorised by the developer or not, it is the evaluator's responsibility to determine that the subsystems have the appropriate information for their role (SFR-enforcing, SFR-supporting, or SFR non-interfering) in the TOE, and to obtain the appropriate information from the developer should the developer fail to provide the required information for a particular subsystem. SFR-enforcing behaviour refers to how a subsystem provides the functionality that implements an SFR. While not at the level of an algorithmic description, a detailed description of behaviour typically discusses how the functionality is provided in terms of what key data and data structures are, what control relationships exist within a subsystem, and how these elements work together to provide the SFR-enforcing behaviour. Such a description also references SFR-supporting behaviour, which the evaluator should consider in performing subsequent work units. To determine completeness and accuracy, the evaluator examines other information available (e.g., functional specification, security architecture description). Descriptions of functionality in these documents should be consistent with what is provided for evidence for this work unit. The evaluator shall examine the TOE design to determine that it provides a complete and accurate high-level summary of the SFR-supporting and SFR-non-interfering behaviour of the SFR-enforcing subsystems. The developer may designate subsystems as SFR-enforcing, SFR-supporting, and SFR non-interfering, but these "tags" are used only to describe the amount and type of information the developer must provide, and can be used to limit the amount of information the developer has to develop if their engineering process does not produce the documentation required. Whether the subsystems have been categorised by the developer or not, it is the evaluator's responsibility to determine that the subsystems have the appropriate information for their role (SFR-enforcing, SFR-supporting, or SFR non-interfering) in the TOE, and to obtain the appropriate information from the developer should the developer fail to provide the required information for a particular subsystem. In contrast to the previous work unit, this work unit calls for the evaluator to assess the information provided for SFR-enforcing subsystems that is SFR-supporting or SFR-non-interfering. The goal of this assessment is two-fold. First, it should provide the evaluator greater understanding of the way each subsystem works. Second, this assessment will help the evaluator to determine that all SFR-enforcing behaviour exhibited by a SFR-enforcing subsystem has been described. Unlike the previous work unit, the information provided for the SFR-supporting or SFR-non-interfering behaviour does not have to be as detailed as that provided by the SFR-enforcing behaviour. For example, data structures or data items that do not pertain to SFR-enforcing functionality will likely not need to be described in detail, if at all. It is the evaluator's determination, however, with respect to what "high-level" means for a particular TOE, and the evaluator obtains enough information from the developer (even if it turns out to be equivalent to information provided for the parts of the subsystem that are SFR-enforcing) to make a sound verdict for this work unit. The evaluator is cautioned, however, that "perfect" assurance is not a goal nor required by this work unit, so judgement will have to be exercised in determine the amount and composition of the evidence required to make a verdict on this work unit. To determine completeness and accuracy, the evaluator examines other information available (e.g., functional specification, security architecture description). Summaries of functionality in these documents should be consistent with what is provided for evidence for this work unit. In particular, the functional specification should be used to determine that the behaviour required to implement the TSF Interfaces described by the functional specification are completely described by the subsystem, since the behaviour will either be SFR-enforcing, SFR-supporting or SFR-non-interfering. The evaluator shall examine the TOE design to determine that it provides a complete and accurate high-level summary of the behaviour of the SFR-supporting subsystems. The developer may designate subsystems as SFR-enforcing, SFR-supporting, and SFR non-interfering, but these "tags" are used only to describe the amount and type of information the developer must provide, and can be used to limit the amount of information the developer has to develop if their engineering process does not produce the documentation required. Whether the subsystems have been categorised by the developer or not, it is the evaluator's responsibility to determine that the subsystems have the appropriate information for their role (SFR-enforcing, SFR-supporting, or SFR non-interfering) in the TOE, and to obtain the appropriate information from the developer should the developer fail to provide the required information for a particular subsystem. In contrast to the previous two work units, this work unit calls for the developer to provide (and the evaluator to assess) information about SFR supporting subsystems. Such subsystems should be referenced by the descriptions of the SFR-enforcing subsystems, as well as by the descriptions of interactions in work unit . The goal of evaluator's assessment, like that for the previous work unit, is two-fold. First, it should provide the evaluator with an understanding of the way each SFR-supporting subsystem works. Second, the evaluator determines that the behaviour is summarized in enough detail so that the way in which the subsystem supports the SFR-enforcing behaviour is clear, and that the behaviour is not itself SFR-enforcing. The information provided for SFR-supporting subsystem's behaviour does not have to be as detailed as that provided by the SFR-enforcing behaviour. For example, data structures or data items that do not pertain to SFR-enforcing functionality will likely not need to be described in detail, if at all. It is the evaluator's determination, however, with respect to what "high-level" means for a particular TOE, and the evaluator obtains enough information from the developer (even if it turns out to be equivalent to information provided for the parts of the subsystem that are SFR-enforcing) to make a sound verdict for this work unit. The evaluator is cautioned, however, that "perfect" assurance is not a goal nor required by this work unit, so judgement will have to be exercised in determine the amount and composition of the evidence required to make a verdict on this work unit. To determine completeness and accuracy, the evaluator examines other information available (e.g., functional specification, security architecture description). Summaries of functionality in these documents should be consistent with what is provided for evidence for this work unit. The evaluator shall examine the TOE design to determine that interactions between the subsystems of the TSF are described. The goal of describing the interactions between the subsystems is to help provide the reader a better understanding of how the TSF performs it functions. These interactions do not need to be characterised at the implementation level (e.g., parameters passed from one routine in a subsystem to a routine in a different subsystem; global variables; hardware signals (e.g., interrupts) from a hardware subsystem to an interrupt-handling subsystem), but the data elements identified for a particular subsystem that are going to be used by another subsystem need to be covered in this discussion. Any control relationships between subsystems (e.g., a subsystem responsible for configuring a rule base for a firewall system and the subsystem that actually implements these rules) should also be described. It should be noted while the developer should characterise all interactions between subsystems, the evaluators need to use their own judgement in assessing the completeness of the description. If the reason for an interaction is unclear, or if there are SFR-related interactions (discovered, for instance, in examining the descriptions of subsystem behaviour) that do not appear to be described, the evaluator ensures that this information is provided by the developer. However, if the evaluator can determine that interactions among a particular set of subsystems, while incompletely described by the developer, will not aid in understanding the overall functionality nor security functionality provided by the TSF, then the evaluator may choose to consider the description sufficient, and not pursue completeness for its own sake. The evaluator shall examine the TOE design to determine that it contains a complete and accurate mapping from the TSFI described in the functional specification to the subsystems of the TSF described in the TOE design. The subsystems described in the TOE design provide a description of how the TSF works at a detailed level for SFR-enforcing portions of the TSF, and at a higher level for other portions of the TSF. The TSFI provide a description of how the implementation is exercised. The evidence from the developer identifies the subsystem that is initially involved when an operation is requested at the TSFI, and identify the various subsystems that are primarily responsible for implementing the functionality. Note that a complete "call tree" for each TSFI is not required for this work unit. The evaluator assesses the completeness of the mapping by ensuring that all of the TSFI map to at least one subsystem. The verification of accuracy is more complex. The first aspect of accuracy is that each TSFI is mapped to a subsystem at the TSF boundary. This determination can be made by reviewing the subsystem description and interactions, and from this information determining its place in the architecture. The next aspect of accuracy is that the mapping makes sense. For instance, mapping a TSFI dealing with access control to a subsystem that checks passwords is not accurate. The evaluator should again use judgement in making this determination. The goal is that this information aids the evaluator in understanding the system and implementation of the SFRs, and ways in which entities at the TSF boundary can interact with the TSF. The bulk of the assessment of whether the SFRs are described accurately by the subsystems is performed in other work units. The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements. The evaluator shall examine the TOE security functional requirements and the TOE design, to determine that all ST security functional requirements are covered by the TOE design. The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were implemented in specific places within fifteen modules, it would be inadequate for the evaluator to map to one subsystem and claim the work unit had been completed. Instead, the evaluator would map (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A, behaviours x, p, and q; etc. The evaluator shall examine the TOE design to determine that it is an accurate instantiation of all security functional requirements. The evaluator ensures that each security requirement listed in the TOE security functional requirements subclause of the ST has a corresponding design description in the TOE design that accurately details how the TSF meets that requirement. This requires that the evaluator identify a collection of subsystems that are responsible for implementing a given functional requirement, and then examine those subsystems to understand how the requirement is implemented. Finally, the evaluator would assess whether the requirement was accurately implemented. As an example, if the ST requirements specified a role-based access control mechanism, the evaluator would first identify the subsystems that contribute to this mechanism's implementation. This can be done by in-depth knowledge or understanding of the TOE design or by work done in the previous work unit. Note that this trace is only to identify the subsystems, and is not the complete analysis. The next step would be to understand what mechanism the subsystems implemented. For instance, if the design described an implementation of access control based on UNIX-style protection bits, the design would not be an accurate instantiation of those access control requirements present in the ST example used above. If the evaluator cannot determine that the mechanism was accurately implemented because of a lack of detail, the evaluator would have to assess whether all of the SFR-enforcing subsystems have been identified, or if adequate detail had been provided for those subsystems. The objective of this sub-activity is to determine whether the TOE design provides a description of the TOE in terms of subsystems sufficient to determine the TSF boundary, and provides a description of the TSF internals in terms of modules (and optionally higher-level abstractions). It provides a detailed description of the SFR-enforcing modules and enough information about the SFR-supporting and SFR-non-interfering modules for the evaluator to determine that the SFRs are completely and accurately implemented; as such, the TOE design provides an explanation of the implementation representation. There are three types of activity that the evaluator must undertake with respect to the TOE design. First, the evaluator determines that the TSF boundary has been adequately described. Second, the evaluator determines that the developer has provided documentation that conforms to the content and presentation requirements for this subsystem, and that is consistent with other documentation provided for the TOE. Finally, the evaluator must analyse the design information provided for the SFR-enforcing modules (at a detailed level) and the SFR-supporting and SFR-non-interfering modules (at a less detailed level) to understand how the system is implemented, and with that knowledge ensure that the TSFI in the functional specification are adequately described, and that the test information adequately tests the TSF (done in work units). It is important to note that while the developer is obligated to provide a complete description of the TSF (although SFR-enforcing modules will have more detail than the SFR-supporting or SFR-non-interfering modules), the evaluator is expected to use their judgement in performing their analysis. While the evaluator is expected to look at every module, the detail to which they examine each module may vary. The evaluator analyses each module in order to gain enough understanding to determine the effect of the functionality of the module on the security of the system, and the depth to which they need to analyse the module may vary depending on the module's role in the system. An important aspect of this analysis is that the evaluator should use the other documentation provided (TSS, functional specification, security architecture description, and the TSF internal document) in order to determine that the functionality that is described is correct, and that the implicit designation of SFR-supporting or SFR-non-interfering modules (see below) is supported by their role in the system architecture. The developer may designate modules as SFR-enforcing, SFR-supporting, and SFR non-interfering, but these "tags" are used only to describe the amount and type of information the developer must provide, and can be used to limit the amount of information the developer has to develop if their engineering process does not produce the documentation required. Whether the modules have been categorised by the developer or not, it is the evaluator's responsibility to determine that the modules have the appropriate information for their role (SFR-enforcing, SFR-supporting, or SFR non-interfering) in the TOE, and to obtain the appropriate information from the developer should the developer fail to provide the required information for a particular module. the ST; the functional specification; security architecture description; the TOE design. The developer shall provide the design of the TOE. The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design. The design shall describe the structure of the TOE in terms of subsystems. The design shall describe the TSF in terms of modules. The design shall identify all subsystems of the TSF. The design shall provide a description of each subsystem of the TSF. The design shall provide a description of the interactions among all subsystems of the TSF. The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF. The design shall describe each SFR-enforcing module in terms of its purpose and relationship with other modules. The design shall describe each SFR-enforcing module in terms of its SFR-related interfaces, return values from those interfaces, interaction with other modules and called SFR-related interfaces to other SFR-enforcing modules. The design shall describe each SFR-supporting and SFR-non-interfering module in terms of its purpose and interaction with other modules. The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE design to determine that the structure of the entire TOE is described in terms of subsystems. The evaluator ensures that all of the subsystems of the TOE are identified. This description of the TOE will be used as input to work unit , where the parts of the TOE that make up the TSF are identified. That is, this requirement is on the entire TOE rather than on only the TSF. The TOE (and TSF) may be described in multiple layers of abstraction (i.e. subsystems and modules). Depending upon the complexity of the TOE, its design may be described in terms of subsystems and modules, as described in CC Part 3, Annex A.4, . For a very simple TOE that can be described solely at the "module" level (see ), this work unit is not applicable and therefore considered to be satisfied. In performing this activity, the evaluator examines other evidence presented for the TOE (e.g., ST, operator user guidance) to determine that the description of the TOE in such evidence is consistent with the description contained in the TOE design. The evaluator shall examine the TOE design to determine that the entire TSF is described in terms of modules. The evaluator will examine the modules for specific properties in other work units; in this work unit the evaluator determines that the modular description covers the entire TSF, and not just a portion of the TSF. The evaluator uses other evidence provided for the evaluation (e.g., functional specification, security architecture description) in making this determination. For example, if the functional specification contains interfaces to functionality that does not appear to be described in the TOE design description, it may be the case that a portion of the TSF has not been included appropriately. Making this determination will likely be an iterative process, whereas more analysis is done on the other evidence, more confidence can be gained with respect to the completeness of the documentation. Unlike subsystems, modules describe the implementation in a level of detail that can serve as a guide to reviewing the implementation representation. A description of a module should be such that one can create an implementation of the module from the description, and the resulting implementation would be 1) identical to the actual TSF implementation in terms of the interfaces presented, 2) identical in the use of interfaces that are mentioned in the design, and 3) functionally equivalent to the description of the purpose of the TSF module. For instance, RFC 793 provides a high-level description of the TCP protocol. It is necessarily implementation independent. While it provides a wealth of detail, it is not a suitable design description because it is not specific to an implementation. An actual implementation can add to the protocol specified in the RFC, and implementation choices (for instance, the use of global data vs. local data in various parts of the implementation) may have an impact on the analysis that is performed. The design description of the TCP module would list the interfaces presented by the implementation (rather than just those defined in RFC 793), as well as an algorithm description of the processing associated with the modules implementing TCP (assuming it was part of the TSF). The evaluator shall examine the TOE design to determine that all subsystems of the TSF are identified. If the design is presented solely in terms of modules, then subsystems in these requirements are equivalent to modules and the activity should be performed at the module level. In work unit all of the subsystems of the TOE were identified, and a determination made that the non-TSF subsystems were correctly characterised. Building on that work, the subsystems that were not characterised as non-TSF subsystems should be precisely identified. The evaluator determines that, of the hardware and software installed and configured according to the guidance, each subsystem has been accounted for as either one that is part of the TSF, or one that is not. The evaluator shall examine the TOE design to determine that each subsystem of the TSF describes its role in the enforcement of SFRs described in the ST. If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case. On systems that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the goal of the subsystem-level description is to give the evaluator context for the modular description that follows. Therefore, the evaluator ensures that the subsystem-level description contains a description of how the security functional requirements are achieved in the design, but at a level of abstraction above the modular description. This description should discuss the mechanisms used at a level that is aligned with the module description; this will provide the evaluators the road map needed to intelligently assess the information contained in the module description. A well-written set of subsystem descriptions will help guide the evaluator in determining the modules that are most important to examine, thus focusing the evaluation activity on the portions of the TSF that have the most relevance with respect to the enforcement of the SFRs. The evaluator ensures that all subsystems of the TSF have a description. While the description should focus on the role that the subsystem plays in enforcing or supporting the implementation of the SFRs, enough information must be present so that a context for understanding the SFR-related functionality is provided. The evaluator shall examine the TOE design to determine that each SFR-non-interfering subsystem of the TSF is described such that the evaluator can determine that the subsystem is SFR-non-interfering. If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case. An SFR-non-interfering subsystem is one on which the SFR-enforcing and SFR-supporting subsystems have no dependence; that is, they play no role in implementing SFR functionality. The evaluator ensures that all subsystems of the TSF have a description. While the description should focus on the role that the subsystem does not play in enforcing or supporting the implementation of the SFRs, enough information must be present so that a context for understanding the SFR-non-interfering functionality is provided. The evaluator shall examine the TOE design to determine that interactions between the subsystems of the TSF are described. If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case. On systems that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the goal of describing the interactions between the subsystems is to help provide the reader a better understanding of how the TSF performs its functions. These interactions do not need to be characterised at the implementation level (e.g., parameters passed from one routine in a subsystem to a routine in a different subsystem; global variables; hardware signals (e.g., interrupts) from a hardware subsystem to an interrupt-handling subsystem), but the data elements identified for a particular subsystem that are going to be used by another subsystem should be covered in this discussion. Any control relationships between subsystems (e.g., a subsystem responsible for configuring a rule base for a firewall system and the subsystem that actually implements these rules) should also be described. It should be noted while the developer should characterise all interactions between subsystems, the evaluators need to use their own judgement in assessing the completeness of the description. If the reason for an interaction is unclear, or if there are SFR-related interactions (discovered, for instance, in examining the module-level documentation) that do not appear to be described, the evaluator ensures that this information is provided by the developer. However, if the evaluator can determine that interactions among a particular set of subsystems, while incompletely described by the developer, and a complete description will not aid in understanding the overall functionality nor security functionality provided by the TSF, then the evaluator may choose to consider the description sufficient, and not pursue completeness for its own sake. The evaluator shall examine the TOE design to determine that the mapping between the subsystems of the TSF and the modules of the TSF is complete. If the design is presented solely in terms of modules, then this work unit is considered satisfied. For TOEs that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the developer provides a simple mapping showing how the modules of the TSF are allocated to the subsystems. This will provide the evaluator a guide in performing their module-level assessment. To determine completeness, the evaluator examines each mapping and determines that all subsystems map to at least one module, and that all modules map to exactly one subsystem. The evaluator shall examine the TOE design to determine that the mapping between the subsystems of the TSF and the modules of the TSF is accurate. If the design is presented solely in terms of modules, then this work unit is considered satisfied. For TOEs that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the developer provides a simple mapping showing how the modules of the TSF are allocated to the subsystems. This will provide the evaluator a guide in performing their module-level assessment. The evaluator may choose to check the accuracy of the mapping in conjunction with performing other work units. An "inaccurate" mapping is one where the module is mistakenly associated with a subsystem where its functions are not used within the subsystem. Because the mapping is intended to be a guide supporting more detailed analysis, the evaluator is cautioned to apply appropriate effort to this work unit. Expending extensive evaluator resources verifying the accuracy of the mapping is not necessary. Inaccuracies that lead to misunderstandings related to the design that are uncovered as part of this or other work units are the ones that should be associated with this work unit and corrected. The evaluator shall examine the TOE design to determine that the description of the purpose of each SFR-enforcing module and relationship with other modules is complete and accurate. The developer may designate modules as SFR-enforcing, SFR-supporting, and SFR non-interfering, but these "tags" are used only to describe the amount and type of information the developer must provide, and can be used to limit the amount of information the developer has to develop if their engineering process does not produce the documentation required. Whether the modules have been categorised by the developer or not, it is the evaluator's responsibility to determine that the modules have the appropriate information for their role (SFR-enforcing, SFR-supporting, or SFR non-interfering) in the TOE, and to obtain the appropriate information from the developer should the developer fail to provide the required information for a particular module. The purpose of a module provides a description indicating what function the module is fulfilling. A word of caution to evaluator is in order. The focus of this work unit should be to provide the evaluator an understanding of how the module works so that determinations can be made about the soundness of the implementation of the SFRs, as well as to support architectural analysis performed for component. As long as the evaluator has a sound understanding of the module's operation, and its relationship to other modules and the TOE as a whole, the evaluator should consider the objective of the work achieved and not engage in a documentation exercise for the developer (by requiring, for example, a complete algorithmic description for a self-evident implementation representation). Because the modules are at such a low level, it may be difficult determine completeness and accuracy impacts from other documentation, such as operational user guidance, the functional specification, the TSF internals, or the security architecture description. However, the evaluator uses the information present in those documents to the extent possible to help ensure that the purpose is accurately and completely described. This analysis can be aided by the analysis performed for the work units for the element, which maps the TSFI in the functional specification to the modules of the TSF. The evaluator shall examine the TOE design to determine that the description of the interfaces presented by each SFR-enforcing module contain an accurate and complete description of the SFR-related parameters, the calling conventions for each interface, and any values returned directly by the interface. The SFR-related interfaces of a module are those interfaces used by other modules as a means to invoke the SFR-related operations provided, and to provide inputs to or receive outputs from the module. The purpose in the specification of these interfaces is to permit the exercise of them during testing. Inter-module interfaces that are not SFR-related need not be specified or described, since they are not a factor in testing. Likewise, other internal interfaces that are not a factor in traversing SFR-related paths of execution (such as those internal paths that are fixed) need not be specified or described, since they are not a factor in testing. SFR-related interfaces are described in terms of how they are invoked, and any values that are returned. This description would include a list of SFR-related parameters, and descriptions of these parameters. Note that global data would also be considered parameters if used by the module (either as inputs or outputs) when invoked. If a parameter were expected to take on a set of values (e.g., a "flag" parameter), the complete set of values the parameter can take on that would have an effect on module processing would be specified. Likewise, parameters representing data structures are described such that each field of the data structure is identified and described. Note that different programming languages may have additional "interfaces" that would be non-obvious; an example would be operator/function overloading in C++. This "implicit interface" in the class description would also be described as part of the low-level TOE design. Note that although a module can present only one interface, it is more common that a module presents a small set of related interfaces. In terms of the assessment of parameters (inputs and outputs) to a module, any use of global data must also be considered. A module "uses" global data if it either reads or writes the data. In order to assure the description of such parameters (if used) is complete, the evaluator uses other information provided about the module in the TOE design (interfaces, algorithmic description, etc.), as well as the description of the particular set of global data assessed in work unit . For instance, the evaluator can first determine the processing the module performs by examining its function and interfaces presented (particularly the parameters of the interfaces). They can then check to see if the processing appears to "touch" any of the global data areas identified in the TOE design. The evaluator then determines that, for each global data area that appears to be "touched", that global data area is listed as a means of input or output by the module the evaluator is examining. Invocation conventions are a programming-reference-type description that one can use to correctly invoke a module's interface if one were writing a program to make use of the module's functionality through that interface. This includes necessary inputs and outputs, including any set-up that may need to be performed with respect to global variables. Values returned through the interface refer to values that are either passed through parameters or messages; values that the function call itself returns in the style of a "C" program function call; or values passed through global means (such as certain error routines in *ix-style operating systems). In order to assure the description is complete, the evaluator uses other information provided about the module in the TOE design (e.g., algorithmic description, global data used) to ensure that it appears all data necessary for performing the functions of the module is presented to the module, and that any values that other modules expect the module under examination to provide are identified as being returned by the module. The evaluator determines accuracy by ensuring that the description of the processing matches the information listed as being passed to or from an interface. The evaluator shall examine the TOE design to determine that SFR-supporting and SFR-non-interfering modules are correctly categorised. In the cases where the developer has provided different amounts of information for different modules, an implicit categorisation has been done. That is, modules (for instance) with detail presented on their SFR-related interfaces (see ) are candidate SFR-enforcing modules, although examination by the evaluator may lead to a determination that some set of them are SFR-supporting or SFR-non-interfering. Those with only a description of their purpose and interaction with other modules (for instance) are "implicitly categorised" as SFR-supporting or SFR-non-interfering. In these cases, a key focus of the evaluator for this work unit is attempting to determine from the evidence provided for each module implicitly categorised as SFR-supporting or SFR-non-interfering and the evaluation information about other modules (in the TOE design, the functional specification, the security architecture description, and the operational user guidance), whether the module is indeed SFR-supporting or SFR-non-interfering. At this level of assurance some error should be tolerated; the evaluator does not have to be absolutely sure that a given module is SFR-supporting or SFR-non-interfering, even though it is labelled as such. However, if the evidence provided indicates that a SFR-supporting or SFR-non-interfering module is SFR-enforcing, the evaluator requests additional information from the developer in order to resolve the apparent inconsistency. For instance, suppose the documentation for Module A (an SFR-enforcing module) indicates that it calls Module B to perform an access check on a certain type of construct. When the evaluator examines the information associated with Module B, they find that all the developer has provided is a purpose and a set of interactions (thus implicitly categorising Module B as SFR-supporting or SFR-non-interfering). On examining the purpose and interactions from Module A, the evaluator finds no mention of Module B performing any access checks, and Module A is not listed as a module with which Module B interacts. At this point the evaluator should approach the developer to resolve the discrepancies between the information provided in Module A and that in Module B. Another example would be where the evaluator examines the mapping of the TSFI to the modules as provided by . This examination shows that Module C is associated with an SFR requiring identification of the user. Again, when the evaluator examines the information associated with Module C, they find that all the developer has provided is a purpose and a set of interactions (thus implicitly categorising Module C as SFR-supporting or SFR-non-interfering). Examining the purpose and interactions presented for Module C, the evaluator is unable to determine why Module C, listed as mapping to a TSFI concerned with user identification, would not be classified as SFR-enforcing. Again, the evaluator should approach the developer to resolve this discrepancy. A final example is from the opposite point of view. As before, the developer has provided information associated with Module D consisting of a purpose and a set of interactions (thus implicitly categorising Module D as SFR-supporting or SFR-non-interfering). The evaluator examines all of the evidence provided, including the purpose and interactions for Module D. The purpose appears to give a meaningful description of Module D's function in the TOE, the interactions are consistent with that description, and there is nothing to indicate that Module D is SFR-enforcing. In this case, the evaluator should not demand more information about Module D "just to be sure" it is correctly categorised. The developer has met their obligations and the resulting assurance the evaluator has in the implicit categorisation of Module D is (by definition) appropriate for this assurance level. The evaluator shall examine the TOE design to determine that the description of the purpose of each SFR-supporting or SFR-non-interfering module is complete and accurate. The description of the purpose of a module indicates what function the module is fulfilling. From the description, the evaluator should be able to obtain a general idea of the module's role. In order to assure the description is complete, the evaluator uses the information provided about the module's interactions with other modules to assess whether the reasons for the module being called are consistent with the module's purpose. If the interaction description contains functionality that is not apparent from, or in conflict with, the module's purpose, the evaluator needs to determine whether the problem is one of accuracy or of completeness. The evaluator should be wary of purposes that are too short, since meaningful analysis based on a one-sentence purpose is likely to be impossible. Because the modules are at such a low level, it may be difficult determine completeness and accuracy impacts from other documentation, such as administrative guidance, the functional specification, the security architecture description, or the TSF internals document. However, the evaluator uses the information present in those documents to the extent possible to help ensure that the function is accurately and completely described. This analysis can be aided by the analysis performed for the work units for the element, which maps the TSFI in the functional specification to the modules of the TSF. The evaluator shall examine the TOE design to determine that the description of an SFR-supporting or SFR-non-interfering module's interaction with other modules is complete and accurate. It is important to note that, in terms of the Part 3 requirement and this work unit, the term interaction is intended to convey less rigour than interface. An interaction does not need to be characterised at the implementation level (e.g., parameters passed from one routine in a module to a routine in a different module; global variables; hardware signals (e.g., interrupts) from a hardware subsystem to an interrupt-handling subsystem), but the data elements identified for a particular module that are going to be used by another module should be covered in this discussion. Any control relationships between modules (e.g., a module responsible for configuring a rule base for a firewall system and the module that actually implements these rules) should also be described. Because the modules are at such a low level, it may be difficult determine completeness and accuracy impacts from other documentation, such as operational user guidance, the functional specification, the security architecture description, or the TSF internals document. However, the evaluator uses the information present in those documents to the extent possible to help ensure that the function is accurately and completely described. This analysis can be aided by the analysis performed for the work units for the element, which maps the TSFI in the functional specification to the modules of the TSF. A module's interaction with other modules goes beyond just a call-tree-type document. The interaction is described from a functional perspective of why a module interacts with other modules. The module's purpose describes what functions the module provides to other modules; the interactions should describe what the module depends on from other modules in order to accomplish this function. The evaluator shall examine the TOE design to determine that it contains a complete and accurate mapping from the TSFI described in the functional specification to the modules of the TSF described in the TOE design. The modules described in the TOE design provide a description of the implementation of the TSF. The TSFI provide a description of how the implementation is exercised. The evidence from the developer identifies the module that is initially invoked when an operation is requested at the TSFI, and identifies the chain of modules invoked up to the module that is primarily responsible for implementing the functionality. However, a complete call tree for each TSFI is not required for this work unit. The cases in which more than one module would have to be identified are where there are "entry point" modules or wrapper modules that have no functionality other than conditioning inputs or de-multiplexing an input. Mapping to one of these modules would not provide any useful information to the evaluator. The evaluator assesses the completeness of the mapping by ensuring that all of the TSFI map to at least one module. The verification of accuracy is more complex. The first aspect of accuracy is that each TSFI is mapped to a module at the TSF boundary. This determination can be made by reviewing the module description and its interfaces/interactions. The next aspect of accuracy is that each TSFI identifies a chain of modules between the initial module identified and a module that is primarily responsible for implementing the function presented at the TSF. Note that this may be the initial module, or there may be several modules, depending on how much pre-conditioning of the inputs is done. It should be noted that one indicator of a pre-conditioning module is that it is invoked for a large number of the TSFI, where the TSFI are all of similar type (e.g., system call). The final aspect of accuracy is that the mapping makes sense. For instance, mapping a TSFI dealing with access control to a module that checks passwords is not accurate. The evaluator should again use judgement in making this determination. The goal is that this information aids the evaluator in understanding the system and implementation of the SFRs, and ways in which entities at the TSF boundary can interact with the TSF. The bulk of the assessment of whether the SFRs are described accurately by the modules is performed in other work units. The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements. The evaluator shall examine the TOE security functional requirements and the TOE design, to determine that all ST security functional requirements are covered by the TOE design. The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems, and later to modules. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were implemented in specific places within fifteen modules, it would be inadequate for the evaluator to map to one subsystem and claim the work unit had been completed. Instead, the evaluator would map (rule 1) to modules x, y, and z of subsystem A; (rule 2) to modules x, p, and q of subsystem A; etc. The evaluator shall examine the TOE design to determine that it is an accurate instantiation of all security functional requirements. The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. As an example, if the ST requirements specified a role-based access control mechanism, the evaluator would first identify the subsystems, and modules that contribute to this mechanism's implementation. This can be done by in-depth knowledge or understanding of the TOE design or by work done in the previous work unit. Note that this trace is only to identify the subsystems, and modules, and is not the complete analysis. The next step would be to understand what mechanism the subsystems, and modules implemented. For instance, if the design described an implementation of access control based on UNIX-style protection bits, the design would not be an accurate instantiation of those access control requirements present in the ST example used above. If the evaluator cannot determine that the mechanism was accurately implemented because of a lack of detail, the evaluator would have to assess whether all of the SFR-enforcing subsystems and modules have been identified, or if adequate detail had been provided for those subsystems and modules. The objective of this sub-activity is to determine whether the TOE design provides a description of the TOE in terms of subsystems sufficient to determine the TSF boundary, and provides a description of the TSF internals in terms of modules (and optionally higher-level abstractions). It provides a detailed description of the SFR-enforcing and SFR-supporting modules and enough information about the SFR-non-interfering modules for the evaluator to determine that the SFRs are completely and accurately implemented; as such, the TOE design provides an explanation of the implementation representation. There are three types of activity that the evaluator must undertake with respect to the TOE design. First, the evaluator determines that the TSF boundary has been adequately described. Second, the evaluator determines that the developer has provided documentation that conforms to the content and presentation requirements this subsystem, and that is consistent with other documentation provided for the TOE. Finally, the evaluator must analyse the design information provided for the SFR-enforcing modules (at a detailed level) and the SFR-supporting and SFR-non-interfering modules (at a less detailed level) to understand how the system is implemented, and with that knowledge ensure that the TSFI in the functional specification are adequately described, and that the test information adequately tests the TSF (done in the work units). the ST; the functional specification; security architecture description; the TOE design. The developer shall provide the design of the TOE. The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design. The design shall describe the structure of the TOE in terms of subsystems. The design shall describe the TSF in terms of modules, designating each module as SFR-enforcing, SFR-supporting, or SFR-non-interfering. The design shall identify all subsystems of the TSF. The design shall provide a semiformal description of each subsystem of the TSF, supported by informal, explanatory text where appropriate. The design shall provide a description of the interactions among all subsystems of the TSF. The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF. The design shall describe each SFR-enforcing and SFR-supporting module in terms of its purpose and relationship with other modules. The design shall describe each SFR-enforcing and SFR-supporting module in terms of its SFR-related interfaces, return values from those interfaces, interaction with other modules and called SFR-related interfaces to other SFR-enforcing or SFR-supporting modules. The design shall describe each SFR-non-interfering module in terms of its purpose and interaction with other modules. The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE design to determine that the structure of the entire TOE is described in terms of subsystems. The evaluator ensures that all of the subsystems of the TOE are identified. This description of the TOE will be used as input to work unit , where the parts of the TOE that make up the TSF are identified. That is, this requirement is on the entire TOE rather than on only the TSF. The TOE (and TSF) may be described in multiple layers of abstraction (i.e. subsystems and modules). Depending upon the complexity of the TOE, its design may be described in terms of subsystems and modules, as described in CC Part 3, Annex A.4, . For a very simple TOE that can be described solely at the "module" level (see ), this work unit is not applicable and therefore considered to be satisfied. In performing this activity, the evaluator examines other evidence presented for the TOE (e.g., ST, operator user guidance) to determine that the description of the TOE in such evidence is consistent with the description contained in the TOE design. The evaluator shall examine the TOE design to determine that the entire TSF is described in terms of modules. The evaluator will examine the modules for specific properties in other work units; in this work unit the evaluator determines that the modular description covers the entire TSF, and not just a portion of the TSF. The evaluator uses other evidence provided for the evaluation (e.g., functional specification, architectural description) in making this determination. For example, if the functional specification contains interfaces to functionality that does not appear to be described in the TOE design description, it may be the case that a portion of the TSF has not been included appropriately. Making this determination will likely be an iterative process, whereas more analysis is done on the other evidence, more confidence can be gained with respect to the completeness of the documentation. Unlike subsystems, modules describe the implementation in a level of detail that can serve as a guide to reviewing the implementation representation. A description of a module should be such that one can create an implementation of the module from the description, and the resulting implementation would be 1) identical to the actual TSF implementation in terms of the interfaces presented, 2) identical in the use of interfaces that are mentioned in the design, and 3) functionally equivalent to the description of the purpose of the TSF module. For instance, RFC 793 provides a high-level description of the TCP protocol. It is necessarily implementation independent. While it provides a wealth of detail, it is not a suitable design description because it is not specific to an implementation. An actual implementation can add to the protocol specified in the RFC, and implementation choices (for instance, the use of global data vs. local data in various parts of the implementation) may have an impact on the analysis that is performed. The design description of the TCP module would list the interfaces presented by the implementation (rather than just those defined in RFC 793), as well as an algorithm description of the processing associated with the modules implementing TCP (assuming it was part of the TSF). The evaluator shall check the TOE design to determine that the TSF modules are identified as either SFR-enforcing, SFR-supporting, or SFR-non-interfering. The purpose of designating each module (according to the role a particular module plays in the enforcement of the SFRs) is to allow developers to provide less information about the parts of the TSF that have little role in security. It is always permissible for the developer to provide more information or detail than the requirements demand, as can occur when the information has been gathered outside the evaluation context. In such cases the developer must still designate the modules as either SFR-enforcing, SFR-supporting, or SFR-non-interfering. The accuracy of these designations is continuously reviewed as the evaluation progresses. The concern is the mis-designation of modules as being less important (and hence, having less information) than is really the case. While blatant mis-designations may be immediately apparent (e.g., designating an authentication module as anything but SFR-enforcing when is one of the SFRs being claimed), other mis-designations might not be discovered until the TSF is better understood. The evaluator must therefore keep in mind that these designations are the developer's initial best effort, but are subject to change. Further guidance is provided under work unit , which examines the accuracy of these designations. The evaluator shall examine the TOE design to determine that all subsystems of the TSF are identified. If the design is presented solely in terms of modules, then subsystems in these requirements are equivalent to modules and the activity should be performed at the module level. In work unit all of the subsystems of the TOE were identified, and a determination made that the non-TSF subsystems were correctly characterised. Building on that work, the subsystems that were not characterised as non-TSF subsystems should be precisely identified. The evaluator determines that, of the hardware and software installed and configured according to the guidance, each subsystem has been accounted for as either one that is part of the TSF, or one that is not. The evaluator shall examine the TDS documentation to determine that the semiformal notation used for describing the subsystems, modules and their interfaces is defined or referenced. A semiformal notation can be either defined by the sponsor or a corresponding standard be referenced. The evaluator should provide a mapping of security functions and their interfaces outlining in what part of the documentation a function or interface is semiformal described and what notation is used. The evaluator examines all semiformal notations used to make sure that they are of a semiformal style and to justify the appropriateness of the manner how the semiformal notations are used for the TOE. The evaluator is reminded that a semi-formal presentation is characterised by a standardised format with a well-defined syntax that reduces ambiguity that may occur in informal presentations. The syntax of all semiformal notations used in the functional specification shall be defined or a corresponding standard be referenced. The evaluator verifies that the semiformal notations used for expressing the functional specification are capable of expressing features relevant to security. In order to determine this, the evaluator can refer to the SFR and compare the TSF security features stated in the ST and those described in the FSP using the semiformal notations. The evaluator shall examine the TOE design to determine that each subsystem of the TSF describes its role in the enforcement of SFRs described in the ST. If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case. On systems that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the goal of the subsystem-level description is to give the evaluator context for the modular description that follows. Therefore, the evaluator ensures that the subsystem-level description contains a description of how the security functional requirements are achieved in the design, but at a level of abstraction above the modular description. This description should discuss the mechanisms used at a level that is aligned with the module description; this will provide the evaluators the road map needed to intelligently assess the information contained in the module description. A well-written set of subsystem descriptions will help guide the evaluator in determining the modules that are most important to examine, thus focusing the evaluation activity on the portions of the TSF that have the most relevance with respect to the enforcement of the SFRs. The evaluator ensures that all subsystems of the TSF have a description. While the description should focus on the role that the subsystem plays in enforcing or supporting the implementation of the SFRs, enough information must be present so that a context for understanding the SFR-related functionality is provided. The evaluator shall examine the TOE design to determine that each SFR-non-interfering subsystem of the TSF is described such that the evaluator can determine that the subsystem is SFR-non-interfering. If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case. An SFR-non-interfering subsystem is one on which the SFR-enforcing and SFR-supporting subsystems have no dependence; that is, they play no role in implementing SFR functionality. The evaluator ensures that all subsystems of the TSF have a description. While the description should focus on the role that the subsystem does not play in enforcing or supporting the implementation of the SFRs, enough information must be present so that a context for understanding the SFR-non-interfering functionality is provided. The evaluator shall examine the TOE design to determine that interactions between the subsystems of the TSF are described. If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case. On systems that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the goal of describing the interactions between the subsystems is to help provide the reader a better understanding of how the TSF performs it functions. These interactions do not need to be characterised at the implementation level (e.g., parameters passed from one routine in a subsystem to a routine in a different subsystem; global variables; hardware signals (e.g., interrupts) from a hardware subsystem to an interrupt-handling subsystem), but the data elements identified for a particular subsystem that are going to be used by another subsystem need to be covered in this discussion. Any control relationships between subsystems (e.g., a subsystem responsible for configuring a rule base for a firewall system and the subsystem that actually implements these rules) should also be described. It should be noted while the developer should characterise all interactions between subsystems, the evaluators need to use their own judgement in assessing the completeness of the description. If the reason for an interaction is unclear, or if there are SFR-related interactions (discovered, for instance, in examining the module-level documentation) that do not appear to be described, the evaluator ensures that this information is provided by the developer. However, if the evaluator can determine that interactions among a particular set of subsystems, while incompletely described by the developer, and a complete description will not aid in understanding the overall functionality nor security functionality provided by the TSF, then the evaluator may choose to consider the description sufficient, and not pursue completeness for its own sake. The evaluator shall examine the TOE design to determine that the mapping between the subsystems of the TSF and the modules of the TSF is complete. If the design is presented solely in terms of modules, then this work unit is considered satisfied. For TOEs that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the developer provides a simple mapping showing how the modules of the TSF are allocated to the subsystems. This will provide the evaluator a guide in performing their module-level assessment. To determine completeness, the evaluator examines each mapping and determines that all subsystems map to at least one module, and that all modules map to exactly one subsystem. The evaluator shall examine the TOE design to determine that the mapping between the subsystems of the TSF to the modules of the TSF is accurate. If the design is presented solely in terms of modules, then this work unit is considered satisfied. For TOEs that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the developer provides a simple mapping showing how the modules of the TSF are allocated to the subsystems. This will provide the evaluator a guide in performing their module-level assessment. The evaluator may choose to check the accuracy of the mapping in conjunction with performing other work units. An "inaccurate" mapping is one where the module is mistakenly associated with a subsystem where its functions are not used within the subsystem. Because the mapping is intended to be a guide supporting more detailed analysis, the evaluator is cautioned to apply appropriate effort to this work unit. Expending extensive evaluator resources verifying the accuracy of the mapping is not necessary. Inaccuracies that lead to misunderstandings related to the design that are uncovered as part of this or other work units are the ones that should be associated with this work unit and corrected. The evaluator shall examine the TOE design to determine that the description of the purpose of each SFR-enforcing and SFR-supporting module, and relationship with other modules is complete and accurate. The developer may designate modules as SFR-enforcing, SFR-supporting, and SFR non-interfering, but these "tags" are used only to describe the amount and type of information the developer must provide, and can be used to limit the amount of information the developer has to develop if their engineering process does not produce the documentation required. Whether the modules have been categorised by the developer or not, it is the evaluator's responsibility to determine that the modules have the appropriate information for their role (SFR-enforcing, SFR-supporting, or SFR non-interfering) in the TOE, and to obtain the appropriate information from the developer should the developer fail to provide the required information for a particular module. The purpose of a module provides a description indicating what function the module is fulfilling. A word of caution to evaluator is in order. The focus of this work unit should be to provide the evaluator an understanding of how the module works so that determinations can be made about the soundness of the implementation of the SFRs, as well as to support architectural analysis performed for subsystems. As long as the evaluator has a sound understanding of the module's operation, and its relationship to other modules and the TOE as a whole, the evaluator should consider the objective of the work achieved and not engage in a documentation exercise for the developer (by requiring, for example, a complete algorithmic description for a self-evident implementation representation). Because the modules are at such a low level, it may be difficult determine completeness and accuracy impacts from other documentation, such as operational user guidance, the functional specification, the TSF internals, or the security architecture description. However, the evaluator uses the information present in those documents to the extent possible to help ensure that the purpose is accurately and completely described. This analysis can be aided by the analysis performed for the work units for the element, which maps the TSFI in the functional specification to the modules of the TSF. The evaluator shall examine the TOE design to determine that the description of the interfaces presented by each SFR-enforcing and SFR-supporting module contain an accurate and complete description of the SFR-related parameters, the invocation conventions for each interface, and any values returned directly by the interface. The SFR-related interfaces of a module are those interfaces used by other modules as a means to invoke the SFR-related operations provided, and to provide inputs to or receive outputs from the module. The purpose in the specification of these interfaces is to permit the exercise of them during testing. Inter-module interfaces that are not SFR-related need not be specified or described, since they are not a factor in testing. Likewise, other internal interfaces that are not a factor in traversing SFR-related paths of execution (such as those internal paths that are fixed). SFR-related interfaces of SFR-supporting modules are all interfaces of SFR-supporting modules that are called directly or indirectly from SFR-enforcing modules. Those interfaces need to be described with all the parameter used in such a call. This allows the evaluator to understand the purpose of the call to the SFR-supporting module in the context of operation of the SFR-enforcing modules. SFR-related interfaces are described in terms of how they are invoked, and any values that are returned. This description would include a list of parameters, and descriptions of these parameters. Note that global data would also be considered parameters if used by the module (either as inputs or outputs) when invoked. If a parameter were expected to take on a set of values (e.g., a "flag" parameter), the complete set of values the parameter can take on that would have an effect on module processing would be specified. Likewise, parameters representing data structures are described such that each field of the data structure is identified and described. Note that different programming languages may have additional "interfaces" that would be non-obvious; an example would be operator/function overloading in C++. This "implicit interface" in the class description would also be described as part of the low-level TOE design. Note that although a module can present only one interface, it is more common that a module presents a small set of related interfaces. In terms of the assessment of parameters (inputs and outputs) to a module, any use of global data must also be considered. A module "uses" global data if it either reads or writes the data. In order to assure the description of such parameters (if used) is complete, the evaluator uses other information provided about the module in the TOE design (interfaces, algorithmic description, etc.), as well as the description of the particular set of global data assessed in work unit . For instance, the evaluator can first determine the processing the module performs by examining its function and interfaces presented (particularly the parameters of the interfaces). They can then check to see if the processing appears to "touch" any of the global data areas identified in the TDS design. The evaluator then determines that, for each global data area that appears to be "touched", that global data area is listed as a means of input or output by the module the evaluator is examining. Invocation conventions are a programming-reference-type description that one can use to correctly invoke a module's interface if one were writing a program to make use of the module's functionality through that interface. This includes necessary inputs and outputs, including any set-up that may need to be performed with respect to global variables. Values returned through the interface refer to values that are either passed through parameters or messages; values that the function call itself returns in the style of a "C" program function call; or values passed through global means (such as certain error routines in *ix-style operating systems). In order to assure the description is complete, the evaluator uses other information provided about the module in the TOE design (e.g., algorithmic description, global data used) to ensure that it appears all data necessary for performing the functions of the module is presented to the module, and that any values that other modules expect the module under examination to provide are identified as being returned by the module. The evaluator determines accuracy by ensuring that the description of the processing matches the information listed as being passed to or from an interface. The evaluator shall examine the TOE design to determine that SFR-non-interfering modules are correctly categorised. As mentioned in work unit , less information is required about modules that are SFR-non-interfering. A key focus of the evaluator for this work unit is attempting to determine from the evidence provided for each module implicitly categorised as SFR-non-interfering and the evaluation (information about other modules in the TOE design, the functional specification, the security architecture description, the operational user guidance, the TSF internals document, and perhaps even the implementation representation) whether the module is indeed SFR-non-interfering. At this level of assurance some error should be tolerated; the evaluator does not have to be absolutely sure that a given module is SFR-non-interfering, even though it is labelled as such. However, if the evidence provided indicates that a SFR-non-interfering module is SFR-enforcing or SFR-supporting, the evaluator requests additional information from the developer in order to resolve the apparent inconsistency. For example, suppose the documentation for Module A (an SFR-enforcing module) indicates that it calls Module B to perform an access check on a certain type of construct. When the evaluator examines the information associated with Module B, it is discovered that the only information the developer has provided is a purpose and a set of interactions (thus implicitly categorising Module B as SFR-supporting or SFR-non-interfering). On examining the purpose and interactions from Module A, the evaluator finds no mention of Module B performing any access checks, and Module A is not listed as a module with which Module B interacts. At this point the evaluator should approach the developer to resolve the discrepancies between the information provided in Module A and that in Module B. Another example would be where the evaluator examines the mapping of the TSFI to the modules as provided by . This examination shows that Module C is associated with an SFR requiring identification of the user. Again, when the evaluator examines the information associated with Module C, they find that all the developer has provided is a purpose and a set of interactions (thus implicitly categorising Module C as SFR-non-interfering). Examining the purpose and interactions presented for Module C, the evaluator is unable to determine why Module C, listed as mapping to a TSFI concerned with user identification, would not be classified as SFR-enforcing or SFR-supporting. Again, the evaluator should approach the developer to resolve this discrepancy. A final example illustrates the opposite situation. As before, the developer has provided information associated with Module D consisting of a purpose and a set of interactions (thus implicitly categorising Module D as SFR-non-interfering). The evaluator examines all of the evidence provided, including the purpose and interactions for Module D. The purpose appears to give a meaningful description of Module D's function in the TOE, the interactions are consistent with that description, and there is nothing to indicate that Module D is SFR-enforcing or SFR-supporting. In this case, the evaluator should not demand more information about Module D "just to be sure" it is correctly categorised. The developer has met the obligations and the resulting assurance the evaluator has in the implicit categorisation of Module D is (by definition) appropriate for this assurance level. The evaluator shall examine the TOE design to determine that the description of the purpose of each SFR-non-interfering module is complete and accurate. The description of the purpose of a module indicates what function the module is fulfilling. From the description, the evaluator should be able to obtain a general idea of the module's role. In order to assure the description is complete, the evaluator uses the information provided about the module's interactions with other modules to assess whether the reasons for the module being called are consistent with the module's purpose. If the interaction description contains functionality that is not apparent from, or in conflict with, the module's purpose, the evaluator needs to determine whether the problem is one of accuracy or of completeness. The evaluator should be wary of purposes that are too short, since meaningful analysis based on a one-sentence purpose is likely to be impossible. Because the modules are at such a low level, it may be difficult determine completeness and accuracy impacts from other documentation, such as operational user guidance, the functional specification, the security architecture description, or the TSF internals document. However, the evaluator uses the information present in those documents to the extent possible to help ensure that the function is accurately and completely described. This analysis can be aided by the analysis performed for the work units for the element, which maps the TSFI in the functional specification to the modules of the TSF. The evaluator shall examine the TOE design to determine that the description of an SFR-non-interfering module's interaction with other modules is complete and accurate. It is important to note that, in terms of the Part 3 requirement and this work unit, the term interaction is intended to convey less rigour than interface. An interaction does not need to be characterised at the implementation level (e.g., parameters passed from one routine in a module to a routine in a different module; global variables; hardware signals (e.g., interrupts) from a hardware subsystem to an interrupt-handling subsystem), but the data elements identified for a particular module that are going to be used by another module should be covered in this discussion. Any control relationships between modules (e.g., a module responsible for configuring a rule base for a firewall system and the module that actually implements these rules) should also be described. A module's interaction with other modules can be captured in many ways. The intent for the TOE design is to allow the evaluator to understand (in part through analysis of module interactions) the role of the SFR-supporting and SFR-non-interfering modules in the overall TOE design. Understanding of this role will aid the evaluator in performing work unit . A module's interaction with other modules goes beyond just a call-tree-type document. The interaction is described from a functional perspective of why a module interacts with other modules. The module's purpose describes what functions the module provides to other modules; the interactions should describe what the module depends on from other modules in order to accomplish this function. Because the modules are at such a low level, it may be difficult determine completeness and accuracy impacts from other documentation, such as operational user guidance, the functional specification, the security architecture description, or the TSF internals document. However, the evaluator uses the information present in those documents to the extent possible to help ensure that the interactions are accurately and completely described. The evaluator shall examine the TOE design to determine that it contains a complete and accurate mapping from the TSFI described in the functional specification to the modules of the TSF described in the TOE design. The modules described in the TOE design provide a description of the implementation of the TSF. The TSFI provide a description of how the implementation is exercised. The evidence from the developer identifies the module that is initially invoked when an operation is requested at the TSFI, and identify the chain of modules invoked up to the module that is primarily responsible for implementing the functionality. However, a complete call tree for each TSFI is not required for this work unit. The cases in which more than one module would have to be identified are where there are "entry point" modules or wrapper modules that have no functionality other than conditioning inputs or de-multiplexing an input. Mapping to one of these modules would not provide any useful information to the evaluator. The evaluator assesses the completeness of the mapping by ensuring that all of the TSFI map to at least one module. The verification of accuracy is more complex. The first aspect of accuracy is that each TSFI is mapped to a module at the TSF boundary. This determination can be made by reviewing the module description and its interfaces/interactions. The next aspect of accuracy is that each TSFI identifies a chain of modules between the initial module identified and a module that is primarily responsible for implementing the function presented at the TSF. Note that this may be the initial module, or there may be several modules, depending on how much pre-conditioning of the inputs is done. It should be noted that one indicator of a pre-conditioning module is that it is invoked for a large number of the TSFI, where the TSFI are all of similar type (e.g., system call). The final aspect of accuracy is that the mapping makes sense. For instance, mapping a TSFI dealing with access control to a module that checks passwords is not accurate. The evaluator should again use judgement in making this determination. The goal is that this information aids the evaluator in understanding the system and implementation of the SFRs, and ways in which entities at the TSF boundary can interact with the TSF. The bulk of the assessment of whether the SFRs are described accurately by the modules is performed in other work units. The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements. The evaluator shall examine the TOE security functional requirements and the TOE design, to determine that all ST security functional requirements are covered by the TOE design. The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems, and later to modules. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were implemented in specific places within fifteen modules, it would be inadequate for the evaluator to map to one subsystem and claim the work unit had been completed. Instead, the evaluator would map (rule 1) to modules x, y and z of subsystem A; (rule 2) to x, p, and q of subsystem A; etc. The evaluator shall examine the TOE design to determine that it is an accurate instantiation of all security functional requirements. The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. As an example, if the ST requirements specified a role-based access control mechanism, the evaluator would first identify the subsystems, and modules that contribute to this mechanism's implementation. This can be done by in-depth knowledge or understanding of the TOE design or by work done in the previous work unit. Note that this trace is only to identify the subsystems, and modules, and is not the complete analysis. The next step would be to understand what mechanism the subsystems, and modules implemented. For instance, if the design described an implementation of access control based on UNIX-style protection bits, the design would not be an accurate instantiation of those access control requirements present in the ST example used above. If the evaluator cannot determine that the mechanism was accurately implemented because of a lack of detail, the evaluator would have to assess whether all of the SFR-enforcing subsystems and modules have been identified, or if adequate detail had been provided for those subsystems and modules. The objectives of this sub-activity are to determine whether the TOE design provides a description of the TOE in terms of subsystems sufficient to determine the TSF boundary, and provides a description of the TSF internals in terms of modules (and optionally higher-level abstractions). It provides enough information about the modules for the evaluator to determine that the SFRs are completely and accurately implemented; as such, the TOE design provides an explanation of the implementation representation. There are three types of activity that the evaluator must undertake with respect to the TOE design. First, the evaluator determines that the TSF boundary has been adequately described. Second, the evaluator determines that the developer has provided documentation that conforms to the content and presentation requirements this subsystem, and that is consistent with other documentation provided for the TOE. Finally, the evaluator must analyse the design information provided for the modules (at a detailed level) to understand how the system is implemented, and with that knowledge ensure that the TSFI in the functional specification are adequately described, and that the test information adequately tests the TSF (done in the work units). the ST; the functional specification; security architecture description; the TOE design. The developer shall provide the design of the TOE. The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design. The design shall describe the structure of the TOE in terms of subsystems. The design shall describe the TSF in terms of modules, designating each module as SFR-enforcing, SFR-supporting, or SFR-non-interfering. The design shall identify all subsystems of the TSF. The design shall provide a semiformal description of each subsystem of the TSF, supported by informal, explanatory text where appropriate. The design shall provide a description of the interactions among all subsystems of the TSF. The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF. The design shall provide a semiformal description of each module in terms of its purpose, interaction, interfaces, return values from those interfaces, and called interfaces to other modules, supported by informal, explanatory text where appropriate. The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE design to determine that the structure of the entire TOE is described in terms of subsystems. The evaluator ensures that all of the subsystems of the TOE are identified. This description of the TOE will be used as input to work unit , where the parts of the TOE that make up the TSF are identified. That is, this requirement is on the entire TOE rather than on only the TSF. The TOE (and TSF) may be described in multiple layers of abstraction (i.e. subsystems and modules). Depending upon the complexity of the TOE, its design may be described in terms of subsystems and modules, as described in CC Part 3, Annex A.4, . For a very simple TOE that can be described solely at the "module" level (see ), this work unit is not applicable and therefore considered to be satisfied. In performing this activity, the evaluator examines other evidence presented for the TOE (e.g., ST, operator user guidance) to determine that the description of the TOE in such evidence is consistent with the description contained in the TOE design. The evaluator shall examine the TOE design to determine that the entire TSF is described in terms of modules. The evaluator will examine the modules for specific properties in other work units; in this work unit the evaluator determines that the modular description covers the entire TSF, and not just a portion of the TSF. The evaluator uses other evidence provided for the evaluation (e.g., functional specification, architectural description) in making this determination. For example, if the functional specification contains interfaces to functionality that does not appear to be described in the TOE design description, it may be the case that a portion of the TSF has not been included appropriately. Making this determination will likely be an iterative process, whereas more analysis is done on the other evidence, more confidence can be gained with respect to the completeness of the documentation. Unlike subsystems, modules describe the implementation in a level of detail that can serve as a guide to reviewing the implementation representation. A description of a module should be such that one can create an implementation of the module from the description, and the resulting implementation would be 1) identical to the actual TSF implementation in terms of the interfaces presented, 2) identical in the use of interfaces that are mentioned in the design, and 3) functionally equivalent to the description of the purpose of the TSF module. For instance, RFC 793 provides a high-level description of the TCP protocol. It is necessarily implementation independent. While it provides a wealth of detail, it is not a suitable design description because it is not specific to an implementation. An actual implementation can add to the protocol specified in the RFC, and implementation choices (for instance, the use of global data vs. local data in various parts of the implementation) may have an impact on the analysis that is performed. The design description of the TCP module would list the interfaces presented by the implementation (rather than just those defined in RFC 793), as well as an algorithm description of the processing associated with the modules implementing TCP (assuming it was part of the TSF). The evaluator shall check the TOE design to determine that the TSF modules are identified as either SFR-enforcing, SFR-supporting, or SFR-non-interfering. The purpose of designating each module (according to the role a particular module plays in the enforcement of the SFRs) is to allow developers to provide less information about the parts of the TSF that have little role in security. It is always permissible for the developer to provide more information or detail than the requirements demand, as can occur when the information has been gathered outside the evaluation context. In such cases the developer must still designate the modules as either SFR-enforcing, SFR-supporting, or SFR-non-interfering. The accuracy of these designations is continuously reviewed as the evaluation progresses. The concern is the mis-designation of modules as being less important (and hence, having less information) than is really the case. While blatant mis-designations may be immediately apparent (e.g., designating an authentication module as anything but SFR-enforcing when is one of the SFRs being claimed), other mis-designations might not be discovered until the TSF is better understood. The evaluator must therefore keep in mind that these designations are the developer's initial best effort, but are subject to change. Further guidance is provided under work unit 6, which examines the accuracy of these designations. The evaluator shall examine the TOE design to determine that all subsystems of the TSF are identified. If the design is presented solely in terms of modules, then subsystems in these requirements are equivalent to modules and the activity should be performed at the module level. In work unit all of the subsystems of the TOE were identified, and a determination made that the non-TSF subsystems were correctly characterised. Building on that work, the subsystems that were not characterised as non-TSF subsystems should be precisely identified. The evaluator determines that, of the hardware and software installed and configured according to the guidance, each subsystem has been accounted for as either one that is part of the TSF, or one that is not. The evaluator shall examine the TDS documentation to determine that the semiformal notation used for describing the subsystems, modules and their interfaces is defined or referenced. A semiformal notation can be either defined by the sponsor or a corresponding standard be referenced. The evaluator should provide a mapping of security functions and their interfaces outlining in what part of the documentation a function or interface is semiformal described and what notation is used. The evaluator examines all semiformal notations used to make sure that they are of a semiformal style and to justify the appropriateness of the manner how the semiformal notations are used for the TOE. The evaluator is reminded that a semi-formal presentation is characterised by a standardised format with a well-defined syntax that reduces ambiguity that may occur in informal presentations. The syntax of all semiformal notations used in the functional specification shall be defined or a corresponding standard be referenced. The evaluator verifies that the semiformal notations used for expressing the functional specification are capable of expressing features relevant to security. In order to determine this, the evaluator can refer to the SFR and compare the TSF security features stated in the ST and those described in the FSP using the semiformal notations. Note that requires the module description to be semiformal. This work unit therefore applies also to that description. The evaluator shall examine the TOE design to determine that each subsystem of the TSF describes its role in the enforcement of SFRs described in the ST. If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case. On systems that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the goal of the subsystem-level description is to give the evaluator context for the modular description that follows. Therefore, the evaluator ensures that the subsystem-level description contains a description of how the security functional requirements are achieved in the design, but at a level of abstraction above the modular description. This description should discuss the mechanisms used at a level that is aligned with the module description; this will provide the evaluators the road map needed to intelligently assess the information contained in the module description. A well-written set of subsystem descriptions will help guide the evaluator in determining the modules that are most important to examine, thus focusing the evaluation activity on the portions of the TSF that have the most relevance with respect to the enforcement of the SFRs. The evaluator ensures that all subsystems of the TSF have a description. While the description should focus on the role that the subsystem plays in enforcing or supporting the implementation of the SFRs, enough information must be present so that a context for understanding the SFR-related functionality is provided. The evaluator shall examine the TOE design to determine that each SFR-non-interfering subsystem of the TSF is described such that the evaluator can determine that the subsystem is SFR-non-interfering. If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case. An SFR-non-interfering subsystem is one on which the SFR-enforcing and SFR-supporting subsystems have no dependence; that is, they play no role in implementing SFR functionality. The evaluator ensures that all subsystems of the TSF have a description. While the description should focus on the role that the subsystem does not play in enforcing or supporting the implementation of the SFRs, enough information must be present so that a context for understanding the SFR-non-interfering functionality is provided. The evaluator shall examine the TOE design to determine that interactions between the subsystems of the TSF are described. If the design is presented solely in terms of modules, then this work unit will be considered satisfied by the assessment done in subsequent work units; no explicit action on the part of the evaluator is necessary in this case. On systems that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the goal of describing the interactions between the subsystems is to help provide the reader a better understanding of how the TSF performs it functions. These interactions do not need to be characterised at the implementation level (e.g., parameters passed from one routine in a subsystem to a routine in a different subsystem; global variables; hardware signals (e.g., interrupts) from a hardware subsystem to an interrupt-handling subsystem), but the data elements identified for a particular subsystem that are going to be used by another subsystem need to be covered in this discussion. Any control relationships between subsystems (e.g., a subsystem responsible for configuring a rule base for a firewall system and the subsystem that actually implements these rules) should also be described. It should be noted while the developer should characterise all interactions between subsystems, the evaluators need to use their own judgement in assessing the completeness of the description. If the reason for an interaction is unclear, or if there are SFR-related interactions (discovered, for instance, in examining the module-level documentation) that do not appear to be described, the evaluator ensures that this information is provided by the developer. However, if the evaluator can determine that interactions among a particular set of subsystems, while incompletely described by the developer, and a complete description will not aid in understanding the overall functionality nor security functionality provided by the TSF, then the evaluator may choose to consider the description sufficient, and not pursue completeness for its own sake. The evaluator shall examine the TOE design to determine that the mapping between the subsystems of the TSF and the modules of the TSF is complete. If the design is presented solely in terms of modules, then this work unit is considered satisfied. For TOEs that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the developer provides a simple mapping showing how the modules of the TSF are allocated to the subsystems. This will provide the evaluator a guide in performing their module-level assessment. To determine completeness, the evaluator examines each mapping and determines that all subsystems map to at least one module, and that all modules map to exactly one subsystem. The evaluator shall examine the TOE design to determine that the mapping between the subsystems of the TSF to the modules of the TSF is accurate. If the design is presented solely in terms of modules, then this work unit is considered satisfied. For TOEs that are complex enough to warrant a subsystem-level description of the TSF in addition to the modular description, the developer provides a simple mapping showing how the modules of the TSF are allocated to the subsystems. This will provide the evaluator a guide in performing their module-level assessment. The evaluator may choose to check the accuracy of the mapping in conjunction with performing other work units. An "inaccurate" mapping is one where the module is mistakenly associated with a subsystem where its functions are not used within the subsystem. Because the mapping is intended to be a guide supporting more detailed analysis, the evaluator is cautioned to apply appropriate effort to this work unit. Expending extensive evaluator resources verifying the accuracy of the mapping is not necessary. Inaccuracies that lead to misunderstandings related to the design that are uncovered as part of this or other work units are the ones that should be associated with this work unit and corrected. The evaluator shall examine the TOE design to determine that the semiformal description of the purpose of each module, and its relationship with other modules is complete and accurate. The developer may designate modules as SFR-enforcing, SFR-supporting, and SFR non-interfering, but these "tags" are used only to describe the amount and type of information the developer must provide, and can be used to limit the amount of information the developer has to develop if their engineering process does not produce the documentation required. Whether the modules have been categorised by the developer or not, it is the evaluator's responsibility to determine that the modules have the appropriate information for their role (SFR-enforcing, SFR-supporting, or SFR non-interfering) in the TOE, and to obtain the appropriate information from the developer should the developer fail to provide the required information for a particular module. The purpose of a module provides a description indicating what function the module is fulfilling. A word of caution to the evaluator is in order. The focus of this work unit should be to provide the evaluator an understanding of how the module works so that determinations can be made about the soundness of the implementation of the SFRs, as well as to support architectural analysis performed for subsystems. As long as the evaluator has a sound understanding of the module's operation, and its relationship to other modules and the TOE as a whole, the evaluator should consider the objective of the work achieved and not engage in a documentation exercise for the developer (by requiring, for example, a complete algorithmic description for a self-evident implementation representation). Because the modules are at such a low level, it may be difficult determine completeness and accuracy impacts from other documentation, such as operational user guidance, the functional specification, the TSF internals, or the security architecture description. However, the evaluator uses the information present in those documents to the extent possible to help ensure that the purpose is accurately and completely described. This analysis can be aided by the analysis performed for the work units for the element, which maps the TSFI in the functional specification to the modules of the TSF. The evaluator shall examine the TOE design to determine that the semiformal description of the interfaces presented by each module contain an accurate and complete description of the related parameters, the invocation conventions for each interface, and any values returned directly by the interface. The interfaces of a module are those interfaces used by other modules as a means to invoke the operations provided, and to provide inputs to or receive outputs from the module. The purpose in the specification of these interfaces is to permit the exercise of them during testing. Inter-module interfaces that are not SFR-related need not be specified or described, since they are not a factor in testing. Likewise, other internal interfaces that are not a factor in traversing SFR-related paths of execution (such as those internal paths that are fixed). SFR-related interfaces are all interfaces that are called directly or indirectly from SFR-enforcing modules. Those interfaces need to be described with all the parameter used in such a call. This allows the evaluator to understand the purpose of the call in the context of operation of the SFR-enforcing modules. SFR-related interfaces are described in terms of how they are invoked, and any values that are returned. This description would include a list of parameters, and descriptions of these parameters. Note that global data would also be considered parameters if used by the module (either as inputs or outputs) when invoked. If a parameter were expected to take on a set of values (e.g., a "flag" parameter), the complete set of values the parameter can take on, that would have an effect on module processing, would be specified. Likewise, parameters representing data structures are described such that each field of the data structure is identified and described. Note that different programming languages may have additional "interfaces" that would be non-obvious; an example would be operator/function overloading in C++. This "implicit interface" in the class description would also be described as part of the low-level TOE design. Note that although a module can present only one interface, it is more common that a module presents a small set of related interfaces. In terms of the assessment of parameters (inputs and outputs) to a module, any use of global data must also be considered. A module "uses" global data if it either reads or writes the data. In order to assure the description of such parameters (if used) is complete, the evaluator uses other information provided about the module in the TOE design (interfaces, algorithmic description, etc.), as well as the description of the particular set of global data assessed in work unit . For instance, the evaluator can first determine the processing the module performs by examining its function and interfaces presented (particularly the parameters of the interfaces). They can then check to see if the processing appears to "touch" any of the global data areas identified in the TDS design. The evaluator then determines that, for each global data area that appears to be "touched", that global data area is listed as a means of input or output by the module the evaluator is examining. Invocation conventions are a programming-reference-type description that one can use to correctly invoke a module's interface if one were writing a program to make use of the module's functionality through that interface. This includes necessary inputs and outputs, including any set-up that may need to be performed with respect to global variables. Values returned through the interface refer to values that are either passed through parameters or messages; values that the function call itself returns in the style of a "C" program function call; or values passed through global means (such as certain error routines in *ix-style operating systems). In order to assure the description is complete, the evaluator uses other information provided about the module in the TOE design (e.g., algorithmic description, global data used) to ensure that it appears all data necessary for performing the functions of the module is presented to the module, and that any values that other modules expect the module under examination to provide are identified as being returned by the module. The evaluator determines accuracy by ensuring that the description of the processing matches the information listed as being passed to or from an interface. The evaluator shall examine the TOE design to determine that it contains a complete and accurate mapping from the TSFI described in the functional specification to the modules of the TSF described in the TOE design. The modules described in the TOE design provide a description of the implementation of the TSF. The TSFI provide a description of how the implementation is exercised. The evidence from the developer identifies the module that is initially invoked when an operation is requested at the TSFI, and identify the chain of modules invoked up to the module that is primarily responsible for implementing the functionality. However, a complete call tree for each TSFI is not required for this work unit. The cases in which more than one module would have to be identified are where there are "entry point" modules or wrapper modules that have no functionality other than conditioning inputs or de-multiplexing an input. Mapping to one of these modules would not provide any useful information to the evaluator. The evaluator assesses the completeness of the mapping by ensuring that all of the TSFI map to at least one module. The verification of accuracy is more complex. The first aspect of accuracy is that each TSFI is mapped to a module at the TSF boundary. This determination can be made by reviewing the module description and its interfaces/interactions. The next aspect of accuracy is that each TSFI identifies a chain of modules between the initial module identified and a module that is primarily responsible for implementing the function presented at the TSF. Note that this may be the initial module, or there may be several modules, depending on how much pre-conditioning of the inputs is done. It should be noted that one indicator of a pre-conditioning module is that it is invoked for a large number of the TSFI, where the TSFI are all of similar type (e.g., system call). The final aspect of accuracy is that the mapping makes sense. For instance, mapping a TSFI dealing with access control to a module that checks passwords is not accurate. The evaluator should again use judgement in making this determination. The goal is that this information aids the evaluator in understanding the system and implementation of the SFRs, and ways in which entities at the TSF boundary can interact with the TSF. The bulk of the assessment of whether the SFRs are described accurately by the modules is performed in other work units. The evaluator shall examine the TOE security functional requirements and the TOE design, to determine that all ST security functional requirements are covered by the TOE design. The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems, and later to modules. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. For example, the component contains an element with assignments. If the ST contained, for instance, ten rules in the assignment, and these ten rules were implemented in specific places within fifteen modules, it would be inadequate for the evaluator to map to one subsystem and claim the work unit had been completed. Instead, the evaluator would map (rule 1) to modules x, y and z of subsystem A; (rule 2) to x, p, and q of subsystem A; etc. The evaluator shall examine the TOE design to determine that it is an accurate instantiation of all security functional requirements. The evaluator may construct a map between the TOE security functional requirements and the TOE design. This map will likely be from a functional requirement to a set of subsystems and modules. Note that this map may have to be at a level of detail below the component or even element level of the requirements, because of operations (assignments, refinements, selections) performed on the functional requirement by the ST author. As an example, if the ST requirements specified a role-based access control mechanism, the evaluator would first identify the subsystems, and modules that contribute to this mechanism's implementation. This can be done by in-depth knowledge or understanding of the TOE design or by work done in the previous work unit. Note that this trace is only to identify the subsystems, and modules, and is not the complete analysis. The next step would be to understand what mechanism the subsystems, and modules implemented. For instance, if the design described an implementation of access control based on UNIX-style protection bits, the design would not be an accurate instantiation of those access control requirements present in the ST example used above. If the evaluator cannot determine that the mechanism was accurately implemented because of a lack of detail, the evaluator would have to assess whether all of the SFR-enforcing subsystems and modules have been identified, or if adequate detail had been provided for those subsystems and modules. The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements. The developer shall provide the design of the TOE. The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design. The developer shall provide a formal specification of the TSF subsystems. The developer shall provide a proof of correspondence between the formal specifications of the TSF subsystems and of the functional specification. The design shall describe the structure of the TOE in terms of subsystems. The design shall describe the TSF in terms of modules, designating each module as SFR-enforcing, SFR-supporting, or SFR-non-interfering. The design shall identify all subsystems of the TSF. The design shall provide a semiformal description of each subsystem of the TSF, supported by informal, explanatory text where appropriate. The design shall provide a description of the interactions among all subsystems of the TSF. The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF. The design shall describe each module in semiformal style in terms of its purpose, interaction, interfaces, return values from those interfaces, and called interfaces to other modules, supported by informal, explanatory text where appropriate. The formal specification of the TSF subsystems shall describe the TSF using a formal style, supported by informal, explanatory text where appropriate. The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. The proof of correspondence between the formal specifications of the TSF subsystems and of the functional specification shall demonstrate that all behaviour described in the TOE design is a correct and complete refinement of the TSFI that invoked it. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements. The guidance documents class provides the requirements for guidance documentation for all user roles. For the secure preparation and operation of the TOE it is necessary to describe all relevant aspects for the secure handling of the TOE. The class also addresses the possibility of unintended incorrect configuration or handling of the TOE. In many cases it can be appropriate to provide guidance in separate documents for preparation and operation of the TOE, or even separate for different user roles as, e.g. end-users, administrators, application programmers using software or hardware interfaces. The guidance documents class is subdivided into two families which are concerned with the preparative user guidance (what has to be done to transform the delivered TOE into its evaluated configuration in the operational environment as described in the ST) and with the operational user guidance (what has to be done during the operation of the TOE in its evaluated configuration). The purpose of the guidance document activity is to judge the adequacy of the documentation describing how the user can handle the TOE in a secure manner. Such documentation should take into account the various types of users (e.g. those who accept, install, administrate or operate the TOE) whose incorrect actions can adversely affect the security of the TOE or of their own data. The guidance documents class is subdivided into two families which are concerned firstly with the preparative procedures (all that has to be done to transform the delivered TOE into its evaluated configuration in the environment as described in the ST, i.e. accepting and installing the TOE) and secondly with the operational user guidance (all that has to be done during the operation of the TOE in its evaluated configuration, i.e. operation and administration). The guidance documents activity applies to those functions and interfaces which are related to the security of the TOE. The secure configuration of the TOE is described in the ST. Operational user guidance refers to written material that is intended to be used by all types of users of the TOE in its evaluated configuration: end-users, persons responsible for maintaining and administering the TOE in a correct manner for maximum security, and by others (e.g. programmers) using the TOE's external interfaces. Operational user guidance describes the security functionality provided by the TSF, provides instructions and guidelines (including warnings), helps to understand the TSF and includes the security-critical information, and the security-critical actions required, for its secure use. Misleading and unreasonable guidance should be absent from the guidance documentation, and secure procedures for all modes of operation should be addressed. Insecure states should be easy to detect. The operational user guidance provides a measure of confidence that non-malicious users, administrators, application providers and others exercising the external interfaces of the TOE will understand the secure operation of the TOE and will use it as intended. The evaluation of the user guidance includes investigating whether the TOE can be used in a manner that is insecure but that the user of the TOE would reasonably believe to be secure. The objective is to minimize the risk of human or other errors in operation that may deactivate, disable, or fail to activate security functionality, resulting in an undetected insecure state. This family contains only one component. There may be different user roles or groups that are recognized by the TOE and that can interact with the TSF. These user roles and groups should be taken into consideration by the operational user guidance. They may be roughly grouped into administrators and non-administrative users, or more specifically grouped into persons responsible for receiving, accepting, installing and maintaining the TOE, application programmers, revisors, auditors, daily-management, end-users. Each role can encompass an extensive set of capabilities or can be a single one. The requirement encompasses the aspect that any warnings to the users during operation of a TOE with regard to the security problem definition and the security objectives for the operational environment described in the PP/ST are appropriately covered in the user guidance. The concept of secure values, as employed in , has relevance where a user has control over security parameters. Guidance needs to be provided on secure and insecure settings for such parameters. requires that the user guidance describes the appropriate reactions to all security-relevant events. Although many security-relevant events are the result of performing functions, this need not always be the case (e.g. the audit log fills up, an intrusion is detected). Furthermore, a security-relevant event may happen as a result of a specific chain of functions or, conversely, several security-relevant events may be triggered by one function. requires that the user guidance is clear and reasonable. Misleading or unreasonable guidance may result in a user of the TOE believing that the TOE is secure when it is not. An example of misleading guidance would be the description of a single guidance instruction that can be parsed in more than one way, one of which may result in an insecure state. An example of unreasonable guidance would be a recommendation to follow a procedure that is so complicated that it cannot reasonably be expected that users will follow this guidance. The objectives of this sub-activity are to determine whether the user guidance describes for each user role the security functionality and interfaces provided by the TSF, provides instructions and guidelines for the secure use of the TOE, addresses secure procedures for all modes of operation, facilitates prevention and detection of insecure TOE states, or whether it is misleading or unreasonable. the ST; the functional specification; the TOE design, if applicable; the user guidance. The developer shall provide operational user guidance. The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. The operational user guidance shall, for each user role, describe the security controls to be followed in order to fulfil the security objectives for the operational environment as described in the ST. The operational user guidance shall be clear and reasonable. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. The configuration of the TOE may allow different user roles to have dissimilar privileges in making use of the different functions of the TOE. This means that some users are authorized to perform certain functions, while other users may not be so authorized. These functions and privileges should be described, for each user role, by the user guidance. The user guidance identifies, for each user role, the functions and privileges that must be controlled, the types of commands required for them, and the reasons for such commands. The user guidance should contain warnings regarding the use of these functions and privileges. Warnings should address expected effects, possible side effects, and possible interactions with other functions and privileges. The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the secure use of the available interfaces provided by the TOE. The user guidance should provide advice regarding effective use of the TSF (e.g. reviewing password composition practises, suggested frequency of user file backups, discussion on the effects of changing user access privileges). The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the available security functionality and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. The user guidance should contain an overview of the security functionality that is visible at the user interfaces. The user guidance should identify and describe the purpose, behaviour, and interrelationships of the security interfaces and functionality. For each user-accessible interface, the user guidance should: describe the method(s) by which the interface is invoked (e.g. command-line, programming-language system call, menu selection, command button); describe the parameters to be set by the user, their particular purposes, valid and default values, and secure and insecure use settings of such parameters, both individually or in combination; describe the immediate TSF response, message, or code returned. The evaluator should consider the functional specification and the ST to determine that the TSF described in these documents is consistent to the operational user guidance. The evaluator has to ensure that the operational user guidance is complete to allow the secure use through the TSFI available to all types of human users. The evaluator may, as an aid, prepare an informal mapping between the guidance and these documents. Any omissions in this mapping may indicate incompleteness. The evaluator shall examine the operational user guidance to determine that it describes, for each user role, each type of security-relevant event relative to the user functions that need to be performed, including changing the security characteristics of entities under the control of the TSF and operation following failure or operational error. All types of security-relevant events are detailed for each user role, such that each user knows what events may occur and what action (if any) they may have to take in order to maintain security. Security-relevant events that may occur during operation of the TOE (e.g. audit trail overflow, system crash, updates to user records, such as when a user account is removed when the user leaves the organisation) are adequately defined to allow user intervention to maintain secure operation. The evaluator shall examine the operational user guidance and other evaluation evidence to determine that the guidance identifies all possible modes of operation of the TOE (including, if applicable, operation following failure or operational error), their consequences and implications for maintaining secure operation. Other evaluation evidence, particularly the functional specification, provide an information source that the evaluator should use to determine that the guidance contains sufficient guidance information. If test documentation is included in the assurance package, then the information provided in this evidence can also be used to determine that the guidance contains sufficient guidance documentation. The detail provided in the test steps can be used to confirm that the guidance provided is sufficient for the use and administration of the TOE. The evaluator should focus on a single human visible TSFI at a time, comparing the guidance for securely using the TSFI with other evaluation evidence, to determine that the guidance related to the TSFI is sufficient for the secure usage (i.e. consistent with the SFRs) of that TSFI. The evaluator should also consider the relationships between interfaces, searching for potential conflicts. The evaluator shall examine the operational user guidance to determine that it describes, for each user role, the security measures to be followed in order to fulfil the security objectives for the operational environment as described in the ST. The evaluator analyses the security objectives for the operational environment in the ST and determines that for each user role, the relevant security measures are described appropriately in the user guidance. The security measures described in the user guidance should include all relevant external procedural, physical, personnel and connectivity measures. Note that those measures relevant for secure installation of the TOE are examined in . The evaluator shall examine the operational user guidance to determine that it is clear. The guidance is unclear if it can reasonably be misconstrued by an administrator or user, and used in a way detrimental to the TOE, or to the security provided by the TOE. The evaluator shall examine the operational user guidance to determine that it is reasonable. The guidance is unreasonable if it makes demands on the TOE's usage or operational environment that are inconsistent with the ST or unduly onerous to maintain security. Preparative procedures are useful for ensuring that the TOE has been received and installed in a secure manner as intended by the developer. The requirements for preparation call for a secure transition from the delivered TOE to its initial operational environment. This includes investigating whether the TOE can be configured or installed in a manner that is insecure but that the user of the TOE would reasonably believe to be secure. This family contains only one component. It is recognized that the application of these requirements will vary depending on aspects, e.g. whether the TOE is delivered in an operational state, or whether it has to be installed at the TOE owner's site. The first process covered by the preparative procedures is the consumer's secure acceptance of the received TOE in accordance with the developer's delivery procedures. If the developer has not defined delivery procedures, security of the acceptance has to be ensured otherwise. Installation of the TOE includes transforming its operational environment into a state that conforms to the security objectives for the operational environment provided in the ST. It can also be the case that no installation is necessary, for example a smart card. In this case it may be inappropriate to require and analyse installation procedures. The requirements in this assurance family are presented separately from those in the family, due to the infrequent, possibly one-time use of the preparative procedures. The objective of this sub-activity is to determine whether the procedures and steps for the secure preparation of the TOE have been documented and result in a secure configuration. The preparative procedures refer to all acceptance and installation procedures, that are necessary to progress the TOE to the secure configuration as described in the ST. the ST; the TOE including its preparative procedures; the description of developer's delivery procedures, if applicable. The developer shall provide the TOE including its preparative procedures. The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the provided acceptance procedures to determine that they describe the steps necessary for secure acceptance of the TOE in accordance with the developer's delivery procedures. If it is not anticipated by the developer's delivery procedures that acceptance procedures will or can be applied, this work unit is not applicable, and is therefore considered to be satisfied. The acceptance procedures should include as a minimum, that the user has to check that all parts of the TOE as indicated in the ST have been delivered in the correct version. The acceptance procedures should reflect the steps the user has to perform in order to accept the delivered TOE that are implied by the developer's delivery procedures. The acceptance procedures should provide detailed information about the following, if applicable: making sure that the delivered TOE is the complete evaluated instance; detecting modification/masquerading of the delivered TOE. The evaluator shall examine the provided installation procedures to determine that they describe the steps necessary for secure installation of the TOE and the secure preparation of the operational environment in accordance with the security objectives in the ST. If it is not anticipated that installation procedures will or can be applied (e.g. because the TOE may already be delivered in an operational state), this work unit is not applicable, and is therefore considered to be satisfied. The installation procedures should provide detailed information about the following, if applicable: minimum system requirements for secure installation; requirements for the operational environment in accordance with the security objectives provided by the ST; the steps the user has to perform in order to get to an operational TOE being commensurate with its evaluated configuration. Such a description shall include - for each step - a clear scheme for the decision on the next step depended on success, failure or problems at the current step; changing the installation specific security characteristics of entities under the control of the TSF (for example parameters, settings, passwords); handling exceptions and problems. The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. The evaluator shall perform all user procedures necessary to prepare the TOE to determine that the TOE and its operational environment can be prepared securely using only the supplied preparative procedures. Preparation requires the evaluator to advance the TOE from a deliverable state to the state in which it is operational, including acceptance and installation of the TOE, and enforcing the SFRs consistent with the security objectives for the TOE specified in the ST. The evaluator should follow only the developer's procedures and may perform the activities that customers are usually expected to perform to accept and install the TOE, using the supplied preparative procedures only. Any difficulties encountered during such an exercise may be indicative of incomplete, unclear or unreasonable guidance. This work unit may be performed in conjunction with the evaluation activities under . If it is known that the TOE will be used as a dependent component for a composed TOE evaluation, then the evaluator should ensure that the operational environment is satisfied by the base component used in the composed TOE. Life-cycle support is an aspect of establishing appropriate security controls in the development, production, delivery and maintenance of the TOE. Confidence in the correspondence between the TOE security requirements and the TOE is greater if security analysis and the production of the evidence are done on a regular basis as an integral part of the development, production, delivery and maintenance activities. During the life-cycle of the TOE it is distinguished whether the TOE is under the responsibility of the TOE developer or the user rather than whether it is located in the development or the user environment. The point of transition is when the TOE is accepted by the user. User in this context relates to the end-user as well as product- and system integrators. The class consists of nine families: provides requirements for the developer's description of the life-cycle model used in the development, production, delivery and maintenance life-cycle of the TOE; provides requirements for the management of the configuration items; requires a minimum set of configuration items to be managed in the defined way; is concerned with the developer's physical, logical, procedural, personnel, and other security controls; provides requirements for the development tools and implementation standards used by the developer; provides requirements for the handling of security flaws; provides requirements for the procedures used for the delivery of the TOE to the downstream user. processes occurring during the development of the TOE are denoted rather as transfers, and are handled in the context of integration and acceptance procedures in other families of this class; is concerned with the generation of certain artefacts during the development process; is concerned with the integration of composition parts and a consistency check of delivery procedures. Throughout this class, development and related terms (developer, develop) are meant in the more general sense to comprise development and production, whereas production specifically means the process of transforming the implementation representation into the final TOE. The purpose of the life-cycle support activity is to determine the adequacy of the security procedures that the developer uses during the development and maintenance of the TOE. These procedures include the life-cycle model used by the developer, the configuration management, the security measures used throughout TOE development, the tools used by the developer throughout the life-cycle of the TOE, the handling of security flaws, and the delivery activity. Poorly controlled development and maintenance of the TOE can result in vulnerabilities in the implementation. Conformance to a defined life-cycle model can help to improve controls in this area. A measurable life-cycle model used for the TOE can remove ambiguity in assessing the development progress of the TOE. The purpose of the configuration management activity is to assist the consumer in identifying the evaluated TOE, to ensure that configuration items are uniquely identified, and the adequacy of the procedures that are used by the developer to control and track changes that are made to the TOE. This includes details on what changes are tracked, how potential changes are incorporated, and the degree to which automation is used to reduce the scope for error. Developer security procedures are intended to protect the TOE and its associated design information from interference or disclosure. Interference in the development process may allow the deliberate introduction of vulnerabilities. Disclosure of design information may allow vulnerabilities to be more easily exploited. The adequacy of the procedures will depend on the nature of the TOE and the development process. The use of well-defined development tools and the application of implementation standards by the developer and by third parties involved in the development process help to ensure that vulnerabilities are not inadvertently introduced during refinement. The flaw remediation activity is intended to track security flaws, to identify corrective actions, and to distribute the corrective action information to TOE users. The purpose of the delivery activity is to judge the adequacy of the documentation of the procedures used to ensure that the TOE is delivered to the consumer without modification. The composite-specific work units defined here are intended to be integrated as refinements to the evaluation activities of the class listed in the following table. The other activities of class do not require composite-specific work units. Assurance family Evaluation activity Evaluation work unit Composite-specific work unit If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable. Configuration management (CM) techniques, properly defined as part of the development life-cycle model, contribute to the assurance argument that the TOE meets the SFRs. A CM system that is managed and operated correctly will help ensure the integrity of the portions of the TOE that are controlled, by providing a method of tracking any changes to the TOE, and to help ensure that all changes to the TOE are authorized. The objective of this family is to require the TOE developer's CM system to have certain capabilities. These capabilities are intented to reduce the likelihood that accidental or unauthorised modifications of the configuration items will occur. The CM system should support maintaining the integrity of the TOE throughout the part of the TOE's life-cycle that is under the control of the developer. The objective of introducing automated CM tools is to increase the effectiveness of the CM system. While both automated and manual CM systems can be bypassed, ignored, or proven insufficient to prevent unauthorised modification, automated systems are less susceptible to human error or negligence. The objectives of this family include the following: ensuring that the TOE is identifiable and complete before it is sent to the downstream user; ensuring that no configuration items are missed during evaluation; preventing unauthorised modification, addition, or deletion of TOE configuration items. The components in this family are levelled on the basis of the CM system capabilities, the scope of the CM documentation and the evidence provided by the developer. In the case where the TOE is a subset of a product, the requirements of this family apply only to the TOE configuration items, not to the product as a whole. For developer organizations that specify more than one CM application or include different instances of a CM application within the scope of the TOEs design, development, production and maintenance, it is required to document all of them. For evaluation purposes, the set of CM applications should be regarded as parts of an overall CM system, applicable to the TOE, which is addressed in the criteria. The overall CM system should address any aspects of integration between component CM applications. Several elements of this family refer to configuration items. These elements identify CM requirements to be imposed on all items identified in the configuration list, but leave the contents of the list to the discretion of the developer. can be used to narrow this discretion by identifying specific items that must be included in the configuration list, and hence within the scope of the overall CM system. introduces a requirement that the CM system uniquely identify all configuration items. This also requires that modifications to configuration items result in a new, unique identifier being assigned to the configuration item. introduces the requirement that the evidence shall demonstrate that the CM system operates in accordance with the CM plan. Examples of such evidence can be documentation such as screen snapshots or audit trail output from the CM system, or a detailed demonstration of the CM system by the developer. The evaluator is responsible for determining that this evidence is sufficient to show that the CM system operates in accordance with the CM plan. introduces a requirement that the CM system provide an automated means to support the production of the TOE. This requires that the CM system provide an automated means to assist in determining that the correct configuration items are used in generating the TOE. introduces a requirement that the CM system provide an automated means to ascertain the changes between the TOE and its preceding version. If no previous version of the TOE exists, the developer still needs to provide an automated means to ascertain the changes between the TOE and a future version of the TOE. The objectives of this sub-activity are to determine whether the developer has clearly identified the TOE. the ST; the TOE suitable for testing. The developer shall provide the TOE and a unique reference for the TOE. The TOE shall be labelled with its unique reference. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the TOE provided for evaluation is labelled with its reference. The evaluator should ensure that the TOE contains the unique reference which is stated in the ST. This can be achieved through labelled packaging or media, or by a label displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the TOE (e.g. at the point of purchase or use). The TOE may provide a method by which it can be easily identified. For example, a software TOE may display its name and version number during the start up routine, or in response to a command line entry. A hardware or firmware TOE may be identified by a part number physically stamped on the TOE. Alternatively, the unique reference provided for the TOE may be the combination of the unique reference of each component from which the TOE is comprised (e.g. in the case of a composed TOE). The evaluator shall check that the TOE references used are consistent. If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible to relate any labelled guidance documentation supplied as part of the TOE to the evaluated operational TOE. This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, that they have installed this version, and that they have the correct version of the guidance to operate the TOE in accordance with its ST. The evaluator also verifies that the TOE reference is consistent with the ST. If this work unit is applied to a composed TOE, the following will apply. The composed IT TOE will not be labelled with its unique (composite) reference, but only the individual components will be labelled with their appropriate TOE reference. It would require further development for the IT TOE to be labelled, i.e. during start-up and/or operation, with the composite reference. If the composed TOE is delivered as the constituent component TOEs, then the TOE items delivered will not contain the composite reference. However, the composed TOE ST will include the unique reference for the composed TOE and will identify the components comprising the composed TOE through which the consumers will be able to determine whether they have the appropriate items. The objectives of this sub-activity are to determine whether the developer uses a CM system that uniquely identifies all configuration items. This component contains an implicit evaluator action to determine that the CM system is being used. As the requirements here are limited to identification of the TOE and provision of a configuration list, this action is already covered by, and limited to, the existing work units. At Evaluation of sub-activity the requirements are expanded beyond these two items, and more explicit evidence of operation is required. the ST; the TOE suitable for testing; the configuration management documentation. The developer shall provide the TOE and a unique reference for the TOE. The developer shall provide the CM documentation. The developer shall use a CM system. The TOE shall be labelled with its unique reference. The CM documentation shall describe the method used to uniquely identify the configuration items. The CM system shall uniquely identify all configuration items. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the TOE provided for evaluation is labelled with its reference. The evaluator should ensure that the TOE contains the unique reference which is stated in the ST. This can be achieved through labelled packaging or media, or by a label displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the TOE (e.g. at the point of purchase or use). The TOE may provide a method by which it can be easily identified. For example, a software TOE may display its name and version number during the start up routine, or in response to a command line entry. A hardware or firmware TOE may be identified by a part number physically stamped on the TOE. Alternatively, the unique reference provided for the TOE may be the combination of the unique reference of each component from which the TOE is comprised (e.g. in the case of a composed TOE). The evaluator shall check that the TOE references used are consistent. If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible to relate any labelled guidance documentation supplied as part of the TOE to the evaluated operational TOE. This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, that they have installed this version, and that they have the correct version of the guidance to operate the TOE in accordance with its ST. The evaluator also verifies that the TOE reference is consistent with the ST. If this work unit is applied to a composed TOE, the following will apply. The composed IT TOE will not be labelled with its unique (composite) reference, but only the individual components will be labelled with their appropriate TOE reference. It would require further development for the IT TOE to be labelled, i.e. during start-up and/or operation, with the composite reference. If the composed TOE is delivered as the constituent component TOEs, then the TOE items delivered will not contain the composite reference. However, the composed TOE ST will include the unique reference for the composed TOE and will identify the components comprising the composed TOE through which the consumers will be able to determine whether they have the appropriate items. The evaluator shall examine the method of identifying configuration items to determine that it describes how configuration items are uniquely identified. Procedures should describe how the status of each configuration item can be tracked throughout the life-cycle of the TOE. The procedures may be detailed in the CM plan or throughout the CM documentation. The information included should describe: the method how each configuration item is uniquely identified, such that it is possible to track versions of the same configuration item; the method how configuration items are assigned unique identifiers and how they are entered into the CM system; the method to be used to identify superseded versions of a configuration item. The evaluator shall examine the configuration items to determine that they are identified in a way that is consistent with the CM documentation. Assurance that the CM system uniquely identifies all configuration items is gained by examining the identifiers for the configuration items. For both configuration items that comprise the TOE, and drafts of configuration items that are submitted by the developer as evaluation evidence, the evaluator confirms that each configuration item possesses a unique identifier in a manner consistent with the unique identification method that is described in the CM documentation. The objectives of this sub-activity are to determine whether the developer uses a CM system that uniquely identifies all configuration items, and whether the ability to modify these items is properly controlled. the ST; the TOE suitable for testing; the configuration management documentation. The developer shall provide the TOE and a unique reference for the TOE. The developer shall provide the CM documentation. The developer shall use a CM system. The TOE shall be labelled with its unique reference. The CM documentation shall describe the method used to uniquely identify the configuration items. The CM system shall uniquely identify all configuration items. The CM system shall provide controls such that only authorized changes are made to the configuration items. The CM documentation shall include a CM plan. The CM plan shall describe how the CM system is used for the development of the TOE. The evidence shall demonstrate that all configuration items are being maintained under the CM system. The evidence shall demonstrate that the CM system is being operated in accordance with the CM plan. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the TOE provided for evaluation is labelled with its reference. The evaluator should ensure that the TOE contains the unique reference which is stated in the ST. This can be achieved through labelled packaging or media, or by a label displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the TOE (e.g. at the point of purchase or use). The TOE may provide a method by which it can be easily identified. For example, a software TOE may display its name and version number during the start up routine, or in response to a command line entry. A hardware or firmware TOE may be identified by a part number physically stamped on the TOE. Alternatively, the unique reference provided for the TOE may be the combination of the unique reference of each component from which the TOE is comprised (e.g. in the case of a composed TOE). The evaluator shall check that the TOE references used are consistent. If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible to relate any labelled guidance documentation supplied as part of the TOE to the evaluated operational TOE. This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, that they have installed this version, and that they have the correct version of the guidance to operate the TOE in accordance with its ST. The evaluator also verifies that the TOE reference is consistent with the ST. If this work unit is applied to a composed TOE, the following will apply. The composed IT TOE will not be labelled with its unique (composite) reference, but only the individual components will be labelled with their appropriate TOE reference. It would require further development for the IT TOE to be labelled, i.e. during start-up and/or operation, with the composite reference. If the composed TOE is delivered as the constituent component TOEs, then the TOE items delivered will not contain the composite reference. However, the composed TOE ST will include the unique reference for the composed TOE and will identify the components comprising the composed TOE through which the consumers will be able to determine whether they have the appropriate items. The evaluator shall examine the method of identifying configuration items to determine that it describes how configuration items are uniquely identified. Procedures should describe how the status of each configuration item can be tracked throughout the life-cycle of the TOE. The procedures may be detailed in the CM plan or throughout the CM documentation. The information included should describe: the method how each configuration item is uniquely identified, such that it is possible to track versions of the same configuration item; the method how configuration items are assigned unique identifiers and how they are entered into the CM system; the method to be used to identify superseded versions of a configuration item. The evaluator shall examine the configuration items to determine that they are identified in a way that is consistent with the CM documentation. Assurance that the CM system uniquely identifies all configuration items is gained by examining the identifiers for the configuration items. For both configuration items that comprise the TOE, and drafts of configuration items that are submitted by the developer as evaluation evidence, the evaluator confirms that each configuration item possesses a unique identifier in a manner consistent with the unique identification method that is described in the CM documentation. The evaluator shall examine the CM access control measures described in the CM plan to determine that they are effective in preventing unauthorized access to the configuration items. The evaluator may use a number of methods to determine that the CM access control measures are effective. For example, the evaluator may exercise the access control measures to ensure that the procedures cannot be bypassed. The evaluator may use the outputs generated by the CM system procedures required by . The evaluator may also witness a demonstration of the CM system to ensure that the access control measures employed are operating effectively. The evaluator shall check that the CM documentation provided includes a CM plan. The CM plan needs not to be a connected document, but it is recommended that there is a single document that describes where the various parts of the CM plan can be found. If the CM plan is no single document, the list in the following work unit gives hints regarding which context is expected. The evaluator shall examine the CM plan to determine that it describes how the CM system is used for the development of the TOE. The descriptions contained in a CM plan include, if applicable: all activities performed in the TOE development that are subject to configuration management procedures (e.g. creation, modification or deletion of a configuration item, data-backup, archiving); which means (e.g. CM tools, forms) have to be made available; the usage of the CM tools: the necessary details for a user of the CM system to be able to operate the CM tools correctly in order to maintain the integrity of the TOE; which other objects (development components, tools, assessment environments) are taken under CM control; the roles and responsibilities of individuals required to perform operations on individual configuration items (different roles may be identified for different types of configuration items, e.g. design documentation or source code); how CM instances (e.g. change control boards, interface control working groups) are introduced and staffed; the description of the change management, including the process of verifying that the proposed change is necessary and the consequence would be acceptable; the procedures that are used to ensure that only authorized individuals can make changes to configuration items; the procedures that are used to ensure that concurrency problems do not occur as a result of simultaneous changes to configuration items; the evidence that is generated as a result of application of the procedures. For example, for a change to a configuration item, the CM system can record a description of the change, accountability for the change, identification of all configuration items affected, status (e.g. pending or completed), and date and time of the change. This can be recorded in an audit trail of changes made or change control records; the approach to version control and unique referencing of TOE versions (e.g. covering the release of patches in operating systems, and the subsequent detection of their application). The evaluator shall check that the configuration items identified in the configuration list are being maintained by the CM system. The CM system employed by the developer should maintain the integrity of the TOE. The evaluator should check that for each type of configuration item (e.g. design documents or source code modules) contained in the configuration list there are examples of the evidence generated by the procedures described in the CM plan. In this case, the approach to sampling will depend upon the level of granularity used in the CM system to control CM items. Where, for example, 10,000 source code modules are identified in the configuration list, a different sampling strategy needs to be applied compared to the case in which there are only 5, or even 1. The emphasis of this activity should be on ensuring that the CM system is being operated correctly, rather than on the detection of any minor error. For guidance on sampling see A.2, Sampling. The evaluator shall check the CM documentation to ascertain that it includes the CM system records identified by the CM plan. The output produced by the CM system should provide the evidence that the evaluator needs to be confident that the CM plan is being applied, and also that all configuration items are being maintained by the CM system as required by . Example output can include change control forms, or configuration item access approval forms. The evaluator shall examine the evidence to determine that the CM system is being operated in accordance with the CM plan. The evaluator should select and examine a sample of evidence covering each type of CM-relevant operation that has been performed on a configuration item (e.g. creation, modification, deletion, reversion to an earlier version) to confirm that all operations of the CM system have been carried out in line with documented procedures. The evaluator confirms that the evidence includes all the information identified for that operation in the CM plan. Examination of the evidence may require access to a CM tool that is used. The evaluator may choose to sample the evidence. For guidance on sampling see A.2, Sampling. Further confidence in the correct operation of the CM system and the effective maintenance of configuration items may be established by means of interviews with selected development staff. In conducting such interviews, the evaluator aims to gain a deeper understanding of how the CM system is used in practise as well as to confirm that the CM procedures are being applied as described in the CM documentation. Note that such interviews should complement rather than replace the examination of documentary evidence, and may not be necessary if the documentary evidence alone satisfies the requirement. However, given the wide scope of the CM plan it is possible that some aspects (e.g. roles and responsibilities) may not be clear from the CM plan and records alone. This is one case where clarification may be necessary through interviews. It is expected that the evaluator will visit the development site in support of this activity. For guidance on site visits see A.4, Site Visits. The objectives of this sub-activity are to determine whether the developer has clearly identified the TOE and its associated configuration items, and whether the ability to modify these items is properly controlled by automated tools, thus making the CM system less susceptible to human error or negligence. the ST; the TOE suitable for testing; the configuration management documentation. The developer shall provide the TOE and a unique reference for the TOE. The developer shall provide the CM documentation. The developer shall use a CM system. The TOE shall be labelled with its unique reference. The CM documentation shall describe the method or methods used to uniquely identify the configuration items. The CM system shall uniquely identify all configuration items. The CM system shall provide automated controls such that only authorized changes are made to the configuration items. The CM system shall support the production of the TOE by automated means. The CM documentation shall include a CM plan. The CM plan shall describe how the CM system is used for the development of the TOE. The CM plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE. The evidence shall demonstrate that all configuration items are being maintained under the CM system. The evidence shall demonstrate that the CM system is being operated in accordance with the CM plan. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the TOE provided for evaluation is labelled with its reference. The evaluator should ensure that the TOE contains the unique reference which is stated in the ST. This can be achieved through labelled packaging or media, or by a label displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the TOE (e.g. at the point of purchase or use). The TOE may provide a method by which it can be easily identified. For example, a software TOE may display its name and version number during the start up routine, or in response to a command line entry. A hardware or firmware TOE may be identified by a part number physically stamped on the TOE. Alternatively, the unique reference provided for the TOE may be the combination of the unique reference of each component from which the TOE is comprised (e.g. in the case of a composed TOE). The evaluator shall check that the TOE references used are consistent. If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible to relate any labelled guidance documentation supplied as part of the TOE to the evaluated operational TOE. This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, that they have installed this version, and that they have the correct version of the guidance to operate the TOE in accordance with its ST. The evaluator also verifies that the TOE reference is consistent with the ST. If this work unit is applied to a composed TOE, the following will apply. The composed TOE will not be labelled with its unique (composite) reference, but only the individual components will be labelled with their appropriate TOE reference. It would require further development for the composed TOE to be labelled, i.e. during start-up and/or operation, with the composite reference. If the composed TOE is delivered as the constituent component TOEs, then the TOE items delivered will not contain the composite reference. However, the composed TOE ST will include the unique reference for the composed TOE and will identify the components comprising the composed TOE through which the consumers will be able to determine whether they have the appropriate items. The evaluator shall examine the method of identifying configuration items to determine that it describes how configuration items are uniquely identified. Procedures should describe how the status of each configuration item can be tracked throughout the life-cycle of the TOE. The procedures may be detailed in the CM plan or throughout the CM documentation. The information included should describe: the method how each configuration item is uniquely identified, such that it is possible to track versions of the same configuration item; the method how configuration items are assigned unique identifiers and how they are entered into the CM system; the method to be used to identify superseded versions of a configuration item. The evaluator shall examine the configuration items to determine that they are identified in a way that is consistent with the CM documentation. Assurance that the CM system uniquely identifies all configuration items is gained by examining the identifiers for the configuration items. For configuration items identified under , the evaluator confirms that each configuration item possesses a unique identifier in a manner consistent with the unique identification method that is described in the CM documentation. The evaluator shall examine the CM access control measures described in the CM plan (cf. ) to determine that they are automated and effective in preventing unauthorized access to the configuration items. The evaluator may use a number of methods to determine that the CM access control measures are effective. For example, the evaluator may exercise the access control measures to ensure that the procedures cannot be bypassed. The evaluator may use the outputs generated by the CM system procedures required by . The evaluator may also witness a demonstration of the CM system to ensure that the access control measures employed are operating effectively. The evaluator shall check the CM plan (cf.) for automated procedures for supporting the production of the TOE. The term "production" applies to those processes adopted by the developer to progress the TOE from the implementation representation to a state acceptable for delivery to the end customer. The evaluator verifies the existence of automated production support procedures within the CM plan. The following are examples for automated means supporting the production of the TOE: a "make" tool (as provided with many software development tools) in the case of a software TOE; a tool ensuring automatically (for example by means of bar codes) that only parts are combined which indeed belong together in the case of a hardware TOE. The evaluator shall examine the TOE production support procedures to determine that they are effective in ensuring that a TOE is generated that reflects its implementation representation. The production support procedures should describe which tools have to be used to produce the final TOE from the implementation representation in a clearly defined way. The conventions, directives, or other necessary constructs are described under . The evaluator determines that by following the production support procedures the correct configuration items would be used to generate the TOE. For example, in a software TOE this may include checking that the automated production procedures ensure that all source files and related libraries are included in the compiled object code. Moreover, the procedures should ensure that compiler options and comparable other options are defined uniquely. For a hardware TOE, this work unit may include checking that the automatic production procedures ensure that the belonging parts are built together and no parts are missing. The customer can then be confident that the version of the TOE delivered for installation is derived from the implementation representation in an unambiguous way and implements the SFRs as described in the ST. The evaluator should bear in mind that the CM system need not necessarily possess the capability to produce the TOE, but should provide support for the process that will help reduce the probability of human error. The evaluator shall check that the CM documentation provided includes a CM plan. The CM plan does not need to be contained within a single document, but it is recommended that there is a separate document that describes where the various parts of the CM plan can be found. If the CM plan is provided by a set of documents, the list in the following work unit gives guidance regarding the required content. The evaluator shall examine the CM plan to determine that it describes how the CM system is used for the development of the TOE. The descriptions contained in a CM plan include, if applicable: all activities performed in the TOE development that are subject to configuration management procedures (e.g. creation, modification or deletion of a configuration item, data-backup, archiving); which means (e.g. CM tools, forms) have to be made available; the usage of the CM tools: the necessary details for a user of the CM system to be able to operate the CM tools correctly in order to maintain the integrity of the TOE; the production support procedures; which other objects (development components, tools, assessment environments) are taken under CM control; the roles and responsibilities of individuals required to perform operations on individual configuration items (different roles may be identified for different types of configuration items, e.g. design documentation or source code); how CM instances (e.g. change control boards, interface control working groups) are introduced and staffed; the description of the change management; the procedures that are used to ensure that only authorized individuals can make changes to configuration items; the procedures that are used to ensure that concurrency problems do not occur as a result of simultaneous changes to configuration items; the evidence that is generated as a result of application of the procedures. For example, for a change to a configuration item, the CM system can record a description of the change, accountability for the change, identification of all configuration items affected, status (e.g. pending or completed), and date and time of the change. This can be recorded in an audit trail of changes made or change control records; the approach to version control and unique referencing of TOE versions (e.g. covering the release of patches in operating systems, and the subsequent detection of their application). The evaluator shall examine the CM plan to determine that it describes the procedures used to accept modified or newly created configuration items as parts of the TOE. The descriptions of the acceptance procedures in the CM plan should include the developer roles or individuals responsible for the acceptance and the criteria to be used for acceptance. In order to meet the desired assurance level, the acceptance criteria may include a suite of tests that determines whether the required security objective and/or performance objective is met. The criteria should take into account all acceptance situations that may occur, in particular: accepting an item into the CM system for the first time, in particular inclusion of software, firmware and hardware components from other manufacturers into the TOE ("integration"); moving configuration items to the next life-cycle phase at each stage of the construction of the TOE (e.g. module, subsystem, system); subsequent to transports between different development sites. If this work unit is applied to a dependent component that is going to be integrated in a composed TOE, the CM plan should consider the control of base components obtained by the dependent TOE developer. When obtaining the components the evaluators are to verify the following: Transfer of each base component from the base component developer to the integrator (dependent TOE developer) was performed in accordance with the base component TOE's secure delivery procedures, as reported in the base component TOE certification report. The component received has the same identifiers as those stated in the ST and Certification Report for the component TOE. All additional material required by a developer for composition (integration) is provided. This is to include the necessary extract of the component TOE's functional specification. The evaluator shall check that the configuration items identified in the configuration list are being maintained by the CM system. The CM system employed by the developer should maintain the integrity of the TOE. The evaluator should check that for each type of configuration item (e.g. design documents or source code modules) contained in the configuration list there are examples of the evidence generated by the procedures described in the CM plan. In this case, the approach to sampling will depend upon the level of granularity used in the CM system to control CM items. Where, for example, 10,000 source code modules are identified in the configuration list, a different sampling strategy needs to be applied compared to the case in which there are only 5, or even 1. The emphasis of this activity should be on ensuring that the CM system is being operated correctly, rather than on the detection of any minor error. For guidance on sampling see A.2, Sampling. The evaluator shall check the CM documentation to ascertain that it includes the CM system records identified by the CM plan. The output produced by the CM system should provide the evidence that the evaluator needs to be confident that the CM plan is being applied, and also that all configuration items are being maintained by the CM system as required by . Example output can include change control forms, or configuration item access approval forms. The evaluator shall examine the evidence to determine that the CM system is being operated in accordance with the CM plan. The evaluator should select and examine a sample of evidence covering each type of CM-relevant operation that has been performed on a configuration item (e.g. creation, modification, deletion, reversion to an earlier version) to confirm that all operations of the CM system have been carried out in line with documented procedures. The evaluator confirms that the evidence includes all the information identified for that operation in the CM plan. Examination of the evidence may require access to a CM tool that is used. The evaluator may choose to sample the evidence. For guidance on sampling see A.2, Sampling. Further confidence in the correct operation of the CM system and the effective maintenance of configuration items may be established by means of interviews with selected development staff. In conducting such interviews, the evaluator aims to gain a deeper understanding of how the CM system is used in practise as well as to confirm that the CM procedures are being applied as described in the CM documentation. Note that such interviews should complement rather than replace the examination of documentary evidence, and may not be necessary if the documentary evidence alone satisfies the requirement. However, given the wide scope of the CM plan it is possible that some aspects (e.g. roles and responsibilities) may not be clear from the CM plan and records alone. This is one case where clarification may be necessary through interviews. It is expected that the evaluator will visit the development site in support of this activity. For guidance on site visits see A.4, Site Visits. The objectives of this sub-activity are to determine whether the developer has clearly identified the TOE and its associated configuration items, and whether the ability to modify these items is properly controlled by automated tools, thus making the CM system less susceptible to human error or negligence. the ST; the TOE suitable for testing; the configuration management documentation. The developer shall provide the TOE and a unique reference for the TOE. The developer shall provide the CM documentation. The developer shall use a CM system. The TOE shall be labelled with its unique reference. The CM documentation shall describe the method used to uniquely identify the configuration items. The CM documentation shall justify that the acceptance procedures provide for an adequate and appropriate review of changes to all configuration items. The CM system shall uniquely identify all configuration items. The CM system shall provide automated controls such that only authorized changes are made to the configuration items. The CM system shall support the production of the TOE by automated means. The CM system shall ensure that the person responsible for accepting a configuration item into CM is not the person who developed it. The CM system shall identify the configuration items that comprise the TSF. The CM system shall support the audit of all changes to the TOE by automated means, including the originator, date, and time in the audit trail. The CM system shall provide an automated means to identify all other configuration items that are affected by the change of a given configuration item. The CM system shall be able to identify the version of the implementation representation from which the TOE is generated. The CM documentation shall include a CM plan. The CM plan shall describe how the CM system is used for the development of the TOE. The CM plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE. The evidence shall demonstrate that all configuration items are being maintained under the CM system. The evidence shall demonstrate that the CM system is being operated in accordance with the CM plan. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the TOE provided for evaluation is labelled with its reference. The evaluator should ensure that the TOE contains the unique reference which is stated in the ST. This can be achieved through labelled packaging or media, or by a label displayed by the operational TOE. This is to ensure that it would be possible for consumers to identify the TOE (e.g. at the point of purchase or use). The TOE may provide a method by which it can be easily identified. For example, a software TOE may display its name and version number during the start up routine, or in response to a command line entry. A hardware or firmware TOE may be identified by a part number physically stamped on the TOE. Alternatively, the unique reference provided for the TOE may be the combination of the unique reference of each component from which the TOE is comprised (e.g. in the case of a composed TOE). The evaluator shall check that the TOE references used are consistent. If the TOE is labelled more than once then the labels have to be consistent. For example, it should be possible to relate any labelled guidance documentation supplied as part of the TOE to the evaluated operational TOE. This ensures that consumers can be confident that they have purchased the evaluated version of the TOE, that they have installed this version, and that they have the correct version of the guidance to operate the TOE in accordance with its ST. The evaluator also verifies that the TOE reference is consistent with the ST. If this work unit is applied to a composed TOE, the following will apply. The composed IT TOE will not be labelled with its unique (composite) reference, but only the individual components will be labelled with their appropriate TOE reference. It would require further development for the IT TOE to be labelled, i.e. during start-up and/or operation, with the composite reference. If the composed TOE is delivered as the constituent component TOEs, then the TOE items delivered will not contain the composite reference. However, the composed TOE ST will include the unique reference for the composed TOE and will identify the components comprising the composed TOE through which the consumers will be able to determine whether they have the appropriate items. The evaluator shall examine the method of identifying configuration items to determine that it describes how configuration items are uniquely identified. Procedures should describe how the status of each configuration item can be tracked throughout the life-cycle of the TOE. The procedures may be detailed in the CM plan or throughout the CM documentation. The information included should describe: the method how each configuration item is uniquely identified, such that it is possible to track versions of the same configuration item; the method how configuration items are assigned unique identifiers and how they are entered into the CM system; the method to be used to identify superseded versions of a configuration item. The evaluator shall examine the CM documentation to determine that it justifies that the acceptance procedures provide for an adequate and appropriate review of changes to all configuration items. The CM documentation should make it sufficiently clear that by following the acceptance procedures only parts of adequate quality are incorporated into the TOE. The evaluator shall examine the configuration items to determine that they are identified in a way that is consistent with the CM documentation. Assurance that the CM system uniquely identifies all configuration items is gained by examining the identifiers for the configuration items. For both configuration items that comprise the TOE, and drafts of configuration items that are submitted by the developer as evaluation evidence, the evaluator confirms that each configuration item possesses a unique identifier in a manner consistent with the unique identification method that is described in the CM documentation. The evaluator shall examine the CM access control measures described in the CM plan (cf. ) to determine that they are automated and effective in preventing unauthorized access to the configuration items. The evaluator may use a number of methods to determine that the CM access control measures are effective. For example, the evaluator may exercise the access control measures to ensure that the procedures cannot be bypassed. The evaluator may use the outputs generated by the CM system procedures required by . The evaluator may also witness a demonstration of the CM system to ensure that the access control measures employed are operating effectively. The evaluator shall check the CM plan (cf. ) for automated procedures for supporting the production of the TOE. The term "production" applies to those processes adopted by the developer to progress the TOE from the implementation representation to a state acceptable for delivery to the end customer. The evaluator verifies the existence of automated production support procedures within the CM plan. The following are examples for automated means supporting the production of the TOE: a "make" tool (as provided with many software development tools) in the case of a software TOE; a tool ensuring automatically (for example by means of bar codes) that only parts are combined which indeed belong together in the case of a hardware TOE. The evaluator shall examine the TOE production support procedures to determine that they are effective in ensuring that a TOE is generated that reflects its implementation representation. The production support procedures should describe which tools have to be used to produce the final TOE from the implementation representation in a clearly defined way. The conventions, directives, or other necessary constructs are described under . The evaluator determines that by following the production support procedures the correct configuration items would be used to generate the TOE. For example, in a software TOE this may include checking that the automated production procedures ensure that all source files and related libraries are included in the compiled object code. Moreover, the procedures should ensure that compiler options and comparable other options are defined uniquely. For a hardware TOE, this work unit may include checking that the automatic production procedures ensure that the belonging parts are built together and no parts are missing. The customer can then be confident that the version of the TOE delivered for installation is derived from the implementation representation in an unambiguous way and implements the SFRs as described in the ST. The evaluator should bear in mind that the CM system need not necessarily possess the capability to produce the TOE, but should provide support for the process that will help reduce the probability of human error. The evaluator shall examine the CM system to determine that it ensures that the person responsible for accepting a configuration item is not the person who developed it. The acceptance procedures describe who is responsible for accepting a configuration item. From these descriptions, the evaluator should be able to determine that the person who developed a configuration item is in no case responsible for its acceptance. The evaluator shall examine the CM system to determine that it identifies the configuration items that comprise the TSF. The CM documentation should describe how the CM system identifies the configuration items that comprise the TSF. The evaluator should select a sample of configuration items covering each type of items, particularly containing TSF and non-TSF items, and check that they are correctly classified by the CM system. For guidance on sampling see A.2, Sampling. The evaluator shall examine the CM system to determine that it supports the audit of all changes to the TOE by automated means, including the originator, date, and time in the audit trail. The evaluator should inspect a sample of audit trails and check, if they contain the minimum information. The evaluator shall examine the CM system to determine that it provides an automated means to identify all other configuration items that are affected by the change of a given configuration item. The CM documentation should describe how the CM system identifies all other configuration items that are affected by the change of a given configuration item. The evaluator should select a sample of configuration items, covering all types of items, and exercise the automated means to determine that it identifies all items that are affected by the change of the selected item. For guidance on sampling see A.2, Sampling. The evaluator shall examine the CM system to determine that it is able to identify the version of the implementation representation from which the TOE is generated. The CM documentation should describe how the CM system identifies the version of the implementation representation from which the TOE is generated. The evaluator should select a sample of the parts used to produce the TOE and should apply the CM system to verify that it identifies the corresponding implementation representation in the correct version. For guidance on sampling see A.2, Sampling. The evaluator shall check that the CM documentation provided includes a CM plan. The CM plan needs not to be a connected document, but it is recommended that there is a single document that describes where the various parts of the CM plan can be found. If the CM plan is no single document, the list in the following work unit gives hints regarding which context is expected. The evaluator shall examine the CM plan to determine that it describes how the CM system is used for the development of the TOE. The descriptions contained in a CM plan include, if applicable: all activities performed in the TOE development that are subject to configuration management procedures (e.g. creation, modification or deletion of a configuration item, data-backup, archiving); which means (e.g. CM tools, forms) have to be made available; the usage of the CM tools: the necessary details for a user of the CM system to be able to operate the CM tools correctly in order to maintain the integrity of the TOE; the production support procedures; which other objects (development components, tools, assessment environments) are taken under CM control; the roles and responsibilities of individuals required to perform operations on individual configuration items (different roles may be identified for different types of configuration items, e.g. design documentation or source code); how CM instances (e.g. change control boards, interface control working groups) are introduced and staffed; the description of the change management; the procedures that are used to ensure that only authorized individuals can make changes to configuration items; the procedures that are used to ensure that concurrency problems do not occur as a result of simultaneous changes to configuration items; the evidence that is generated as a result of application of the procedures. For example, for a change to a configuration item, the CM system can record a description of the change, accountability for the change, identification of all configuration items affected, status (e.g. pending or completed), and date and time of the change. This can be recorded in an audit trail of changes made or change control records; the approach to version control and unique referencing of TOE versions (e.g. covering the release of patches in operating systems, and the subsequent detection of their application). The evaluator shall examine the CM plan to determine that it describes the procedures used to accept modified or newly created configuration items as parts of the TOE. The descriptions of the acceptance procedures in the CM plan should include the developer roles or individuals responsible for the acceptance and the criteria to be used for acceptance. In order to meet the desired assurance level, the acceptance criteria may include a suite of tests that determines whether the required security objective and/or performance objective is met. The criteria should take into account all acceptance situations that may occur, in particular: accepting an item into the CM system for the first time, in particular inclusion of software, firmware and hardware components from other manufacturers into the TOE ("integration"); moving configuration items to the next life-cycle phase at each stage of the construction of the TOE (e.g. module, subsystem, system); subsequent to transports between different development sites. If this work unit is applied to a dependent component that is going to be integrated in a composed TOE, the CM plan should consider the control of base components obtained by the dependent TOE developer. When obtaining the components the evaluators are to verify the following: Transfer of each base component from the base component developer to the integrator (dependent TOE developer) was performed in accordance with the base component TOE's secure delivery procedures, as reported in the base component TOE certification report. The component received has the same identifiers as those stated in the ST and Certification Report for the component TOE. All additional material required by a developer for composition (integration) is provided. This is to include the necessary extract of the component TOE's functional specification. The evaluator shall check that the configuration items identified in the configuration list are being maintained by the CM system. The CM system employed by the developer should maintain the integrity of the TOE. The evaluator should check that for each type of configuration item (e.g. design documents or source code modules) contained in the configuration list there are examples of the evidence generated by the procedures described in the CM plan. In this case, the approach to sampling will depend upon the level of granularity used in the CM system to control CM items. Where, for example, 10,000 source code modules are identified in the configuration list, a different sampling strategy needs to be applied compared to the case in which there are only 5, or even 1. The emphasis of this activity should be on ensuring that the CM system is being operated correctly, rather than on the detection of any minor error. For guidance on sampling see A.2, Sampling. The evaluator shall check the CM documentation to ascertain that it includes the CM system records identified by the CM plan. The output produced by the CM system should provide the evidence that the evaluator needs to be confident that the CM plan is being applied, and also that all configuration items are being maintained by the CM system as required by . Example output can include change control forms, or configuration item access approval forms. The evaluator shall examine the evidence to determine that the CM system is being operated in accordance with the CM plan. The evaluator should select and examine a sample of evidence covering each type of CM-relevant operation that has been performed on a configuration item (e.g. creation, modification, deletion, reversion to an earlier version) to confirm that all operations of the CM system have been carried out in line with documented procedures. The evaluator confirms that the evidence includes all the information identified for that operation in the CM plan. Examination of the evidence may require access to a CM tool that is used. The evaluator may choose to sample the evidence. For guidance on sampling see A.2, Sampling. Further confidence in the correct operation of the CM system and the effective maintenance of configuration items may be established by means of interviews with selected development staff. In conducting such interviews, the evaluator aims to gain a deeper understanding of how the CM system is used in practise as well as to confirm that the CM procedures are being applied as described in the CM documentation. Note that such interviews should complement rather than replace the examination of documentary evidence, and may not be necessary if the documentary evidence alone satisfies the requirement. However, given the wide scope of the CM plan it is possible that some aspects (e.g. roles and responsibilities) may not be clear from the CM plan and records alone. This is one case where clarification may be necessary through interviews. It is expected that the evaluator will visit the development site in support of this activity. For guidance on site visits see A.4, Site Visits. The evaluator shall determine that the application of the production support procedures results in a TOE as provided by the developer for testing activities. The evaluator shall examine the production support procedures to determine that by following these procedures a TOE would be produced like that one provided by the developer for testing activities. If the TOE is a small software TOE and production consists of compiling and linking, the evaluator can confirm the adequacy of the production support procedures by reapplying them. If the production process of the TOE is more complicated (as for example in the case of a smart card), but has already started, the evaluator should inspect the application of the production support procedures during a visit of the development site. They can compare a copy of the TOE produced in their presence with the samples used for their testing activities. For guidance on site visits see A.4, Site Visits. Otherwise the evaluator's determination should be based on the documentary evidence provided by the developer. This work unit may be performed in conjunction with the evaluation activities under . The objective of this family is to identify items to be included as configuration items and hence placed under the CM requirements of . Applying configuration management to these additional items provides additional assurance that the integrity of TOE is maintained. The components in this family are levelled on the basis of which of the following are required to be included as configuration items: the TOE and the evaluation evidence required by the SARs; the parts of the TOE; the implementation representation; security flaws; and development tools and related information. While mandates a list of configuration items and that each item on this list be under CM, leaves the contents of the configuration list to the discretion of the developer. narrows this discretion by identifying items that must be included in the configuration list, and hence come under the CM requirements of . The objective of this sub-activity is to determine whether the developer performs configuration management on the TOE and the evaluation evidence. These configuration items are controlled in accordance with . the ST; the configuration list. The developer shall provide a configuration list for the TOE. The configuration list shall include the following: the TOE itself; and the evaluation evidence required by the SARs. The configuration list shall uniquely identify the configuration items. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the configuration list includes the following set of items: the TOE itself; the evaluation evidence required by the SARs in the ST. The evaluator shall examine the configuration list to determine that it uniquely identifies each configuration item. The configuration list contains sufficient information to uniquely identify which version of each item has been used (typically a version number). Use of this list will enable the evaluator to check that the correct configuration items, and the correct version of each item, have been used during the evaluation. The objective of this sub-activity is to determine whether the configuration list includes the TOE, the parts that comprise the TOE, and the evaluation evidence. These configuration items are controlled in accordance with . the ST; the configuration list. The developer shall provide a configuration list for the TOE. The configuration list shall include the following: the TOE itself; the evaluation evidence required by the SARs; and the parts that comprise the TOE. The configuration list shall uniquely identify the configuration items. For each TSF relevant configuration item, the configuration list shall indicate the developer of the item. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the configuration list includes the following set of items: the TOE itself; the parts that comprise the TOE; the evaluation evidence required by the SARs. The evaluator shall examine the configuration list to determine that it uniquely identifies each configuration item. The configuration list contains sufficient information to uniquely identify which version of each item has been used (typically a version number). Use of this list will enable the evaluator to check that the correct configuration items, and the correct version of each item, have been used during the evaluation. The evaluator shall check that the configuration list indicates the developer of each TSF relevant configuration item. If only one developer is involved in the development of the TOE, this work unit is not applicable, and is therefore considered to be satisfied. The objective of this sub-activity is to determine whether the configuration list includes the TOE, the parts that comprise the TOE, the TOE implementation representation, and the evaluation evidence. These configuration items are controlled in accordance with . the ST; the configuration list. The developer shall provide a configuration list for the TOE. The configuration list shall include the following: the TOE itself; the evaluation evidence required by the SARs; the parts that comprise the TOE; and the implementation representation. The configuration list shall uniquely identify the configuration items. For each TSF relevant configuration item, the configuration list shall indicate the developer of the item. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the configuration list includes the following set of items: the TOE itself; the parts that comprise the TOE; the TOE implementation representation; the evaluation evidence required by the SARs in the ST. The evaluator shall examine the configuration list to determine that it uniquely identifies each configuration item. The configuration list contains sufficient information to uniquely identify which version of each item has been used (typically a version number). Use of this list will enable the evaluator to check that the correct configuration items, and the correct version of each item, have been used during the evaluation. The evaluator shall check that the configuration list indicates the developer of each TSF relevant configuration item. If only one developer is involved in the development of the TOE, this work unit is not applicable, and is therefore considered to be satisfied. The objective of this sub-activity is to determine whether the configuration list includes the TOE, the parts that comprise the TOE, the TOE implementation representation, security flaws, and the evaluation evidence. These configuration items are controlled in accordance with . the ST; the configuration list. The developer shall provide a configuration list for the TOE. The configuration list shall include the following: the TOE itself; the evaluation evidence required by the SARs; the parts that comprise the TOE; the implementation representation; and security flaw reports and resolution status. The configuration list shall uniquely identify the configuration items. For each TSF relevant configuration item, the configuration list shall indicate the developer of the item. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the configuration list includes the following set of items: the TOE itself; the parts that comprise the TOE; the TOE implementation representation; the evaluation evidence required by the SARs in the ST; the documentation used to record details of reported security flaws associated with the implementation (e.g., problem status reports derived from a developer's problem database). The evaluator shall examine the configuration list to determine that it uniquely identifies each configuration item. The configuration list contains sufficient information to uniquely identify which version of each item has been used (typically a version number). Use of this list will enable the evaluator to check that the correct configuration items, and the correct version of each item, have been used during the evaluation. The evaluator shall check that the configuration list indicates the developer of each TSF relevant configuration item. If only one developer is involved in the development of the TOE, this work unit is not applicable, and is therefore considered to be satisfied. The objective of this sub-activity is to determine whether the configuration list includes the TOE, the parts that comprise the TOE, the TOE implementation representation, security flaws, development tools and related information, and the evaluation evidence. These configuration items are controlled in accordance with . the ST; the configuration list. The developer shall provide a configuration list for the TOE. The configuration list shall include the following: the TOE itself; the evaluation evidence required by the SARs; the parts that comprise the TOE; the implementation representation; security flaw reports and resolution status; and development tools and related information. The configuration list shall uniquely identify the configuration items. For each TSF relevant configuration item, the configuration list shall indicate the developer of the item. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the configuration list includes the following set of items: the TOE itself; the parts that comprise the TOE; the TOE implementation representation; the evaluation evidence required by the SARs in the ST; the documentation used to record details of reported security flaws associated with the implementation (e.g., problem status reports derived from a developer's problem database); all tools (incl. test software, if applicable) involved in the development and production of the TOE including the names, versions, configurations and roles of each development tool, and related documentation. For a software TOE, "development tools" are usually programming languages and compiler and "related documentation" comprises compiler and linker options. For a hardware TOE, "development tools" can be hardware design languages, simulation and synthesis tools, compilers, and "related documentation" can comprise compiler options again. The evaluator shall examine the configuration list to determine that it uniquely identifies each configuration item. The configuration list contains sufficient information to uniquely identify which version of each item has been used (typically a version number). Use of this list will enable the evaluator to check that the correct configuration items, and the correct version of each item, have been used during the evaluation. The evaluator shall check that the configuration list indicates the developer of each TSF relevant configuration item. If only one developer is involved in the development of the TOE, this work unit is not applicable, and is therefore considered to be satisfied. The aim of this family is to determine whether the correct version of the dependent component is installed onto / embedded into the correct version of the related base component, and the preparative guidance procedures of the base component developer and the dependent component developer are compatible with the acceptance procedures of the composite product integrator. This family contains only one component. The composite product evaluator shall verify that the correct version of the dependent component under evaluation has been installed onto / embedded into the evaluated version of the related base component of the composite product. The composite product evaluation sponsor shall ensure that appropriate evidence generated by the composite product integrator is available for the composite product evaluator. This evidence may include, amongst other, the configuration list of the base component developer (e.g. provided within his acknowledgement statement). The composite product evaluator shall verify that the delivery procedures of the base component developer and the dependent component developer are compatible with the acceptance procedures used by the composite product integrator. The composite product evaluator shall verify that all configuration parameters prescribed by the base component developer and the dependent component developer (e.g. pre-personalization data, pre-personalisation scripts) are used by the composite product integrator. The composite product evaluation sponsor shall ensure that appropriate evidence generated by the composite product integrator is available for the composite product evaluator. This evidence may include, amongst other, the element of evidence for the dependent component reception, acceptance and parameterisation by the base component developer (e.g. in form of his acknowledgement statement). The aim of this activity is to determine whether: the correct version of the dependent component is installed onto/ embedded into the correct version of the related base component, and the preparative guidance procedures of the base component developer and the dependent component developer are compatible with the acceptance procedures of the composite product integrator. The composite product evaluator shall verify that the correct version of the dependent component under evaluation has been installed onto / embedded into the evaluated version of the related base component of the composite product. The composite product evaluation sponsor shall ensure that appropriate evidence generated by the composite product integrator is available for the composite product evaluator. This evidence may include, amongst other items, the configuration list of the base component developer (e.g. provided within his acknowledgement statement). The composite product evaluator shall verify that the delivery procedures of the base component developer and the dependent component developer are compatible with the acceptance procedures used by the composite product integrator. The composite product evaluator shall verify that all configuration parameters prescribed by the base component developer and the dependent component developer (e.g. pre-personalization data, pre-personalisation scripts) are used by the composite product integrator. The composite product evaluation sponsor shall ensure that appropriate evidence generated by the composite product integrator is available for the composite product evaluator. This evidence may include, amongst other items, the element of evidence for the dependent component reception, acceptance and parameterisation by the base component developer (e.g. in form of his acknowledgement statement). The developer shall provide components configuration evidence. The components configuration evidence shall show that the evaluated version of the dependent component has been installed onto / embedded into the evaluated version of the related base component. The components configuration evidence shall show that: The evidence for delivery and acceptance compatibility shall show that the delivery procedures of the base component developer and the dependent component developer are compatible with the acceptance procedures of the composite product integrator. The evidence shall show that preparative guidance procedures prescribed by the base component developer and the dependent component developer are either actually being used by the composite product integrator or compatible with the composite product integrator guidance and do not contradict each other. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the evidence that the evaluated version of the dependent component has been installed onto / embedded into the correct evaluated version of the related base component. From the perspective of the composite evaluation it is important that the correct evaluated version of the dependent component and base component are used. The documentation of the base component provided by the base component developer contains requirements for the secure acceptance procedure of the base component and security measures to which the dependent component developer or composite product integrator shall adhere. The dependent component developer shall provide evidence that (if applicable), these requirements are followed up and the required security measures are implemented. The special composite product evaluator activity is to check the evidence of the version correctness for both parts of the composite product and that the secure acceptance and installation of the base component has been performed. For the base component, the evaluator shall determine that the actual identification of the base component is commensurate with the expected evaluated data of the base component evaluation as part of following up on the procedures as specified in the of the base component. For the dependent component, the relevant task is trivial due to the fact that the composite product evaluator shall perform this task in the context of the assurance family . Components identification evidence can be supplied in two different ways: technical and organisational. A technical evidence of version correctness is being generated by the composite product itself: the base component and the dependent component return, in each case, strings containing unambiguous version numbers as answers to the respective commands. For example, it can be the return string of a command or the hard copy of the Windows Information (like "About"); in case of smart cards it can be an appropriate ATR. Technical evidence of version correctness for hardware can also be supplied, if applicable, by reading out the unambiguous inscription on its surface. Note that there is no physical indication existing on most smart card's microcontrollers. Technical evidence is recommended to be provided. An organisational evidence of version correctness is being generated by the composite product integrator on the basis of his configuration lists containing unambiguous version information of the base component and the dependent component having been composed into the final composite product. For example, in case of smart cards it can be an acknowledgement statement (e.g. configuration list) of the underlying platform (base component) manufacturer to the application software (dependent component) manufacturer containing the evidence for the versions of the platform, any embedded software and its pre-personalisation parameters. Organisational evidence is always possible and, hence, shall be provided. The result of this work unit shall be integrated to the result of / (or the equivalent higher components if a higher assurance level is selected). The evaluator shall confirm that the evidence for delivery compatibility is complete, coherent, and internally consistent. The evaluator shall examine the acceptance procedures of the composite product integrator, the delivery procedures of the base component developer and the dependent component developer to see that they are compatible and where necessary either applied by the composite product integrator or prescribed in the preparative guidance. The general information of the preparative guidance requirements that amongst others includes configuration parameters is represented and shall be examined in the context of the assurance family [1.2C]. The special evaluator activity is to examine the developer's evidence and to decide whether the composite product integrator appropriately treats this special subset of the preparative guidance requirements. The evaluator shall examine this provided evidence which includes the check whether the delivery procedures of the base component developer and the dependent component developer are compatible with the acceptance procedures of the composite product integrator. In the cases where the composite product integrator leaves preparative guidance requirements prescribed by the base component developer and the dependent component developer to the user, the composite product evaluator verifies that such requirements are presented in the preparative guidance of the composite evaluation. For example, for a Java Card as a composite product, the Card Issuer shall set all parameters as prescribed by the Java Card Platform (base component) developer and the Applet (dependent component) developer while installing the Applet onto the Java Card Platform. Also, the Card Issuer shall verify that the package is byte-code-verified and has a valid digital signature. The result of this work unit shall be integrated to the result of / and / . The concern of this family is the secure transfer of the finished TOE from the development environment into the responsibility of the user. The requirements for delivery call for system control and distribution facilities and procedures that detail the controls necessary to provide assurance that the security of the TOE is maintained during distribution of the TOE to the user. For a valid distribution of the TOE, the procedures used for the distribution of the TOE address the implied or identified objectives identified in the PP/ST relating to the security of the TOE during delivery. This family contains only one component. An increasing level of protection for the TOE is established by requiring that the delivery procedures are commensurate with the assumed attack potential in the family specified in the ST. Transfers from subcontractors to the developer or between different development sites are not considered here, but in the family . The end of the delivery phase is marked by the acceptance of the transfer of the TOE into the responsibility of the downstream user. This does not necessarily coincide with the arrival of the TOE at the downstream user's location. The delivery procedures should consider, if applicable, issues such as: ensuring that the TOE received by the consumer corresponds precisely to the evaluated version of the TOE; avoiding or detecting any tampering with the actual version of the TOE; preventing submission of a counterfeit version of the TOE; avoiding unwanted knowledge of distribution of the TOE to the consumer: there can be cases where potential attackers should not know when and how it is delivered; avoiding or detecting the TOE being intercepted during delivery; and avoiding the TOE being delayed or stopped during distribution. The delivery procedures should include the recipient's actions implied by these issues. The consistent description of these implied actions is examined in the family, if present. The objective of this sub-activity is to determine whether the delivery documentation describes all procedures used to maintain security of the TOE when distributing the TOE to the user. the ST; the delivery documentation. The developer shall document and provide procedures for delivery of the TOE or parts of it to the consumer. The developer shall use the delivery procedures. The evaluator shall examine aspects of the delivery process to determine that the delivery procedures are used. The approach taken by the evaluator to check the application of delivery procedures will depend on the nature of the TOE, and the delivery process itself. In addition to examination of the procedures themselves, the evaluator seeks some assurance that they are applied in practise. Some possible approaches are: a visit to the distribution site(s) where practical application of the procedures may be observed; examination of the TOE at some stage during delivery, or after the user has received it (e.g. checking for tamper proof seals); observing that the process is applied in practise when the evaluator obtains the TOE through regular channels; questioning end users as to how the TOE was delivered. For guidance on site visits see A.4, Site Visits. It may be the case of a newly developed TOE that the delivery procedures have yet to be exercised. In these cases, the evaluator has to be satisfied that appropriate procedures and facilities are in place for future deliveries and that all personnel involved are aware of their responsibilities. The evaluator may request a "dry run" of a delivery if this is practical. If the developer has produced other similar products, then an examination of procedures in their use may be useful in providing assurance. The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to the consumer. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the delivery documentation to determine that it describes all procedures that are necessary to maintain security when distributing versions of the TOE or parts of it to the consumer. The delivery documentation describes proper procedures to maintain security of the TOE during transfer of the TOE or its component parts and to determine the identification of the TOE. The delivery documentation should cover the entire TOE, but may contain different procedures for different parts of the TOE. The evaluation should consider the totality of procedures. The delivery procedures should be applicable across all phases of delivery from the production environment to the installation environment (e.g. packaging, storage and distribution). Standard commercial practise for packaging and delivery may be acceptable. This includes shrink wrapped packaging, a security tape or a sealed envelope. For the distribution, physical (e.g. public mail or a private distribution service) or electronic (e.g. electronic mail or downloading off the Internet) procedures may be used. Cryptographic checksums or a software signature may be used by the developer to ensure that tampering or masquerading can be detected. Tamper proof seals additionally indicate if the confidentiality has been broken. For software TOEs, confidentiality can be assured by using encryption. If availability is of concern, a secure transportation might be required. Interpretation of the term "necessary to maintain security" will need to consider: The nature of the TOE (e.g. whether it is software or hardware). The overall security level stated for the TOE by the chosen level of the Vulnerability Assessment. If the TOE is required to be resistant against attackers of a certain potential in its intended environment, this should also apply to the delivery of the TOE. The evaluator should determine that a balanced approach has been taken, such that delivery does not present a weak point in an otherwise secure development process. The security objectives provided by the ST. The emphasis in the delivery documentation is likely to be on measures related to integrity, as integrity of the TOE is always important. However, confidentiality and availability of the delivery will be of concern in the delivery of some TOEs; procedures relating to these aspects of the secure delivery should also be discussed in the procedures. Development security is concerned with the determination and specification of security controls relating to the developer provided environment. Such controls include coverage of security relevant aspects of asset management, human resources security, physical and environmental security, communications and operations management, access control, information systems acquisition, development and maintenance, information security incident management, and business continuity management. The components in this family are levelled on the basis of whether justification of the sufficiency of the security controls is required. This family deals with controls to remove or reduce threads and security risks existing at the developer's site. The evaluator should visit the site(s) in order to assess evidence for development security. This may include sites of subcontractors involved in the TOE development and production. Any decision not to visit shall be agreed with the evaluation authority. Although development security deals with the maintenance of the TOE and hence with aspects becoming relevant after the completion of the evaluation, the requirements specify only that the development security controls be in place at the time of evaluation. Furthermore, does not contain any requirements related to the sponsor's intention to apply the development security controls in the future, after completion of the evaluation. It is recognized that confidentiality may not always be an issue for the protection of the TOE in its development environment. The use of the word "necessary" allows for the selection of appropriate safeguards. The objective of this sub-activity is to determine whether the developer's security controls on the development environment are adequate to provide the confidentiality and integrity of the TOE design and implementation that is necessary to ensure that secure operation of the TOE is not compromised. the ST; the development security documentation. In addition, the evaluator may need to examine other deliverables to determine that the security controls are well-defined and followed. Specifically, the evaluator may need to examine the developer's configuration management documentation (the input for the Evaluation of sub-activity and the Evaluation of sub-activity ). Evidence that the procedures are being applied is also required. The developer shall produce and provide development security documentation. The development security documentation shall describe all the physical, logical, procedural, personnel, and other security controls that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the development security documentation to determine that it details all security measures used in the development environment that are necessary to protect the confidentiality and integrity of the TOE design and implementation. The evaluator determines what is necessary by first referring to the ST for any information that may assist in the determination of necessary protection. If no explicit information is available from the ST the evaluator will need to make a determination of the necessary measures. In cases where the developer's measures are considered less than what is necessary, a clear justification should be provided for the assessment, based on a potential exploitable vulnerability. The following types of security measures are considered by the evaluator when examining the documentation: physical, for example physical access controls used to prevent unauthorised access to the TOE development environment (during normal working hours and at other times); procedural, for example covering: granting of access to the development environment or to specific parts of the environment such as development machines, revocation of access rights when a person leaves the development team, transfer of protected material within and out of the development environment and between different development sites in accordance with defined acceptance procedures, admitting and escorting visitors to the development environment, roles and responsibilities in ensuring the continued application of security measures, and the detection of security breaches. personnel, for example any controls or checks made to establish the trustworthiness of new development staff; other security measures, for example the logical protections on any development machines. The development security documentation should identify the locations at which development occurs, and describe the aspects of development performed, along with the security measures applied at each location and for transports between different locations. For example, development can occur at multiple facilities within a single building, multiple buildings at the same site, or at multiple sites. Transports of parts of the TOE or the unfinished TOE between different development sites are to be covered by Development security , whereas the transport of the finished TOE to the consumer is dealt with in . Development includes the production of the TOE. The evaluator shall examine the development confidentiality and integrity policies in order to determine the sufficiency of the security measures employed. The evaluator should examine whether the following is included in the policies: what information relating to the TOE development needs to be kept confidential, and which members of the development staff are allowed to access such material; what material must be protected from unauthorized modification in order to preserve the integrity of the TOE, and which members of the development staff are allowed to modify such material. The evaluator should determine that these policies are described in the development security documentation, that the security measures employed are consistent with the policies, and that they are complete. It should be noted that configuration management procedures will help protect the integrity of the TOE and the evaluator should avoid overlap with the work-units conducted for the . For example, the CM documentation may describe the security procedures necessary for controlling the roles or individuals who should have access to the development environment and who may modify the TOE. Whereas the requirements are fixed, those for the Development security , mandating only necessary measures, are dependent on the nature of the TOE, and on information that may be provided in the ST. The evaluators would then determine that such a policy had been applied under this sub-activity. The evaluator shall confirm that the security controls are being applied. The evaluator shall examine the development security documentation and associated evidence to determine that the security measures are being applied. This work unit requires the evaluator to determine that the security measures described in the development security documentation are being followed, such that the integrity of the TOE and the confidentiality of associated documentation is being adequately protected. For example, this can be determined by examination of the documentary evidence provided. Documentary evidence should be supplemented by visiting the development environment. A visit to the development environment will allow the evaluator to: observe the application of security measures (e.g. physical measures); examine documentary evidence of application of procedures; interview development staff to check awareness of the development security policies and procedures, and their responsibilities. A development site visit is a useful means of gaining confidence in the measures being used. Any decision not to make such a visit should be determined in consultation with the evaluation authority. For guidance on site visits see A.4, Site Visits. The objective of this sub-activity is to determine whether the developer's security controls on the development environment are adequate to provide the confidentiality and integrity of the TOE design and implementation that is necessary to ensure that secure operation of the TOE is not compromised. Additionally, sufficiency of the measures as applied is intended be justified. the ST; the development security documentation. In addition, the evaluator may need to examine other deliverables to determine that the security controls are well-defined and followed. Specifically, the evaluator may need to examine the developer's configuration management documentation (the input for the Evaluation of sub-activity and the Evaluation of sub-activity ). Evidence that the procedures are being applied is also required. The developer shall produce and provide development security documentation. The development security documentation shall describe all the physical, procedural, personnel, and other security controls that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment. The development security documentation shall justify that the security controls provide the necessary level of protection to maintain the confidentiality and integrity of the TOE. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the development security documentation to determine that it details all security measures used in the development environment that are necessary to protect the confidentiality and integrity of the TOE design and implementation. The evaluator determines what is necessary by first referring to the ST for any information that may assist in the determination of necessary protection. If no explicit information is available from the ST the evaluator will need to make a determination of the necessary measures. In cases where the developer's measures are considered less than what is necessary, a clear justification should be provided for the assessment, based on a potential exploitable vulnerability. The following types of security measures are considered by the evaluator when examining the documentation: physical, for example physical access controls used to prevent unauthorized access to the TOE development environment (during normal working hours and at other times); procedural, for example covering: granting of access to the development environment or to specific parts of the environment such as development machines; revocation of access rights when a person leaves the development team; transfer of protected material out of the development environment and between different development sites in accordance with defined acceptance procedures; admitting and escorting visitors to the development environment. roles and responsibilities in ensuring the continued application of security measures, and the detection of security breaches; personnel, for example any controls or checks made to establish the trustworthiness of new development staff; other security measures, for example the logical protections on any development machines. The development security documentation should identify the locations at which development occurs, and describe the aspects of development performed, along with the security measures applied at each location and for transports between different locations. For example, development can occur at multiple facilities within a single building, multiple buildings at the same site, or at multiple sites. Transports of parts of the TOE or the unfinished TOE between different development sites are to be covered by the Development security , whereas the transport of the finished TOE to the consumer is dealt with in the . Development includes the production of the TOE. The evaluator shall examine the development security documentation to determine that an appropriate justification is given why the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE. Since attacks on the TOE or its related information are assumed in different design and production stages, measures and procedures need to have an appropriate level necessary to prevent those attacks or to make them more difficult. Since this level depends on the overall attack potential claimed for the TOE (cf. the component chosen), the development security documentation should justify the necessary level of protection to maintain the confidentiality and integrity of the TOE. This level has to be achieved by the security measures applied. The concept of protection measures should be consistent, and the justification should include an analysis of how the measures are mutually supportive. All aspects of development and production on all the different sites with all roles involved up to delivery of the TOE should be analysed. Justification may include an analysis of potential vulnerabilities taking the applied security measures into account. There may be a convincing argument showing that e.g.: The technical measures and mechanisms of the developer's infrastructure are sufficient for keeping the appropriate security level (e.g. cryptographic mechanisms as well as physical protection mechanisms, properties of the CM system (cf. ). The system containing the implementation representation of the TOE (including concerning guidance documents) provides effective protection against logical attacks e.g. by "Trojan" code or viruses. It can be adequate, if the implementation representation is kept on an isolated system where only the software necessary to maintain it is installed and where no additional software is installed afterwards. Data brought into this system need to be carefully considered to prevent the installation of hidden functionality onto the system. The effectiveness of these measures need to be tested, e.g. by independently trying to get access to the machine, install some additional executable or get some information out of the machine using logical attacks. The appropriate organisational (procedural and personal) measures are unconditionally enforced. The evaluator shall examine the development confidentiality and integrity policies in order to determine the sufficiency of the security measures employed. The evaluator should examine whether the following is included in the policies: what information relating to the TOE development needs to be kept confidential, and which members of the development staff are allowed to access such material; what material must be protected from unauthorized modification in order to preserve the integrity of the TOE, and which members of the development staff are allowed to modify such material. The evaluator should determine that these policies are described in the development security documentation, that the security measures employed are consistent with the policies, and that they are complete. It should be noted that configuration management procedures will help protect the integrity of the TOE and the evaluator should avoid overlap with the work-units conducted for the . For example, the CM documentation may describe the security procedures necessary for controlling the roles or individuals who should have access to the development environment and who may modify the TOE. Whereas the requirements are fixed, those for the Development security , mandating only necessary measures, are dependent on the nature of the TOE, and on information that may be provided in the ST. For example, the ST may identify a security objective for the development environment that requires the TOE to be developed by staff that has security clearance. The evaluators would then determine that such a policy had been applied under this sub-activity. The evaluator shall confirm that the security controls are being applied. The evaluator shall examine the development security documentation and associated evidence to determine that the security measures are being applied. This work unit requires the evaluator to determine that the security measures described in the development security documentation are being followed, such that the integrity of the TOE and the confidentiality of associated documentation is being adequately protected. For example, this can be determined by examination of the documentary evidence provided. Documentary evidence should be supplemented by visiting the development environment. A visit to the development environment will allow the evaluator to: observe the application of security measures (e.g. physical measures); examine documentary evidence of application of procedures; interview development staff to check awareness of the development security policies and procedures, and their responsibilities. A development site visit is a useful means of gaining confidence in the measures being used. Any decision not to make such a visit should be determined in consultation with the evaluation authority. For guidance on site visits see A.4, Site Visits. Flaw remediation requires that discovered security flaws be tracked and corrected by the developer. Although future compliance with flaw remediation procedures cannot be determined at the time of the TOE evaluation, it is possible to evaluate the policies and procedures that a developer has in place to track and correct flaws, and to distribute the flaw information and corrections. The components in this family are levelled on the basis of the increasing extent in scope of the flaw remediation procedures and the rigour of the flaw remediation policies. This family provides assurance that the TOE will be maintained and supported in the future, requiring the TOE developer to track and correct flaws in the TOE. Additionally, requirements are included for the distribution of flaw corrections. However, this family does not impose evaluation requirements beyond the current evaluation. The TOE user is considered to be the focal point in the user organization that is responsible for receiving and implementing fixes to security flaws. This is not necessarily an individual user, but may be an organisational representative who is responsible for the handling of security flaws. The use of the term TOE user recognizes that different organisations have different procedures for handling flaw reporting, which may be done either by an individual user, or by a central administrative body. The flaw remediation procedures should describe the methods for dealing with all types of flaws encountered. These flaws may be reported by the developer, by users of the TOE, or by other parties with familiarity with the TOE. Some flaws may not be reparable immediately. There may be some occasions where a flaw cannot be fixed and other (e.g. procedural) controls must be taken. The documentation provided should cover the procedures for providing the operational sites with fixes and providing information on flaws where fixes are delayed (and what to do in the interim) or when fixes are not possible. Changes applied to a TOE after its release render it unevaluated; although some information from the original evaluation may still apply. The phrase "release of the TOE" used in this family therefore refers to a version of a product that is a release of a certified TOE, to which changes have been applied. The objective of this sub-activity is to determine whether the developer has established flaw remediation procedures that describe the tracking of security flaws, the identification of corrective actions, and the distribution of corrective action information to TOE users. the flaw remediation procedures documentation. The developer shall document and provide flaw remediation procedures addressed to TOE developers. The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the flaw remediation procedures documentation to determine that it describes the procedures used to track all reported security flaws in each release of the TOE. The procedures describe the actions that are taken by the developer from the time each suspected security flaw is reported to the time that it is resolved. This includes the flaw's entire time frame, from initial detection through ascertaining that the flaw is a security flaw, to resolution of the security flaw. If a flaw is discovered not to be security-relevant, there is no need (for the purposes of the requirements) for the flaw remediation procedures to track it further; only that there be an explanation of why the flaw is not security-relevant. While these requirements do not mandate that there be a publicised means for TOE users to report security flaws, they do mandate that all security flaws that are reported be tracked. That is, a reported security flaw cannot be ignored simply because it comes from outside the developer's organisation. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would produce a description of each security flaw in terms of its nature and effects. The procedures identify the actions that are taken by the developer to describe the nature and effects of each security flaw in sufficient detail to be able to reproduce it. The description of the nature of a security flaw addresses whether it is an error in the documentation, a flaw in the design of the TSF, a flaw in the implementation of the TSF, etc. The description of the security flaw's effects identifies the portions of the TSF that are affected and how those portions are affected. For example, a security flaw in the implementation can be found that affects the identification and authentication enforced by the TSF by permitting authentication with the password "BACKDOOR". The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would identify the status of finding a correction to each security flaw. The flaw remediation procedures identify the different stages of security flaws. This differentiation includes at least: suspected security flaws that have been reported, suspected security flaws that have been confirmed to be security flaws, and security flaws whose solutions have been implemented. It is permissible that additional stages (e.g. flaws that have been reported but not yet investigated, flaws that are under investigation, security flaws for which a solution has been found but not yet implemented) be included. The evaluator shall check the flaw remediation procedures to determine that the application of these procedures would identify the corrective action for each security flaw. Corrective action may consist of a repair to the hardware, firmware, or software portions of the TOE, a modification of TOE guidance, or both. Corrective action that constitutes modifications to TOE guidance (e.g. details of procedural measures to be taken to obviate the security flaw) includes both those measures serving as only an interim solution (until the repair is issued) as well as those serving as a permanent solution (where it is determined that the procedural measure is the best solution). If the source of the security flaw is a documentation error, the corrective action consists of an update of the affected TOE guidance. If the corrective action is a procedural measure, this measure will include an update made to the affected TOE guidance to reflect these corrective procedures. The evaluator shall examine the flaw remediation procedures documentation to determine that it describes a means of providing the TOE users with the necessary information on each security flaw. The necessary information about each security flaw consists of its description (not necessarily at the same level of detail as that provided as part of work unit ), the prescribed corrective action, and any associated guidance on implementing the correction. TOE users may be provided with such information, correction, and documentation updates in any of several ways, such as their posting to a website, their being sent to TOE users, or arrangements made for the developer to install the correction. In cases where the means of providing this information requires action to be initiated by the TOE user, the evaluator examines any TOE guidance to ensure that it contains instructions for retrieving the information. The only metric for assessing the adequacy of the method used for providing the information, corrections and guidance is that there be a reasonable expectation that TOE users can obtain or receive it. For example, consider the method of dissemination where the requisite data is posted to a website for one month, and the TOE users know that this will happen and when this will happen. This may not be especially reasonable or effective (as, say, a permanent posting to the website), yet it is feasible that the TOE user can obtain the necessary information. On the other hand, if the information were posted to the website for only one hour, yet TOE users had no way of knowing this or when it would be posted, it is infeasible that they would ever get the necessary information. The objective of this sub-activity is to determine whether the developer has established flaw remediation procedures that describe the tracking of security flaws, the identification of corrective actions, and the distribution of corrective action information to TOE users. Additionally, this sub-activity determines whether the developer's procedures provide for the corrections of security flaws, for the receipt of flaw reports from TOE users, and for assurance that the corrections introduce no new security flaws. In order for the developer to be able to act appropriately upon security flaw reports from TOE users, TOE users need to understand how to submit security flaw reports to the developer, and developers need to know how to receive these reports. Flaw remediation guidance addressed to the TOE user ensures that TOE users are aware of how to communicate with the developer; flaw remediation procedures describe the developer's role is such communication the flaw remediation procedures documentation; law remediation guidance documentation. The developer shall document and provide flaw remediation procedures addressed to TOE developers. The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws. The developer shall provide flaw remediation guidance addressed to TOE users. The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and enquiries of suspected security flaws in the TOE. The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users. The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws. The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the flaw remediation procedures documentation to determine that it describes the procedures used to track all reported security flaws in each release of the TOE. The procedures describe the actions that are taken by the developer from the time each suspected security flaw is reported to the time that it is resolved. This includes the flaw's entire time frame, from initial detection through ascertaining that the flaw is a security flaw, to resolution of the security flaw. If a flaw is discovered not to be security-relevant, there is no need (for the purposes of the requirements) for the flaw remediation procedures to track it further; only that there be an explanation of why the flaw is not security-relevant. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would produce a description of each security flaw in terms of its nature and effects. The procedures identify the actions that are taken by the developer to describe the nature and effects of each security flaw in sufficient detail to be able to reproduce it. The description of the nature of a security flaw addresses whether it is an error in the documentation, a flaw in the design of the TSF, a flaw in the implementation of the TSF, etc. The description of the security flaw's effects identifies the portions of the TSF that are affected and how those portions are affected. For example, a security flaw in the implementation can be found that affects the identification and authentication enforced by the TSF by permitting authentication with the password "BACKDOOR". The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would identify the status of finding a correction to each security flaw. The flaw remediation procedures identify the different stages of security flaws. This differentiation includes at least: suspected security flaws that have been reported, suspected security flaws that have been confirmed to be security flaws, and security flaws whose solutions have been implemented. It is permissible that additional stages (e.g. flaws that have been reported but not yet investigated, flaws that are under investigation, security flaws for which a solution has been found but not yet implemented) be included. The evaluator shall check the flaw remediation procedures to determine that the application of these procedures would identify the corrective action for each security flaw. Corrective action may consist of a repair to the hardware, firmware, or software portions of the TOE, a modification of TOE guidance, or both. Corrective action that constitutes modifications to TOE guidance (e.g. details of procedural measures to be taken to obviate the security flaw) includes both those measures serving as only an interim solution (until the repair is issued) as well as those serving as a permanent solution (where it is determined that the procedural measure is the best solution). If the source of the security flaw is a documentation error, the corrective action consists of an update of the affected TOE guidance. If the corrective action is a procedural measure, this measure will include an update made to the affected TOE guidance to reflect these corrective procedures. The evaluator shall examine the flaw remediation procedures documentation to determine that it describes a means of providing the TOE users with the necessary information on each security flaw. The necessary information about each security flaw consists of its description (not necessarily at the same level of detail as that provided as part of work unit ), the prescribed corrective action, and any associated guidance on implementing the correction. TOE users may be provided with such information, correction, and documentation updates in any of several ways, such as their posting to a website, their being sent to TOE users, or arrangements made for the developer to install the correction. In cases where the means of providing this information requires action to be initiated by the TOE user, the evaluator examines any TOE guidance to ensure that it contains instructions for retrieving the information. The only metric for assessing the adequacy of the method used for providing the information, corrections and guidance is that there be a reasonable expectation that TOE users can obtain or receive it. For example, consider the method of dissemination where the requisite data is posted to a website for one month, and the TOE users know that this will happen and when this will happen. This may not be especially reasonable or effective (as, say, a permanent posting to the website), yet it is feasible that the TOE user can obtain the necessary information. On the other hand, if the information were posted to the website for only one hour, yet TOE users had no way of knowing this or when it would be posted, it is infeasible that they would ever get the necessary information. The evaluator shall examine the flaw remediation procedures to determine that they describe procedures for the developer to accept reports of security flaws or requests for corrections to such flaws. The procedures ensure that TOE users have a means by which they can communicate with the TOE developer. By having a means of contact with the developer, the user can report security flaws, enquire about the status of security flaws, or request corrections to flaws. This means of contact may be part of a more general contact facility for reporting non-security related problems. The use of these procedures is not restricted to TOE users; however, only the TOE users are actively supplied with the details of these procedures. Others who can have access to or familiarity with the TOE can use the same procedures to submit reports to the developer, who is then expected to process them. Any means of submitting reports to the developer, other than those identified by the developer, are beyond the scope of this work unit; reports generated by other means need not be addressed. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would help to ensure every reported flaw is corrected. The flaw remediation procedures cover not only those security flaws discovered and reported by developer personnel, but also those reported by TOE users. The procedures are sufficiently detailed so that they describe how it is ensured that each reported security flaw is corrected. The procedures contain reasonable steps that show progress leading to the eventual, inevitable resolution. The procedures describe the process that is taken from the point at which the suspected security flaw is determined to be a security flaw to the point at which it is resolved. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would help to ensure that the TOE users are issued remediation procedures for each security flaw. The procedures describe the process that is taken from the point at which a security flaw is resolved to the point at which the remediation procedures are provided. The procedures for delivering corrective actions should be consistent with the security objectives; they need not necessarily be identical to the procedures used for delivering the TOE, as documented to meet , if included in the assurance requirements. For example, if the hardware portion of a TOE were originally delivered by bonded courier, updates to hardware resulting from flaw remediation would likewise be expected to be distributed by bonded courier. Updates unrelated to flaw remediation would follow the procedures set forth in the documentation meeting the requirements. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in safeguards that the potential correction contains no adverse effects. Through analysis, testing, or a combination of the two, the developer may reduce the likelihood that adverse effects will be introduced when a security flaw is corrected. The evaluator assesses whether the procedures provide detail in how the necessary mix of analysis and testing actions is to be determined for a given correction. The evaluator also determines that, for instances where the source of the security flaw is a documentation problem, the procedures include the means of safeguarding against the introduction of contradictions with other documentation. The evaluator shall examine the flaw remediation guidance to determine that the application of these procedures would result in a means for the TOE user to provide reports of suspected security flaws or requests for corrections to such flaws. The guidance ensures that TOE users have a means by which they can communicate with the TOE developer. By having a means of contact with the developer, the user can report security flaws, enquire about the status of security flaws, or request corrections to flaws. The objective of this sub-activity is to determine whether the developer has established flaw remediation procedures that describe the tracking of security flaws, the identification of corrective actions, and the distribution of corrective action information to TOE users. Additionally, this sub-activity determines whether the developer's procedures provide for the corrections of security flaws, for the receipt of flaw reports from TOE users, for assurance that the corrections introduce no new security flaws, for the establishment of a point of contact for each TOE user, and for the timely issue of corrective actions to TOE users. In order for the developer to be able to act appropriately upon security flaw reports from TOE users, TOE users need to understand how to submit security flaw reports to the developer, and developers need to know how to receive these reports. Flaw remediation guidance addressed to the TOE user ensures that TOE users are aware of how to communicate with the developer; flaw remediation procedures describe the developer's role is such communication. the flaw remediation procedures documentation; flaw remediation guidance documentation. The developer shall document and provide flaw remediation procedures addressed to TOE developers. The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws. The developer shall provide flaw remediation guidance addressed to TOE users. The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and enquiries of suspected security flaws in the TOE. The flaw remediation procedures shall include a procedure requiring timely response and the automatic distribution of security flaw reports and the associated corrections to registered users who might be affected by the security flaw. The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users. The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws. The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE. The flaw remediation guidance shall describe a means by which TOE users may register with the developer, to be eligible to receive security flaw reports and corrections. The flaw remediation guidance shall identify the specific points of contact for all reports and enquiries about security issues involving the TOE. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the flaw remediation procedures documentation to determine that it describes the procedures used to track all reported security flaws in each release of the TOE. The procedures describe the actions that are taken by the developer from the time each suspected security flaw is reported to the time that it is resolved. This includes the flaw's entire time frame, from initial detection through ascertaining that the flaw is a security flaw, to resolution of the security flaw. If a flaw is discovered not to be security-relevant, there is no need (for the purposes of the requirements) for the flaw remediation procedures to track it further; only that there be an explanation of why the flaw is not security-relevant. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would produce a description of each security flaw in terms of its nature and effects. The procedures identify the actions that are taken by the developer to describe the nature and effects of each security flaw in sufficient detail to be able to reproduce it. The description of the nature of a security flaw addresses whether it is an error in the documentation, a flaw in the design of the TSF, a flaw in the implementation of the TSF, etc. The description of the security flaw's effects identifies the portions of the TSF that are affected and how those portions are affected. For example, a security flaw in the implementation can be found that affects the identification and authentication enforced by the TSF by permitting authentication with the password "BACKDOOR". The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would identify the status of finding a correction to each security flaw. The flaw remediation procedures identify the different stages of security flaws. This differentiation includes at least: suspected security flaws that have been reported, suspected security flaws that have been confirmed to be security flaws, and security flaws whose solutions have been implemented. It is permissible that additional stages (e.g. flaws that have been reported but not yet investigated, flaws that are under investigation, security flaws for which a solution has been found but not yet implemented) be included. The evaluator shall check the flaw remediation procedures to determine that the application of these procedures would identify the corrective action for each security flaw. Corrective action may consist of a repair to the hardware, firmware, or software portions of the TOE, a modification of TOE guidance, or both. Corrective action that constitutes modifications to TOE guidance (e.g. details of procedural measures to be taken to obviate the security flaw) includes both those measures serving as only an interim solution (until the repair is issued) as well as those serving as a permanent solution (where it is determined that the procedural measure is the best solution). If the source of the security flaw is a documentation error, the corrective action consists of an update of the affected TOE guidance. If the corrective action is a procedural measure, this measure will include an update made to the affected TOE guidance to reflect these corrective procedures. The evaluator shall examine the flaw remediation procedures documentation to determine that it describes a means of providing the TOE users with the necessary information on each security flaw. The necessary information about each security flaw consists of its description (not necessarily at the same level of detail as that provided as part of work unit ), the prescribed corrective action, and any associated guidance on implementing the correction. TOE users may be provided with such information, correction, and documentation updates in any of several ways, such as their posting to a website, their being sent to TOE users, or arrangements made for the developer to install the correction. In cases where the means of providing this information requires action to be initiated by the TOE user, the evaluator examines any TOE guidance to ensure that it contains instructions for retrieving the information. The only metric for assessing the adequacy of the method used for providing the information, corrections and guidance is that there be a reasonable expectation that TOE users can obtain or receive it. For example, consider the method of dissemination where the requisite data is posted to a website for one month, and the TOE users know that this will happen and when this will happen. This may not be especially reasonable or effective (as, say, a permanent posting to the website), yet it is feasible that the TOE user can obtain the necessary information. On the other hand, if the information were posted to the website for only one hour, yet TOE users had no way of knowing this or when it would be posted, it is infeasible that they would ever get the necessary information. For TOE users who register with the developer (see work unit ), the passive availability of this information is not sufficient. Developers must actively send the information (or a notification of its availability) to registered TOE users. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in a means for the developer to receive from TOE user reports of suspected security flaws or requests for corrections to such flaws. The procedures ensure that TOE users have a means by which they can communicate with the TOE developer. By having a means of contact with the developer, the user can report security flaws, enquire about the status of security flaws, or request corrections to flaws. This means of contact may be part of a more general contact facility for reporting non-security related problems. The use of these procedures is not restricted to TOE users; however, only the TOE users are actively supplied with the details of these procedures. Others who can have access to or familiarity with the TOE can use the same procedures to submit reports to the developer, who is then expected to process them. Any means of submitting reports to the developer, other than those identified by the developer, are beyond the scope of this work unit; reports generated by other means need not be addressed. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in a timely means of providing the registered TOE users who can be affected with reports about, and associated corrections to, each security flaw. The issue of timeliness applies to the issuance of both security flaw reports and the associated corrections. However, these need not be issued at the same time. It is recognised that flaw reports should be generated and issued as soon as an interim solution is found, even if that solution is as drastic as turn off the TOE. Likewise, when a more permanent (and less drastic) solution is found, it should be issued without undue delay. It is unnecessary to restrict the recipients of the reports and associated corrections to only those TOE users who can be affected by the security flaw; it is permissible that all TOE users be given such reports and corrections for all security flaws, provided such is done in a timely manner. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in automatic distribution of the reports and associated corrections to the registered TOE users who can be affected. Automatic distribution does not mean that human interaction with the distribution method is not permitted. In fact, the distribution method can consist entirely of manual procedures, perhaps through a closely monitored procedure with prescribed escalation upon the lack of issue of reports or corrections. It is unnecessary to restrict the recipients of the reports and associated corrections to only those TOE users who can be affected by the security flaw; it is permissible that all TOE users be given such reports and corrections for all security flaws, provided such is done automatically. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would help to ensure that every reported flaw is corrected. The flaw remediation procedures cover not only those security flaws discovered and reported by developer personnel, but also those reported by TOE users. The procedures are sufficiently detailed so that they describe how it is ensured that each reported security flaw is remediated. The procedures contain reasonable steps that show progress leading to the eventual, inevitable resolution. The procedures describe the process that is taken from the point at which the suspected security flaw is determined to be a security flaw to the point at which it is resolved. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would help to ensure that the TOE users are issued remediation procedures for each security flaw. The procedures describe the process that is taken from the point at which a security flaw is resolved to the point at which the remediation procedures are provided. The procedures for delivering remediation procedures should be consistent with the security objectives; they need not necessarily be identical to the procedures used for delivering the TOE, as documented to meet , if included in the assurance requirements. For example, if the hardware portion of a TOE were originally delivered by bonded courier, updates to hardware resulting from flaw remediation would likewise be expected to be distributed by bonded courier. Updates unrelated to flaw remediation would follow the procedures set forth in the documentation meeting the requirements. The evaluator shall examine the flaw remediation procedures to determine that the application of these procedures would result in safeguards that the potential correction contains no adverse effects. Through analysis, testing, or a combination of the two, the developer may reduce the likelihood that adverse effects will be introduced when a security flaw is corrected. The evaluator assesses whether the procedures provide detail in how the necessary mix of analysis and testing actions is to be determined for a given correction. The evaluator also determines that, for instances where the source of the security flaw is a documentation problem, the procedures include the means of safeguarding against the introduction of contradictions with other documentation. The evaluator shall examine the flaw remediation guidance to determine that the application of these procedures would result in a means for the TOE user to provide reports of suspected security flaws or requests for corrections to such flaws. The guidance ensures that TOE users have a means by which they can communicate with the TOE developer. By having a means of contact with the developer, the user can report security flaws, enquire about the status of security flaws, or request corrections to flaws. The evaluator shall examine the flaw remediation guidance to determine that it describes a means of enabling the TOE users to register with the developer. Enabling the TOE users to register with the developer simply means having a way for each TOE user to provide the developer with a point of contact; this point of contact is to be used to provide the TOE user with information related to security flaws that can affect that TOE user, along with any corrections to the security flaw. Registering the TOE user may be accomplished as part of the standard procedures that TOE users undergo to identify themselves to the developer, for the purposes of registering a software licence, or for obtaining update and other useful information. There need not be one registered TOE user per installation of the TOE; it would be sufficient if there were one registered TOE user for an organisation. For example, a corporate TOE user might have a centralised acquisition office for all of its sites. In this case, the acquisition office would be a sufficient point of contact for all of that TOE user's sites, so that all of the TOE user's installations of the TOE have a registered point of contact. In either case, it must be possible to associate each TOE that is delivered with an organisation in order to ensure that there is a registered user for each TOE. For organisations that have many different addresses, this assures that there will be no user who is erroneously presumed to be covered by a registered TOE user. It should be noted that TOE users need not register; they must only be provided with a means of doing so. However, users who choose to register must be directly sent the information (or a notification of its availability). The evaluator shall examine the flaw remediation guidance to determine that it identifies specific points of contact for user reports and enquiries about security issues involving the TOE. The guidance includes a means whereby registered TOE users can interact with the developer to report discovered security flaws in the TOE or to make enquiries regarding discovered security flaws in the TOE. Poorly defined or uncontrolled processes applied during the development, production and maintenance of the TOE can result in a TOE that does not meet all of its security objectives. Therefore, it is important that well defined and controlled processes be established as early as possible in the TOE's life-cycle. Defining and implementing such processes does not guarantee that the TOE meets all of its SFRs. It is possible that the processes will be insufficient or inadequate. Adopting a life-cycle model, or models that meets the needs of the developer's organization will improve the likelihood that the development, production and maintenance processes applied to TOE support the correct design and implementation of a TOE that meets the specified SFRs. The determination of appropriate process controls in order to support process improvement is a long-established best practice. The components in this family are levelled on the basis of increasing requirements for measurability of the life-cycle model, and for compliance with that model. A life-cycle model encompasses the procedures, tools and techniques used to develop and maintain the TOE. Aspects of the process that may be covered by such a model include design methods, review procedures, project management controls, change control procedures, test methods and acceptance procedures. An effective life-cycle model will address these aspects of the development and maintenance process within an overall management structure that assigns responsibilities and monitors progress. There are different types of acceptance situations that are dealt with at different locations in the criteria: acceptance of parts delivered by subcontractors ("integration") should be treated in this family, Life-cycle definition (), acceptance subsequent to internal transportations in Development security (), acceptance of parts into the CM system in (), and acceptance of the delivered TOE by the consumer in (). The first three types may overlap. Although life-cycle definition deals with the maintenance of the TOE and hence with aspects becoming relevant after the completion of the evaluation, its evaluation adds assurance through an analysis of the life-cycle information for the TOE provided at the time of the evaluation. A life-cycle model provides for the necessary control over the development and maintenance of the TOE, if the model enables sufficient minimization of the danger that the TOE will not meet its security requirement. A measurable life-cycle model is a model using some quantitative valuation (arithmetic parameters and/or metrics) of the managed product in order to measure development properties of the product. Typical metrics are source code complexity metrics, defect density (errors per size of code) or mean time to failure. For the security evaluation all those metrics are of relevance, which are used to increase quality by decreasing the probability of faults and thereby in turn increasing assurance in the security of the TOE. One should take into account that there exist standardised life-cycle models on the one hand (like the waterfall model) and standardised metrics on the other hand (like error density), which may be combined. The CC series does not require the life-cycle to follow exactly one standard defining both aspects. The objective of this sub-activity is to determine whether the developer has used a documented model of the TOE life-cycle. the ST; the life-cycle definition documentation. The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE. The developer shall provide life-cycle definition documentation. The life-cycle definition documentation shall describe the processes used to develop and maintain the TOE. The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the documented description of the life-cycle model used to determine that it covers the development and maintenance process. The description of the life-cycle model should include: information on the life-cycle phases of the TOE and the boundaries between the subsequent phases; information on the procedures, tools and techniques used by the developer (e.g. for design, coding, testing, bug-fixing); overall management structure governing the application of the procedures (e.g. an identification and description of the individual responsibilities for each of the procedures required by the development and maintenance process covered by the life-cycle model); information on which parts of the TOE are delivered by subcontractors, if subcontractors are involved. Evaluation of this sub-activity does not require the model used to conform to any standard life-cycle model. The evaluator shall examine the life-cycle model to determine that use of the procedures, tools and techniques described by the life-cycle model will make the necessary positive contribution to the development and maintenance of the TOE. The information provided in the life-cycle model gives the evaluator assurance that the development and maintenance procedures adopted would minimise the likelihood of security flaws. For example, if the life-cycle model described the review process, but did not make provision for recording changes to components, then the evaluator may be less confident that errors will not be introduced into the TOE. The evaluator may gain further assurance by comparing the description of the model against an understanding of the development process gleaned from performing other evaluator actions relating to the TOE development (e.g. those covered under the ). Identified deficiencies in the life-cycle model will be of concern if they can reasonably be expected to give rise to the introduction of flaws into the TOE, either accidentally or deliberately. CC series does not mandate any particular development approach, and each should be judged on merit. For example, spiral, rapid-prototyping and waterfall approaches to design can all be used to produce a quality TOE if applied in a controlled environment. The objective of this sub-activity is to determine whether the developer has used a documented and measurable model of the TOE life-cycle. the ST; the life-cycle definition documentation; information about the standard used; the life-cycle output documentation. The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE that is based on a measurable life-cycle model. The developer shall provide life-cycle definition documentation. The developer shall measure the TOE development using the measurable life-cycle model. The developer shall provide life-cycle output documentation. The life-cycle definition documentation shall describe the model used to develop and maintain the TOE including the details of its arithmetic parameters and/or metrics used to measure the quality of the TOE and/or its development. The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE. The life-cycle output documentation shall provide the results of the measurements of the TOE development using the measurable life-cycle model. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the documented description of the life-cycle model used to determine that it covers the development and maintenance process, including the details of its arithmetic parameters and/or metrics used to measure the TOE development. The description of the life-cycle model includes: information on the life-cycle phases of the TOE and the boundaries between the subsequent phases; information on the procedures, tools and techniques used by the developer (e.g. for design, coding, testing, bug-fixing); overall management structure governing the application of the procedures (e.g. an identification and description of the individual responsibilities for each of the procedures required by the development and maintenance process covered by the life-cycle model); information on which parts of the TOE are delivered by subcontractors, if subcontractors are involved; information on the parameters/metrics that are used to measure the TOE development. Metrics standards typically include guides for measuring and producing reliable products and cover the aspects reliability, quality, performance, complexity and cost. For the evaluation all those metrics are of relevance, which are used to increase quality by decreasing the probability of faults and thereby in turn increase assurance in the security of the TOE. The evaluator shall examine the life-cycle model to determine that use of the procedures, tools and techniques described by the life-cycle model will make the necessary positive contribution to the development and maintenance of the TOE. The information provided in the life-cycle model gives the evaluator assurance that the development and maintenance procedures adopted would minimise the likelihood of security flaws. For example, if the life-cycle model described the review process, but did not make provision for recording changes to components, then the evaluator may be less confident that errors will not be introduced into the TOE. The evaluator may gain further assurance by comparing the description of the model against an understanding of the development process gleaned from performing other evaluator actions relating to the TOE development (e.g. those covered under the ). Identified deficiencies in the life-cycle model will be of concern if they can reasonably be expected to give rise to the introduction of flaws into the TOE, either accidentally or deliberately. CC series does not mandate any particular development approach, and each should be judged on merit. For example, spiral, rapid-prototyping and waterfall approaches to design can all be used to produce a quality TOE if applied in a controlled environment. For the metrics/measurements used in the life-cycle model, evidence has to be provided that shows how those metrics/measurements usefully contribute to the minimisation of the likelihood of flaws. This can be viewed as the overall goal for measurement in an context. As a consequence, the metrics/measurements have to be selected based on their capability to achieve that overall goal or contribute to that. In the first place a metric/measure is suitable with respect to if a correlation between the metric/measure and the number of flaws can be stated with a certain degree of reliability. But also, a metric/measure useful for management purposes as for planning and monitoring the TOE development are helpful since badly managed projects are endangered to produce bad quality and to introduce flaws. It may be possible to use metrics for quality improvement, for which this use is not obvious. For example, a metric to estimate the expected cost of a product development may help quality, if the developer can show that this is used to provide an adequate budget for development projects and that this helps to avoid quality problems arising from resource shortages. It is not required that every single step in the life cycle of the TOE is measurable. However, the evaluator should see from the description of the measures and procedures that the metrics are appropriate to control the overall quality of the TOE and to minimise possible security flaws by this. The evaluator shall examine the life-cycle output documentation to determine that it provides the results of the measurements of the TOE development using the measurable life-cycle model. The results of the measurements and the life-cycle progress of the TOE should be in accordance with the life-cycle model. The output documentation not only includes numeric values of the metrics but also documents actions taken as a result of the measurements and in accordance with the model. For example, there may be a requirement that a certain design phase needs to be repeated, if some error rates measured during testing are outside of a defined threshold. In this case the documentation should show that such action was taken, if indeed the thresholds were not met. If the evaluation is conducted in parallel with the development of the TOE it may be possible that quality measurements have not been used in the past. In this case the evaluator should use the documentation of the planned procedures in order to gain confidence that corrective actions are defined if results of quality measurements deviate from some threshold. The evaluator shall confirm that the measurements of the TOE development processes and security relevant properties of the TOE support improvements in the development processes and/or the TOE itself. Tools and techniques is an aspect of selecting tools that are used to develop, analyse and implement the TOE. It includes requirements to prevent ill-defined, inconsistent or incorrect development tools from being used to develop the TOE. This includes, but is not limited to, programming languages, documentation, implementation standards, and other parts of the TOE such as supporting runtime libraries. The components in this family are levelled on the basis of increasing requirements on the description and scope of the implementation standards and the documentation of implementation-dependent options. There is a requirement for well-defined development tools. These are tools that are clearly and completely described. For example, programming languages and computer aided design (CAD) systems that are based on a standard published by standards bodies are considered to be well-defined. Self-made tools would need further investigation to clarify whether they are well-defined. The requirement in is especially applicable to programming languages so as to ensure that all statements in the source code have an unambiguous meaning. In and , implementation guidelines may be accepted as an implementation standard if they have been approved by some group of experts (e.g. academic experts, standards bodies). Implementation standards are normally public, well accepted and common practise in a specific industry, but developer-specific implementation guidelines may also be accepted as a standard; the emphasis is on the expertise. Tools and techniques distinguishes between the implementation standards applied by the developer () and the implementation standards for "all parts of the TOE" () which include third party software, hardware, or firmware. The configuration list introduced in requires that for each TSF relevant configuration item to indicate if it has been generated by the TOE developer or by third party developers. The objective of this sub-activity is to determine whether the developer has used well-defined development tools (e.g. programming languages or computer-aided design (CAD) systems) that yield consistent and predictable results. This work may be performed in parallel with the evaluation activities under , specifically with regard to determining the use of features in the tools that will affect the object code (e.g. compilation options). the development tool documentation; the subset of the implementation representation. The developer shall provide the documentation identifying each development tool being used for the TOE. The developer shall document and provide the selected implementation-dependent options of each development tool. Each development tool used for implementation shall be well-defined. The documentation of each development tool shall unambiguously define the meaning of all statements as well as all conventions and directives used in the implementation. The documentation of each development tool shall unambiguously define the meaning of all implementation-dependent options. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the development tool documentation provided to determine that each development tools is well-defined. For example, a well-defined language, compiler or CAD system may be considered to be one that conforms to a recognised standard, such as the ISO standards. A well-defined language is one that has a clear and complete description of its syntax, and a detailed description of the semantics of each construct. The evaluator shall examine the documentation of each development tool to determine that it unambiguously defines the meaning of all statements as well as all conventions and directives used in the implementation. The development tool documentation (e.g. programming language specifications and user manuals) should cover all statements used in the implementation representation of the TOE, and for each such statement should provide a clear and unambiguous definition of the purpose and effect of that statement. This work may be performed in parallel with the evaluator's examination of the implementation representation performed during the sub-activity. The key test the evaluator should apply is whether or not the documentation is sufficiently clear for the evaluator to be able to understand the implementation representation. The documentation should not assume (for example) that the reader is an expert in the programming language used. Reference to the use of a documented standard is an acceptable approach to meet this requirement, provided that the standard is available to the evaluator. Any differences from the standard should be documented. The critical test is whether the evaluator can understand the TOE source code when performing source code analysis covered in the sub-activity. However, the following checklist can additionally be used in searching for problem areas: In the language definition, phrases such as "the effect of this construct is undefined" and terms such as "implementation dependent" or "erroneous" may indicate ill-defined areas; Aliasing (allowing the same piece of memory to be referenced in different ways) is a common source of ambiguity problems; Exception handling (e.g. what happens after memory exhaustion or stack overflow) is often poorly defined. Most languages in common use, however well designed, will have some problematic constructs. If the implementation language is mostly well defined, but some problematic constructs exist, then an inconclusive verdict should be assigned, pending examination of the source code. The implementation standards description should include at least following: How to implement TOE so as to avoid problematic constructs inherent in the programming language used and/or in the development tool How to implement TOE so as to avoid unwanted behaviour from security perspective (or vulnerabilities) introduced by the development tool. Note that sometimes developers face the situation that the code generated by the development tool used by the developer does not fulfil the desired security property. How to implement TOE so as to meet the rules imposed by third party developers. Note that information required under will be a part of the rules when composite evaluation approach is selected. It is not sufficient to describe just naming rules which do no harm to the security in the light of modern compilers. The evaluator should verify, during the examination of source code, that any use of the problematic constructs does not introduce vulnerabilities. The evaluator should also ensure that constructs precluded by the documented standard are not used. The development tool documentation should define all conventions and directives used in the implementation. The evaluator shall examine the development tool documentation to determine that it unambiguously defines the meaning of all implementation-dependent options. The documentation of software development tools should include definitions of implementation-dependent options that may affect the meaning of the executable code, and those that are different from the standard language as documented. Where source code is provided to the evaluator, information should also be provided on compilation and linking options used. The documentation for hardware design and development tools should describe the use of all options that affect the output from the tools (e.g. detailed hardware specifications, or actual hardware). The objective of this sub-activity is to determine whether the developer has used well-defined development tools (e.g. programming languages or computer-aided design (CAD) systems) that yield consistent and predictable results, and whether implementation standards have been applied. This work may be performed in parallel with the evaluation activities under , specifically with regard to determining the use of features in the tools that will affect the object code (e.g. compilation options). the development tool documentation; the implementation standards description; the provided implementation representation of the TSF. The developer shall provide the documentation identifying each development tool being used for the TOE. The developer shall document and provide the selected implementation-dependent options of each development tool. The developer shall describe and provide the implementation standards that are being applied by the developer. Each development tool used for implementation shall be well-defined. The documentation of each development tool shall unambiguously define the meaning of all statements as well as all conventions and directives used in the implementation. The documentation of each development tool shall unambiguously define the meaning of all implementation-dependent options. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the development tool documentation provided to determine that each development tool is well-defined. For example, a well-defined language, compiler or CAD system may be considered to be one that conforms to a recognised standard, such as the ISO standards. A well-defined language is one that has a clear and complete description of its syntax, and a detailed description of the semantics of each construct. The evaluator shall examine the documentation of each development tool to determine that it unambiguously defines the meaning of all statements as well as all conventions and directives used in the implementation. The development tool documentation (e.g. programming language specifications and user manuals) should cover all statements used in the implementation representation of the TOE, and for each such statement should provide a clear and unambiguous definition of the purpose and effect of that statement. This work may be performed in parallel with the evaluator's examination of the implementation representation performed during the sub-activity. The key test the evaluator should apply is whether or not the documentation is sufficiently clear for the evaluator to be able to understand the implementation representation. The documentation should not assume (for example) that the reader is an expert in the programming language used. Reference to the use of a documented standard is an acceptable approach to meet this requirement, provided that the standard is available to the evaluator. Any differences from the standard should be documented. The critical test is whether the evaluator can understand the TOE source code when performing source code analysis covered in the sub-activity. However, the following checklist can additionally be used in searching for problem areas: In the language definition, phrases such as "the effect of this construct is undefined" and terms such as "implementation dependent" or "erroneous" may indicate ill-defined areas; Aliasing (allowing the same piece of memory to be referenced in different ways) is a common source of ambiguity problems; Exception handling (e.g. what happens after memory exhaustion or stack overflow) is often poorly defined. Most languages in common use, however well designed, will have some problematic constructs. If the implementation language is mostly well defined, but some problematic constructs exist, then an inconclusive verdict should be assigned, pending examination of the source code. The implementation standards description should include at least following: How to implement TOE so as to avoid problematic constructs inherent in the programming language used and/or in the development tool; How to implement TOE so as to avoid unwanted behaviour from security perspective (or vulnerabilities) introduced by the development tool. Note that sometimes developers face the situation that the code generated by the development tool used by the developer does not fulfil the desired security property; How to implement TOE so as to meet the rules imposed by third party developers. Note that information required under will be a part of the rules when composite evaluation approach is selected. It is not sufficient to describe just naming rules which do no harm to the security in the light of modern compilers. The evaluator should verify, during the examination of source code, that any use of the problematic constructs does not introduce vulnerabilities. The evaluator should also ensure that constructs precluded by the documented standard are not used. The development tool documentation should define all conventions and directives used in the implementation. The evaluator shall examine the development tool documentation to determine that it unambiguously defines the meaning of all implementation-dependent options. The documentation of software development tools should include definitions of implementation-dependent options that may affect the meaning of the executable code, and those that are different from the standard language as documented. Where source code is provided to the evaluator, information should also be provided on compilation and linking options used. The documentation for hardware design and development tools should describe the use of all options that affect the output from the tools (e.g. detailed hardware specifications, or actual hardware). The evaluator shall confirm that the implementation standards have been applied. The evaluator shall examine aspects of the implementation process to determine that documented implementation standards have been applied. This work unit requires the evaluator to analyse the provided implementation representation of the TOE to determine whether the documented implementation standards have been applied. The evaluator should verify that constructs excluded by the documented standard are not used. Additionally, the evaluator should verify the developer's procedures which ensure the application of the defined standards within the design and implementation process of the TOE. Therefore, documentary evidence should be supplemented by visiting the development environment. A visit to the development environment will allow the evaluator to: observe the application of defined standards; examine documentary evidence of application of procedures describing the use of defined standards; interview development staff to check awareness of the application of defined standards and procedures. A development site visit is a useful means of gaining confidence in the procedures being used. Any decision not to make such a visit should be determined in consultation with the evaluation authority. The evaluator compares the provided implementation representation with the description of the applied implementation standards and verifies their use. At this level it is not required that the complete provided implementation representation of the TSF is based on implementation standards, but only those parts that are developed by the TOE developer. The evaluator may consult the configuration list required by the to get the information which parts are developed by the TOE developer, and which by third party developers. If the referenced implementation standards are not applied for at least parts of the provided implementation representation, the evaluator action related to this work unit is assigned a fail verdict. Note that parts of the TOE which are not TSF relevant do not need to be examined. This work unit may be performed in conjunction with the evaluation activities under . The objective of this sub-activity is to determine whether the developer and their subcontractors have used well-defined development tools (e.g. programming languages or computer-aided design (CAD) systems) that yield consistent and predictable results, and whether implementation standards have been applied. This work may be performed in parallel with the evaluation activities under , specifically with regard to determining the use of features in the tools that will affect the object code (e.g. compilation options). the development tool documentation; the implementation standards description; the provided implementation representation of the TSF. The developer shall provide the documentation identifying each development tool being used for the TOE. The developer shall document and provide the selected implementation-dependent options of each development tool. The developer shall describe and provide the implementation standards that are being applied by the developer and by any third-party providers for all parts of the TOE. Each development tool used for implementation shall be well-defined. The documentation of each development tool shall unambiguously define the meaning of all statements as well as all conventions and directives used in the implementation. The documentation of each development tool shall unambiguously define the meaning of all implementation-dependent options. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the development tool documentation provided to determine that each development tool is well-defined. For example, a well-defined language, compiler or CAD system may be considered to be one that conforms to a recognised standard, such as the ISO standards. A well-defined language is one that has a clear and complete description of its syntax, and a detailed description of the semantics of each construct. At this level, the documentation of development tools used by third party contributors to the TOE has to be included in the evaluator's examination. The evaluator shall examine the documentation of each development tool to determine that it unambiguously defines the meaning of all statements as well as all conventions and directives used in the implementation. The development tool documentation (e.g. programming language specifications and user manuals) should cover all statements used in the implementation representation of the TOE, and for each such statement should provide a clear and unambiguous definition of the purpose and effect of that statement. This work may be performed in parallel with the evaluator's examination of the implementation representation performed during the sub-activity. The key test the evaluator should apply is whether or not the documentation is sufficiently clear for the evaluator to be able to understand the implementation representation. The documentation should not assume (for example) that the reader is an expert in the programming language used. Reference to the use of a documented standard is an acceptable approach to meet this requirement, provided that the standard is available to the evaluator. Any differences from the standard should be documented. The critical test is whether the evaluator can understand the TOE source code when performing source code analysis covered in the sub-activity. However, the following checklist can additionally be used in searching for problem areas: In the language definition, phrases such as "the effect of this construct is undefined" and terms such as "implementation dependent" or "erroneous" may indicate ill-defined areas; Aliasing (allowing the same piece of memory to be referenced in different ways) is a common source of ambiguity problems; Exception handling (e.g. what happens after memory exhaustion or stack overflow) is often poorly defined. Most languages in common use, however well designed, will have some problematic constructs. If the implementation language is mostly well defined, but some problematic constructs exist, then an inconclusive verdict should be assigned, pending examination of the source code. The implementation standards description should include at least following: How to implement TOE so as to avoid problematic constructs inherent in the programming language used and/or in the development tool How to implement TOE so as to avoid unwanted behaviour from security perspective (or vulnerabilities) introduced by the development tool. Note that sometimes developers face the situation that the code generated by the development tool used by the developer does not fulfil the desired security property. How to implement TOE so as to meet the rules imposed by third party developers Note that information required under will be a part of the rules when composite evaluation approach is selected. It is not sufficient to describe just naming rules which do no harm to the security in the light of modern compilers. The evaluator should verify, during the examination of source code, that any use of the problematic constructs does not introduce vulnerabilities. The evaluator should also ensure that constructs precluded by the documented standard are not used. The development tool documentation should define all conventions and directives used in the implementation. At this level, the documentation of development tools used by third party contributors to the TOE has to be included in the evaluator's examination. The evaluator shall examine the development tool documentation to determine that it unambiguously defines the meaning of all implementation-dependent options. The documentation of software development tools should include definitions of implementation-dependent options that may affect the meaning of the executable code, and those that are different from the standard language as documented. Where source code is provided to the evaluator, information should also be provided on compilation and linking options used. The documentation for hardware design and development tools should describe the use of all options that affect the output from the tools (e.g. detailed hardware specifications, or actual hardware). At this level, the documentation of development tools used by third party contributors to the TOE has to be included in the evaluator's examination. The evaluator shall confirm that the implementation standards have been applied. The evaluator shall examine aspects of the implementation process to determine that documented implementation standards have been applied. This work unit requires the evaluator to analyse the provided implementation representation of the TOE to determine whether the documented implementation standards have been applied. The evaluator should verify that constructs excluded by the documented standard are not used. Additionally, the evaluator should verify the developer's procedures which ensure the application of the defined standards within the design and implementation process of the TOE. Therefore, documentary evidence should be supplemented by visiting the development environment. A visit to the development environment will allow the evaluator to: observe the application of defined standards; examine documentary evidence of application of procedures describing the use of defined standards; interview development staff to check awareness of the application of defined standards and procedures. A development site visit is a useful means of gaining confidence in the procedures being used. Any decision not to make such a visit should be determined in consultation with the evaluation authority. The evaluator compares the provided implementation representation with the description of the applied implementation standards and verifies their use. At this level it is required that the complete provided implementation representation of the TSF is based on implementation standards, including third party contributions. This may require the evaluator to visit the sites of contributors. The evaluator may consult the configuration list required by the to see who has developed which part of the TOE. Note that parts of the TOE which are not TSF relevant do not need to be examined. This work unit may be performed in conjunction with the evaluation activities under . This family aims to add trust to the development process or a development. It focuses on the generation of certain artefacts in the development process. These artefacts are used at a later point in time to assess the degree to which the development process is trustable. This trust is realized through the validation of the generated artefacts for confirming them as sufficient evidence for trustable development. This family introduces developer practices within the development process to generate the required artefacts for realizing trustable development. If a requirement in this family does not explicitly specify the use of automation to generate the required artefacts, the developer is free to undertake the corresponding practice manually, or to use some integrated automation in the development process, or to use a hybrid method of both. It is expected that the degree of trust in the development process is proportional to the degree of automation adoption to implement the corresponding practice in the development process. This family also has a relationship with the family. As focuses on the tools and techniques aspect for developing, analysing, and implementing the TOE, it provides the necessary context when describing the practices of this family being introduced into the development process. The components in this family are levelled on the basis of increasing cross-checking for consistency with relevant evidence from components of other families of other security assurance classes. The requirements in provide a degree of trust in the developer's ability to identify the set of implementation representation which actually has been used during the TOE generation time. This degree of trust helps to positively answer the question "is that really the source code for this software" or "is that really the register-transfer level (RTL) design or description for this integrated circuit hardware" or "is that really the set of implementation representation for this TOE", which is potentially relevant in an evaluation. Such degree of trust is built on the timing of when the set of implementation representation identifiers is recorded or logged, the integrity and authenticity of the record of implementation representation identifiers, and the traceability of implementation representation identifiers from the TOE. In the case where some implementation representation elements are also covered in the configuration list due to , the requirements in make sure that these implementation representation elements actually are identifiable through the use of the implementation representation identifiers of . With the accurate recording or logging of the actual implementation representation being used by the development tools under the scope of , it provides an additional evidence to convince a third party that a regeneration of the TOE is functionally equivalent to the original TOE. The requirements in provide the developer an opportunity to testify the absence of functional differences between the two possibly visibly different TOEs which have been independently generated from the identical set of implementation representation. The objectives of this sub-activity are to determine whether the developer has recorded the unique identifiers of the implementation representation which has been used to generate the TOE. the ST; the list of TOE implementation representation identifiers as output from the developer action of ; the list of TOE implementation representation element names; the timestamp of the list of TOE implementation representation identifiers as output from the developer action of ; the (author) origination information of the list of TOE implementation representation identifiers; the developer documentation describing the following as required in ; the developer's creation of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the developer's timestamp being applied to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information; the developer's mechanism to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the user manual of the developer's development tool which use the TOE implementation representation. The developer shall identify individual elements of the TOE implementation representation to record the list of unique TOE implementation representation identifiers, as the development tool generates the TOE. The developer shall use the current date and time to timestamp the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall maintain the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall ensure the authenticity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time, with the maintenance of the (author) origination information. The developer shall be able to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall produce and provide documentation describing the developer's creation of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the developer's timestamp being applied to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information; the developer's mechanism to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The list of unique TOE implementation representation identifiers as recorded during the TOE generation time shall demonstrate the correspondence between the TOE implementation representation element identifiers and the TOE implementation representation element names. The TOE implementation representation element names shall be in the same form as used or referenced by the development tool to generate the TOE. The timestamp of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time shall be consistent with the creation time of the TOE. The (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time shall be consistent with the (author) origination information of the TOE. The author origination information may be the name of an affiliate of an organization. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the developer documentation describing the developer's creation of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time to determine that there is a correspondence between the TOE implementation representation identifiers and the TOE implementation representation element names. If the developer simply uses the unique TOE implementation representation identifiers as the TOE implementation representation element names, then the correspondence is trivial. Otherwise, the correspondence should have the following effect. If two elements within the TOE implementation representation share the same name, then either they are the same or they are separately identified by two distinct identifiers. If the TOE implementation representation elements are data files residing in a repository such as a hard drive or in the cloud, then the TOE implementation representation element names are just file names. In that case, it is possible that those two files in the hard drive or in the cloud share the same name, but they have different contents. As a result, two distinct identifiers are necessary to distinguish them apart. The correspondence between the TOE implementation representation element identifiers and the TOE implementation representation element names therefore maps or links the two distinct identifiers to the same file name. The evaluator shall confirm that the development tool for generating the TOE is capable to use or reference the implementation representation element names. The evaluator shall examine the user manual of the developer's development tool used to generate the TOE to determine that the development tool accepts the TOE implementation representation element names as its input parameters. If the TOE implementation representation elements are data files residing in a repository such as a hard drive or in the cloud, then the evaluator only need to discover from the development tool user manual that the development tool accepts local or remote file names as its input parameters. The evaluator shall confirm that the list of unique TOE implementation representation identifiers as recorded during the TOE generation time is consistent with the creation time of the TOE. The evaluator shall check the timestamp of the list of TOE implementation representation identifiers as output from the developer action of that it is consistent with the creation time of the TOE as referenced in the ST. Consistency is confirmed by determining that the timestamp on the list of TOE implementation representation identifiers is earlier than the TOE creation time as referenced in the ST, and consistent with the time interval expected from the developer's build process (e.g. as described in deliverables for ). The evaluator shall confirm that the (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time is consistent with the (author) origination information of the TOE. The evaluator shall check the (author) origination information of the list of unique TOE implementation representation identifiers that it is consistent with the (author) origination information of the TOE as referenced in the ST. This consistence means that the (author) origination of the list of unique TOE implementation representation identifiers is related to the (author) origination of the TOE in a reasonable manner. A reasonable relationship is that the (author) origination of the list of unique TOE implementation representation identifiers is an employee, a contractor, a supplier, a subsidiary, or an organizational division of, or is identical to the (author) origination of the TOE. The evaluator shall check the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information. The evaluator shall check the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information by examining the developer documentation describing the maintenance of this integrity characteristic. It is necessary that the developer documentation explains an applicable scenario where none of the following items is freely modified without any proper authorization after its initial existence: the list of unique TOE implementation representation identifiers; its associated timestamp; its associated (author) origination information. Applicable scenarios include the following: these items reside in an access-controlled location and the associated access log/record indicates that these items have not been changed since their initial creation; these items are written in a read only media; these items are digitally signed and are verifiable with a valid public key. The evaluator shall confirm the developer's ability to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The evaluator shall examine the developer documentation describing the developer's mechanism to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time to confirm the developer's ability to trace from the TOE to the list of unique TOE implementation representation identifiers. It is necessary that the evaluator follows the developer documentation to find a list of identifiers using the TOE as its input and the evaluator checks that this list of identifiers matches the list of TOE implementation representation identifiers as output from the developer action . It is acceptable that the developer uses a tracing mechanism that directly or indirectly writes the list of TOE implementation representation identifiers or its representation to the TOE. Alternatively, it is also acceptable that the developer uses a bill of materials database as a tracing mechanism to maintain the correspondence between the TOE and the list of TOE implementation representation identifiers. The objectives of this sub-activity are to determine whether the elements of implementation representation maintained under the configuration scope of are identifiable using the developer's unique identifiers of the implementation representation as recorded during the TOE generation time. the ST; the list of TOE implementation representation identifiers as output from the developer action of or ; the list of TOE implementation representation element names; the timestamp of the list of TOE implementation representation identifiers as output from the developer action of or ; the (author) origination information of the list of TOE implementation representation identifiers; the developer documentation describing the following as required in or the developer's creation of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the developer's timestamp being applied to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information; the developer's mechanism to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the user manual of the developer's development tool which use the TOE implementation representation; the element names of implementation representation (as parts of the configuration list) under the configuration scope of . The developer shall identify individual elements of the TOE implementation representation to record the list of unique TOE implementation representation identifiers, as the development tool generates the TOE. The developer shall use the current date and time to timestamp the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall maintain the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall ensure the authenticity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time, with the maintenance of the (author) origination information. The developer shall be able to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall produce and provide documentation describing the developer's creation of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the developer's timestamp being applied to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information; the developer's mechanism to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall provide evidence that the elements of implementation representation under the configuration scope of are identified by the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The list of unique TOE implementation representation identifiers as recorded during the TOE generation time shall demonstrate the correspondence between the TOE implementation representation element identifiers and the TOE implementation representation element names. The TOE implementation representation element names shall be in the same form as used or referenced by the development tool to generate the TOE. The timestamp of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time shall be consistent with the creation time of the TOE. The (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time shall be consistent with the (author) origination information of the TOE. The author origination information may be the name of an affiliate of an organization. The list of identifiers of the elements of implementation representation under the configuration scope of shall match with the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the developer documentation describing the developer's creation of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time to determine that there is a correspondence between the TOE implementation representation identifiers and the TOE implementation representation element names. If the developer simply uses the unique TOE implementation representation identifiers as the TOE implementation representation element names, then the correspondence is trivial. Otherwise, the correspondence should have the following effect. If two elements within the TOE implementation representation share the same name, then either they are the same or they are separately identified by two distinct identifiers. If the TOE implementation representation elements are data files residing in a repository such as a hard drive or in the cloud, then the TOE implementation representation element names are just file names. In that case, it is possible that those two files in the hard drive or in the cloud share the same name, but they have different contents. As a result, two distinct identifiers are necessary to distinguish them apart. The correspondence between the TOE implementation representation element identifiers and the TOE implementation representation element names therefore maps or links the two distinct identifiers to the same file name. The evaluator shall confirm that the development tool for generating the TOE is capable to use or reference the implementation representation element names. The evaluator shall examine the user manual of the developer's development tool used to generate the TOE to determine that the development tool accepts the TOE implementation representation element names as its input parameters. If the TOE implementation representation elements are data files residing in a repository such as a hard drive or in the cloud, then the evaluator only need to discover from the development tool user manual that the development tool accepts local or remote file names as its input parameters. The evaluator shall confirm that the list of unique TOE implementation representation identifiers as recorded during the TOE generation time is consistent with the creation time of the TOE. The evaluator shall check the timestamp of the list of TOE implementation representation identifiers as output from the developer action of that it is consistent with the creation time of the TOE as referenced in the ST. Consistency is confirmed by determining that the timestamp on the list of TOE implementation representation identifiers is earlier than the TOE creation time as referenced in the ST, and consistent with the time interval expected from the developer's build process (e.g. as described in deliverables for ). The evaluator shall confirm that the (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time is consistent with the (author) origination information of the TOE. The evaluator shall check the (author) origination information of the list of unique TOE implementation representation identifiers that it is consistent with the (author) origination information of the TOE as referenced in the ST. This consistence means that the (author) origination of the list of unique TOE implementation representation identifiers is related to the (author) origination of the TOE in a justifiable manner. A reasonable relationship is that the (author) origination of the list of unique TOE implementation representation identifiers is an employee, a contractor, a supplier, a subsidiary, or an organizational division of, or is identical to the (author) origination of the TOE. The evaluator shall check the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information. The evaluator shall check the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information by examining the developer documentation describing the maintenance of this integrity characteristic. It is necessary that the developer documentation explains how unauthorized modification of any of the following items is prevented: the list of unique TOE implementation representation identifiers; its associated timestamp; its associated (author) origination information. Possible approaches include the following: these items reside in an access-controlled location and the associated access log/record indicates that these items have not been changed since their initial creation; these items are written in a read only media; these items are digitally signed and are verifiable with a valid public key. The evaluator shall confirm the developer's ability to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The evaluator shall examine the developer documentation describing the developer's mechanism to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time to confirm the developer's ability to trace from the TOE to the list of unique TOE implementation representation identifiers. It is necessary that the evaluator follows the developer documentation to find a list of identifiers using the TOE as its input and the evaluator checks that this list of identifiers matches the list of TOE implementation representation identifiers as output from the developer action of . It is acceptable that the developer uses a tracing mechanism that directly or indirectly writes the list of TOE implementation representation identifiers or its representation to the TOE. Alternatively, it is also acceptable that the developer uses a bill of materials database as a tracing mechanism to maintain the correspondence between the TOE and the list of TOE implementation representation identifiers. The evaluator shall confirm that the list of identifiers of the elements of implementation representation under the configuration scope of matches with the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The evaluator shall check that the TOE implementation representation identifiers in the correspondence as determined in Work unit are capable to identify the element names of implementation representation (as parts of the configuration list) under the configuration scope of . A regenerated TOE copy is a TOE regeneration from another copy of the TOE implementation representation according to the developer's unique identifiers of the implementation representation as recorded during the TOE generation time. The objectives of this sub-activity are to determine that the developer's explanation of the functional differences, if any, between the regenerated TOE copy and the original TOE takes into account all visible differences, if any, between the regenerated TOE copy and the original TOE. the ST; the list of TOE implementation representation identifiers as output from the developer action of or or ; the list of TOE implementation representation element names; the timestamp of the list of TOE implementation representation identifiers as output from the developer action of or or ; the (author) origination information of the list of TOE implementation representation identifiers; the developer documentation describing the following as required in or or ; the developer's creation of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the developer's timestamp being applied to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information; the developer's mechanism to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the user manual of the developer's development tool which use the TOE implementation representation; the element names of implementation representation (as parts of the configuration list) under the configuration scope of ; the inputs for the evaluation of sub-activity, which are: the implementation representation; the documentation of the development tools, as resulting from ; TOE design description. the developer's explanation of the functional differences, if any, between the regenerated TOE copy and the original TOE as output from the developer action of . The developer shall identify individual elements of the TOE implementation representation to record the list of unique TOE implementation representation identifiers, as the development tool generates the TOE. The developer shall use the current date and time to timestamp the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall maintain the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall ensure the authenticity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time, with the maintenance of the (author) origination information. The developer shall be able to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall produce and provide documentation describing the developer's creation of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the developer's timestamp being applied to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time; the maintenance of the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information; the developer's mechanism to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer shall provide evidence that the elements of implementation representation under the configuration scope of are identified by the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. After applying the development tools to another copy of the TOE implementation representation according to the list of unique TOE implementation representation identifiers to regenerate a TOE copy, the developer shall explain the functional differences, if any, between the TOE copy and the original TOE. The developer shall produce and provide documentation explaining the functional differences, if any, between the regenerated TOE copy and the original TOE. The list of unique TOE implementation representation identifiers as recorded during the TOE generation time shall demonstrate the correspondence between the TOE implementation representation element identifiers and the TOE implementation representation element names. The TOE implementation representation element names shall be in the same form as used or referenced by the development tool to generate the TOE. The timestamp of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time shall be consistent with the creation time of the TOE. The (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time shall be consistent with the (author) origination information of the TOE. The author origination information may be the name of an affiliate of an organization. The list of identifiers of the elements of implementation representation under the configuration scope of shall match with the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The developer's explanation of the functional differences, if any, between the regenerated TOE copy and the original TOE shall take into account all visible differences, if any, between the regenerated TOE copy and the original TOE The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the developer documentation describing the developer's creation of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time to determine that there is a correspondence between the TOE implementation representation identifiers and the TOE implementation representation element names. If the developer simply uses the unique TOE implementation representation identifiers as the TOE implementation representation element names, then the correspondence is trivial. Otherwise, the correspondence should have the following effect. If two elements within the TOE implementation representation share the same name, then either they are the same or they are separately identified by two distinct identifiers. If the TOE implementation representation elements are data files residing in a repository such as a hard drive or in the cloud, then the TOE implementation representation element names are just file names. In that case, it is possible that those two files in the hard drive or in the cloud share the same name, but they have different contents. As a result, two distinct identifiers are necessary to distinguish them apart. The correspondence between the TOE implementation representation element identifiers and the TOE implementation representation element names therefore maps or links the two distinct identifiers to the same file name. The evaluator shall examine the user manual of the developer's development tool used to generate the TOE to determine that the development tool accepts the TOE implementation representation element names as its input parameters. If the TOE implementation representation elements are data files residing in a repository such as a hard drive or in the cloud, then the evaluator only need to discover from the development tool user manual that the development tool accepts local or remote file names as its input parameters. The evaluator shall check the timestamp of the list of TOE implementation representation identifiers as output from the developer action of that it is consistent with the creation time of the TOE as referenced in the ST. Consistency is confirmed by determining that the timestamp on the list of TOE implementation representation identifiers is earlier than the TOE creation time as referenced in the ST, and consistent with the time interval expected from the developer's build process (e.g. as described in deliverables for ). The evaluator shall confirm that the development tool for generating the TOE is capable to use or reference the implementation representation element names. The evaluator shall confirm that the list of unique TOE implementation representation identifiers as recorded during the TOE generation time is consistent with the creation time of the TOE. The evaluator shall confirm that the (author) origination information of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time is consistent with the (author) origination information of the TOE. The evaluator shall check the (author) origination information of the list of unique TOE implementation representation identifiers that it is consistent with the (author) origination information of the TOE as referenced in the ST. This consistency means that the (author) origination of the list of unique TOE implementation representation identifiers is related to the (author) origination of the TOE professionally. A reasonable relationship is that the (author) origination of the list of unique TOE implementation representation identifiers is an employee, a contractor, a supplier, a subsidiary, or an organizational division of, or is identical to the (author) origination of the TOE. The evaluator shall check the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information. The evaluator shall check the integrity of the list of unique TOE implementation representation identifiers as recorded during the TOE generation time and its associated timestamp and (author) origination information by examining the developer documentation describing the maintenance of this integrity characteristic. It is necessary that the developer documentation explains an applicable scenario where none of the following items is freely modified without any proper authorization after its initial existence: the list of unique TOE implementation representation identifiers; its associated timestamp; its associated (author) origination information. Applicable scenarios include the following: these items reside in an access-controlled location and the associated access log/record indicates that these items have not been changed since their initial creation; these items are written in a read only media; these items are digitally signed and are verifiable with a valid public key. The evaluator shall confirm the developer's ability to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The evaluator shall examine the developer documentation describing the developer's mechanism to trace from the TOE to the list of unique TOE implementation representation identifiers as recorded during the TOE generation time to confirm the developer's ability to trace from the TOE to the list of unique TOE implementation representation identifiers. It is necessary that the evaluator follows the developer documentation to find a list of identifiers using the TOE as its input and the evaluator checks that this list of identifiers matches the list of TOE implementation representation identifiers as output from the developer action of . It is acceptable that the developer uses a tracing mechanism that directly or indirectly writes the list of TOE implementation representation identifiers or its representation to the TOE. Alternatively, it is also acceptable that the developer uses a bill of materials database as a tracing mechanism to maintain the correspondence between the TOE and the list of TOE implementation representation identifiers. The evaluator shall confirm that the list of identifiers of the elements of implementation representation under the configuration scope of matches with the list of unique TOE implementation representation identifiers as recorded during the TOE generation time. The evaluator shall check that the TOE implementation representation identifiers in the correspondence as determined in Work unit are capable to identify the element names of implementation representation (as parts of the configuration list) under the configuration scope of . The evaluator shall check that the developer's explanation of the functional differences, if any, between the regenerated TOE copy and the original TOE takes into account all visible differences, if any, between the regenerated TOE copy and the original TOE. The evaluator shall check that the developer's explanation of the functional differences, if any, between the regenerated TOE copy and the original TOE takes into account all visible differences, if any, between the regenerated TOE copy and the original TOE. If parts of the TOE consist of software such as a collection of binary executable files, then it is possible to observe the corresponding differences between the regenerated TOE copy and the original TOE using a binary file editor/viewer or other applicable software diagnostic or testing tools. If parts of the TOE consist of hardware such as integrated circuits, then it is possible to observe the corresponding differences between the regenerated TOE copy and the original TOE using a microscope or other applicable hardware diagnostic or testing tools. In either case, if there is no visible difference between the regenerated TOE copy and the original TOE, then there is no functional difference for the developer to explain. Evaluating a PP is required to demonstrate that the PP is sound and internally consistent, and, if the PP is based on one or more other PPs or on packages, that the PP is a correct instantiation of these PPs and packages. These properties are necessary for the PP to be suitable for use as the basis for writing an ST or another PP. Clause 7 should be used in conjunction with CC Part 1, Annexes B and D, as these annexes clarify the concepts here and provide many examples. This clause describes the evaluation of a PP. The requirements and methodology for PP evaluation are identical for each PP evaluation, regardless of the EAL (or other set of assurance requirements) that is claimed in the PP. The evaluation methodology in this clause is based on the requirements on the PP as specified in . This clause should be used in conjunction with CC Part 1, Annexes B and D, as these Annexes clarify the concepts here and provide many examples. While evaluating a PP that is based on one or more certified PPs, it may be possible to re-use the fact that these PPs were certified. The potential for re-use of the result of a certified PP is greater if the PP under evaluation does not add threats, OSPs, security objectives and/or security requirements to those of the PP that conformance is being claimed to. If the PP under evaluation contains much more than the certified PP, re-use may not be useful at all. The evaluator is allowed to re-use the PP evaluation results by doing certain analyses only partially or not at all if these analyses or parts thereof were already done as part of the PP evaluation. While doing this, the evaluator should assume that the analyses in the PP were performed correctly. An example would be where the PP that conformance is being claimed to contains a set of security requirements, and these were determined to be internally consistent during its evaluation. If the PP under evaluation uses the exact same requirements, the consistency analysis does not have to be repeated during the PP evaluation. If the PP under evaluation adds one or more requirements, or performs operations on these requirements, the analysis will have to be repeated. However, it may be possible to save work in this consistency analysis by using the fact that the original requirements are internally consistent. If the original requirements are internally consistent, the evaluator only has to determine that: the set of all new and/or changed requirements is internally consistent, and the set of all new and/or changed requirements is consistent with the original requirements. The evaluator notes in the ETR each case where analyses are not done or only partially done for this reason. The objective of this family is to determine the validity of the conformance claim. In addition, this family specifies how STs and other PPs are to claim conformance with the PP. The objective of this sub-activity is to determine the validity of various conformance claims. These describe how the PP conforms to CC, other PPs and packages. the PP; the package(s) that the PP claims conformance to. The developer shall provide a conformance claim. The developer shall provide a conformance claim rationale. The developer shall provide a conformance statement. The conformance claim shall identify the CC edition to which the PP claims conformance. The conformance claim shall describe the conformance of the PP to CC Part 2 as either "CC Part 2 conformant" or "CC Part 2 extended". The conformance claim shall describe the conformance of the PP as either "CC Part 3 conformant" or "CC Part 3 extended". The conformance claim shall be consistent with the extended components definition. The conformance claim shall identify all PPs and packages to which the PP claims conformance. The conformance claim shall describe any conformance of the PP to a functional package as one of package-conformant, package-augmented, or package-tailored. The conformance claim shall describe any conformance of the PP to an assurance package as either package-conformant or package-augmented. The conformance claim shall describe any conformance of the PP to another PP as PP Conformant. The conformance claim rationale shall demonstrate that the TOE type is consistent with the TOE type in the PP(s) to which conformance is being claimed. The conformance claim rationale shall demonstrate that the statement of the security problem definition is consistent with the statement of the security problem definition in the PPs and any functional packages for which conformance is being claimed. The conformance claim rationale shall demonstrate that the statement of security objectives is consistent with the statement of security objectives in the PPs and any functional packages for which conformance is being claimed. The conformance claim rationale shall demonstrate that the statement of security requirements is consistent with the statement of security requirements in the PPs and any functional packages for which conformance is being claimed. The conformance statement shall describe the conformance required of any PPs/STs to the PP as one of exact, strict, or demonstrable conformance. For an exact conformance PP, the conformance statement shall contain an allowed-with statement that identifies the set of PPs (if any) to which, in combination with the PP under evaluation, exact conformance is allowed to be claimed. For an exact conformance PP, the conformance statement shall contain an allowed-with statement that identifies the set of PP-Modules (if any) that are allowed to be used with the PP under evaluation in a PP-Configuration. The conformance statement shall identify the set of derived Evaluation Methods and Evaluation Activities (if any) that shall be used with the PP under evaluation. This list shall contain: any Evaluation methods and Evaluation activities that are specified for the PP under evaluation; any Evaluation methods and Evaluation activities specified in conformance statements of PPs to which conformance is being claimed by the PP under evaluation; any Evaluation methods and Evaluation activities specified in the Security Requirements sections of packages to which conformance is being claimed by the PP under evaluation. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the conformance claim identifies the edition of the CC to which the PP claims conformance. The evaluator determines that CC conformance claim identifies the edition of the CC that was used to develop this PP. This should include the edition number of the CC and, unless the International English edition of the CC was used, the language of the edition of the CC that was used. The evaluator shall check that CC conformance claim states a claim of either "CC Part 2 conformant" or "CC Part 2 extended" for the PP. The evaluator shall check that CC conformance claim states a claim of either "CC Part 3 conformant" or "CC Part 3 extended" for the PP. The evaluator shall examine the CC conformance claim for CC Part 2 to determine that it is consistent with the extended components definition. If CC conformance claim contains CC Part 2 conformant, the evaluator determines that the extended components definition does not define functional components. If CC conformance claim contains CC Part 2 extended, the evaluator determines that the extended components definition defines at least one extended functional component. The evaluator shall examine the CC conformance claim for CC Part 3 to determine that it is consistent with the extended components definition. If CC conformance claim contains CC Part 3 conformant, the evaluator determines that the extended components definition does not define assurance components. If CC conformance claim contains CC Part 3 extended, the evaluator determines that the extended components definition defines at least one extended assurance component. The evaluator shall check that the conformance claim contains a PP claim that identifies all PPs for which the PP claims conformance. If the PP does not claim conformance to another PP, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that any referenced PPs are unambiguously identified (e.g. by title and version number, or by the identification included in the introduction of that PP). The evaluator is reminded that claims of partial conformance to a PP are not permitted. If the PP is of exact conformance type, the evaluator determines that the PP claims conformance to no other PPs. If the PP is not of exact conformance type, the evaluator determines that any PPs to which conformance is claimed do not require exact conformance in their conformance statement. The evaluator shall check, for each identified functional package, that the package definition is complete. If the PP does not claim conformance to a functional package, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the package definition is conformant to the requirements from CC Part 1, Clause 9 "Packages" by checking that the functional package includes: A functional package identification, giving a unique name, version, date, sponsor, and the CC edition; A functional package overview, giving a narrative description of the security functionality; A component rationale that provides the rationale for selecting the functional components/requirements included in the package; If the package defines an SPD then: the package includes a security requirements rationale. the package includes a security objectives rationale if security objectives for the environment are defined. If the package is a direct rationale package, there are no security objectives for the TOE defined and the security requirements rationale maps directly to the SPD. If the package is not a direct rationale package, then security objectives for the TOE are defined, the security objectives rationale covers the objectives with respect to the SPD, and the security requirements rationale maps the requirements to the security objectives. one or more security components or requirements (the functional package SFRs); If extended components have been specified then the functional package includes an extended components definition; The evaluator shall check, for each identified assurance package, that the package definition is complete. If the PP does not claim conformance to an assurance package, this work unit is not applicable and therefore considered to be satisfied. If the assurance package is a reference to one of the assurance packages contained in CC Part 5 then this work unit is also considered to be satisfied. The evaluator determines that the package definition is conformant to the requirements from CC Part 1, Clause 9 "Packages" by checking that the assurance package includes: An assurance package identification, giving a unique name, version, date, sponsor, and the CC edition; An assurance package overview, giving a narrative description of the security functionality; One or more security components or requirements (the assurance package SARs) drawn from CC Part 3, extended assurance components or some combination of both; An assurance package shall not include an SPD or security objectives; If extended components have been specified then the assurance package includes an extended components definition; A security requirements rationale that provides the rationale for selecting the assurance components/ requirements included in the package. The evaluator shall check that, for each identified functional package, the conformance claim states a claim of conformance to that package as one of package-conformant, package-augmented, or package-tailored. If the PP does not claim conformance to a functional package, this work unit is not applicable and therefore considered to be satisfied. If the package conformance claim contains package-conformant, the evaluator determines that all assumptions, threats, OSPs, security objectives and SFRs included in the package are included in identical form in the PP (after allowing for iteration, refinement, assignments and selections from the package to be completed as required by the PP). If the package conformance claim contains package-augmented, the evaluator determines that all assumptions, threats, OPSs, Security Objectives, and SFRs included in the package are included in identical form in the PP (after allowing for iteration, refinement, assignments and selections from the package to be completed as required by the PP) except that the PP shall have at least one additional SFR or one SFR that is hierarchically higher than an SFR in the functional package. If the package conformance claim contains package-tailored, the evaluator determines that all assumptions, threats, OPSs, Security Objectives, and SFRs included in the package are included in identical form in the PP (after allowing for iteration, refinement, assignments and selections from the package to be completed as required by the PP) except that the PP shall include additional selection values for at least one of the SFRs in the package, and may also have one or more SFRs that are hierarchically higher than an SFR in the functional package. The evaluator shall check that, for each identified assurance package, the conformance claim states a claim of conformance to that package as one of package-conformant or package-augmented. If the package conformance claim contains package-conformant, the evaluator determines that the PP contains all SARs included in the package, but no additional SARs. If the package conformance claim contains package-augmented, the evaluator determines that the PP contains all SARs included in the package, and at least one additional SAR or at least one SAR that is hierarchical to a SAR in the package. The evaluator shall check that if the PP claims conformance to another PP, that claim is described as PP Conformant. If the PP does not claim conformance to another PP, this work unit is considered satisfied. The evaluator shall examine the conformance claim rationale to determine that the TOE type of the TOE is consistent with all TOE types of the PPs. If the PP does not claim conformance to another PP, this work unit is not applicable and therefore considered to be satisfied. The relation between the types may be simple: a firewall PP claiming conformance to another firewall PP, or more complex: a smart card PP claiming conformance to a number of other PPs at the same time: a PP for the integrated circuit, a PP for the smart card OS, and two PPs for two applications on the smart card. The evaluator shall examine the conformance claim rationale to determine that it demonstrates that the statement of security problem definition is consistent with the statements of security problem definition stated in the PPs and functional packages to which conformance is being claimed, taking into consideration the conformance statement of PPs to which conformance is being claimed. If the PP under evaluation does not claim conformance with any PP or functional packages, this work unit is not applicable and therefore considered to be satisfied. If the conformance claim includes functional packages, the evaluator determines that the security problem definition of the PP under evaluation consists of all assumptions, threats and OSPs of all functional packages. The terms exact, strict and demonstrable conformance are defined in CC Part 1. If packages are used, the rules defined in the following paragraphs concerning strict and demonstrable conformance also hold for the SPD descriptions taken from the packages. Note that since a PP that specifies strict or demonstrable conformance in its conformance statement can only claim conformance to another PP whose conformance statement requires strict or demonstrable conformance, those are the only cases covered in the following paragraphs. If strict conformance is required by the PP to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines whether: the threats in the PP under evaluation are a superset of or identical to the threats in the PP to which conformance is being claimed; the OSPs in the PP under evaluation are a superset of or identical to the OSPs in the PP to which conformance is being claimed; the assumptions in the PP claiming conformance are identical to the assumptions in the PP to which conformance is being claimed, with two possible exceptions described in the following two bullet points: an assumption (or part of an assumption) from the PP to which conformance is claimed, can be omitted, if all security objectives for the operational environment addressing this assumption (or part of an assumption) are replaced by security objectives for the TOE; an assumption can be added to the assumptions defined in the PP to which conformance is claimed, if a justification is given, why the new assumption neither mitigates a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the PP to which conformance is claimed, nor fulfils an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the PP to which conformance is claimed. The following discussion gives some motivation and examples for cases where a PP, omits assumptions from another PP to which conformance is claimed, or adds new assumptions: example for omitting an assumption: A PP to which conformance is claimed, may contain an assumption stating that the operational environment prevents unauthorized modification or interception of data sent to an external interface of the TOE. This may be the case if the TOE accepts data in clear text and without integrity protection at this interface and is assumed to be located in a secure operational environment, which will prevent attackers from accessing these data. The assumption will then be mapped in the PP, to which conformance is claimed, to some objective for the operational environment stating that the data interchanged at this interface are protected by adequate measures in the operational environment. If a PP claiming this PP, defines a more secure TOE, which has an additional security objective stating that the TOE itself protects these data, for example by providing a secure channel for encryption and integrity protection of all data transferred via this interface, the corresponding objective and assumption for the operational environment can be omitted from the PP claiming conformance. This is also called re-assigning of the objective, since the objective is re-assigned from the operational environment to the TOE. Note, that this TOE is still secure in an operational environment fulfilling the omitted assumption and therefore still fulfils the PP to which conformance is claimed. example for adding an assumption: In this example, the PP to which conformance is claimed, is designed to specify requirements for a TOE of type "Firewall" and the author of another PP wishes to claim conformance to this PP for a TOE, which implements a firewall, but additionally provides the functionality of a virtual private network (VPN) component. For the VPN functionality, the TOE needs cryptographic keys and these keys may also have to be handled securely by the operational environment (e. g. if symmetric keys are used to secure the network connection and therefore need to be provided in some secure way to other components in the network). In this case, it is acceptable to add an assumption that the cryptographic keys used by the VPN are handled securely by the operational environment. This assumption does not address threats or OSPs of the PP to which conformance is claimed, and therefore fulfils the conditions stated above. counterexample for adding an assumption: In a variant of the first example a PP to which conformance is claimed, may already contain an objective for the TOE to provide a secure channel for one of its interfaces, and this objective is mapped to a threat of unauthorized modification or reading of the data on this interface. In this case, it is clearly not allowed for another PP claiming this PP, to add an assumption for the operational environment, which assumes that the operational environment protects data on this interface against modification or unauthorized reading of the data. This assumption would reduce a threat, which is meant to be addressed by the TOE. Therefore, a TOE fulfilling a PP with this added assumption would not automatically fulfil the PP to which conformance is claimed, anymore and this addition is therefore not allowed. second counterexample for adding an assumption: In the example above of a TOE implementing a firewall it would not be admissible to add a general assumption that the TOE is only connected to trusted devices, because this would obviously remove essential threats relevant for a firewall (namely that there is untrusted IP traffic, which needs to be filtered). Therefore, this addition would not be allowed. If demonstrable conformance is required by the PP to which conformance is being claimed, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security problem definition of the PP under evaluation is equivalent or more restrictive than the statement of security problem definition in the PP to which conformance is being claimed. For this, the conformance claim rationale needs to demonstrate that the security problem definition in the PP claiming conformance is equivalent (or more restrictive) than the security problem definition in the PP to which conformance is claimed. This means that: all TOEs that would meet the security problem definition in the PP claiming conformance also meet the security problem definition in the PP to which conformance is claimed. This can also be shown indirectly by demonstrating that every event, which realizes a threat defined in the PP to which conformance is claimed, or violates an OSP defined in the PP to which conformance is claimed, would also realize a threat stated in the PP claiming conformance or violate an OSP defined in the PP claiming conformance. Note that fulfilling an OSP stated in the PP claiming conformance may avert a threat stated in the PP to which conformance is claimed, or that averting a threat stated in the PP claiming conformance may fulfil an OSP stated in the PP to which conformance is claimed, so threats and OSPs can substitute each other; all operational environments that would meet the security problem definition in the PP to which conformance is claimed, would also meet the security problem definition in the PP claiming conformance (with one exception in the next bullet); besides a set of assumptions in the PP claiming conformance needed to demonstrate conformance to the SPD of the PP to which conformance is claimed, a PP claiming conformance may specify further assumptions, but only if these additional assumptions are independent of and do not affect the security problem definition as defined in the PP to which conformance is claimed. More detailed, there are no assumptions in the PP claiming conformance that exclude threats to the TOE that need to be countered by the TOE according to the PP to which conformance is claimed. Similarly, there are no assumptions in the PP claiming conformance that realize aspects of an OSP stated in the PP to which conformance is claimed, which are meant to be fulfilled by the TOE according to the PP to which conformance is claimed. The evaluator shall examine the conformance claim rationale to determine that the statement of security objectives is consistent with the statement of security objectives in the PPs and functional packages to which conformance is being claimed, taking into consideration the conformance statement of PPs to which conformance is being claimed. If the PP does not claim conformance to another PP nor to functional packages, this work unit is not applicable and therefore considered to be satisfied. If conformance is claimed to any functional packages, the evaluator determines that the security objectives of the PP under evaluation include all security objectives of all functional packages to which conformance is claimed. If packages are used, the rules defined in the following paragraphs concerning strict and demonstrable conformance also hold for the security objectives taken from the packages. Note that since a PP can only claim conformance to another PP whose conformance statement requires strict or demonstrable conformance, those are the only cases covered in the following paragraphs. If strict conformance is required by the PP to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines whether: the PP under evaluation contains all security objectives for the TOE of the PP to which conformance is being claimed. Note that it is allowed for the PP under evaluation to have additional security objectives for the TOE; the security objectives for the operational environment in the PP claiming conformance are identical to the security objectives for the operational environment in the PP to which conformance is being claimed, with two possible exceptions described in the following two bullet points; a security objective for the operational environment (or part of such security objective) from the PP to which conformance is claimed, can be replaced by the same (part of the) security objective stated for the TOE; a security objective for the operational environment can be added to the objectives defined in the PP to which conformance is claimed, if a justification is given, why the new objective neither mitigates a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the PP to which conformance is claimed, nor fulfils an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the PP to which conformance is claimed. When examining a PP claiming another PP which omits security objectives for the operational environment from the PP to which conformance is claimed, or adds new security objectives for the operational environment, the evaluator shall carefully determine, if the conditions given above are fulfilled. The examples given for the case of assumptions in the preceding work unit are also valid here. If demonstrable conformance is required by the PP to which conformance is being claimed, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security objectives of the PP under evaluation is equivalent or more restrictive than the statement of security objectives in the PP to which conformance is being claimed. For this the conformance claim rationale needs to demonstrate that the security objectives in the PP claiming conformance are equivalent to (or more restrictive than) the security objectives in the PP to which conformance is claimed. This means that: all TOEs that would meet the security objectives for the TOE in the PP claiming conformance also meet the security objectives for the TOE in the PP to which conformance is claimed; all operational environments that would meet the security objectives for the operational environment in the PP to which conformance is claimed, would also meet the security objectives for the operational environment in the PP claiming conformance (with one exception in the next bullet); besides a set of security objectives for the operational environment in the PP claiming conformance, which are used to demonstrate conformance to the set of security objectives defined in the PP to which conformance is claimed, a PP claiming conformance may specify further security objectives for the operational environment, but only if these security objectives neither affect the original set of security objectives for the TOE nor the security objectives for the operational environment as defined in the PP to which conformance is claimed. The evaluator shall examine the PP to determine that the statement of security requirements is consistent with all security requirements stated in the PPs and any functional packages to which conformance is being claimed, taking into consideration the conformance statements of PPs to which conformance is being claimed. If the PP does not claim conformance to another PP nor to functional packages, this work unit is not applicable and therefore considered to be satisfied. If conformance is claimed to any functional packages, the evaluator determines that the SFRs of the PP under evaluation include all SFRs (or hierarchical SFRs) of all functional packages to which conformance is claimed. If packages are used, the rules defined in the following paragraphs concerning strict and demonstrable conformance also hold for the SFRs taken from the packages. Note that since a PP can only claim conformance to another PP whose conformance statement requires strict or demonstrable conformance, those are the only cases covered in the following paragraphs. If strict conformance is required by the PP to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines whether the statement of security requirements in the PP under evaluation is a superset of or identical to the statement of security requirements in the PP to which conformance is being claimed (for strict conformance). If demonstrable conformance is required by the PP to which conformance is being claimed, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security requirements of the PP under evaluation is equivalent or more restrictive than the statement of security requirements in the PP to which conformance is being claimed. For: SFRs: The conformance rationale in the PP claiming conformance shall demonstrate that the overall set of requirements defined by the SFRs in the PP claiming conformance is equivalent (or more restrictive) than the overall set of requirements defined by the SFRs in the PP to which conformance is claimed. This means that all TOEs that would meet the requirements defined by the set of all SFRs in the PP claiming conformance would also meet the requirements defined by the set of all SFRs in the PP to which conformance is claimed; SARs: The PP claiming conformance shall contain all SARs in the PP to which conformance is claimed, but may claim additional SARs or replace SARs by hierarchically stronger SARs. The completion of operations in the PP claiming conformance must be consistent with that in the PP to which conformance is claimed; either the same completion will be used in the PP claiming conformance as that in the PP to which conformance is claimed or a completion that makes the SAR more restrictive (the rules of refinement apply). The evaluator shall check that the PP conformance statement states a claim of exact-PP, strict-PP or demonstrable-PP conformance. The evaluator shall check the conformance statement to determine that it contains an allowed-with statement that lists the set of PPs to which, in combination with the PP being evaluated, an exact conformance claim (in an ST or PP-Configuration) is allowed. If the PP does not require exact conformance in its conformance statement, this work unit does not apply and is therefore considered satisfied. If the PP does not allow claims of exact conformance to it in combination with any other PPs, then no list of PPs is required and this work unit is considered satisfied. The usage of the allowed-with statement is a matter of policy and is not addressed here. There are no other actions for the evaluator other than determining that the list is present. The evaluator shall check the conformance statement to determine that it contains an allowed-with statement that lists the set of PP-Modules that, in combination with the PP being evaluated, can be present in a PP-Configuration that requires exact conformance. If the PP does not require exact conformance in its conformance statement, this work unit does not apply and is therefore considered satisfied. If the PP does not allow claims of exact conformance to it in combination with any PP-Modules, then no list of PP-Modules is required and this work unit is considered satisfied. The usage of the allowed-with statement is a matter of policy and is not addressed here. There are no other actions for the evaluator other than determining that the list is present. The evaluator shall check the conformance statement of the PP under evaluation to determine that: if any derived Evaluation Methods and Evaluation Activities are required by other items to which the PP claims conformance then these are all identified in the PP under evaluation, along with any derived Evaluation Methods and Evaluation Activities that the PP itself requires; the list of derived Evaluation Methods and Evaluation Activities is sufficiently structured and detailed to unambiguously identify and locate every member of the list; if there is any overlap in the scope of the identified Evaluation Methods and Evaluation Activities (i.e. where an overlay exists as described in CC Part 4) then the rationale for the resulting set of Evaluation Methods and Evaluation Activities is applicable to the TOE as described by the PP under evaluation. The intention of this work unit is to ensure that when evaluating a TOE that claims conformance with the PP under evaluation then the correct Evaluation Methods and Evaluation Activities can be used. This means that identification in the PP need not list individual Evaluation Activities where these are unambiguously included in a listed Evaluation Method. Similarly, where multiple Evaluation Methods or Evaluation Activities are included in a single document then it is sufficient to reference the document, provided this does lead to unambiguous identification of the Evaluation Methods and Evaluation Activities that apply to the PP under evaluation. If a document lists multiple different Evaluation Methods applicable to different use cases then it would not be sufficient to reference the document: the relevant use cases would also have to be identified. Extended security requirements are requirements that are not based on components from CC Part 2 or this document, but which are based on extended components: components defined by the PP author. Evaluation of the definition of extended components is necessary to determine that they are clear and unambiguous, and that they are necessary, i.e. they may not be clearly expressed using existing CC Part 2 or this document components. The objective of this sub-activity is to determine whether extended components have been clearly and unambiguously defined, and whether they are necessary, i.e. they may not be clearly expressed using existing CC Part 2 or CC Part 3 components. the PP. The developer shall provide a statement of security requirements. The developer shall provide an extended components definition. The statement of security requirements shall identify all extended security requirements. The extended components definition shall define an extended component for each extended security requirement. The extended components definition shall describe how each extended component is related to the existing CC series components, families, and classes. The extended components definition shall use the existing CC series components, families, classes, and methodology as a model for presentation. The extended components shall consist of measurable and objective elements such that conformance or nonconformance to these elements may be demonstrated. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that all security requirements in the statement of security requirements that are not identified as extended requirements are present in CC Part 2 or in CC Part 3. The evaluator shall check that the extended components definition defines an extended component for each extended security requirement. If the PP does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. A single extended component may be used to define multiple iterations of an extended security requirement, it is not necessary to repeat this definition for each iteration. The evaluator shall examine the extended components definition to determine that it describes how each extended component fits into the existing CC components, families, and classes. If the PP does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that each extended component is either: a member of an existing CC Part 2 or CC Part 3 family; or a member of a new family defined in the PP. If the extended component is a member of an existing CC Part 2 or CC Part 3 family, the evaluator determines that the extended components definition adequately describes why the extended component should be a member of that family and how it relates to other components of that family. If the extended component is a member of a new family defined in the PP, the evaluator confirms that the extended component is not appropriate for an existing family. If the PP defines new families, the evaluator determines that each new family is either: a member of an existing CC Part 2 or CC Part 3 class; or a member of a new class defined in the PP. If the family is a member of an existing CC Part 2 or CC Part 3 class, the evaluator determines that the extended components definition adequately describes why the family should be a member of that class and how it relates to other families in that class. If the family is a member of a new class defined in the PP, the evaluator confirms that the family is not appropriate for an existing class. The evaluator shall examine the extended components definition to determine that each definition of an extended component identifies all applicable dependencies of that component. If the PP does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator confirms that no applicable dependencies have been overlooked by the PP author. The evaluator shall examine the extended components definition to determine that each extended functional component uses the existing CC Part 2 components as a model for presentation. If the PP does not contain extended SFRs, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the extended functional component is consistent with CC Part 2, 7.1.4, Component structure. If the extended functional component uses operations, the evaluator determines that the extended functional component is consistent with CC Part 1, 8.2, Operations. If the extended functional component is hierarchical to an existing functional component, the evaluator determines that the extended functional component is consistent with CC Part 2, Introduction. The evaluator shall examine the extended components definition to determine that each definition of a new functional family uses the existing CC functional families as a model for presentation. If the PP does not define new functional families, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new functional families are defined consistent with CC Part 2, 7.1.3, Family structure. The evaluator shall examine the extended components definition to determine that each definition of a new functional class uses the existing CC functional classes as a model for presentation. If the PP does not define new functional classes, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new functional classes are defined consistent with CC Part 2, 7.1.2, Class structure. The evaluator shall examine the extended components definition to determine that each definition of an extended assurance component uses the existing CC Part 3 components as a model for presentation. If the PP does not contain extended SARs, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the extended assurance component definition is consistent with CC Part 3, 6.4, Assurance component structure. If the extended assurance component uses operations, the evaluator determines that the extended assurance component is consistent with CC Part 1, 8.2, Operations. If the extended assurance component is hierarchical to an existing assurance component, the evaluator determines that the extended assurance component is consistent with CC Part 3, 6.4, Assurance component structure. The evaluator shall examine the extended components definition to determine that, for each defined extended assurance component, applicable methodology has been provided. If the PP does not contain extended SARs, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that, for each evaluator action element of each extended SAR, one or more work units are provided and that successfully performing all work units for a given evaluator action element will demonstrate that the element has been achieved. The evaluator shall examine the extended components definition to determine that each definition of a new assurance family uses the existing CC assurance families as a model for presentation. If the PP does not define new assurance families, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new assurance families are defined consistent with CC Part 3, 6.3, Assurance family structure. The evaluator shall examine the extended components definition to determine that each definition of a new assurance class uses the existing CC assurance classes as a model for presentation. If the PP does not define new assurance classes, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new assurance classes are defined consistent with CC Part 3, 6.2, Assurance class structure. The evaluator shall examine the extended components definition to determine that each element in each extended component is measurable and states objective evaluation requirements, such that conformance or nonconformance can be demonstrated. If the PP does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that elements of extended functional components are stated in such a way that they are testable, and traceable through the appropriate TSF representations. The evaluator also determines that elements of extended assurance components avoid the need for subjective evaluator judgement. The evaluator is reminded that whilst being measurable and objective is appropriate for all evaluation criteria, it is acknowledged that no formal method exists to prove such properties. Therefore, the existing CC functional and assurance components are to be used as a model for determining what constitutes conformance to this requirement. The evaluator shall confirm that no extended component may be clearly expressed using existing components. The evaluator shall examine the extended components definition to determine that each extended component may not be clearly expressed using existing components. If the PP does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator should take components from CC Part 2 and CC Part 3, other extended components that have been defined in the PP, combinations of these components, and possible operations on these components into account when making this determination. The evaluator is reminded that the role of this work unit is to preclude unnecessary duplication of components, that is, components that may be clearly expressed by using other components. The evaluator should not undertake an exhaustive search of all possible combinations of components including operations in an attempt to find a way to express the extended component by using existing components. The objective of this family is to describe the TOE in a narrative way. Evaluation of the PP introduction is required to demonstrate that the PP is correctly identified, and that the PP reference and TOE overview are consistent with each other. The objective of this sub-activity is to determine whether the PP is correctly identified, and whether the PP reference and TOE overview are consistent with each other. the PP. The developer shall provide a PP introduction. The PP introduction shall contain a PP reference and a TOE overview. The PP reference shall uniquely identify the PP. The TOE overview shall summarize the usage and major security features of the TOE. The TOE overview shall identify the TOE type. The TOE overview shall identify any non-TOE hardware/software/firmware available to the TOE. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the PP introduction contains a PP reference and a TOE overview. The evaluator shall examine the PP reference to determine that it uniquely identifies the PP. The evaluator determines that the PP reference identifies the PP itself, so that it may be easily distinguished from other PPs, and that it also uniquely identifies each version of the PP, e.g. by including a version number and/or a date of publication. The PP should have some referencing system that is capable of supporting unique references (e.g. use of numbers, letters or dates). The evaluator shall examine the TOE overview to determine that it describes the usage and major security features of the TOE. The TOE overview should briefly (i.e. several paragraphs) describe the usage and major security features expected of the TOE. The TOE overview should enable consumers and potential TOE developers to quickly determine whether the PP is of interest to them. The evaluator determines that the overview is clear enough for TOE developers and consumers, and sufficient to give them a general understanding of the intended usage and major security features of the TOE. The evaluator shall check that the TOE overview identifies the TOE type. The evaluator shall examine the TOE overview to determine that it identifies any non-TOE hardware/software/firmware available to the TOE. While some TOEs may run stand-alone, other TOEs (notably software TOEs) need additional hardware, software or firmware to operate. In this subclause of the PP, the PP author lists all hardware, software, and/or firmware that will be available for the TOE to run on. This identification should be detailed enough for potential consumers and TOE developers to determine whether their TOE may operate with the listed hardware, software and firmware. The security objectives are a concise statement of the intended response to the security problem defined through the family. Evaluation of the security objectives is required to demonstrate that the security objectives adequately and completely address the security problem definition and that the division of this problem between the TOE and its operational environment is clearly defined. The components in this family are levelled on whether they prescribe only security objectives for the operational environment, or also security objectives for the TOE. The objective of this sub-activity is to determine whether the security objectives for the operational environment are clearly defined. the PP. The developer shall provide a statement of security objectives for the operational environment. The developer shall provide a security objectives rationale objectives for the operational environment. The statement of security objectives shall describe the security objectives for the operational environment. The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective, and assumptions upheld by that security objective. The security objectives rationale shall demonstrate that the security objectives for the operational environment uphold all assumptions. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security objectives defines the security objectives for the operational environment. The evaluator checks that the security objectives for the operational environment are identified. The evaluator shall check that the security objectives rationale traces the security objectives for the operational environment back to threats countered by that security objective, to OSPs enforced by that security objective, and to assumptions upheld by that security objective. Each security objective for the operational environment may trace back to threats, OSPs, assumptions, or a combination of threats, OSPs and/or assumptions, but it must trace back to at least one threat, OSP or assumption. Failure to trace a security objective for the operational environment back to at least a threat, OSP or assumption, implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the operational environment has no useful purpose. There is no prescribed location where this tracing element of the rationale must be placed: for example, the relevant parts may be located under each threat, OSP and assumption in order to help make the security argument clearer and easier to read. The evaluator shall examine the security objectives rationale to determine that for each assumption for the operational environment it contains an appropriate justification that the security objectives for the operational environment are suitable to uphold that assumption. If no security objectives for the operational environment trace back to the assumption, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an assumption about the operational environment of the TOE demonstrates that the security objectives are sufficient: if all security objectives for the operational environment that trace back to that assumption are achieved, the operational environment upholds the assumption. The evaluator also determines that each security objective for the operational environment that traces back to an assumption about the operational environment of the TOE is necessary: when the security objective is achieved it actually contributes to the operational environment upholding the assumption. Note that simply listing in the security objectives rationale the security objectives for the operational environment associated with each assumption may be a part of a justification, but does not constitute a justification by itself. A descriptive justification is required, although in simple cases this justification may be as minimal as "Security Objective X directly upholds Assumption Y". The objective of this sub-activity is to determine whether the security objectives adequately and completely address the security problem definition and that the division of this problem between the TOE and its operational environment is clearly defined. the PP. The developer shall provide a statement of security objectives. The developer shall provide a security objectives rationale. The statement of security objectives shall describe the security objectives for the TOE and the security objectives for the operational environment. The security objectives rationale shall trace each security objective for the TOE back to threats countered by that security objective and OSPs enforced by that security objective. The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective, and assumptions upheld by that security objective. The security objectives rationale shall demonstrate that the security objectives counter all threats. The security objectives rationale shall demonstrate that the security objectives enforce all OSPs. The security objectives rationale shall demonstrate that the security objectives for the operational environment uphold all assumptions. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security objectives defines the security objectives for the TOE and the security objectives for the operational environment. The evaluator checks that both categories of security objectives are clearly identified and separated from the other category. The evaluator shall check that the security objectives rationale traces all security objectives for the TOE back to threats countered by the objectives and/or OSPs enforced by the objectives. Each security objective for the TOE may trace back to threats or OSPs, or a combination of threats and OSPs, but it must trace back to at least one threat or OSP. Optional requirements may require Threats/OSPs to be specified, and security objectives associated with these SPD elements are also covered by this work unit. Failure to trace a security objective for the TOE back to at least one threat or OSP, implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the TOE has no useful purpose. The evaluator shall check that the security objectives rationale traces the security objectives for the operational environment back to threats countered by that security objective, to OSPs enforced by that security objective, and to assumptions upheld by that security objective. Each security objective for the operational environment may trace back to threats, OSPs, assumptions, or a combination of threats, OSPs and/or assumptions, but it must trace back to at least one threat, OSP or assumption. Failure to trace a security objective for the operational environment back to at least one threat, OSP, or assumption, implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the operational environment has no useful purpose. The evaluator shall examine the security objectives rationale to determine that it justifies for each threat that the security objectives are suitable to counter that threat. If no security objectives trace back to the threat, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for a threat shows whether the threat is removed, diminished or mitigated. The evaluator determines that the justification for a threat demonstrates that the security objectives are sufficient: if all security objectives that trace back to the threat are achieved, the threat is removed, sufficiently diminished, or the effects of the threat are sufficiently mitigated. Note that the tracings from security objectives to threats provided in the security objectives rationale may be part of a justification, but do not constitute a justification by themselves. Even in the case that a security objective is merely a statement reflecting the intent to prevent a particular threat from being realised, a justification is required, but this justification may be as minimal as "Security Objective X directly counters Threat Y". The evaluator also determines that each security objective that traces back to a threat is necessary: when the security objective is achieved it actually contributes to the removal, diminishing or mitigation of that threat. The evaluator shall examine the security objectives rationale to determine that for each OSP it justifies that the security objectives are suitable to enforce that OSP. If no security objectives trace back to the OSP, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an OSP demonstrates that the security objectives are sufficient: if all security objectives that trace back to that OSP are achieved, the OSP is enforced. The evaluator also determines that each security objective that traces back to an OSP is necessary: when the security objective is achieved it actually contributes to the enforcement of the OSP. Note that the tracings from security objectives to OSPs provided in the security objectives rationale may be part of a justification, but do not constitute a justification by themselves. In the case that a security objective is merely a statement reflecting the intent to enforce a particular OSP, a justification is required, but this justification may be as minimal as "Security Objective X directly enforces OSP Y". The evaluator shall examine the security objectives rationale to determine that for each assumption for the operational environment it contains an appropriate justification that the security objectives for the operational environment are suitable to uphold that assumption. If no security objectives for the operational environment trace back to the assumption, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an assumption about the operational environment of the TOE demonstrates that the security objectives are sufficient: if all security objectives for the operational environment that trace back to that assumption are achieved, the operational environment upholds the assumption. The evaluator also determines that each security objective for the operational environment that traces back to an assumption about the operational environment of the TOE is necessary: when the security objective is achieved it actually contributes to the operational environment upholding the assumption. Note that the tracings from security objectives for the operational environment to assumptions provided in the security objectives rationale may be a part of a justification, but do not constitute a justification by themselves. Even in the case that a security objective of the operational environment is merely a restatement of an assumption, a justification is required, but this justification may be as minimal as "Security Objective X directly upholds Assumption Y". The SFRs form a clear, unambiguous and well-defined description of the expected security behaviour of the TOE. The SARs form a clear, unambiguous and well-defined description of the expected activities that will be undertaken to gain assurance in the TOE. Evaluation of the security requirements is required to ensure that they are clear, unambiguous and well-defined. The components in this family are levelled on whether the SFRs are derived from SPD, or whether the SFRs are derived from security objectives for the TOE. The objective of this sub-activity is to determine whether the SFRs and SARs are clear, unambiguous and well-defined, whether they are internally consistent, and whether the SFRs counter the threats and implement the organisational security policies of the TOE. the PP. The developer shall provide a statement of security requirements. The developer shall provide a security requirements rationale. The statement of security requirements shall describe the SFRs and the SARs. All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined. The statement of security requirements shall identify all operations on the security requirements. All operations shall be performed correctly. Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied. The security requirements rationale shall trace each SFR back to the threats countered by that SFR and the OSPs enforced by that SFR. The security requirements rationale shall demonstrate that the SFRs (in conjunction with the security objectives for the environment) counter all threats for the TOE. The security requirements rationale shall demonstrate that the SFRs (in conjunction with the security objectives for the environment) enforce all OSPs for the TOE. The security requirements rationale shall explain why the SARs were chosen. The statement of security requirements shall be internally consistent. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security requirements describes the SFRs. The evaluator determines that each SFR is identified by one of the following means: by reference to an individual component in CC Part 2; by reference to an extended component in the extended components definition of the PP; by reference to a PP that the PP claims to be conformant with including any optional requirements defined in the PP; by reference to a security requirements package that the PP claims to be conformant with; by reproduction in the PP. It is not required to use the same means of identification for all SFRs. The evaluator shall check that the statement of security requirements describes the SARs. The evaluator determines that each SAR is identified by one of the following means: by reference to an individual component in CC Part 3; by reference to an extended component in the extended components definition of the PP; by reference to a PP that the PP claims to be conformant with; by reference to a security requirements package that the PP claims to be conformant with; by reproduction in the PP. It is not required to use the same means of identification for all SARs. The evaluator shall examine the PP to determine that all subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs are defined. The evaluator determines that the PP defines all: (types of) subjects and objects that are used in the SFRs; (types of) security attributes of subjects, users, objects, information, sessions and/or resources, possible values that these attributes may take and any relations between these values (e.g. top_secret is "higher" than secret); (types of) operations that are used in the SFRs, including the effects of these operations; (types of) external entities in the SFRs; other terms that are introduced in the SFRs and/or SARs by completing operations, if these terms are not immediately clear, or are used outside their dictionary definition. The goal of this work unit is to ensure that the SFRs and SARs are well-defined and that no misunderstanding may occur due to the introduction of vague terms. This work unit should not be taken into extremes, by forcing the PP author to define every single word. The general audience of a set of security requirements should be assumed to have a reasonable knowledge of IT, security and the CC series. All of the above may be presented in groups, classes, roles, types or other groupings or characterisations that allow easy understanding. The evaluator is reminded that these lists and definitions do not have to be part of the statement of security requirements, but may be placed (in part or in whole) in different subclauses. This can be especially applicable if the same terms are used in the rest of the PP. The evaluator shall check that the statement of security requirements identifies all operations on the security requirements. The evaluator determines that all operations are identified in each SFR or SAR where such an operation is used. This includes both completed operations and uncompleted operations. Identification may be achieved by typographical distinctions, or by explicit identification in the surrounding text, or by any other distinctive means. If the PP defines selection-based SFRs, the evaluator determines that the PP clearly identifies the dependencies between the selection in an SFR and the selection-based SFR(s) to be included in the PP/ST should that selection be chosen by the PP/ST author. The evaluator shall examine the statement of security requirements to determine that all assignment operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all iteration operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all selection operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all refinement operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that each dependency of the security requirements is either satisfied, or that the security requirements rationale justifies the dependency not being satisfied. A dependency is satisfied by the inclusion of the relevant component (or one that is hierarchical to it) within the statement of security requirements. The component used to satisfy the dependency should, if necessary, be modified by operations to ensure that it actually satisfies that dependency. A justification that a dependency is not met should address either: why the dependency is not necessary or useful, in which case no further information is required; or that the dependency has been addressed by the operational environment of the TOE, in which case the justification should describe how the security objectives for the operational environment address this dependency. The evaluator ensures that if a functional package defines a dependency on another functional package, then that functional package is included in the PP. If a functional package identifies dependencies on its requirements that need to be satisfied by the underlying PP, the evaluator ensures that their analysis covers these dependencies as well. The evaluator shall check that the security requirements rationale traces each SFR back to the threats countered by that SFR and OSPs enforced by that SFR. The evaluator determines that each SFR is traced back to at least one threat or OSP for the TOE. Failure to trace implies that either the security requirements rationale is incomplete, or the SFR has no useful purpose. There is no prescribed location where this tracing element of the rationale must be placed: for example, the relevant parts may be located under each threat and OSP in order to help make the security argument clearer and easier to read. The evaluator shall examine the security requirements rationale to determine that for each threat it demonstrates that the SFRs are suitable to meet that threat. If no SFRs trace back to a threat, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for a threat shows whether the threat is removed, diminished or mitigated. The evaluator determines that the justification for a threat demonstrates that the SFRs are sufficient: if all SFRs that trace back to the threat are achieved then, in the context of any applicable OSPs and assumptions, the threat is removed, sufficiently diminished, or the effects of the threat are sufficiently mitigated. Note that simply listing in the security requirements rationale the SFRs associated with each threat may be part of a justification, but does not constitute a justification by itself. A descriptive justification is required, although in simple cases this justification may be as minimal as "SFR X directly counters Threat Y". The evaluator also determines that each SFR that traces back to a threat is necessary: when the SFR is implemented it actually contributes to the removal, diminishing or mitigation of that threat. The evaluator shall examine the security requirements rationale to determine that for each OSP it justifies that the SFRs are suitable to enforce that OSP. If no SFRs or security objectives for the operational environment trace back to the OSP, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an OSP demonstrates that the security objectives are sufficient: if all SFRs that trace back to that OSP are achieved then, in the context of any applicable assumptions, the OSP is enforced. The evaluator also determines that each SFR that traces back to an OSP is necessary: when the SFR is implemented it actually contributes to the enforcement of the OSP. Note that simply listing in the security requirements rationale the SFRs associated with each OSP may be part of a justification, but does not constitute a justification by itself. A descriptive justification is required, although in simple cases this justification may be as minimal as "SFR X directly enforces OSP Y". The evaluator shall check that the security requirements rationale explains why the SARs were chosen. The evaluator is reminded that any explanation is correct, as long as it is coherent and neither the SARs nor the explanation have obvious inconsistencies with the remainder of the PP. An example of an obvious inconsistency between the SARs and the remainder of the PP would be to have threat agents that are very capable, but an SAR that does not protect against these threat agents. The evaluator shall examine the statement of security requirements to determine that it is internally consistent. The evaluator determines that the combined set of all SFRs and SARs is internally consistent. With respect to optional requirements, the evaluator determines that: all optional requirements either trace to an SPD element that is itself not optional, or trace to an SPD element that is clearly associated with that optional SFR; all optional requirements are clearly identified as either: elective and therefore for inclusion purely at the discretion of the ST author (i.e. conformance to the PP does not depend on their inclusion in the ST); or conditional and therefore required if a conformant TOE implements the functionality covered by the requirement. all optional requirements do not conflict with non-optional requirements (a capability cannot be both required and optional; however, a base capability can be required with enhancements to that capability being specified as optional). The evaluator determines that on all occasions where different security requirements apply to the same types of developer evidence, events, operations, data, tests to be performed etc. or to "all objects", "all subjects" etc., that these requirements do not conflict. Some possible conflicts are: an extended SAR specifying that the design of a certain cryptographic algorithm is to be kept secret, and another extended SAR specifying an open source review; specifying that subject identity is to be logged, specifying who has access to these logs, and specifying that some actions of subjects should be unobservable to other subjects. If the subject that should not be able to see an activity may access logs of this activity, these SFRs conflict; specifying deletion of information no longer needed, and specifying that a TOE may return to a previous state. If the information that is needed for the rollback to the previous state has been deleted, these requirements conflict; multiple iterations of , especially where some iterations cover the same subjects, objects, or operations. If one access control SFR allows a subject to perform an operation on an object, while another access control SFR does not allow this, these requirements conflict. The objective of this sub-activity is to determine whether the SFRs and SARs are clear, unambiguous and well-defined, whether they are internally consistent, and whether the SFRs meet the security objectives of the TOE. the PP. The developer shall provide a statement of security requirements. The developer shall provide a security requirements rationale. The statement of security requirements shall describe the SFRs and the SARs. All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined. The statement of security requirements shall identify all operations on the security requirements. All operations shall be performed correctly. Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied. The security requirements rationale shall trace each SFR back to the security objectives for the TOE enforced by that SFR. The security requirements rationale shall demonstrate that the SFRs meet all security objectives for the TOE. The security requirements rationale shall explain why the SARs were chosen. The statement of security requirements shall be internally consistent. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security requirements describes the SFRs. The evaluator determines that each SFR is identified by one of the following means: by reference to an individual component in CC Part 2; by reference to an extended component in the extended components definition of the PP; by reference to an individual component in a PP that the PP claims to be conformant with, including any optional requirements defined in the PP; by reference to an individual component in a security requirements package that the PP claims to be conformant with; by reproduction in the PP. It is not required to use the same means of identification for all SFRs. The evaluator shall check that the statement of security requirements describes the SARs. The evaluator determines that each SAR is identified by one of the following means: by reference to an individual component in CC Part 3; by reference to an extended component in the extended components definition of the PP; by reference to an individual component in a PP that the PP claims to be conformant with; by reference to an individual component in a security requirements package that the PP claims to be conformant with; by reproduction in the PP. It is not required to use the same means of identification for all SARs. Note that if optional requirements are defined by the PP, there may be associated threats that are covered by this work unit. The evaluator shall examine the PP to determine that all subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs are defined. The evaluator determines that the PP defines all: (types of) subjects and objects that are used in the SFRs; (types of) security attributes of subjects, users, objects, information, sessions and/or resources, possible values that these attributes may take and any relations between these values (e.g. top_secret is "higher" than secret); (types of) operations that are used in the SFRs, including the effects of these operations; (types of) external entities in the SFRs; other terms that are introduced in the SFRs and/or SARs by completing operations, if these terms are not immediately clear, or are used outside their dictionary definition. The goal of this work unit is to ensure that the SFRs and SARs are well-defined and that no misunderstanding may occur due to the introduction of vague terms. This work unit should not be taken into extremes, by forcing the PP author to define every single word. The general audience of a set of security requirements should be assumed to have a reasonable knowledge of IT, security and the CC series. All of the above may be presented in groups, classes, roles, types or other groupings or characterisations that allow easy understanding. The evaluator is reminded that these lists and definitions do not have to be part of the statement of security requirements, but may be placed (in part or in whole) in different subclauses. This can be especially applicable if the same terms are used in the rest of the PP. The evaluator shall check that the statement of security requirements identifies all operations on the security requirements. The evaluator determines that all operations are identified in each SFR or SAR where such an operation is used. This includes both completed operations and uncompleted operations. Identification may be achieved by typographical distinctions, or by explicit identification in the surrounding text, or by any other distinctive means. If the PP defines selection-based SFRs, the evaluator determines that the PP clearly identifies the dependencies between the selection in an SFR and the selection-based SFR(s) to be included in the PP/ST should that selection be chosen by the PP/ST author. The evaluator shall examine the statement of security requirements to determine that all assignment operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all iteration operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all selection operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that all refinement operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2, Operations. The evaluator shall examine the statement of security requirements to determine that each dependency of the security requirements is either satisfied, or that the security requirements rationale justifies the dependency not being satisfied. A dependency is satisfied by the inclusion of the relevant component (or one that is hierarchical to it) within the statement of security requirements. The component used to satisfy the dependency should, if necessary, be modified by operations to ensure that it actually satisfies that dependency. A justification that a dependency is not met should address either: why the dependency is not necessary or useful, in which case no further information is required; or that the dependency has been addressed by the operational environment of the TOE, in which case the justification should describe how the security objectives for the operational environment address this dependency. The evaluator ensures that if a functional package defines a dependency on another functional package, then that functional package is included in the PP If a functional package identifies dependencies on its requirements that need to be satisfied by the underlying PP, the evaluator ensures that their analysis covers these dependencies as well. The evaluator shall check that the security requirements rationale traces each SFR back to the security objectives for the TOE. Optional requirements may require Threats/OSPs to be specified, and security objectives associated with these SPD elements are also covered by this work unit. The evaluator determines that each SFR is traced back to at least one security objective for the TOE. Failure to trace implies that either the security requirements rationale is incomplete, the security objectives for the TOE are incomplete, or the SFR has no useful purpose. The evaluator shall examine the security requirements rationale to determine that for each security objective for the TOE it justifies that the SFRs are suitable to meet that security objective for the TOE. If no SFRs trace back to the security objective for the TOE, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for a security objective for the TOE demonstrates that the SFRs are sufficient: if all SFRs that trace back to the objective are satisfied, the security objective for the TOE is achieved. If the SFRs that trace back to a security objective for the TOE have any uncompleted assignments, or uncompleted or restricted selections, the evaluator determines that for every conceivable completion or combination of completions of these operations, the security objective is still met. The evaluator also determines that each SFR that traces back to a security objective for the TOE is necessary: when the SFR is satisfied, it actually contributes to achieving the security objective. Note that the tracings from SFRs to security objectives for the TOE provided in the security requirements rationale may be a part of the justification, but do not constitute a justification by themselves. The evaluator shall check that the security requirements rationale explains why the SARs were chosen. The evaluator is reminded that any explanation is correct, as long as it is coherent and neither the SARs nor the explanation have obvious inconsistencies with the remainder of the PP. An example of an obvious inconsistency between the SARs and the remainder of the PP would be to have threat agents that are very capable, but an SAR that does not protect against these threat agents. The evaluator shall examine the statement of security requirements to determine that it is internally consistent. The evaluator determines that the combined set of all SFRs and SARs is internally consistent. With respect to optional requirements, the evaluator determines that: all optional requirements either trace to an SPD element that is itself not optional, or trace to an SPD element that is clearly associated with that optional SFR; all optional requirements are clearly identified as either: elective and therefore for inclusion purely at the discretion of the ST author (i.e. conformance to the PP does not depend on their inclusion in the ST); or conditional and therefore required if a conformant TOE implements the functionality covered by the requirement. all optional requirements do not conflict with non-optional requirements (a capability cannot be both required and optional; however, a base capability can be required with enhancements to that capability being specified as optional). The evaluator determines that on all occasions where different security requirements apply to the same types of developer evidence, events, operations, data, tests to be performed etc. or to "all objects", "all subjects" etc., that these requirements do not conflict. Some possible conflicts are: an extended SAR specifying that the design of a certain cryptographic algorithm is to be kept secret, and another extended SAR specifying an open source review; specifying that subject identity is to be logged, specifying who has access to these logs, and specifying that some actions of subjects should be unobservable to other subjects. If the subject that should not be able to see an activity may access logs of this activity, these SFRs conflict; specifying deletion of information no longer needed, and specifying that a TOE may return to a previous state. If the information that is needed for the rollback to the previous state has been deleted, these requirements conflict; multiple iterations of , especially where some iterations cover the same subjects, objects, or operations. If one access control SFR allows a subject to perform an operation on an object, while another access control SFR does not allow this, these requirements conflict. This part of the PP defines the security problem to be addressed by the TOE and the operational environment of the TOE. Evaluation of the security problem definition is required to demonstrate that the security problem intended to be addressed by the TOE and its operational environment, is clearly defined. The objective of this sub-activity is to determine that the security problem intended to be addressed by the TOE and its operational environment is clearly defined. the PP. The developer shall provide a security problem definition. The security problem definition shall describe the threats. All threats shall be described in terms of a threat agent, an asset, and an adverse action. The security problem definition shall describe the organizational security policies (OSPs). The security problem definition shall describe the assumptions about the operational environment of the TOE. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the security problem definition describes the threats. If all security objectives are derived from assumptions and/or OSPs only, the statement of threats need not be present in the PP. In this case, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the security problem definition describes the threats that must be countered by the TOE and/or its operational environment. Note that if optional requirements are defined by the PP, there may be associated threats that are covered by this work unit. The evaluator shall examine the security problem definition to determine that all threats are described in terms of a threat agent, an asset, and an adverse action. If all security objectives are derived from assumptions and OSPs only, the statement of threats need not be present in the PP. In this case, this work unit is not applicable and therefore considered to be satisfied. Threat agents may be further described by aspects such as expertise, resource, opportunity, and motivation. The evaluator shall examine that the security problem definition describes the OSPs. If all security objectives are derived from assumptions and/or threats only, OSPs need not be present in the PP. In this case, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that OSP statements are made in terms of rules or guidelines that must be followed by the TOE and/or its operational environment. The evaluator determines that each OSP is explained and/or interpreted in sufficient detail to make it clearly understandable; a clear presentation of policy statements is necessary to permit tracing security objectives to them. Note that if optional requirements are defined by the PP, there may be associated OSPs that are covered by this work unit. The evaluator shall examine the security problem definition to determine that it describes the assumptions about the operational environment of the TOE. If there are no assumptions, this work unit is not applicable and is therefore considered to be satisfied. The evaluator determines that each assumption about the operational environment of the TOE is explained in sufficient detail to enable consumers to determine that their operational environment matches the assumption. If the assumptions are not clearly understood, the end result may be that the TOE is used in an operational environment in which it will not function in a secure manner. Evaluating an ST is required to demonstrate that the ST is sound and internally consistent, and, if the ST is based on a PP-Configuration, or one or more PPs or packages, that the ST is a correct instantiation of the PP-Configuration, PPs, and packages. These properties are necessary for the ST to be suitable for use as the basis for a TOE evaluation. Clause 9 should be used in conjunction with CC Part 1, Annexes B, C and D as these annexes clarify the concepts here and provide many examples. This clause describes the evaluation of an ST. The ST evaluation should be started prior to any TOE evaluation sub-activities since the ST provides the basis and context to perform these sub-activities. The evaluation methodology in this subclause is based on the requirements on the ST as specified in CC Part 3 class . This clause should be used in conjunction with CC Part 1, Annexes A, B and C, as these Annexes clarify the concepts here and provide many examples. While evaluating an ST that is based on one or more certified PPs, it may be possible to re-use the fact that these PPs were certified. The potential for re-use of the result of a certified PP is greater if the ST does not add threats, OSPs, assumptions, security objectives and/or security requirements to those of the PP. If the ST contains much more than the certified PP, re-use may not be useful at all. The evaluator is allowed to re-use the PP evaluation results by doing certain analyses only partially or not at all if these analyses or parts thereof were already done as part of the PP evaluation. While doing this, the evaluator should assume that the analyses in the PP were performed correctly. An example would be where the PP contains a set of security requirements, and these were determined to be internally consistent during the PP evaluation. If the ST uses the exact same requirements, the consistency analysis does not have to be repeated during the ST evaluation. If the ST adds one or more requirements, or performs operations on these requirements, the analysis will have to be repeated. However, it may be possible to save work in this consistency analysis by using the fact that the original requirements are internally consistent. If the original requirements are internally consistent, the evaluator only has to determine that: the set of all new and/or changed requirements is internally consistent, and; the set of all new and/or changed requirements is consistent with the original requirements. The evaluator notes in the ETR each case where analyses are not done or only partially done for this reason. The same re-use discussion applies to an ST claiming conformance to a certified PP-Configuration. The composite-specific work units defined in are intended to be integrated as refinements to the evaluation activities of the class listed in the following table. The other activities of the class do not require composite-specific work units. Assurance family Evaluation activity Evaluation work unit Composite-specific work unit The objective of this family is to determine the validity of the conformance claim. In addition, this family specifies how STs are to claim conformance with the PP or PP-Configuration. The objective of this sub-activity is to determine the validity of various conformance claims. These describe how the ST and the TOE conform to CC and how the ST conforms to a PP-Configuration, PPs and packages. the ST; the PP(s) or PP-Configuration that the ST claims conformance to; the package(s) that the ST claims conformance to. The developer shall provide a conformance claim. The developer shall provide a conformance claim rationale. The conformance claim shall identify the edition of the CC to which the ST and the TOE claim conformance. The conformance claim shall describe the conformance of the ST to CC Part 2 as either "CC Part 2 conformant" or "CC Part 2 extended". The conformance claim shall describe the conformance of the ST as either "CC Part 3 conformant" or "CC Part 3 extended". The conformance claim shall be consistent with the extended components definition. The conformance claim shall identify a PP-Configuration, or all PPs and security requirement packages to which the ST claims conformance. The conformance claim shall describe any conformance of the ST to a package as either package-conformant or package-augmented. The conformance claim shall describe any conformance of the ST to a PP as PP-Conformant. The conformance claim rationale shall demonstrate that the TOE type is consistent with the TOE type in the PP-Configuration or PPs for which conformance is being claimed. The conformance claim rationale shall demonstrate that the statement of the security problem definition is consistent with the statement of the security problem definition in the PP-Configuration, PPs and any functional packages for which conformance is being claimed. The conformance claim rationale shall demonstrate that the statement of security objectives is consistent with the statement of security objectives in the PP-Configuration, PPs, and any functional package for which conformance is being claimed. The conformance claim rationale shall demonstrate that the statement of security requirements is consistent with the statement of security requirements in the PP-Configuration, PPs, and any functional packages for which conformance is being claimed. The conformance claim for PP(s) or a PP-Configuration shall be exact, strict, or demonstrable or a list of conformance types. If the conformance claim identifies a set of Evaluation methods and Evaluation activities derived from CEM work units that shall be used to evaluate the TOE then this set shall include all those that are included in any package, PP, or PP-Module in a PP-Configuration to which the ST claims conformance, and no others. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the conformance claim identifies the edition of the CC to which the ST and the TOE claim conformance. The evaluator determines that the conformance claim identifies the edition of the CC that was used to develop this ST. This should include the version number of the CC and, unless the English version of the CC was used, the language of the edition of the CC that was used. For a composed TOE, the evaluator will consider any differences between the edition of the CC claimed for a component and the edition of the CC claimed for the composed TOE. If the editions differ the evaluator will assess whether the differences between them will lead to conflicting claims. For instances where conformance claims for the base TOE and dependent TOE are for different major releases of the CC (e.g. one component TOE conformance claim is CC v2.x and the other component TOE conformance claim is CC v3.x), the conformance claim for the composed TOE will be the earlier release of the CC, as CC is developed with an aim to provide backwards compatibility (although this may not be achieved in the strictest sense, it is understood to be achieved in principle). The evaluator shall check that the conformance claim states a claim of either "CC Part 2 conformant" or "CC Part 2 extended" for the ST. For a composed TOE, the evaluator will consider whether this claim is consistent not only with CC Part 2, but also with the claims of conformance to CC Part 2 by each of the component TOEs, i.e. if one or more component TOEs claims to be CC Part 2 extended, then the composed TOE should also claim to be CC Part 2 extended. The conformance claim for the composed TOE may be CC Part 2 extended, even though the component TOEs are CC Part 2 conformant, in the event that additional SFRs are claimed for the base TOE (see composed TOE guidance for ) The evaluator shall check that the conformance claim states a claim of either "CC Part 3 conformant" or "CC Part 3 extended" for the ST. The evaluator shall examine the conformance claim for CC Part 2 to determine that it is consistent with the extended components definition. If the conformance claim contains CC Part 2 conformant, the evaluator determines that the extended components definition does not define functional components. If the conformance claim contains CC Part 2 extended, the evaluator determines that the extended components definition defines at least one extended functional component. The evaluator shall examine the conformance claim for CC Part 3 to determine that it is consistent with the extended components definition. If the conformance claim contains CC Part 3 conformant, the evaluator determines that the extended components definition does not define assurance components. If the conformance claim contains CC Part 3 extended, the evaluator determines that the extended components definition defines at least one extended assurance component. The evaluator shall check that the conformance claim contains a PP claim that identifies all PPs for which the ST claims conformance. If the ST does not claim conformance to a PP, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that any referenced PPs are unambiguously identified (e.g. by title and version number, or by the identification included in the introduction of that PP). For conformance claims to PPs containing functional packages, the evaluator shall check that: for each PP to which the ST claims conformance, the ST does not include conformance claims to any packages to which the PP also claims conformance, unless the ST augments the requirements in that package. For example, if a PP claims <package foo>-conformant to package foo, and an ST claims conformance to the PP, then the ST does not also claim "<package foo>-conformant" in its conformance claim. However, if it augments package foo with a requirement, then it would claim "<package foo>-augmented" in its conformance claim. The evaluator determines that if the ST does claim conformance to a package that is claimed by one of the PPs to which the ST is claiming conformance, the PP has a conformance type of strict or demonstrable. An ST is not allowed to claim conformance on any functional packages when claiming exact conformance to one or more PPs. The evaluator is reminded that claims of partial conformance to a PP are not permitted. Therefore, conformance to a PP requiring a composite solution may be claimed in an ST for a composed TOE. Conformance to such a PP would not have been possible during the evaluation of the component TOEs, as these components would not have satisfied the composed solution. This is only possible in the instances where the "composite" PP permits use of the composition evaluation approach (use of components). For PPs containing functional packages, partial conformance means that not all packages have been included in the ST, a functional package has only been partially included into the ST, or a dependency requirement within or between functional packages has not been met. Note that exclusion of optional requirements that the ST either chooses not to, or is not required to, claim does not result in "partial conformance" to the PP, and is therefore allowed. The evaluator shall check that, for each PP to which the ST claims conformance, the allowed-with statement included in the conformance statement of that PP lists all other PPs in the ST's conformance claim. If the ST is not claiming exact conformance to more than one PP, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the allowed-with statement included in the conformance statement of each PP to which conformance is being claimed lists each of the other PPs identified in the conformance claim section of the ST as being "allowed to be claimed with" that PP. Note that this is only applicable in cases where that PP requires exact conformance and the ST claims exact conformance. Consider the case where an ST is being evaluated and claims conformance to PPs B and C; this is depicted in . The ST is claiming exact conformance, so all PPs require exact conformance in their conformance statements. Under this work unit, the evaluator determines that PP B lists (in its allowed-with statement) "PP C" as being a PP that can be claimed (by an ST) with PP B. Likewise, the evaluator determines that PP C lists (in its allowed-with statement) "PP B" as being a PP that can be claimed (by an ST) with PP C.

The evaluator shall check that the conformance claim contains a PP-Configuration claim that identifies the PP-Configuration to which the ST claims conformance. If the ST does not claim conformance to a PP-Configuration, this work unit is not applicable and therefore considered to be satisfied. The evaluator shall check that the ST claims conformance to exactly one PP-Configuration. An ST cannot simultaneously claim conformance to a PP-Configuration and one or more PP(s) that is/are not part of that PP-Configuration. The evaluator determines that the referenced PP-Configuration is unambiguously identified (e.g. by title and version number, or by the identification included in the introduction of that PP-Configuration). An ST is not allowed to claim conformance to a PP-Configuration and a functional package, so the evaluator should confirm that no functional package conformance claims are included in the ST conformance claim section if it claims conformance to a PP-Configuration. If an ST claims conformance to a PP-Configuration that claims, or whose components claim, conformance to a security assurance package, the evaluator ensures that the ST does not include conformance claims to those packages unless the ST augments those packages. The evaluator shall check, for each identified functional package, that the package definition is complete. If the ST does not claim conformance to a functional package, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the package definition is conformant to the requirements from CC Part 1, Clause 9 "Packages" by checking that the functional package includes: A functional package identification, giving a unique name, version, date, sponsor, and the CC edition; A functional package overview, giving a narrative description of the security functionality; A component rationale that provides the rationale for selecting the functional components/requirements included in the package; If the package defines an SPD then: the package includes a security requirements rationale; the package includes a security objectives rationale if security objectives for the environment are defined; If the package is a direct rationale package, there are no security objectives for the TOE defined and the security requirements rationale maps directly to the SPD; If the package is not a direct rationale package, then security objectives for the TOE are defined, the security objectives rationale covers the objectives with respect to the SPD, and the security requirements rationale maps the requirements to the security objectives. one or more security components or requirements (the functional package SFRs); If extended components have been specified then the functional package includes an extended components definition; The evaluator shall check, for each identified assurance package, that the package definition is complete. If the ST does not claim conformance to an assurance package, this work unit is not applicable and therefore considered to be satisfied. If the assurance package is a reference to one of the assurance packages contained in CC Part 5 then this work unit is also considered to be satisfied. The evaluator determines that the package definition is conformant to the requirements from CC Part 1, Clause 9 "Packages" by checking that the assurance package includes: An assurance package identification, giving a unique name, version, date, sponsor, and the CC edition; An assurance package overview, giving a narrative description of the security functionality; One or more security components or requirements (the assurance package SARs) drawn from CC Part 3, extended assurance components or some combination of both; An assurance package shall not include an SPD or security objectives; If extended components have been specified then the assurance package includes an extended components definition; A security requirements rationale that provides the rationale for selecting the assurance components/ requirements included in the package. The evaluator shall check that the conformance claim contains a package claim that identifies all packages to which the ST claims conformance. If the ST does not claim conformance to a package, this work unit is not applicable and therefore considered to be satisfied. Stipulations on packages to which the ST claims conformance that are also claimed conformance to by a PP to which the ST is claiming conformance to are addressed in other work units. The evaluator also determines that if the ST is claiming conformance to a PP-Configuration, then only assurance packages are claimed conformance to by the ST. Additionally, the evaluator determines that if the ST is claiming exact conformance to a PP or PP-Configuration, then no packages are claimed conformance to by the ST. The evaluator is reminded that claims of partial conformance to a package are not permitted. The evaluator shall check that, for each identified package, the conformance claim states a claim of either package-conformant or package-augmented. If the ST claims conformance to a PP/PP-Configuration and the PP/PP-Configuration component itself claims conformance to one or more functional packages then the ST shall not separately make a conformance claim to the same packages unless the conditions outlined in work unit (for PPs) or (for PP-Configuration components) are met. If the ST does not claim conformance to a package, this work unit is not applicable and therefore considered to be satisfied. If the package conformance claim contains package-conformant, the evaluator determines that: if the package is an assurance package, then the ST contains all SARs included in the package, but no additional SARs; if the package is a functional package, then all assumptions, threats, OSPs, security objectives and SFRs included in the package are identical to those included in the ST (after allowing any remaining iterations, refinements, assignments or selections from the package to be made in the ST). If the package conformance claim contains package-augmented, the evaluator determines that: if the package is an assurance package then the ST contains all SARs included in the package, and at least one additional SAR or at least one SAR that is hierarchical to a SAR in the package; if the package is a functional package, then the constituent parts (security problem definition, security objectives, SFRs) of that ST contain all constituent parts (security problem definition, security objectives, SFRs) of that specific package, but additionally contain at least one enhancement of the security functionality defined by that specific package (finally resulting in an additional SFR or one an SFR that is hierarchically higher than an SFR in the package). The evaluator determines that, if the ST claims exact conformance to a PP/PP-Configuration, no package conformance claims are present. The evaluator shall check that if the ST claims conformance to PPs, only PP-Conformant claims are present. For a Direct Rationale ST, the evaluator shall check that only conformance claims to Direct Rationale PPs are present. In this work unit, the term "PP" shall be understood to mean "PP or PP-Configuration component". The evaluator shall examine the conformance claim rationale to determine that the TOE type of the TOE is consistent with all TOE types of the PPs. If the ST does not claim conformance to a PP, this work unit is not applicable and therefore considered to be satisfied. The relation between the types may be simple: a firewall ST claiming conformance to a firewall PP, or more complex: a smart card ST claiming conformance to a number of PPs at the same time (a PP for the integrated circuit, a PP for the smart card OS, and two PPs for two applications on the smart card). For a composed TOE, the evaluator will determine whether the conformance claim rationale demonstrates that the TOE types of the component TOEs are consistent with the composed TOE type. This does not mean that both the component and the composed TOE types have to be the same, but rather that the component TOEs are suitable for integration to provide the composed TOE. It should be made clear in the composed TOE ST which SFRs are only included as a result of composition, and were not examined as SFRs in the base and dependent TOE (e.g. EALx) evaluation. The evaluator shall examine the conformance claim rationale to determine that it demonstrates that the statement of security problem definition is consistent with the statements of security problem definition stated in the PPs/PP-Configuration/functional packages to which conformance is being claimed. If the ST does not claim conformance with any PP/PP-Configuration/functional package, this work unit is not applicable and therefore considered to be satisfied. If the PP/PP-Configuration/functional package does not have a statement of security problem definition, this work unit is not applicable and therefore considered to be satisfied. If the PP/PP-Configuration contains functional packages, the evaluator determines that the security problem definition of the ST consists of all assumptions, threats and OSPs of all functional packages. If functional packages are claimed, the rules defined in the following paragraphs concerning exact, strict and demonstrable conformance also hold for the SPD descriptions taken from the functional packages. If exact conformance is required by the PPs/PP-Configuration to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines whether: the threats in the ST are identical (no fewer threats, no additional threats) to the threats in the PP/PP-Configuration to which conformance is being claimed. If exact conformance is being claimed to more than one PP, then the set of threats in the ST must be identical to the union of the threats in all PPs to which conformance is being claimed. the OSPs in the ST are identical (no fewer OSPs, no additional OSPs) to the OSPs in the PP/PP-Configuration to which conformance is being claimed. If exact conformance is being claimed to more than one PP, then the set of OSPs in the ST must be identical to the union of the OSPs in all PPs to which conformance is being claimed. the assumptions in the ST are identical (no fewer assumptions, no additional assumptions) to the assumptions in the PP/PP-Configuration to which conformance is being claimed. If exact conformance is being claimed to more than one PP, then the set of assumptions in the ST must be identical to the union of the assumptions in all PPs to which conformance is being claimed, with the following possible exception; An assumption (or part of an assumption) from a PP can be omitted, if all security objectives for the operational environment addressing this assumption (or part of an assumption) are replaced by security objectives for the TOE that are identical to (taken from) another of the PPs to which the ST is claiming conformance. When examining an ST in these circumstances (assumptions from one PP are replaced by security objectives on the TOE from one of the other PPs) the evaluator shall carefully determine that the condition given above is fulfilled. The following discussion gives an example: An ST is claiming exact conformance to two PPs. As determined in previous work units, both PPs require exact conformance in their conformance statements, and both PPs list the other as being "allowed with" the PP in a conformance claim by an ST. One PP to which the ST claims conformance contains an assumption stating that the operational environment prevents unauthorized modification or interception of data sent to an external interface of the TOE. This may be the case if the TOE accepts data in clear text and without integrity protection at this interface and is assumed to be located in a secure operational environment, which will prevent attackers from accessing this data. The assumption will then be mapped in the PP to some objective for the operational environment stating that the data interchanged at this interface are protected by adequate measures in the operational environment. Suppose there is another PP that specifies that conformant TOEs must protect data sent over the TOEs external interfaces, and has appropriate threats and security objectives addressing this threat. The ST author can then replace the assumption and security objective for the environment related to the protection of data over the external interfaces of the TOE from one PP with the security objective stating that the TOE itself protects these data, for example by providing a secure channel for encryption and integrity protection of all data transferred via this interface from the other PP; the corresponding objective and assumption for the operational environment from the other PP is thus omitted from the ST. This is also called re-assigning of the objective, since the objective is re-assigned from the operational environment to the TOE. Note, that this TOE is still secure in an operational environment fulfilling the omitted assumption and therefore still fulfils the PP. Further, the set of threats and objectives in the ST is still no broader than the union of threats and objectives in the PPs to which it is claiming exact conformance. If strict conformance is required by the PPs/PP-Configuration to which conformance is being claimed no conformance claim rationale is required. Instead, the evaluator determines whether: the threats in the ST are a superset of or identical to the threats in the PPs/PP-Configuration to which conformance is being claimed; the OSPs in the ST are a superset of or identical to the OSPs in the PPs/PP-Configuration to which conformance is being claimed; the assumptions in the ST are identical to the assumptions in the PPs/PP-Configuration to which conformance is being claimed, with two possible exceptions described in the following two bullet points: an assumption (or part of an assumption) from a PP/PP-Configuration can be omitted, if all security objectives for the operational environment addressing this assumption (or part of an assumption) are replaced by security objectives for the TOE; an assumption can be added to the assumptions defined in a PP/PP-Configuration, if a rationale is given, why the new assumption neither mitigates a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the PP/PP-Configuration, nor fulfils an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the PP/PP-Configuration. When examining an ST claiming a PP/PP-Configuration, which omits assumptions from the PP/PP-Configuration or adds new assumptions, the evaluator shall carefully determine, if the conditions given above are fulfilled. The following discussion gives some motivation and examples for these cases: example for omitting an assumption: A PP may contain an assumption stating that the operational environment prevents unauthorized modification or interception of data sent to an external interface of the TOE. This may be the case if the TOE accepts data in clear text and without integrity protection at this interface and is assumed to be located in a secure operational environment, which will prevent attackers from accessing these data. The assumption will then be mapped in the PP to some objective for the operational environment stating that the data interchanged at this interface are protected by adequate measures in the operational environment. If an ST claiming this PP defines a more secure TOE, which has an additional security objective stating that the TOE itself protects these data, for example by providing a secure channel for encryption and integrity protection of all data transferred via this interface, the corresponding objective and assumption for the operational environment can be omitted from the ST. This is also called re-assigning of the objective, since the objective is re-assigned from the operational environment to the TOE. Note, that this TOE is still secure in an operational environment fulfilling the omitted assumption and therefore still fulfils the PP; example for adding an assumption: In this example, the PP is designed to specify requirements for a TOE of type "Firewall" and an ST author wishes to claim this PP for a TOE, which implements a firewall, but additionally provides the functionality of a virtual private network (VPN) component. For the VPN functionality, the TOE needs cryptographic keys and these keys may also have to be handled securely by the operational environment (e. g. if symmetric keys are used to secure the network connection and therefore need to be provided in some secure way to other components in the network). In this case, it is acceptable to add an assumption that the cryptographic keys used by the VPN are handled securely by the operational environment. This assumption does not address threats or OSPs of the PP and therefore fulfils the conditions stated above; counter example for adding an assumption: In a variant of the first example a PP may already contain an objective for the TOE to provide a secure channel for one of its interfaces, and this objective is mapped to a threat of unauthorized modification or reading of the data on this interface. In this case, it is clearly not allowed for an ST claiming this PP to add an assumption for the operational environment, which assumes that the operational environment protects data on this interface against modification or unauthorized reading of the data. This assumption would reduce a threat, which is meant to be addressed by the TOE. Therefore, a TOE fulfilling an ST with this added assumption would not automatically fulfil the PP anymore and this addition is therefore not allowed; second counter example for adding an assumption: In the example above of a TOE implementing a firewall it would not be admissible to add a general assumption that the TOE is only connected to trusted devices, because this would obviously remove essential threats relevant for a firewall (namely that there is untrusted IP traffic, which needs to be filtered). Therefore, this addition would not be allowed. If demonstrable conformance is required by the PP/PP-Configuration, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security problem definition of the ST is equivalent or more restrictive than the statement of security problem definition in the PP/PP-Configuration to which conformance is being claimed. For this, the conformance claim rationale needs to demonstrate that the security problem definition in the ST is equivalent (or more restrictive) than the security problem definition in the PP/PP-Configuration. This means that: all TOEs that would meet the security problem definition in the ST also meet the security problem definition in the PP/PP-Configuration. This can also be shown indirectly by demonstrating that every event, which realises a threat defined in the PP or violates an OSP defined in the PP/PP-Configuration, would also realise a threat stated in the ST or violate an OSP defined in the ST. Note that fulfilling an OSP stated in the ST may avert a threat stated in the PP/PP-Configuration or that averting a threat stated in the ST may fulfil an OSP stated in the PP/PP-Configuration, so threats and OSPs can substitute each other; all operational environments that would meet the security problem definition in the PP/PP-Configuration would also meet the security problem definition in the ST (with one exception in the next bullet); besides a set of assumptions in the ST needed to demonstrate conformance to the SPD of the PP/PP-Configuration, an ST may specify further assumptions, but only if these additional assumptions are independent of and do not affect the security problem definition as defined in the PP/PP-Configuration. More detailed, there are no assumptions in the ST that exclude threats to the TOE that need to be countered by the TOE according to the PP. Similarly, there are no assumptions in the ST that realise aspects of an OSP stated in the PP/PP-Configuration, which are meant to be fulfilled by the TOE according to the PP/PP-Configuration. For a composed TOE, the evaluator will consider whether the security problem definition of the composed TOE is consistent with that specified in the STs for the component TOEs. This is determined in terms of demonstrable conformance. In particular, the evaluator examines the conformance claim rationale to determine that: threat statements and OSPs in the composed TOE ST do not contradict those from the component STs; any assumptions made in the component STs are upheld in the composed TOE ST. That is, either the assumption should also be present in the composed ST, or the assumption should be positively addressed in the composed ST. The assumption may be positively addressed through specification of requirements in the composed TOE to provide functionality fulfilling the concern captured in the assumption. The evaluator shall examine the conformance claim rationale to determine that the statement of security objectives is consistent, with the statement of security objectives in the PPs/PP-Configuration/functional packages to which conformance is being claimed. If the ST does not claim conformance to a PP/PP-Configuration/functional packages, this work unit is not applicable and therefore considered to be satisfied. If the PP/PP-Configuration to which conformance is being claimed contains functional packages, the evaluator determines that the security objectives of the ST consist of all security objectives of all functional packages. If functional packages are claimed the rules defined in the following paragraphs concerning exact, strict and demonstrable conformance also hold for the security objectives taken from these packages. If exact conformance is required by the PPs/PP-Configuration to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines whether: the ST contains all security objectives for the TOE of the PP/PP-Configuration to which conformance is being claimed. Note that in the exact conformance case, it is not allowed for the ST under evaluation to have additional security objectives for the TOE. If conformance is being claimed to more than one PP, the set of security objectives for the TOE must be identical to the union of the security objectives for the TOE in the PPs to which conformance is being claimed. It should be noted that in the case that optional requirements have associated SPD elements, exact conformance can still be claimed if objectives associated with the SPD elements are omitted when the associated optional SFRs are also omitted; the security objectives for the operational environment in the ST are identical to the security objectives for the operational environment in the PP/PP-Configuration to which conformance is being claimed. If conformance is being claimed to more than one PP, the set of security objectives for the operational environment must be identical to the union of the security objectives for the operational environment in the PPs to which conformance is being claimed with the possible exception as follows: a security objective for the operational environment (or part of such security objective) from one PP can be replaced by the same (part of the) security objective for the TOE from another PP. If strict conformance is required by the PPs/PP-Configuration to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines whether: the ST contains all security objectives for the TOE of the PP/PP-Configuration to which conformance is being claimed. Note that it is allowed for the ST under evaluation to have additional security objectives for the TOE; the security objectives for the operational environment in the ST are identical to the security objectives for the operational environment in the PP/PP-Configuration to which conformance is being claimed, with two possible exceptions described in the following two bullet points; a security objective for the operational environment (or part of such security objective) from the PP/PP-Configuration can be replaced by the same (part of the) security objective stated for the TOE; a security objective for the operational environment can be added to the objectives defined in the PP/PP-Configuration, if a justification is given, why the new objective neither mitigates a threat (or a part of a threat) meant to be addressed by security objectives for the TOE in the PP/PP-Configuration, nor fulfils an OSP (or part of an OSP) meant to be addressed by security objectives for the TOE in the PP/PP-Configuration. When examining an ST claiming a PP/PP-Configuration, which omits security objectives for the operational environment from the PP/PP-Configuration or adds new security objectives for the operational environment, the evaluator shall carefully determine, if the conditions given above are fulfilled. The examples given for the case of assumptions in the preceding work unit are also valid here. If demonstrable conformance is required by the PPs/PP-Configuration to which conformance is being claimed, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security objectives of the ST is equivalent or more restrictive than the statement of security objectives in the PP/PP-Configuration to which conformance is being claimed. For this the conformance claim rationale needs to demonstrate that the security objectives in the ST are equivalent (or more restrictive) than the security objectives in the PP/PP-Configuration. This means that: all TOEs that would meet the security objectives for the TOE in the ST also meet the security objectives for the TOE in the PP/PP-Configuration; all operational environments that would meet the security objectives for the operational environment in the PP/PP-Configuration would also meet the security objectives for the operational environment in the ST (with one exception in the next bullet); besides a set of security objectives for the operational environment in the ST, which are used to demonstrate conformance to the set of security objectives defined in the PP/PP-Configuration, an ST may specify further security objectives for the operational environment, but only if these security objectives neither affect the original set of security objectives for the TOE nor the security objectives for the operational environment as defined in the PP/PP-Configuration to which conformance is claimed. For a composed TOE, the evaluator will consider whether the security objectives of the composed TOE are consistent with that specified in the STs for the component TOEs. This is determined in terms of demonstrable conformance. In particular, the evaluator examines the conformance claim rationale to determine that: the statement of security objectives in the dependent TOE ST relevant to any IT in the operational environment are consistent with the statement of security objectives for the TOE in the base TOE ST. It is not expected that the statement of security objectives for the environment within in the dependent TOE ST will cover all aspects of the statement of security objectives for the TOE in the base TOE ST; the statement of security objectives in the composed ST is consistent with the statements of security objectives in the STs for the component TOEs. The evaluator shall examine the ST to determine that it is consistent with all security requirements in the PPs/PP-Configuration/functional packages for which conformance is being claimed. If the ST does not claim conformance to a PP/PP-Configuration/functional package, this work unit is not applicable and therefore considered to be satisfied. If the PPs/PP-Configuration to which conformance is being claimed contains functional packages, the evaluator determines that the SFRs of the ST consist of all SFRs (or hierarchical SFRs) of all functional packages. If functional packages are used, the rules defined in the following paragraphs concerning exact, strict and demonstrable conformance also hold for the SFRs taken from these packages. If exact conformance is required by the PP/PP-Configuration to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines that the statement of security requirements in the PP to which conformance is being claimed is exactly reproduced in the ST, with the following allowances: an SFR from the PP/PP-Configuration may be iterated or refined in the ST; all SFRs that are defined in the PP/PP-Configuration to which conformance is being claimed as selection-based upon a particular selection shall be included if and only if that selection on which inclusion is based is present in the ST. If a selection is not chosen by the ST author, then the selection-based SFRs associated with that selection are not included in the ST; there are no additional security requirements (SFRs or SARs) that are included in the ST that are not also present in the PP/PP-Configuration; in the case where exact conformance is being claimed to multiple PPs, the evaluator determines there are no additional security requirements included in the ST that are not in at least one of the PPs, and that all of the requirements (with the allowances described above) in all of the PPs have been included in the ST; In the case where multiple PPs, or multiple components of a PP-Configuration, to which an ST claims conformance have requirements that need to be combined or de-conflicted, such de-confliction guidance will be provided in those PPs/components as a result of the allow-with analysis performed by the PP/component authors. It is acceptable to include such modified requirements as explicitly allowed in the ST. The ST includes any optional requirements (and associated SPD elements) from the PP/PP-Configuration as follows: elective requirements defined in the PP/PP-Configuration that the ST wishes to claim; and/or conditional requirements defined in the PP/PP-Configuration that the ST is required to claim (as stipulated in the PP/PP-Configuration) due to the TOE implementation. If strict conformance is required by the PP to which conformance is being claimed, no conformance claim rationale is required. Instead, the evaluator determines whether the statement of security requirements in the ST is a superset of, or identical to, the statement of security requirements in the PP to which conformance is being claimed (for strict conformance). If demonstrable conformance is required by the PPs/PP-Configuration to which conformance is being claimed, the evaluator examines the conformance claim rationale to determine that it demonstrates that the statement of security requirements of the ST is equivalent or more restrictive than the statement of security requirements in the PPs/PP-Configuration to which conformance is being claimed. For: SFRs: the conformance rationale in the ST shall demonstrate that the overall set of requirements defined by the SFRs in the ST is equivalent (or more restrictive) than the overall set of requirements defined by the SFRs in the PPs/PP-Configuration. This means that all TOEs that would meet the requirements defined by the set of all SFRs in the ST would also meet the requirements defined by the set of all SFRs in the PPs/PP-Configuration; SARs: the ST shall contain all SARs in the PPs/PP-Configuration, but may claim additional SARs or replace SARs by hierarchically stronger SARs. The completion of operations in the ST must be consistent with that in the PPs/PP-Configuration; either the same completion will be used in the ST as that in the PPs/PP-Configuration or a completion that makes the SAR more restrictive (the rules of refinement apply). For a composed TOE, the evaluator will consider whether the security requirements of the composed TOE are consistent with that specified in the STs for the component TOEs. This is determined in terms of demonstrable conformance. In particular, the evaluator examines the conformance rationale to determine that: the statement of security requirements in the dependent TOE ST relevant to any IT in the operational environment is consistent with the statement of security requirements for the TOE in the base TOE ST. It is not expected that the statement of security requirements for the environment within in the dependent TOE ST will cover all aspects of the statement of security requirements for the TOE in the base TOE ST, as some SFRs may need to be added to the statement of security requirements in the composed TOE ST. However, the statement of security requirements in the base should support the operation of the dependent component; the statement of security objectives in the dependent TOE ST relevant to any IT in the operational environment is consistent with the statement of security requirements for the TOE in the base TOE ST. It is not expected that the statement of security objectives for the environment within in the dependent TOE ST will cover all aspects of the statement of security requirements for the TOE in the base TOE ST; the statement of security requirements in the composed is consistent with the statements of security requirements in the STs for the component TOEs. The evaluator shall check that the conformance claim for PPs or a PP-Configuration is one of exact, strict, or demonstrable or a list of conformance types. If the ST claims exact conformance to one PP, then it must claim exact conformance to all PPs, and all PPs must require exact conformance. The evaluator shall check the conformance claim of the ST to determine that: if any derived Evaluation Methods and Evaluation Activities are required by other items to which the ST claims conformance then these are all identified in the ST, otherwise, no Evaluation Methods and Evaluation Activities are identified; the list of derived Evaluation Methods and Evaluation Activities is sufficiently structured and detailed to unambiguously identify and locate every member of the list; if there is any overlap in the scope of the identified Evaluation Methods and Evaluation Activities (i.e. where an overlay exists as described in CC Part 4) then the rationale for the resulting set of Evaluation Methods and Evaluation Activities is applicable to the TOE as described by the ST. The intention of this work unit is to ensure that the correct Evaluation Methods and Evaluation Activities can be used when evaluating the TOE described by the ST. This means that identification in the ST need not list individual Evaluation Activities where these are unambiguously included in a listed Evaluation Method. Similarly, where multiple Evaluation Methods or Evaluation Activities are included in a single document then it is sufficient to reference the document, provided this does lead to unambiguous identification of the Evaluation Methods and Evaluation Activities that apply to the ST. If a document lists multiple different Evaluation Methods applicable to different use cases then it would not be sufficient to reference the document: the relevant use cases would also have to be identified. The aim of this family is to determine whether the ST of the composite product Denoted by composite product Security Target or composite-ST in the following. does not contradict the ST of the related base component Denoted by base component Security Target or base-ST in the following.Generally, a Security Target expresses a security policy for the TOE defined.. This family contains only one component. A ST for the composite product shall be written and evaluated. The composite product evaluator shall examine that the ST of the composite product does not contradict the ST of the related base component. In particular, it means that the composite product evaluator shall examine the composite product ST and the base component ST for any conflicting assumptions, compatibility of security objectives, security requirements and security functionality needed by the dependent component. The composite product evaluation sponsor shall ensure that the ST of the base component is available for the dependent component developer, for the composite product evaluator and for the composite product evaluation authority. The information available in the public version of the base component ST may not be sufficient. These application notes aid the developer to create as well as the evaluator to analyse a composite product ST and describe a general methodology for it. In order to create a composite product ST, the developer should perform the following steps: Step 1: The developer formulates a preliminary ST for the composite product (the composite-ST) using the standard code of practice. The composite-ST can be formulated independently of the ST of the composite product's related base component (the base-ST), at least as long as there are no formal PP conformance claims. Step 2: The developer determines the overlap between the base-ST and the composite-ST through analysing and comparing their respective TOE Security Functionality (TSF) Because the TSF enforce the Security Target (together with the organisational measures enforcing the security objectives for the operational environment of the TOE).The comparison shall be performed on the abstraction level of SFRs. If the developer defined security functionality groups (TSF-groups) in the TSS part of his Security Target, the evaluator should also consider them in order to get a better understanding for the context of the security services offered by the TOE.. Step 3: The developer determines under which conditions he can trust in and rely on the base component-TSF being used by the composite-ST without a new examination. Having undertaken these steps the developer completes the preliminary ST for the composite product. It is not mandatory that the composite product and its related base component are being evaluated according to the same edition of the CC. It is due to the fact that the dependent component of the composite product can rely on some security services of the base component, if (i) the assurance level of the base component covers the intended assurance level of the composite product and (ii) the base component evaluation is valid (i.e. accepted by the base component evaluation authority) and up-to-date. Equivalence of single assurance components (and, hence, of assurance levels) belonging to different CC series editions shall be established / acknowledged by the composite product evaluation authority. If conformance to a PP is claimed, e.g. a composite product ST claims conformance to a PP (that possibly claims conformance to a further PP), the consistency check can be reduced to the elements of the ST having not already been covered by these PPs. However, in general the fact of compliance to a PP is not sufficient to avoid inconsistencies. Assume the following situation, where → stands for "complies with": composite-ST → PP 1 → PP 2 ← base-ST PP 1 may require any kind of conformance e.g. "strict", "exact" or "demonstrable" according to the CC series., but this does not affect the "additional elements" that the base-ST may introduce beyond PP 2. In conclusion, these additions are not necessarily consistent with the composite-ST's additions chosen beyond PP 1. There is no scenario that ensures their consistency "by construction". Note that consistency may be no direct matching: Objectives for the base component's environment may become objectives for the composite TOE. The aim of this activity is to determine whether the Security Target of the composite product Denoted by composite product Security Target or composite-ST in the in the composite specific work units. does not contradict the Security Target of the related base component Denoted by base component Security Target or base-ST in the in the composite specific work units.Generally, a Security Target expresses a security policy for the TOE defined.. A Security Target for the composite product shall be written and evaluated. The composite product evaluator shall examine that the Security Target of the composite product does not contradict the Security Target of the related base component. In particular, this means that the composite product evaluator shall examine the composite product Security Target and the base component Security Target for any conflicting assumptions, compatibility of security objectives, security requirements and security functionality needed by the dependent component. The composite product evaluation sponsor shall ensure that the Security Target of the base component is available for the dependent component developer, for the composite product evaluator and for the composite product evaluation authority. The information available in the public version of the base component Security Target may not be sufficient. These application notes aid the developer to create as well as the evaluator to analyse a composite product Security Target and describe a general methodology for it. For detailed information / guidance please refer to the single work units below. In order to create a composite product Security Target the developer should perform the following steps: Step 1: The developer formulates a preliminary Security Target for the composite product (the composite-ST) using the standard code of practice. The composite-ST can be formulated independently of the Security Target of the composite product's related base component (the base-ST) – at least as long as there are no formal PP conformance claims. Step 2: The developer determines the overlap between the base-ST and the composite-ST by analysing and comparing their respective TOE Security Functionality (TSF) Because the TSF enforce the Security Target (together with the organisational measures enforcing the security objectives for the operational environment of the TOE).The comparison shall be performed on the abstraction level of SFRs. If the developer defined security functionality groups (TSF-groups) in the TSS part of his Security Target, the evaluator should also consider them in order to get a better understanding for the context of the security services offered by the TOE.. Step 3: The developer determines under which conditions they can trust in and rely on the base component-TSF being used by the composite-ST without a new examination. Having undertaken these steps the developer completes the preliminary Security Target for the composite product. It is not mandatory that the composite product and its related base component are being evaluated according to the same edition of the CC (all parts). It is due to the fact that the dependent component of the composite product can rely on some security services of the base component, if (i) the assurance level of the base component covers the intended assurance level of the composite product and (ii) the base component evaluation is valid (i.e. accepted by the base component evaluation authority) and up-to-date. Equivalence of single assurance components (and, hence, of assurance levels) belonging to different CC editions shall be established / acknowledged by the composite product evaluation authority. If conformance to a PP is claimed, e.g. a composite product Security Target claims conformance to a PP (that possibly claims conformance to a further PP), the consistency check can be reduced to the elements of the Security Target having not already been covered by these PPs. However, in general the fact of compliance to a PP is not sufficient to avoid inconsistencies. Assume the following situation, where → stands for "complies with": composite-ST → PP 1 → PP 2 ← base-ST PP 1 may require any kind of conformance, e.g. "strict", "exact" or "demonstrable" according to CC., but this does not affect the "additional elements" that the base-ST may introduce beyond PP 2. In conclusion, these additions are not necessarily consistent with the composite-ST's additions chosen beyond PP 1: There is no scenario that ensures their consistency "by construction". Note that consistency may be no direct matching: Objectives for the base component's environment may become objectives for the composite TOE. The developer shall provide a statement of compatibility between the composite product Security Target and the base component Security Target. This statement may be provided within the composite product Security Target. The statement of compatibility shall describe the separation of the base component-TSF into relevant base component-TSF being used by the composite product Security Target and others. The statement of compatibility between the composite product Security Target and the base component Security Target shall show (e.g. in form of a mapping) that the Security Targets of the composite product and of the related base component match, i.e. that there is no conflict between security environments, security objectives, and security requirements of the composite product Security Target and the base component Security Target. It may be provided by indicating the concerned elements directly in the composite product Security Target followed by explanatory text, if necessary. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of compatibility describes the separation of the base component-TSF into relevant base component-TSF being used by the composite product Security Target and others. Please note that TSF means "TOE Security Functionality", whereby the TSF content is represented by SFRs. The respective TOE summary specification (TSS) shall provide, for each SFR, a description on how each SFR is met. The evaluator shall use this description in order to understand the contextual frame of the SFRs. If the developer defined security functionality groups (TSF-groups) in the TSS part of his Security Target as such contextual frame of the SFRs, the evaluator should also consider them in order to get a better understanding for the context of the security services offered by the TOE. This work unit relates to Step 2 of the Application Notes above. In order to determine the intersection area the evaluator considers the list of the base component-SFRs as given in the base component Security Target as single properties of the base component's security services. These base component-SFRs shall be separated in three groups: IP_SFR: Irrelevant base component-SFRs not being used by the composite-ST; RP_SFR-SERV: Relevant base component-SFRs being used by the composite-ST to implement a security service with associated TSFI; RP_SFR-MECH: Relevant base component-SFRs being used by the composite-ST because of their security properties providing protection against attacks to the TOE as a whole and being addressed in . These required security properties are a result of the security mechanisms and services that are implemented in the base component. To give an example, assume that there are the following base component-SFRs: Cryptographic operations /RSA, /AES, /EC as well as tamper-resistance and limited capabilities and availability and . The second and third group RP_SFR-SERV and RP_SFR-MECH exactly represent the intersection area in question. For example, IP_SFR = {/AES}, RP_SFR-SERV = {/RSA, /EC} and RP_SFR-MECH = {, , }, i.e. AES is not used by the composite TOE, but all other base component-SFRs are used. However, the RP_SFR-MECH cannot be directly connected to SFRs in the composite-ST. The size of the overlapping area (i.e. the content of the group RP_SFR-SERV and RP_SFR-MECH) results from the concrete properties of the base-ST and the composite-ST. If the composite-ST does not use any property of the base-ST and, hence, the intersection area is an empty set (i.e. RP_SFR-MECH ∪ RP_SFR-SERV = {∅}), no further composite evaluation activities are necessary at all: In such a case there is a technical, but not a security composition of the base component and the dependent component. The result of this work unit shall be integrated to the result of / (or the equivalent higher components if a higher assurance level is selected) and / . The evaluator shall examine the statement of compatibility to determine that the base component-TSF being used by the composite product Security Target are complete and consistent for the current composite product. In order to determine the completeness of the list of the base component-TSF being used by the composite-ST, the evaluator shall verify that: {base component-SFRs} = IP_SFR ∪ RP_SFR-SERV ∪ RP_SFR-MECH; Elements that belong to RP_SFR-SERV and RP_SFR-MECH are taken into account during the evaluation of the composite TOE. The IP-SFR are obviously part of the base component but they are not considered during the evaluation of the composite TOE. In order to determine the consistency of the list of the base component-TSF being used by the composite-ST, the evaluator shall verify that there are no ambiguities and contradictory statements. The result of this work unit shall be integrated to the result of / (or the equivalent higher components if a higher assurance level is selected) and / . The evaluator shall check that the security assurance requirements of the composite evaluation represent a subset of the security assurance requirements of the base component and its evaluation. This work unit relates to Step 2 of the Application Notes above. In order to ensure a sufficient degree of trustworthiness of the base component-TSF the evaluator compares the TOE security assurance requirements of the composite evaluation with those of the base component and its evaluation. The evaluator decides that the degree of trustworthiness of the base component-TSF is sufficient, if the composite product-SAR represent a subset of the base component-SAR: base component-SAR ⊇ composite product-SAR E.g. the EAL chosen for the composite evaluation does not exceed the EAL applied to the evaluation of the base component. The result of this work unit shall be integrated to the result of / . The evaluator shall examine the statement of compatibility to determine that all performed operations on the relevant TOE security functional requirements of the base component are appropriate for the composite product Security Target. This work unit relates to Step 3 of the Application Notes above. The relevant TOE security functional requirements of the base component comprise at least the elements of the group RP_SFR-SERV (cf. the work unit ), but also the RP_SFR-MECH may be presented as relevant TOE security functional requirements. The non-relevant TOE security functional requirements belong to IP_SFR. In order to perform this work unit the evaluator compares single parameters of the relevant SFRs of the base component with those of the composite evaluation. For example, the evaluator compares the properties of the respective components /RSA and determines that the composite-ST requires a key length of 2048 bit and the base-ST enforces the RSA-function with a key length of 1024 and 2048 bit, i.e. this parameter of the base component is appropriate for the composite-ST. Note, that the composite product-SFRs need not necessarily be the same as the base component-SFRs, e.g. a trusted channel () in the composite product can be built using an RSA implementation (/RSA) of the base component. The result of this work unit shall be integrated to the result of / . The evaluator shall examine the statement of compatibility to determine that the relevant TOE security objectives of the base component are not contradictory to those of the composite product Security Target. This work unit relates to Step 3 of the Application Notes above. The relevant TOE security objectives of the base-ST are those that are mapped to the relevant SFRs of the base-ST (cf. the work unit ). In order to perform this work unit the evaluator compares the relevant TOE security objectives of the base-ST with those of the composite-ST and determines whether they are not contradictory. The result of this work unit shall be integrated to the result of / . The evaluator shall examine the statement of compatibility to determine that the significant security objectives for the operational environment of the base component are not contradictory to those of the composite product Security Target. This work unit relates to Step 3 of the Application Notes above. In order to determine which security objectives for the operational environment of the base-ST are significant for the composite-ST the evaluator analyses the objectives for the environment of the base-ST and their separation in the following groups: IrOE: The objectives for the environment being not relevant for the composite-ST, e.g. the objectives for the environment about the developing and manufacturing phases of the base component; CfPOE: The objectives for the environment being fulfilled by the composite-ST automatically. Such objectives for the environment of the base-ST can always be assigned to the TOE security objectives of the composite-ST. Due to this fact they will be fulfilled either by the composite product-SFRs or by the composite product-SARs automatically. To give an example, let there be an objective for the environment OE.Resp-Appl of the base-ST: "All User Data are owned by Smartcard Embedded Software. Therefore, it must be assumed that security relevant User Data (especially cryptographic keys) are treated by the Smartcard Embedded Software as defined for the specific application context". Furthermore, a TOE security objective OT.Key_Secrecy of the composite-ST is given: "The secrecy of the signature private key used for signature generation is reasonably assured against attacks with a high attack potential." If the private key is the only sensitive data element, then the objective for the environment OE.Resp-Appl is covered by the TOE security objective OT.Key_Secrecy automatically; SgOE: The remaining objectives for the environment of the base-ST belonging neither to the group IrOE nor CfOE Exactly this group makes up the significant objectives for the environment for the composite-ST, which shall be addressed in the composite-ST. In order to accomplish this work unit the evaluator compares the significant security objectives for the operational environment of the base-ST with those of the composite-ST and determines whether they are not contradictory. If necessary, the significant security objectives for the operational environment of the base-ST shall be included into the composite-ST including the related assumptions from which the objectives for the environment are drawn. The inclusion is not necessary, if the composite-ST already contains equivalent (or similar) security objectives (covering all relevant aspects) and assumptions. Since assurance of the development and manufacturing environment of the base component is confirmed by the base component's evaluation, the respective objectives for the base component, if any, belong to the group IrOE. Assurance of development and manufacturing environment is usually completely addressed by the assurance class , and, hence, requires no explicit security objective. The result of this work unit shall be integrated to the result of / and / . Extended security requirements are requirements that are not based on components from CC Part 2 or this document, but which are based on extended components: components defined by the ST author. Evaluation of the definition of extended components is necessary to determine that they are clear and unambiguous, and that they are necessary, i.e. they may not be clearly expressed using existing CC Part 2 or this document components. The objective of this sub-activity is to determine whether extended components have been clearly and unambiguously defined, and whether they are necessary, i.e. they may not be clearly expressed using existing CC Part 2 or CC Part 3 components. the ST. The developer shall provide a statement of security requirements. The developer shall provide an extended components definition. The statement of security requirements shall identify all extended security requirements. The extended components definition shall define an extended component for each extended security requirement. The extended components definition shall describe how each extended component is related to the existing CC series components, families, and classes. The extended components definition shall use the existing CC series components, families, classes, and methodology as a model for presentation. The extended components shall consist of measurable and objective elements such that conformance or nonconformance to these elements may be demonstrated. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that all security requirements in the statement of security requirements that are not identified as extended requirements are present in CC Part 2 or in CC Part 3. The evaluator shall check that the extended components definition defines an extended component for each extended security requirement. If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. If the extended component definition(s) are taken from a PP/PP-Configuration that has previously been certified then the PP/PP-Configuration evaluation results may be reused as described in 12.2.1. A single extended component may be used to define multiple iterations of an extended security requirement; it is not necessary to repeat this definition for each iteration. The evaluator shall examine the extended components definition to determine that it describes how each extended component fits into the existing CC components, families, and classes. If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that each extended component is either: a member of an existing CC Part 2 or CC Part 3 family; or a member of a new family defined in the ST. If the extended component is a member of an existing CC Part 2 or CC Part 3 family, the evaluator determines that the extended components definition adequately describes why the extended component should be a member of that family and how it relates to other components of that family. If the extended component is a member of a new family defined in the ST, the evaluator confirms that the extended component is not appropriate for an existing family. If the ST defines new families, the evaluator determines that each new family is either: a member of an existing CC Part 2 or CC Part 3 class; or a member of a new class defined in the ST. If the family is a member of an existing CC Part 2 or CC Part 3 class, the evaluator determines that the extended components definition adequately describes why the family should be a member of that class and how it relates to other families in that class. If the family is a member of a new class defined in the ST, the evaluator confirms that the family is not appropriate for an existing class. The evaluator shall examine the extended components definition to determine that each definition of an extended component identifies all applicable dependencies of that component. If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator confirms that no applicable dependencies have been overlooked by the ST author. The evaluator shall examine the extended components definition to determine that each extended functional component uses the existing CC Part 2 components as a model for presentation. If the ST does not contain extended SFRs, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the extended functional component is consistent with CC Part 2, 7.1.4, Component structure. If the extended functional component uses operations, the evaluator determines that the extended functional component is consistent with CC Part 1, 8.2, Operations. If the extended functional component is hierarchical to an existing functional component, the evaluator determines that the extended functional component is consistent with CC Part 2, Introduction. The evaluator shall examine the extended components definition to determine that each definition of a new functional family uses the existing CC functional families as a model for presentation. If the ST does not define new functional families, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new functional families are defined consistent with CC Part 2, 7.1.3, Family structure. The evaluator shall examine the extended components definition to determine that each definition of a new functional class uses the existing CC functional classes as a model for presentation. If the ST does not define new functional classes, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new functional classes are defined consistent with CC Part 2, 7.1.2, Class structure. The evaluator shall examine the extended components definition to determine that each definition of an extended assurance component uses the existing CC Part 3 components as a model for presentation. If the ST does not contain extended SARs, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the extended assurance component definition is consistent with CC Part 3, 6.2, Assurance component structure. If the extended assurance component uses operations, the evaluator determines that the extended assurance component is consistent with CC Part 1, 8.2, Operations. If the extended assurance component is hierarchical to an existing assurance component, the evaluator determines that the extended assurance component is consistent with CC Part 3:2022, 6.1.3, Assurance component structure. The evaluator shall examine the extended components definition to determine that, for each defined extended assurance component, applicable methodology has been provided. If the ST does not contain extended SARs, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that, for each evaluator action element of each extended SAR, one or more work units are provided and that successfully performing all work units for a given evaluator action element will demonstrate that the element has been achieved. The evaluator shall examine the extended components definition to determine that each definition of a new assurance family uses the existing CC assurance families as a model for presentation. If the ST does not define new assurance families, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new assurance families are defined consistent with CC Part 3, 6.3, Assurance family structure. The evaluator shall examine the extended components definition to determine that each definition of a new assurance class uses the existing CC assurance classes as a model for presentation. If the ST does not define new assurance classes, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that all new assurance classes are defined consistent with CC Part 3, 6.2, Assurance class structure. The evaluator shall examine the extended components definition to determine that each element in each extended component is measurable and states objective evaluation requirements, such that conformance or nonconformance can be demonstrated. If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that elements of extended functional components are stated in such a way that they are testable, and traceable through the appropriate TSF representations. The evaluator also determines that elements of extended assurance components avoid the need for subjective evaluator judgement. The evaluator is reminded that whilst being measurable and objective is appropriate for all evaluation criteria, it is acknowledged that no formal method exists to prove such properties. Therefore, the existing CC functional and assurance components are to be used as a model for determining what constitutes conformance with this requirement. The evaluator shall confirm that no extended component may be clearly expressed using existing components. The evaluator shall examine the extended components definition to determine that each extended component cannot be clearly expressed using existing components. If the ST does not contain extended security requirements, this work unit is not applicable and therefore considered to be satisfied. The evaluator should take components from CC Part 2 and CC Part 3, other extended components that have been defined in the ST, combinations of these components, and possible operations on these components into account when making this determination. The evaluator is reminded that the role of this work unit is to preclude unnecessary duplication of components, that is, components that may be clearly expressed by using other components. The evaluator should not undertake an exhaustive search of all possible combinations of components including operations in an attempt to find a way to express the extended component by using existing components. The objective of this family is to describe the TOE in a narrative way on three levels of abstraction: TOE reference, TOE overview and TOE description. Evaluation of the ST introduction is required to demonstrate that the ST and the TOE are correctly identified, that the TOE is correctly described at three levels of abstraction and that these three descriptions are consistent with each other. The objective of this sub-activity is to determine whether the ST and the TOE are correctly identified, whether the TOE is correctly described in a narrative way at three levels of abstraction (TOE reference, TOE overview and TOE description), and whether these three descriptions are consistent with each other. the ST. The developer shall provide an ST introduction. The ST introduction shall contain an ST reference, a TOE reference, a TOE overview and a TOE description. The ST reference shall uniquely identify the ST. The TOE reference shall uniquely identify the TOE. The TOE overview shall summarize the usage and major security features of the TOE. The TOE overview shall identify the TOE type. The TOE overview shall identify any non-TOE hardware/software/firmware required by the TOE. For a multi-assurance ST, the TOE overview shall describe the TSF organization in terms of the sub-TSFs defined in the PP-Configuration the ST claims conformance to. The TOE description shall describe the physical scope of the TOE. The TOE description shall describe the logical scope of the TOE. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the ST introduction contains an ST reference, a TOE reference, a TOE overview and a TOE description. The evaluator shall examine the ST reference to determine that it uniquely identifies the ST. The evaluator determines that the ST reference identifies the ST itself, so that it may be easily distinguished from other STs, and that it also uniquely identifies each version of the ST, e.g. by including a version number and/or a date of publication. In evaluations where a CM system is provided, the evaluator may validate the uniqueness of the reference by checking the configuration list. In the other cases, the ST should have some referencing system that is capable of supporting unique references (e.g. use of numbers, letters or dates). The evaluator shall examine the TOE reference to determine that it uniquely identifies the TOE. The evaluator determines that the TOE reference uniquely identifies the TOE, so that it is clear to which TOE the ST refers, and that it also identifies the version of the TOE, e.g. by including a version/release/build number, or a date of release. In the end of the evaluation, the evaluator shall check the TOE reference, and any unique identifiers associated with the TOE physical components are consistent with the identifier(s) assigned to the TOE evaluated in work units related to .x.1C and the configuration list evaluated in work units related to .x.2C. The evaluator shall examine the TOE reference to determine that it is not misleading. If the TOE is related to one or more well-known products, it is allowed to reflect this in the TOE reference. However, this should not be used to mislead consumers and it must be made clear which part of the product has been evaluated. When a TOE needs some required non-TOE hardware/software/firmware to run properly, the TOE reference may include the name of the non-TOE hardware/software/firmware used by the TOE, however it must be made clear that the non-TOE hardware/software/firmware has not been evaluated. The evaluator shall examine the TOE overview to determine that it describes the usage and major security features of the TOE. The TOE overview may describe security features that are provided by the product, and/or those that users may expect in that product type, but it must clearly distinguish those features that are evaluated and those that are not evaluated. The TOE overview shall be consistent with information provided in other sections of the Security Target such as the TOE description, the security objectives, the security functional requirements, and the TOE summary specification. In addition to ensuring the evaluated security features are consistently described throughout the ST, this means that any security feature that is not evaluated is only discussed within the ST introduction, or else is explicitly identified as not evaluated in each other place where it is mentioned (failure to make this identification means that this work unit is assigned a fail verdict). The TOE overview in an ST for a composed TOE should describe the usage and major security feature of the composed TOE, rather than those of the individual component TOEs. The evaluator determines that the overview is clear enough for consumers, and sufficient to give them a general understanding of the intended usage and major security features of the TOE. The evaluator shall check that the TOE overview identifies the TOE type. The evaluator shall examine the TOE overview to determine that the TOE type is not misleading. There are situations where the general consumer would expect certain functionality of the TOE because of its TOE type. If this functionality is absent in the TOE, the evaluator determines that the TOE overview adequately discusses this absence. There are also TOEs where the general consumer would expect that the TOE should be able to operate in a certain operational environment because of its TOE type. If the TOE is unable to operate in such an operational environment, the evaluator determines that the TOE overview adequately discusses this. The evaluator shall examine the TOE overview to determine that it identifies any non-TOE hardware/software/firmware required by the TOE. While some TOEs are able to run stand-alone, other TOEs (notably software TOEs) need additional hardware, software or firmware to operate. If the TOE does not require any hardware, software or firmware, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the TOE overview identifies any additional hardware, software and firmware needed by the TOE to operate. This identification does not have to be exhaustive, but detailed enough for potential consumers of the TOE to determine whether their current hardware, software and firmware support use of the TOE, and, if this is not the case, which additional hardware, software and/or firmware is needed. For a multi-assurance ST, the evaluator shall examine the TOE overview to determine that it describes the TSF organization in terms of the sub-TSFs defined in the PP-Configuration to which the ST claims conformance. The TSF organization is possibly completed with details of the actual TOE. The evaluator shall examine the TOE description to determine that it describes the physical scope of the TOE. The evaluator determines that the TOE description lists the hardware, firmware, software and guidance parts that constitute the TOE and describes them at a level of detail that is sufficient to give the reader a general understanding of those parts. As a minimum, the TOE description will cover the following elements: each separately delivered part of the TOE, which will be identified by its unique identifier and the current format (binary, wafer, inlay, pdf, docx, chm, etc.); the delivery method used by the developer to make available each part to the TOE consumer (web site download, courier delivery, etc.). The physical description will also include some clear statements about the evaluated TOE configuration. In the case where a product can have multiple physical components, and therefore multiple configurations, the evaluated configurations must be briefly described and identified. The evaluator also determines that there is no possible misunderstanding as to whether any hardware, firmware, software or guidance part is part of the TOE or not. The evaluator shall examine the TOE description to determine that it describes the logical scope of the TOE. The evaluator determines that the TOE description discusses the logical security features offered by the TOE at a level of detail that is sufficient to give the reader a general understanding of those features. The evaluator also determines that there is no possible misunderstanding as to whether any logical security feature is offered by the TOE or not. An ST for a composed TOE may refer out to the description of the logical scope of the component TOEs, provided in the component TOE STs to provide the majority of this description for the composed TOE. However, the evaluator determines that the composed TOE ST clearly discusses which features of the individual components are not within the composed TOE, and therefore not a feature of the composed TOE. The evaluator shall confirm that the TOE reference, the TOE overview, and the TOE description are consistent with each other. The evaluator shall examine the TOE reference, TOE overview and TOE description to determine that they are consistent with each other. The security objectives are a concise statement of the intended response to the security problem defined through the family. Evaluation of the security objectives is required to demonstrate that the security objectives adequately and completely address the security problem definition, that the division of this problem between the TOE and its operational environment is clearly defined. The components in this family are levelled on whether they prescribe only security objectives for the operational environment , or also security objectives for the TOE . The objective of this sub-activity is to determine whether the security objectives for the operational environment are clearly defined. the ST. The developer shall provide a statement of security objectives for the operational environment. The developer shall provide a security objectives rationale for the operational environment. The statement of security objectives shall describe the security objectives for the operational environment. The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective, and assumptions upheld by that security objective. The security objectives rationale shall demonstrate that the security objectives for the operational environment uphold all assumptions. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security objectives defines the security objectives for the operational environment. The evaluator checks that the security objectives for the operational environment are identified. The evaluator shall check that the security objectives rationale traces all security objectives for the operational environment back to threats countered by the objectives, OSPs enforced by the objectives and/or assumptions upheld by the objectives. Each security objective for the operational environment may trace back to threats, OSPs or assumptions, or a combination of threats, OSPs and assumptions, but it must trace back to at least one threat, OSP or assumption. Failure to trace implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the operational environment has no useful purpose. The evaluator shall examine the security objectives rationale to determine that for each assumption for the operational environment it contains an appropriate justification that the security objectives for the operational environment are suitable to uphold that assumption. If no security objectives for the operational environment trace back to the assumption, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an assumption about the operational environment of the TOE demonstrates that the security objectives are sufficient: if all security objectives for the operational environment that trace back to that assumption are achieved, the operational environment upholds the assumption. The evaluator also determines that each security objective for the operational environment that traces back to an assumption about the operational environment of the TOE is necessary: when the security objective is achieved it actually contributes to the operational environment upholding the assumption. Note that the tracings from security objectives for the operational environment to assumptions provided in the security objectives rationale may be a part of a justification, but do not constitute a justification by themselves. Even in the case that a security objective of the operational environment is merely a restatement of an assumption, a justification is required, but this justification may be as minimal as "Security Objective X directly upholds Assumption Y". The objective of this sub-activity is to determine whether the security objectives adequately and completely address the security problem definition and that the division of this problem between the TOE and its operational environment is clearly defined. the ST. The developer shall provide a statement of security objectives. The developer shall provide a security objectives rationale. The statement of security objectives shall describe the security objectives for the TOE and the security objectives for the operational environment. The security objectives rationale shall trace each security objective for the TOE back to threats countered by that security objective and OSPs enforced by that security objective. The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective, and assumptions upheld by that security objective. The security objectives rationale shall demonstrate that the security objectives counter all threats. The security objectives rationale shall demonstrate that the security objectives enforce all OSPs. The security objectives rationale shall demonstrate that the security objectives for the operational environment uphold all assumptions. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security objectives defines the security objectives for the TOE and the security objectives for the operational environment. The evaluator checks that both categories of security objectives are clearly identified and separated from the other category. The evaluator shall check that the security objectives rationale traces all security objectives for the TOE back to threats countered by the objectives and/or OSPs enforced by the objectives. Each security objective for the TOE may trace back to threats or OSPs, or a combination of threats and OSPs, but it must trace back to at least one threat or OSP. Failure to trace implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the TOE has no useful purpose. The evaluator shall check that the security objectives rationale traces the security objectives for the operational environment back to threats countered by that security objective, to OSPs enforced by that security objective, and to assumptions upheld by that security objective. Each security objective for the operational environment may trace back to threats, OSPs, assumptions, or a combination of threats, OSPs and/or assumptions, but it must trace back to at least one threat, OSP or assumption. Failure to trace implies that either the security objectives rationale is incomplete, the security problem definition is incomplete, or the security objective for the operational environment has no useful purpose. The evaluator shall examine the security objectives rationale to determine that it justifies for each threat that the security objectives are suitable to counter that threat. If no security objectives trace back to the threat, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for a threat shows whether the threat is removed, diminished or mitigated. The evaluator determines that the justification for a threat demonstrates that the security objectives are sufficient: if all security objectives that trace back to the threat are achieved, the threat is removed, sufficiently diminished, or the effects of the threat are sufficiently mitigated. Note that the tracings from security objectives to threats provided in the security objectives rationale may be part of a justification, but do not constitute a justification by themselves. Even in the case that a security objective is merely a statement reflecting the intent to prevent a particular threat from being realised, a justification is required, but this justification may be as minimal as "Security Objective X directly counters Threat Y". The evaluator also determines that each security objective that traces back to a threat is necessary: when the security objective is achieved it actually contributes to the removal, diminishing or mitigation of that threat. The evaluator shall examine the security objectives rationale to determine that for each OSP it justifies that the security objectives are suitable to enforce that OSP. If no security objectives trace back to the OSP, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an OSP demonstrates that the security objectives are sufficient: if all security objectives that trace back to that OSP are achieved, the OSP is enforced. The evaluator also determines that each security objective that traces back to an OSP is necessary: when the security objective is achieved it actually contributes to the enforcement of the OSP. Note that the tracings from security objectives to OSPs provided in the security objectives rationale may be part of a justification, but do not constitute a justification by themselves. In the case that a security objective is merely a statement reflecting the intent to enforce a particular OSP, a justification is required, but this justification may be as minimal as "Security Objective X directly enforces OSP Y". The evaluator shall examine the security objectives rationale to determine that for each assumption for the operational environment it contains an appropriate justification that the security objectives for the operational environment are suitable to uphold that assumption. If no security objectives for the operational environment trace back to the assumption, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an assumption about the operational environment of the TOE demonstrates that the security objectives are sufficient: if all security objectives for the operational environment that trace back to that assumption are achieved, the operational environment upholds the assumption. The evaluator also determines that each security objective for the operational environment that traces back to an assumption about the operational environment of the TOE is necessary: when the security objective is achieved it actually contributes to the operational environment upholding the assumption. Note that the tracings from security objectives for the operational environment to assumptions provided in the security objectives rationale may be a part of a justification, but do not constitute a justification by themselves. Even in the case that a security objective of the operational environment is merely a restatement of an assumption, a justification is required, but this justification may be as minimal as "Security Objective X directly upholds Assumption Y". The SFRs form a clear, unambiguous and well-defined description of the expected security behaviour of the TOE. The SARs form a clear, unambiguous and canonical description of the expected activities that will be undertaken to gain assurance in the TOE. Evaluation of the security requirements is required to ensure that they are clear, unambiguous and well-defined. The components in this family are levelled on whether they are stated as is (see ), or whether the SFRs are derived from security objectives for the TOE (see .). The objective of this sub-activity is to determine whether the SFRs and SARs are clear, unambiguous and well-defined, whether they are internally consistent, and whether the SFRs counter the threats and implement the organisational security policies of the TOE. the ST. The developer shall provide a statement of security requirements. The developer shall provide a security requirements rationale. The statement of security requirements shall describe the SFRs and the SARs. For a single-assurance ST, the statement of security requirements shall define the global set of SARs that apply to the entire TOE. The sets of SARs shall be consistent with the PPs or PP-Configuration to which the ST claims conformance. For a multi-assurance ST, the statement of security requirements shall define the global set of SARs that apply to the entire TOE and the sets of SARs that apply to each sub-TSF. The sets of SARs shall be consistent with the multi-assurance PP-Configuration to which the ST claims conformance. All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined. The statement of security requirements shall identify all operations on the security requirements. All operations shall be performed correctly. Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied. The security requirements rationale shall demonstrate that the SFRs (in conjunction with the security objectives for the environment) counter all threats for the TOE. The security requirements rationale shall demonstrate that the SFRs (in conjunction with the security objectives for the environment) enforce all OSPs. The security requirements rationale shall explain why the SARs were chosen. The statement of security requirements shall be internally consistent. If the ST defines sets of SARs that expand the sets of SARs of the PPs or PP-Configuration it claims conformance to, the security requirements rationale shall include an assurance rationale that justifies the consistency of the extension and provides a rationale for the disposition of any Evaluation methods and Evaluation activities identified in the conformance statement that are affected by the extension of the sets of SARs. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security requirements describes the SFRs. The evaluator determines that each SFR is identified by one of the following means: by reference to an individual component in CC Part 2; by reference to an extended component in the extended components definition of the ST; by reference to a PP that the ST claims to be conformant with, including any optional requirements defined in the PP; by reference to a security requirements package that the ST claims to be conformant with; by reproduction in the ST. It is not required to use the same means of identification for all SFRs. The evaluator shall check that the statement of security requirements describes the SARs. The evaluator determines that each SAR is identified by one of the following means: by reference to an individual component in CC Part 3; by reference to an extended component in the extended components definition of the ST; by reference to a PP that the ST claims to be conformant with; by reference to a security requirements package that the ST claims to be conformant with; by reproduction in the ST. It is not required to use the same means of identification for all SARs. Note that if optional requirements are defined by the PP, there may be associated threats that are covered by this work unit. The evaluator shall check that the statement of security requirements defines the global set of SARs that apply to the entire TOE. The evaluator shall examine the sets of SARs to determine that they are consistent with the PPs or the PP-Configuration to which the ST claims conformance. For a multi-assurance ST, the evaluator shall examine the statement of security requirements to determine that it defines the global set of SARs that apply to the entire TOE. The TSF organization associates sub-TSFs with specific assurance requirements. It may happen that sub-TSFs are implemented by different sets of subsystems/modules, but there may also be some degree of overlap: a subsystem or module may implement functionalities belonging to two different sub-TSFs. This means that the two sets of SARs apply to the common subsystem or module (i.e. the union of the sets of SARs applies). In both cases, for each sub-TSF, all of the other sub-TSFs belong to the TOE and the corresponding subsystems/modules must be evaluated through the prism of the requirements of the sub-TSF. The evaluator shall check that the SARs that apply to each sub-TSF are defined in the ST and that they are either identical to the ones defined in the PP-Configuration or augmented. Augmentation is only allowed when strict or demonstrable conformance is being claimed by the ST to the PP-Configuration. For augmented sets of SARs, the evaluator shall check that a rationale is provided. The evaluator shall check that the sets of SARs defined in the ST are consistent with the multi-assurance PP-Configuration to which the ST claims conformance. The evaluator shall examine the ST to determine that all subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs are defined. The evaluator determines that the ST defines all: (types of) subjects and objects that are used in the SFRs; (types of) security attributes of subjects, users, objects, information, sessions and/or resources, possible values that these attributes may take and any relations between these values (e.g. top_secret is "higher" than secret); (types of) operations that are used in the SFRs, including the effects of these operations; (types of) external entities in the SFRs; other terms that are introduced in the SFRs and/or SARs by completing operations, if these terms are not immediately clear, or are used outside their dictionary definition. The goal of this work unit is to ensure that the SFRs and SARs are well-defined and that no misunderstanding may occur due to the introduction of vague terms. This work unit should not be taken into extremes, by forcing the ST author to define every single word. The general audience of a set of security requirements should be assumed to have a reasonable knowledge of IT, security and the CC series. All of the above may be presented in groups, classes, roles, types or other groupings or characterisations that allow easy understanding. The evaluator is reminded that these lists and definitions do not have to be part of the statement of security requirements, but may be placed (in part or in whole) in different subclauses. This may be especially applicable if the same terms are used in the rest of the ST. The evaluator shall check that the statement of security requirements identifies all operations on the security requirements. The evaluator determines that all operations are identified in each SFR or SAR where such an operation is used. Identification may be achieved by typographical distinctions, or by explicit identification in the surrounding text, or by any other distinctive means. The evaluator shall examine the statement of security requirements to determine that all assignment operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2 Operations. The evaluator shall examine the statement of security requirements to determine that all iteration operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2 Operations. The evaluator shall examine the statement of security requirements to determine that all selection operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2 Operations. The evaluator shall examine the statement of security requirements to determine that all refinement operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2 Operations. The evaluator shall examine the statement of security requirements to determine that each dependency of the security requirements is either satisfied, or that a security requirements rationale is provided which justifies the dependency not being satisfied. A dependency is satisfied by the inclusion of the relevant component (or one that is hierarchical to it) within the statement of security requirements. The component used to satisfy the dependency should, if necessary, be modified by operations to ensure that it actually satisfies that dependency. A justification that a dependency is not met should address either: why the dependency is not necessary or useful, in which case no further information is required; or that the dependency has been addressed by the operational environment of the TOE, in which case the justification should describe how the security objectives for the operational environment address this dependency. The evaluator shall examine the security requirements rationale to determine that for each threat it demonstrates that the SFRs are suitable to meet that threat and that each SFR is traced back to at least one threat (or OSP) for the TOE. If no SFRs trace back to a threat, the evaluator action related to this work unit is assigned a fail verdict as it implies that either the security requirements rationale is incomplete, the security objectives for the TOE are incomplete, or some SFRs have no useful purpose. The evaluator determines that the justification for a threat shows whether the threat is removed, diminished or mitigated. The evaluator determines that the justification for a threat demonstrates that the SFRs are sufficient: if all SFRs that trace back to the threat are achieved then, in the context of any applicable OSPs and assumptions, the threat is removed, sufficiently diminished, or the effects of the threat are sufficiently mitigated. Note that simply listing in the security requirements rationale the SFRs associated with each threat may be part of a justification, but does not constitute a justification by itself. A descriptive justification is required, although in simple cases this justification may be as minimal as "SFR X directly counters Threat Y". The evaluator also determines that each SFR that traces back to a threat is necessary: when the SFR is implemented it actually contributes to the removal, diminishing or mitigation of that threat. The evaluator shall examine the security requirements rationale to determine that for each OSP it justifies that the SFRs are suitable to enforce that OSP. If no SFRs or security objectives for the operational environment trace back to the OSP, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for an OSP demonstrates that the security objectives are sufficient: if all SFRs that trace back to that OSP are achieved then, in the context of any applicable assumptions, the OSP is enforced. The evaluator also determines that each SFR that traces back to an OSP is necessary: when the SFR is implemented it actually contributes to the enforcement of the OSP. Note that simply listing in the security requirements rationale the SFRs associated with each OSP may be part of a justification, but does not constitute a justification by itself. A descriptive justification is required, although in simple cases this justification may be as minimal as "SFR X directly enforces OSP Y". The evaluator shall examine the security requirements rationale to determine that the inclusion of each chosen SAR has been explained and is justified. The evaluator shall examine the statement of security requirements to determine that it is internally consistent. The evaluator determines that the combined set of all SFRs and SARs is internally consistent. With respect to optional requirements, the evaluator determines that: all optional requirements either trace to an SPD element that is itself not optional, or trace to an SPD element that is clearly associated with that optional SFR; all optional requirements marked as conditional in a PP or PP-Configuration Component to which the ST claims conformance are included if the TOE implements functionality that is covered by the requirement. Elective optional requirements may be omitted; all optional requirements do not conflict with non-optional requirements (a capability cannot be both required and optional; however, a base capability can be required with enhancements to that capability being specified as optional). The evaluator determines that on all occasions where different security requirements apply to the same types of developer evidence, events, operations, data, tests to be performed etc. or to "all objects", "all subjects" etc., that these requirements do not conflict. Some possible conflicts are: an extended SAR specifying that the design of a certain cryptographic algorithm is to be kept secret, and another extended SAR specifying an open source review; specifying that subject identity is to be logged, specifying who has access to these logs, and specifying that some actions of subjects should be unobservable to other subjects. If the subject that should not be able to see an activity may access logs of this activity, these SFRs conflict; specifying deletion of information no longer needed, and specifying that a TOE may return to a previous state. If the information that is needed for the rollback to the previous state has been deleted, these requirements conflict; multiple iterations of especially where some iterations cover the same subjects, objects, or operations. If one access control SFR allows a subject to perform an operation on an object, while another access control SFR does not allow this, these requirements conflict. If an ST extends the sets of SARs of the PP(s) or PP-Configuration it claims conformance to, the evaluator shall examine the security requirements rationale to determine that it includes an assurance rationale justifying the consistency of the extension with regard to the SPD, together with a rationale for the disposition of any Evaluation Methods/Evaluation Activities defined in the PP(s) or PP-Configuration to which it claims conformance that are affected by the extension of the sets of SARs. If the ST does not claim conformance to one or more PPs, or to a PP-Configuration, this work unit is not applicable and should be considered satisfied. If the ST claims exact conformance to one or more PPs, or to a PP-Configuration, then augmentation of the SARs is not allowed and the evaluator verifies that either no augmentation has been performed (in which case this work unit is considered satisfied), or that the conformance claim is either strict or demonstrable. Where the expansion of the SARs affects any Evaluation Methods/Evaluation Activities defined in the PP or PP-Configuration to which the ST claims conformance, the evaluator examines the assurance rationale to confirm that it preserves the relevant aspects of the affected Evaluation Methods/Evaluation Activities, taking into account the context in which the ST is to be used. This includes a check that the assurance resulting from meeting the expanded SARs will be as least as strong as that generated by the original Evaluation Methods/Evaluation Activities. If either rationale is missing, or incomplete, then the evaluator action related to this work unit is assigned a fail verdict. The objective of this sub-activity is to determine whether the SFRs and SARs are clear, unambiguous and well-defined, whether they are internally consistent, and whether the SFRs meet the security objectives of the TOE. the ST. The developer shall provide a statement of security requirements. The developer shall provide a security requirements rationale. The statement of security requirements shall describe the SFRs and the SARs. For a single-assurance ST, the statement of security requirements shall define the global set of SARs that apply to the entire TOE. The sets of SARs shall be consistent with the PPs or PP-Configuration to which the ST claims conformance. For a multi-assurance ST, the statement of security requirements shall define the global set of SARs that apply to the entire TOE and the sets of SARs that apply to each sub-TSF. The sets of SARs shall be consistent with the multi-assurance PP-Configuration to which the ST claims conformance. All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined. The statement of security requirements shall identify all operations on the security requirements. All operations shall be performed correctly. Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied. The security requirements rationale shall demonstrate that the SFRs meet all security objectives for the TOE. The security requirements rationale shall explain why the SARs were chosen. The statement of security requirements shall be internally consistent. If the ST defines sets of SARs that expand the sets of SARs of the PPs or PP-Configuration it claims conformance to, the security requirements rationale shall include an assurance rationale that justifies the consistency of the extension and provides a rationale for the disposition of any Evaluation methods and Evaluation activities identified in the conformance statement that are affected by the extension of the sets of SARs. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the statement of security requirements describes the SFRs. The evaluator determines that each SFR is identified by one of the following means: by reference to an individual component in CC Part 2; by reference to an extended component in the extended components definition of the ST; by reference to an individual component in a PP that the ST claims to be conformant with, including any optional requirements defined in the PP; by reference to an individual component in a security requirements package that the ST claims to be conformant with; by reproduction in the ST. It is not required to use the same means of identification for all SFRs. The evaluator shall check that the statement of security requirements describes the SARs. The evaluator determines that all SARs are identified by one of the following means: by reference to an individual component in CC Part 3; by reference to an extended component in the extended components definition of the ST; by reference to an individual component in a PP that the ST claims to be conformant with; by reference to an individual component in a security requirements package that the ST claims to be conformant with; by reproduction in the ST. It is not required to use the same means of identification for all SARs. Note that if optional requirements are defined by the PP, there may be associated threats that are covered by this work unit. The evaluator shall check that the statement of security requirements defines the global set of SARs that apply to the entire TOE. The evaluator shall examine the sets of SARs to determine that they are consistent with the PPs or PP-Configuration to which the ST claims conformance. For a multi-assurance ST, the evaluator shall examine the statement of security requirements to determine that it defines the global set of SARs that apply to the entire TOE. The TSF organization associates sub-TSFs with specific assurance requirements. It may happen that sub-TSFs are implemented by different sets of subsystems/modules, but there may also be some degree of overlap: a subsystem or module may implement functionalities belonging to two different sub-TSFs. This means that the two sets of SARs apply to the common subsystem or module (i.e. the union of the sets of SARs applies). In both cases, for each sub-TSF, all of the other sub-TSFs belong to the TOE and the corresponding subsystems/modules must be evaluated through the prism of the requirements of the sub-TSF. The evaluator shall check that the SARs that apply to each sub-TSF are defined in the ST and that they are either identical to the ones defined in the PP-Configuration or augmented. Augmentation is only allowed when strict or demonstrable conformance is being claimed by the ST to the PP-Configuration. For augmented sets of SARs, the evaluator shall check that a rationale is provided. The evaluator shall check that the sets of SARs defined in the ST are consistent with the multi-assurance PP-Configuration to which the ST claims conformance. The evaluator shall examine the ST to determine that all subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs are defined. The evaluator determines that the ST defines all: (types of) subjects and objects that are used in the SFRs; (types of) security attributes of subjects, users, objects, information, sessions and/or resources, possible values that these attributes may take and any relations between these values (e.g. top_secret is "higher" than secret); (types of) operations that are used in the SFRs, including the effects of these operations; (types of) external entities in the SFRs; other terms that are introduced in the SFRs and/or SARs by completing operations, if these terms are not immediately clear, or are used outside their dictionary definition. The goal of this work unit is to ensure that the SFRs and SARs are well-defined and that no misunderstanding may occur due to the introduction of vague terms. This work unit should not be taken into extremes, by forcing the ST author to define every single word. The general audience of a set of security requirements should be assumed to have a reasonable knowledge of IT, security and the CC series. All of the above may be presented in groups, classes, roles, types or other groupings or characterisations that allow easy understanding. The evaluator is reminded that these lists and definitions do not have to be part of the statement of security requirements, but may be placed (in part or in whole) in different subclauses. This may be especially applicable if the same terms are used in the rest of the ST. The evaluator shall check that the statement of security requirements identifies all operations on the security requirements. The evaluator determines that all operations are identified in each SFR or SAR where such an operation is used. Identification may be achieved by typographical distinctions, or by explicit identification in the surrounding text, or by any other distinctive means. The evaluator shall examine the statement of security requirements to determine that all assignment operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2 Operations. The evaluator shall examine the statement of security requirements to determine that all iteration operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2 Operations. The evaluator shall examine the statement of security requirements to determine that all selection operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2 Operations. The evaluator shall examine the statement of security requirements to determine that all refinement operations are performed correctly. Guidance on the correct performance of operations may be found in CC Part 1, 8.2 Operations. The evaluator shall examine the statement of security requirements to determine that each dependency of the security requirements is either satisfied, or that the security requirements rationale justifies the dependency not being satisfied. A dependency is satisfied by the inclusion of the relevant component (or one that is hierarchical to it) within the statement of security requirements. The component used to satisfy the dependency should, if necessary, be modified by operations to ensure that it actually satisfies that dependency. A justification that a dependency is not met should address either: why the dependency is not necessary or useful, in which case no further information is required; or that the dependency has been addressed by the operational environment of the TOE, in which case the justification should describe how the security objectives for the operational environment address this dependency. The evaluator shall examine the security requirements rationale to determine that for each security objective for the TOE it demonstrates that the SFRs are suitable to meet that security objective for the TOE. If no SFRs trace back to the security objective for the TOE, the evaluator action related to this work unit is assigned a fail verdict. The evaluator determines that the justification for a security objective for the TOE demonstrates that the SFRs are sufficient: if all SFRs that trace back to the objective are satisfied, the security objective for the TOE is achieved. The evaluator also determines that each SFR that traces back to a security objective for the TOE is necessary: when the SFR is satisfied, it actually contributes to achieving the security objective. Note that the tracings from SFRs to security objectives for the TOE provided in the security requirements rationale may be a part of the justification, but do not constitute a justification by themselves. The evaluator shall check that the security requirements rationale explains why the SARs were chosen. The evaluator is reminded that any explanation is correct, as long as it is coherent and neither the SARs nor the explanation have obvious inconsistencies with the remainder of the ST. An example of an obvious inconsistency between the SARs and the remainder of the ST would be to have threat agents that are very capable, but an SAR that does not protect against these threat agents. The evaluator shall examine the statement of security requirements to determine that it is internally consistent. The evaluator determines that the combined set of all SFRs and SARs is internally consistent. With respect to optional requirements, the evaluator determines that: all optional requirements either trace to an SPD element that is itself not optional, or trace to an SPD element that is clearly associated with that optional SFR; all optional requirements marked as conditional in a PP or PP-Configuration Component to which the ST claims conformance are included if the TOE implements functionality that is covered by the requirement. Elective optional requirements may be omitted; all optional requirements do not conflict with non-optional requirements (a capability cannot be both required and optional; however, a base capability can be required with enhancements to that capability being specified as optional). The evaluator determines that on all occasions where different security requirements apply to the same types of developer evidence, events, operations, data, tests to be performed etc. or to "all objects", "all subjects" etc., that these requirements do not conflict. Some possible conflicts are: an extended SAR specifying that the design of a certain cryptographic algorithm is to be kept secret, and another extended assurance requirement specifying an open source review; specifying that subject identity is to be logged, specifying who has access to these logs, and specifying that some actions of subjects should be unobservable to other subjects. If the subject that should not be able to see an activity may access logs of this activity, these SFRs conflict; specifying deletion of information no longer needed, and specifying that a TOE may return to a previous state. If the information that is needed for the rollback to the previous state has been deleted, these requirements conflict; multiple iterations of especially where some iterations cover the same subjects, objects, or operations. If one access control SFR allows a subject to perform an operation on an object, while another access control SFR does not allow this, these requirements conflict. If an ST that extends the sets of SARs of the PP-Configuration it claims conformance to, the evaluator shall examine the security requirements rationale to determine that it includes an assurance rationale justifying the consistency of the extension with regard to the SPD, together with a rationale for the disposition of any Evaluation Methods/Evaluation Activities defined in the PP(s) or PP-Configuration to which it claims conformance that are affected by the extension of the sets of SARs. If the ST does not claim conformance to one or more PPs, or to a PP-Configuration, this work unit is not applicable and should be considered satisfied. If the ST claims exact conformance to one or more PPs, or to a PP-Configuration, then augmentation of the SARs is not allowed and the evaluator verifies that either no augmentation has been performed (in which case this work unit is considered satisfied), or that the conformance claim is either strict or demonstrable. Where the expansion of the SARs affects any Evaluation Methods/Evaluation Activities defined in the PP or PP-Configuration to which the ST claims conformance, the evaluator examines the assurance rationale to confirm that it preserves the relevant aspects of the affected Evaluation Methods/Evaluation Activities, taking into account the context in which the ST is to be used. This includes a check that the assurance resulting from meeting the expanded SARs will be as least as strong as that generated by the original Evaluation Methods/Evaluation Activities. If either rationale is missing, or incomplete, then the evaluator action related to this work unit is assigned a fail verdict. This part of the ST defines the security problem to be addressed by the TOE and the operational environment of the TOE. Evaluation of the security problem definition is required to demonstrate that the security problem intended to be addressed by the TOE and its operational environment, is clearly defined. The objective of this sub-activity is to determine that the security problem intended to be addressed by the TOE and its operational environment is clearly defined. the ST. The developer shall provide a security problem definition. The security problem definition shall describe the threats. All threats shall be described in terms of a threat agent, an asset, and an adverse action. The security problem definition shall describe the OSPs. The security problem definition shall describe the assumptions about the operational environment of the TOE. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the security problem definition describes the threats. If all security objectives are derived from assumptions and/or OSPs only, the statement of threats need not be present in the ST. In this case, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that the security problem definition describes the threats that must be countered by the TOE and/or operational environment. The evaluator shall examine the security problem definition to determine that all threats are described in terms of a threat agent, an asset, and an adverse action. If all security objectives are derived from assumptions and/or OSPs only, the statement of threats need not be present in the ST. In this case, this work unit is not applicable and therefore considered to be satisfied. Threat agents may be further described by aspects such as expertise, resource, opportunity, and motivation. The evaluator shall examine that the security problem definition describes the OSPs. If all security objectives are derived from assumptions and threats only, OSPs need not be present in the ST. In this case, this work unit is not applicable and therefore considered to be satisfied. The evaluator determines that OSP statements are made in terms of rules or guidelines that must be followed by the TOE and/or its operational environment. The evaluator determines that each OSP is explained and/or interpreted in sufficient detail to make it clearly understandable; a clear presentation of policy statements is necessary to permit tracing security objectives to them. The evaluator shall examine the security problem definition to determine that it describes the assumptions about the operational environment of the TOE. If there are no assumptions, this work unit is not applicable and is therefore considered to be satisfied. The evaluator determines that each assumption about the operational environment of the TOE is explained in sufficient detail to enable consumers to determine that their operational environment matches the assumption. If the assumptions are not clearly understood, the end result may be that the TOE is used in an operational environment in which it will not function in a secure manner. The TOE summary specification enables evaluators and potential consumers to gain a general understanding of how the TOE is implemented. Evaluation of the TOE summary specification is necessary to determine whether it is adequately described how the TOE: meets its SFRs; protects itself against interference, logical tampering and bypass; and whether the TOE summary specification is consistent with other narrative descriptions of the TOE. The components in this family are levelled on whether the TOE summary specification only needs to describe how the TOE meets the SFRs, or whether the TOE summary specification also needs to describe how the TOE protects itself against logical tampering and bypass. This additional description may be used in special circumstances where there can be a specific concern regarding the TOE security architecture. The objective of this sub-activity is to determine whether the TOE summary specification addresses all SFRs, and whether the TOE summary specification is consistent with other narrative descriptions of the TOE. the ST. The developer shall provide a TOE summary specification. The TOE summary specification shall describe how the TOE meets each SFR. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE summary specification to determine that it describes how the TOE meets each SFR. The evaluator determines that the TOE summary specification provides, for each SFR from the statement of security requirements, a description on how that SFR is met. The evaluator is reminded that the objective of each description is to provide potential consumers of the TOE with a high-level view of how the developer intends to satisfy each SFR and that the descriptions therefore should not be overly detailed. Often several SFRs will be implemented in one context; for instance, a password authentication mechanism may implement , and . Therefore, usually the TSS will not consist of a long list with texts for each single SFR, but complete groups of SFRs may be covered by one text passage. For a composed TOE, the evaluator also determines that it is clear which component provides each SFR or how the components combine to meet each SFR. The evaluator shall confirm that the TOE summary specification is consistent with the TOE overview and the TOE description. The evaluator shall examine the TOE summary specification to determine that it is consistent with the TOE overview and the TOE description. The TOE overview, TOE description, and TOE summary specification describe the TOE in a narrative form at increasing levels of detail. These descriptions therefore need to be consistent. The objective of this sub-activity is to determine whether the TOE summary specification addresses all SFRs, whether the TOE summary specification addresses interference, logical tampering and bypass, and whether the TOE summary specification is consistent with other narrative descriptions of the TOE. the ST. The developer shall provide a TOE summary specification. The TOE summary specification shall describe how the TOE meets each SFR. The TOE summary specification shall describe how the TOE protects itself against interference and logical tampering. The TOE summary specification shall describe how the TOE protects itself against bypass. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE summary specification to determine that it describes how the TOE meets each SFR. The evaluator determines that the TOE summary specification provides, for each SFR from the statement of security requirements, a description on how that SFR is met. The evaluator is reminded that the objective of each description is to provide potential consumers of the TOE with a high-level view of how the developer intends to satisfy each SFR and that the descriptions therefore should not be overly detailed. Often several SFRs will be implemented in one context; for instance, a password authentication mechanism may implement , and . Therefore, usually the TSS will not consist of a long list with texts for each single SFR, but complete groups of SFRs may be covered by one text passage. For a composed TOE, the evaluator also determines that it is clear which component provides each SFR or how the components combine to meet each SFR. The evaluator shall examine the TOE summary specification to determine that it describes how the TOE protects itself against interference and logical tampering. The evaluator is reminded that the objective of each description is to provide potential consumers of the TOE with a high-level view of how the developer intends to provide protection against interference and logical tampering and that the descriptions therefore should not be overly detailed. For a composed TOE, the evaluator also determines that it is clear which component provides the protection or how the components combine to provide protection. The evaluator shall examine the TOE summary specification to determine that it describes how the TOE protects itself against bypass. The evaluator is reminded that the objective of each description is to provide potential consumers of the TOE with a high-level view of how the developer intends to provide protection against bypass and that the descriptions therefore should not be overly detailed. For a composed TOE, the evaluator also determines that it is clear which component provides the protection or how the components combine to provide protection. The evaluator shall confirm that the TOE summary specification is consistent with the TOE overview and the TOE description. The evaluator shall examine the TOE summary specification to determine that it is consistent with the TOE overview and the TOE description. The TOE overview, TOE description, and TOE summary specification describe the TOE in a narrative form at increasing levels of detail. These descriptions therefore need to be consistent. The class "Tests" encompasses five families: , , (i.e. functional testing performed by evaluators), and . Testing provides assurance that the TSF behaves as described (in the functional specification, TOE design, implementation representation, and allows straightforward traceability of SFR in test scenario). The emphasis in this class is on confirmation that the TSF operates according to its design descriptions. This class does not address penetration testing, which is based upon an analysis of the TSF that specifically seeks to identify vulnerabilities in the design and implementation of the TSF. Penetration testing is addressed separately as an aspect of vulnerability assessment in the class. The class separates testing into developer testing and evaluator testing. The , and families address the completeness of developer testing. addresses the rigour with which the functional specification is tested; addresses whether testing against other design descriptions (security architecture, TOE design, and implementation representation) is required. addresses the performing of the tests by the developer and how this testing should be documented. Finally, then addresses evaluator testing: whether the evaluator should repeat part or all of the developer testing and how much independent testing the evaluator should do. determines whether the composite product as a whole exhibits the properties necessary to satisfy the functional requirements of its ST. The goal of this activity is to determine whether the TOE behaves as described in the ST and as specified in the evaluation evidence (described in the class). This determination is achieved through some combination of the developer's own functional testing of the TSF and independent testing the TSF by the evaluator . At the lowest level of assurance, there is no requirement for developer involvement, so the only testing is conducted by the evaluator, using the limited available information about the TOE. Additional assurance is gained as the developer becomes increasingly involved both in testing and in providing additional information about the TOE, and as the evaluator increases the independent testing activities. Testing of the TSF is conducted by the evaluator and, in most cases, by the developer. The evaluator's testing efforts consist not only of creating and running original tests, but also of assessing the adequacy of the developer's tests and re-running a subset of them. The evaluator analyses the developer's tests to determine the extent to which they are sufficient to demonstrate that TSFI (see ) perform as specified, and to understand the developer's approach to testing. Similarly, the evaluator analyses the developer's tests to determine the extent to which they are sufficient to demonstrate the internal behaviour and properties of the TSF. The evaluator also executes a subset of the developer's tests as documented to gain confidence in the developer's test results: the evaluator will use the results of this analysis as an input to independently testing a subset of the TSF. With respect to this subset, the evaluator takes a testing approach that is different from that of the developer, particularly if the developer's tests have shortcomings. To determine the adequacy of developer's test documentation or to create new tests, the evaluator needs to understand the desired expected behaviour of the TSF, both internally and as seen at the TSFI, in the context of the SFRs it is to satisfy. The evaluator may choose to divide the TSF and TSFI into subsets according to functional areas of the ST (audit subsystem, audit-related TSFI, authentication module, authentication-related TSFI, etc.) if they were not already divided in the ST, and focus on one subset of the TSF and TSFI at a time, examining the ST requirement and the relevant parts of the development and guidance documentation to gain an understanding of the way the TOE is expected to behave. This reliance upon the development documentation underscores the need for the dependencies on by and . The CC series has separated coverage and depth from functional tests to increase the flexibility when applying the components of the families. However, the requirements of the families are intended to be applied together to confirm that the TSF operates according to its specification. This tight coupling of families has led to some duplication of evaluator work units across sub-activities. These application notes are used to minimise duplication of text between sub-activities. Before the adequacy of test documentation can be accurately evaluated, or before new tests can be created, the evaluator has to understand the desired expected behaviour of a security function in the context of the requirements it is to satisfy. As mentioned earlier, the evaluator may choose to subset the TSF and TSFI according to SFRs (audit, authentication, etc.) in the ST and focus on one subset at a time. The evaluator examines each ST requirement and the relevant parts of the functional specification and guidance documentation to gain an understanding of the way the related TSFI is expected to behave. Similarly, the evaluator examines the relevant parts of the TOE design and security architecture documentation to gain an understanding of the way the related modules or subsystems of the TSF are expected to behave. With an understanding of the expected behaviour, the evaluator examines the test plan to gain an understanding of the testing approach. In most cases, the testing approach will entail a TSFI being stimulated and its responses observed. Externally-visible functionality can be tested directly; however, in cases where functionality is not visible external to the TOE (for example, testing the residual information protection functionality), other means will need to be employed. In cases where it is impractical or inadequate to test specific functionality (where it provides no externally-visible TSFI), the test plan should identify the alternate approach to verify expected behaviour. It is the evaluator's responsibility to determine the suitability of the alternate approach. However, the following should be considered when assessing the suitability of alternate approaches: an analysis of the implementation representation to determine that the required behaviour should be exhibited by the TOE is an acceptable alternate approach. This can mean a code inspection for a software TOE or perhaps a chip mask inspection for a hardware TOE. it is acceptable to use evidence of developer integration or module testing, even if the claimed assurance requirements do not include availability of lower-level descriptions of the TOE modules, e.g. Evaluation of sub-activity , or implementation . If evidence of developer integration or module testing is used in verifying the expected behaviour of a security functionality, care should be given to confirm that the testing evidence reflects the current implementation of the TOE. If the subsystems or modules have been changed since testing occurred, evidence that the changes were tracked and addressed by analysis or further testing will usually be required. It should be emphasised that supplementing the testing effort with alternate approaches should only be undertaken when both the developer and evaluator determine that there exists no other practical means to test the expected behaviour. Test pre-requisites are necessary to establish the required initial conditions for the test. They may be expressed in terms of parameters that must be set or in terms of test ordering in cases where the completion of one test establishes the necessary pre-requisites for another test. The evaluator must determine that the pre-requisites are complete and appropriate in that they will not bias the observed test results towards the expected test results. The test steps and expected results specify the actions and parameters to be applied to the TSFI as well as how the expected results should be verified and what they are. The evaluator must determine that the test steps and expected results are consistent with the descriptions of the TSFI in the functional specification. This means that each characteristic of the TSFI behaviour explicitly described in the functional specification should have tests and expected results to verify that behaviour. The overall aim of this testing activity is to determine that each subsystem, module, and TSFI has been sufficiently tested against the behavioural claims in the functional specification, TOE design, and architecture description. At the higher assurance levels, testing also includes bounds testing and negative testing. The test procedures will provide insight as to how the TSFIs, modules, and subsystems have been exercised by the developer during testing. The evaluator uses this information when developing additional tests to independently test the TSF. The composite-specific work units defined here are intended to be integrated as refinements to the evaluation activities of the class listed in the following table. The other activities of the class do not require composite-specific work units. Assurance family Evaluation activity Evaluation work unit Composite-specific work unit If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable. The aim of this family is to determine whether the composite product as a whole exhibits the properties necessary to satisfy the functional requirements of its composite product ST. This family contains only one component. A composite product can be tested by testing its components separately and by testing the integrated product. Separate testing means that its base component and its dependent component are being tested independently of each other. A lot of tests of the base component may have been performed within the scope of its accomplished evaluation. The dependent component may be tested on a simulator or an emulator, which represent a virtual machine. Integration testing means that the composite product is being tested as it is: the dependent component is running together with the related base component. Some dependent component functionality testing can only be performed on emulators, before its embedding/integration onto the base component, as effectiveness of this testing may not be visible using the interfaces of the composite product. Nevertheless, functional testing of the composite product shall be performed also on composite product samples according to the description of the security functions of the composite product and using the standard approach as required by the relevant assurance class. No additional developer's action is required here. Since the amount, the coverage and the depth of the functional tests of the base component have already been validated by the base component evaluation, it is not necessary to re-perform these tasks in the composite evaluation. Please note that the ETR for composite evaluation does not provide any information on functional testing for the base component. The behaviour of implementation of some SFRs can depend on properties of the base component as well as on the dependent component (e.g. correctness of the measures of the composite product to withstand a side channel attack or correctness of the implementation of tamper resistance against physical attacks). In such case the SFR implementation shall be tested on the final composite product, but not on a simulator or an emulator. This family focuses exclusively on testing of the composite product as a whole and represents merely partial efforts within the general test approach being covered by the assurance class . These integration tests shall be specified and performed, whereby the approach of the standard assurance families of the class shall be applied. The composite product evaluation sponsor shall ensure that the following is available for the composite product evaluator: composite product samples suitable for testing. The aim of this activity is to determine whether the composite product as a whole exhibits the properties necessary to satisfy the functional requirements of its composite product Security Target. A composite product can be tested by testing its components separately and by testing the integrated product. Separate testing means that its base component and the dependent component are being tested independently of each other. A lot of tests of the base component may have been performed within the scope of its accomplished evaluation. The dependent component may be tested on a simulator or an emulator, which represent a virtual machine. Integration testing means that the composite product is being tested as it is: the dependent component is running together with the related base component. Some dependent component functionality testing can only be performed on emulators, before its embedding/integration into the base component, as effectiveness of this testing may not be visible using the interfaces of the composite product. Nevertheless, functional testing of the composite product shall be performed also on composite product samples according to the description of the security functions of the composite product and using the standard approach as required by the relevant assurance class. No additional developer's action is required here. Since the amount, the coverage and the depth of the functional tests of the base component have already been validated by the base component evaluation, it is not necessary to re-perform these tasks in the composite evaluation. Please note that the ETR for composite evaluation does not provide any information on functional testing for the base component. The behaviour of implementation of some SFRs can depend on properties of the base component as well as of the dependent component (e.g. correctness of the measures of the composite product to withstand a side channel attack or correctness of the implementation of tamper resistance against physical attacks). In such case the SFR implementation shall be tested on the final composite product, but not on a simulator or an emulator. This activity focuses exclusively on testing of the composite product as a whole and represents merely partial efforts within the general test approach being covered by the assurance class . These integration tests shall be specified and performed, whereby the approach of the standard assurance families of the class shall be applied. The correct behaviour of the base component-TSF being relevant for the composite product Security Target (corresponding to the group RP_SFR-SERV and RP_SFR-MECH in the work unit ), and absence of exploitable vulnerabilities (sufficient effectiveness) in the context of the base component Security Target, are confirmed by the validity of the base component evaluation (i.e. acceptance of the base component evaluation by the report of the base component evaluation). The composite product evaluation sponsor shall ensure that the following is available for the composite product evaluator: composite product samples suitable for testing. The developer shall provide a set of tests as required by the assurance package chosen. The developer shall provide the composite product for testing. Content and presentation of the specification and documentation of the integration tests shall correspond to the standard requirements of the assurance families and . The composite product provided shall be suitable for testing. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine that the developer performed the integration tests for all SFRs having to be tested for the composite product as a whole. In order to perform this work unit the evaluator shall analyse, for each SFR, whether it directly depends on security properties of the base component and of the dependent component. Then the evaluator shall verify that the integration tests performed by the developer cover at least all such SFRs. If the assurance package chosen does not contain the families and (e.g. EAL1), this work unit is not applicable. The result of this work unit shall be integrated to the result of / and / (or the equivalent higher components if a higher assurance level is selected). This family establishes that the TSF has been tested against its functional specification. This is achieved through an examination of developer evidence of correspondence. The components in this family are levelled on the basis of specification. The objective of this sub-activity is to determine whether the developer has tested the TSFIs, and that the developer's test coverage evidence shows correspondence between the tests identified in the test documentation and the TSFIs described in the functional specification. The coverage analysis provided by the developer is required to show the correspondence between the tests provided as evaluation evidence and the functional specification. However, the coverage analysis need not demonstrate that all TSFI have been tested, or that all externally-visible interfaces to the TOE have been tested. Such shortcomings are considered by the evaluator during the independent testing sub-activity. the ST; the functional specification; the test documentation; the test coverage evidence. The developer shall provide evidence of the test coverage. The evidence of the test coverage shall show the correspondence between the tests in the test documentation and the TSFIs in the functional specification. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the test coverage evidence to determine that the correspondence between the tests identified in the test documentation and the TSFIs described in the functional specification is accurate. Correspondence may take the form of a table or matrix. The coverage evidence required for this component will reveal the extent of coverage, rather than to show complete coverage. In cases where coverage is shown to be poor the evaluator should increase the level of independent testing to compensate. The objective of this sub-activity is to determine whether the developer has tested all of the TSFIs, and that the developer's test coverage evidence shows correspondence between the tests identified in the test documentation and the TSFIs described in the functional specification. the ST; the functional specification; the test documentation; the test coverage analysis. The developer shall provide an analysis of the test coverage. The analysis of the test coverage shall demonstrate the correspondence between the tests in the test documentation and the TSFIs in the functional specification. The analysis of the test coverage shall demonstrate that all TSFIs in the functional specification have been tested. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the test coverage analysis to determine that the correspondence between the tests in the test documentation and the interfaces in the functional specification is accurate. A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the interfaces presented in the test coverage analysis has to be unambiguous. The evaluator is reminded that this does not imply that all tests in the test documentation must map to interfaces in the functional specification. The evaluator shall examine the test plan to determine that the testing approach for each interface demonstrates the expected behaviour of that interface. Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. The evaluator shall examine the test procedures to determine that the test prerequisites, test steps and expected result(s) adequately test each interface. Guidance on this work units, as it pertains to the functional specification, can be found in: 15.2.3, Verifying the adequacy of tests. The evaluator shall examine the test coverage analysis to determine that the correspondence between the interfaces in the functional specification and the tests in the test documentation is complete. All TSFIs that are described in the functional specification have to be present in the test coverage analysis and mapped to tests in order for completeness to be claimed, although exhaustive specification testing of interfaces is not required. Incomplete coverage would be evident if an interface was identified in the functional specification and no test was mapped to it. The evaluator is reminded that this does not imply that all tests in the test documentation must map to interfaces in the functional specification. The objective of this sub-activity is to determine whether the developer has tested all of the TSFIs exhaustively, and that the developer's test coverage evidence shows correspondence between the tests identified in the test documentation and the TSFIs described in the functional specification. A particular objective of this component is to confirm that all parameters of all of the TSFIs have been tested. the ST; the functional specification; the test documentation; the test coverage analysis. The developer shall provide an analysis of the test coverage. The analysis of the test coverage shall demonstrate the correspondence between the tests in the test documentation and the TSFIs in the functional specification. The analysis of the test coverage shall demonstrate that all TSFIs in the functional specification have been completely tested. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the test coverage analysis to determine that the correspondence between the tests in the test documentation and the interfaces in the functional specification is accurate. A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the interfaces presented in the test coverage analysis has to be unambiguous. The evaluator is reminded that this does not imply that all tests in the test documentation must map to interfaces in the functional specification. The evaluator shall examine the test plan to determine that the testing approach for each interface demonstrates the expected behaviour of that interface. Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. The evaluator shall examine the test procedures to determine that the test prerequisites, test steps and expected result(s) adequately test each interface. Guidance on this work unit, as it pertains to the functional specification, can be found in: 15.2.3 Verifying the adequacy of tests. The evaluator shall examine the test coverage analysis to determine that the correspondence between the interfaces in the functional specification and the tests in the test documentation is complete. All TSFIs that are described in the functional specification have to be present in the test coverage analysis and mapped to tests in order for completeness to be claimed. Exhaustive specification testing of interfaces is required for this mapping. Incomplete coverage would be evident if an interface was identified in the functional specification and no test was mapped to it. The evaluator is reminded that this does not imply that all tests in the test documentation must map to interfaces in the functional specification. The evaluator shall examine the test coverage analysis to determine that the correspondence between the interfaces in the functional specification and the tests in the test documentation shows that all TSFIs were tested completely. This means that the evaluator examines whether all aspects of purpose, method of use, parameters, parameter descriptions, actions and error messages for all TSFIs present in the functional specification are covered by the tests. Note that the level of detail present in the functional specification depends on the component of chosen in the ST of the TOE. The evaluator may conclude that the higher-level descriptions in the functional specification, like purpose or method of use, are implicitly covered, if coverage of lower-level descriptions like parameters, parameter descriptions, actions and error messages are covered. Therefore, in general it will only be necessary to confirm coverage on these lower levels. The evaluator is reminded that (for example) coverage of all parameters does not necessarily mean coverage of every possible value a parameter may allow. However, every value for which a distinct qualitative behaviour of the TOE is expected, needs to be covered. As an example: If one of the parameters of a function call is a two-byte value, which specifies the length of further parameters, only some typical values need to be tested. However, the evaluator will make sure that some specific cases (like the value zero or the maximal value) will be covered. If the evaluator sees that a potential attacker might be able to invoke a TSFI with inconsistent parameter values (e. g. if one parameter specifies the length of a second parameter and it is possible to make the second parameter actually longer than the chosen value for the first parameter suggests) and this case is not covered by the developer's testing, the evaluator may decide either to test this during their activities in or to require the developer to provide coverage also for this case. Similar considerations as for parameters hold for error messages specified in the functional specification: Each error message, which belongs to a qualitatively distinct error case, needs to be covered by testing. Note, that there may be exceptions, for example error messages for errors, which cannot be provoked during testing. For such error messages other ways of coverage need to be found as discussed in 15.2.2, "Testing vs. alternate approaches to verify the expected behaviour of functionality". Note that also the developer is allowed to use such alternative approaches to testing (e. g. checking something in the source code) in the coverage table. The evaluator has to examine, in this case, if this use of an alternative approach is acceptable (usually only in cases where testing is practically impossible). The components in this family deal with the level of detail to which the TSF is tested by the developer. Testing of the TSF is based upon increasing depth of information derived from additional design representations and descriptions (TOE design, implementation representation, and security architecture description). The objective is to counter the risk of missing an error in the development of the TOE. Testing that exercises specific internal interfaces can provide assurance not only that the TSF exhibits the desired external security behaviour, but also that this behaviour stems from correctly operating internal functionality. The components in this family are levelled on the basis of increasing detail provided in the TSF representations, from the TOE design to the implementation representation. This levelling reflects the TSF representations presented in the class. The TOE design describes the internal components (e.g. subsystems) and, perhaps, modules of the TSF, together with a description of the interfaces among these components and modules. Evidence of testing of this TOE design must show that the internal interfaces have been exercised and seen to behave as described. This may be achieved through testing via the external interfaces of the TSF, or by testing of the TOE subsystem or module interfaces in isolation, perhaps employing a test harness. In cases where some aspects of an internal interface cannot be tested via the external interfaces, there should either be justification that these aspects need not be tested, or the internal interface needs to be tested directly. In the latter case the TOE design needs to be sufficiently detailed in order to facilitate direct testing. In cases where the description of the TSF's architectural soundness (in ) cites specific mechanisms, the tests performed by the developer must show that the mechanisms have been exercised and seen to behave as described. At the highest component of this family, the testing is performed not only against the TOE design, but also against the implementation representation. The objective of this sub-activity is to determine whether the developer has tested the TSF subsystems against the TOE design and the security architecture description. the ST; the functional specification; the TOE design; the security architecture description; the test documentation; the depth of testing analysis. The developer shall provide the analysis of the depth of testing. The analysis of the depth of testing shall demonstrate the correspondence between the tests in the test documentation and the TSF subsystems in the TOE design. The analysis of the depth of testing shall demonstrate that all TSF subsystems in the TOE design have been tested. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the depth of testing analysis to determine that the descriptions of the behaviour of TSF subsystems and of their interactions is included within the test documentation. This work unit verifies the content of the correspondence between the tests and the descriptions in the TOE design. In cases where the description of the TSF's architectural soundness in cites specific mechanisms, this work unit also verifies the correspondence between the tests and the descriptions of the behaviour of such mechanisms. A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the behaviour/interaction presented in the depth-of coverage analysis has to be unambiguous. When Evaluation of sub-activity is combined with a component of , which includes descriptions at the module level, e.g. evaluation of sub-activity , the level of detail needed to map the test cases to the behaviour of the subsystems may require information from the module description to be used. This is because Evaluation of sub-activity allows the description of details to be shifted from the subsystem level to the module level, or even to omit the subsystems altogether. In any case, the required level of detail in the provided reference to the tested behaviour can be defined as "the level of detail required for the description of subsystem behaviour as defined by Evaluation of sub-activity (in particular work unit )". It states that a detailed description of the behaviour typically discusses how the functionality is provided, in terms of what key data and data structures represent; what control relationships exist within a subsystem and how these elements work together to provide the SFR-enforcing behaviour. The evaluator is reminded that not all tests in the test documentation must map to a subsystem behaviour or interaction description. The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for the behaviour description demonstrates the behaviour of that subsystem as described in the TOE design. Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. When Evaluation of sub-activity is combined with a component of , which includes descriptions at the module level, e.g. Evaluation of sub-activity , the level of detail needed to map the test cases to the behaviour of the subsystems may require information from the module description to be used. This is because Evaluation of sub-activity allows the description of details to be shifted from the subsystem level to the module level, or even to omit the subsystems altogether. In any case, the required level of detail in the provided reference to the tested behaviour can be defined as "the level of detail required for the description of subsystem behaviour as defined by Evaluation of sub-activity (in particular work unit )". It states that a detailed description of the behaviour typically discusses how the functionality is provided, in terms of what key data and data structures represent; what control relationships exist within a subsystem and how these elements work together to provide the SFR-enforcing behaviour. If TSF subsystem interfaces are described, the behaviour of those subsystems may be tested directly from those interfaces. Otherwise, the behaviour of those subsystems is tested from the TSFI interfaces. Or a combination of the two may be employed. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the behaviour that is described in the TOE design. The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for the behaviour description demonstrates the interactions among subsystems as described in the TOE design. While the previous work unit addresses behaviour of subsystems, this work unit addresses the interactions among subsystems. Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. If TSF subsystem interfaces are described, the interactions with other subsystems may be tested directly from those interfaces. Otherwise, the interactions among subsystems must be inferred from the TSFI interfaces. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the interactions among subsystems that are described in the TOE design. The evaluator shall examine the test procedures to determine that all descriptions of TSF subsystem behaviour and interaction are tested. This work unit verifies the completeness of work unit . All descriptions of TSF subsystem behaviour and of interactions among TSF subsystems that are provided in the TOE design have to be tested. Incomplete depth of testing would be evident if a description of TSF subsystem behaviour or of interactions among TSF subsystems was identified in the TOE design and no tests can be attributed to it. When Evaluation of sub-activity is combined with a component of , which includes descriptions at the module level, e.g. Evaluation of sub-activity , the level of detail needed to map the test cases to the behaviour of the subsystems may require information from the module description to be used. This is because Evaluation of sub-activity allows the description of details to be shifted from the subsystem level to the module level, or even to omit the subsystems altogether. In any case, the required level of detail in the provided reference to the tested behaviour can be defined as "the level of detail required for the description of subsystem behaviour as defined by Evaluation of sub-activity (in particular work unit )". It states that a detailed description of the behaviour typically discusses how the functionality is provided, in terms of what key data and data structures represent; what control relationships exist within a subsystem and how these elements work together to provide the SFR-enforcing behaviour. The evaluator is reminded that this does not imply that all tests in the test documentation must map to the subsystem behaviour or interaction description in the TOE design. The objective of this sub-activity is to determine whether the developer has tested all the TSF subsystems and SFR-enforcing modules against the TOE design and the security architecture description. the ST; the functional specification; the TOE design; the security architecture description; the test documentation; the depth of testing analysis. The developer shall provide the analysis of the depth of testing. The analysis of the depth of testing shall demonstrate the correspondence between the tests in the test documentation and the TSF subsystems and SFR-enforcing modules in the TOE design. The analysis of the depth of testing shall demonstrate that all TSF subsystems in the TOE design have been tested. The analysis of the depth of testing shall demonstrate that the SFR-enforcing modules in the TOE design have been tested. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the depth of testing analysis to determine that descriptions of the behaviour of TSF subsystems and of their interactions are included within the test documentation. This work unit verifies the content of the correspondence between the tests and the descriptions in the TOE design. In cases where the description of the TSF's architectural soundness in cites specific mechanisms, this work unit also verifies the correspondence between the tests and the descriptions of the behaviour of such mechanisms. A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the behaviour/interaction presented in the depth-of coverage analysis has to be unambiguous. The evaluator is reminded that not all tests in the test documentation must map to a subsystem behaviour or interaction description. The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for the behaviour description demonstrates the behaviour of that subsystem as described in the TOE design. Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. If TSF subsystem interfaces are described, the behaviour of those subsystems may be tested directly from those interfaces. Otherwise, the behaviour of those subsystems is tested from the TSFI interfaces. Or a combination of the two may be employed. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the behaviour that is described in the TOE design. The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for the behaviour description demonstrates the interactions among subsystems as described in the TOE design. While the previous work unit addresses behaviour of subsystems, this work unit addresses the interactions among subsystems. Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. If TSF subsystem interfaces are described, the interactions with other subsystems may be tested directly from those interfaces. Otherwise, the interactions among subsystems must be inferred from the TSFI interfaces. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the interactions among subsystems that are described in the TOE design. The evaluator shall examine the depth of testing analysis to determine that the interfaces of SFR-enforcing modules are included within the test documentation. This work unit verifies the content of the correspondence between the tests and the descriptions in the TOE design. In cases where the description of the TSF's architectural soundness in cites specific mechanisms at the modular level, this work unit also verifies the correspondence between the tests and the descriptions of the behaviour of such mechanisms. A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the SFR-enforcing modules presented in the depth-of coverage analysis has to be unambiguous. The evaluator is reminded that not all tests in the test documentation must map to the interfaces of SFR-enforcing modules. The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for each SFR-enforcing module interface demonstrates the expected behaviour of that interface. While work unit addresses expected behaviour of subsystems, this work unit addresses expected behaviour of the SFR-enforcing module interfaces that are covered by . Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. Testing of an interface may be performed directly at that interface, or at the external interfaces, or a combination of both. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the interfaces. Specifically, the evaluator determines whether testing at the internal interfaces is necessary or whether these internal interfaces can be adequately tested (albeit implicitly) by exercising the external interfaces. This determination is left to the evaluator, as is its justification. The evaluator shall examine the test procedures to determine that all descriptions of TSF subsystem behaviour and interaction are tested. This work unit verifies the completeness of work unit . All descriptions of TSF subsystem behaviour and of interactions among TSF subsystems that are provided in the TOE design have to be tested. Incomplete depth of testing would be evident if a description of TSF subsystem behaviour or of interactions among TSF subsystems was identified in the TOE design and no tests can be attributed to it. The evaluator is reminded that this does not imply that all tests in the test documentation must map to the subsystem behaviour or interaction description in the TOE design. The evaluator shall examine the test procedures to determine that all interfaces of SFR-enforcing modules are tested. This work unit verifies the completeness of work unit . All interfaces of SFR-enforcing modules that are provided in the TOE design have to be tested. Incomplete depth of testing would be evident if any interface of any SFR-enforcing modules was identified in the TOE design and no tests can be attributed to it. The evaluator is reminded that this does not imply that all tests in the test documentation must map to an interface of an SFR-enforcing module in the TOE design. The objective of this sub-activity is to determine whether the developer has tested the all the TSF subsystems and modules against the TOE design and the security architecture description. the ST; the functional specification; the TOE design; the security architecture description; the test documentation; the depth of testing analysis. The developer shall provide the analysis of the depth of testing. The analysis of the depth of testing shall demonstrate the correspondence between the tests in the test documentation and the TSF subsystems and modules in the TOE design. The analysis of the depth of testing shall demonstrate that all TSF subsystems in the TOE design have been tested. The analysis of the depth of testing shall demonstrate that all TSF modules in the TOE design have been tested. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the depth of testing analysis to determine that descriptions of the behaviour of TSF subsystems and of their interactions are included within the test documentation. This work unit verifies the content of the correspondence between the tests and the descriptions in the TOE design. A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the behaviour/interaction presented in the depth-of coverage analysis has to be unambiguous. The evaluator is reminded that not all tests in the test documentation must map to a subsystem behaviour or interaction description. The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for the behaviour description demonstrates the behaviour of that subsystem as described in the TOE design. Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. If TSF subsystem interfaces are provided, the behaviour of those subsystems may be performed directly from those interfaces. Otherwise, the behaviour of those subsystems is tested from the TSFI interfaces. Or a combination of the two may be employed. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the behaviour that is described in the TOE design. The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for the behaviour description demonstrates the interactions among subsystems as described in the TOE design. Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. While the previous work unit addresses behaviour of subsystems, this work unit addresses the interactions among subsystems. If TSF subsystem interfaces are provided, the interactions with other subsystems may be performed directly from those interfaces. Otherwise, the interactions among subsystems must be inferred from the TSFI interfaces. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the interactions among subsystems that are described in the TOE design. The evaluator shall examine the depth of testing analysis to determine that the interfaces of TSF modules are included within the test documentation. This work unit verifies the content of the correspondence between the tests and the descriptions in the TOE design. A simple cross-table may be sufficient to show test correspondence. The identification of the tests and the behaviour/interaction presented in the depth-of coverage analysis has to be unambiguous. The evaluator is reminded that not all tests in the test documentation must map to a subsystem behaviour or interaction description. The evaluator shall examine the test plan, test prerequisites, test steps and expected result(s) to determine that the testing approach for each TSF module interface demonstrates the expected behaviour of that interface. Guidance on this work unit can be found in: 15.2.1, Understanding the expected behaviour of the TOE; 15.2.2, Testing vs. alternate approaches to verify the expected behaviour of functionality. Testing of an interface may be performed directly at that interface, or at the external interfaces, or a combination of both. Whatever strategy is used the evaluator will consider its appropriateness for adequately testing the interfaces. Specifically, the evaluator determines whether testing at the internal interfaces is necessary or whether these internal interfaces can be adequately tested (albeit implicitly) by exercising the external interfaces. This determination is left to the evaluator, as is its justification. The evaluator shall examine the test procedures to determine that all descriptions of TSF subsystem behaviour and interaction are tested. This work unit verifies the completeness of work unit . All descriptions of TSF subsystem behaviour and of interactions among TSF subsystems that are provided in the TOE design have to be tested. Incomplete depth of testing would be evident if a description of TSF subsystem behaviour or of interactions among TSF subsystems was identified in the TOE design and no tests can be attributed to it. The evaluator is reminded that this does not imply that all tests in the test documentation must map to the subsystem behaviour or interaction description in the TOE design. The evaluator shall examine the test procedures to determine that all interfaces of all TSF modules are tested. This work unit verifies the completeness of work unit . All interfaces of TSF modules that are provided in the TOE design have to be tested. Incomplete depth of testing would be evident if any interface of any TSF module was identified in the TOE design and no tests can be attributed to it. The evaluator is reminded that this does not imply that all tests in the test documentation must map to an interface of a TSF module in the TOE design. The developer shall provide the analysis of the depth of testing. The analysis of the depth of testing shall demonstrate the correspondence between the tests in the test documentation and the TSF subsystems and modules in the TOE design. The analysis of the depth of testing shall demonstrate that all TSF subsystems in the TOE design have been tested. The analysis of the depth of testing shall demonstrate that all modules in the TOE design have been tested. The analysis of the depth of testing shall demonstrate that the TSF operates in accordance with its implementation representation. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Functional testing performed by the developer provides assurance that the tests in the test documentation are performed and documented correctly. The correspondence of these tests to the design descriptions of the TSF is achieved through the and families. This family contributes to providing assurance that the likelihood of undiscovered flaws is relatively small. The families , and are used in combination to define the evidence of testing to be supplied by a developer. Independent functional testing by the evaluator is specified by . This family contains two components, the higher requiring that ordering dependencies are analysed. Procedures for performing tests are expected to provide instructions for using test programs and test suites, including the test environment, test conditions, test data parameters and values. The test procedures should also show how the test results are derived from the test inputs. Ordering dependencies are relevant when the successful execution of a particular test depends upon the existence of a particular state. For example, this can require that test A be executed immediately before test B, since the state resulting from the successful execution of test A is a prerequisite for the successful execution of test B. Thus, failure of test B can be related to a problem with the ordering dependencies. In the above example, test B can fail because test C (rather than test A) was executed immediately before it, or the failure of test B can be related to a failure of test A. The objective of this sub-activity is to determine whether the developer correctly performed and documented the tests in the test documentation. The extent to which the test documentation is required to cover the TSF is dependent upon the coverage assurance component. For the developer tests provided, the evaluator determines whether the tests are repeatable, and the extent to which the developer's tests can be used for the evaluator's independent testing effort. Any TSFI for which the developer's test results indicate that it might not perform as specified should be tested independently by the evaluator to determine whether or not it does. the ST; the functional specification; the test documentation. The developer shall test the TSF and document the results. The developer shall provide test documentation. The test documentation shall consist of test plans, expected test results and actual test results. The test plans shall identify the tests to be performed and describe the scenarios for performing each test. These scenarios shall include any ordering dependencies on the results of other tests. The expected test results shall show the anticipated outputs from a successful execution of the tests. The actual test results shall be consistent with the expected test results. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the test documentation includes test plans, expected test results and actual test results. The evaluator checks that test plans, expected tests results and actual test results are included in the test documentation. The evaluator shall examine the test plan to determine that it describes the scenarios for performing each test. The evaluator determines that the test plan provides information about the test configuration being used: both on the configuration of the TOE and on any test equipment being used. This information should be detailed enough to ensure that the test configuration is reproducible. The evaluator also determines that the test plan provides information about how to execute the test: any necessary automated set-up procedures (and whether they require privilege to run), inputs to be applied, how these inputs are applied, how output is obtained, any automated clean-up procedures (and whether they require privilege to run), etc. This information should be detailed enough to ensure that the test is reproducible. The evaluator may wish to employ a sampling strategy when performing this work unit. The evaluator shall examine the test plan to determine that the TOE test configuration is consistent with the ST. The TOE referred to in the developer's test plan should have the same unique reference as established by the sub-activities and identified in the ST introduction. It is possible for the ST to specify more than one configuration for evaluation. The evaluator verifies that all test configurations identified in the developer test documentation are consistent with the ST. For example, the ST can define configuration options that must be set, which can have an impact upon what constitutes the TOE by including or excluding additional portions. The evaluator verifies that all such variations of the TOE are considered. The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. The evaluator may wish to employ a sampling strategy when performing this work unit. If this work unit is applied to a component TOE that can be used/integrated in a composed TOE (see ), the following will apply. In the instances that the component TOE under evaluation depends on other components in the operational environment to support their operation, the developer may wish to consider using the other component(s) that will be used in the composed TOE to fulfil the requirements of the operational environment as one of the test configurations. This will reduce the amount an additional testing that will be required for the composed TOE evaluation. The evaluator shall examine the test plans to determine that sufficient instructions are provided for any ordering dependencies. Some steps may have to be performed to establish initial conditions. For example, user accounts need to be added before they can be deleted. An example of ordering dependencies on the results of other tests is the need to perform actions in a test that will result in the generation of audit records, before performing a test to consider the searching and sorting of those audit records. Another example of an ordering dependency would be where one test case generates a file of data to be used as input for another test case. The evaluator may wish to employ a sampling strategy when performing this work unit. The evaluator shall examine the test documentation to determine that all expected tests results are included. The expected test results are needed to determine whether or not a test has been successfully performed. Expected test results are sufficient if they are unambiguous and consistent with expected behaviour given the testing approach. The evaluator may wish to employ a sampling strategy when performing this work unit. The evaluator shall check that the actual test results in the test documentation are consistent with the expected test results in the test documentation. A comparison of the actual and expected test results provided by the developer will reveal any inconsistencies between the results. It may be that a direct comparison of actual results cannot be made until some data reduction or synthesis has been first performed. In such cases, the developer's test documentation should describe the process to reduce or synthesise the actual data. For example, the developer may need to test the contents of a message buffer after a network connection has occurred to determine the contents of the buffer. The message buffer will contain a binary number. This binary number would have to be converted to another form of data representation in order to make the test more meaningful. The conversion of this binary representation of data into a higher-level representation will have to be described by the developer in enough detail to allow an evaluator to perform the conversion process. It should be noted that the description of the process used to reduce or synthesise the actual data is used by the evaluator not to actually perform the necessary modification but to assess whether this process is correct. It is up to the developer to transform the expected test results into a format that allows an easy comparison with the actual test results. The evaluator may wish to employ a sampling strategy when performing this work unit. The evaluator shall report the developer testing effort, outlining the testing approach, configuration, depth and results. The developer testing information recorded in the ETR allows the evaluator to convey the overall testing approach and effort expended on the testing of the TOE by the developer. The intent of providing this information is to give a meaningful overview of the developer testing effort. It is not intended that the information regarding developer testing in the ETR be an exact reproduction of specific test steps or results of individual tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the developer's testing approach, amount of testing performed, TOE test configurations, and the overall results of the developer testing. Information that would typically be found in the ETR subclause regarding the developer testing effort is: TOE test configurations. The particular configurations of the TOE that were tested, including whether any privileged code was required to set up the test or clean up afterwards; testing approach. An account of the overall developer testing strategy employed; testing results. A description of the overall developer testing results. This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the developer testing effort. The objective of this sub-activity is to determine whether the developer correctly performed and documented the tests in the test documentation and to ensure that testing is structured such as to avoid circular arguments about the correctness of the interfaces being tested. Although the test procedures may state pre-requisite initial test conditions in terms of ordering of tests, they may not provide a rationale for the ordering. An analysis of test ordering, which provides this rationale, is an important factor in determining the adequacy of testing, as there is a possibility of faults being concealed by the ordering of tests. the ST; the functional specification; the test documentation. The developer shall test the TSF and document the results. The developer shall provide test documentation. The test documentation shall consist of test plans, expected test results and actual test results. The test plans shall identify the tests to be performed and describe the scenarios for performing each test. These scenarios shall include any ordering dependencies on the results of other tests. The expected test results shall show the anticipated outputs from a successful execution of the tests. The actual test results shall be consistent with the expected test results. The test documentation shall include an analysis of the test procedure ordering dependencies. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall check that the test documentation includes test plans, expected test results and actual test results. The evaluator checks that test plans, expected tests results and actual test results are included in the test documentation. The evaluator shall examine the test plan to determine that it describes the scenarios for performing each test. The evaluator determines that the test plan provides information about the test configuration being used: both on the configuration of the TOE and on any test equipment being used. This information should be detailed enough to ensure that the test configuration is reproducible. The evaluator also determines that the test plan provides information about how to execute the test: any necessary automated set-up procedures (and whether they require privilege to run), inputs to be applied, how these inputs are applied, how output is obtained, any automated clean-up procedures (and whether they require privilege to run), etc. This information should be detailed enough to ensure that the test is reproducible. The evaluator may wish to employ a sampling strategy when performing this work unit. The evaluator shall examine the test plan to determine that the TOE test configuration is consistent with the ST. The TOE referred to in the developer's test plan should have the same unique reference as established by the sub-activities and identified in the ST introduction. It is possible for the ST to specify more than one configuration for evaluation. The evaluator verifies that all test configurations identified in the developer test documentation are consistent with the ST. For example, the ST can define configuration options that must be set, which can have an impact upon what constitutes the TOE by including or excluding additional portions. The evaluator verifies that all such variations of the TOE are considered. The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. The evaluator may wish to employ a sampling strategy when performing this work unit. If this work unit is applied to a component TOE that can be used/integrated in a composed TOE (see ), the following will apply. In the instances that the component TOE under evaluation depends on other components in the operational environment to support their operation, the developer may wish to consider using the other component(s) that will be used in the composed TOE to fulfil the requirements of the operational environment as one of the test configurations. This will reduce the amount an additional testing that will be required for the composed TOE evaluation. The evaluator shall examine the test plans to determine that sufficient instructions are provided for any ordering dependencies. Some steps may have to be performed to establish initial conditions. For example, user accounts need to be added before they can be deleted. An example of ordering dependencies on the results of other tests is the need to perform actions in a test that will result in the generation of audit records, before performing a test to consider the searching and sorting of those audit records. Another example of an ordering dependency would be where one test case generates a file of data to be used as input for another test case. The evaluator may wish to employ a sampling strategy when performing this work unit. The evaluator shall examine the test documentation to determine that all expected tests results are included. The expected test results are needed to determine whether or not a test has been successfully performed. Expected test results are sufficient if they are unambiguous and consistent with expected behaviour given the testing approach. The evaluator may wish to employ a sampling strategy when performing this work unit. The evaluator shall check that the actual test results in the test documentation are consistent with the expected test results in the test documentation. A comparison of the actual and expected test results provided by the developer will reveal any inconsistencies between the results. It may be that a direct comparison of actual results cannot be made until some data reduction or synthesis has been first performed. In such cases, the developer's test documentation should describe the process to reduce or synthesise the actual data. For example, the developer may need to test the contents of a message buffer after a network connection has occurred to determine the contents of the buffer. The message buffer will contain a binary number. This binary number would have to be converted to another form of data representation in order to make the test more meaningful. The conversion of this binary representation of data into a higher-level representation will have to be described by the developer in enough detail to allow an evaluator to perform the conversion process. It should be noted that the description of the process used to reduce or synthesise the actual data is used by the evaluator not to actually perform the necessary modification but to assess whether this process is correct. It is up to the developer to transform the expected test results into a format that allows an easy comparison with the actual test results. The evaluator may wish to employ a sampling strategy when performing this work unit. The evaluator shall report the developer testing effort, outlining the testing approach, configuration, depth and results. The developer testing information recorded in the ETR allows the evaluator to convey the overall testing approach and effort expended on the testing of the TOE by the developer. The intent of providing this information is to give a meaningful overview of the developer testing effort. It is not intended that the information regarding developer testing in the ETR be an exact reproduction of specific test steps or results of individual tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the developer's testing approach, amount of testing performed, TOE test configurations, and the overall results of the developer testing. Information that would typically be found in the ETR section regarding the developer testing effort is: TOE test configurations: The particular configurations of the TOE that were tested, including whether any privileged code was required to set up the test or clean up afterwards; testing approach: An account of the overall developer testing strategy employed; testing results: A description of the overall developer testing results. This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the developer testing effort. The evaluator shall examine the analysis of the test procedure ordering dependencies to determine that a sufficient justification for the chosen ordering of test cases is given. Usually the evaluator will generate a table of all cases, where the test documentation requires a certain ordering of the tests and will then examine if sufficient justification is given in any case, why testing in this ordering is adequate and sufficient. As an example we assume that the TSF provide a random number generator, which needs to be initialised (for example with an adequate seed) before random numbers of a specified quality can be generated. In this case the evaluator will consider the following question: Does the test documentation only describe an ordering of tests, where the initialisation is done before calling the function to generate a random number? In this case the justification needs to show, why the developer expects that in the intended environment of the TOE the random number function will not be called without initialisation of the random number generator. If for example the user guidance documentation includes a clear instruction that the random number generator needs to be initialised adequately before being called, this may be considered adequate as a justification. Note that the question of whether it can be plausibly assumed that users will follow such instruction is covered by the evaluation activities for the classes and and needs not to be re-examined here. If, on the other hand, the TOE provides an authentication protocol, which implicitly uses random numbers provided by the random number generator, and an attacker can therefore "call" the random number generator implicitly by simply trying to authenticate, and if neither the TOE nor the environment prevent an attacker from doing this even before the random number generator is initialised, a test case needs to show, what happens in such situation. If, for example, instead of returning a "bad" random number, the random number function would return an error, when called without proper initialisation, it would be much better to include a test showing this secure behaviour instead of trying to justify why the functions are only tested in the usual order. Even without an evaluator would be expected to look for potential vulnerabilities like the one described above. However, adds assurance by requiring the developer to give a systematic justification, why their chosen order of test cases doesn't hide such potential failures of security functions. The objectives of this family are built upon the assurances achieved in the , , and families by verifying the developer testing and performing additional tests by the evaluator. Levelling is based upon the amount of developer test documentation and test support and the amount of evaluator testing. This family deals with the degree to which there is independent functional testing of the TSF. Independent functional testing may take the form of repeating the developer's functional tests (in whole or in part) or of extending the scope or the depth of the developer's tests. These activities are complementary, and an appropriate mix must be planned for each TOE, which takes into account the availability and coverage of test results, and the functional complexity of the TSF. Sampling of developer tests is intended to provide confirmation that the developer has carried out his planned test programme on the TSF and has correctly recorded the results. The size of sample selected will be influenced by the detail and quality of the developer's functional test results. The evaluator will also need to consider the scope for devising additional tests, and the relative benefit that may be gained from effort in these two areas. It is recognized that repetition of all developer tests may be feasible and desirable in some cases, but may be very arduous and less productive in others. The highest component in this family should therefore be used with caution. Sampling will address the whole range of test results available, including those supplied to meet the requirements of both and . There is also a need to consider the different configurations of the TOE that are included within the evaluation. The evaluator will need to assess the applicability of the results provided, and to plan his own testing accordingly. The suitability of the TOE for testing is based on the access to the TOE, and the supporting documentation and information required (including any test software or tools) to run tests. The need for such support is addressed by the dependencies to other assurance families. Additionally, suitability of the TOE for testing may be based on other considerations. For example, the version of the TOE submitted by the developer may not be the final version. The term interfaces refers to interfaces described in the functional specification and TOE design, and parameters passed through invocations identified in the implementation representation. The exact set of interfaces to be used is selected through and the components. References to a subset of the interfaces are intended to allow the evaluator to design an appropriate set of tests which is consistent with the objectives of the evaluation being conducted. The goal of this activity is to determine, by independently testing a subset of the TSFI, whether the TOE behaves as specified in the functional specification and guidance documentation. the ST; the functional specification; the operational user guidance; the preparative user guidance; the TOE suitable for testing. The developer shall provide the TOE for testing. The TOE shall be suitable for testing. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. The TOE provided by the developer should have the same unique reference as established by the sub-activities and identified in the ST introduction. It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST. The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly. The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state. It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the Evaluation of sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only. If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed can satisfy work unit . The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. The evaluator shall devise a test subset. The evaluator selects a test subset and testing strategy that is appropriate for the TOE. One extreme testing strategy would be to have the test subset contain as many interfaces as possible tested with little rigour. Another testing strategy would be to have the test subset contain a few interfaces based on their perceived relevance and rigorously test these interfaces. Typically, the testing approach taken by the evaluator should fall somewhere between these two extremes. The evaluator should exercise most of the interfaces using at least one test, but testing need not demonstrate exhaustive specification testing. The evaluator, when selecting the subset of the interfaces to be tested, should consider the following factors: The number of interfaces from which to draw upon for the test subset. Where the TSF includes only a small number of relatively simple interfaces, it may be practical to rigorously test all of the interfaces. In other cases this may not be cost-effective, and sampling is required. Maintaining a balance of evaluation activities. The evaluator effort expended on the test activity should be commensurate with that expended on any other evaluation activity. The evaluator selects the interfaces to compose the subset. This selection will depend on a number of factors, and consideration of these factors may also influence the choice of test subset size: Significance of interfaces. Those interfaces more significant than others should be included in the test subset. One major factor of "significance" is the security-relevance (SFR-enforcing interfaces would be more significant than SFR-supporting interfaces, which are more significant than SFR-non-interfering interfaces; see ). The other major factor of "significance" is the number of SFRs mapping to this interface (as determined when identifying the correspondence between levels of abstraction in ). Complexity of the interface. Complex interfaces may require complex tests that impose onerous requirements on the developer or evaluator, which may not be conducive to cost-effective evaluations. Conversely, they are a likely area to find errors and are good candidates for the subset. The evaluator will need to strike a balance between these considerations. Implicit testing. Testing some interfaces may often implicitly test other interfaces, and their inclusion in the subset may maximise the number of interfaces tested (albeit implicitly). Certain interfaces will typically be used to provide a variety of security functionality, and will tend to be the target of an effective testing approach. Types of interfaces (e.g. programmatic, command-line, protocol). The evaluator should consider including tests for all different types of interfaces that the TOE supports. Interfaces that give rise to features that are innovative or unusual. Where the TOE contains innovative or unusual features, which may feature strongly in marketing literature and guidance documents, the corresponding interfaces should be strong candidates for testing. This guidance articulates factors to consider during the selection process of an appropriate test subset, but these are by no means exhaustive. The evaluator shall produce test documentation for the test subset that is sufficiently detailed to enable the tests to be reproducible. With an understanding of the expected behaviour of the TSF, from the ST and the functional specification, the evaluator has to determine the most feasible way to test the interface. Specifically, the evaluator considers: the approach that will be used, for instance, whether an external interface will be tested, or an internal interface using a test harness, or will an alternate test approach be employed (e.g. in exceptional circumstances, a code inspection, if the implementation representation is available); the interface(s) that will be used to test and observe responses; the initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have); special test equipment that will be required to either stimulate an interface (e.g. packet generators) or make observations of an interface (e.g. network analysers). The evaluator may find it practical to test each interface using a series of test cases, where each test case will test a very specific aspect of expected behaviour. The evaluator's test documentation should specify the derivation of each test, tracing it back to the relevant interface(s). The evaluator shall conduct testing. The evaluator uses the test documentation developed as a basis for executing tests on the TOE. The test documentation is used as a basis for testing but this does not preclude the evaluator from performing additional ad hoc tests. The evaluator may devise new tests based on behaviour of the TOE discovered during testing. These new tests are recorded in the test documentation. The evaluator shall record the following information about the tests that compose the test subset: identification of the interface behaviour to be tested; instructions to connect and setup all required test equipment as required to conduct the test; instructions to establish all prerequisite test conditions; instructions to stimulate the interface; instructions for observing the behaviour of the interface; descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results; instructions to conclude the test and establish the necessary post-test state for the TOE; actual test results. The level of detail should be such that another evaluator can repeat the tests and obtain an equivalent result. While some specific details of the test results may be different (e.g. time and date fields in an audit record) the overall result should be identical. There may be instances when it is unnecessary to provide all the information presented in this work unit (e.g. the actual test results of a test may not require any analysis before a comparison between the expected results can be made). The determination to omit this information is left to the evaluator, as is the justification. The evaluator shall check that all actual test results are consistent with the expected test results. Any differences in the actual and expected test results may indicate that the TOE does not perform as specified or that the evaluator test documentation may be incorrect. Unexpected actual results may require corrective maintenance to the TOE or test documentation and perhaps require re-running of impacted tests and modifying the test sample size and composition. This determination is left to the evaluator, as is its justification. The evaluator shall report in the ETR the evaluator testing effort, outlining the testing approach, configuration, depth and results. The evaluator testing information reported in the ETR allows the evaluator to convey the overall testing approach and effort expended on the testing activity during the evaluation. The intent of providing this information is to give a meaningful overview of the testing effort. It is not intended that the information regarding testing in the ETR be an exact reproduction of specific test instructions or results of individual tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the testing approach chosen, amount of testing performed, TOE test configurations, and the overall results of the testing activity. Information that would typically be found in the ETR subclause regarding the evaluator testing effort is: TOE test configurations. The particular configurations of the TOE that were tested; subset size chosen. The amount of interfaces that were tested during the evaluation and a justification for the size; selection criteria for the interfaces that compose the subset. Brief statements about the factors considered when selecting interfaces for inclusion in the subset; interfaces tested. A brief listing of the interfaces that merited inclusion in the subset; verdict for the activity. The overall judgement on the results of testing during the evaluation. This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the testing the evaluator performed during the evaluation. The goal of this activity is to determine, by independently testing a subset of the TSF, whether the TOE behaves as specified in the design documentation, and to gain confidence in the developer's test results by performing a sample of the developer's tests. the ST; the functional specification; the TOE design description; the operational user guidance; the preparative user guidance; the configuration management documentation; the test documentation; the TOE suitable for testing. The developer shall provide the TOE for testing. The TOE shall be suitable for testing. The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. The TOE provided by the developer and identified in the test plan should have the same unique reference as established by the sub-activities and identified in the ST introduction. It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST. The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly. The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state. It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the Evaluation of sub-activity sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only. If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed can satisfy work unit . The evaluator shall examine the set of resources provided by the developer to determine that they are equivalent to the set of resources used by the developer to functionally test the TSF. The set of resource used by the developer is documented in the developer test plan, as considered in the family. The resource set may include access to the relevant developer test environment, and special test equipment, among others. Resources that are not identical to those used by the developer need to be equivalent in terms of any impact they may have on test results. The evaluator shall execute a sample of tests in the test documentation to verify the developer test results. The evaluator shall conduct testing using a sample of tests found in the developer test plan and procedures. The overall aim of this work unit is to perform a sufficient number of the developer tests to confirm the validity of the developer's test results. The evaluator has to decide on the size of the sample, and the developer tests that will compose the sample (see A.2). All the developer tests can be traced back to specific interfaces. Therefore, the factors to consider in the selection of the tests to compose the sample are similar to those listed for subset selection in work-unit . Additionally, the evaluator may wish to employ a random sampling method to select developer tests to include in the sample. The evaluator shall check that all the actual test results are consistent with the expected test results. Inconsistencies between the developer's expected test results and actual test results will compel the evaluator to resolve the discrepancies. Inconsistencies encountered by the evaluator can be resolved by a valid explanation and resolution of the inconsistencies by the developer. If a satisfactory explanation or resolution cannot be reached, the evaluator's confidence in the developer's test results may be lessened and it may be necessary for the evaluator to increase the sample size to the extent that the subset identified in work unit is adequately tested: deficiencies with the developer's tests need to result in either corrective action to the TOE by the developer (e.g., if the inconsistency is caused by incorrect behaviour) or to the developer's tests (e.g., if the inconsistency is caused by an incorrect test), or in the production of new tests by the evaluator. The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. The evaluator shall devise a test subset. The evaluator selects a test subset and testing strategy that is appropriate for the TOE. One extreme testing strategy would be to have the test subset contain as many interfaces as possible tested with little rigour. Another testing strategy would be to have the test subset contain a few interfaces based on their perceived relevance and rigorously test these interfaces. Typically, the testing approach taken by the evaluator should fall somewhere between these two extremes. The evaluator should exercise most of the interfaces using at least one test, but testing need not demonstrate exhaustive specification testing. The evaluator, when selecting the subset of the interfaces to be tested, should consider the following factors: The developer test evidence. The developer test evidence consists of: the test documentation, the available test coverage analysis, and the available depth of testing analysis. The developer test evidence will provide insight as to how the TSF has been exercised by the developer during testing. The evaluator applies this information when developing new tests to independently test the TOE. Specifically, the evaluator should consider: Augmentation of developer testing for interfaces. The evaluator may wish to perform more of the same type of tests by varying parameters to more rigorously test the interface. Supplementation of developer testing strategy for interfaces. The evaluator may wish to vary the testing approach of a specific interface by testing it using another test strategy. The number of interfaces from which to draw upon for the test subset. Where the TSF includes only a small number of relatively simple interfaces, it may be practical to rigorously test all of them. In other cases, this may not be cost-effective, and sampling is required. Maintaining a balance of evaluation activities. The evaluator effort expended on the test activity should be commensurate with that expended on any other evaluation activity. The evaluator selects the interfaces to compose the subset. This selection will depend on a number of factors, and consideration of these factors may also influence the choice of test subset size: Rigour of developer testing of the interfaces. Those interfaces that the evaluator determines require additional testing should be included in the test subset. Developer test results. If the results of developer tests cause the evaluator to doubt that an interface is not properly implemented, then the evaluator should include such interfaces in the test subset. Significance of interfaces. Those interfaces more significant than others should be included in the test subset. One major factor of "significance" is the security-relevance (SFR-enforcing interfaces would be more significant than SFR-supporting interfaces, which are more significant than SFR-non-interfering interfaces; see ). The other major factor of "significance" is the number of SFRs mapping to this interface (as determined when identifying the correspondence between levels of abstraction in ). Complexity of interfaces. Interfaces that require complex implementation may require complex tests that impose onerous requirements on the developer or evaluator, which may not be conducive to cost-effective evaluations. Conversely, they are a likely area to find errors and are good candidates for the subset. The evaluator will need to strike a balance between these considerations. Implicit testing. Testing some interfaces may often implicitly test other interfaces, and their inclusion in the subset may maximise the number of interfaces tested (albeit implicitly). Certain interfaces will typically be used to provide a variety of security functionality, and will tend to be the target of an effective testing approach. Types of interfaces (e.g. programmatic, command-line, protocol). The evaluator should consider including tests for all different types of interfaces that the TOE supports. Interfaces that give rise to features that are innovative or unusual. Where the TOE contains innovative or unusual features, which may feature strongly in marketing literature and guidance documents, the corresponding interfaces should be strong candidates for testing. This guidance articulates factors to consider during the selection process of an appropriate test subset, but these are by no means exhaustive. The evaluator shall produce test documentation for the test subset that is sufficiently detailed to enable the tests to be reproducible. With an understanding of the expected behaviour of the TSF, from the ST, the functional specification, and the TOE design description, the evaluator has to determine the most feasible way to test the interface. Specifically, the evaluator considers: the approach that will be used, for instance, whether an external interface will be tested, or an internal interface using a test harness, or will an alternate test approach be employed (e.g. in exceptional circumstances, a code inspection); the interface(s) that will be used to test and observe responses; the initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have); special test equipment that will be required to either stimulate an interface (e.g. packet generators) or make observations of an interface (e.g. network analysers). The evaluator may find it practical to test each interface using a series of test cases, where each test case will test a very specific aspect of expected behaviour of that interface. The evaluator's test documentation should specify the derivation of each test, tracing it back to the relevant interface(s). The evaluator shall conduct testing. The evaluator uses the test documentation developed as a basis for executing tests on the TOE. The test documentation is used as a basis for testing, but this does not preclude the evaluator from performing additional ad hoc tests. The evaluator may devise new tests based on behaviour of the TOE discovered during testing. These new tests are recorded in the test documentation. The evaluator shall record the following information about the tests that compose the test subset: identification of the interface behaviour to be tested; instructions to connect and setup all required test equipment as required to conduct the test; instructions to establish all prerequisite test conditions; instructions to stimulate the interface; instructions for observing the interface; descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results; instructions to conclude the test and establish the necessary post-test state for the TOE; actual test results. The level of detail should be such that another evaluator can repeat the tests and obtain an equivalent result. While some specific details of the test results may be different (e.g. time and date fields in an audit record) the overall result should be identical. There may be instances when it is unnecessary to provide all the information presented in this work unit (e.g. the actual test results of a test may not require any analysis before a comparison between the expected results can be made). The determination to omit this information is left to the evaluator, as is the justification. The evaluator shall check that all actual test results are consistent with the expected test results. Any differences in the actual and expected test results may indicate that the TOE does not perform as specified or that the evaluator test documentation may be incorrect. Unexpected actual results may require corrective maintenance to the TOE or test documentation and perhaps require re-running of impacted tests and modifying the test sample size and composition. This determination is left to the evaluator, as is its justification. The evaluator shall report in the ETR the evaluator testing effort, outlining the testing approach, configuration, depth and results. The evaluator testing information reported in the ETR allows the evaluator to convey the overall testing approach and effort expended on the testing activity during the evaluation. The intent of providing this information is to give a meaningful overview of the testing effort. It is not intended that the information regarding testing in the ETR be an exact reproduction of specific test instructions or results of individual tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the testing approach chosen, amount of evaluator testing performed, amount of developer tests performed, TOE test configurations, and the overall results of the testing activity. Information that would typically be found in the ETR subclause regarding the evaluator testing effort is: TOE test configurations. The particular configurations of the TOE that were tested; subset size chosen. The amount of interfaces that were tested during the evaluation and a justification for the size; selection criteria for the interfaces that compose the subset. Brief statements about the factors considered when selecting interfaces for inclusion in the subset; Interfaces tested. A brief listing of the interfaces that merited inclusion in the subset; developer tests performed. The amount of developer tests performed and a brief description of the criteria used to select the tests; verdict for the activity. The overall judgement on the results of testing during the evaluation. This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the testing the evaluator performed during the evaluation. The developer shall provide the TOE for testing. The TOE shall be suitable for testing. The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall execute all tests in the test documentation to verify the developer test results. The evaluator shall test the TSF to confirm that the entire TSF operates as specified. The class addresses the possibility of exploitable vulnerabilities introduced in the development or the operation of the TOE. Generally, the vulnerability assessment activity covers various vulnerabilities in the development and operation of the TOE. Development vulnerabilities take advantage of some property of the TOE, or the product where the TOE resides, which was introduced during its development, e.g. defeating the TSF self-protection through tampering, direct attack or monitoring of the TSF, defeating the TSF domain separation through monitoring or direct attack the TSF, or defeating non-bypassability through circumventing (bypassing) the TSF. Explicit dependencies of the TOE on IT systems in the environment must also be considered. Operational vulnerabilities take advantage of weaknesses in non-technical countermeasures to violate the TOE SFRs, e.g. misuse or incorrect configuration. Misuse investigates whether the TOE can be configured or used in a manner that is insecure, but that an administrator or user of the TOE would reasonably believe to be secure. Assessment of development vulnerabilities is covered by the assurance family . Basically, all development vulnerabilities can be considered in the context of due to the fact, that this family allows application of a wide range of assessment methodologies being unspecific to the kind of an attack scenario. These unspecific assessment methodologies comprise, among other, also the specific methodologies for those TSF where covert channels are to be considered (a channel capacity estimation can be done using informal engineering measurements, as well as actual test measurements) or can be overcome by the use of sufficient resources in the form of a direct attack (underlying technical concept of those TSF is based on probabilistic or permutational mechanisms; a qualification of their security behaviour and the effort required to overcome them can be made using a quantitative or statistical analysis). If there are security objectives specified in the ST to either to prevent one user of the TOE from observing activity associated with another user of the TOE, or to ensure that information flows cannot be used to achieve enforced illicit data signals, covert channel analysis should be considered during the conduct of the vulnerability analysis. This is often reflected by the inclusion of and multilevel access control policies specified through and/or requirements in the ST. The purpose of the vulnerability assessment activity is to determine the exploitability of flaws or weaknesses in the TOE in the operational environment. This determination is based upon analysis of the evaluation evidence and a search of publicly available material by the evaluator and is supported by evaluator penetration testing. The composite-specific work units defined here are intended to be integrated as refinements to the evaluation activities of the class listed in the following table. The other activities of the class do not require composite-specific work units. Assurance family Evaluation activity Evaluation work unit Composite-specific work unit If the level of the assurance requirement chosen is higher than those identified in this table, the composite-specific work unit is also applicable. The aim of this family is to determine the exploitability of flaws or weaknesses in the composite product as a whole in the intended environment. This family contains only one component. This family focuses exclusively on the vulnerability assessment of the composite product as a whole and represents merely partial efforts within the general approach being covered by the standard i.e. as defined by CEM. assurance family of the class : . The composite product evaluator shall perform a vulnerability analysis for the composite product using, amongst other, the results of the base component evaluation. This vulnerability analysis shall be confirmed by penetration testing. The composite product evaluator shall check that the confidentiality protection of the dependent component embedded into/installed onto the base component is consistent with the confidentiality level claimed by the dependent component developer for . In special cases, the vulnerability analysis and the definition of attacks can be difficult, need considerable time and require extensive pre-testing, if only documentation is available. The base component may also be used in a way that was not foreseen by the base component developer and the base component evaluator, or the dependent component developer may not have followed the stipulations provided with the base component. Different possibilities exist to shorten composite product vulnerability analysis in such cases: E.g. the composite product evaluator may consult the base component evaluator and draw on his experience gained during the base component evaluation. Alternatively, an approach aiming on the separation of vulnerabilities of the dependent component and the base component by using specific test samples of the base component on which the composite product evaluator may load test dependent components on his own discretion. The intention hereby is to use test dependent components without countermeasures and without deactivating any base component inherent countermeasure. The results of the vulnerability assessment for the base component of the composite product represented in the ETR for composite evaluation can be re-used under the following conditions: they are up-to-date and all composite activities for correctness – , , and – are finalised with the verdict PASS. Due to composing of the base component and the dependent component a new quality arises, which may cause additional vulnerabilities of the base component which might be not mentioned in the ETR for composite evaluation. In these circumstances the composite product evaluation authority may require a re-assessment or re-evaluation of the base component focusing on the new vulnerabilities' issues. The composite product evaluation sponsor shall ensure that the following is made available for the composite product evaluator: the base component-related user guidance, the base component-related ETR for composite evaluation prepared by the base component evaluator, the report of the base component evaluation authority. The aim of this activity is to determine the exploitability of flaws or weaknesses in the composite product as a whole in the intended environment. This activity focuses exclusively on the vulnerability assessment of the composite product as a whole and represents merely partial efforts within the general approach being covered by the standard assurance family of the class : . The composite product evaluator shall perform a vulnerability analysis for the composite product using, among others, the results of the base component evaluation. This vulnerability analysis shall be confirmed by penetration testing. The composite product evaluator shall check that the confidentiality protection of the dependent component embedded into/installed onto the base component is consistent with the confidentiality level claimed by the dependent component developer for . In special cases, the vulnerability analysis and the definition of attacks can be difficult, need considerable time and require extensive pre-testing, if only documentation is available. The base component may also be used in a way that was not foreseen by the base component developer and the base component evaluator, or the dependent component developer may not have followed the (security) requirements provided with the base component and its evaluation-related documentation. Different possibilities exist to shorten composite product vulnerability analysis in such cases. For example, the composite product evaluator may consult the base component evaluator and draw on his experience gained during the base component evaluation. Alternatively, an approach aiming at the separation of vulnerabilities of the dependent component and the base component by using specific test samples of the base component on which the composite product evaluator may load test dependent components at his own discretion. The intention hereby is to use test dependent components without countermeasures and without deactivating any base component inherent countermeasure. Within the composite evaluation technique, the so-called ETR for composite evaluation and the evaluation authority report play an important role. Please refer to CC Part 1, 14.3.3.6 and 14.3.3.7 for more details, in particular concerning objective and contents of these documents and corresponding rules for their handling and usage in the framework of the composite evaluation approach. The results of the vulnerability assessment for the base component of the composite product represented in the ETR for composite evaluation can be reused under the following conditions: they are up-to-date and all composite evaluation activities for correctness – , , and – were finalised with the verdict PASS. The validity and topicality of the base component's report of the base component evaluation authority and of the ETR for composite evaluation are a prerequisite for using such documents in the composite evaluation approach and therefore shall be verified by the composite product evaluator. Due to composing of the base component and the dependent component additional vulnerabilities of the base component can occur that might be not mentioned or addressed in the ETR for composite evaluation. In these circumstances the composite product evaluation authority may require a re-assessment or re-evaluation of the base component focusing on the new vulnerabilities' issues. The composite product evaluation sponsor shall ensure that the following is made available for the composite product evaluator: the base component-related user guidance; the base component-related ETR for composite evaluation prepared by the base component evaluator; the base component's report of the base component evaluation authority. The developer shall provide the composite product for penetration testing. The composite product provided shall be suitable for testing as a whole. The evaluator shall conduct penetration testing of the composite product as a whole building on the evaluator's own vulnerability analysis to ensure that the vulnerabilities being relevant for the composite product Security Target are not exploitable. The evaluator shall examine the results of the vulnerability assessment for the base component of the composite product to determine that they can be re-used for the composite evaluation. The results of the vulnerability assessment for the base component of the composite product are usually represented in the ETR for composite evaluation. They can be re-used if the following conditions are met: they are up-to-date and all composite evaluation activities for correctness – , , and – resulted in verdicts of PASS. The validity and topicality of the base component's report of the base component evaluation authority and of the ETR for composite evaluation are a prerequisite for their re-use in the composite evaluation of the composite product and shall be verified by the composite product evaluator. It is noted that the base component itself can be a composite product. This means also that the validity and topicality of each evaluation authority report and ETR for composite evaluation of all the products / TOEs that compose the base component shall be checked. When the relevance of the ETR(s) for composite evaluation for the composite product is checked, the necessity of checking their contents depends on the dependent component of the composite product and the user available TSFI. If the base component-TSFI are available to the user of the composite product or are used by the dependent component, the contents of the ETR(s) for composite evaluation shall be checked. Otherwise, such relevance check of contents might be not necessary. The evaluator shall also consider the relevant requirements in any base component-related report of the base component evaluation authority. The result of this work unit shall be integrated to the result of / (or the equivalent higher components if a higher assurance level is selected). The evaluator shall specify, conduct and document penetration testing of the composite product as a whole, using the standard approach of the assurance family . If all correctness-related activities (, , and ) have resulted in verdicts of PASS, and the composite product's base component with its base component evaluation covers all security properties needed for the composite product, then, a composition of this base component and the dependent component may also not create additional vulnerabilities of the base component. If the evaluator determined that composing of the base component and the dependent component creates additional vulnerabilities of the base component, a contradiction to the verdict PASS for the correctness activities has to be supposed or the report of the base component evaluation authority for the base component does not cover all security properties and evaluation-related information of the base component as needed for the current composite product and its evaluation. The result of this work unit shall be integrated to the result of / , , (or the equivalent higher components if a higher assurance level is selected). Vulnerability analysis is an assessment to determine whether potential vulnerabilities identified, during the evaluation of the development and anticipated operation of the TOE or by other methods (e.g. by flaw hypotheses or quantitative or statistical analysis of the security behaviour of the underlying security mechanisms), can allow attackers to violate the SFRs. Vulnerability analysis deals with the threats that an attacker will be able to discover flaws that will allow unauthorised access to data and functionality, allow the ability to interfere with or alter the TSF, or interfere with the authorized capabilities of other users. In case of a multi-assurance evaluation the vulnerability analysis shall assess the defined sub-TSF as well as the TOE as a whole. Levelling is based on an increasing rigour of vulnerability analysis by the evaluator and increased levels of attack potential required by an attacker to identify and exploit the potential vulnerabilities. The objective of this sub-activity is to determine whether the TOE, in its operational environment, has easily identifiable exploitable vulnerabilities. The evaluator should consider performing additional tests as a result of potential vulnerabilities encountered during the conduct of other parts of the evaluation. The use of the term guidance in this sub-activity refers to the operational guidance and the preparative guidance. Potential vulnerabilities may be in information that is publicly available, or not, and may require skill to exploit, or not. These two aspects are related, but are distinct. It should not be assumed that, simply because a potential vulnerability is identifiable from information that is publicly available, it can be easily exploited. the ST; the guidance documentation; the TOE suitable for testing; information publicly available to support the identification of potential vulnerabilities. Other input for this sub-activity is: current information regarding potential vulnerabilities (e.g. from an evaluation authority). The developer shall provide the TOE for testing. The TOE shall be suitable for testing. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. The TOE provided by the developer and identified in the test plan should have the same unique reference as established by the sub-activities and identified in the ST introduction. It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST. The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly. The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the Evaluation of sub-activity sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only. If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed can satisfy work unit . The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE. The evaluator shall examine sources of information publicly available to identify potential vulnerabilities in the TOE. The evaluator examines the sources of information publicly available to support the identification of possible potential vulnerabilities in the TOE. There are many sources of publicly available information, which should be considered, e.g. mailing lists and security forums on the world wide web that report known vulnerabilities in specified technologies. The evaluator should not constrain their consideration of publicly available information to the above but should consider any other relevant information available. While examining the evidence provided the evaluator will use the information in the public domain to further search for potential vulnerabilities. Where the evaluators have identified areas of concern, the evaluator should consider information publicly available that relate to those areas of concern. The availability of information that may be readily available to an attacker that helps to identify and facilitate attacks effectively operates to substantially enhance the attack potential of a given attacker. The accessibility of vulnerability information and sophisticated attack tools on the Internet makes it more likely that this information will be used in attempts to identify potential vulnerabilities in the TOE and exploit them. Modern search tools make such information easily available to the evaluator, and the determination of resistance to published potential vulnerabilities and well-known generic attacks can be achieved in a cost-effective manner. The search of the information publicly available should be focused on those sources that refer specifically to the product from which the TOE is derived. The extensiveness of this search should consider the following factors: TOE type, evaluator experience in this TOE type, expected attack potential and the level of evidence available. The identification process is iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation. The evaluator will report what actions were taken to identify potential vulnerabilities in the information publicly available. However, in this type of search, the evaluator may not be able to describe the steps in identifying potential vulnerabilities before the outset of the examination, as the approach may evolve as a result of findings during the search. The evaluator will report the evidence examined in completing the search for potential vulnerabilities. The evaluator shall record in the ETR the identified potential vulnerabilities that are candidates for testing and applicable to the TOE in its operational environment. It may be identified that no further consideration of the potential vulnerability is required if for example the evaluator identifies that measures in the operational environment, either IT or non-IT, prevent exploitation of the potential vulnerability in that operational environment. For instance, restricting physical access to the TOE to authorized users only may effectively render a potential vulnerability to tampering unexploitable. The evaluator records any reasons for exclusion of potential vulnerabilities from further consideration if the evaluator determines that the potential vulnerability is not applicable in the operational environment. Otherwise, the evaluator records the potential vulnerability for further consideration. A list of potential vulnerabilities applicable to the TOE in its operational environment, which can be used as an input into penetration testing activities, shall be reported in the ETR by the evaluators. The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential. The evaluator shall devise penetration tests, based on the independent search for potential vulnerabilities. The evaluator prepares for penetration testing as necessary to determine the susceptibility of the TOE, in its operational environment, to the potential vulnerabilities identified during the search of the sources of information publicly available. Any current information provided to the evaluator by a third party (e.g. evaluation authority) regarding known potential vulnerabilities will be considered by the evaluator, together with any encountered potential vulnerabilities resulting from the performance of other evaluation activities. The evaluator will probably find it practical to carry out penetration test using a series of test cases, where each test case will test for a specific potential vulnerability. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a Basic attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers a potential vulnerability that is beyond Basic attack potential, this is reported in the ETR as a residual vulnerability. The evaluator shall produce penetration test documentation for the tests based on the list of potential vulnerabilities in sufficient detail to enable the tests to be repeatable. The test documentation shall include: identification of the potential vulnerability the TOE is being tested for; instructions to connect and setup all required test equipment as required to conduct the penetration test; instructions to establish all penetration test prerequisite initial conditions; instructions to stimulate the TSF; instructions for observing the behaviour of the TSF; descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results; instructions to conclude the test and establish the necessary post-test state for the TOE. The evaluator prepares for penetration testing based on the list of potential vulnerabilities identified during the search of the public domain. The evaluator is not expected to determine the exploitability for potential vulnerabilities beyond those for which a Basic attack potential is required to effect an attack. However, as a result of evaluation expertise, the evaluator may discover a potential vulnerability that is exploitable only by an attacker with greater than Basic attack potential. Such vulnerabilities are to be reported in the ETR as residual vulnerabilities. With an understanding of the potential vulnerability, the evaluator determines the most feasible way to test for the TOE's susceptibility. Specifically, the evaluator considers: the TSFI or other TOE interface that will be used to stimulate the TSF and observe responses; initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have); special test equipment that will be required to either stimulate a TSFI or make observations of a TSFI (although it is unlikely that specialist equipment would be required to exploit a potential vulnerability assuming a Basic attack potential); whether theoretical analysis should replace physical testing, particularly relevant where the results of an initial test can be extrapolated to demonstrate that repeated attempts of an attack are likely to succeed after a given number of attempts. The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where each test case will test for a specific potential vulnerability. The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the tests and obtain an equivalent result. The evaluator shall conduct penetration testing. The evaluator uses the penetration test documentation resulting from work unit as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learnt during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a Basic attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers a potential vulnerability that is beyond Basic attack potential, this is reported in the ETR as a residual vulnerability. The evaluator shall record the actual results of the penetration tests. While some specific details of the actual test results may be different from those expected (e.g. time and date fields in an audit record) the overall result should be identical. Any unexpected test results should be investigated. The impact on the evaluation should be stated and justified. The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results. The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration testing approach and effort expended on this sub-activity. The intent of providing this information is to give a meaningful overview of the evaluator's penetration testing effort. It is not intended that the information regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual penetration tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE test configurations, and the overall results of the penetration testing activity. Information that would typically be found in the ETR subclause regarding evaluator penetration testing efforts is: TOE test configurations. The particular configurations of the TOE that were penetration tested; TSFI penetration tested. A brief listing of the TSFI and other TOE interfaces that were the focus of the penetration testing; verdict for the sub-activity. The overall judgement on the results of penetration testing. This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the penetration testing the evaluator performed during the evaluation. The evaluator shall examine the results of all penetration testing to determine that the TOE, in its operational environment, is resistant to an attacker possessing a Basic attack potential. If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an attacker possessing less than Enhanced-Basic attack potential, then this evaluator action fails. The guidance in B.2 should be used to determine the attack potential required to exploit a particular vulnerability and whether it can therefore be exploited in the intended environment. It may not be necessary for the attack potential to be calculated in every instance, only if there is some doubt as to whether or not the vulnerability can be exploited by an attacker possessing an attack potential less than Enhanced-Basic. The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for each: its source (e.g. evaluation methodology activity being undertaken when it was conceived, known to the evaluator, read in a publication); the SFR(s) not met; a description; whether it is exploitable in its operational environment or not (i.e. exploitable or residual). the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and the equipment required to perform the identified vulnerabilities, and the corresponding values using Tables B.2 and B.3 of Annex B. The objective of this sub-activity is to determine whether the TOE, in its operational environment, has vulnerabilities exploitable by attackers possessing Basic attack potential. The evaluator should consider performing additional tests as a result of potential vulnerabilities encountered during other parts of the evaluation. the ST; the functional specification; the TOE design; the security architecture description; the guidance documentation; the TOE suitable for testing; information publicly available to support the identification of possible potential vulnerabilities. The remaining implicit evaluation evidence for this sub-activity depends on the components that have been included in the assurance package. The evidence provided for each component is to be used as input in this sub-activity. Other input for this sub-activity is: current information regarding public domain potential vulnerabilities and attacks (e.g. from an evaluation authority). The developer shall provide the TOE for testing. The developer shall provide a list of third party components included in the TOE and the TOE delivery. The TOE shall be suitable for testing. The list of third party components shall include components provided by third parties, and that are part of the TOE or otherwise part of the TOE delivery. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. The TOE provided by the developer and identified in the test plan should have the same unique reference as established by the sub-activities and identified in the ST introduction. It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST. The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly. The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the Evaluation of sub-activity sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only. If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed can satisfy work unit . The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE the components in the list of third party components, and specific IT products in the environment that the TOE depends on. The evaluator shall examine sources of information publicly available to identify potential vulnerabilities in the TOE. The evaluator examines the sources of information publicly available to support the identification of possible potential vulnerabilities in the TOE. There are many sources of publicly available information which the evaluator should consider using items such as those available on the world wide web, including: specialist publications (magazines, books); research papers. The evaluator should not constrain their consideration of publicly available information to the above, but should consider any other relevant information available. While examining the evidence provided the evaluator will use the information in the public domain to further search for potential vulnerabilities. Where the evaluators have identified areas of concern, the evaluator should consider information publicly available that relate to those areas of concern. The availability of information that may be readily available to an attacker that helps to identify and facilitate attacks may substantially enhance the attack potential of a given attacker. The accessibility of vulnerability information and sophisticated attack tools on the Internet makes it more likely that this information will be used in attempts to identify potential vulnerabilities in the TOE and exploit them. Modern search tools make such information easily available to the evaluator, and the determination of resistance to published potential vulnerabilities and well-known generic attacks can be achieved in a cost-effective manner. The search of the information publicly available should be focused on those sources that refer specifically to the product from which the TOE is derived. The extensiveness of this search should consider the following factors: TOE type, evaluator experience in this TOE type, expected attack potential and the level of evidence available. The identification process is iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation. The evaluator will report what actions were taken to identify potential vulnerabilities in the evidence. However, in this type of search, the evaluator may not be able to describe the steps in identifying potential vulnerabilities before the outset of the examination, as the approach may evolve as a result of findings during the search. The evaluator will report the evidence examined in completing the search for potential vulnerabilities. This selection of evidence may be derived from those areas of concern identified by the evaluator, linked to the evidence the attacker is assumed to be able to obtain, or according to another rationale provided by the evaluator. The evaluator shall perform an independent vulnerability analysis of the TOE using the guidance documentation, functional specification, TOE design and security architecture description to identify potential vulnerabilities in the TOE. The evaluator shall conduct a search of ST, guidance documentation, functional specification, TOE design and security architecture description evidence to identify possible potential vulnerabilities in the TOE. A search of the evidence should be completed whereby specifications and documentation for the TOE are analysed and then potential vulnerabilities in the TOE are hypothesised, or speculated. The list of hypothesised potential vulnerabilities is then prioritised on the basis of the estimated probability that a potential vulnerability exists and, assuming an exploitable vulnerability does exist the attack potential required to exploit it, and on the extent of control or compromise it would provide. The prioritised list of potential vulnerabilities is used to direct penetration testing against the TOE. The security architecture description provides the developer vulnerability analysis, as it documents how the TSF protects itself from interference from untrusted subjects and prevents the bypass of security enforcement functionality. Therefore, the evaluator should use this description of the protection of the TSF as a basis for the search for possible ways to undermine the TSF. Subject to the SFRs the TOE is to meet in the operational environment, the evaluator's independent vulnerability analysis should consider generic potential vulnerabilities under each of the following headings: generic potential vulnerabilities relevant for the type of TOE being evaluated, as may be supplied by the evaluation authority; bypassing; tampering; direct attacks; monitoring; misuse. Items b) to f) are explained in greater detail in Annex B. The security architecture description should be considered in light of each of the above generic potential vulnerabilities. Each potential vulnerability should be considered to search for possible ways in which to defeat the TSF protection and undermine the TSF. The evaluator shall record in the ETR the identified potential vulnerabilities that are candidates for testing and applicable to the TOE in its operational environment. It may be identified that no further consideration of the potential vulnerability is required if for example the evaluator identifies that measures in the operational environment, either IT or non-IT, prevent exploitation of the potential vulnerability in that operational environment. For instance, restricting physical access to the TOE to authorized users only may effectively render a potential vulnerability to tampering unexploitable. The evaluator records any reasons for exclusion of potential vulnerabilities from further consideration if the evaluator determines that the potential vulnerability is not applicable in the operational environment. Otherwise, the evaluator records the potential vulnerability for further consideration. A list of potential vulnerabilities applicable to the TOE in its operational environment, which can be used as an input into penetration testing activities, shall be reported in the ETR by the evaluators. The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential. The evaluator shall devise penetration tests, based on the independent search for potential vulnerabilities. The evaluator prepares for penetration testing as necessary to determine the susceptibility of the TOE, in its operational environment, to the potential vulnerabilities identified during the search of the sources of information publicly available. Any current information provided to the evaluator by a third party (e.g. evaluation authority) regarding known potential vulnerabilities will be considered by the evaluator, together with any encountered potential vulnerabilities resulting from the performance of other evaluation activities. The evaluator is reminded that, as for considering the security architecture description in the search for vulnerabilities (as detailed in ), testing should be performed to confirm the architectural properties. This is likely to require negative tests attempting to disprove the properties of the security architecture. In developing the strategy for penetration testing, the evaluator will ensure that each of the major characteristics of the security architecture description are tested, either in functional testing (as considered in Clause 14) or evaluator penetration testing. The evaluator will probably find it practical to carry out penetration test using a series of test cases, where each test case will test for a specific potential vulnerability. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a Basic attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond Basic attack potential, this is reported in the ETR as a residual vulnerability. Guidance on determining the necessary attack potential to exploit a potential vulnerability can be found in B.2. Potential vulnerabilities hypothesised as exploitable only by attackers possessing Enhanced-Basic, Moderate or High attack potential do not result in a failure of this evaluator action. Where analysis supports the hypothesis, these need not be considered further as an input to penetration testing. However, such vulnerabilities are reported in the ETR as residual vulnerabilities. Potential vulnerabilities hypothesised as exploitable by an attacker possessing a Basic attack potential and resulting in a violation of the security objectives should be the highest priority potential vulnerabilities comprising the list used to direct penetration testing against the TOE. The evaluator shall produce penetration test documentation for the tests based on the list of potential vulnerabilities in sufficient detail to enable the tests to be repeatable. The test documentation shall include: identification of the potential vulnerability the TOE is being tested for; instructions to connect and setup all required test equipment as required to conduct the penetration test; instructions to establish all penetration test prerequisite initial conditions; instructions to stimulate the TSF; instructions for observing the behaviour of the TSF; descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results; instructions to conclude the test and establish the necessary post-test state for the TOE. The evaluator prepares for penetration testing based on the list of potential vulnerabilities identified during the search of the public domain and the analysis of the evaluation evidence. The evaluator is not expected to determine the exploitability for potential vulnerabilities beyond those for which a Basic attack potential is required to effect an attack. However, as a result of evaluation expertise, the evaluator may discover a potential vulnerability that is exploitable only by an attacker with greater than Basic attack potential. Such vulnerabilities are to be reported in the ETR as residual vulnerabilities. With an understanding of the potential vulnerability, the evaluator determines the most feasible way to test for the TOE's susceptibility. Specifically, the evaluator considers: the TSFI or other TOE interface that will be used to stimulate the TSF and observe responses (It is possible that the evaluator will need to use an interface to the TOE other than the TSFI to demonstrate properties of the TSF such as those described in the security architecture description (as required by ). It should the noted, that although these TOE interfaces provide a means of testing the TSF properties, they are not the subject of the test.); initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have); special test equipment that will be required to either stimulate a TSFI or make observations of a TSFI (although it is unlikely that specialist equipment would be required to exploit a potential vulnerability assuming a Basic attack potential); whether theoretical analysis should replace physical testing, particularly relevant where the results of an initial test can be extrapolated to demonstrate that repeated attempts of an attack are likely to succeed after a given number of attempts. The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where each test case will test for a specific potential vulnerability. The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the tests and obtain an equivalent result. The evaluator shall conduct penetration testing. The evaluator uses the penetration test documentation resulting from work unit as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learnt during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing. Should penetration testing show that a hypothesised potential vulnerability does not exist, then the evaluator should determine whether or not the evaluator's own analysis was incorrect, or if evaluation deliverables are incorrect or incomplete. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a Basic attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond basic attack potential, this is reported in the ETR as a residual vulnerability. The evaluator shall record the actual results of the penetration tests. While some specific details of the actual test results may be different from those expected (e.g. time and date fields in an audit record) the overall result should be identical. Any unexpected test results should be investigated. The impact on the evaluation should be stated and justified. The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results. The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration testing approach and effort expended on this sub-activity. The intent of providing this information is to give a meaningful overview of the evaluator's penetration testing effort. It is not intended that the information regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual penetration tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE test configurations, and the overall results of the penetration testing activity. Information that would typically be found in the ETR subclause regarding evaluator penetration testing efforts is: TOE test configurations. The particular configurations of the TOE that were penetration tested; TSFI penetration tested. A brief listing of the TSFI and other TOE interfaces that were the focus of the penetration testing; Verdict for the sub-activity. The overall judgement on the results of penetration testing. This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the penetration testing the evaluator performed during the evaluation. The evaluator shall examine the results of all penetration testing to determine that the TOE, in its operational environment, is resistant to an attacker possessing a Basic attack potential. If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an attacker possessing less than an Enhanced-Basic attack potential, then this evaluator action fails. The guidance in B.2 should be used to determine the attack potential required to exploit a particular vulnerability and whether it can therefore be exploited in the intended environment. It may not be necessary for the attack potential to be calculated in every instance, only if there is some doubt as to whether or not the vulnerability can be exploited by an attacker possessing an attack potential less than Enhanced-Basic. The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for each: its source (e.g. evaluation methodology activity being undertaken when it was conceived, known to the evaluator, read in a publication); the SFR(s) not met; a description; whether it is exploitable in its operational environment or not (i.e. exploitable or residual); the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and the equipment required to perform the identified vulnerabilities, and the corresponding values using Tables B.2 and B.3 of B.2. The objective of this sub-activity is to determine whether the TOE, in its operational environment, has vulnerabilities exploitable by attackers possessing Enhanced-Basic attack potential. During the conduct of evaluation activities the evaluator may also identify areas of concern. These are specific portions of the TOE evidence that the evaluator has some reservation about, although the evidence meets the requirements for the activity with which the evidence is associated. For example, a particular interface specification looks particularly complex, and therefore may be prone to error either in the development of the TOE or in the operation of the TOE. There is no potential vulnerability apparent at this stage, further investigation is required. This is beyond the bounds of encountered, as further investigation is required. The focused approach to the identification of potential vulnerabilities is an analysis of the evidence with the aim of identifying any potential vulnerabilities evident through the contained information. It is an unstructured analysis, as the approach is not predetermined. Further guidance on focused vulnerability analysis can be found in B.1.4.2.2. the ST; the functional specification; the TOE design; the security architecture description; the implementation subset selected; the guidance documentation; the TOE suitable for testing; information publicly available to support the identification of possible potential vulnerabilities; the results of the testing of the basic design. The remaining implicit evaluation evidence for this sub-activity depends on the components that have been included in the assurance package. The evidence provided for each component is to be used as input in this sub-activity. Other input for this sub-activity is: current information regarding public domain potential vulnerabilities and attacks (e.g. from an evaluation authority). The developer shall provide the TOE for testing. The developer shall provide a list of third party components included in the TOE and the TOE delivery. The TOE shall be suitable for testing. The list of third party components shall include components provided by third parties, and that are part of the TOE or otherwise part of the TOE delivery. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. The TOE provided by the developer and identified in the test plan should have the same unique reference as established by the sub-activities and identified in the ST introduction. It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST. The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly. The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the Evaluation of sub-activity sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only. If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed can satisfy work unit . The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE the components in the list of third party components, and specific IT products in the environment that the TOE depends on. The evaluator shall examine sources of information publicly available to identify potential vulnerabilities in the TOE. The evaluator examines the sources of information publicly available to support the identification of possible potential vulnerabilities in the TOE. There are many sources of publicly available information which the evaluator should consider using items such as those available on the world wide web, including: specialist publications (magazines, books); research papers; conference proceedings. The evaluator should not constrain their consideration of publicly available information to the above but should consider any other relevant information available. While examining the evidence provided the evaluator will use the information in the public domain to further search for potential vulnerabilities. Where the evaluators have identified areas of concern, the evaluator should consider information publicly available that relate to those areas of concern. The availability of information that may be readily available to an attacker that helps to identify and facilitate attacks may substantially enhance the attack potential of a given attacker. The accessibility of vulnerability information and sophisticated attack tools on the Internet makes it more likely that this information will be used in attempts to identify potential vulnerabilities in the TOE and exploit them. Modern search tools make such information easily available to the evaluator, and the determination of resistance to published potential vulnerabilities and well-known generic attacks can be achieved in a cost-effective manner. The search of the information publicly available should be focused on those sources that refer to the technologies used in the development of the product from which the TOE is derived. The extensiveness of this search should consider the following factors: TOE type, evaluator experience in this TOE type, expected attack potential and the level of evidence available. The identification process is iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation. The evaluator will report what actions were taken to identify potential vulnerabilities in the evidence. However, in this type of search, the evaluator may not be able to describe the steps in identifying potential vulnerabilities before the outset of the examination, as the approach may evolve as a result of findings during the search. The evaluator will report the evidence examined in completing the search for potential vulnerabilities. This selection of evidence may be derived from those areas of concern identified by the evaluator, linked to the evidence the attacker is assumed to be able to obtain, or according to another rationale provided by the evaluator. The evaluator shall perform an independent, focused vulnerability analysis of the TOE using the guidance documentation, functional specification, TOE design, security architecture description and implementation representation to identify potential vulnerabilities in the TOE. The evaluator shall conduct a focused search of ST, guidance documentation, functional specification, TOE design, security architecture description and implementation representation to identify possible potential vulnerabilities in the TOE. A flaw hypothesis methodology needs to be used whereby specifications and development and guidance evidence are analysed and then potential vulnerabilities in the TOE are hypothesised, or speculated. The evaluator uses the knowledge of the TOE design and operation gained from the TOE deliverables to conduct a flaw hypothesis to identify potential flaws in the development of the TOE and potential errors in the specified method of operation of the TOE. The security architecture description provides the developer vulnerability analysis, as it documents how the TSF protects itself from interference from untrusted subjects and prevents the bypass of security enforcement functionality. Therefore, the evaluator should build upon the understanding of the TSF protection gained from the analysis of this evidence and then develop this in the knowledge gained from other development evidence. The approach taken is directed by areas of concern identified during examination of the evidence during the conduct of evaluation activities and ensuring a representative sample of the development and guidance evidence provided for the evaluation is searched. For guidance on sampling see Annex A. This guidance should be considered when selecting the subset, giving reasons for: the approach used in selection; qualification that the evidence to be examined supports that approach. The areas of concern may relate to the sufficiency of specific protection features detailed in the security architecture description. The evidence to be considered during the vulnerability analysis may be linked to the evidence the attacker is assumed to be able to obtain. For example, the developer may protect the TOE design and implementation representations, so the only information assumed to be available to an attacker is the functional specification and guidance (publicly available). So, although the objectives for assurance in the TOE ensure the TOE design and implementation representation requirements are met, these design representations may only be searched to further investigate areas of concerns. On the other hand, if the source is publicly available it would be reasonable to assume that the attacker has access to the source and can use this in attempts to attack the TOE. Therefore, the source should be considered in the focused examination approach. The following indicates examples for the selection of the subset of evidence to be considered: For an evaluation where all levels of design abstraction from functional specification to implementation representation are provided, examination of information in the functional specification and the implementation representation may be selected, as the functional specification provides detail of interfaces available to an attacker, and the implementation representation incorporates the design decisions made at all other design abstractions. Therefore, the TOE design information will be considered as part of the implementation representation. Examination of a particular subset of information in each of the design representations provided for the evaluation. Coverage of particular SFRs through each of the design representations provided for the evaluation. Examination of each of the design representations provided for the evaluation, considering different SFRs within each design representations. Examination of aspects of the evidence provided for the evaluation relating to current potential vulnerability information the evaluator has received (e.g. from a scheme). This approach to identification of potential vulnerabilities is to take an ordered and planned approach; applying a system to the examination. The evaluator is to describe the method to be used in terms of what evidence will be considered, the information within the evidence that is to be examined, the manner in which this information is to be considered and the hypothesis that is to be created. The following provide some examples that a hypothesis may take: consideration of malformed input for interfaces available to an attacker at the external interfaces; examination of a key security mechanism cited in the security architecture description, such as process separation, hypothesising internal buffer overflows that may lead to degradation of separation; search to identify any objects created in the TOE implementation representation that are then not fully controlled by the TSF, and can be used by an attacker to undermine SFRs. For example, the evaluator may identify that interfaces are a potential area of weakness in the TOE and specify an approach to the search that "all interface specifications provided in the functional specification and TOE design will be searched to hypothesise potential vulnerabilities" and go on to explain the methods used in the hypothesis. The identification process is iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation. The evaluator will report what actions were taken to identify potential vulnerabilities in the evidence. However, in this type of search, the evaluator may not be able to describe the steps in identifying potential vulnerabilities before the outset of the examination, as the approach may evolve as a result of findings during the search. The evaluator will report the evidence examine in completing the search for potential vulnerabilities. This selection of evidence may be derived from those areas of concern identified by the evaluator, linked to the evidence the attacker is assumed to be able to obtain, or according to another rationale provided by the evaluator. Subject to the SFRs the TOE is to meet in the operational environment, the evaluator's independent vulnerability analysis should consider generic potential vulnerabilities under each of the following headings: generic potential vulnerabilities relevant for the type of TOE being evaluated, as may be supplied by the evaluation authority; bypassing; tampering; direct attacks; monitoring; misuse. Items b) to f) are explained in greater detail in Annex B. The security architecture description should be considered in light of each of the above generic potential vulnerabilities. Each potential vulnerability should be considered to search for possible ways in which to defeat the TSF protection and undermine the TSF. The evaluator shall record in the ETR the identified potential vulnerabilities that are candidates for testing and applicable to the TOE in its operational environment. It may be identified that no further consideration of the potential vulnerability is required if for example the evaluator identifies that measures in the operational environment, either IT or non-IT, prevent exploitation of the potential vulnerability in that operational environment. For instance, restricting physical access to the TOE to authorized users only may effectively render a potential vulnerability to tampering unexploitable. The evaluator records any reasons for exclusion of potential vulnerabilities from further consideration if the evaluator determines that the potential vulnerability is not applicable in the operational environment. Otherwise, the evaluator records the potential vulnerability for further consideration. A list of potential vulnerabilities applicable to the TOE in its operational environment, which can be used as an input into penetration testing activities, shall be reported in the ETR by the evaluators. The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Enhanced-Basic attack potential. The evaluator shall devise penetration tests, based on the independent search for potential vulnerabilities. The evaluator prepares for penetration testing as necessary to determine the susceptibility of the TOE, in its operational environment, to the potential vulnerabilities identified during the search of the sources of information publicly available. Any current information provided to the evaluator by a third party (e.g. evaluation authority) regarding known potential vulnerabilities will be considered by the evaluator, together with any encountered potential vulnerabilities resulting from the performance of other evaluation activities. The evaluator is reminded that, as for considering the security architecture description in the search for vulnerabilities (as detailed in ), testing should be performed to confirm the architectural properties. If requirements from are included in the SARs, the developer testing evidence will include testing performed to confirm the correct implementation of any specific mechanisms detailed in the security architecture description. However, the developer testing will not necessarily include testing of all aspects of the architectural properties that protect the TSF, as much of this testing will be negative testing in nature, attempting to disprove the properties. In developing the strategy for penetration testing, the evaluator will ensure that all aspects of the security architecture description are tested, either in functional testing (as considered in Clause 14) or evaluator penetration testing. It will probably be practical to carry out penetration test using a series of test cases, where each test case will test for a specific potential vulnerability. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required an Enhanced-Basic attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond Enhanced-Basic attack potential, this is reported in the ETR as a residual vulnerability. Guidance on determining the necessary attack potential to exploit a potential vulnerability can be found in B.2. Potential vulnerabilities hypothesised as exploitable only by attackers possessing Moderate or High attack potential do not result in a failure of this evaluator action. Where analysis supports the hypothesis, these need not be considered further as an input to penetration testing. However, such vulnerabilities are reported in the ETR as residual vulnerabilities. Potential vulnerabilities hypothesised as exploitable by an attacker possessing a Basic or Enhanced-Basic attack potential and resulting in a violation of the security objectives should be the highest priority potential vulnerabilities comprising the list used to direct penetration testing against the TOE. The evaluator shall produce penetration test documentation for the tests based on the list of potential vulnerabilities in sufficient detail to enable the tests to be repeatable. The test documentation shall include: identification of the potential vulnerability the TOE is being tested for; instructions to connect and setup all required test equipment as required to conduct the penetration test; instructions to establish all penetration test prerequisite initial conditions; instructions to stimulate the TSF; instructions for observing the behaviour of the TSF; descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results; instructions to conclude the test and establish the necessary post-test state for the TOE. The evaluator prepares for penetration testing based on the list of potential vulnerabilities identified during the search of the public domain and the analysis of the evaluation evidence. The evaluator is not expected to determine the exploitability for potential vulnerabilities beyond those for which an Enhanced-Basic attack potential is required to effect an attack. However, as a result of evaluation expertise, the evaluator may discover a potential vulnerability that is exploitable only by an attacker with greater than Enhanced-Basic attack potential. Such vulnerabilities are to be reported in the ETR as residual vulnerabilities. With an understanding of the potential vulnerability, the evaluator determines the most feasible way to test for the TOE's susceptibility. Specifically, the evaluator considers: the TSFI or other TOE interface that will be used to stimulate the TSF and observe responses (It is possible that the evaluator will need to use an interface to the TOE other than the TSFI to demonstrate properties of the TSF such as those described in the security architecture description (as required by ). It should the noted, that although these TOE interfaces provide a means of testing the TSF properties, they are not the subject of the test.); initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have); special test equipment that will be required to either stimulate a TSFI or make observations of a TSFI (although it is unlikely that specialist equipment would be required to exploit a potential vulnerability assuming an Enhanced-Basic attack potential); whether theoretical analysis should replace physical testing, particularly relevant where the results of an initial test can be extrapolated to demonstrate that repeated attempts of an attack are likely to succeed after a given number of attempts. The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where each test case will test for a specific potential vulnerability. The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the tests and obtain an equivalent result. The evaluator shall conduct penetration testing. The evaluator uses the penetration test documentation resulting from work unit as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learnt during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing. Should penetration testing show that a hypothesised potential vulnerability does not exist, then the evaluator should determine whether or not the evaluator's own analysis was incorrect, or if evaluation deliverables are incorrect or incomplete. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required an Enhanced-Basic attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond Enhanced-Basic attack potential, this is reported in the ETR as a residual vulnerability. The evaluator shall record the actual results of the penetration tests. While some specific details of the actual test results may be different from those expected (e.g. time and date fields in an audit record) the overall result should be identical. Any unexpected test results should be investigated. The impact on the evaluation should be stated and justified. The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results. The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration testing approach and effort expended on this sub-activity. The intent of providing this information is to give a meaningful overview of the evaluator's penetration testing effort. It is not intended that the information regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual penetration tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE test configurations, and the overall results of the penetration testing activity. Information that would typically be found in the ETR subclause regarding evaluator penetration testing efforts is: TOE test configurations. The particular configurations of the TOE that were penetration tested; TSFI penetration tested. A brief listing of the TSFI and other TOE interfaces that were the focus of the penetration testing; Verdict for the sub-activity. The overall judgement on the results of penetration testing. This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the penetration testing the evaluator performed during the evaluation. The evaluator shall examine the results of all penetration testing to determine that the TOE, in its operational environment, is resistant to an attacker possessing an Enhanced-Basic attack potential. If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an attacker possessing less than Moderate attack potential, then this evaluator action fails. The guidance in B.2 should be used to determine the attack potential required to exploit a particular vulnerability and whether it can therefore be exploited in the intended environment. It may not be necessary for the attack potential to be calculated in every instance, only if there is some doubt as to whether or not the vulnerability can be exploited by an attacker possessing an attack potential less than Moderate. The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for each: its source (e.g. evaluation methodology activity being undertaken when it was conceived, known to the evaluator, read in a publication); the SFR(s) not met; a description; whether it is exploitable in its operational environment or not (i.e. exploitable or residual). the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and the equipment required to perform the identified vulnerabilities, and the corresponding values using Tables B.2 and B.3 of B.2. The objective of this sub-activity is to determine whether the TOE, in its operational environment, has vulnerabilities exploitable by attackers possessing Moderate attack potential. The methodical analysis approach takes the form of a structured examination of the evidence. This method requires the evaluator to specify the structure and form the analysis will take (i.e. the manner in which the analysis is performed is predetermined, unlike the focused analysis). The method is specified in terms of the information that will be considered and how/why it will be considered. Further guidance on methodical vulnerability analysis can be found in B.4.2.4. the ST; the functional specification; the TOE design; the security architecture description; the implementation representation; the guidance documentation; the TOE suitable for testing; information publicly available to support the identification of possible potential vulnerabilities; the results of the testing of the basic design. The remaining implicit evaluation evidence for this sub-activity depends on the components that have been included in the assurance package. The evidence provided for each component is to be used as input in this sub-activity. Other input for this sub-activity is: current information regarding public domain potential vulnerabilities and attacks (e.g. from an evaluation authority). The developer shall provide the TOE for testing. The developer shall provide a list of third party components included in the TOE and the TOE delivery. The TOE shall be suitable for testing. The list of third party components shall include components provided by third parties, and that are part of the TOE or otherwise part of the TOE delivery. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. The TOE provided by the developer and identified in the test plan should have the same unique reference as established by the sub-activities and identified in the ST introduction. It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST. The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly. The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the Evaluation of sub-activity sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only. If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed can satisfy work unit . The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE the components in the list of third party components, and specific IT products in the environment that the TOE depends on. The evaluator shall examine sources of information publicly available to identify potential vulnerabilities in the TOE. The evaluator examines the sources of information publicly available to support the identification of possible potential vulnerabilities in the TOE. There are many sources of publicly available information which the evaluator should consider using items such as those available on the world wide web, including: specialist publications (magazines, books); research papers; conference proceedings. The evaluator should not constrain their consideration of publicly available information to the above, but should consider any other relevant information available. While examining the evidence provided the evaluator will use the information in the public domain to further search for potential vulnerabilities. Where the evaluators have identified areas of concern, the evaluator should consider information publicly available that relate to those areas of concern. The availability of information that may be readily available to an attacker that helps to identify and facilitate attacks may substantially enhance the attack potential of a given attacker. The accessibility of vulnerability information and sophisticated attack tools on the Internet makes it more likely that this information will be used in attempts to identify potential vulnerabilities in the TOE and exploit them. Modern search tools make such information easily available to the evaluator, and the determination of resistance to published potential vulnerabilities and well-known generic attacks can be achieved in a cost-effective manner. The search of the information publicly available should be focused on those sources that refer to the technologies used in the development of the product from which the TOE is derived. The extensiveness of this search should consider the following factors: TOE type, evaluator experience in this TOE type, expected attack potential and the level of evidence available. The identification process is iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation. The evaluator will describe the approach to be taken to identify potential vulnerabilities in the publicly available material, detailing the search to be performed. This may be driven by factors such as areas of concern identified by the evaluator, linked to the evidence the attacker is assumed to be able to obtain. However, it is recognised that in this type of search the approach may further evolve as a result of findings during the search. Therefore, the evaluator will also report any actions taken in addition to those described in the approach to further investigate issues thought to lead to potential vulnerabilities, and will report the evidence examined in completing the search for potential vulnerabilities. The evaluator shall perform an independent, methodical vulnerability analysis of the TOE using the guidance documentation, functional specification, TOE design, security architecture description and implementation representation to identify potential vulnerabilities in the TOE. The evaluator shall conduct a methodical analysis of ST, guidance documentation, functional specification, TOE design, security architecture description and implementation representation to identify possible potential vulnerabilities in the TOE. Guidance on methodical vulnerability analysis is provided in B.1.4.2.3. This approach to identification of potential vulnerabilities is to take an ordered and planned approach. A system is to be applied in the examination. The evaluator is to describe the method to be used in terms of the manner in which this information is to be considered and the hypothesis that is to be created. A flaw hypothesis methodology needs to be used whereby the ST, development (functional specification, TOE design and implementation representation) and guidance evidence are analysed and then vulnerabilities in the TOE are hypothesised, or speculated. The evaluator uses the knowledge of the TOE design and operation gained from the TOE deliverables to conduct a flaw hypothesis to identify potential flaws in the development of the TOE and potential errors in the specified method of operation of the TOE. The security architecture description provides the developer vulnerability analysis, as it documents how the TSF protects itself from interference from untrusted subjects and prevents the bypass of security enforcement functionality. Therefore, the evaluator should build upon the understanding of the TSF protection gained from the analysis of this evidence and then develop this in the knowledge gained from other development evidence. The approach taken to the methodical search for vulnerabilities is to consider any areas of concern identified in the results of the evaluator's assessment of the development and guidance evidence. However, the evaluator should also consider each aspect of the security architecture analysis to search for any ways in which the protection of the TSF can be undermined. It may be helpful to structure the methodical analysis on the basis of the material presented in the security architecture description, introducing concerns from other evidence as appropriate. The analysis can then be further developed to ensure all other material from the evidence is considered. The following provide some examples of hypotheses that may be created when examining the evidence: consideration of malformed input for interfaces available to an attacker at the external interfaces; examination of a key security mechanism cited in the security architecture description, such as process separation, hypothesising internal buffer overflows that may lead to degradation of separation; search to identify any objects created in the TOE implementation representation that are then not fully controlled by the TSF, and can be used by an attacker to undermine SFRs. For example, the evaluator may identify that interfaces are a potential area of weakness in the TOE and specify an approach to the search that "all interface specifications in the evidence provided will be searched to hypothesise potential vulnerabilities" and go on to explain the methods used in the hypothesis. In addition, areas of concern the evaluator has identified during examination of the evidence during the conduct of evaluation activities. Areas of concern may also be identified during the conduct of other work units associated with this component, in particular , and where the development and conduct of penetration tests may identify further areas of concerns for investigation, or potential vulnerabilities. However, examination of only a subset of the development and guidance evidence or their contents is not permitted in this level of rigour. The approach description should provide a demonstration that the methodical approach used is complete, providing confidence that the approach used to search the deliverables has considered all of the information provided in those deliverables. This approach to identification of potential vulnerabilities is to take an ordered and planned approach; applying a system to the examination. The evaluator is to describe the method to be used in terms of how the evidence will be considered; the manner in which this information is to be considered and the hypothesis that is to be created. This approach should be agreed with the evaluation authority, and the evaluation authority may provide detail of any additional approaches the evaluator should take to the vulnerability analysis and identify any additional information that should be considered by the evaluator. Although a system to identifying potential vulnerabilities is predefined, the identification process may still be iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation. Subject to the SFRs the TOE is to meet in the operational environment, the evaluator's independent vulnerability analysis should consider generic potential vulnerabilities under each of the following headings: generic potential vulnerabilities relevant for the type of TOE being evaluated, as may be supplied by the evaluation authority; bypassing; tampering; direct attacks; monitoring; misuse. Items b) to f) are explained in greater detail in Annex B. The security architecture description should be considered in light of each of the above generic potential vulnerabilities. Each potential vulnerability should be considered to search for possible ways in which to defeat the TSF protection and undermine the TSF. The evaluator shall record in the ETR the identified potential vulnerabilities that are candidates for testing and applicable to the TOE in its operational environment. It may be identified that no further consideration of the potential vulnerability is required if for example the evaluator identifies that measures in the operational environment, either IT or non-IT, prevent exploitation of the potential vulnerability in that operational environment. For instance, restricting physical access to the TOE to authorized users only may effectively render a potential vulnerability to tampering unexploitable. The evaluator records any reasons for exclusion of potential vulnerabilities from further consideration if the evaluator determines that the potential vulnerability is not applicable in the operational environment. Otherwise, the evaluator records the potential vulnerability for further consideration. A list of potential vulnerabilities applicable to the TOE in its operational environment, which can be used as an input into penetration testing activities, shall be reported in the ETR by the evaluators. The evaluator shall conduct penetration testing based on the identified potential vulnerabilities to determine that the TOE is resistant to attacks performed by an attacker possessing Moderate attack potential. The evaluator shall devise penetration tests, based on the independent search for potential vulnerabilities. The evaluator prepares for penetration testing as necessary to determine the susceptibility of the TOE, in its operational environment, to the potential vulnerabilities identified during the search of the sources of information publicly available. Any current information provided to the evaluator by a third party (e.g. evaluation authority) regarding known potential vulnerabilities will be considered by the evaluator, together with any encountered potential vulnerabilities resulting from the performance of other evaluation activities. The evaluator is reminded that, as for considering the security architecture description in the search for vulnerabilities (as detailed in ), testing should be performed to confirm the architectural properties. If requirements from are included in the SARs, the developer testing evidence will include testing performed to confirm the correct implementation of any specific mechanisms detailed in the security architecture description. However, the developer testing will not necessarily include testing of all aspects of the architectural properties that protect the TSF, as much of this testing will be negative testing in nature, attempting to disprove the properties. In developing the strategy for penetration testing, the evaluator will ensure that all aspects of the security architecture description are tested, either in functional testing or evaluator penetration testing. The evaluator will probably find it practical to carry out penetration test using a series of test cases, where each test case will test for a specific potential vulnerability. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a Moderate attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond Moderate attack potential, this is reported in the ETR as a residual vulnerability. Guidance on determining the necessary attack potential to exploit a potential vulnerability can be found in B.2. Potential vulnerabilities hypothesised as exploitable by an attacker possessing a Moderate (or less) attack potential and resulting in a violation of the security objectives should be the highest priority potential vulnerabilities comprising the list used to direct penetration testing against the TOE. The evaluator shall produce penetration test documentation for the tests based on the list of potential vulnerabilities in sufficient detail to enable the tests to be repeatable. The test documentation shall include: identification of the potential vulnerability the TOE is being tested for; instructions to connect and setup all required test equipment as required to conduct the penetration test; instructions to establish all penetration test prerequisite initial conditions; instructions to stimulate the TSF; instructions for observing the behaviour of the TSF; descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results; instructions to conclude the test and establish the necessary post-test state for the TOE. The evaluator prepares for penetration testing based on the list of potential vulnerabilities identified during the search of the public domain and the analysis of the evaluation evidence. The evaluator is not expected to determine the exploitability for potential vulnerabilities beyond those for which a Moderate attack potential is required to effect an attack. However, as a result of evaluation expertise, the evaluator may discover a potential vulnerability that is exploitable only by an attacker with greater than Moderate attack potential. Such vulnerabilities are to be reported in the ETR as residual vulnerabilities. With an understanding of the potential vulnerability, the evaluator determines the most feasible way to test for the TOE's susceptibility. Specifically the evaluator considers: the TSFI or other TOE interface that will be used to stimulate the TSF and observe responses (It is possible that the evaluator will need to use an interface to the TOE other than the TSFI to demonstrate properties of the TSF such as those described in the security architecture description (as required by ). It should the noted, that although these TOE interfaces provide a means of testing the TSF properties, they are not the subject of the test.); initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have); special test equipment that will be required to either stimulate a TSFI or make observations of a TSFI; whether theoretical analysis should replace physical testing, particularly relevant where the results of an initial test can be extrapolated to demonstrate that repeated attempts of an attack are likely to succeed after a given number of attempts. The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where each test case will test for a specific potential vulnerability. The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the tests and obtain an equivalent result. The evaluator shall conduct penetration testing. The evaluator uses the penetration test documentation resulting from work unit as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learnt during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing. Should penetration testing show that a hypothesised potential vulnerability does not exist, then the evaluator should determine whether or not the evaluator's own analysis was incorrect, or if evaluation deliverables are incorrect or incomplete. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a Moderate attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond Moderate attack potential, this is reported in the ETR as a residual vulnerability. The evaluator shall record the actual results of the penetration tests. While some specific details of the actual test results may be different from those expected (e.g. time and date fields in an audit record) the overall result should be identical. Any unexpected test results should be investigated. The impact on the evaluation should be stated and justified. The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results. The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration testing approach and effort expended on this sub-activity. The intent of providing this information is to give a meaningful overview of the evaluator's penetration testing effort. It is not intended that the information regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual penetration tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE test configurations, and the overall results of the penetration testing activity. Information that would typically be found in the ETR subclause regarding evaluator penetration testing efforts is: TOE test configurations. The particular configurations of the TOE that were penetration tested; TSFI penetration tested. A brief listing of the TSFI and other TOE interfaces that were the focus of the penetration testing; Verdict for the sub-activity. The overall judgement on the results of penetration testing. This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the penetration testing the evaluator performed during the evaluation. The evaluator shall examine the results of all penetration testing to determine that the TOE, in its operational environment, is resistant to an attacker possessing a Moderate attack potential. If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an attacker possessing less than a High attack potential, then this evaluator action fails. The guidance in B.2 should be used to determine the attack potential required to exploit a particular vulnerability and whether it can therefore be exploited in the intended environment. It may not be necessary for the attack potential to be calculated in every instance, only if there is some doubt as to whether or not the vulnerability can be exploited by an attacker possessing an attack potential less than high. The evaluator shall report in the ETR all exploitable vulnerabilities and residual vulnerabilities, detailing for each: its source (e.g. evaluation methodology activity being undertaken when it was conceived, known to the evaluator, read in a publication); the SFR(s) not met; a description; whether it is exploitable in its operational environment or not (i.e. exploitable or residual). the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and the equipment required to perform the identified vulnerabilities, and the corresponding values using Tables B.2 and B.3 of B.2. The objective of this sub-activity is to determine whether the TOE, in its operational environment, has vulnerabilities exploitable by attackers possessing High attack potential. The methodical analysis approach takes the form of a structured examination of the evidence. This method requires the evaluator to specify the structure and form the analysis will take (i.e. the manner in which the analysis is performed is predetermined, unlike the focused analysis). The method is specified in terms of the information that will be considered and how/why it will be considered. Further guidance on methodical vulnerability analysis can be found in B.2.2.2.3. the ST; the functional specification; the TOE design; the security architecture description; the implementation representation; the guidance documentation; the TOE suitable for testing; information publicly available to support the identification of possible potential vulnerabilities; the results of the testing of the basic design. The remaining implicit evaluation evidence for this sub-activity depends on the components that have been included in the assurance package. The evidence provided for each component is to be used as input in this sub-activity. Other input for this sub-activity is: current information regarding public domain potential vulnerabilities and attacks (e.g. from an evaluation authority). The developer shall provide the TOE for testing. The developer shall provide a list of third party components included in the TOE and the TOE delivery. The TOE shall be suitable for testing. The list of third party components shall include components provided by third parties, and that are part of the TOE or otherwise part of the TOE delivery. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. The evaluator shall examine the TOE to determine that the test configuration is consistent with the configuration under evaluation as specified in the ST. The TOE provided by the developer and identified in the test plan should have the same unique reference as established by the sub-activities and identified in the ST introduction. It is possible for the ST to specify more than one configuration for evaluation. The TOE may comprise a number of distinct hardware and software entities that need to be tested in accordance with the ST. The evaluator verifies that all test configurations are consistent with the ST. The evaluator should consider the security objectives for the operational environment described in the ST that may apply to the test environment and ensure they are met in the testing environment. There may be some objectives for the operational environment that do not apply to the test environment. For example, an objective about user clearances may not apply; however, an objective about a single point of connection to a network would apply. If any test resources are used (e.g. meters, analysers) it will be the evaluator's responsibility to ensure that these resources are calibrated correctly. The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state It is possible for the evaluator to determine the state of the TOE in a number of ways. For example, previous successful completion of the Evaluation of sub-activity sub-activity will satisfy this work unit if the evaluator still has confidence that the TOE being used for testing was installed properly and is in a known state. If this is not the case, then the evaluator should follow the developer's procedures to install and start up the TOE, using the supplied guidance only. If the evaluator has to perform the installation procedures because the TOE is in an unknown state, this work unit when successfully completed can satisfy work unit . The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE the components in the list of third party components, and specific IT products in the environment that the TOE depends on. The evaluator shall examine sources of information publicly available to identify potential vulnerabilities in the TOE. The evaluator examines the sources of information publicly available to support the identification of possible potential vulnerabilities in the TOE. There are many sources of publicly available information which the evaluator should consider using items such as those available on the world wide web, including: specialist publications (magazines, books); research papers; conference proceedings. The evaluator should not constrain their consideration of publicly available information to the above but should consider any other relevant information available. While examining the evidence provided the evaluator will use the information in the public domain to further search for potential vulnerabilities. Where the evaluators have identified areas of concern, the evaluator should consider information publicly available that relate to those areas of concern. The availability of information that may be readily available to an attacker that helps to identify and facilitate attacks may substantially enhance the attack potential of a given attacker. The accessibility of vulnerability information and sophisticated attack tools on the Internet makes it more likely that this information will be used in attempts to identify potential vulnerabilities in the TOE and exploit them. Modern search tools make such information easily available to the evaluator, and the determination of resistance to published potential vulnerabilities and well-known generic attacks can be achieved in a cost-effective manner. The search of the information publicly available should be focused on those sources that refer to the technologies used in the development of the product from which the TOE is derived. The extensiveness of this search should consider the following factors: TOE type, evaluator experience in this TOE type, expected attack potential and the level of evidence available. The identification process is iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation. The evaluator will describe the approach to be taken to identify potential vulnerabilities in the publicly available material, detailing the search to be performed. This may be driven by factors such as areas of concern identified by the evaluator, linked to the evidence the attacker is assumed to be able to obtain. However, it is recognised that in this type of search the approach may further evolve as a result of findings during the search. Therefore, the evaluator will also report any actions taken in addition to those described in the approach to further investigate issues thought to lead to potential vulnerabilities, and will report the evidence examined in completing the search for potential vulnerabilities. The evaluator shall perform an independent, methodical vulnerability analysis of the TOE using the guidance documentation, functional specification, TOE design, security architecture description and implementation representation to identify potential vulnerabilities in the TOE. The evaluator shall conduct a methodical analysis of ST, guidance documentation, functional specification, TOE design, security architecture description and implementation representation to identify possible potential vulnerabilities in the TOE. Guidance on methodical vulnerability analysis is provided in B.2.2.2.3. This approach to identification of potential vulnerabilities is to take an ordered and planned approach. A system is to be applied in the examination. The evaluator is to describe the method to be used in terms of the manner in which this information is to be considered and the hypothesis that is to be created. A flaw hypothesis methodology should be used whereby the ST, development (functional specification, TOE design and implementation representation) and guidance evidence are analysed and then vulnerabilities in the TOE are hypothesised, or speculated. The evaluator should use the knowledge of the TOE design and operation gained from the TOE deliverables to conduct a flaw hypothesis to identify potential flaws in the development of the TOE and potential errors in the specified method of operation of the TOE. The security architecture description provides the developer vulnerability analysis, as it documents how the TSF protects itself from interference from untrusted subjects and prevents the bypass of security enforcement functionality. Therefore, the evaluator should build upon the understanding of the TSF protection gained from the analysis of this evidence and then develop this in the knowledge gained from other development (e.g. ) evidence. The approach taken to the methodical search for vulnerabilities is to consider any areas of concern identified in the results of the evaluator's assessment of the development and guidance evidence. However, the evaluator should also consider each aspect of the security architecture analysis to search for any ways in which the protection of the TSF can be undermined. It may be helpful to structure the methodical analysis on the basis of the material presented in the security architecture description, introducing concerns from other evidence as appropriate. The analysis can then be further developed to ensure all other material from the evidence is considered. The following provide some examples of hypotheses that may be created when examining the evidence: consideration of malformed input for interfaces available to an attacker at the external interfaces; examination of a key security mechanism cited in the security architecture description, such as process separation, hypothesising internal buffer overflows that may lead to degradation of separation; search to identify any objects created in the TOE implementation representation that are then not fully controlled by the TSF, and can be used by an attacker to undermine SFRs. For example, the evaluator may identify that interfaces are a potential area of weakness in the TOE and specify an approach to the search that "all interface specifications in the evidence provided will be searched to hypothesise potential vulnerabilities" and go on to explain the methods used in the hypothesis. In addition, areas of concern the evaluator has identified during examination of the evidence during the conduct of evaluation activities. Areas of concern may also be identified during the conduct of other work units associated with this component, in particular , and where the development and conduct of penetration tests may identify further areas of concerns for investigation, or potential vulnerabilities. However, examination of only a subset of the development and guidance evidence or their contents is not permitted in this level of rigour. The approach description should provide a demonstration that the methodical approach used is complete, providing confidence that the approach used to search the deliverables has considered all of the information provided in those deliverables. This approach to identification of potential vulnerabilities is to take an ordered and planned approach; applying a system to the examination. The evaluator is to describe the method to be used in terms of how the evidence will be considered; the manner in which this information is to be considered and the hypothesis that is to be created. This approach should be agreed with the evaluation authority, and the evaluation authority should provide detail of any additional approaches the evaluator should take to the vulnerability analysis and identify any additional information that should be considered by the evaluator. Although a system to identifying potential vulnerabilities is predefined, the identification process may still be iterative, where the identification of one potential vulnerability may lead to identifying another area of concern that requires further investigation. Subject to the SFRs the TOE is to meet in the operational environment, the evaluator's independent vulnerability analysis should consider generic potential vulnerabilities under each of the following headings: generic potential vulnerabilities relevant for the type of TOE being evaluated, as may be supplied by the evaluation authority; bypassing; tampering; direct attacks; monitoring; misuse. Items b) to f) are explained in greater detail in B.2.1.-consideration if the evaluator determines that the potential vulnerability is not applicable in the operational environment. Otherwise, the evaluator records the potential vulnerability for further consideration. A list of potential vulnerabilities applicable to the TOE in its operational environment, which can be used as an input into penetration testing activities, shall be reported in the ETR by the evaluators. The evaluator shall conduct penetration testing based on the identified potential vulnerabilities to determine that the TOE is resistant to attacks performed by an attacker possessing High attack potential. The evaluator shall devise penetration tests, based on the independent search for potential vulnerabilities. The evaluator prepares for penetration testing as necessary to determine the susceptibility of the TOE, in its operational environment, to the potential vulnerabilities identified during the search of the sources of publicly available information and the analysis of the TOE guidance and design evidence. The evaluator should have access to current information (e.g. from the evaluation authority) regarding known potential vulnerabilities that may not have been considered by the evaluator. The evaluator is reminded that, as for considering the security architecture description in the search for vulnerabilities (as detailed in ), testing should be performed to confirm the architectural properties. If requirements from are included in the SARs, the developer testing evidence will include testing performed to confirm the correct implementation of any specific mechanisms detailed in the security architecture description. However, the developer testing will not necessarily include testing of all aspects of the architectural properties that protect the TSF, as much of this testing will be negative testing in nature, attempting to disprove the properties. In developing the strategy for penetration testing, the evaluator will ensure that all aspects of the security architecture description are tested, either in functional testing or evaluator penetration testing. The evaluator will probably find it practical to carry out penetration test using a series of test cases, where each test case will test for a specific potential vulnerability. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a High attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond High attack potential, this is reported in the ETR as a residual vulnerability. Guidance on determining the necessary attack potential to exploit a potential vulnerability can be found in B.4. Potential vulnerabilities hypothesised as exploitable by an attacker possessing a High (or less) attack potential and resulting in a violation of the security objectives should be the highest priority potential vulnerabilities comprising the list used to direct penetration testing against the TOE. The evaluator shall produce penetration test documentation for the tests based on the list of potential vulnerabilities in sufficient detail to enable the tests to be repeatable. The test documentation shall include: identification of the potential vulnerability the TOE is being tested for; instructions to connect and setup all required test equipment as required to conduct the penetration test; instructions to establish all penetration test prerequisite initial conditions; instructions to stimulate the TSF; instructions for observing the behaviour of the TSF; descriptions of all expected results and the necessary analysis to be performed on the observed behaviour for comparison against expected results; instructions to conclude the test and establish the necessary post-test state for the TOE. The evaluator prepares for penetration testing based on the list of potential vulnerabilities identified during the search of the public domain and the analysis of the evaluation evidence. The evaluator is not expected to determine the exploitability for potential vulnerabilities beyond those for which a High attack potential is required to effect an attack. However, as a result of evaluation expertise, the evaluator may discover a potential vulnerability that is exploitable only by an attacker with greater than High attack potential. Such vulnerabilities are to be reported in the ETR as residual vulnerabilities. With an understanding of the potential vulnerability, the evaluator determines the most feasible way to test for the TOE's susceptibility. Specifically, the evaluator considers: the TSFI or other TOE interface that will be used to stimulate the TSF and observe responses (It is possible that the evaluator will need to use an interface to the TOE other than the TSFI to demonstrate properties of the TSF such as those described in the security architecture description (as required by ). It should the noted, that although these TOE interfaces provide a means of testing the TSF properties, they are not the subject of the test.); initial conditions that will need to exist for the test (i.e. any particular objects or subjects that will need to exist and security attributes they will need to have); special test equipment that will be required to either stimulate a TSFI or make observations of a TSFI; whether theoretical analysis should replace physical testing, particularly relevant where the results of an initial test can be extrapolated to demonstrate that repeated attempts of an attack are likely to succeed after a given number of attempts. The evaluator will probably find it practical to carry out penetration testing using a series of test cases, where each test case will test for a specific potential vulnerability. The intent of specifying this level of detail in the test documentation is to allow another evaluator to repeat the tests and obtain an equivalent result. The evaluator shall conduct penetration testing. The evaluator uses the penetration test documentation resulting from work unit as a basis for executing penetration tests on the TOE, but this does not preclude the evaluator from performing additional ad hoc penetration tests. If required, the evaluator may devise ad hoc tests as a result of information learnt during penetration testing that, if performed by the evaluator, are to be recorded in the penetration test documentation. Such tests may be required to follow up unexpected results or observations, or to investigate potential vulnerabilities suggested to the evaluator during the pre-planned testing. Should penetration testing show that a hypothesised potential vulnerability does not exist, then the evaluator should determine whether or not the evaluator's own analysis was incorrect, or if evaluation deliverables are incorrect or incomplete. The evaluator is not expected to test for potential vulnerabilities (including those in the public domain) beyond those which required a High attack potential. In some cases, however, it will be necessary to carry out a test before the exploitability can be determined. Where, as a result of evaluation expertise, the evaluator discovers an exploitable vulnerability that is beyond High attack potential, this is reported in the ETR as a residual vulnerability. The evaluator shall record the actual results of the penetration tests. While some specific details of the actual test results may be different from those expected (e.g. time and date fields in an audit record) the overall result should be identical. Any unexpected test results should be investigated. The impact on the evaluation should be stated and justified. The evaluator shall report in the ETR the evaluator penetration testing effort, outlining the testing approach, configuration, depth and results. The penetration testing information reported in the ETR allows the evaluator to convey the overall penetration testing approach and effort expended on this sub-activity. The intent of providing this information is to give a meaningful overview of the evaluator's penetration testing effort. It is not intended that the information regarding penetration testing in the ETR be an exact reproduction of specific test steps or results of individual penetration tests. The intention is to provide enough detail to allow other evaluators and evaluation authorities to gain some insight about the penetration testing approach chosen, amount of penetration testing performed, TOE test configurations, and the overall results of the penetration testing activity. Information that would typically be found in the ETR section regarding evaluator penetration testing efforts is: TOE test configurations. The particular configurations of the TOE that were penetration tested; TSFI penetration tested. A brief listing of the TSFI and other TOE interfaces that were the focus of the penetration testing; Verdict for the sub-activity. The overall judgement on the results of penetration testing. This list is by no means exhaustive and is only intended to provide some context as to the type of information that should be present in the ETR concerning the penetration testing the evaluator performed during the evaluation. The evaluator shall examine the results of all penetration testing to determine that the TOE, in its operational environment, is resistant to an attacker possessing a High attack potential. If the results reveal that the TOE, in its operational environment, has vulnerabilities exploitable by an attacker possessing an attack potential less than or equal to High, then this evaluator action fails. The guidance in B.4 and the guidance for special technical areas that is relevant for the national scheme should be used to determine the attack potential required to exploit a particular vulnerability and whether it can therefore be exploited in the intended environment. It may not be necessary for the attack potential to be calculated in every instance, only if there is some doubt as to whether or not the vulnerability can be exploited by an attacker possessing an attack potential less than or equal to High. The evaluator shall report in the corresponding ETR-part all exploitable vulnerabilities and residual vulnerabilities, detailing for each: its source (e.g. CEM activity being undertaken when it was conceived, known to the evaluator, read in a publication); the SFR(s) not met; a description; whether it is exploitable in its operational environment or not (i.e. exploitable or residual); the amount of time, level of expertise, level of knowledge of the TOE, level of opportunity and the equipment required to perform the identified vulnerabilities, and the corresponding values using Tables B.2 and B.3 of Annex B. Security auditing involves recognizing, recording, storing, and analyzing information related to security relevant activities (i.e. activities controlled by the TSF). The resulting audit records can be examined to determine which security relevant activities took place and whom (which user) is responsible for them. The audit families allow PP, PP-Module, functional package or ST authors the ability to define requirements for monitoring user activities and, in some cases, detecting real, possible, or imminent violations of the enforcement of the SFRs. The TOE's security audit functions are defined to help monitor security-relevant events, and act as a deterrent against security violations. The requirements of the audit families refer to functions that include audit data protection, record format, and event selection, as well as analysis tools, violation alarms, and real-time analysis. The audit records may be presented in human-readable format either directly or indirectly or both. An example of direct presentation is storing the audit records in human-readable format. An example of indirect presentation is by using audit reduction tools. While developing the security audit requirements, the author of a PP, PP-Module, functional package or ST should take note of the inter-relationships among the audit families and components. The potential exists to specify a set of audit requirements that conform with the family/component dependencies lists, while at the same time resulting in a deficient audit function. An audit function that requires all security relevant events to be audited but without the selectivity to control them on any reasonable basis such as individual user or object. The implementation of audit requirements for networks and other large systems can differ significantly from those needed for stand-alone systems. Larger, more complex, and active systems require more thought concerning which audit data to collect and how this can be managed, due to the lowered feasibility of interpreting (or even storing) what gets collected. The traditional notion of a time-ordered list, set of records or "trail" of audited events is not always applicable in a global asynchronous network with many arbitrary events occurring at once. Also, different hosts and servers on a distributed TOE can have differing naming policies and values. Further, the use of symbolic names for audit review requires a net-wide convention to avoid redundancies and "name clashes". A multi-object audit repository, portions of which are accessible by a potentially wide variety of authorized users, are usually required if audit repositories are to serve a useful function in distributed systems. Finally, misuse of authority by authorized users can be addressed by systematically avoiding local storage of audit data pertaining to administrator actions. This family defines the response to be taken in case of detected events indicative of a potential security violation. The security audit automatic response family describes requirements for the handling of audit events. The requirement can include requirements for alarms or TSF action (automatic response). The TSF can include the generation of real time alarms, termination of the offending process, disabling of a service, or disconnection or invalidation of a user account. An audit event is defined to be an "potential security violation" when indicated by the components. One or more actions should be taken for follow up action in the event of an alarm. These actions can include informing the authorized user of the alarm, presenting the authorized user with a set of possible containment actions, or options for the authorized user to take corrective actions. The timing of the actions should be carefully considered by the PP, PP-Module, functional package or ST author. At , the TSF shall take actions in case a potential security violation is detected. The management (addition, removal, or modification) of actions Actions taken due to potential security violations The TSF shall take list of actions the author of a PP, PP-Module, functional package or ST specifies the actions to be taken in case of a potential security violation. upon detection of a potential security violation. This family defines requirements for recording the occurrence of security relevant events that take place under TSF control. This family identifies the level of auditing, enumerates the types of events that shall be auditable by the TSF, and identifies the minimum set of audit-related information that should be provided within various audit record types. The security audit data generation family includes requirements to specify the audit events that shall be generated by the TSF for security-relevant events. This family is presented in a manner that avoids a dependency on all components requiring audit support. Each component has an audit subclause developed in which the events to be audited for that functional area are listed. When the PP, PP-Module, functional package or ST is written, the items in the audit area are used to complete the variable in these components. Thus, the specification of what can be audited for a functional area is localized in that functional area. The list of auditable events is entirely dependent on the other functional families within the PP, PP-Module, functional package or ST. Each family definition should therefore include a list of its family-specific auditable events. Each auditable event in the list of auditable events specified in the functional family should correspond to one of the levels of audit event generation specified in this family (i.e. minimal, basic, detailed). This provides the author of a PP, PP-Module, functional package or ST with the information necessary to ensure that all appropriate auditable events are specified in the PP, PP-Module, functional package or ST. The following example shows how auditable events are to be specified in appropriate functional families: The following actions should be auditable if is included in the PP, PP-Module, functional package or ST: minimal: Successful use of the user security attribute administration functions; basic: All attempted uses of the user security attribute administration functions; basic: Identification of which user security attributes have been modified; detailed: With the exception of specific sensitive attribute data items, the new values of the attributes should be captured. Sensitive attribute data items include passwords and cryptographic keys. For each functional component that is chosen, the auditable events that are indicated in that component, at and below the level indicated in should be auditable. So, in the previous example "Basic" would be selected in , the auditable events mentioned in a), b) and c) should be auditable. Observe that the categorization of auditable events (minimal, basic, detailed) is hierarchical in that order. This means that: when minimal audit generation is desired, all auditable events identified as being minimal should be included in the PP, PP-Module, functional package or ST through the use of the appropriate assignment operation; when basic audit generation is desired, all auditable events identified as being either minimal or basic, should also be included in the PP, PP-Module, functional package or ST through the use of the appropriate assignment operation, except when the higher-level event simply provides more detail than the lower level event; when detailed audit generation is desired, all identified auditable events (minimal, basic, and detailed) should be included in the PP, PP-Module, functional package or ST. A PP, PP-Module, functional package or ST author may decide to include other auditable events beyond those required for a given audit level. The PP, PP-Module, functional package or ST may claim only minimal audit capabilities while including most of the basic capabilities because the few excluded capabilities conflict with other PP, PP-Module, functional package or ST constraints (perhaps because they require the collection of unavailable data). The functionality that creates the auditable event should be specified in the PP, PP-Module, functional package or ST as a functional requirement. The following are examples of the types of the events that can be defined as auditable within each PP, PP-Module, functional package or ST functional component: introduction of objects within the control of the TSF into a subject's address space; deletion of objects; distribution or revocation of access rights or capabilities; changes to subject or object security attributes; policy checks performed by the TSF as a result of a request by a subject; the use of access rights to bypass a policy check; use of Identification and Authentication functions; actions taken by an operator, and/or authorized user (such as. suppression of a TSF protection mechanism as human-readable labels); import/export of data from/to removable media (such as printed output, tapes, USB sticks). has a dependency on . If correctness of time is not an issue for this TOE, elimination of this dependency can be justified by the author of a PP, PP-Module, functional package or ST. This component defines requirements to identify the auditable events for which audit records should be generated, and the information to be provided in the audit records. by itself can be used when the SFRs do not require that individual user identities be associated with audit events. This can be appropriate when the PP, PP-Module, functional package or ST also contains privacy requirements. If the user identity needs to be incorporated can be used in addition to . If the subject is a user, the user identity may be recorded as the subject identity. The identity of the user may not yet have been verified if has not been applied. Therefore, in the instance of an invalid login the claimed user identity should be recorded. It should also be considered whether to indicate when a recorded identity has not been authenticated. defines the level of auditable events and specifies the list of data that shall be recorded in each record. The TSF shall be able to generate audit data of the following auditable events: Start-up and shutdown of the audit functions; All auditable events for the minimum basic detailed not specified the author of a PP, PP-Module, functional package or ST should select the level of auditable events called out in the audit subclause of other functional components included in the PP, PP-Module, functional package or ST. This level is one of the following: "minimum", "basic", "detailed" or "not specified". level of audit; other specifically defined auditable events the author of a PP, PP-Module, functional package or ST should select the level of auditable events called out in the audit subclause of other functional components included in the PP, PP-Module, functional package or ST. This level is one of the following: "minimum", "basic", "detailed" or "not specified". . The TSF shall record within the audit data at least the following information: Date and time of the auditable event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; For each auditable event type, based on the auditable event definitions of the functional components included in the PP, PP-Module, functional package or ST, other audit relevant information the author of a PP, PP-Module, functional package or ST should assign, for each of the auditable events included in the PP, PP-Module, functional package or ST, either a list of other audit relevant information to be included in audit events records or none. . This component addresses the requirement of accountability of auditable events at the level of individual user identity. This component should be used in addition to . There is a potential conflict between the audit and privacy requirements. For audit purposes, it can be desirable to know who performed an action. It is possible that a user wants to keep his/her actions to himself/herself and not be identified by other persons such as a site with job offers. Alternatively, it can be required in the Organizational Security Policy that the identity of the users must be protected. In those cases, the objectives for audit and privacy can contradict each other. Therefore, if this requirement is selected and privacy is important, inclusion of the component user pseudonymity should be considered. Requirements on determining the real user name based on its pseudonym are specified in the privacy class. If the identity of the user has not yet been verified through authentication, in the instance of an invalid login the claimed user identity should be recorded. It should be considered to indicate when a recorded identity has not been authenticated. In , the TSF shall associate auditable events to individual user identities. For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. This family defines requirements for automated means that analyze system activity and audit data looking for possible or real security violations. This analysis may work in support of intrusion detection, or automatic response to a potential security violation. The actions to be taken based on the detection can be specified using the family as desired. This family defines requirements for automated means that analyze system activity and audit data looking for possible or real security violations. This analysis can work in support of intrusion detection, or automatic response to a potential security violation. The action to be performed by the TSF on detection of a potential violation is defined in components. For real-time analysis, audit data can be transformed into a useful format for automated treatment, but into a different useful format for delivery to authorized users for review. This component is used to specify the set of auditable events whose occurrence or accumulated occurrence held to indicate a potential violation of the enforcement of the SFRs, and any rules to be used to perform the violation analysis. In , basic threshold detection on the basis of a fixed rule set is required. Maintenance of the rules by (adding, modifying, deletion) of rules from the set of rules Enabling and disabling of any of the analysis mechanisms Automated responses performed by the tool The TSF shall be able to apply a set of rules in monitoring the audited events and based upon these rules indicate a potential violation of the enforcement of the SFRs. The TSF shall enforce the following rules for monitoring audited events: Accumulation or combination of subset of defined auditable events the author of a PP, PP-Module, functional package or ST should identify the subset of defined auditable events whose occurrence or accumulated occurrence need to be detected as an indication of a potential violation of the enforcement of the SFRs. known to indicate a potential security violation; any other rules the author of a PP, PP-Module, functional package or ST should identify the subset of defined auditable events whose occurrence or accumulated occurrence need to be detected as an indication of a potential violation of the enforcement of the SFRs. . A profile is a structure that characterizes the behaviour of users and/or subjects; it represents how the users/subjects interact with the TSF in a variety of ways. Patterns of usage are established with respect to the various types of activity the users/subjects engage in. The ways in which the various types of activity are recorded in the profile are referred to as profile metrics. Patterns of usage: patterns in exceptions raised, patterns in resource utilization (when, which, how), patterns in actions performed. Profile metrics: resource measures, event counters, timers. Each profile represents the expected patterns of usage performed by members of the profile target group. This pattern may be based on past use (historical patterns) or on normal use for users of similar target groups (expected behaviour). A profile target group refers to one or more users who interact with the TSF. The activity of each member of the profile group is used by the analysis tool in establishing the usage patterns represented in the profile. The following are some examples of profile target groups: single user account: one profile per user; group ID or group account: one profile for all users who possess the same group ID or operate using the same group account; operating role: one profile for all users sharing a given operating role; system: one profile for all users of a system. Each member of a profile target group is assigned an individual suspicion rating that represents how closely that member's new activity corresponds to the established patterns of usage represented in the group profile. The sophistication of the anomaly detection tool will largely be determined by the number of target profile groups required by the PP, PP-Module, functional package or ST and the complexity of the required profile metrics. The author of a PP, PP-Module, functional package or ST should enumerate specifically what activity should be monitored and/or analysed by the TSF. The author of a PP, PP-Module, functional package or ST should also identify specifically what information pertaining to the activity is necessary to construct the usage profiles. requires that the TSF maintain profiles of system usage. The word maintain implies that the anomaly detector is actively updating the usage profile based on new activity performed by the profile target members. It is important here that the metrics for representing user activity are defined by the author of a PP, PP-Module, functional package or ST. There can be a thousand different actions an individual can be capable of performing, but the anomaly detector can choose to monitor a subset of that activity. Anomalous activity gets integrated into the profile just like non-anomalous activity (assuming the tool is monitoring those actions). Things that may have appeared anomalous four months ago, can over time become the norm (and vice-versa) as the user's work duties change. The TSF wouldn't be able to capture this notion if it filtered out anomalous activity from the profile updating algorithms. Administrative notification should be provided such that the authorized user understands the significance of the suspicion rating. The author of a PP, PP-Module, functional package or ST should define how to interpret suspicion ratings and the conditions under which anomalous activity is indicated to the mechanism. In , the TSF maintains individual profiles of system usage, where a profile represents the historical patterns of usage performed by members of the profile target group. A profile target group refers to a group of one or more individuals who interact with the TSF. Each member of a profile target group is assigned an individual suspicion rating that represents how well that member's current activity corresponds to the established patterns of usage represented in the profile. This analysis can be performed at runtime or during a post-collection batch-mode analysis. Maintenance (deletion, modification, addition) of the group of users in the profile target group The TSF shall be able to maintain profiles of system usage, where an individual profile represents the historical patterns of usage performed by the member(s) of the profile target group the author of a PP, PP-Module, functional package or ST should specify the profile target group. A single PP, PP-Module, functional package or ST may include multiple profile target groups. . The TSF shall be able to maintain a suspicion rating associated with each user whose activity is recorded in a profile, where the suspicion rating represents the degree to which the user's current activity is found inconsistent with the established patterns of usage represented in the profile. The TSF shall be able to indicate a possible violation of the enforcement of the SFRs when a user's suspicion rating exceeds the following threshold conditions conditions under which anomalous activity is reported by the TSF the author of a PP, PP-Module, functional package or ST should specify conditions under which anomalous activity is reported by the TSF. Conditions may include the suspicion rating reaching a certain value or be based on the type of anomalous activity observed. . In practice, it is at best rare when an analysis tool can detect with certainty when a security violation is imminent. However, there do exist some system events that are so significant that they are always worthy of independent review. Example of such events include the deletion of a key TSF security data file (such as the password file) or activity such as a remote user attempting to gain administrative privilege. These events are referred to as signature events in that their occurrence in isolation from the rest of the system activity are indicative of intrusive activity. The complexity of a given tool will depend greatly on the assignments defined by the author of a PP, PP-Module, functional package or ST in identifying the base set of signature events. The author of a PP, PP-Module, functional package or ST should enumerate specifically what events should be monitored by the TSF in order to perform the analysis. The author of a PP, PP-Module, functional package or ST should identify specifically what information pertaining to the event is necessary to determine if the event maps to a signature event. Administrative notification should be provided such that the authorized user understands the significance of the event and the appropriate possible responses. An effort was made in the specification of these requirements to avoid a dependency on audit data as the sole input for monitoring system activity. This was done in recognition of the existence of previously developed intrusion detection tools that do not perform their analyses of system activity solely through the use of audit data. Examples of other input data include network datagrams, resource/accounting data, or combinations of various system data. The elements of do not require that the TSF implementing the immediate attack heuristics be the same TSF whose activity is being monitored. Thus, one can develop an intrusion detection component that operates independently of the system whose system activity is being analyzed. In , the TSF shall be able to detect the occurrence of signature events that represent a significant threat to enforcement of the SFRs. This search for signature events may occur in real-time or during a post-collection batch-mode analysis. Maintenance (deletion, modification, addition) of the subset of system events The TSF shall be able to maintain an internal representation of the following signature events a subset of system events the author of a PP, PP-Module, functional package or ST should identify a base subset of system events whose occurrence, in isolation from all other system activity, can indicate a violation of the enforcement of the SFRs. These include events that by themselves indicate a clear violation to the enforcement of the SFRs, or whose occurrence is so significant that they warrant actions. that may indicate a violation of the enforcement of the SFRs. The TSF shall be able to compare the signature events against the record of system activity discernible from an examination of the information to be used to determine system activity the author of a PP, PP-Module, functional package or ST should specify the information used to determine system activity. This information is the input data used by the analysis tool to determine the system activity that has occurred on the TOE. This data may include audit data, combinations of audit data with other system data, or may consist of data other than the audit data. The author of a PP, PP-Module, functional package or ST should define precisely what system events and event attributes are being monitored within the input data. . The TSF shall be able to indicate a potential violation of the enforcement of the SFRs when a system event is found to match a signature event that indicates a potential violation of the enforcement of the SFRs. In practice, it is at best rare when an analysis tool can detect with certainty when a security violation is imminent. However, there do exist some system events that are so significant they are always worthy of independent review. Example of such events include the deletion of a key TSF security data file (such as the password file) or activity such as a remote user attempting to gain administrative privilege. These events are referred to as signature events in that their occurrence in isolation from the rest of the system activity are indicative of intrusive activity. Event sequences are an ordered set of signature events that can indicate intrusive activity. The complexity of a given tool will depend greatly on the assignments defined by the author of a PP, PP-Module, functional package or ST in identifying the base set of signature events and event sequences. The author of a PP, PP-Module, functional package or ST should enumerate specifically what events should be monitored by the TSF in order to perform the analysis. The author of a PP, PP-Module, functional package or ST should identify specifically what information pertaining to the event is necessary to determine if the event maps to a signature event. Administrative notification should be provided such that the authorized user understands the significance of the event and the appropriate possible responses. An effort was made in the specification of these requirements to avoid a dependency on audit data as the sole input for monitoring system activity. This was done in recognition of the existence of previously developed intrusion detection tools that do not perform their analyses of system activity solely through the use of audit data. Examples of other input data include network datagrams, resource/accounting data, or combinations of various system data. Levelling, therefore, requires the author of a PP, PP-Module, functional package or ST to specify the type of input data used to monitor system activity. The elements of do not require that the TSF implementing the complex attack heuristics be the same TSF whose activity is being monitored. Thus, one can develop an intrusion detection component that operates independently of the system whose system activity is being analyzed. In , the TSF shall be able to represent and detect multi-step intrusion scenarios. The TSF is able to compare system events (possibly performed by multiple individuals) against event sequences known to represent entire intrusion scenarios. The TSF shall be able to indicate when a signature event or event sequence is found that indicates a potential violation of the enforcement of the SFRs. Maintenance (deletion, modification, addition) of the subset of system events Maintenance (deletion, modification, addition) of the set of sequences of system events The TSF shall be able to maintain an internal representation of the following event sequences of known intrusion scenarios list of sequences of system events whose occurrence are representative of known penetration scenarios the author of a PP, PP-Module, functional package or ST should identify a base set of lists of sequences of system events whose occurrence are representative of known penetration scenarios. These event sequences represent known penetration scenarios. Each event represented in the sequence should map to a monitored system event, such that as the system events are performed, they are bound (mapped) to the known penetration event sequences. and the following signature events a subset of system events the author of a PP, PP-Module, functional package or ST should identify a base subset of system events whose occurrence, in isolation from all other system activity, may indicate a violation of the enforcement of the SFRs. These include events that by themselves indicate a clear violation to the SFRs, or whose occurrence is so significant they warrant action. that may indicate a potential violation of the enforcement of the SFRs. The TSF shall be able to compare the signature events and event sequences against the record of system activity discernible from an examination of the information to be used to determine system activity the author of a PP, PP-Module, functional package or ST should specify the information used to determine system activity. This information is the input data used by the analysis tool to determine the system activity that has occurred on the TOE. This data may include audit data, combinations of audit data with other system data, or may consist of data other than the audit data. The author of a PP, PP-Module, functional package or ST should define precisely what system events and event attributes are being monitored within the input data. . The TSF shall be able to indicate a potential violation of the enforcement of the SFRs when system activity is found to match a signature event or event sequence that indicates a potential violation of the enforcement of the SFRs. This family defines the requirements for tools that are made available to authorized users to assist in the review of audit data. The Security audit review family defines requirements related to review of the audit information. These functions should allow pre-storage or post-storage audit selection. An example of requirement related to review of the audit information is the ability to selectively review: the actions of one or more users (such as. identification, authentication, TOE entry, and access control actions); the actions performed on a specific object or TOE resource; all of a specified set of audited exceptions; or actions associated with a specific SFR attribute. The distinction between audit reviews is based on functionality. Audit review (only) encompasses the ability to view audit data. Selectable review is more sophisticated and requires the ability to select subsets of audit data based on a single criterion or multiple criteria with logical (i.e. and/or) relations and order the audit data before it is reviewed. This component provides authorized users the capability to obtain and interpret the information. In the case of human users this information needs to be in a human understandable presentation. In the case of external IT entities, the information needs to be unambiguously represented in an electronic fashion. This component is also used to specify that users and/or authorized users can read the audit records. These audit records will be provided in a manner appropriate to the user. There are different types of users (human users, machine users) that can have different needs. The content of the audit records that can be viewed can be specified. provides the capability to read information from the audit data. Maintenance (deletion, modification, addition) of the group of users with read access right to the audit records Reading of information from the audit records The TSF shall provide authorized users the author of a PP, PP-Module, functional package or ST should specify the authorized users that can use this capability. If appropriate the author of a PP, PP-Module, functional package or ST may include security roles (see ). with the capability to read list of audit information the author of a PP, PP-Module, functional package or ST should specify the type of information the specified user is permitted to obtain from the audit records. from the audit data. The TSF shall provide the audit data in a manner suitable for the user to interpret the information. This component specifies that any users not identified in will not be able to read the audit records. requires that there are no other users except those that have been identified in that can read the information. Unsuccessful attempts to read information from the audit records The TSF shall prohibit all users read access to the audit data, except those users that have been granted explicit read access. This component is used to specify that it should be possible to perform selection of the audit data to be reviewed. If based on multiple criteria, those criteria should be related together with logical (i.e. "and" or "or") relations, and the tools should provide the ability to manipulate audit data Means of manipulating audit data include sorting and filtering. requires audit review tools to select the audit data to be reviewed based on criteria. The parameters used for the viewing The TSF shall provide the ability to apply methods of selection and/or ordering the author of a PP, PP-Module, functional package or ST should specify whether capabilities to select and/or order audit data is required from the TSF. of audit data based on criteria with logical relations the author of a PP, PP-Module, functional package or ST should assign the criteria, possibly with logical relations, to be used to select the audit data for review. The logical relations are intended to specify whether the operation can be on an individual attribute or a collection of attributes. . This family defines requirements to select the set of events to be audited during TOE operation from the set of all auditable events. The security audit event selection family provides requirements related to the capabilities of identifying which of the possible auditable events are to be audited. The auditable events are defined in the family, but those events should be defined as being selectable in this component to be audited. This family ensures that it is possible to keep the audit trail from becoming so large that it becomes useless, by defining the appropriate granularity of the selected security audit events. This component defines the selection criteria used, and the resulting audited subsets of the set of all auditable events, based on user attributes, subject attributes, object attributes, or event types. The existence of individual user identities is not assumed for this component. This allows for TOEs such as routers that may not support the notion of users. For a distributed environment, the host identity can be used as a selection criterion for events to be audited. The management function will handle the rights of authorized users to query or modify the selections. requires the ability to select the set of events to be audited from the set of all auditable events, identified in , based upon attributes to be specified by the author of a PP, PP-Module, functional package or ST. Maintenance of the rights to view/modify the audit data All modifications to the audit configuration that occur while the audit collection functions are operating The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes: object identity user identity subject identity host identity event type the author of a PP, PP-Module, functional package or ST should select whether the security attributes upon which audit selectivity is based, is related to object identity, user identity, subject identity, host identity, or event type. list of additional attributes that audit selectivity is based upon the author of a PP, PP-Module, functional package or ST should select whether the security attributes upon which audit selectivity is based, is related to object identity, user identity, subject identity, host identity, or event type. This family defines the requirements for the TSF to be able to create and maintain a secure audit trail. Stored audit data refers to those data stored within an audit trail, and not to any audit data that has been retrieved (to temporary storage) through selection. The security audit data storage family describes requirements for storing audit data for later use, including requirements controlling the loss of audit information due to TOE failure, attack and/or exhaustion of storage space. In a distributed environment, as the location of the audit trail is in the TSF, but not necessarily co-located with the function generating the audit data, the author of a PP, PP-Module, functional package or ST can request authentication of the originator of the audit record, or non-repudiation of the origin of the record prior to storing this record in the audit trail. The TSF will protect the stored audit records in the audit trail from unauthorised deletion and modification. It is noted that in some TOEs the auditor (role) can not be authorized to delete the audit records for a certain period of time. is dependent upon , if "transmit the generated audit data to an external IT entity using a trusted channel according to " is not selected then the author of a PP, PP-Module, functional package or ST can satisfy the dependency by providing the rationale explaining why it was not selected. requires that the storage location(s) for audit data be specified. Maintenance of remote audit storage locations Changes in the location of remote audit data storage The TSF shall be able to store generated audit data on the TOE itself transmit the generated audit data to an external IT entity using a trusted channel according to other storage location(s) If additional or alternative storage locations for audit data need to be specified by the author of a PP, PP-Module, functional package or ST then this requirement can be specified in using the assignment found within the selection. . the author of a PP, PP-Module, functional package or ST should select where the audit data is stored. Audit data may be stored on the TOE itself, be transmitted to an external entity using a trusted channel, or other storage options can be specified in the assignment. In a distributed environment, as the location of the audit trail is in the TSF, but not necessarily co-located with the function generating the audit data, the author of a PP, PP-Module, functional package or ST can request authentication of the originator of the audit record, or non-repudiation of the origin of the record prior storing this record in the audit trail. The TSF will protect the stored audit data in the audit trail from unauthorized deletion and modification. It is noted that in some TOEs the auditor (role) can not be authorized to delete the audit records for a certain period of time. requires that protections are placed on the audit data. It will be protected from unauthorized deletion and/or modification. The TSF shall protect the stored audit data in the audit trail from unauthorized deletion. The TSF shall be able to prevent detect the author of a PP, PP-Module, functional package or ST should specify whether the TSF shall prevent or only be able to detect modifications of the stored audit data in the audit trail. Only one of these options may be chosen. unauthorized modifications to the stored audit data in the audit trail. This component allows the author of a PP, PP-Module, functional package or ST to specify to which metrics the audit trail should conform. In a distributed environment, as the location of the audit trail is in the TSF, but not necessarily co-located with the function generating the audit data, the author of a PP, PP-Module, functional package or ST can request authentication of the originator of the audit record, or non-repudiation of the origin of the record prior storing this record in the audit trail. specifies the guarantees that the TSF maintains over the audit data given the occurrence of an undesired condition. Maintenance of the parameters that control the audit data storage capability The TSF shall protect the stored audit data in the audit trail from unauthorized deletion. The TSF shall be able to prevent detect unauthorized modifications to the stored audit data in the audit trail. The TSF shall ensure that metric for saving audit data PP, PP-Module, functional package or ST author should specify the metric that the TSF must ensure with respect to the stored audit records. This metric limits the data loss by enumerating the number of records that must be kept, or the time that records are guaranteed to be maintained. stored audit data will be maintained when the following conditions occur: audit data storage exhaustion failure attack . This component specifies the behaviour of the TOE if the audit trail is full: either audit records are ignored, or the TOE is frozen such that no audited events can take place. The requirement also states that no matter how the requirement is instantiated, the authorized user with specific rights to this effect, can continue to generate audited events (actions). The reason is that otherwise the authorized user can not even reset the TOE. Consideration should be given to the choice of the action to be taken by the TSF in the case of audit storage exhaustion, as ignoring events, which provides better availability of the TOE, will also permit actions to be performed without being recorded and without the user being accountable. specifies actions to be taken if a threshold on the stored audit data is exceeded. Maintenance (deletion, modification, addition) of actions to be taken in case of imminent audit data storage failure Actions taken due to exceeding of a threshold The TSF shall actions to be taken in case of possible audit data storage failure if the audit data storage exceeds pre-defined limit . This component requires that actions will be taken when the audit trail exceeds certain pre-defined limits. specifies actions to be taken in the case that audit data storage is full. Maintenance (deletion, modification, addition) of actions to be taken in case of audit data storage failure Actions taken due to the audit data storage failure The TSF shall ignore audited events "prevent audited events except those taken by the authorized user with special rights" overwrite the oldest stored audit records other actions to be taken in case of audit storage failure and conditions for the actions the author of a PP, PP-Module, functional package or ST should specify other actions that should be taken in case of audit storage failure, such as informing the authorized user. If there is no other action to be taken in case of audit storage failure, this assignment can be completed with "none". the author of a PP, PP-Module, functional package or ST should select whether the TSF shall ignore audited actions, or whether it should prevent audited actions from happening, or whether the oldest audit records should be overwritten when the TSF can no longer store audit records. Only one of these options may be chosen. if the audit data storage is full. This class provides two families specifically concerned with assuring the identity of a party participating in a data exchange. These families are related to assuring the identity of the originator of transmitted information (proof of origin) and assuring the identity of the recipient of transmitted information (proof of receipt). These families ensure that an originator cannot deny having sent the message, nor can the recipient deny having received it. This class describes requirements specifically of interest for TOEs that are used for the transport of information. Families within this class deal with non-repudiation. In this class, the concept of "information" is used. This information should be interpreted as the object being communicated, and can contain an electronic mail message, a file, or a set of predefined attribute types. In the literature, the terms "proof of receipt" and "proof of origin" are commonly used terms. However, it is recognized that the term "proof" can be interpreted in a legal sense to imply a form of mathematical rationale. The components in this class interpret the de-facto use of the word "proof" in the context of "evidence" that the TSF demonstrates the non-repudiated transport of types of information. Non-repudiation of origin ensures that the originator of information cannot successfully deny having sent the information. This family requires that the TSF provide a method to ensure that a subject that receives information during a data exchange is provided with evidence of the origin of the information. This evidence can then be verified by either this subject or other subjects. Non-repudiation of origin defines requirements to provide evidence to users/subjects about the identity of the originator of some information. The originator cannot successfully deny having sent the information because evidence of origin provides evidence of the binding between the originator and the information sent. The recipient or a third party can verify the evidence of origin. This evidence should not be forgeable. Evidence of origin can be a digital signature. If the information or the associated attributes are altered in any way, validation of the evidence of origin can fail. Therefore, a PP, PP-Module, functional package or ST author should consider including integrity requirements such as in the PP, PP-Module, functional package or ST. In non-repudiation, there are several different roles involved, each of which can be combined in one or more subjects. The first role is a subject that requests evidence of origin (only in ). The second role is the recipient and/or other subjects to which the evidence is provided. The third role is a subject that requests verification of the evidence of origin. Subject that requests evidence of origin: a recipient or a third party such as an arbiter. Subject to which the evidence is provided: A notary. The author of a PP, PP-Module, functional package or ST specifies the conditions that must be met to be able to verify the validity of the evidence. An example of a condition which can be specified is where the verification of evidence must occur within 24 h. These conditions, therefore, allow the tailoring of the non-repudiation to legal requirements, such as being able to provide evidence for several years. In most cases, the identity of the recipient will be the identity of the user who received the transmission. In some instances, the author of a PP, PP-Module, functional package or ST does not want the user identity to be exported. In that case, the author of a PP, PP-Module, functional package or ST considers whether it is appropriate to include this class, or whether the identity of the transport service provider or the identity of the host should be used. In addition to (or instead of) the user identity, a PP, PP-Module, functional package or ST author can be more concerned about the time the information was transmitted. For example, requests for proposals must be transmitted before a certain date in order to be considered. In such instances, these requirements can be customized to provide a timestamp indication (time of origin). There are no user application notes specified for this component. requires the TSF to provide subjects with the capability to request evidence of the origin of information. The management of changes to information types, fields, originator attributes and recipients of evidence The identity of the user who requested that evidence of origin would be generated The invocation of the non-repudiation service Identification of the information, the destination, and a copy of the evidence provided The identity of the user who requested a verification of the evidence The TSF shall be able to generate evidence of origin for transmitted list of information types the author of a PP, PP-Module, functional package or ST should fill in the types of information subject to the evidence of origin function. at the request of the originator recipient list of third parties An example of the type of information is "electronic mail messages". . The TSF shall be able to relate the list of attributes the author of a PP, PP-Module, functional package or ST should fill in the list of the attributes that shall be linked to the information. of the originator of the information, and the list of information fields of the information to which the evidence applies. The TSF shall provide a capability to verify the evidence of origin of information to originator recipient list of third parties the author of a PP, PP-Module, functional package or ST should specify the user/subject who can verify the evidence of origin. the author of a PP, PP-Module, functional package or ST should fill in the list of limitations under which the evidence can be verified. given limitations on the evidence of origin . There are no user application notes specified for this component. requires that the TSF always generate evidence of origin for transmitted information. The invocation of the non-repudiation service Identification of the information, the destination, and a copy of the evidence provided The identity of the user who requested a verification of the evidence The TSF shall enforce the generation of evidence of origin for transmitted list of information types the author of a PP, PP-Module, functional package or ST should fill in the types of information subject to the evidence of origin function. at all times. The TSF shall be able to relate the list of attributes the author of a PP, PP-Module, functional package or ST should fill in the list of the attributes that shall be linked to the information; for example, originator identity, time of origin, and location of origin. of the originator of the information, and the list of information fields the author of a PP, PP-Module, functional package or ST should fill in the list of information fields within the information over which the attributes provide evidence of origin, such as the body of a message. of the information to which the evidence applies. The TSF shall provide a capability to verify the evidence of origin of information to originator recipient list of third parties the author of a PP, PP-Module, functional package or ST should specify the user/subject who can verify the evidence of origin. the author of a PP, PP-Module, functional package or ST should fill in the list of limitations under which the evidence can be verified. given limitations on the evidence of origin an example would be that the evidence can only be verified within a 24-h time interval. . Non-repudiation of receipt ensures that the recipient of information cannot successfully deny receiving the information. This family requires that the TSF provide a method to ensure that a subject that transmits information during a data exchange is provided with evidence of receipt of the information. This evidence can then be verified by either this subject or other subjects. Non-repudiation of receipt defines requirements to provide evidence to other users/subjects that the information was received by the recipient. The recipient cannot successfully deny having received the information because evidence of receipt provides evidence of the binding between the recipient attributes and the information. The originator or a third party can verify the evidence of receipt. This evidence should not be forgeable. An example of a receipt is a digital signature. It should be noted that the provision of evidence that the information was received does not necessarily imply that the information was read or comprehended, but only delivered. If the information or the associated attributes are altered in any way, validation of the evidence of receipt with respect to the original information can fail. Therefore, a PP, PP-Module, functional package or ST author should consider including integrity requirements such as in the PP, PP-Module, functional package or ST. In non-repudiation, there are several different roles involved, each of which can be combined in one or more subjects. The first role is a subject that requests evidence of receipt (only in ). The second role is the recipient and/or other subjects to which the evidence is provided). The third role is a subject that requests verification of the evidence of receipt, for example, an originator or a third party such as an arbiter. A recipient or subject can be a notary. The author of a PP, PP-Module, functional package or ST specifies the conditions that must be met to be able to verify the validity of the evidence. An example of a condition which can be specified is where the verification of evidence must occur within 24 h. These conditions, therefore, allow the tailoring of the non-repudiation to legal requirements, such as being able to provide evidence for several years. In most cases, the identity of the recipient will be the identity of the user who received the transmission. In some instances, the author of a PP, PP-Module, functional package or ST does not want the user identity to be exported. In that case, the author of a PP, PP-Module, functional package or ST considers whether it is appropriate to include this class, or whether the identity of the transport service provider or the identity of the host should be used. In addition to (or instead of) the user identity, a PP, PP-Module, functional package or ST author can be more concerned about the time the information was received. When an offer expires at a certain date, orders must be received before a certain date in order to be considered. In such instances, these requirements can be customized to provide a timestamp indication (time of receipt). There are no user application notes specified for this component. requires the TSF to provide subjects with a capability to request evidence of the receipt of information. The management of changes to information types, fields, originator attributes and third-party recipients of evidence The identity of the user who requested that evidence of receipt would be generated The invocation of the non-repudiation service Identification of the information, the destination, and a copy of the evidence provided The identity of the user who requested a verification of the evidence The TSF shall be able to generate evidence of receipt for received list of information types the author of a PP, PP-Module, functional package or ST should fill in the types of information subject to the evidence of receipt function, for example, electronic mail messages. at the request of the originator recipient list of third parties the author of a PP, PP-Module, functional package or ST should specify the user/subject who can request evidence of receipt. the author of a PP, PP-Module, functional package or ST, dependent on the selection, should specify the third parties that can request evidence of receipt. . The TSF shall be able to relate the list of attributes the author of a PP, PP-Module, functional package or ST should fill in the list of the attributes that shall be linked to the information; for example, recipient identity, time of receipt, and location of receipt. of the recipient of the information, and the list of information fields the author of a PP, PP-Module, functional package or ST should fill in the list of information fields with the fields within the information over which the attributes provide evidence of receipt, such as the body a message. of the information to which the evidence applies. The TSF shall provide a capability to verify the evidence of receipt of information to originator recipient list of third parties the author of a PP, PP-Module, functional package or ST should specify the user/subjects who can verify the evidence of receipt. the author of a PP, PP-Module, functional package or ST should fill in the list of limitations under which the evidence can be verified. For example, the evidence can only be verified within a 24-hour time interval. An assignment of "immediate" or "indefinite" is acceptable. given limitations on the evidence of receipt the author of a PP, PP-Module, functional package or ST, dependent on the selection, should specify the third parties that can verify the evidence of receipt. . There are no user application notes specified for this component. requires that the TSF always generate evidence of receipt for received information. The invocation of the non-repudiation service Identification of the information, the destination, and a copy of the evidence provided The identity of the user who requested a verification of the evidence The TSF shall enforce the generation of evidence of receipt for received list of information types the author of a PP, PP-Module, functional package or ST should fill in the types of information subject to the evidence of receipt function. at all times. The TSF shall be able to relate the list of attributes the author of a PP, PP-Module, functional package or ST should fill in the list of the attributes that shall be linked to the information. of the recipient of the information, and the list of information fields an example would be the recipient identity, time of receipt, and location of receipt. of the information to which the evidence applies. The TSF shall provide a capability to verify the evidence of receipt of information to originator recipient list of third parties the author of a PP, PP-Module, functional package or ST should specify the user/subjects who can verify the evidence of receipt. the author of a PP, PP-Module, functional package or ST should fill in the list of limitations under which the evidence can be verified. An assignment of "immediate" or "indefinite" is acceptable. given limitations on the evidence of receipt an example would be when the evidence can only be verified within a 24-h time interval. . The TSF may employ cryptographic functionality to help satisfy several high-level security objectives. These include, but are not limited to: identification and authentication, non-repudiation, trusted path, trusted channel, and data separation. This class is used when the TOE implements cryptographic functions, the implementation of which can be in hardware, firmware and/or software. The TSF may employ cryptographic functionality to help satisfy several high-level security objectives. These include, but are not limited to: identification and authentication; non-repudiation; trusted path; trusted channel; data separation. This class is used when the TOE implements cryptographic functions, the implementation of which can be in hardware, firmware and/or software. The class is composed of four families: , , , and . The family addresses the management aspects of cryptographic keys; the family is concerned with the operational use of those cryptographic keys; the family provides requirements for generating random bits; and the is concerned with ensuring that random numbers meet defined quality metrics. For each cryptographic key generation method implemented by the TOE, if any, the author of a PP, PP-Module, functional package or ST should select the component. For each cryptographic key distribution method implemented by the TOE, if any, the author of a PP, PP-Module, functional package or ST should select the . For each cryptographic key access method implemented by the TOE, if any, the author of a PP, PP-Module, functional package or ST should select the . For each cryptographic key derivation method implemented by the TOE, if any, the author of a PP, PP-Module, functional package or ST should select the . For each cryptographic key destruction method implemented by the TOE, if any, the author of a PP, PP-Module, functional package or ST should select the component. For each cryptographic operation (such as digital signature, data encryption, key agreement, secure hash, etc.) performed by the TOE, if any, the author of a PP, PP-Module, functional package or ST should select the component. For each deterministic random bit generation service implemented by the TOE, if any, the author of a PP, PP-Module, functional package or ST should select the component. For each external seeding source used by the TOE, if any, the author of a PP, PP-Module, functional package or ST should select the component. For each internal seeding source (single) used by the TOE, if any, the author of a PP, PP-Module, functional package or ST should select the component. Where internal seeding source (multiple) is to be specified, the author of a PP, PP-Module, functional package or ST should select the component. For cases where the TOE combines entropy sources, the component should be specified by PP, PP-Module, functional package or ST author. For each random bit generation service implemented by the TOE, the author of a PP, PP-Module, functional package or ST should specify the component. For each random number generation service implemented by the TOE, the author of a PP, PP-Module, functional package or ST should specify the component. Cryptographic functionality may be used to meet objectives specified in class , and in families , , , , , , to meet a variety of objectives. In the cases where cryptographic functionality is used to meet objectives for other classes, the individual functional components specify the objectives that cryptographic functionality must satisfy. The objectives in class should be used when assurance for the cryptographic functionality of the TOE is sought by consumers. Cryptographic keys must be managed throughout their life cycle. This family is intended to support that lifecycle and consequently defines requirements for the following activities: cryptographic key generation; cryptographic key distribution; cryptographic key access; cryptographic key derivation; timing and event of cryptographic key destruction. This family should be included whenever there are functional requirements for the management of cryptographic keys. Previous editions of this document specified .4 which has been deprecated in this edition of this document. In order to preserve consistency when applying different editions of this document, the component number has not been re-used. Cryptographic keys need to be managed throughout their lifetime. The typical events in the lifecycle of a cryptographic key include but are not limited to key generation or derivation, distribution, entry, storage, access, and destruction. backup; escrow; archive; recovery. The inclusion of other stages is dependent on the key management strategy being implemented, as the TOE is not always involved in all of the key life-cycle phases. The TOE may only generate and distribute cryptographic keys. This family is intended to support the cryptographic key lifecycle and consequently defines requirements for the following activities: cryptographic key generation; cryptographic key derivation; cryptographic key distribution; cryptographic key access; cryptographic key destruction. This family should be included whenever there are functional requirements for the management of cryptographic keys. If is included in the PP, PP-Module, functional package or ST then, in the context of the events being audited: the object attributes may include the assigned user for the cryptographic key, the user role, the cryptographic operation that the cryptographic key is to be used for, the cryptographic key identifier and the cryptographic key validity period; the object value may include the values of cryptographic key(s) and parameters excluding any sensitive information (such as secret or private cryptographic keys). Typically, random numbers are used to generate cryptographic keys. If this is the case, then should be used instead of the component . In cases where random number generation is required for purposes other than for the generation of cryptographic keys, the component should be used. Evaluators should refer to CC Part 1, B.4 for information in regard to the use of standards specified in . has a dependency on , the dependency should be understood as the dependency of two directions, 1) destruction of key derivation key, and 2) destruction of derived keys. Evaluators should keep in mind that the dependency of two directions shall be fulfilled, and should also consider any intermediate values (such as those from key establishment) that should be destroyed in order to preserve the confidentiality of the key. This component requires the cryptographic key sizes and method used to generate cryptographic keys to be specified, this may be in accordance with an assigned standard. It should be used to specify the cryptographic key sizes and the method used to generate the cryptographic keys. Only one instance of the component is needed for the same method and multiple key sizes. The key size may be common or different for the various entities and may be either the input to or the output from the method. An example of a method is an algorithm. requires cryptographic keys to be generated in accordance with a specified algorithm and key sizes which can be based on an assigned standard. Success and failure of the activity The object attribute(s), and object value(s) excluding any sensitive information The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm cryptographic key generation algorithm the author of a PP, PP-Module, functional package or ST should specify the cryptographic key generation algorithm to be used. and specified cryptographic key sizes cryptographic key sizes the author of a PP, PP-Module, functional package or ST should specify the cryptographic key sizes to be used. The key sizes specified should be appropriate for the algorithm and its intended use. that meet the following: list of standards the author of a PP, PP-Module, functional package or ST should specify the assigned standard that documents the method used to generate cryptographic keys. The assigned standard may comprise none, one or more actual standards publications, for example, from international, national, industry or organizational standards. . This component requires the method used to distribute cryptographic keys to be specified, this may be in accordance with an assigned standard. See CC Part 1 for information on using standards in PPs, PP-Modules, functional packages and STs. requires cryptographic keys to be distributed in accordance with a specified distribution method which can be based on an assigned standard. The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method cryptographic key distribution method the author of a PP, PP-Module, functional package or ST should specify the cryptographic key distribution method to be used. that meets the following: list of standards the author of a PP, PP-Module, functional package or ST should specify the assigned standard that documents the method used to distribute cryptographic keys. The assigned standard may comprise none, one or more actual standards publications, for example, from international, national, industry or organizational standards. . This component is intended to allow the specification of requirements on the usage of keys outside the TOE (e.g. backup, archival, escrow, recovery) and requires the methods used to access cryptographic keys be specified, this may be in accordance with an assigned standard. is not intended to postulate the access control on cryptographic keys. requires access to cryptographic keys to be performed in accordance with a specified access method which can be based on an assigned standard. The TSF shall perform type of cryptographic key access the author of a PP, PP-Module, functional package or ST should specify the type of cryptographic key access being used. in accordance with a specified cryptographic key access method cryptographic key access method examples of types of cryptographic key access include (but are not limited to) cryptographic key backup, cryptographic key archival, cryptographic key escrow, and cryptographic key recovery. that meets the following: list of standards the author of a PP, PP-Module, functional package or ST should specify the cryptographic key access method to be used. . This component requires the specification of the methods and parameters associated with the key derivation for a specified type of key. has a dependency on , the dependency should be understood as the dependency of two directions, 1) destruction of key derivation key, and 2) destruction of derived keys. PP, PP-Module, functional package and ST authors should keep in mind that the dependency of two directions shall be fulfilled and should also consider any intermediate values (such as those from key establishment) that should be destroyed in order to preserve the confidentiality of the key. requires that the methods, standards, and parameters for key-derivation are specified. The TSF shall derive cryptographic keys key type from input parameters in accordance with a specified key derivation algorithm key derivation algorithm and specified cryptographic key sizes list of key sizes that meet the following: list of standards . This component requires the list of keys, including any keying material and the method used to destroy cryptographic keys to be specified, this can be in accordance with an assigned standard. The purpose of the destruction of cryptographic keys and keying material is to prevent their recovery in consideration of threats related to their compromise. Keying material includes keys and initialization vectors necessary to establish and maintain cryptographic keying relationships. When a DRBG is used to generate a cryptographic key or any keying material, and the PP/ST author desires to protect the DRBG state to avoid the possibility that knowledge of this state can compromise the key or keying material, then the PP/ST author includes DRBG entropy input, seed input, and internal state of the DRBG in the assignment in . See also regarding the destruction of the DRBG state using the uninstantiate operation. requires cryptographic keys to be destroyed in accordance with specified destruction methods which can be based on an assigned standard. The TSF shall destroy list of cryptographic keys (including keying material) when no longer needed other circumstances for key or keying material destruction the author of a PP, PP-Module, functional package or ST selects the circumstances of the destruction of key or key material. . The TSF shall destroy cryptographic keys and keying material specified by in accordance with a specified cryptographic key destruction method cryptographic key destruction method the author of a PP, PP-Module, functional package or ST provides the cryptographic key destruction method and the standards specifying the cryptographic key destruction method. that meets the following: list of standards . In order for a cryptographic operation to function correctly, the operation shall be performed in accordance with a specified algorithm and with a cryptographic key of a specified size. This family should be included whenever there are requirements for cryptographic operations to be performed. Typical cryptographic operations include data encryption and/or decryption, digital signature generation and/or verification, cryptographic checksum generation for integrity and/or verification of checksum, secure hash (message digest), cryptographic key encryption and/or decryption, and cryptographic key agreement. A cryptographic operation may have cryptographic mode(s) of operation associated with it. If this is the case, then the cryptographic mode(s) shall be specified. Examples of cryptographic modes of operation are cipher block chaining, output feedback mode, electronic code book mode, and cipher feedback mode. Cryptographic operations may be used to support one or more TOE security services. The component can need to be iterated more than once depending on: the user application for which the security service is being used; the use of different cryptographic algorithms and/or cryptographic key sizes; the type or sensitivity of the data being operated on. If is included in the PP, PP-Module, functional package or ST then, in the context of the cryptographic operation events being audited: the types of cryptographic operation may include digital signature generation and/or verification, cryptographic checksum generation for integrity and/or for verification of checksum, secure hash (message digest) computation, data encryption and/or decryption, cryptographic key encryption and/or decryption, cryptographic key agreement, and random number generation; the subject attributes may include subject role(s) and user(s) associated with the subject; the object attributes may include the assigned user for the cryptographic key, user role, cryptographic operation the cryptographic key is to be used for, cryptographic key identifier, and the cryptographic key validity period. When specifying cryptographic operations, the author of a PP, PP-Module, functional package or ST should perform due diligence in order to have confidence that the specified cryptographic operations are appropriate for the selected assurance requirements and in consideration of the technology types, environment and use cases of the TOE. In some cases, certification bodies can apply policies in regard to the selection of cryptographic operations. (See CEM, A.6 n). This component requires the cryptographic algorithm and key size used to perform specified cryptographic operation(s) which can be based on an assigned standard. The dependencies to or will be required for cryptographic algorithm operations which internally generate random numbers. DSA signature generation, ECDSA signature generation, RSASSA-PSS signature generation. The dependencies to or may not be necessary for deterministic cryptographic algorithm operations. AES encryption / decryption in ECB mode. requires a cryptographic operation to be performed in accordance with a specified algorithm and with a cryptographic key of specified sizes. The specified algorithm and cryptographic key sizes can be based on an assigned standard. Success and failure, and the type of cryptographic operation Any applicable cryptographic mode(s) of operation, subject attributes and object attributes The TSF shall perform list of cryptographic operations the author of a PP, PP-Module, functional package or ST specifies the cryptographic operations being performed. Typical cryptographic operations include digital signature generation and/or verification, cryptographic checksum generation for integrity and/or for verification of checksum, secure hash (message digest) computation, data encryption and/or decryption, cryptographic key encryption and/or decryption, cryptographic key agreement, and random number generation. The cryptographic operation may be performed on user data or TSF data. in accordance with a specified cryptographic algorithm cryptographic algorithm the author of a PP, PP-Module, functional package or ST should specify the cryptographic algorithm to be used. Examples of typical cryptographic algorithms include, but are not limited to, DES, RSA and IDEA. and cryptographic key sizes cryptographic key sizes the author of a PP, PP-Module, functional package or ST should specify the cryptographic key sizes to be used. The key sizes specified should be appropriate for the algorithm and its intended use. that meet the following: list of standards . Components in this family address the requirements for random bit/number generation. When specifying random bit generation methods, the author of a PP, PP-Module, functional package or ST should perform due diligence in order to have confidence that the specifications are appropriate for the selected assurance requirements and in consideration of the technology types, environment and use cases of the TOE. In some cases, certification bodies can apply policies in regard to the selection of random bit generators. (See CEM, A.6 n). For , these dependencies shall always be met. CC Part 1, 8.3 c) allows a justification to be provided if a dependency is not met is not allowed for this component. Reseeding is the typical mechanism for updating RBG state. If reseeding is not feasible, the TSF should uninstantiate RBGs rather than produce output that is of insufficient quality. "Uninstantiate" means that the internal state of the RBG is no longer available for use. The situation "never" should be selected only if the RBG cannot be reseeded or uninstantiated. The situation "on demand" indicates that there is an interface to trigger reseeding or uninstantiating of the RBG, whether internal to the TOE or presented as a TSFI (e.g. an API call). The situation "on the condition" allows the PP/ST author to specify application-specific conditions for reseeding. The list of standards should specify the reseed interval, and procedures for uninstantiating and reseeding. This assignment should be "None" if the situation is "never". Health tests for the RBG are specified in . If a TOE needs to protect the DRBG state to avoid the possibility that knowledge of this state can compromise a key or keying material derived from its output, then the PP/ST author will include DRBG entropy input, seed input, and internal state of the DRBG in the assignment in an instance of . This applies particularly where neither "reseeding" nor "re-instantiating" apply in the last selection of (and therefore where a different method of destruction needs to be specified). requires random bit generation to be performed in accordance with selected standards. It also specifies whether the initial seeding is done via an internal or external noise source, as well as when and how an RBG's state is updated. Failure of the randomization process, failure to initialize or reseed (as supported by the technology) The TSF shall perform deterministic random bit generation services using RBG algorithm in accordance with list of standards after initialization with a seed. The TSF shall use a TSF noise source name of noise source TSF interface for seeding for initialized seeding. The TSF shall update the RBG state by reseeding uninstantiating and re-instantiating using a TSF noise source name of noise source TSF interface for seeding in the following situations: never on demand on the condition: condition after time in accordance with list of standards . For this component, the interface to obtain the entropy noise source can be used multiple times to provide input. For instance, if the input length is 128 bits, it can be used twice to gather 256 bits. In this instance, the 128 bits would not be provided to the DRBG, since the DRBG can only be instantiated once, rather a function would gather the 128 bits twice and provide the DRBG with 256 bits of entropy noise source. This component does not describe requirements on seed quality: It is the responsibility of the operational environment to define their requirement in this regard and to ensure that it is met by the external source. Guidance in the introduction to PP, PP-Module, functional package or ST authors should address protection from modification and disclosure of the value from the external noise source, as well as the leaking of any pertinent information (e.g. internal state) regarding the RBG. gives requirements for seeding by an external (outside the TOE) entropy source. The TSF shall be able to accept a minimum input of minimum input length greater than zero from a TSF interface for the purpose of seeding. If the author of a PP, PP-Module, functional package or ST wishes to use multiple internal noise sources, they iterate this requirement for each noise source being used by the TSF. Hardware-based noise sources are sources whose primary function is noise generation, such as ring oscillators, diodes, and thermal noise. While software is used to collect the noise from these hardware sources, these are not software-based. Software-based noise sources are those sources that have some other primary function and the noise is a byproduct of their normal operation. Examples of software-based noise sources are user or system-based events, reading the least significant bits from an event timer. Hardware-based noise sources may be stochastically modeled, in which case the amount of entropy is well understood. Software-based noise sources are usually less well understood and therefore will typically take a more conservative approach, gathering larger numbers of bits than required and then performing a compression function to derive the final output. Software-based noise sources often rely on an entropy estimator. gives requirements for seeding using a TSF entropy source. The TSF shall be able to seed the RBG using a TSF software-based noise source TSF hardware-based noise source name of noise source with a minimum of number of bits bits of min-entropy. The minimum entropy is defined per source/iteration of . The resulting minimum entropy is covered by which is a dependency of . gives requirements for seeding using multiple TSF entropy sources. The TSF shall be able to seed the RBG using number TSF software-based noise source(s) number TSF hardware-based noise source(s) . gives requirements for combining multiple entropy sources (multiple internal sources, internal and external). The TSF shall combining operation output from TSF noise source(s) input from TSF interface(s) for seeding) to create the entropy input into the derivation function as defined in list of standards , resulting in a minimum of number of bits bits of min-entropy. Specifying the interface type is important for developing evaluation activities and important information for an external instance requesting the RBG service from the TOE. requires random numbers to be supplied over an external interface as a service to other entities. The TSF shall provide a hardware software other interface type other interface types can be a service over a network interface. Examples of interface types are Ethernet or wireless. interface to make the RBG output, as specified in , available as a service to entities outside of the TOE. This family defines quality requirements for the generation of random numbers which are intended to be use for cryptographic purposes. When specifying random number generation methods, the author of a PP, PP-Module, functional package or ST should perform due diligence in order to have confidence that the specifications are appropriate for the selected assurance requirements and in consideration of the technology types, environment and use cases of the TOE. In some cases, certification bodies can apply policies in regard to the selection of random bit generators. (See CEM, A.6 n). The ST writer shall perform the missing operation appropriate for cryptographic application of the random numbers in the elements and . The ST writer shall perform the selections for specification of the security capabilities provided by the random number generator of the TOE. Some users of can find The National Institute of Standards and Technology (NIST) Special Publication 800-90A Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June 2015 and NIST Special Publication 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation, January 2018 useful. The evaluation of the random number generator shall follow a recognized methodology, An example of a recognized methodology is AIS31, published by the Bundesamt für Sicherheit in der Informationstechnik (BSI) organization. requires that random numbers meet a defined quality metric. The TSF shall provide a physical non-physical true deterministic hybrid physical hybrid deterministic the author of a PP, PP-Module, functional package or ST should specify the list of security capabilities. random number generator that implements: list of security capabilities the author of a PP, PP-Module, functional package or ST should specify the list of security capabilities. Examples of security capabilities include: a total failure test detects a total failure of entropy source immediately when the RNG has started. When a total failure is detected, no random numbers will be output; if a total failure of the entropy source occurs while the RNG is being operated, the RNG [selection: prevents the output of any internal random number that depends on some raw random numbers that have been generated after the total failure of the entropy source, generates the internal random numbers with a post-processing algorithm of class DRG.2 as long as its internal state entropy guarantees the claimed output entropy]; the online test detection non-tolerable statistical defects of the raw random number sequence (i) immediately when the RNG has started, and (ii) while the RNG is being operated. The TSF must not output any random numbers before the power-up online test has finished successfully or when a defect has been detected; the online test procedure be effective to detect non-tolerable weaknesses of the random numbers soon. the online test procedure checks the quality of the raw random number sequence. It is triggered [selection: externally, at regular intervals, continuously, applied upon specified internal events]. The online test is suitable for detecting non-tolerable statistical defects of the statistical properties of the raw random numbers within an acceptable period of time; failure or severe degradation of the noise source be detectable; continuous tests or other mechanisms in the entropy source protect against producing output during malfunctions. In the case of a PP, PP-Module or functional package, can be completed with a more restrictive language such as: assignment: list of additional security capabilities. . The TSF shall provide bits octets of bits numbers format of the numbers that meet a defined quality metric the author of a PP, PP-Module, functional package or ST should make the appropriate selection in regard to the quality metric. Examples of quality metrics include test procedure A [assignment: additional standard test suites] does not distinguish the internal random numbers from output sequences of an ideal RNG; The assignment for additional standard statistical test suite may be empty. the average Shannon entropy per internal random bit exceeds 0.998; each output bit is independent of all other output bits. In the case of a PP, PP-Module or functional package, can be completed with a more restrictive language such as: [selection: full entropy output, [assignment: bias and entropy rate of the output]. The "quality metric" can include both qualitative metric and quantitative metric. In the case of a hybrid deterministic RNG, the following is an example: /HD The TSF shall provide a hybrid deterministic random number generator that implements: [selection: CTR_DRBG, Hash_DRBG, HMAC_DRBG] as defined in NIST Special Publication 800-90A. /HD The TSF shall provide [selection: bits, octets of bits, numbers [assignment: format of the numbers]] that meet [assignment: security bits]. . This class contains families specifying requirements related to protecting user data. is split into four groups of families (listed below) that address user data within a TOE, during import, export, and storage as well as security attributes directly related to user data. The families in this class are organized into four groups: user data protection SFPs: ; . Components in these families permit the author of a PP, PP-Module, functional package or ST to name the user data protection SFPs and define the scope of control of the policy, necessary to address the security objectives. The names of these policies are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an "access control SFP" or an "information flow control SFP". The rules that define the functionality of the named access control and information flow control SFPs will be defined in the and families (respectively). forms of user data protection: ; ; ; ; ; ; ; . off-line storage, import and export: ; ; . Components in these families address the trustworthy transfer into or out of the TOE. inter-TSF communication: ; . Components in these families address communication between the TSF of the TOE and another trusted IT product. This class contains families specifying requirements related to protecting user data. This class differs from and in that specifies components to protect user data, specifies components to protect attributes associated with the user, and specifies components to protect TSF information. The class does not contain explicit requirements for traditional Mandatory Access Controls (MAC) or traditional Discretionary Access Controls (DAC); however, such requirements may be constructed using components from this class. does not explicitly deal with confidentiality, integrity, or availability, as all three are most often intertwined in the policy and mechanisms. However, the TOE security policy shall adequately cover these three objectives in the PP, PP-Module, functional package or ST. A final aspect of this class is that it specifies access control in terms of "operations". An operation is defined as a specific type of access on a specific object. It depends on the level of abstraction of the author of a PP, PP-Module, functional package or ST whether these operations are described as "read" and/or "write" operations, or as more complex operations such as "update the database". The access control policies are policies that control access to the information container. The attributes represent attributes of the container. Once the information is out of the container, the accessor is free to modify that information, including writing the information into a different container with different attributes. By contrast, an information flow policy controls access to the information, independent of the container. The attributes of the information, which may be associated with the attributes of the container (or may not, as in the case of a multi-level database) stay with the information as it moves. The accessor does not have the ability, in the absence of an explicit authorization, to change the attributes of the information. This class is not meant to be a complete taxonomy of IT access policies, as others can be imagined. Those policies included here are simply those for which current experience with actual systems provides a basis for specifying requirements. There may be other forms of intent that are not captured in the definitions here. A goal of having user-imposed (and user-defined) controls on information flow (such as. an automated implementation of the NO FOREIGN handling caveat). Such concepts can be handled as refinements of, or extensions to the components. Finally, it is important when looking at the components in to remember that these components are requirements for functions that may be implemented by a mechanism that also serves or can serve another purpose. It is possible to build an access control policy that uses labels as the basis of the access control mechanism. A set of SFRs may encompass many SFPs, each to be identified by the two policy-oriented components , and . These policies will typically take confidentiality, integrity, and availability aspects into consideration as required, to satisfy the TOE requirements. Care should be taken to ensure that all objects are covered by at least one SFP and that there are no conflicts arising from implementing the multiple SFPs. When building a PP, PP-Module, functional package or ST using components from the class, the following information provides guidance on where to look and what to select from the class. The requirements in the class are defined in terms of a set of SFRs that will implement an SFP. Since a TOE may implement multiple SFPs simultaneously, the author of a PP, PP-Module, functional package or ST shall specify the name for each SFP, so it can be referenced in other families. This name will then be used in each component selected to indicate that it is being used as part of the definition of requirements for that SFP. This allows the author to easily indicate the scope for operations, e.g. objects covered, operations covered, authorized users. Each instantiation of a component can apply to only one SFP. Therefore, if an SFP is specified in a component then this SFP will apply to all the elements in this component. The components may be instantiated multiple times within a PP, PP-Module, functional package or ST to account for different policies if requested. The key to selecting components from this family is to have a well-defined set of TOE security objectives to enable proper selection of the components from the two policy components; and . In and respectively, all access control policies and all information flow control policies are named. Furthermore, the scope of control of these components in terms of the subjects, objects and operations covered by this security functionality. The names of these policies are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an "access control SFP" or an "information flow control SFP". The rules that define the functionality of the named access control and information flow control SFPs will be defined in the and families (respectively). The following steps are guidance on how this class is applied in the construction of a PP, PP-Module, functional package or ST: identify the policies to be enforced from the , and families. These families define scope of control for the policy, granularity of control and may identify some rules to go with the policy; identify the components and perform any applicable operations in the policy components. The assignment operations may be performed generally (such as with a statement "All files") or specifically (The files "A", "B", etc.) depending upon the level of detail known; identify any applicable function components from the and families to address the named policy families from and . Perform the operations to make the components define the rules to be enforced by the named policies. This should make the components fit the requirements of the selected function envisioned or to be built; identify who will have the ability to control and change security attributes under the function, such as only a security administrator, only the owner of the object, etc. Select the appropriate components from and perform the operations. Refinements may be useful here to identify missing features, such as that some or all changes shall be done via trusted path; identify any appropriate components from the for initial values for new objects and subjects; identify any applicable rollback components from the family; identify any applicable residual information protection requirements from the family; identify any applicable import or export components, and how security attributes should be handled during import and export, from the and families; identify any applicable internal TOE communication components from the family; identify any requirements for integrity protection of stored information from the ; identify any applicable inter-TSF communication components from the or families. This family identifies the access control SFPs (by name) and defines the scope of control of the policies that form the identified access control portion of the SFRs related to the SFP. This scope of control is characterized by three sets: the subjects under control of the policy, the objects under control of the policy, and the operations among controlled subjects and controlled objects that are covered by the policy. The criteria allow multiple policies to exist, each having a unique name. This is accomplished by iterating components from this family once for each named access control policy. The rules that define the functionality of an access control SFP will be defined by other families such as and . The names of the access control SFPs identified here in are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an "access control SFP". This family is based upon the concept of arbitrary controls on the interaction of subjects and objects. The scope and purpose of the controls is based upon the attributes of the accessor (subject), the attributes of the container being accessed (object), the actions (operations) and any associated access control rules. The components in this family are capable of identifying the access control SFPs (by name) to be enforced by the traditional DAC mechanisms. It further defines the subjects, objects and operations that are covered by identified access control SFPs. The rules that define the functionality of an access control SFP will be defined by other families, such as and . The names of the access control SFPs defined in are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an "access control SFP". The access control SFP covers a set of triplets: subject, object, and operations. Therefore, a subject can be covered by multiple access control SFPs but only with respect to a different operation or a different object. Of course, the same applies to objects and operations. A critical aspect of an access control function that enforces an access control SFP is the ability for users to modify the attributes involved in access control decisions. The family does not address these aspects. Some of these requirements are left undefined, but can be added as refinements, while others are covered elsewhere in other families and classes such as . There are no audit requirements in as this family specifies access control SFP requirements. Audit requirements will be found in families specifying functions to satisfy the access control SFPs identified in this family. This family provides a PP, PP-Module, functional package or ST author the capability to specify several policies, for example, a fixed access control SFP to be applied to one scope of control, and a flexible access control SFP to be defined for a different scope of control. To specify more than one access control policy, the components from this family can be iterated multiple times in a PP, PP-Module, functional package or ST to different subsets of operations and objects. This will accommodate TOEs that contain multiple policies, each addressing a particular set of operations and objects. In other words, the author of a PP, PP-Module, functional package or ST should specify the required information in the ACC component for each of the access control SFPs that the TSF will enforce. For example, a TOE incorporating three access control SFPs, each covering only a subset of the objects, subjects, and operations within the TOE, will contain one component for each of the three access-control SFPs, necessitating a total of three components. The terms object and subject refer to generic elements in the TOE. For a policy to be implementable, the entities shall be clearly identified. For a PP, the objects and operations can be expressed as types such as: named objects, data repositories, observe accesses, etc. For a specific TOE these generic terms (subject, object) shall be refined. Files, registers, ports, daemons, open calls. This component specifies that the policy cover some well-defined set of operations on some subset of the objects. It places no constraints on any operations outside the set - including operations on objects for which other operations are controlled. requires that each identified access control SFP be in place for a subset of the possible operations on a subset of the objects in the TOE. The TSF shall enforce the access control SFP the author of a PP, PP-Module, functional package or ST should specify a uniquely named access control SFP to be enforced by the TSF. on list of subjects, objects, and operations among subjects and objects covered by the SFP the author of a PP, PP-Module, functional package or ST should specify the list of subjects, objects, and operations among subjects and objects covered by the SFP. . This component requires that all possible operations on objects, that are included in the SFP, are covered by an access control SFP. The author of a PP, PP-Module, functional package or ST shall demonstrate that each combination of objects and subjects is covered by an access control SFP. requires that each identified access control SFP cover all operations on subjects and objects covered by that SFP. It further requires that all objects and operations protected by the TSF are covered by at least one identified access control SFP. The TSF shall enforce the access control SFP the author of a PP, PP-Module, functional package or ST should specify a uniquely named access control SFP to be enforced by the TSF. on list of subjects and objects the author of a PP, PP-Module, functional package or ST should specify the list of subjects and objects covered by the SFP. All operations among those subjects and objects will be covered by the SFP. and all operations among subjects and objects covered by the SFP. The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. This family describes the rules for the specific functions that can implement an access control policy named in . specifies the scope of control of the policy. This family describes the rules for the specific functions that can implement an access control policy named in which also specifies the scope of control of the policy. This family provides a PP, PP-Module, functional package or ST author the capability to describe the rules for access control. This results in a TOE where the access to objects will not change. An example of such an object is "Message of the Day", which is readable by all, and changeable only by the authorized administrator. This family also provides the author of a PP, PP-Module, functional package or ST with the ability to describe rules that provide for exceptions to the general access control rules. Such exceptions would either explicitly allow or deny authorization to access an object. There are no explicit components to specify other possible functions such as two-person control, sequence rules for operations, or exclusion controls. However, these mechanisms, as well as traditional DAC mechanisms, can be represented with the existing components, by careful drafting of the access control rules. A variety of acceptable access control functionality may be specified in this family. access control lists (ACLs); time-based access control specifications; origin-based access control specifications; owner-controlled access control attributes. This component provides requirements for a mechanism that mediates access control based on security attributes associated with subjects and objects. Each object and subject have a set of associated attributes, such as location, time of creation, access rights such as Access Control Lists (ACLs)). This component allows the author of a PP, PP-Module, functional package or ST to specify the attributes that will be used for the access control mediation. This component allows access control rules, using these attributes, to be specified. Examples of the attributes that a PP, PP-Module, functional package or ST author can assign are: an identity attribute may be associated with users, subjects, or objects to be used for mediation. Examples of such attributes can be the name of the program image used in the creation of the subject, or a security attribute assigned to the program image; a time attribute can be used to specify that access will be authorized during certain times of the day, during certain days of the week, or during a certain calendar year; a location attribute can specify whether the location is the location of the request for the operation, the location where the operation will be carried out, or both. It can be based upon internal tables to translate the logical interfaces of the TSF into locations such as through terminal locations, CPU locations, etc.; a grouping attribute allows a single group of users to be associated with an operation for the purposes of access control. If required, the refinement operation should be used to specify the maximum number of definable groups, the maximum membership of a group, and the maximum number of groups to which a user can concurrently be associated. This component also provides requirements for the access control security functions to be able to explicitly authorize or deny access to an object based upon security attributes. This can be used to provide privilege, access rights, or access authorizations within the TOE. Such privileges, rights, or authorizations can apply to users, subjects (representing users or applications), and objects. allows the TSF to enforce access control based upon security attributes and named groups of attributes. Furthermore, the TSF may have the ability to explicitly authorize or deny access to an object based upon security attributes. Managing the attributes used to make explicit access or denial-based decisions Successful requests to perform an operation on an object covered by the SFP All requests to perform an operation on an object covered by the SFP The specific security attributes used in making an access check The TSF shall enforce the access control SFP the author of a PP, PP-Module, functional package or ST should specify an access control SFP name that the TSF is to enforce. The name of the access control SFP, and the scope of control for that policy are defined in components from . to objects based on the following: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes the author of a PP, PP-Module, functional package or ST should specify, for each controlled subject and object, the security attributes and/or named groups of security attributes that the function will use in the specification of the rules. . The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects the author of a PP, PP-Module, functional package or ST should specify the SFP rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects. These rules specify when access is granted or denied. It can specify general access control functions or granular access control functions. . The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: rules, based on security attributes, that explicitly authorize access of subjects to objects the author of a PP, PP-Module, functional package or ST should specify the rules, based on security attributes, that explicitly authorize access of subjects to objects that will be used to explicitly authorize access. These rules are in addition to those specified in . They are included in as they are intended to contain exceptions to the rules in . . The TSF shall explicitly deny access of subjects to objects based on the following additional rules: rules, based on security attributes, that explicitly deny access of subjects to objects the author of a PP, PP-Module, functional package or ST should specify the rules, based on security attributes, that explicitly deny access of subjects to objects. These rules are in addition to those specified in . They are included in as they are intended to contain exceptions to the rules in . An example of rules to explicitly deny access is based on a privilege vector associated with a subject that always denies access to objects covered by the access control SFP that has been specified. If such a capability is not desired, then the author of a PP, PP-Module, functional package or ST should specify "none". . Data authentication permits an entity to accept responsibility for the authenticity of information. This family provides a method of providing a guarantee of the validity of a specific unit of data that can be subsequently used to verify that the information content has not been forged or fraudulently modified. In contrast to , this family is intended to be applied to "static" data rather than data that is being transferred. This family describes specific functions that can be used to authenticate "static" data. Components in this family are to be used when there is a requirement for "static" data authentication, i.e. where data is to be signed but not transmitted. The non-repudiation of origin family provides for non-repudiation of origin of information received during a data exchange. This component may be satisfied by one-way hash functions to generate a hash value for a definitive document that may be used as verification of the validity or authenticity of its information content. Cryptographic checksum, fingerprint, message digest. requires that the TSF is capable of generating a guarantee of authenticity of the information content of objects. The assignment or modification of the objects for which data authentication may apply can be configurable Successful generation of validity evidence Unsuccessful generation of validity evidence The identity of the subject that requested the evidence The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of list of objects or information types the author of a PP, PP-Module, functional package or ST should specify the list of objects or information types for which the TSF shall be capable of generating data authentication evidence. . The TSF shall provide list of subjects the author of a PP, PP-Module, functional package or ST should specify the list of subjects that will have the ability to verify data authentication evidence for the objects identified in the previous element. The list of subjects can be very specific, if the subjects are known, or it can be more generic and refer to a "type" of subject such as an identified role. with the ability to verify evidence of the validity of the indicated information. This component additionally requires the ability to verify the identity of the user that provided the guarantee of authenticity. A trusted third party. additionally requires that the TSF is capable of establishing the identity of the subject who provided the guarantee of authenticity. Successful generation of validity evidence Unsuccessful generation of validity evidence The identity of the subject that requested the evidence The identity of the subject that generated the evidence The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of list of objects or information types the author of a PP, PP-Module, functional package or ST should specify the list of objects or information types for which the TSF shall be capable of generating data authentication evidence. . The TSF shall provide list of subjects the author of a PP, PP-Module, functional package or ST should specify the list of subjects that will have the ability to verify data authentication evidence for the objects identified in the previous element as well as the identity of the user that created the data authentication evidence. with the ability to verify evidence of the validity of the indicated information and the identity of the user that generated the evidence. This family defines functions for TSF-mediated exporting of user data from the TOE such that its security attributes and protection either can be explicitly preserved or can be ignored once it has been exported. It is concerned with limitations on export and with the association of security attributes with the exported user data. This family defines functions for TSF-mediated exporting of user data from the TOE such that its security attributes either can be explicitly preserved or can be ignored once it has been exported. Consistency of these security attributes are addressed by . is concerned with limitations on export and association of security attributes with the exported user data. This family, and the corresponding Import family , address how the TOE deals with user data transferred into and outside its control. In principle, this family is concerned with the TSF-mediated exporting of user data and its related security attributes. A variety of activities can be involved here: exporting of user data without any security attributes; exporting user data including security attributes where the two are associated with one another and the security attributes unambiguously represent the exported user data. If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate these components once for each named SFP. This component is used to specify the TSF-mediated exporting of user data without the export of its security attributes. requires that the TSF enforces the appropriate SFPs when exporting user data outside the TSF. User data that is exported by this function is exported without its associated security attributes. Successful export of information All attempts to export information The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when exporting user data. The user data that this function exports is scoped by the assignment of these SFPs. when exporting user data, controlled under the SFP(s), outside of the TOE. The TSF shall export the user data without the user data's associated security attributes. The user data is exported together with its security attributes. The security attributes are unambiguously associated with the user data. There are several ways of achieving this association. One way that this can be achieved is by physically collocating the user data and the security attributes. On the same external media. An alternative way is by using cryptographic techniques such as secure signatures to associate the attributes and the user data. can be used to assure that the attributes are correctly received at the other trusted IT product while can be used to make sure that those attributes are properly interpreted. Furthermore, can be used to make sure that the export is being initiated by the proper user. requires that the TSF enforces the appropriate SFPs using a function that accurately and unambiguously associates security attributes with the user data that is exported. The additional exportation control rules can be configurable by a user in a defined role The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when exporting user data. The user data that this function exports is scoped by the assignment of these SFPs. when exporting user data, controlled under the SFP(s), outside of the TOE. The TSF shall export the user data with the user data's associated security attributes. The TSF shall ensure that the security attributes, when exported outside the TOE, are unambiguously associated with the exported user data. The TSF shall ensure that interpretation of the security attributes of the exported user data is as intended by the owner of the user data. The TSF shall enforce the following rules when user data is exported from the TOE: additional exportation control rules the author of a PP, PP-Module, functional package or ST should specify any additional exportation control rules or "none" if there are no additional exportation control rules. These rules will be enforced by the TSF in addition to the access control SFPs and/or information flow control SFPs selected in . . This family identifies the information flow control SFPs (by name) and defines the scope of control for each named information flow control SFP. This scope of control is characterized by three sets: the subjects under control of the policy, the information under control of the policy, and operations which cause controlled information to flow to and from controlled subjects covered by the policy. The criteria allow multiple policies to exist, each having a unique name. This is accomplished by iterating components from this family once for each named information flow control policy. The rules that define the functionality of an information flow control SFP will be defined by other families such as and . The names of the information flow control SFPs identified here in are meant to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an "information flow control SFP". The TSF mechanism controls the flow of information in accordance with the information flow control SFP. Operations that would change the security attributes of information are not generally permitted as this would be in violation of an information flow control SFP. However, such operations may be permitted as exceptions to the information flow control SFP if explicitly specified. This family covers the identification of information flow control SFPs and, for each, specifies the scope of control of the SFP. The components in this family are capable of identifying the information flow control SFPs to be enforced by the traditional MAC mechanisms that would be found in a TOE. However, they go beyond just the traditional MAC mechanisms and can be used to identify and describe non-interference policies and state-transitions. It further defines the subjects under control of the policy, the information under control of the policy, and operations which cause controlled information to flow to and from controlled subjects for each information flow control SFP in the TOE. The information flow control SFP will be defined by other families such as and . The information flow control SFPs named here in are intended to be used throughout the remainder of the functional components that have an operation that calls for an assignment or selection of an "information flow control SFP". These components are quite flexible. They allow the domain of flow control to be specified and there is no requirement that the mechanism be based upon labels. The different elements of the information flow control components also permit different degrees of exception to the policy. Each SFP covers a set of triplets: subject, information, and operations that cause information to flow to and from subjects. Some information flow control policies may be at a very low level of detail and explicitly describe subjects in terms of processes within an operating system. Other information flow control policies may be at a high level and describe subjects in the generic sense of users or input/output channels. If the information flow control policy is at too high a level of detail, it may not clearly define the desired IT security functions. In such cases, it is more appropriate to include such descriptions of information flow control policies as objectives. In this case the desired IT security functions can be specified as supportive of those objectives. In the second component , each information flow control SFP will cover all possible operations that cause information covered by that SFP to flow to and from subjects covered by that SFP. Furthermore, all information flows will need to be covered by a SFP. Therefore, for each action that causes information to flow, there will be a set of rules that define whether the action is allowed. If there are multiple SFPs that are applicable for a given information flow, all involved SFPs shall allow this flow before it is permitted to take place. An information flow control SFP covers a well-defined set of operations. The SFPs coverage may be "complete" with respect to some information flows, or it may address only some of the operations that affect the information flow. An access control SFP controls access to the objects that contain information. An information flow control SFP controls access to the information, independent of its container. The attributes of the information, which may be associated with the attributes of the container (or may not, as in the case of a multi-level database) stay with the information as it flows. The accessor does not have the ability, in the absence of an explicit authorization, to change the attributes of the information. Information flows and operations can be expressed at multiple levels. In the case of a ST, the information flows and operations can be specified at a system-specific level: TCP/IP packets flowing through a firewall based upon known IP addresses. For a PP, the information flows and operations can be expressed as types, e.g. email, data repositories, observe accesses. The components in this family can be applied multiple times in a PP, PP-Module, functional package or ST to different subsets of operations and objects. This will accommodate TOEs that contain multiple policies, each addressing a particular set of objects, subjects, and operations. This component requires that an information flow control policy apply to a subset of the possible operations in the TOE. requires that each identified information flow control SFPs be in place for a subset of the possible operations on a subset of information flows in the TOE. The TSF shall enforce the information flow control SFP the author of a PP, PP-Module, functional package or ST should specify a uniquely named information flow control SFP to be enforced by the TSF. on list of subjects, information, and operations that cause controlled information to flow to and from controlled subjects covered by the SFP the author of a PP, PP-Module, functional package or ST should specify the list of subjects, information, and operations which cause controlled information to flow to and from controlled subjects covered by the SFP. As mentioned above, the list of subjects can be at various levels of detail depending on the needs of the author of a PP, PP-Module, functional package or ST. . This component requires that all possible operations that cause information to flow to and from subjects included in the SFP, are covered by an information flow control SFP. The author of a PP, PP-Module, functional package or ST shall demonstrate that each combination of information flows and subjects is covered by an information flow control SFP. requires that each identified information flow control SFP cover all operations on subjects and information covered by that SFP. It further requires that all information flows and operations controlled by the TSF are covered by at least one identified information flow control SFP. The TSF shall enforce the information flow control SFP the author of a PP, PP-Module, functional package or ST should specify a uniquely named information flow control SFP to be enforced by the TSF. on list of subjects and information the author of a PP, PP-Module, functional package or ST should specify the list of subjects and information that will be covered by the SFP. All operations that cause that information to flow to and from subjects will be covered by the SFP. As mentioned above, the list of subjects can be at various levels of detail depending on the needs of the author of a PP, PP-Module, functional package or ST. and all operations that cause that information to flow to and from subjects covered by the SFP. The TSF shall ensure that all operations that cause any information in the TOE to flow to and from any subject in the TOE are covered by an information flow control SFP. This family describes the rules for the specific functions that can implement the information flow control SFPs named in , which also specifies the scope of control of the policy. It consists of two kinds of requirements: one addressing the common information flow function issues, and a second addressing illicit information flows (i.e. covert channels). This division arises because the issues concerning illicit information flows are, in some sense, orthogonal to the rest of an information flow control SFP. By their nature, they circumvent the information flow control SFP resulting in a violation of the policy. As such, they require special functions to either limit or prevent their occurrence. This family describes the rules for the specific functions that can implement the information flow control SFPs named in , which also specifies the scope of control of the policies. It consists of two "trees:" one addressing the common information flow control function issues, and a second addressing illicit information flows (i.e. covert channels) with respect to one or more information flow control SFPs. This division arises because the issues concerning illicit information flows are, in some sense, orthogonal to the rest of an SFP. Illicit information flows are flows in violation of policy; thus, they are not a policy issue. In order to implement strong protection against disclosure or modification in the face of untrusted software, controls on information flow are required. Access controls alone are not sufficient because they only control access to containers, allowing the information they contain to flow, without controls, throughout a system. In this family, the phrase "types of illicit information flows" is used. This phrase may be used to refer to the categorization of flows as "Storage Channels" or "Timing Channels", or it can refer to improved categorizations reflective of the needs of a PP, PP-Module, functional package or ST author. The flexibility of these components allows the definition of a privilege policy within and to allow the controlled bypass of all or part of a particular SFP. If there is a need for a predefined approach to SFP bypass, the author of a PP, PP-Module, functional package or ST should consider incorporating a privilege policy. This component requires security attributes on information, and on subjects that cause that information to flow and subjects that act as recipients of that information. The attributes of the containers of the information should also be considered if it is desired that they should play a part in information flow control decisions or if they are covered by an access control policy. This component specifies the key rules that are enforced and describes how security attributes are derived. This component does not specify the details of how a security attribute is assigned (i.e. user versus process). Flexibility in policy is provided by having assignments that allow specification of additional policy and function requirements, as necessary. This component also provides requirements for the information flow control functions to be able to explicitly authorize and deny an information flow based upon security attributes. This can be used to implement a privilege policy that covers exceptions to the basic policy defined in this component. requires security attributes on information, and on subjects that cause that information to flow and on subjects that act as recipients of that information. It specifies the rules that must be enforced by the function and describes how security attributes are derived by the function. Managing the attributes used to make explicit access-based decisions Decisions to permit requested information flows All decisions on requests for information flow The specific security attributes used in making an information flow enforcement decision Some specific subsets of the information that has flowed based upon policy goals The TSF shall enforce the information flow control SFP the author of a PP, PP-Module, functional package or ST should specify the information flow control SFPs enforced by the TSF. The name of the information flow control SFP, and the scope of control for that policy are defined in components from . based on the following types of subject and information security attributes: list of subjects and information controlled under the indicated SFP, and for each, the security attributes the author of a PP, PP-Module, functional package or ST should specify, for each type of controlled subject and information, the security attributes that are relevant to the specification of the SFP rules. . The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: for each operation, the security attribute-based relationship that hold between subject and information security attributes the author of a PP, PP-Module, functional package or ST should specify for each operation, the security attribute-based relationship that holds between subject and information security attributes that the TSF will enforce. . The TSF shall enforce the additional information flow control SFP rules the author of a PP, PP-Module, functional package or ST should specify any additional information flow control SFP rules that the TSF is to enforce. This includes all rules of the SFP that are either not based on the security attributes of the information and the subject or rules that automatically modify the security attributes of information or subjects as a result of an access operation. An example for the first case is a rule of the SFP controlling a threshold value for specific types of information. This would for example be the case when the information flow SFP contains rules on access to statistical data where a subject is only allowed to access this type of information up to a specific number of accesses. An example for the second case would be a rule stating under which conditions and how the security attributes of a subject or object change as the result of an access operation. Some information flow policies for example may limit the number of access operations to information with specific security attributes. If there are no additional rules then the author of a PP, PP-Module, functional package or ST should specify "none". . The TSF shall explicitly authorize an information flow based on the following rules: rules, based on security attributes, that explicitly authorize information flows the author of a PP, PP-Module, functional package or ST should specify the rules, based on security attributes, that explicitly authorize information flows. These rules are in addition to those specified in the preceding elements. They are included in as they are intended to contain exceptions to the rules in the preceding elements. . The TSF shall explicitly deny an information flow based on the following rules: rules, based on security attributes, that explicitly deny information flows the author of a PP, PP-Module, functional package or ST should specify the rules, based on security attributes, that explicitly deny information flows. These rules are in addition to those specified in the preceding elements. They are included in as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly deny information flows is based on a privilege vector associated with a subject that always denies the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the author of a PP, PP-Module, functional package or ST should specify "none". . This component requires that the named information flow control SFP uses hierarchical security attributes that form a lattice. It is important to note that the hierarchical relationship requirements identified in need only apply to the information flow control security attributes for the information flow control SFPs that have been identified in . This component is not meant to apply to other SFPs such as access control SFPs. phrases the requirements for the set of security attributes to form a lattice. A number of information flow policies defined in the literature and implemented in IT products are based on a set of security attributes that form a lattice. is specifically included to address this type of information flow policies. If it is the case that multiple information flow control SFPs are to be specified, and that each of these SFPs will have their own security attributes that are not related to one another, then the author of a PP, PP-Module, functional package or ST should iterate this component once for each of those SFPs. Otherwise, a conflict can arise with the sub-items of since the required relationships will not exist. expands on the requirements of by requiring that all information flow control SFPs in the set of SFRs use hierarchical security attributes that form a lattice (as defined in mathematics). is derived from the mathematical properties of a lattice. A lattice consists of a set of elements with an ordering relationship with the property defined in the first bullet, a least upper bound which is the unique element in the set that is greater than or equal to (in the ordering relationship) than any other element of the lattice, and a greatest lower bound, which is the unique element in the set that is smaller than or equal to than any other element of the lattice. The TSF shall enforce the information flow control SFP the author of a PP, PP-Module, functional package or ST should specify the information flow control SFPs enforced by the TSF. The name of the information flow control SFP, and the scope of control for that policy are defined in components from . based on the following types of subject and information security attributes: list of subjects and information controlled under the indicated SFP, and for each, the security attributes the author of a PP, PP-Module, functional package or ST should specify, for each type of controlled subject and information, the security attributes that are relevant to the specification of the SFP rules. For example, such security attributes may be things such the subject identifier, subject sensitivity label, subject clearance label, information sensitivity label, etc. The types of security attributes should be sufficient to support the environmental needs. . The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules, based on the ordering relationships between security attributes hold: for each operation, the security attribute-based relationship that shall hold between subject and information security attributes the author of a PP, PP-Module, functional package or ST should specify for each operation, the security attribute-based relationship that holds between a subject and the information security attributes that the TSF will enforce. These relationships should be based upon the ordering relationships between the security attributes. . The TSF shall enforce the additional information flow control SFP rules the author of a PP, PP-Module, functional package or ST should specify any additional information flow control SFP rules that the TSF is to enforce. This includes all rules of the SFP that are either not based on the security attributes of the information and the subject or rules that automatically modify the security attributes of information or subjects as a result of an access operation. An example for the first case is a rule of the SFP controlling a threshold value for specific types of information. . The TSF shall explicitly authorize an information flow based on the following rules: rules, based on security attributes, that explicitly authorize information flows the author of a PP, PP-Module, functional package or ST should specify the rules, based on security attributes, that explicitly authorize information flows. These rules are in addition to those specified in the preceding elements. They are included in as they are intended to contain exceptions to the rules in the preceding elements. . The TSF shall explicitly deny an information flow based on the following rules: rules, based on security attributes, that explicitly deny information flows the author of a PP, PP-Module, functional package or ST should specify the rules, based on security attributes, that explicitly deny information flows. These rules are in addition to those specified in the preceding elements. They are included in as they are intended to contain exceptions to the rules in the preceding elements. An example of rules to explicitly deny information flows is based on a privilege vector associated with a subject that always denies the subject the ability to cause an information flow for information that is covered by the SFP that has been specified. If such a capability is not desired, then the author of a PP, PP-Module, functional package or ST should specify "none". . The TSF shall enforce the following relationships for any two valid information flow control security attributes: there exists an ordering function that, given two valid security attributes, determines if the security attributes are equal, if one security attribute is greater than the other, or if the security attributes are incomparable; there exists a "least upper bound" in the set of security attributes, such that, given any two valid security attributes, there is a valid security attribute that is greater than or equal to the two valid security attributes; there exists a "greatest lower bound" in the set of security attributes, such that, given any two valid security attributes, there is a valid security attribute that is not greater than the two valid security attributes. This component should be used when at least one of the SFPs that requires control of illicit information flows does not require elimination of flows. For the specified illicit information flows, certain maximum capacities should be provided. In addition, a PP, PP-Module, functional package or ST author has the ability to specify whether the illicit information flows must be audited. requires the SFP to cover illicit information flows, but does not necessarily eliminate them. Decisions to permit requested information flows All decisions on requests for information flow The use of identified illicit information flow channels The specific security attributes used in making an information flow enforcement decision Some specific subsets of the information that has flowed based upon policy goals The use of identified illicit information flow channels with estimated maximum capacity exceeding a specified value The TSF shall enforce the information flow control SFP the author of a PP, PP-Module, functional package or ST should specify the information flow control SFPs enforced by the TSF. The name of the information flow control SFP, and the scope of control for that policy are defined in components from . to limit the capacity of types of illicit information flows the author of a PP, PP-Module, functional package or ST should specify the types of illicit information flows that are subject to a maximum capacity limitation. to a maximum capacity the author of a PP, PP-Module, functional package or ST should specify the maximum capacity permitted for any identified illicit information flows. . This component should be used when all the SFPs that requires control of illicit information flows require elimination of some (but not necessarily all) illicit information flows. requires the SFP to cover the elimination of some (but does not necessarily all) illicit information flows. The TSF shall enforce the information flow control SFP the author of a PP, PP-Module, functional package or ST should specify the information flow control SFPs enforced by the TSF. The name of the information flow control SFP, and the scope of control for that policy are defined in components from . to limit the capacity of types of illicit information flows the author of a PP, PP-Module, functional package or ST should specify the types of illicit information flows which are subject to a maximum capacity limitation. to a maximum capacity the author of a PP, PP-Module, functional package or ST should specify the maximum capacity permitted for any identified illicit information flows. . The TSF shall prevent types of illicit information flows the author of a PP, PP-Module, functional package or ST should specify the types of illicit information flows to be eliminated. This list may not be empty as this component requires that some illicit information flows are to be eliminated. . This component should be used when the SFPs that require control of illicit information flows require elimination of all illicit information flows. However, the author of a PP, PP-Module, functional package or ST should carefully consider the potential impact that eliminating all illicit information flows can have on the normal functional operation of the TOE. Many practical applications have shown that there is an indirect relationship between illicit information flows and normal functionality within a TOE and eliminating all illicit information flows may result in less than desired functionality. requires SFP to cover the elimination of all illicit information flows. The TSF shall ensure that no illicit information flows exist to circumvent name of information flow control SFP the author of a PP, PP-Module, functional package or ST should specify the information flow control SFP for which illicit information flows are to be eliminated. The name of the information flow control SFP, and the scope of control for that policy are defined in components from . . This component should be used when it is desired that the TSF provide the ability to monitor the use of illicit information flows that exceed a specified capacity. If it is desired that such flows be audited, then this component can serve as the source of audit events to be used by components from the family. requires the SFP to monitor illicit information flows for specified and maximum capacities. The enabling or disabling of the monitoring function Modification of the maximum capacity at which the monitoring occurs The TSF shall enforce the information flow control SFP the author of a PP, PP-Module, functional package or ST should specify the information flow control SFPs enforced by the TSF. The name of the information flow control SFP, and the scope of control for that policy are defined in components from . to monitor types of illicit information flows the author of a PP, PP-Module, functional package or ST should specify the types of illicit information flows that will be monitored for exceeding a maximum capacity. when it exceeds the maximum capacity the author of a PP, PP-Module, functional package or ST should specify the maximum capacity above which illicit information flows will be monitored by the TSF. . The "Information retention control" family addresses a basic need in secure information processing and storage applications for the secure management of data no longer needed by the TOE to perform its operations, but that is still stored in the TOE. The historical view of IT systems as data storage systems suggested that once entered, data would seldom be deleted from the system, and if it was deleted, this would mainly be because of storage exhaustion problems. However, in a multilateral or high security environment it is important to minimize the replication of data, as well as the time period during which data is stored in the system. It is also possible that users can want their IT products to avoid retaining sensitive data that they consider to be exploitable by third parties or that can threaten privacy. may help users to gain confidence that the product is secure by deleting every copy of the data when it is no longer needed. The family addresses one side of this problem, but an explicit requirement on the management of data that is no longer needed is missing. Of course, competing requirements can arise, since some data can be needed by the system for more operations over a longer time period. Possible solutions to this problem are: better protecting the information objects stored in the TOE from access; re-requesting the protected information from the user each time it is needed. Information retention control ensures, that data no longer necessary for the operation of the TOE is deleted by the TOE. Components of this family require the author of a PP, PP-Module, functional package or ST to identify the TOE operations, including both simple and complex processing and the information objects, that are not to be kept in the TOE, that are the subject of those operations. The TOE is also required to keep track of such stored information objects, and to delete both the on-line and the off-line information objects that are no longer required. This family sets only requirements on information objects requested for specific activities in the TOE operation, and not on general data gathering. The policies which control the collection, storage, processing, disclosure, and elimination of general user data stored on the TOE are detailed elsewhere, and are in the domain of the environmental objectives and organizational policies, not of the PP, PP-Module, functional package or ST. When more than one operation requires the presence of a protected object, all operations, which refer to the required object, shall end before deleting it. While a great aspect of the elimination of the objects as required by refers to the information stored within the object as a container, it also includes all attributes (also in the meaning of metadata) that may be associated with the object. In this aspect, the focus of differs from other components related to access or information flow control policies, such as and . More important, objects here are always considered in the context of selected activities that are performed on these objects. In contrast to residual information protection , excludes objects from any access or information flow and deletes them, irreversibly and untraceably when they are no longer needed by a set of activities. While it may not be completely clear, which objects to consider, it is essential that the list of objects is assigned by the author of a PP, PP-Module, functional package or ST at the very latest in order to allow for concrete tests. In any case the list of objects shall be derived from a structured analysis. The information erasure policy as defined in serves to protect all information that is contained in the assigned objects from being misused, regardless of whether the information is primary content or any kind of attribute. The policy covers combinations of objects and activities. The policy's coverage may be "complete" with respect to all the objects related to one or more activities, or it may address only some of the objects related to one or more activities. The term "promptly" in specifically refers to the fact that the objects shall be terminated in a manner that ensures that they cannot be accessed as before. requires that the TSF ensure that any copy of a defined set of objects in the TOE is deleted when no longer strictly necessary for the operation of the TOE. The TSF shall enforce the information erasure policy the author of a PP, PP-Module, functional package or ST should specify a uniquely named information erasure policy to be enforced by the TSF. on a list of objects the author of a PP, PP-Module, functional package or ST should specify the list of objects that are required for the respective list of activities, e.g. "all message objects". required for list of operations the author of a PP, PP-Module, functional package or ST should specify the list of activities that the information erasure policy is concerned with, e.g. "all activities related to passing a message on, such as receiving a message, cryptographic handling of a message, sending a message". so that the selected objects are deleted irreversibly and untraceably from the TOE promptly upon termination of the selected operations. The TSF shall ensure that list of objects the author of a PP, PP-Module, functional package or ST should specify the list of objects that are required for the respective list of activities. This assignment shall be identical to the assigned objects in . cannot be accessed after their release and prior to their irreversible and untraceable deletion. This family defines the mechanisms for TSF-mediated importing of user data into the TOE such that it has appropriate security attributes and is appropriately protected. It is concerned with limitations on importation, determination of desired security attributes, and interpretation of security attributes associated with the user data. This family defines mechanisms for TSF-mediated importing of user data from outside the TOE into the TOE such that the user data security attributes can be preserved. Consistency of these security attributes are addressed by . is concerned with limitations on import, user specification of security attributes, and association of security attributes with the user data. This family, and the corresponding export family , address how the TOE deals with user data outside its control. This family is concerned with assigning and abstraction of the user data security attributes. A variety of activities can be involved here: importing user data from an unformatted medium (e.g. tape, scanner, video or audio signal), without including any security attributes, and physically marking the medium to indicate its contents; importing user data, including security attributes, from a medium and verifying that the object security attributes are appropriate; importing user data, including security attributes, from a medium using a cryptographic sealing technique to protect the association of user data and security attributes. This family is not concerned with the determination of whether the user data may be imported. It is concerned with the values of the security attributes to associate with the imported user data. There are two possibilities for the import of user data: either the user data is unambiguously associated with reliable object security attributes (values and meaning of the security attributes is not modified), or no reliable security attributes (or no security attributes at all) are available from the import source. This family addresses both cases. If there are reliable security attributes available, they may have been associated with the user data by physical means (the security attributes are on the same media), or by logical means (the security attributes are distributed differently but include unique object identification). Cryptographic checksum. This family is concerned with TSF-mediated importing of user data and maintaining the association of security attributes as required by the SFP. Other families are concerned with other import aspects such as consistency, trusted channels, and integrity that are beyond the scope of this family. Furthermore, is only concerned with the interface to the import medium. is responsible for the other end point of the medium (the source). Some of the well-known import requirements are: importing of user data without any security attributes; importing of user data including security attributes where the two are associated with one another and the security attributes unambiguously represent the information being imported. These import requirements may be handled by the TSF with or without human intervention, depending on the IT limitations and the organizational security policy. For example, if user data is received on a "confidential" channel, the security attributes of the objects will be set to "confidential". If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate these components once for each named SFP. This component is used to specify the import of user data that does not have reliable (or any) security attributes associated with it. This function requires that the security attributes for the imported user data be initialized within the TSF. It can also be the case that the author of a PP, PP-Module, functional package or ST specifies the rules for import. It may be appropriate, in some environments, to require that these attributes be supplied via a trusted path or a trusted channel mechanism. requires that the security attributes correctly represent the user data and are supplied separately from the object. The modification of the additional control rules used for import Successful import of user data, including any security attributes All attempts to import user data, including any security attributes The specification of security attributes for imported user data supplied by an authorized user The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when importing user data from outside of the TOE. The user data that this function imports is scoped by the assignment of these SFPs. when importing user data, controlled under the SFP, from outside of the TOE. The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE. The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: additional importation control rules the author of a PP, PP-Module, functional package or ST should specify any additional importation control rules or "none" if there are no additional importation control rules. These rules will be enforced by the TSF in addition to the access control SFPs and/or information flow control SFPs selected in . . This component is used to specify the import of user data that has reliable security attributes associated with it. This function relies upon the security attributes that are accurately and unambiguously associated with the objects on the import medium. Once imported, those objects will have those same attributes. This requires to ensure the consistency of the data. It can also be the case that the author of a PP, PP-Module, functional package or ST specifies the rules for import. requires that security attributes correctly represent the user data and are accurately and unambiguously associated with the user data imported from outside the TOE. The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when importing user data from outside of the TOE. The user data that this function imports is scoped by the assignment of these SFPs. when importing user data, controlled under the SFP, from outside of the TOE. The TSF shall use the security attributes associated with the imported user data. The TSF shall ensure that the protocol used provides for the unambiguous association between the security attributes and the user data received. The TSF shall ensure that interpretation of the security attributes of the imported user data is as intended by the source of the user data. The TSF shall enforce the following rules when importing user data controlled under the SFP from outside the TOE: additional importation control rules the author of a PP, PP-Module, functional package or ST should specify any additional importation control rules or "none" if there are no additional importation control rules. These rules will be enforced by the TSF in addition to the access control SFPs and/or information flow control SFPs selected in . . This family provides requirements that address protection of user data when it is transferred between separated parts of a TOE across an internal channel. This may be contrasted with the and families, which provide protection for user data when it is transferred between distinct TSFs across an external channel, and and , which address TSF-mediated transfer of data to or from outside the TOE. This family provides requirements that address protection of user data when it is transferred between parts of a TOE across an internal channel. This may be contrasted with the and family, which provide protection for user data when it is transferred between distinct TSFs across an external channel, and and , which address TSF-mediated transfer of data to or from outside the TOE. The requirements in this family allow a PP, PP-Module, functional package or ST author to specify the desired security for user data while in transit within the TOE. This security can be protection against disclosure, modification, or loss of availability. The determination of the degree of physical separation above which this family should apply depends on the intended environment of use. In a hostile environment, there may be risks arising from transfers between parts of the TOE separated by only a system bus. In more benign environments, the transfers may be across more traditional network media. If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate these components once for each named SFP. No component rationale or application notes have been given. requires that user data be protected when transmitted between parts of the TOE. If the TSF provides multiple methods to protect user data during transmission between physically separated parts of the toe, the TSF can provide a pre-defined role with the ability to select the method that will be used Successful transfers of user data, including identification of the protection method used All attempts to transfer user data, including the protection method used and any errors that occurred The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred. to prevent the disclosure modification loss of use the author of a PP, PP-Module, functional package or ST should specify the types of transmission errors that the TSF should prevent occurring for user data while in transport. The options are disclosure, modification, loss of use. of user data when it is transmitted between physically-separated parts of the TOE. This component can, for example, be used to provide different forms of protection to information with different clearance levels. One of the ways to achieve separation of data when it is transmitted is through the use of separate logical or physical channels. requires separation of data based on the value of SFP-relevant attributes in addition to the first component. The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred. to prevent the disclosure modification loss of use the author of a PP, PP-Module, functional package or ST should specify the types of transmission errors that the TSF should prevent occurring for user data while in transport. The options are disclosure, modification, loss of use. of user data when it is transmitted between physically-separated parts of the TOE. The TSF shall separate data controlled by the SFP(s) when transmitted between physically-separated parts of the TOE, based on the values of the following: security attributes that require separation the author of a PP, PP-Module, functional package or ST should specify the security attributes, the values of which the TSF will use to determine when to separate data that is being transmitted between physically-separated parts of the TOE. An example is that user data associated with the identity of one owner is transmitted separately from the user data associated with the identify of a different owner. In this case, the value of the identity of the owner of the data is what is used to determine when to separate the data for transmission. . This component is used in combination with either or . It ensures that the TSF checks received user data (and their attributes) for integrity. or will provide the data in a manner such that it is protected from modification (so that can detect any modifications). The author of a PP, PP-Module, functional package or ST shall specify the types of errors that must be detected. The author of a PP, PP-Module, functional package or ST should consider: modification of data, substitution of data, unrecoverable ordering change of data, replay of data, incomplete data, in addition to other integrity errors. The author of a PP, PP-Module, functional package or ST specifies the actions that the TSF should take on detection of a failure. Ignore the user data, request the data again, inform the authorized administrator, reroute traffic for other lines. requires that the TSF monitor user data transmitted between parts of the TOE for identified integrity errors. The specification of the actions to be taken upon detection of an integrity error can be configurable Successful transfers of user data, including identification of the integrity protection method used All attempts to transfer user data, including the integrity protection method used and any errors that occurred Unauthorized attempts to change the integrity protection method The action taken upon detection of an integrity error The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred and monitored for integrity errors. to monitor user data transmitted between physically-separated parts of the TOE for the following errors: integrity errors the author of a PP, PP-Module, functional package or ST should specify the type of possible integrity errors to be monitored during transmission of the user data. . Upon detection of a data integrity error, the TSF shall specify the action to be taken upon integrity error the author of a PP, PP-Module, functional package or ST should specify the action to be taken by the TSF when an integrity error is encountered. . This component is used in combination with . It ensures that the TSF checks received user data, that has been transmitted by separate channels (based on values of specified security attributes), for integrity. It allows the author of a PP, PP-Module, functional package or ST to specify actions to be taken upon detection of an integrity error. This component can be used to provide different integrity error detection and action for information at different integrity levels. The author of a PP, PP-Module, functional package or ST shall specify the types of errors that must be detected. The author of a PP, PP-Module, functional package or ST should consider: modification of data, substitution of data, unrecoverable ordering change of data, replay of data, incomplete data, in addition to other integrity errors. The author of a PP, PP-Module, functional package or ST should specify the attributes (and associated transmission channels) that necessitate integrity error monitoring. The author of a PP, PP-Module, functional package or ST specifies the actions that the TSF should take on detection of a failure. Ignore the user data, request the data again, inform the authorized administrator, reroute traffic for other lines. expands on the third component by allowing the form of integrity monitoring to differ by SFP-relevant attributes. The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) covering the information being transferred and monitored for integrity errors. to monitor user data transmitted between physically-separated parts of the TOE for the following errors: integrity errors the author of a PP, PP-Module, functional package or ST should specify the type of possible integrity errors to be monitored during transmission of the user data. , based on the following attributes: security attributes that require separate transmission channels the author of a PP, PP-Module, functional package or ST should specify a list of security attributes that require separate transmission channels. This list is used to determine which user data to monitor for integrity errors., based on its security attributes and its transmission channel. This element is directly related to . . Upon detection of a data integrity error, the TSF shall specify the action to be taken upon integrity error the author of a PP, PP-Module, functional package or ST should specify the action to be taken by the TSF when an integrity error is encountered. An example can be that the TSF should request the resubmission of the user data. The SFP(s) specified in will be enforced as the actions are taken by the TSF. . This family addresses the need to ensure that any data contained in a resource is not available when the resource is de-allocated from one object and reallocated to a different object. This family requires protection for any data contained in a resource that has been logically deleted or released but may still be present within the TSF-controlled resource which in turn may be re-allocated to another object. Residual information protection ensures that TSF-controlled resources when de-allocated from an object and before they are reallocated to another object are treated by the TSF in a way that it is not possible to reconstruct all or part of the data contained in the resource before it was de-allocated. A TOE usually has a number of functions that potentially de-allocate resources from an object and potentially re-allocate those resources to objects. Some, but not all of those resources may have been used to store critical data from the previous use of the resource and for those resources requires that they are prepared for reuse. Object reuse applies to explicit requests of a subject or user to release resources as well as implicit actions of the TSF that result in the de-allocation and subsequent re-allocation of resources to different objects. Examples of explicit requests are the deletion or truncation of a file or the release of an area of main memory. Examples of implicit actions of the TSF are the de-allocation and re-allocation of cache regions. The requirement for object reuse is related to the content of the resource belonging to an object, not all information about the resource or object that may be stored elsewhere in the TSF. As an example, to satisfy the requirement for files as objects requires that all sectors that make up the file need to be prepared for re-use. It also applies to resources that are serially reused by different subjects within the system. For example, most operating systems typically rely upon hardware registers (resources) to support processes within the system. As processes are swapped from a "run" state to a "sleep" state (and vice versa), these registers are serially reused by different subjects. While this "swapping" action may not be considered an allocation or deallocation of a resource, can apply to such events and resources. typically controls access to information that is not part of any currently defined or accessible object; however, in certain cases this may not be true. For example, object "A" is a file and object "B" is the disk upon which that file resides. If object "A" is deleted, the information from object "A" is under the control of even though it is still part of object "B". It is important to note that applies only to on-line objects and not off-line objects such as those backed-up on tapes. For example, if a file is deleted in the TOE, can be instantiated to require that no residual information exists upon deallocation; however, the TSF cannot extend this enforcement to that same file that exists on the off-line back-up. Therefore, that same file is still available. If this is a concern, then the author of a PP, PP-Module, functional package or ST should make sure that the proper environmental objectives are in place to support operational user guidance to address off-line objects. and can conflict when is instantiated to require that residual information be cleared at the time the application releases the object to the TSF (i.e. upon deallocation). Therefore, the selection of "deallocation" should not be used with since there would be no information to roll back. The other selection, "unavailability upon allocation", may be used with , but there is the risk that the resource which held the information has been allocated to a new object before the roll back took place. If that were to occur, then the roll back would not be possible. There are no audit requirements in because this is not a user-invokable function. Auditing of allocated or deallocated resources would be auditable as part of the access control SFP or the information flow control SFP operations. This family should apply to the objects specified in the access control SFP(s) or the information flow control SFP(s) as specified by the author of a PP, PP-Module, functional package or ST. This component requires that, for a subset of the objects in the TOE, the TSF will ensure that there is no available residual information contained in a resource allocated to those objects or deallocated from those objects. requires that the TSF ensure that any residual information content of any resources is unavailable to a defined subset of the objects controlled by the TSF upon the resource's allocation or deallocation. The choice of when to perform residual information protection (i.e. upon allocation or deallocation) can be made configurable within the toe The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to deallocation of the resource from the author of a PP, PP-Module, functional package or ST should specify the event, allocation of the resource to or deallocation of the resource from, that invokes the residual information protection function. the following objects: list of objects the author of a PP, PP-Module, functional package or ST should specify the list of objects subject to residual information protection. . This component requires that for all objects in the TOE, the TSF will ensure that there is no available residual information contained in a resource allocated to those objects or deallocated from those objects. requires that the TSF ensure that any residual information content of any resources is unavailable to all objects upon the resource's allocation or deallocation. The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to deallocation of the resource from the author of a PP, PP-Module, functional package or ST should specify the event, allocation of the resource to or deallocation of the resource from, that invokes the residual information protection function. all objects. The rollback operation involves undoing the last operation or a series of operations, bounded by some limit, such as a period of time, and return to a previous known state. Rollback provides the ability to undo the effects of an operation or series of operations to preserve the integrity of the user data. This family addresses the need to return to a well-defined valid state, such as the need of a user to undo modifications to a file or to undo transactions in case of an incomplete series of transaction as in the case of databases. This family is intended to assist a user in returning to a well-defined valid state after the user undoes the last set of actions, or, in distributed databases, the return of all of the distributed copies of the databases to the state before an operation failed. and conflict when enforces that the contents will be made unavailable at the time that a resource is deallocated from an object. Therefore, this use of cannot be combined with as there would be no information to roll back. can be used only with when it enforces that the contents will be unavailable at the time that a resource is allocated to an object. This is because the mechanism will have an opportunity to access the previous information that may still be present in the TOE in order to successfully roll back the operation. The rollback requirement is bounded by certain limits. A text editor typically only allows you roll back up to a certain number of commands. Backups. If backup tapes are rotated, after a tape is reused, the information can no longer be retrieved. This also poses a bound on the rollback requirement. This component allows a user or subject to undo a set of operations on a predefined set of objects. The undo is only possible within certain limits, for example up to a number of characters or up to a time limit. addresses a need to roll back or undo a limited number of operations within the defined bounds. The boundary limit to which rollback may be performed can be a configurable item within the toe Permission to perform a rollback operation can be restricted to a well-defined role All successful rollback operations All attempts to perform rollback operations All attempts to perform rollback operations, including identification of the types of operations rolled back The TSF shall enforce access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when performing rollback operations. This is necessary to make sure that roll back is not used to circumvent the specified SFPs. to permit the rollback of the list of operations the author of a PP, PP-Module, functional package or ST should specify the list of operations that can be rolled back. on the information and/or list of objects the author of a PP, PP-Module, functional package or ST should specify the information and/or list of objects that are subjected to the rollback policy. . The TSF shall permit operations to be rolled back within the boundary limit to which rollback may be performed the author of a PP, PP-Module, functional package or ST should specify the boundary limit to which rollback operations may be performed. The boundary may be specified as a predefined period of time, . This component enforces that the TSF provide the capability to rollback all operations; however, the user can choose to rollback only a part of them. addresses the need to roll back or undo all operations within the defined bounds. The TSF shall enforce access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when performing rollback operations. This is necessary to make sure that roll back is not used to circumvent the specified SFPs. to permit the rollback of all the operations on the list of objects the author of a PP, PP-Module, functional package or ST should specify the list of objects that are subjected to the rollback policy. . The TSF shall permit operations to be rolled back within the boundary limit to which rollback may be performed the author of a PP, PP-Module, functional package or ST should specify the boundary limit to which rollback operations may be performed. The boundary may be specified as a predefined period of time, . This family provides requirements that address protection of user data confidentiality while the data is stored within memory areas protected by the TSF. The TSF provides access to the data in the memory through the specified interfaces only and prevents compromise of their information bypassing these interfaces. It complements the family which protects the user data from integrity errors while being stored in the memory. This family provides requirements that address protection of user data confidentiality while the data is stored within memory areas protected by the TSF. The TSF provides access to the data in the memory through the specified interfaces only and prevents compromise of their information bypassing these interfaces. It complements the family which protects the user data from integrity errors while being stored in the memory. In practice, the dependency to may be satisfied by a PP, PP-Module, functional package or ST author by providing a rationale explaining an alternative method to cryptography is used in some dedicated cases. In , the author of a PP, PP-Module, functional package or ST specifies which user data is to be protected and in which type of memory the user data is requested to be protected. In the second selection the author of a PP, PP-Module, functional package or ST provides the memory type where the user data is to be protected. requires the TSF to protect the confidentiality of information of the user data in specified memory areas. The TSF shall ensure the confidentiality of all user data the following user data list of user data the author of a PP, PP-Module, functional package or ST shall select either "all user data" or provide a list of user data using the assignment below. In the second selection, the author of a PP, PP-Module, functional package or ST can specify either temporary memory, persistent memory or any memory. "Any memory" includes both temporary (volatile) and persistent (non-volatile) memory. the author of a PP, PP-Module, functional package or ST provides a list of the user data that is to be protected in memory. while it is stored in the temporary memory persistent memory any memory . refines the element by allowing the author of a PP, PP-Module, functional package or ST to refine the list of user data using a variety of data characteristics. requires the TSF to protect the confidentiality of the user data according to data characteristics leading to specify a dedicated method of protection of confidentiality. The TSF shall ensure the confidentiality of the all user data the following user data list of user data the operations of selection and the first assignment are the same as that in For the second assignment the author of a PP, PP-Module, functional package or ST provides the data characteristics. Data characteristics can include items such as data length (shorter or longer than a threshold), data type (binary, text, image, sound, video), and data representation (binary, vector, character, frame). according to data characteristics while it is stored under the control of the TSF. The TSF shall ensure the confidentiality of the user data specified in without user intervention. This family provides requirements that address protection of user data while it is stored within containers controlled by the TSF. Integrity errors may affect user data stored in memory, or in a storage device. This family differs from which protects the user data from integrity errors while being transferred within the TOE. This family provides requirements that address protection of user data while it is stored within containers controlled by the TSF. Hardware glitches or errors may affect data stored in memory. This family provides requirements to detect these unintentional errors. The integrity of user data while stored on storage devices controlled by the TSF are also addressed by this family. To prevent a subject from modifying the data, the or families are required (rather than this family). This family differs from that protects the user data from integrity errors while being transferred within the TOE. This component monitors data stored on media for integrity errors. The author of a PP, PP-Module, functional package or ST can specify different kinds of user data attributes that will be used as the basis for monitoring. requires that the TSF monitor user data stored within containers controlled by the TSF for identified integrity errors. Successful attempts to check the integrity of user data, including an indication of the results of the check All attempts to check the integrity of user data, including an indication of the results of the check, if performed The type of integrity error that occurred The TSF shall monitor user data stored in containers controlled by the TSF for integrity errors the author of a PP, PP-Module, functional package or ST should specify the integrity errors that the TSF will detect. on all objects, based on the following attributes: user data attributes the author of a PP, PP-Module, functional package or ST should specify the user data attributes that will be used as the basis for the monitoring. . This component monitors data stored on media for integrity errors. The author of a PP, PP-Module, functional package or ST can specify which action should be taken in case an integrity error is detected. adds the additional capability to the first component by allowing for actions to be taken as a result of an error detection. The actions to be taken upon the detection of an integrity error can be configurable Successful attempts to check the integrity of user data, including an indication of the results of the check All attempts to check the integrity of user data, including an indication of the results of the check, if performed The type of integrity error that occurred The action taken upon detection of an integrity error The TSF shall monitor user data stored in containers controlled by the TSF for integrity errors the author of a PP, PP-Module, functional package or ST should specify the integrity errors that the TSF will detect. on all objects, based on the following attributes: user data attributes the author of a PP, PP-Module, functional package or ST should specify the user data attributes that will be used as the basis for the monitoring. . Upon detection of a data integrity error, the TSF shall action to be taken the author of a PP, PP-Module, functional package or ST should specify the actions to be taken in case an integrity error is detected. . This family defines the requirements for ensuring the confidentiality of user data when it is transferred using an external channel between the TOE and another trusted IT product. This family defines the requirements for ensuring the confidentiality of user data when it is transferred using an external channel between the TOE and another trusted IT product. Confidentiality is enforced by preventing unauthorized disclosure of user data in transit between the two end points. The end points may be a TSF or a user. This family provides a requirement for the protection of user data during transit. In contrast, handles TSF data. Depending on the access control or information flow policies the TSF is required to send or receive user data in a manner such that the confidentiality of the user data is protected. In , the goal is to provide protection from disclosure of user data while in transit. The identity of any user or subject using the data exchange mechanisms The identity of any unauthorized user or subject attempting to use the data exchange mechanisms A reference to the names or other indexing information useful in identifying the user data that was transmitted or received. this can include security attributes associated with the information The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when exchanging user data. The specified policies will be enforced to make decisions about who can exchange data and which data can be exchanged. to transmit receive the author of a PP, PP-Module, functional package or ST should specify whether this element applies to a mechanism that transmits or receives user data. user data in a manner protected from unauthorized disclosure. This family defines the requirements for providing integrity for user data in transit between the TOE and another trusted IT product and recovering from detectable errors. At a minimum, this family monitors the integrity of user data for modifications. Furthermore, this family supports different ways of correcting detected integrity errors. This family defines the requirements for providing integrity for user data in transit between the TSF and another trusted IT product and recovering from detectable errors. At a minimum, this family monitors the integrity of user data for modifications. Furthermore, this family supports different ways of correcting detected integrity errors. This family defines the requirements for providing integrity for user data in transit; while handles TSF data. and are duals of each other, as addresses user data confidentiality. Therefore, the same mechanism that implements can possibly be used to implement other families such as and . Depending on the access control or information flow policies the TSF is required to send or receive user data in a manner such that modification of the user data is detected. There is no requirement for a TSF mechanism to attempt to recover from the modification. addresses detection of modifications, deletions, insertions, and replay errors of the user data transmitted. The identity of any user or subject using the data exchange mechanisms The identity of any user or subject attempting to use the user data exchange mechanisms, but who is unauthorized to do so A reference to the names or other indexing information useful in identifying the user data that was transmitted or received. this can include security attributes associated with the user data Any identified attempts to block transmission of user data The types and/or effects of any detected modifications of transmitted user data The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced on the transmitted data or on the received data. The specified policies will be enforced to make decisions about who can transmit or who can receive data, and which data can be transmitted or received. to transmit receive the author of a PP, PP-Module, functional package or ST should specify whether this element applies to a TSF that is transmitting or receiving objects. user data in a manner protected from modification deletion insertion replay the author of a PP, PP-Module, functional package or ST should specify whether the data should be protected from modification, deletion, insertion, or replay. errors. The TSF shall be able to determine on receipt of user data, whether modification deletion insertion replay the author of a PP, PP-Module, functional package or ST should specify whether the errors of the type: modification, deletion, insertion, or replay are detected. has occurred. This component provides the ability to recover from a set of identified transmission errors, if required, with the help of the other trusted IT product. As the other trusted IT product is outside the TOE, the TSF cannot control its behaviour. However, it can provide functions that have the ability to cooperate with the other trusted IT product for the purposes of recovery. The TSF can include functions that depend upon the source trusted IT product to re-send the data in the event that an error is detected. This component deals with the ability of the TSF to handle such an error recovery. addresses recovery of the original user data by the receiving TSF with help from the source trusted IT product. The identity of any user or subject using the data exchange mechanisms Successful recovery from errors including the type of error that was detected The identity of any user or subject attempting to use the user data exchange mechanisms, but who is unauthorized to do so A reference to the names or other indexing information useful in identifying the user data that was transmitted or received. this can include security attributes associated with the user data Any identified attempts to block transmission of user data The types and/or effects of any detected modifications of transmitted user data The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when recovering user data. The specified policies will be enforced to make decisions about which data can be recovered and how it can be recovered. to be able to recover from list of recoverable errors the author of a PP, PP-Module, functional package or ST should specify the list of integrity errors from which the TSF, with the help of the source trusted IT product, is able to recover the original user data. with the help of the source trusted IT product. This component provides the ability to recover from a set of identified transmission errors. It accomplishes this task without help from the source trusted IT product. If certain errors are detected, the transmission protocol must be robust enough to allow the TSF to recover from the error based on checksums and other information available within that protocol. addresses recovery of the original user data by the receiving TSF on its own without any help from the source trusted IT product. The TSF shall enforce the access control SFP(s) and/or information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should specify the access control SFP(s) and/or information flow control SFP(s) that will be enforced when recovering user data. The specified policies will be enforced to make decisions about which data can be recovered and how it can be recovered. to be able to recover from list of recoverable errors the author of a PP, PP-Module, functional package or ST should specify the list of integrity errors from which the receiving TSF, alone, is able to recover the original user data. without any help from the source trusted IT product. Families in this class address the requirements for functions to establish and verify a claimed user identity. Identification and authentication are required to ensure that users are associated with the proper security attributes The unambiguous identification of authorized users and the correct association of security attributes with users and subjects is critical to the enforcement of the intended security policies. The families in this class deal with determining and verifying the identity of users, determining their authority to interact with the TOE, and with the correct association of security attributes for each authorized user. Other classes of requirements are dependent upon correct identification and authentication of users in order to be effective. A common security requirement is to unambiguously identify the person and/or entity performing functions in a TOE. This involves not only establishing the claimed identity of each user, but also verifying that each user is indeed who he/she claims to be. This is achieved by requiring users to provide the TSF with some information that is known by the TSF to be associated with the user in question. Families in this class address the requirements for functions to establish and verify a claimed user identity. Identification and Authentication is required to ensure that users are associated with the proper security attributes. Security attributes include identity, groups, roles, security, or integrity levels. The unambiguous identification of authorized users and the correct association of security attributes with users and subjects is critical to the enforcement of the security policies. The family addresses defining limits on repeated unsuccessful authentication attempts. The family addresses defining the functionality provided by the TOE to prove its identity and to be verified by an external entity in the TOE IT environment. The family addresses the definition of user attributes that are used in the enforcement of the SFRs. The family addresses the generation and verification of secrets that satisfy a defined metric. The family addresses verifying the identity of a user. The family addresses determining the identity of a user. The family addresses the correct association of security attributes for each authorized user. This family contains requirements for defining values for some number of unsuccessful authentication attempts and TSF actions in cases of authentication attempt failures. Parameters include, but are not limited to, the number of failed authentication attempts and time thresholds. This family addresses requirements for defining values for authentication attempts and TSF actions in cases of authentication attempt failure. Parameters include, but are not limited to, the number of attempts and time thresholds. The session establishment process is the interaction with the user to perform the session establishment independent of the actual implementation. If the number of unsuccessful authentication attempts exceeds the indicated threshold, either the user account or the terminal (or both) will be locked. If the user account is disabled, the user cannot log-on to the system. If the terminal is disabled, the terminal (or the address that the terminal has) cannot be used for any log-on. Both of these situations continues until the condition for re-establishment is satisfied. The author of a PP, PP-Module, functional package or ST may define the number of unsuccessful authentication attempts or may choose to let the TOE developer or the authorized user to define this number. The unsuccessful authentication attempts need not be consecutive, but rather related to an authentication event. Such an authentication event can be the count from the last successful session establishment at a given terminal. The author of a PP, PP-Module, functional package or ST can specify a list of actions that the TSF shall take in the case of authentication failure. An authorized administrator can also be allowed to manage the events, if deemed opportune by the author of a PP, PP-Module, functional package or ST. These actions can be, among other things, terminal deactivation, user account deactivation, or administrator alarm. The conditions under which the situation will be restored to normal be specified on the action. In order to prevent denial of service, TOEs usually ensure that there is at least one user account that cannot be disabled. Further actions for the TSF can be stated by the author of a PP, PP-Module, functional package or ST, including rules for re-enabling the user session establishment process, or sending an alarm to the administrator. Examples of these actions are: until a specified time has lapsed; until the authorized administrator re-enables the terminal/account; a time related to failed previous attempts (every time the attempt fails, the disabling time is doubled). requires that the TSF be able to terminate the session establishment process after a specified number of unsuccessful user authentication attempts. It also requires that, after termination of the session establishment process, the TSF be able to disable the user account or the point of entry from which the attempts were made until an administrator-defined condition occurs. Management of the threshold for unsuccessful authentication attempts Management of actions to be taken in the event of an authentication failure The reaching of the threshold for the unsuccessful authentication attempts and the actions taken and the subsequent, if appropriate, restoration to the normal state The TSF shall detect when positive integer number an administrator configurable positive integer within range of acceptable values unsuccessful authentication attempts occur related to list of authentication events . When the defined number of unsuccessful authentication attempts has been met surpassed the author of a PP, PP-Module, functional package or ST should select whether the event of meeting or surpassing the defined number of unsuccessful authentication attempts shall trigger an action by the TSF. , the TSF shall list of actions the author of a PP, PP-Module, functional package or ST should specify the actions to be taken in case the threshold is met or surpassed, as selected. These actions can be disabling of an account for 5 minutes, disabling the terminal for an increasing amount of time (2 to the power of the number of unsuccessful attempts in seconds), or disabling of the account until unlocked by the administrator and simultaneously informing the administrator. The actions should specify the measures and if applicable the duration of the measure (or the conditions under which the measure will be ended). . This family defines functions provided by the TOE to prove its identity and so allow for verification of the TOE by an external entity in the TOE's IT environment. The other families of describe only the authentication verification of users' identity performed by the TOE and do not describe the functionality of the user to prove their identity. The family allows the specification the functionality allowing a TOE to prove its own identity. allows the specification of the authentication mechanism used to support proving the identity of the TOE to external entities. Authentication Proof of Identity, provides proof of the identity of the TOE to an external entity. Management of authentication information used to prove the claimed identity The TSF shall provide an authentication mechanism the first assignment is where a PP, PP-Module, functional package or ST author specifies the authentication mechanism to be used. to prove the identity of entity by including the following properties list of properties Examples of such an authentication method is "an Authentication Mechanism based on Triple-DES" and "Chip Authentication Protocol according to TR-03110". to an external entity. All authorized users may have a set of security attributes, other than the user's identity, that is used to enforce the SFRs. This family defines the requirements for associating user security attributes with users as needed to support the TSF in making security decisions. All authorized users may have a set of security attributes, other than the user's identity, that are used to enforce the SFRs. This family defines the requirements for associating user security attributes with users as needed to support the TSF in making security decisions. There are dependencies on the individual security policy (SFP) definitions. These individual definitions should contain the listing of attributes that are necessary for policy enforcement. This component specifies the security attributes that should be maintained at the level of the user. This means that the security attributes listed are assigned to and can be changed at the level of the user. In other words, changing a security attribute in this list associated with a user should have no impact on the security attributes of any other user. In case security attributes belong to a group of users (such as a capability list for a group), the user will need to have a reference (as a security attribute) to the relevant group. , allows user security attributes for each user to be maintained individually. If indicated in the assignment, the authorized administrator can be able to define additional security attributes for users The TSF shall maintain the following list of security attributes belonging to individual users: list of security attributes the author of a PP, PP-Module, functional package or ST should specify the security attributes that are associated to an individual user. . This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets and generate secrets to satisfy the defined metric. This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets and generate secrets to satisfy the defined metric. Examples of such mechanisms may include automated checking of user supplied passwords, or automated password generation. A secret can be generated outside the TOE. An example of a secret generated outside of the TOE can be one that is selected by the user and introduced in the TOE. In such cases, the component can be used to ensure that the external generated secret adheres to certain standards, for example a minimum size, not present in a dictionary, and/or not previously used. Secrets can also be generated by the TOE. In those cases, the component can be used to require the TOE to ensure that the secrets that will adhere to some specified metrics. Secrets contain the authentication data provided by the user for an authentication mechanism that is based on knowledge the user possesses. When cryptographic keys are employed, the class should be used instead of this family. Secrets can be generated by the user. This component ensures that those user generated secrets can be verified to meet a certain quality metric. requires the TSF to verify that secrets meet defined quality metrics. The management of the metric used to verify the secrets Rejection by the TSF of any tested secret Rejection or acceptance by the TSF of any tested secret Identification of any changes to the defined quality metrics The TSF shall provide a mechanism to verify that secrets meet a defined quality metric the author of a PP, PP-Module, functional package or ST provides a defined quality metric. The quality metric specification may be as simple as a description of the quality checks to be performed, or as formal as a reference to a government published standard that defines the quality metrics that secrets must meet. . This component allows the TSF to generate secrets for specific functions such as authentication by means of passwords. When a pseudo-random number generator is used in a secret generation algorithm, it should accept as input random data that would provide output that has a high degree of unpredictability. This random data (seed) can be derived from a number of available parameters such as a system clock, system registers, date, time, etc. The parameters should be selected to ensure that the number of unique seeds that can be generated from these inputs should be at least equal to the minimum number of secrets that must be generated. requires the TSF to be able to generate secrets that meet defined quality metrics. The management of the metric used to generate the secrets The TSF shall provide a mechanism to generate secrets that meet a defined quality metric the author of a PP, PP-Module, functional package or ST provides a defined quality metric. The quality metric specification can be as simple as a description of the quality checks to be performed or as formal as a reference to a government published standard that defines the quality metrics that secrets must meet. . The TSF shall be able to enforce the use of TSF generated secrets for list of TSF functions the author of a PP, PP-Module, functional package or ST provides a list of TSF functions for which the TSF generated secrets shall be used. . This family defines the types of user authentication mechanisms supported by the TSF. This family also defines the required attributes on which the user authentication mechanisms be based. This family defines the types of user authentication mechanisms supported by the TSF. This family defines the required attributes on which the user authentication mechanisms are based. This component requires that the author of a PP, PP-Module, functional package or ST define the TSF-mediated actions that can be performed by the TSF on behalf of the user before the claimed identity of the user is authenticated. The TSF-mediated actions should have no security concerns with users incorrectly identifying themselves prior to being authenticated. For all other TSF-mediated actions not in the list, the user shall be authenticated before the action can be performed by the TSF on behalf of the user. This component cannot control whether the actions can also be performed before the identification took place. This requires the use of either or with the appropriate assignments. , allows a user to perform certain actions prior to the authentication of the user's identity. Management of the authentication data by an administrator Management of the authentication data by the associated user Managing the list of actions that can be taken before the user is authenticated Unsuccessful use of the authentication mechanism All use of the authentication mechanism All TSF mediated actions performed before authentication of the user The TSF shall allow list of TSF mediated actions the author of a PP, PP-Module, functional package or ST specifies a list of TSF-mediated actions that can be performed by the TSF on behalf of a user before the claimed identity of the user is authenticated. This list cannot be empty. If no actions are appropriate, component should be used instead. on behalf of the user to be performed before the user is authenticated. The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. This component requires that a user is authenticated before any other TSF-mediated action can take place on behalf of that user. requires that users are authenticated before any other action will be allowed by the TSF. Management of the authentication data by an administrator Management of the authentication data by the user associated with this data Unsuccessful use of the authentication mechanism All use of the authentication mechanism The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. This component addresses requirements for mechanisms that provide protection of authentication data. Authentication data that is copied from another user or is in some way constructed should be detected and/or rejected. These mechanisms provide confidence that users authenticated by the TSF are actually who they claim to be. This component may be useful only with authentication mechanisms that are based on authentication data that cannot be shared. It is impossible for a TSF to detect or prevent the sharing of passwords outside the control of the TSF. requires the authentication mechanism to be able to detect and prevent the use of authentication data that has been forged or copied. Detection of fraudulent authentication data All immediate measures taken and results of checks on the fraudulent data The TSF shall detect prevent the author of a PP, PP-Module, functional package or ST should specify whether the TSF will detect, prevent, or detect and prevent forging of authentication data. use of authentication data that has been forged by any user of the TSF. The TSF shall detect prevent the author of a PP, PP-Module, functional package or ST should specify whether the TSF will detect, prevent, or detect and prevent copying of authentication data. use of authentication data that has been copied from any other user of the TSF. This component addresses requirements for authentication mechanisms based on single-use authentication data. Single-use authentication data can be something the user has or knows, but not something the user is. Single-use authentication data include single-use passwords, encrypted time-stamps, and/or random numbers from a secret lookup table. The author of a PP, PP-Module, functional package or ST can specify to which authentication mechanism(s) this requirement applies. requires an authentication mechanism that operates with single-use authentication data. Attempts to reuse authentication data The TSF shall prevent reuse of authentication data related to identified authentication mechanism(s) the author of a PP, PP-Module, functional package or ST should specify the list of authentication mechanisms to which this requirement applies. This assignment can be "all authentication mechanisms". . The use of this component allows specification of requirements for more than one authentication mechanism to be used within a TOE. For each distinct mechanism, applicable requirements are chosen from the class to be applied to each mechanism. It is possible that the same component is selected multiple times in order to reflect different requirements for the different use of the authentication mechanism. The management functions in the class provide maintenance capabilities for the set of authentication mechanisms, as well as the rules that determine whether the authentication was successful. To allow anonymous users to interact with the TOE, a "none" authentication mechanism may be incorporated. The use of such access needs to be clearly explained in the rules of . requires that different authentication mechanisms be provided and used to authenticate user identities for specific events. The management of authentication mechanisms The final decision on authentication The result of each activated mechanism together with the final decision The TSF shall provide list of multiple authentication mechanisms the author of a PP, PP-Module, functional package or ST defines the available authentication mechanisms. to support user authentication. The TSF shall authenticate any user's claimed identity according to the rules describing how the multiple authentication mechanisms provide authentication the author of a PP, PP-Module, functional package or ST specifies the rules that describe how the authentication mechanisms provide authentication and when each is to be used. This means that for each situation the set of mechanisms used for authenticating the user shall be described. . This component addresses potential needs to re-authenticate users at defined points in time. These may include user requests for the TSF to perform security relevant actions, as well as requests from non-TSF entities for re-authentication. A server application requesting that the TSF re-authenticate the client it is serving. requires the ability to specify events for which the user needs to be re-authenticated. If an authorized administrator can request re-authentication, the management includes a re-authentication request Failure of re-authentication All re-authentication attempts The TSF shall re-authenticate the user under the conditions list of conditions under which re-authentication is required the author of a PP, PP-Module, functional package or ST specifies the list of conditions requiring re-authentication. This list may include a specified user inactivity period that has elapsed, the user requesting a change in active security attributes, or the user requesting the TSF to perform some security critical function. . This component addresses the feedback on the authentication process that will be provided to the user. In some systems, the feedback consists of indicating how many characters have been typed but not showing the characters themselves, in other systems even this information can not be appropriate. This component requires that the authentication data is not provided as-is back to the user. In a workstation environment, it can display a substitute character for each password character provided, and not the original character. A star "*" character. requires that only limited feedback information is provided to the user during the authentication. The management of the rules for authentication well-formedness of rules regarding the semantics of rule-set Verification of enforceability of rules The TSF shall provide only list of feedback to the user while the authentication is in progress. This family defines the conditions under which users shall be required to identify themselves before performing any other actions that are to be mediated by the TSF and which require user identification. This family defines the conditions under which users are required to identify themselves before performing any other actions that are to be mediated by the TSF and that require user identification. This component poses requirements for the user to be identified. The author of a PP, PP-Module, functional package or ST may indicate specific actions that are performed before the identification takes place. If is used, the TSF-mediated actions mentioned in should also appear in this . , allows users to perform certain actions before being identified by the TSF. The management of the user identities If an authorized administrator can change the actions allowed before identification, the managing of the action lists Unsuccessful use of the user identification mechanism, including the user identity provided All use of the user identification mechanism, including the user identity provided The TSF shall allow list of TSF-mediated actions the author of a PP, PP-Module, functional package or ST specifies a list of TSF-mediated actions that can be performed by the TSF on behalf of a user before the user has to identify itself. If no actions are appropriate, component should be used instead. on behalf of the user to be performed before the user is identified. The TSF shall require each user to be successfully identified before allowing any TSF-mediated actions on behalf of that user. In this component users will be identified. A user is not allowed by the TSF to perform any action before being identified. requires that users identify themselves before any action will be allowed by the TSF. The management of the user identities The TSF shall require each user to be successfully identified before allowing any TSF-mediated actions on behalf of that user. An authenticated user, in order to use the TOE, typically activates a subject. The user's security attributes are associated (totally or partially) with this subject. This family defines requirements to create and maintain the association of the user's security attributes to a subject acting on the user's behalf. An authenticated user, in order to use the TOE, typically activates a subject. The user's security attributes are associated (totally or partially) with this subject. This family defines requirements to create and maintain the association of the user's security attributes to a subject acting on the user's behalf. It is intended that a subject is acting on behalf of the user who caused the subject to come into being or to be activated to perform a certain task. Therefore, when a subject is created, that subject is acting on behalf of the user who initiated the creation. In cases where anonymity is used, the subject is still acting on behalf of a user, but the identity of that user is unknown. A special category of subjects is those subjects that serve multiple users. In such cases the user that created this subject is assumed to be the "owner". An example of a user is a server process. requires the specification of any rules governing the association between user attributes and the subject attributes into which they are mapped. An authorized administrator can define default subject security attributes An authorized administrator can change subject security attributes Unsuccessful binding of user security attributes to a subject Success and failure of binding of user security attributes to a subject The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: list of user security attributes the author of a PP, PP-Module, functional package or ST should specify a list of the user security attributes that are to be bound to subjects. . The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: rules for the initial association of attributes the author of a PP, PP-Module, functional package or ST should specify any rules that are to apply upon initial association of attributes with subjects, or "none". . The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: rules for the changing of attributes the author of a PP, PP-Module, functional package or ST should specify any rules that are to apply when changes are made to the user security attributes associated with subjects acting on behalf of users, or "none". . This class is intended to specify the management of several aspects of the TSF: security attributes, TSF data and functions. The different management roles and their interaction, such as separation of capability, can be specified. This class has the following objectives: management of TSF data; management of security attributes; management of functions of the TSF; definition of security roles. This class specifies the management of several aspects of the TSF: Security attributes, TSF data and functions in the TSF. The different management roles and their interaction, such as separation of capability, can also be specified. In an environment where the TOE is made up of multiple physically separated parts, the timing issues with respect to propagation of security attributes, TSF data, and function modification become very complex, especially if the information is required to be replicated across the parts of the TOE. This should be considered when selecting components such as , or , where the behaviour can be impaired. In such situations, use of components from is advisable. The family provides requirements that allow the specification of a policy that limits the capabilities and the availability of TSF functions. This is useful when a PP, PP-Module, functional package or ST author needs to enforce design principles such as least privilege and attack surface minimization. These, and other architectural and design principles along with appropriate evaluation considerations are discussed in ISO/IEC TS 19249. This family defines requirements that limit the capabilities and availability of functions in a combined manner. restricts the access to functions whereas the component Limited Capability of this family requires the functions themselves to be designed in a specific manner. The functional requirements and assume that there are two types of mechanisms (limitation of capabilities and limitation of availability) which together provide protection in order to enforce the policy. This also allows that the TSF is provided without restrictions in the product in its user environment but its capabilities are so limited that the policy is enforced; or conversely the TSF is designed with high functionality but is removed or disabled in the product in its user environment. The combination of both requirements shall enforce the policy. An example of a limited capability is JTAG interface enablement, which can be either enabled or disabled. requires that the TSF is built to provide only the capabilities (perform action, gather information) necessary for its genuine purpose. The TSF shall limit its capabilities so that in conjunction with the following policy is enforced: Limited capability and availability policy the author of a PP, PP-Module, functional package or ST should specify the limited capability policy. . An example of a limited availability is JTAG interface enablement, which can be either enabled or disabled before operational use of the TOE. requires that the TSF restrict the use of functions (refer to ). This can be achieved, for instance, by removing or by disabling functions in a specific phase of the TOE's life-cycle. The TSF shall be designed in a manner that limits its availability so that in conjunction with the following policy is enforced: Limited capability and availability policy the author of a PP, PP-Module, functional package or ST should specify the limited availability policy. . This family allows authorized users to control over the management of functions in the TSF. The TSF management functions enable authorized users to set up and control the secure operation of the TOE. These administrative functions typically fall into a number of different categories: management functions that relate to access control, accountability and authentication controls enforced by the TOE. For example, definition and update of user security characteristics or definition and update of auditing system controls, definition and update of per-user policy attributes, definition of known system access control labels, and control and management of user groups; User security characteristics: unique identifiers associated with user names, user accounts, system entry parameters. Auditing system controls: selection of audit events, management of audit trails, audit trail analysis, and audit report generation. User policy attributes: user clearance. management functions that relate to controls over availability; Definition and update of availability parameters or resource quotas. management functions that relate to general installation and configuration; TOE configuration, manual recovery, installation of TOE security fixes (if any), repair and reinstallation of hardware. management functions that relate to routine control and maintenance of TOE resources. Enabling and disabling peripheral devices, mounting of removable storage media, backup, and recovery. These functions need to be present in a TOE based on the families included in the PP or ST. It is the responsibility of the author of a PP, PP-Module, functional package or ST to ensure that adequate functions will be provided to manage the TOE in a secure fashion. The TSF can contain functions that can be controlled by an administrator. The auditing functions can be switched off, the time synchronization can be switchable, and/or the authentication mechanism can be modifiable. This component allows identified roles to manage the security functions of the TSF. This can entail obtaining the current status of a security function, disabling, or enabling the security function, or modifying the behaviour of the security function. Modifying the behaviour of the security functions is changing of authentication mechanisms. allows the authorized users (roles) to manage the behaviour of functions in the TSF that use rules or have specified conditions that may be manageable. Managing the group of roles that can interact with the functions in the TSF All modifications in the behaviour of the functions in the TSF The TSF shall restrict the ability to determine the behaviour of disable enable modify the behaviour of the author of a PP, PP-Module, functional package or ST should select whether the role can determine the behaviour of, disable, enable, and/or modify the behaviour of the security functions. the functions list of functions the author of a PP, PP-Module, functional package or ST should specify the functions that can be modified by the identified roles. Examples include auditing and time determination. to the authorized identified roles the author of a PP, PP-Module, functional package or ST should specify the roles that are allowed to modify the functions in the TSF. The possible roles are specified in . . This family allows authorized users control over the management of security attributes. This management can include capabilities for viewing and modifying of security attributes. This family defines the requirements on the management of security attributes. Security attributes affect the behaviour of the TSF. Examples of security attributes are the groups to which a user belongs, the roles he or she can assume, the priority of a process (subject), and the rights belonging to a role or a user. These security attributes can need to be managed by the user, a subject, a specific authorized user (a user with explicitly given rights for this management) or inherit values according to a given policy/set of rules. It is noted that the right to assign rights to users is itself a security attribute and/or potentially subject to management by . can be used to ensure that any accepted combination of security attributes is within a secure state. The definition of what "secure" means is left to the TOE guidance. In some instances, subjects, objects, or user accounts are created. If no explicit values for the related security attributes are given, default values need to be used. can be used to specify that these default values can be managed. This component allows users acting in certain roles to manage identified security attributes. The users are assigned to a role within the component . The default value of a parameter is the value the parameter takes when it is instantiated without specifically assigned values. An initial value is provided during the instantiation (creation) of a parameter and overrides the default value. allows authorized users (roles) to manage the specified security attributes. Managing the group of roles that can interact with the security attributes Management of rules by which security attributes inherit specified values All modifications of the values of security attributes The TSF shall enforce the access control SFP(s), information flow control SFP(s) the author of a PP, PP-Module, functional package or ST should list the access control SFP(s) or the information flow control SFP(s) for which the security attributes are applicable. to restrict the ability to change_default query modify delete other operations the author of a PP, PP-Module, functional package or ST should specify the operations that can be applied to the identified security attributes. The author of a PP, PP-Module, functional package or ST can specify that the role can modify the default value (change_default), query, modify the security attribute, delete the security attributes entirely or define their own operation. the author of a PP, PP-Module, functional package or ST should specify the security attributes that can be operated on by the identified roles. It is possible for the author of a PP, PP-Module, functional package or ST to specify that the default value such as default access-rights can be managed. the security attributes list of security attributes to the authorized identified roles Examples of these security attributes are user-clearance, priority of service level, access control list, default access rights. . This component contains requirements on the values that can be assigned to security attributes. The assigned values should be such that the TOE will remain in a secure state. The definition of what "secure" means is not answered in this component but is left to the development of the TOE and the resulting information in the guidance. An example can be that if a user account is created, it should have a non-trivial password. ensures that values assigned to security attributes are valid with respect to the secure state. Management of rules by which security attributes inherit specified values All offered and rejected values for a security attribute All offered and accepted secure values for a security attribute The TSF shall ensure that only secure values are accepted for list of security attributes the author of a PP, PP-Module, functional package or ST should specify the list of security attributes that require only secure values to be provided. . This component requires that the TSF provide default values for relevant object security attributes, which can be overridden by an initial value. It may still be possible for a new object to have different security attributes at creation if a mechanism exists to specify the permissions at time of creation. ensures that the default values of security attributes are appropriately either permissive or restrictive in nature. Managing the group of roles that can specify initial values Managing the permissive or restrictive setting of default values for a given access control SFP Management of rules by which security attributes inherit specified values Modifications of the default setting of permissive or restrictive rules All modifications of the initial values of security attributes The TSF shall enforce the access control SFP, information flow control SFP the author of a PP, PP-Module, functional package or ST should list the access control SFP or the information flow control SFP for which the security attributes are applicable. to provide restrictive permissive other property the author of a PP, PP-Module, functional package or ST should select whether the default property of the access control attribute will be restrictive, permissive, or another property. Only one of these options may be chosen. if the author of a PP, PP-Module, functional package or ST selects another property, the author of a PP, PP-Module, functional package or ST should specify the desired characteristics of the default values. default values for security attributes that are used to enforce the SFP. The TSF shall allow the the authorized identified roles the author of a PP, PP-Module, functional package or ST should specify the roles that are allowed to modify the values of the security attributes. The possible roles are specified in . to specify alternative initial values to override the default values when an object or information is created. This component requires specification of the set of rules through which the security attribute inherits values and the conditions to be met for these rules to be applied. allows the rules/policies to be specified that will dictate the value to be inherited by a security attribute. Specification of the role permitted to establish or modify security attributes Modifications of security attributes, possibly with the old and/or values of security attributes that were modified The TSF shall use the following rules to set the value of security attributes: rules for setting the values of security attributes the author of a PP, PP-Module, functional package or ST specifies the rules governing the value that will be inherited by the specified security attribute, including the conditions that are to be met for the rules to be applied. . This family allows authorized users (roles) control over the management of TSF data. This component imposes requirements on the management of TSF data. Examples of TSF data are the current time and the audit trail. This family allows the specification of whom can read, delete, or create the audit trail. This component allows users with a certain role to manage values of TSF data. The users are assigned to a role within the component . The default value of a parameter is the values the parameter takes when it is instantiated without specifically assigned values. An initial value is provided during the instantiation (creation) of a parameter and overrides the default value. allows authorized users to manage TSF data. Managing the group of roles that can interact with the TSF data All modifications to the values of TSF data The TSF shall restrict the ability to change_default query modify delete clear other operations the author of a PP, PP-Module, functional package or ST should specify the operations that can be applied to the identified TSF data. The author of a PP, PP-Module, functional package or ST can specify that the role can modify the default value (change_default), clear, query or modify the TSF data, or delete the TSF data entirely. If demanded, the author of a PP, PP-Module, functional package or ST can specify any type of operation. To clarify "clear TSF data" means that the content of the TSF data is removed, but that the entity that stores the TSF data remains in the TOE. the author of a PP, PP-Module, functional package or ST should specify the TSF data that can be operated on by the identified roles. It is possible for the author of a PP, PP-Module, functional package or ST to specify that the default value can be managed. the list of TSF data the author of a PP, PP-Module, functional package or ST should specify the roles that are allowed to operate on the TSF data. The possible roles are specified in . to the authorized identified roles if selected, the author of a PP, PP-Module, functional package or ST should specify which other operations the role can perform. . This component specifies limits on TSF data, and actions to be taken if these limits are exceeded. This component will allow limits on the size of the audit trail to be defined, and specification of the actions to be taken when these limits are exceeded. specifies the action to be taken if limits on TSF data are reached or exceeded. Managing the group of roles that can interact with the limits on the TSF data All modifications to the limits on TSF data All modifications in the actions to be taken in case of violation of the limits The TSF shall restrict the specification of the limits for list of TSF data the author of a PP, PP-Module, functional package or ST should specify the TSF data that can have limits, and the value of those limits. An example of such TSF data is the number of users logged-in. to the authorized identified roles the author of a PP, PP-Module, functional package or ST should specify the roles that are allowed to modify the limits on the TSF data and the actions to be taken. The possible roles are specified in . . The TSF shall take the following actions, if the TSF data are at, or exceed, the indicated limits: actions to be taken the author of a PP, PP-Module, functional package or ST should specify the actions to be taken if the specified limit on the specified TSF data is exceeded. . This component covers requirements on the values that can be assigned to TSF data. The assigned values should be such that the TOE will remain in a secure state. The definition of what "secure" means is not answered in this component but is left to the development of the TOE and the resulting information in the guidance. ensures that values assigned to TSF data are valid with respect to the secure state. All rejected values of TSF data The TSF shall ensure that only secure values are accepted for list of TSF data the author of a PP, PP-Module, functional package or ST should specify what TSF data require only secure values to be accepted. . This family addresses revocation of security attributes for a variety of entities within a TOE. This family addresses revocation of security attributes for a variety of entities within a TOE. This component specifies requirements on the revocation of rights. It requires the specification of the revocation rules. Examples are: revocation will take place on the next login of the user; revocation will take place on the next attempt to open the file; revocation will take place within a fixed time. This can mean that all open connections are re-evaluated every x minutes. provides for revocation of security attributes to be enforced at some point in time. Managing the group of roles that can invoke revocation of security attributes Managing the lists of users, subjects, objects, and other resources for which revocation is possible Managing the revocation rules Unsuccessful revocation of security attributes All attempts to revoke security attributes The TSF shall restrict the ability to revoke list of security attributes the author of a PP, PP-Module, functional package or ST should specify which security attributes are to be revoked when a change is made to the associated object/subject/user/other resource. associated with the users subjects objects other additional resources the author of a PP, PP-Module, functional package or ST should specify whether the ability to revoke security attributes from users, subjects, objects, or any additional resources shall be provided by the TSF. the author of a PP, PP-Module, functional package or ST should specify the roles that are allowed to modify the functions in the TSF. The possible roles are specified in . under the control of the TSF to the authorized identified roles the author of a PP, PP-Module, functional package or ST should, if additional resources is selected, specify whether the ability to revoke their security attributes shall be provided by the TSF. . The TSF shall enforce the rules specification of revocation rules the author of a PP, PP-Module, functional package or ST should specify the revocation rules. Examples of these rules can include: "prior to the next operation on the associated resource", or "for all new subject creations". . This family addresses the capability to enforce time limits for the validity of security attributes. This family addresses the capability to enforce time limits for the validity of security attributes. This family can be applied to specify expiration requirements for access control attributes, identification and authentication attributes, certificates, audit attributes, etc. An example of a certificate is key certificates such as ANSI X509. No component rationale or application notes have been provided. provides the capability for an authorized user to specify an expiration time on specified security attributes. Managing the list of security attributes for which expiration is to be supported The actions to be taken if the expiration time has passed Specification of the expiration time for an attribute Action taken due to attribute expiration The TSF shall restrict the capability to specify an expiration time for list of security attributes for which expiration is to be supported the author of a PP, PP-Module, functional package or ST should provide the list of security attributes for which expiration is to be supported. to the authorized identified roles an example of such an attribute can be a user's security clearance. . For each of these security attributes, the TSF shall be able to list of actions to be taken for each security attribute the author of a PP, PP-Module, functional package or ST should provide a list of actions to be taken for each security attribute when it expires. An example can be that the user's security clearance, when it expires, is set to the lowest allowable clearance on the TOE. If immediate revocation is desired by the PP, PP-Module, functional package or ST, the action "immediate revocation" should be specified. after the expiration time for the indicated security attribute has passed. This family allows the specification of the management functions to be provided by the TOE. Management functions provide TSFI that allow administrators to define the parameters that control the operation of security-related aspects of the TOE, such as data protection attributes, TOE protection attributes, audit attributes, and identification and authentication attributes. Management functions also include those functions performed by an operator to ensure continued operation of the TOE, such as backup and recovery. This family works in conjunction with the other components in the class: the component in this family calls out the management functions, and other families in restricts the ability to use these management functions. This family allows the specification of the management functions to be provided by the TOE. Each security management function that is listed in fulfilling the assignment is either security attribute management, TSF data management, or security function management. This component specifies the management functions to be provided. PP, PP-Module, functional package or ST authors should consult the "Management" subclauses for components included in their PP, PP-Module, functional package or ST to provide a basis for the management functions to be listed via this component. requires that the TSF provide specific management functions. Use of the management functions The TSF shall be capable of performing the following management functions: list of management functions to be provided by the TSF the author of a PP, PP-Module, functional package or ST should specify the management functions to be provided by the TSF, either security attribute management, TSF data management, or security function management. . This family is intended to control the assignment of different roles to users. The capabilities of these roles with respect to security management are described in the other families in this class. This family reduces the likelihood of damage resulting from users abusing their authority by taking actions outside their assigned functional responsibilities. It also addresses the threat that inadequate mechanisms have been provided to securely administer the TSF. This family requires that information be maintained to identify whether a user is authorized to use a particular security-relevant administrative function. Some management actions can be performed by users, others only by designated people within the organization. This family allows the definition of different roles, such as owner, auditor, administrator, daily-management. The roles as used in this family are security related roles. Each role can encompass an extensive set of capabilities or can be a single right. This family defines the roles. The capabilities of the role are defined in , and . Set of capabilities: root in UNIX. Single right: right to read a single object such as the helpfile. Some type of roles can be mutually exclusive. The daily-management can be able to define and activate users but can not be able to remove users, which is reserved for the administrator (role). This class will allow policies such as two-person control to be specified. This component specifies the different roles that the TSF should recognize. Often the system distinguishes between the owner of an entity, an administrator, and other users. specifies the roles with respect to security that the TSF recognizes. Managing the group of users that are part of a role Modifications to the group of users that are part of a role Every use of the rights of a role The TSF shall maintain the roles the authorized identified roles the author of a PP, PP-Module, functional package or ST should specify the roles that are recognized by the system. These are the roles that users can occupy with respect to security. . The TSF shall be able to associate users with roles. This component specifies the different roles that the TSF should recognize, and conditions on how those roles can be managed. Often the system distinguishes between the owner of an entity, an administrator, and other users. The conditions on those roles specify the interrelationship between the different roles, as well as restrictions on when the role can be assumed by a user. specifies that in addition to the specification of the roles, there are rules that control the relationship between the roles. Managing the group of users that are part of a role Managing the conditions that the roles must satisfy Modifications to the group of users that are part of a role Unsuccessful attempts to use a role due to the given conditions on the roles Every use of the rights of a role The TSF shall maintain the roles: authorized identified roles the author of a PP, PP-Module, functional package or ST should specify the roles that are recognized by the system. These are the roles that users can occupy with respect to security. . The TSF shall be able to associate users with roles. The TSF shall ensure that the conditions conditions for the different roles the author of a PP, PP-Module, functional package or ST should specify the conditions that govern role assignment. are satisfied. This component specifies that an explicit request shall be given to assume the specific role. requires that an explicit request is given to the TSF to assume a role. Explicit request to assume a role The TSF shall require an explicit request to assume the following roles: the roles the author of a PP, PP-Module, functional package or ST should specify the roles that require an explicit request to be assumed. Examples of roles are: owner, auditor, and administrator. . This class contains privacy requirements. These requirements provide a user protection against discovery and misuse of identity by other users. This class describes the requirements that can be levied to satisfy the users' privacy needs, while still allowing the system flexibility as far as possible to maintain sufficient control over the operation of the system. In the components of this class there is flexibility as to whether or not authorized users are covered by the required security functionality. A PP, PP-Module, functional package or ST author can consider it appropriate not to require protection of the privacy of users against a suitably authorized user. This class, together with other classes (such as those concerned with audit, access control, trusted path, and non-repudiation) provides the flexibility to specify the desired privacy behaviour. On the other hand, the requirements in this class can impose limitations on the use of the components of other classes, such as or . If authorized users are not allowed to see the user identity (perhaps because of Anonymity or Pseudonymity), it will obviously not be possible to hold individual users accountable for any security relevant actions they perform that are covered by the privacy requirements. However, it can still be possible to include audit requirements in a PP, PP-Module, functional package or ST, where the fact that a particular security relevant event has occurred is more important than knowing who was responsible for it. Additional information is provided in the application notes for class , where it is explained that the definition of "identity" in the context of auditing can also be an alias or other information that can identify a user. This class describes four families: Anonymity, Pseudonymity, Unlinkability and Unobservability. Anonymity, Pseudonymity and Unlinkability have a complex interrelationship. When choosing a family, the choice should depend on the threats identified. For some types of privacy threats, pseudonymity will be more appropriate than anonymity. If there is a requirement for auditing. In addition, some types of privacy threats are best countered by a combination of components from several families. All families assume that a user does not explicitly perform an action that discloses the user's own identity. The TSF is not expected to screen the user name in electronic messages or databases. All families in this class have components thatscoped through operations. These operations allow the author of a PP, PP-Module, functional package or ST to state the cooperating users/subjects to which the TSF must be resistant. An instantiation of anonymity can be, "The TSF ensure that the users and/or subjects are unable to determine the user identity bound to the teleconsulting application". It is noted that the TSF should not only provide this protection against individual users, but also against users cooperating to obtain the information. The reader's attention is drawn to ISO/IEC TS 19608, which is based on CC. ISO/IEC TS 19608: selecting and specifying SFRs from CC Part 2 to protect Personally Identifiable Information (PII); the procedure to define both privacy and SFRs in a coordinated manner; developing privacy functional requirements as extended components based on the privacy principles defined in ISO/IEC 29100 through the paradigm described in CC Part 2. This family ensures that a user can use a resource or service without disclosing the user's identity. The requirements for anonymity provide protection of the user identity. Anonymity is not intended to protect the subject identity. Anonymity ensures that a subject may use a resource or service without disclosing its user identity. The intention of this family is to specify that a user or subject can take action without releasing its user identity to others such as users, subjects, or objects. The family provides the author of a PP, PP-Module, functional package or ST with a means to identify the set of users that cannot see the identity of someone performing certain actions. Therefore. if a subject, using anonymity, performs an action, another subject will not be able to determine either the identity or even a reference to the identity of the user employing the subject. The focus of the anonymity is on the protection of the user's identity, not on the protection of the subject identity; hence, the identity of the subject is not protected from disclosure. Although the identity of the subject is not released to other subjects or users, the TSF is not explicitly prohibited from obtaining the users identity. In case the TSF is not allowed to know the identity of the user, can be invoked. In that case, the TSF should not request the user information. The interpretation of "determine" should be taken in the broadest sense of the word. The Components leveling and description distinguishes between the users and an authorized user. An authorized user is often excluded from the component, and therefore allowed to retrieve a user's identity. However, there is no specific requirement that an authorized user be able to have the capability to determine the user's identity. For ultimate privacy, the components would be used to say that no user or authorized user can see the identity of anyone performing any action. Although some systems will provide anonymity for all services that are provided, other systems provide anonymity for certain subjects/operations. To provide this flexibility, an operation is included where the scope of the requirement is defined. If the author of a PP, PP-Module, functional package or ST wants to address all subjects/operations, the words "all subjects and all operations" can be provided. Possible applications include the ability to make enquiries of a confidential nature to public databases, respond to electronic polls, or make anonymous payments or donations. Potential hostile users or subjects include providers, system operators, communication partners and users, who smuggle malicious parts (including malware) into systems. All of these users can investigate usage patterns (such as which users used which services) and misuse this information. This component ensures that the identity of a user is protected from disclosure. There may be instances, however, that a given authorized user can determine who performed certain actions. This component gives the flexibility to capture either a limited or total privacy policy. requires that other users or subjects are unable to determine the identity of a user bound to a subject or operation. The invocation of the anonymity mechanism The TSF shall ensure that set of users and/or subjects the author of a PP, PP-Module, functional package or ST should specify the set of users and/or subjects against which the TSF provides protection. For example, even if the author of a PP, PP-Module, functional package or ST specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject but also protect with respect to cooperating users and/or subjects. are unable to determine the real user name bound to list of subjects and/or operations and/or objects . This component is used to ensure that the TSF is not allowed to know the identity of the user. enhances the requirements of by ensuring that the TSF does not ask for the user identity. The TSF shall ensure that set of users and/or subjects the author of a PP, PP-Module, functional package or ST should specify the set of users and/or subjects against which the TSF provides protection. are unable to determine the real user name bound to list of subjects and/or operations and/or objects . The TSF shall provide list of services the author of a PP, PP-Module, functional package or ST should identify the list of services which are subject to the anonymity requirement, for example, "the accessing of job descriptions". to list of subjects the author of a PP, PP-Module, functional package or ST should identify the list of subjects from which the real user name of the subject should be protected when the specified services are provided. without soliciting any reference to the real user name. This family ensures that a user may use a resource or service without disclosing its user identity but can still be accountable for that use. Pseudonymity ensures that a user may use a resource or service without disclosing its identity but can still be accountable for that use. The user can be accountable by directly being related to a reference (alias) held by the TSF, or by providing an alias that will be used for processing purposes, such as an account number. In several respects, pseudonymity resembles anonymity. Both pseudonymity and anonymity protect the identity of the user, but in pseudonymity a reference to the user's identity is maintained for accountability or other purposes. The component does not specify the requirements on the reference to the user's identity. For the purpose of specifying requirements on this reference two sets of requirements are presented: and . A way to use the reference is by being able to obtain the original user identity. In a digital cash environment, it would be advantageous to be able to trace the user's identity when a check has been issued multiple times (i.e. fraud). In general, the user's identity needs to be retrieved under specific conditions. The author of a PP, PP-Module, functional package or ST can want to incorporate to describe those services. Another usage of the reference is as an alias for a user. A user who does not wish to be identified, can provide an account to which the resource utilization should be charged. In such cases, the reference to the user identity is an alias for the user, where other users or subjects can use the alias for performing their functions without ever obtaining the user's identity (for example, statistical operations on use of the system). In this case, the author of a PP, PP-Module, functional package or ST can wish to incorporate to specify the rules to which the reference must conform. Using these constructs above, digital money can be created using specifying that the user identity will be protected and, if specified in the condition, that there be a requirement to trace the user identity if the digital money is spent twice. When the user is honest, the user identity is protected; if the user tries to cheat, the user identity can be traced. A different kind of system can be a digital credit card, where the user will provide a pseudonym that indicates an account from which the cash can be subtracted. In such cases, for example, can be used. This component would specify that the user identity will be protected and, furthermore, that the same user will only get assigned values for which he/she has provided money (if so specified in the conditions). It should be realized that the more stringent components potentially cannot be combined with other requirements, such as identification and authentication or audit. The interpretation of "determine the identity" should be taken in the broadest sense of the word. The information is not provided by the TSF during the operation, nor can the entity determine the subject or the owner of the subject that invoked the operation, nor will the TSF record information, available to the users or subjects, which can release the user identity in the future. The intent is that the TSF not reveal any information that would compromise the identity of the user. The identity of subjects acting on the user's behalf. The information that is considered to be sensitive depends on the effort an attacker is capable of spending. Possible applications include the ability to charge a caller for premium rate telephone services without disclosing their identity, or to be charged for the anonymous use of an electronic payment system. Potential hostile users include providers, system operators, communication partners and users, who smuggle malicious parts (including malware) into systems. All of these attackers can investigate which users used which services and misuse this information. Additionally, to anonymity services, pseudonymity services contains methods for authorization without identification, especially for anonymous payment ("Digital Cash"). This helps providers to obtain their payment in a secure way while maintaining customer anonymity. This component provides the user protection against disclosure of identity to other users. The user will remain accountable for its actions. requires that a set of users and/or subjects are unable to determine the identity of a user bound to a subject or operation, but that this user is still accountable for its actions. The subject/user that requested resolution of the user identity should be audited The TSF shall ensure that set of users and/or subjects the author of a PP, PP-Module, functional package or ST should specify the set of users and/or subjects against which the TSF provides protection. are unable to determine the real user name bound to list of subjects and/or operations and/or objects . The TSF shall be able to provide number of aliases the author of a PP, PP-Module, functional package or ST should identify the (one or more) number of aliases the TSF is able to provide. aliases of the real user name to list of subjects the author of a PP, PP-Module, functional package or ST should identify the list of subjects to whom the TSF is able to provide an alias. . The TSF shall determine an alias for a user accept the alias from the user the author of a PP, PP-Module, functional package or ST should specify whether the user alias is generated by the TSF or supplied by the user. Only one of these options may be chosen. and verify that it conforms to the alias metric the author of a PP, PP-Module, functional package or ST should identify the metric to which the TSF-generated or user-generated alias should conform. . In this component, the TSF shall ensure that under specified conditions the user identity related to a provided reference can be determined. In the TSF shall provide an alias instead of the user identity. When the specified conditions are satisfied, the user identity to which the alias belong can be determined. Such a condition in an electronic cash environment is, "The TSF shall provide the notary a capability to determine the user identity based on the provided alias only under the conditions that a check has been issued twice". requires the TSF to provide a capability to determine the original user identity based on a provided alias. The TSF shall ensure that set of users and/or subjects the author of a PP, PP-Module, functional package or ST should specify the set of users and/or subjects against which the TSF provides protection. are unable to determine the real user name bound to list of subjects and/or operations and/or objects . The TSF shall be able to provide number of aliases the author of a PP, PP-Module, functional package or ST should identify the (one or more) number of aliases the TSF, is able to provide. aliases of the real user name to list of subjects the author of a PP, PP-Module, functional package or ST should identify the list of subjects to whom the TSF is able to provide an alias. . The TSF shall determine an alias for a user accept the alias from the user the author of a PP, PP-Module, functional package or ST should specify whether the user alias is generated by the TSF or supplied by the user. Only one of these options may be chosen. and verify that it conforms to the alias metric the author of a PP, PP-Module, functional package or ST should identify the metric to which the TSF-generated or user-generated alias should conform. . The TSF shall provide an authorized user list of trusted subjects the author of a PP, PP-Module, functional package or ST should select whether the authorized user and/or trusted subjects can determine the real user name. the author of a PP, PP-Module, functional package or ST should identify the list of conditions under which the trusted subjects and authorized user can determine the real user name based on the provided reference. These conditions can be conditions such as time of day, or they can be administrative such as on a court order. a capability to determine the user identity based on the provided alias only under the following list of conditions the author of a PP, PP-Module, functional package or ST should identify the list of trusted subjects that can obtain the real user name under a specified condition. . In this component, the TSF ensures that the provided reference meets certain construction rules, and thereby can be used in a secure way by potentially insecure subjects. If a user wants to use disk resources without disclosing its identity, pseudonymity can be used. However, every time the user accesses the system, the same alias shall be used. Such conditions may be specified in this component. requires the TSF to follow certain construction rules for the alias to the user identity. The TSF shall ensure that set of users and/or subjects the author of a PP, PP-Module, functional package or ST should specify the set of users and/or subjects against which the TSF provides protection. are unable to determine the real user name bound to list of subjects and/or operations and/or objects . The TSF shall be able to provide number of aliases the author of a PP, PP-Module, functional package or ST should identify the (one or more) number of aliases the TSF is able to provide. aliases of the real user name to list of subjects the author of a PP, PP-Module, functional package or ST should identify the list of subjects to whom the TSF is able to provide an alias. . The TSF shall determine an alias for a user accept the alias from the user the author of a PP, PP-Module, functional package or ST should specify whether the user alias is generated by the TSF, or supplied by the user. Only one of these options may be chosen. and verify that it conforms to the alias metric the author of a PP, PP-Module, functional package or ST should identify the metric to which the TSF-generated or user-generated alias should conform. . The TSF shall provide an alias to the real user name which shall be identical to an alias provided previously under the following list of conditions the author of a PP, PP-Module, functional package or ST should identify the list of conditions that indicate when the used reference for the real user name shall be identical and when it shall be different, for example, "when the user logs on to the same host" it will use a unique alias. otherwise the alias provided shall be unrelated to previously provided aliases. This family ensures that selected entities can be linked together without external entities being able to back trace these links. Unlinkability ensures that a user may make multiple uses of resources or services without others being able to link these uses together. Unlinkability differs from pseudonymity that, although in pseudonymity the user is also not known, relations between different actions can be provided. The requirements for unlinkability are intended to protect the user identity against the use of profiling of the operations. When a telephone smart card is employed with a unique number, the telephone company can determine the behaviour of the user of this telephone card. When a telephone profile of the users is known, the card can be linked to a specific user. Hiding the relationship between different invocations of a service or access of a resource will prevent this kind of information gathering. As a result, a requirement for unlinkability can imply that the subject and user identity of an operation must be protected. Otherwise, this information can be used to link operations together. Unlinkability requires that different operations cannot be related. This relationship can take several forms. The user associated with the operation, or the terminal which initiated the action, or the time the action was executed. The author of a PP, PP-Module, functional package or ST can specify what kind of relationships are present that must be countered. Possible applications include the ability to make multiple use of a pseudonym without creating a usage pattern that can disclose the user's identity. Potential hostile subjects and users include providers, system operators, communication partners and users, who smuggle malicious parts, (including malware) into systems, they do not operate but want to get information about. All of these attackers can investigate (such as which users used which services) and misuse this information. Unlinkability protects users from linkages, which can be drawn between several actions of a customer. A series of phone calls made by an anonymous customer to different partners, where the combination of the partner's identities can disclose the identity of the customer. This component ensures that users cannot link different operations in the system and thereby obtain information. requires that users and/or subjects are unable to determine whether the same user caused certain specific operations in the system, or whether operations are related in some other manner. This component ensures that users cannot link different operations in the system and thereby obtain information. The management of the unlinkability function The invocation of the unlinkability mechanism The TSF shall ensure that set of entities and/or operations the author of a PP, PP-Module, functional package or ST should specify the set of users and/or subjects against which the TSF provides protection. are unable to determine whether list of entities and/or operations were caused by the same user are related as follows list of relations Even if the author of a PP, PP-Module, functional package or ST specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject but must protect with respect to cooperating users and/or subjects. This SFR does not only stipulate at the individual set of operations performed by one entity. This SFR intends to look at a chain of interlinked operations by multiple entities. This chain can be subsumed as a transaction. . This family ensures that a user can use a resource or service without others, especially third parties, being able to observe that the resource or service is being used. Unobservability ensures that a user may use a resource or service without others, especially third parties, being able to observe that the resource or service is being used. Unobservability approaches the user identity from a different direction than the previous families Anonymity, Pseudonymity and Unlinkability. In this case, the intent is to hide the use of a resource or service, rather than to hide the user's identity. A number of techniques can be applied to implement unobservability. Examples of techniques to provide unobservability are: allocation of information impacting unobservability: Unobservability relevant information (such as information that describes that an operation occurred) can be allocated in several locations within the TOE. The information can be allocated to a single randomly chosen part of the TOE such that an attacker does not know which part of the TOE should be attacked. An alternative system can distribute the information such that no single part of the TOE has sufficient information that, if circumvented, the privacy of the user would be compromised. This technique is explicitly addressed in ; broadcast: When information is broadcast (such as Internet and radio frequencies, including Ethernet, Bluetooth, WiFi and near-field communication bands), users cannot determine who actually received and used that information. This technique is especially useful when information should reach receivers who fear a stigma for being interested in that information (such as sensitive medical information); cryptographic protection and message padding: People observing a message stream can obtain information from the fact that a message is transferred and from attributes on that message. By traffic padding, message padding and encrypting the message stream, the transmission of a message and its attributes can be protected. Sometimes, users should not see the use of a resource, but an authorized user must be allowed to see the use of the resource in order to perform their duties. In such cases, the may be used, which provides the capability for one or more authorized users to see the usage. This family makes use of the concept "parts of the TOE". This is considered any part of the TOE that is either physically or logically separated from other parts of the TOE. Unobservability of communications may be an important factor in many areas, such as the enforcement of constitutional rights, organizational policies, or in defense related applications. This component requires that the use of a function or resource cannot be observed by unauthorized users. requires that users and/or subjects cannot determine whether an operation is being performed. The management of the behaviour of the unobservability function The invocation of the unobservability mechanism The TSF shall ensure that list of users and/or subjects the author of a PP, PP-Module, functional package or ST should specify the list of users and/or subjects against which the TSF provides protection. are unable to observe the operation list of operations on list of objects Even if the author of a PP, PP-Module, functional package or ST specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject but must protect with respect to cooperating users and/or subjects. by list of protected users and/or subjects . This component requires that the use of a function or resource cannot be observed by specified users or subjects. Furthermore, this component specifies that information related to the privacy of the user is distributed within the TOE such that attackers can not know which part of the TOE to target, or they need to attack multiple parts of the TOE. An example of the use of this component is the use of a randomly allocated node to provide a function. In such a case the component can require that the privacy related information shall only be available to one identified part of the TOE and will not be communicated outside this part of the TOE. A more complex example can be found in some "voting algorithms". Several parts of the TOE will be involved in the service, but no individual part of the TOE will be able to violate the policy. So, a person may cast a vote (or not) without the TOE being able to determine whether a vote has been cast and what the vote happened to be (unless the vote was unanimous). requires that the TSF provide specific mechanisms to avoid the concentration of privacy related information within the TOE. Such concentrations can impact unobservability if a security compromise occurs. The TSF shall ensure that list of users and/or subjects the author of a PP, PP-Module, functional package or ST should specify the list of users and/or subjects against which the TSF provides protection. For example, even if the author of a PP, PP-Module, functional package or ST specifies a single user or subject role, the TSF must not only provide protection against each individual user or subject but must protect with respect to cooperating users and/or subjects. are unable to observe the operation list of operations on list of objects A set of users can be a group of users which can operate under the same role or can all use the same process(es). by list of protected users and/or subjects the author of a PP, PP-Module, functional package or ST should identify the list of operations that are subjected to the unobservability requirement. Other users/subjects will then not be able to observe the operations on a covered object in the specified list . The TSF shall allocate the unobservability related information the author of a PP, PP-Module, functional package or ST should identify which privacy related information should be distributed in a controlled manner. among different parts of the TOE such that the following conditions hold during the lifetime of the information: list of conditions this information can include: IP address of subject, IP address of object, time, used encryption keys. . This component is used to require that the TSF does not try to obtain information that can compromise unobservability when provided specific services. Therefore, the TSF will not solicit (i.e. try to obtain from other entities) any information that can be used to compromise unobservability. requires that the TSF does not try to obtain privacy related information that can be used to compromise unobservability. The TSF shall provide list of services the author of a PP, PP-Module, functional package or ST should identify the list of services which are subject to the unobservability requirement. "The accessing of job descriptions". to list of subjects without soliciting any reference to privacy related information the author of a PP, PP-Module, functional package or ST should identify the list of subjects from which privacy related information should be protected when the specified services are provided. . This component is used to require that there will be one or more authorized users with the rights to view the resource utilization. Without this component, this review is allowed, but not mandated. requires the TSF to provide one or more authorized users with a capability to observe the usage of resources and/or services. The list of authorized users that are capable of determining the occurrence of operations The observation of the use of a resource or service by a user or subject The TSF shall provide set of authorized users the author of a PP, PP-Module, functional package or ST should specify the set of authorized users for which the TSF provides the capability to observe the resource utilization. A set of authorized users, for example, can be a group of authorized users which can operate under the same role or can all use the same process(es). with the capability to observe the usage of list of resources and/or services the author of a PP, PP-Module, functional package or ST should specify the set of resources and/or services that the authorized user must be able to observe. . This class contains families of functional requirements that relate to the integrity and management of the mechanisms that constitute the TSF and to the integrity of TSF data. Although families in this class appear to duplicate components in the class, and they can be implemented using the same mechanisms. However, focuses on user data protection, while focuses on TSF data protection. In fact, Components from the class are necessary to provide requirements that the SFPs in the TOE cannot be tampered with or bypassed. From the point of view of this class, regarding to the TSF there are three significant elements: the TSF's implementation, which executes and implements the mechanisms that enforce the SFRs; the TSF's data, which are the administrative databases that guide the enforcement of the SFRs; the external entities that the TSF may interact with in order to enforce the SFRs. This class contains families of functional requirements that relate to the integrity and management of the mechanisms that constitute the TSF and to the integrity of TSF data. In some sense, families in this class may appear to duplicate components in the class; they may even be implemented using the same mechanisms. However, focuses on user data protection, while focuses on TSF data protection. In fact, components from the class are necessary to provide requirements that the SFPs in the TOE cannot be tampered with or bypassed. From the point of view of this class, regarding to the TSF there are three significant elements: the TSF's implementation, which executes and implements the mechanisms that enforce the SFRs; the TSF's data, which are the administrative databases that guide the enforcement of the SFRs; the external entities that the TSF may interact with in order to enforce the SFRs. All of the families in the class can be related to these areas, and fall into the following groupings: , which addresses potential leakage of information from the TOE via emanations; , , and , which address the behaviour of the TSF when failure occurs and immediately after; , which addresses the initialization of the TOE into a correct and secure operational state; , which addresses protection of TSF data when it is transmitted between physically-separated parts of the TOE; , which provides an authorized user with the ability to detect external attacks on the parts of the TOE that comprise the TSF; , , , which address the protection and availability of TSF data between the TSF and another trusted IT product; , which addresses the replay of various types of information and/or operations; , which addresses the synchronization of states, based upon TSF data, between different parts of a distributed TSF; , which addresses reliable timing; , which addresses the consistency of TSF data shared between the TSF and another trusted IT product; and , which provide an authorized user with the ability to verify the correct operation of the external entities interacting with the TSF to enforce the SFRs, and the integrity of the TSF data and TSF itself. The family of the class describes the IT SFRs of the TOE related to leakage of information based on emanation. If the TOE must prevent attacks against the TOE and secret data processed by the TOE where the attack is based on external observable phenomena of the TOE during its operation, different types of emissions and interfaces of the TOE as well as different types of TSF data and user data can be addressed. Examples of such attacks against the TOE and its processed secret data are simple power analysis (SPA), differential power analysis (DPA), simple electromagnetic analysis (SEMA), differential electromagnetic analysis (DEMA), timing attacks, padding oracle attacks, cache miss attacks. This family describes the functional requirements for the limitation of intelligible emanations which are not directly addressed by any other component of this document. This family defines the requirements for the TOE to be able to prevent or mitigate attacks against data stored in and used by the TOE where the attack is based on external observable physical phenomena of the TOE. Examples of such attacks are analysis of TOE's electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA), timing attacks. requires the TOE to not emit intelligible emissions enabling access to TSF data or user data. Specifying this component requires a relational representation of any combination of TSF data and/or user data in relation to any emission combined with the attack surface. Data, emissions and attack surfaces may be typified. The Table found as part of the Limit of Emissions element shall be completed by the author of a PP, PP-Module, functional package or ST. Each row, which can be identified using the "Identifier", provides a set of assignments for completing the SFR, allowing the author of a PP, PP-Module, functional package or ST to specify the requirements for TOE emanation protection for various different combinations of emissions, interfaces, TSF data and user data. It is not expected that an author enters all types of emissions and types of attack surfaces (etc.) in one row. Types of emission can include audio frequencies and radio frequencies. Types of interfaces can include physical ports, I.C. boundaries, and electronic components. This family consists of one component, , which defines requirements for the TOE to mitigate intelligible emanations. The TSF shall ensure that the TOE does not emit emissions over its attack surface in such amount that these emissions enable access to TSF data and user data as specified in the following table: ID Emissions Attack surface TSF data User data 1 list of types of emissions list of types of attack surface list of types of TSF data list of types of user data … … … … … The requirements of this family ensure that the TOE will always enforce its SFRs in the event of identified categories of failures in the TSF. The requirements of this family ensure that the TOE will always enforce its SFRs in the event of certain types of failures in the TSF. The term "secure state" refers to a state in which the TSF data are consistent and the TSF continues correct enforcement of the SFRs. Although it is desirable to audit situations in which failure with preservation of secure state occurs, it is not possible in all situations. The author of a PP, PP-Module, functional package or ST should specify those situations in which audit is desired and feasible. Failures in the TSF may include "hard" failures, which indicate an equipment malfunction and which may require maintenance, service, or repair of the TSF. Failures in the TSF may also include recoverable "soft" failures, which may only require initialization or resetting of the TSF. This family consists of only one component, , which requires that the TSF preserve a secure state in the face of the identified failures. Failure of the TSF The TSF shall preserve a secure state when the following types of failures occur: list of types of failures in the TSF the author of a PP, PP-Module, functional package or ST should list the types of failures in the TSF for which the TSF should "fail secure," that is, should preserve a secure state and continue to correctly enforce the SFRs. . This family describes the functional requirements for the initialization of the TSF by a dedicated function of the TOE that ensures the initialization in a correct and secure operational state. This family defines the functional requirements for the initialization of the TSF. A dedicated function of the TOE ensures that the initialization of the TSF results in a correct and secure operational state. This can cover code/data that are stored and executed from non-modifiable memory at boot time, the immutable root-of-trust, and other one-time programmable (OTP) values such as versions and identifiers. This component covers for instance code/data stored and executed from non-modifiable memory at boot time, the immutable root-of-trust, and other OTP values such as versions and identifiers. This family consists of only one component, . This component requires the TOE to provide a TSF initialization function that brings the TSF into a secure operational state at power-on. The TOE shall provide an initialization function which is self-protected for integrity and authenticity. The TOE initialization function shall ensure that certain properties hold on certain elements immediately before establishing the TSF in a secure initial state, as specified in the following table: ID Properties Elements 1 property for instance authenticity, integrity, correct version. list of TSF/user firmware, software or data … … … The TOE initialization function shall detect and respond to errors and failures during initialization such that the TOE is halted successfully completes initialization with reduced functionality signaling error state list of actions the author of a PP, PP-Module, functional package or ST uses the assignment to describe the methods by which the TOE initialization function interacts with the TSF. the author of a PP, PP-Module, functional package or ST uses the selections and assignments to describe the behaviour of the TOE initialization function in the case that errors or other failures are encountered during the initialization. . The TOE initialization function shall only interact with the TSF in defined methods during initialization. This family defines the rules for the prevention of loss of availability of TSF data moving between the TSF and another trusted IT product. This family defines the rules for the prevention of loss of availability of TSF data moving between the TSF and another trusted IT product. This data can be TSF critical data such as passwords, keys, audit data, or TSF executable code. This family is used in a distributed context where the TSF is providing TSF data to another trusted IT product. The TSF can only take the measures at its site and cannot be held responsible for the TSF at the other trusted IT product. If there are different availability metrics for different types of TSF data, then this component should be iterated for each unique pairing of metrics and types of TSF data. No component rationale or application notes have been provided, This family consists of only one component, . This component requires that the TSF ensure, to an identified degree of probability, the availability of TSF data provided to another trusted IT product. Management of the list of types of TSF data that be available to another trusted it product The absence of TSF data when required by a toe The TSF shall ensure the availability of list of types of TSF data the author of a PP, PP-Module, functional package or ST should specify the types of TSF data that are subject to the availability metric. provided to another trusted IT product within a defined availability metric the PP, PP-Module, functional package or ST should specify the availability metric for the applicable TSF data. given the following conditions conditions to ensure availability the author of a PP, PP-Module, functional package or ST should specify the conditions under which availability must be ensured. . This family defines the rules for the protection from unauthorized disclosure of TSF data during transmission between the TSF and another trusted IT product. This family defines the rules for the protection from unauthorized disclosure of TSF data moving between the TSF and another trusted IT product. Examples of this data are TSF critical data such as passwords, keys, audit data, or TSF executable code. This family is used in a distributed context where the TSF is providing TSF data to another trusted IT product. The TSF can only take the measures at its site and cannot be held responsible for the behaviour of the other trusted IT product. Confidentiality of TSF Data during transmission is necessary to protect such information from disclosure. Some possible implementations that can provide confidentiality include the use of cryptographic algorithms as well as spread spectrum techniques. This component is used when it is necessary to make the requirement for confidentiality of TSF data when being transmitted from the TSF to another trusted IT product. This family consists of only one component, , which requires that the TSF ensure that data transmitted between the TSF and another trusted IT product is protected from disclosure while in transit. The TSF shall protect all TSF data transmitted from the TSF to another trusted IT product from unauthorized disclosure during transmission. This family defines the rules for the protection, from unauthorized modification, of TSF data during transmission between the TSF and another trusted IT product. This family defines the rules for the protection, from unauthorized modification, of TSF data during transmission between the TSF and another trusted IT product. Examples of this data are TSF critical data such as passwords, keys, audit data, or TSF executable code. This family is used in a distributed context where the TSF is exchanging TSF data with another trusted IT product. Note that a requirement that addresses modification, detection, or recovery at another trusted IT product cannot be specified, as the mechanisms that another trusted IT product will use to protect its data cannot be determined in advance. For this reason, these requirements are expressed in terms of the "TSF providing a capability" which another trusted IT product can use. In the component some possible means of satisfying this requirement involves the use of cryptographic functions or some form of checksum. This component should be used in situations where it is sufficient to detect when data have been modified. An example of such a situation is one in which another trusted IT product can request the TOE's TSF to retransmit data when modification has been detected or respond to such types of request. The desired strength of modification detection is based upon a specified modification metric that is a function of the algorithm used, which may range from a weak checksum and parity mechanisms that may fail to detect multiple bit changes, to more complicated cryptographic checksum approaches. , provides the ability to detect modification of TSF data during transmission between the TSF and another trusted IT product, under the assumption that another trusted IT product is cognizant of the mechanism used. The detection of modification of transmitted TSF data The action taken upon detection of modification of transmitted TSF data The TSF shall provide the capability to detect modification of all TSF data during transmission between the TSF and another trusted IT product within the following metric: a defined modification metric the PP, PP-Module, functional package or ST should specify the modification metric that the detection mechanism satisfies. This modification metric shall specify the desired strength of the modification detection. . The TSF shall provide the capability to verify the integrity of all TSF data transmitted between the TSF and another trusted IT product and perform action to be taken the PP, PP-Module, functional package or ST should specify the actions to be taken if a modification of TSF data has been detected. An example of an action is: "ignore the TSF data and request the originating trusted product to send the TSF data again". if modifications are detected. This component should be used in situations where it is necessary to detect or correct modifications of TSF critical data. The desired strength of modification detection is based upon a specified modification metric that is a function of the algorithm used, which may range from a checksum and parity mechanisms that may fail to detect multiple bit changes, to more complicated cryptographic checksum approaches. The metric that needs to be defined can either refer to the attacks it will resist or to mechanisms that are well known in the public literature. Attack reference: "only 1 in 1000 random messages will be accepted". Well known mechanism: "the strength must be conformant to the strength offered by Secure Hash Algorithm". The approach taken to correct modification can be done through some form of error correcting checksum. provides the ability for another trusted IT product not only to detect modification, but to correct modified TSF data under the assumption that another trusted IT product is cognizant of the mechanism used. Management of the types of TSF data that the TSF tries to correct if modified in transit Management of the types of action that the TSF takes if TSF data is modified in transit The detection of modification of transmitted TSF data The action taken upon detection of modification of transmitted TSF data The use of the correction mechanism The TSF shall provide the capability to detect modification of all TSF data during transmission between the TSF and another trusted IT product within the following metric: a defined modification metric the PP, PP-Module, functional package or ST should specify the modification metric that the detection mechanism satisfies. This modification metric shall specify the desired strength of the modification detection. . The TSF shall provide the capability to verify the integrity of all TSF data transmitted between the TSF and another trusted IT product and perform action to be taken the PP, PP-Module, functional package or ST should specify the actions to be taken if a modification of TSF data has been detected. if modifications are detected. The TSF shall provide the capability to correct type of modification the author of a PP, PP-Module, functional package or ST should define the types of modification from which the TSF should be capable of recovering. of all TSF data transmitted between the TSF and another trusted IT product. This family provides requirements that address protection of TSF data when it is transferred between separate parts of a TOE across an internal channel. This family provides requirements that address protection of TSF data when it is transferred between separate parts of a TOE across an internal channel. The determination of the degree of separation (i.e., physical, or logical) that would make application of this family useful depends on the intended environment of use. In a hostile environment, there may be risks arising from transfers between parts of the TOE separated by only a system bus or an inter-process communications channel. In more benign environments, the transfers may be across more traditional network media. One practical mechanism available to a TSF to provide this protection is a cryptographically-based mechanism. No component rationale or application notes have been provided. requires that TSF data be protected when transmitted between separate parts of the TOE. Management of the types of modification against which the TSF should protect Management of the mechanism used to provide the protection of the data in transit between different parts of the TSF The TSF shall protect TSF data from disclosure modification the author of a PP, PP-Module, functional package or ST should specify the desired type of protection to be provided from the choices: disclosure, modification. when it is transmitted between separate parts of the TOE. One of the ways to achieve separation of TSF data based on SFP-relevant attributes is through the use of separate logical or physical channels. requires that the TSF separate user data from TSF data during transmission. Management of the types of modification against which the TSF should protect Management of the mechanism used to provide the protection of the data in transit between different parts of the TSF Management of the separation mechanism The TSF shall protect TSF data from disclosure modification the author of a PP, PP-Module, functional package or ST should specify the desired type of protection to be provided from the choices: disclosure, modification. when it is transmitted between separate parts of the TOE. The TSF shall separate user data from TSF data when such data is transmitted between separate parts of the TOE. No component rationale or application notes have been provided. requires that the TSF data transmitted between separate parts of the TOE is monitored for identified integrity errors. Management of the types of modification against which the TSF should protect Management of the mechanism used to provide the protection of the data in transit between different parts of the TSF Management of the types of modification of TSF data the TSF should try to detect Management of the actions that will be taken The detection of modification of TSF data The action taken following detection of an integrity error The TSF shall be able to detect modification of data substitution of data re-ordering of data deletion of data other integrity errors the author of a PP, PP-Module, functional package or ST should specify the desired type of modification that the TSF shall be able to detect. The author of a PP, PP-Module, functional package or ST should select from: modification of data, substitution of data, re-ordering of data, deletion of data, or any other integrity errors. if the author of a PP, PP-Module, functional package or ST chooses the latter selection noted in the preceding paragraph, then the author should also specify what those other integrity errors are that the TSF should be capable of detecting. for TSF data transmitted between separate parts of the TOE. Upon detection of a data integrity error, the TSF shall take the following actions: specify the action to be taken the author of a PP, PP-Module, functional package or ST should specify the action to be taken when an integrity error is identified. . TSF physical protection components refer to restrictions on unauthorized physical access to the TSF, and to the deterrence of, and resistance to, unauthorized physical modification, or substitution of the TSF. The requirements of components in this family ensure that the TSF is protected from physical tampering and interference. Satisfying the requirements of these components results in the TSF being packaged and used in such a manner that physical tampering is detectable, or resistance to physical tampering is enforced. Without these components, the protection functions of a TSF lose their effectiveness in environments where physical damage cannot be prevented. This family also provides requirements regarding how the TSF shall respond to physical tampering attempts. TSF physical protection components refer to restrictions on unauthorized physical access to the TSF, and to the deterrence of, and resistance to, unauthorized physical modification, or substitution of the TSF. The requirements in this family ensure that the TSF is protected from physical tampering and interference. Satisfying the requirements of these components results in the TSF being packaged and used in such a manner that physical tampering is detectable, or resistance to physical tampering is measurable based on defined work factors. Without these components, the protection functions of a TSF lose their effectiveness in environments where physical damage cannot be prevented. This component also provides requirements regarding how the TSF respond to physical tampering attempts. Examples of physical tampering scenarios include mechanical attack, radiation, changing the temperature. It is acceptable for the functions that are available to an authorized user for detecting physical tampering to be available only in an off-line or maintenance mode. Controls should be in place to limit access during such modes to authorized users. As the TSF may not be "operational" during those modes, it may not be able to provide normal enforcement for authorized user access. The physical implementation of a TOE can consist of several structures. This set of "elements" as a whole protect (protect, notify and resist) the TSF from physical tampering. This does not mean that all devices provide these features, but the complete physical construct as a whole should. Examples of structures include an outer shielding, cards, and chips. Although there is only minimal auditing associating with these components, this is solely because there is the potential that the detection and alarm mechanisms may be implemented completely in hardware, below the level of interaction with an audit subsystem. Nevertheless, a PP, PP-Module, functional package or ST author may determine that for a particular anticipated threat environment, there is a need to audit physical tampering. If this is the case, the author of a PP, PP-Module, functional package or ST should include appropriate requirements in the list of audit events. Inclusion of these requirements can have implications on the hardware design and its interface to the software. Examples of a hardware-based detection system is one based on breaking a circuit and lighting a light emitting diode (LED) if the circuit is broken when a button is pressed by the authorized user. should be used when threats from unauthorized physical tampering with parts of the TOE are not countered by procedural methods. It addresses the threat of undetected physical tampering with the TSF. Typically, an authorized user would be given the function to verify whether tampering took place. As written, this component simply provides a TSF capability to detect tampering. Specification of management functions in should be considered to specify who can make use of that capability, and how they can make use of that capability. If this is done by non-IT mechanisms such as physical inspection. management functions are not required. , provides for features that indicate when a TSF device or TSF element is subject to tampering. However, notification of tampering is not automatic; an authorized user invokes a security administrative function or perform manual inspection to determine if tampering has occurred. Management of the user or role that determines whether physical tampering has occurred If detection by it means, detection of intrusion The TSF shall provide unambiguous detection of physical tampering that can compromise the TSF. The TSF shall provide the capability to determine whether physical tampering with the TSF's devices or TSF's elements has occurred. should be used when threats from unauthorized physical tampering with parts of the TOE are not countered by procedural methods, and it is required that designated individuals be notified of physical tampering. It addresses the threat that physical tampering with TSF elements, although detected, may not be noticed. Specification of management functions in should be considered to specify who can make use of that capability, and how they can make use of that capability. , provides for automatic notification of tampering for an identified subset of physical penetrations. Management of the user or role that gets informed about intrusions Management of the list of devices that should inform the indicated user or role about the intrusion Detection of intrusion The TSF shall provide unambiguous detection of physical tampering that can compromise the TSF. The TSF shall provide the capability to determine whether physical tampering with the TSF's devices or TSF's elements has occurred. For list of TSF devices/elements for which active detection is required the author of a PP, PP-Module, functional package or ST should provide a list of TSF devices/elements for which active detection of physical tampering is required. , the TSF shall monitor the devices and elements and notify a designated user or role the author of a PP, PP-Module, functional package or ST should designate a user or role that is to be notified when tampering is detected. The type of user or role may vary depending on the particular security administration component (from ) included in the PP, PP-Module, functional package or ST. when physical tampering with the TSF's devices or TSF's elements has occurred. For some forms of tampering, it is necessary that the TSF not only detects the tampering, but actually resists it or delays the attacker. This component should be used when TSF devices and TSF elements are expected to operate in an environment where a physical tampering of the internals of a TSF device or TSF element itself is a threat. Physical tampering includes observation, analysis, or modification. , provides for features that prevent or resist physical tampering with TSF devices and TSF elements. Management of the automatic responses to physical tampering The TSF shall resist physical tampering scenarios the author of a PP, PP-Module, functional package or ST should specify tampering scenarios to a list of TSF devices/elements for which the TSF should resist physical tampering. This list may be applied to a defined subset of the TSF physical devices and elements based on considerations such as technology limitations and relative physical exposure of the device. Such sub setting should be clearly defined and justified. Furthermore, the TSF should automatically respond to physical tampering. The automatic response should be such that the policy of the device is preserved. to the list of TSF devices/elements by responding automatically such that the SFRs are always enforced. The requirements of this family ensure that the TSF can determine that the TOE is started up without protection compromise and can recover without protection compromise after discontinuity of operations. This family is important because the start-up state of the TSF determines the protection of subsequent states. The requirements of this family ensure that the TSF can determine that the TOE is started-up without protection compromise and can recover without protection compromise after discontinuity of operations. This family is important because the start-up state of the TSF determines the protection of subsequent states. Recovery components reconstruct the TSF secure states, or prevent transitions to insecure states, as a direct response to occurrences of expected failures, discontinuity of operation or start-up. Failures that must be generally anticipated include the following: unmaskable action failures that always result in a system crash (such as persistent inconsistency of critical system tables, uncontrolled transfers within the TSF code caused by transient failures of hardware or firmware, power failures, processor failures, communication failures); media failures causing part or all of the media representing the TSF objects to become inaccessible or corrupt (such as parity errors, disk head crash, persistent read/write failure caused by misaligned disk heads, worn-out magnetic coating, dust on the disk surface, loss of Internet connection); dscontinuity of operation caused by erroneous administrative action or lack of timely administrative action (such as unexpected shutdowns by turning off power, ignoring the exhaustion of critical resources, inadequate installed configuration). Recovery can be from either a complete or partial failure scenario. Although a complete failure can occur in a monolithic operating system, it is less likely to occur in a distributed environment. In such environments, subsystems may fail, but other portions remain operational. Further, critical components may be redundant (disk mirroring, alternative routes), and checkpoints may be available. Thus, recovery is expressed in terms of recovery to a secure state. There are different interactions between and components to be considered when selecting : the need for trusted recovery may be indicated through the results of TSF self-testing, where the results of the self-tests indicate that the TSF is in an insecure state and return to a secure state or entrance in maintenance mode is required; a failure, as discussed above, may be identified by an administrator. Either the administrator may perform the actions to return the TOE to a secure state and then invoke TSF self-tests to confirm that the secure state has been achieved. Or, the TSF self-tests may be invoked to complete the recovery process; a combination of a. and b. above, where the need for trusted recovery is indicated through the results of TSF self-testing, the administrator performs the actions to return the TOE to a secure state and then invokes TSF self-tests to confirm that the secure state has been achieved; self-tests detect a failure/service discontinuity, then either automated recovery or entrance to a maintenance mode. This family identifies a maintenance mode. In this maintenance mode, normal operation can be impossible or severely restricted, as otherwise insecure situations can occur. Typically, only authorized users should be allowed access to this mode but the real details of who can access this mode is a function of . If does not put any controls on who can access this mode, then it may be acceptable to allow any user to restore the system if the TOE enters such a state. However, in practice, this is probably not desirable as the user restoring the system has an opportunity to configure the TOE in such a way as to violate the SFRs. Mechanisms designed to detect exceptional conditions during operation fall under , , and other areas that address the concept of "Software Safety". It is likely that the use of one of these families will be required to support the adoption of . This is to ensure that the TOE will be able to detect when recovery is required. Throughout this family, the phrase "secure state" is used. This refers to some state in which the TOE has consistent TSF data and a TSF that can correctly enforce the policy. This state may be the initial "boot" of a clean system, or it can be some checkpointed state. Following recovery, it may be necessary to confirm that the secure state has been achieved through self-testing of the TSF. However, if the recovery is performed in a manner such that only a secure state can be achieved, else recovery fails, then the dependency to the component may be argued away. In , it is acceptable for the functions that are available to an authorized user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorized users. In It is acceptable for the functions that are available to an authorized user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorized users. For , it is the responsibility of the developer of the TSF to determine the set of recoverable failures and service discontinuities. It is assumed that the robustness of the automated recovery mechanisms will be verified. In It is acceptable for the functions that are available to an authorized user for trusted recovery to be available only in a maintenance mode. Controls should be in place to limit access during maintenance to authorized users. It is assumed that the evaluators will verify the robustness of the automated recovery mechanisms. In the hierarchy of the trusted recovery family, recovery that requires only manual intervention is the least desirable, for it precludes the use of the system in an unattended fashion. This component is intended for use in TOEs that do not require unattended recovery to a secure state. The requirements of this component reduce the threat of protection compromise resulting from an attended TOE returning to an insecure state after recovery from a failure or other discontinuity. , allows a TOE to only provide mechanisms that involve human intervention to return to a secure state. Management of who can access the restore capability within the maintenance mode The fact that a failure or service discontinuity occurred Resumption of the regular operation Type of failure or service discontinuity After list of failures/service discontinuities the author of a PP, PP-Module, functional package or ST should specify the list of failures or service discontinuities following which the TOE will enter a maintenance mode. the TSF shall enter a maintenance mode where the ability to return to a secure state is provided. Automated recovery is considered to be more useful than manual recovery, as it allows the machine to operate in an unattended fashion. The component extends the feature coverage of by requiring that there be at least one automated method of recovery from failure or service discontinuity. It addresses the threat of protection compromise resulting from an unattended TOE returning to an insecure state after recovery from a failure or other discontinuity. , provides, for at least one type of service discontinuity, recovery to a secure state without human intervention; recovery for other discontinuities that can require human intervention. Management of who can access the restore capability within the maintenance mode Management of the list of failures/service discontinuities that will be handled through the automatic procedures When automated recovery from list of failures/service discontinuities the author of a PP, PP-Module, functional package or ST should specify the list of failures or service discontinuities following which the TOE will need to enter a maintenance mode. is not possible, the TSF shall enter a maintenance mode where the ability to return to a secure state is provided. For list of failures/service discontinuities the author of a PP, PP-Module, functional package or ST should specify the list of failures or other discontinuities for which automated recovery shall be possible. , the TSF shall ensure the return of the TOE to a secure state using automated procedures. Automated recovery is considered to be more useful than manual recovery, but it runs the risk of losing a substantial number of objects. Preventing undue loss of objects provides additional utility to the recovery effort. The component extends the feature coverage of by requiring that there not be undue loss of TSF data or objects under the control of the TSF. At , the automated recovery mechanisms can conceivably recover by deleting all objects and returning the TSF to a known secure state. This type of drastic automated recovery is precluded in . This component addresses the threat of protection compromise resulting from an unattended TOE returning to an insecure state after recovery from a failure or other discontinuity with a large loss of TSF data or objects under the control of the TSF. , also provides for automated recovery, but strengthens the requirements by disallowing undue loss of protected objects. When automated recovery from list of failures/service discontinuities the author of a PP, PP-Module, functional package or ST should specify the list of failures or service discontinuities following which the TOE will need to enter a maintenance mode. is not possible, the TSF shall enter a maintenance mode where the ability to return to a secure state is provided. For list of failures/service discontinuities the author of a PP, PP-Module, functional package or ST should specify the list of failures or other discontinuities for which automated recovery is possible. , the TSF shall ensure the return of the TOE to a secure state using automated procedures. The functions provided by the TSF to recover from failure or service discontinuity shall ensure that the secure initial state is restored without exceeding quantification the author of a PP, PP-Module, functional package or ST should provide a quantification for the amount of loss of TSF data or objects that is acceptable. for loss of TSF data or objects under the control of the TSF. The TSF shall provide the capability to determine the objects that were or were not capable of being recovered. Function recovery requires that if there should be some failure in the TSF, that certain functions in the TSF should either complete successfully or recover to a secure state. , provides for recovery at the level of particular functions, ensuring either successful completion or rollback of TSF data to a secure state. If possible, the impossibility to return to a secure state after a failure of the TSF If possible, the detection of a failure of a function The TSF shall ensure that list of functions and failure scenarios the author of a PP, PP-Module, functional package or ST should specify a list of the functions and failure scenarios. In the event that any of the identified failure scenarios happen, the functions that have been specified shall either complete successfully or recover to a consistent and secure state. have the property that the function either completes successfully, or for the indicated failure scenarios, recovers to a consistent and secure state. This family addresses detection of replay for various types of entities and subsequent actions to correct. In the case where replay may be detected, this effectively prevents it. This family addresses detection of replay for various types of entities and subsequent actions to correct. The entities included here are those that can be involved in replay detection. Messages, service requests, service responses, or sessions. The family consists of only one component, , which requires that the TSF shall be able to detect the replay of identified entities. Management of the list of identified entities for which replay is detected Management of the list of actions that need to be taken in case of replay Detected replay attacks Action to be taken based on the specific actions The TSF shall detect replay for the following entities: list of identified entities the author of a PP, PP-Module, functional package or ST should provide a list of identified entities for which detection of replay should be possible. . The TSF shall perform list of specific actions the author of a PP, PP-Module, functional package or ST should specify the list of actions to be taken by the TSF when replay is detected. The potential set of actions that can be taken includes: ignoring the replayed entity, requesting confirmation of the entity from the identified source, and terminating the subject from which the re-played entity originated. when replay is detected. Distributed TOEs can give rise to greater complexity than monolithic TOEs through the potential for differences in state between parts of the TOE, and through delays in communication. In most cases synchronization of state between distributed functions involves an exchange protocol, not a simple action. When malice exists in the distributed environment of these protocols, more complex defensive protocols are required. establishes the requirement for certain critical functions of the TSF to use this trusted protocol. ensures that two distributed parts of the TOE have synchronized their states after a security-relevant action. Distributed TOEs may give rise to greater complexity than monolithic TOEs through the potential for differences in state between parts of the TOE, and through delays in communication. In most cases, synchronization of state between distributed functions involves an exchange protocol, not a simple action. When malice exists in the distributed environment of these protocols, more complex defensive protocols are required. establishes the requirement for certain critical functions of the TSF to use a trusted protocol. ensures that two distributed parts of the TOE, such as hosts, have synchronized their states after a security-relevant action. It is possible that some states will never be synchronized, or the transaction cost can be too high for practical use. Encryption key revocation is an example, where knowing the state after the revocation action is initiated can never be known. Either the action was taken and acknowledgment cannot be sent, or the message was ignored by hostile communication partners and the revocation never occurred. Indeterminacy is unique to distributed TOEs. Indeterminacy and state synchrony are related, and the same solution may apply. It is futile to design for indeterminate states; the author of a PP, PP-Module, functional package or ST should express other requirements in such cases. Raise an alarm, audit the event. In this component, the TSF supplies an acknowledgement to another part of the TSF when requested. This acknowledgement should indicate that one part of a distributed TOE successfully received an unmodified transmission from a different part of the distributed TOE. requires only a simple acknowledgment by the data recipient. Failure to receive an acknowledgement when expected The TSF shall acknowledge, when requested by another part of the TSF, the receipt of an unmodified TSF data transmission. In this component, in addition to the TSF being able to provide an acknowledgement for the receipt of a data transmission, the TSF complies with a request from another part of the TSF for an acknowledgement to the acknowledgement. The local TSF transmits some data to a remote part of the TSF. The remote part of the TSF acknowledges the successful receipt of the data and requests that the sending TSF confirm that it receives the acknowledgement. This mechanism provides additional confidence that both parts of the TSF involved in the data transmission know that the transmission completed successfully. requires mutual acknowledgment of the data exchange. The TSF shall acknowledge, when requested by another part of the TSF, the receipt of an unmodified TSF data transmission. The TSF shall ensure that the relevant parts of the TSF know the correct status of transmitted data among its different parts, using acknowledgements. This family addresses requirements for a reliable time stamp function within a TOE. This family addresses requirements for a reliable time stamp function within a TOE. It is the responsibility of the author of a PP, PP-Module, functional package or ST to clarify the meaning of the phrase "reliable time stamp", and to indicate where the responsibility lies in determining the acceptance of trust. Some possible uses of this component include providing reliable time stamps for the purposes of audit as well as for security attribute expiration. requires that the TSF provide reliable time stamps for TSF functions. Management of the time Changes to the time Providing a timestamp The TSF shall be able to provide reliable time stamps. , requires the description of the time source used in timestamps. Setting of time by user authorized according to security policy Discontinuous changes to the time Changes to the time source The TSF shall allow the user authorized by security policy to set the time configure another time source . In a distributed environment, a TOE may need to exchange TSF data with another trusted IT product. This family defines the requirements for sharing and consistent interpretation of these attributes between the TSF of the TOE and a different trusted IT product. In a distributed or composite environment, a TOE may need to exchange TSF data with another trusted IT Product. The SFP-attributes associated with data, audit information, identification information. This family defines the requirements for sharing and consistent interpretation of these attributes between the TSF of the TOE and that of a different trusted IT Product. The components in this family are intended to provide requirements for automated support for TSF data consistency when such data is transmitted between the TSF of the TOE and another trusted IT Product. It is also possible that wholly procedural means can be used to produce security attribute consistency, but they are not provided for here. This family is different from and , as those two families are concerned only with resolving the security attributes between the TSF and its import/export medium. If the integrity of the TSF data is of concern, requirements should be chosen from the family. These components specify requirements for the TSF to be able to detect or detect and correct modifications to TSF data in transit. The TSF is responsible for maintaining the consistency of TSF data used by or associated with the specified function and that are common between two or more trusted systems. The TSF data of two different systems can have different conventions internally. For the TSF data to be used properly (such as to afford the user data the same protection as within the TOE) by the receiving trusted IT product, the TOE and the other trusted IT product must use a pre-established protocol to exchange TSF data. requires that the TSF provide the capability to ensure consistency of attributes between TSFs. Successful use of TSF data consistency mechanisms Use of the TSF data consistency mechanisms Identification of which TSF data have been interpreted Detection of modified TSF data The TSF shall provide the capability to consistently interpret list of TSF data types the author of a PP, PP-Module, functional package or ST should define the list of TSF data types, for which the TSF shall provide the capability to consistently interpret, when shared between the TSF and another trusted IT product. when shared between the TSF and another trusted IT product. The TSF shall use list of interpretation rules to be applied by the TSF the PP, PP-Module, functional package or ST should assign the list of interpretation rules to be applied by the TSF. when interpreting the TSF data from another trusted IT product. This family defines requirements for the TSF to perform tests on one or more external entities. This component is not intended to be applied to human users. External entities can include applications running on the TOE, hardware or software running "underneath" the TOE (e.g. platforms, operating systems) or applications/boxes connected to the TOE (e.g. intrusion detection systems, firewalls, login servers, time servers). This family defines requirements for the testing of one or more external entities by the TSF. These external entities are not human users, and they can include combinations of software and/or hardware interacting with the TOE. Examples of the types of tests that may be run are: tests for the presence of a firewall, and possibly whether it is correctly configured; tests of some of the properties of the operating system that an application TOE runs on; tests of some of the properties of the IC that a smart card OS TOE runs on (such as the random number generator). The external entity can "lie" about the test results, either on purpose or because it is not working correctly. These tests can be carried out either in some maintenance state, at start-up, on-line, or continuously. The actions to be taken by the TOE as the result of testing are defined also in this family. The tests of external entities should be sufficient to test all of the characteristics of them upon which the TSF relies. For , it is acceptable for the functions for periodic testing to be available only in an off-line or maintenance mode. Controls should be in place to limit access, during maintenance, to authorized users. This component is not intended to be applied to human users. This component provides support for the periodic testing of properties related to external entities upon which the TSF's operation depends, by requiring the ability to periodically invoke testing functions. The author of a PP, PP-Module, functional package or ST may refine the requirement to state whether the function should be available in off-line, on-line or maintenance mode. , provides for testing of the external entities by the TSF. Management of the conditions under which the testing of external entities occurs, such as during initial start-up, regular interval, or under specified conditions Management of the time interval if appropriate Execution of the tests of the external entities and the results of the tests The TSF shall run a suite of tests during initial start-up periodically during normal operation at the request of an authorized user other conditions the author of a PP, PP-Module, functional package or ST should specify when the TSF will run the testing of external entities, during initial start-up, periodically during normal operation, at the request of an authorized user, or under other conditions. If the tests are run often, then the end users should have more confidence that the TOE is operating correctly than if the tests are run less frequently. However, this need for confidence that the TOE is operating correctly needs to be balanced with the potential impact on the availability of the TOE, as often times, the testing of external entities may delay the normal operation of a TOE. the author of a PP, PP-Module, functional package or ST specifies the properties of the external entities to be checked by the tests. to check the fulfillment of list of properties of the external entities . If the test fails, the TSF shall action(s) the author of a PP, PP-Module, functional package or ST should specify what are the action(s) that the TSF shall perform when the testing fails. . The requirements of this family are needed to ensure the consistency of TSF data when such data is replicated internal to the TOE. Such data can become inconsistent if the internal channel between parts of the TOE becomes inoperative. If the TOE is internally structured as a network and parts of the TOE network connections are broken, this can occur when parts become disabled. The requirements of this family are needed to ensure the consistency of TSF data when such data is replicated internal to the TOE. Such data may become inconsistent if an internal channel between parts of the TOE becomes inoperative. If the TOE is internally structured as a network of parts of the TOE, this can occur when parts become disabled, network connections are broken, and so on. The method of ensuring consistency is not specified in this component. It can be attained through a form of transaction logging (where appropriate transactions are "rolled back" to a site upon reconnection); it can be updating the replicated data through a synchronization protocol. If a particular protocol is necessary for a PP, PP-Module, functional package or ST, it can be specified through refinement. It can be impossible to synchronize some states, or the cost of such synchronization can be too high. Examples of this situation are communication channel and encryption key revocations. Indeterminate states can also occur; if a specific behaviour is desired, it should be specified via refinement. No component rationale or application notes have been provided. This family consists of only one component, , which requires that the TSF ensure the consistency of TSF data that is replicated in multiple locations. Restoring consistency upon reconnection Detected inconsistency between TSF data The TSF shall ensure that TSF data is consistent when replicated between parts of the TOE. When parts of the TOE containing replicated TSF data are disconnected, the TSF shall ensure the consistency of the replicated TSF data upon reconnection before processing any requests for list of functions dependent on TSF data replication consistency the author of a PP, PP-Module, functional package or ST should specify the list of functions dependent on TSF data replication consistency. . The family defines the requirements for the self-testing of the TSF with respect to some expected correct operation. Examples are interfaces to enforcement functions, and sample arithmetical operations on critical parts of the TOE. These tests can be carried out at start-up, periodically, at the request of the authorized user, or when other conditions are met. The actions to be taken by the TOE as the result of self-testing are defined in other families. The requirements of this family are also needed to detect the corruption of TSF data and TSF itself (i.e. TSF executable code or TSF hardware component) by various failures that do not necessarily stop the TOE's operation (which would be handled by other families). These checks need to be performed because these failures cannot necessarily be prevented. Such failures can occur either because of unforeseen failure modes or associated oversights in the design of hardware, firmware, or software, or because of malicious corruption of the TSF due to inadequate logical and/or physical protection. The family defines the requirements for the self-testing of the TSF with respect to some expected correct operation. Examples are interfaces to enforcement functions, and sample arithmetical operations on critical parts of the TOE. These tests can be carried out at start-up, periodically, at the request of an authorized user, or when other conditions are met. The actions to be taken by the TOE as the result of self-testing are defined in other families. The requirements of this family are also needed to detect the corruption of TSF data and TSF itself (i.e. TSF executable code or TSF hardware component) by various failures that do not necessarily stop the TOE's operation (which would be handled by other families). These checks are performed because these failures may not necessarily be prevented. Such failures can occur either because of unforeseen failure modes or associated oversights in the design of hardware, firmware, or software, or because of malicious corruption of the TSF due to inadequate logical and/or physical protection. In addition, use of this component may, with appropriate conditions, help to prevent inappropriate or damaging TSF changes being applied to an operational TOE as the result of maintenance activities. The term "correct operation of the TSF" refers primarily to the operation of the TSF and the integrity of the TSF data. For TSF testing, it is acceptable for the functions that are available to the authorized user for periodic testing to be available only in an off-line or maintenance mode. Controls should be in place to limit access during these modes to authorized users. This component provides support for the testing of the critical functions of the TSF's operation by requiring the ability to invoke testing functions and check the integrity of TSF data and executable code. , provides the ability to test the TSF's correct operation. These tests can be performed at start-up, periodically, at the request of the authorized user, or when other conditions are met. It also provides the ability to verify the integrity of TSF data and TSF itself. Management of the conditions under which TSF self-testing occurs, such as during initial start-up, regular interval, or under specified conditions Management of the time interval if appropriate Indication that the TSF self-tests were completed and any failures of the tests Execution of the TSF self-tests and the results of the tests The TSF shall run a suite of the following self-tests during initial start-up periodically during normal operation at the request of the authorized user at the conditions conditions under which self-test should occur the author of a PP, PP-Module, functional package or ST should specify when the TSF will execute the TSF test; during initial start-up, periodically during normal operation, at the request of an authorized user, at other conditions. In the case of the latter option, the author of a PP, PP-Module, functional package or ST should also assign what those conditions are via the following assignment. the author of a PP, PP-Module, functional package or ST should specify whether the self-tests are to be carried out to demonstrate the correct operation of the entire TSF, or of only specified parts of TSF. to demonstrate the correct operation of parts of TSF the author of a PP, PP-Module, functional package or ST should, if selected, specify the conditions under which the self-test should take place. the TSF the author of a PP, PP-Module, functional package or ST should, if selected, specify the list of parts of the TSF that will be subject to TSF self-testing. : list of self-tests run by the TSF . The TSF shall provide authorized users with the capability to verify the integrity of parts of TSF data the author of a PP, PP-Module, functional package or ST should specify whether data integrity is to be verified for all TSF data, or only for selected data. TSF data the author of a PP, PP-Module, functional package or ST should, if selected, specify the list of TSF data that will be verified for integrity. . The TSF shall provide authorized users with the capability to verify the integrity of parts of TSF the author of a PP, PP-Module, functional package or ST should specify whether TSF integrity is to be verified for all TSF, or only for selected TSF. TSF the author of a PP, PP-Module, functional package or ST should, if selected, specify the list of TSF that will be verified for integrity. . This class provides three families that support the availability of required resources such as processing capability and/or storage capacity. The family Fault Tolerance provides protection against unavailability of capabilities caused by failure of the TOE. The family Priority of Service ensures that the resources will be allocated to the more important or time-critical tasks and cannot be monopolized by lower priority tasks. The family Resource Allocation provides limits on the use of available resources, therefore preventing users from monopolizing the resources. This class provides three families that support the availability of required resources such as processing capability and/or storage capacity. The family Fault Tolerance provides protection against unavailability of capabilities caused by failure of the TOE. The family Priority of Service ensures that the resources will be allocated to the more important or time-critical tasks and cannot be monopolized by lower priority tasks. The family Resource Allocation provides limits on the use of available resources, therefore preventing users from monopolizing the resources. The requirements of this family ensure that the TOE will maintain correct operation even in the event of failures. This family provides requirements for the availability of capabilities even in the case of failures. Examples of such failures are power failure, hardware failure, or software error. In case of these errors, if so specified, the TOE will maintain the specified capabilities. The author of a PP, PP-Module, functional package or ST can specify that a TOE used in a nuclear plant will continue the operation of the shut-down procedure in the case of power-failure or communication-failure Because the TOE can only continue its correct operation if the SFRs are enforced, there is a requirement that the system must remain in a secure state after a failure. This capability is provided by . The mechanisms to provide fault tolerance can be active or passive. In case of an active mechanism, specific functions are in place that are activated in case the error occurs. For example, a fire alarm is an active mechanism: the TSF will detect the fire and can take action such as switching operation to a backup. In a passive scheme, the architecture of the TOE is capable of handling the error. For example, the use of a majority voting scheme with multiple processors is a passive solution; failure of one processor will not disrupt the operation of the TOE (although it needs to be detected to allow correction). For this family, it does not matter whether the failure has been initiated accidentally (such as flooding or unplugging the wrong device) or intentionally (such as monopolizing). This component is intended to specify which capabilities the TOE will still provide after a failure of the system. Since it would be difficult to describe all specific failures, categories of failures may be specified. Examples of general failures are flooding of the computer room, short term power interruption, breakdown of a CPU or host, software failure, or buffer overflow. requires the TOE to continue correct operation of identified capabilities in the event of identified failures. Any failure detected by the TSF All toe capabilities being discontinued due to a failure The TSF shall ensure the operation of list of TOE capabilities the author of a PP, PP-Module, functional package or ST should specify the list of TOE capabilities the TOE will maintain during and after a specified failure. when the following failures occur: list of type of failures the author of a PP, PP-Module, functional package or ST should specify the list of types of failures against which the TOE has to be explicitly protected. If a failure in this list occurs, the TOE will be able to continue its operation. . This component is intended to specify against what type of failures the TOE be resistant. Since it would be difficult to describe all specific failures, categories of failures may be specified. Examples of general failures are flooding of the computer room, short term power interruption, breakdown of a CPU or host, software failure, or overflow of buffer. requires the TOE to continue correct operation of all capabilities in the event of identified failures. Any failure detected by the TSF The TSF shall ensure the operation of all the TOE's capabilities when the following failures occur: list of type of failures the author of a PP, PP-Module, functional package or ST should specify the list of types of failures against which the TOE has to be explicitly protected. If a failure in this list occurs, the TOE will be able to continue its operation. . The requirements of this family allow the TSF to control the use of resources under the control of the TSF by users and subjects such that high priority activities under the control of the TSF will always be accomplished without undue interference or delay caused by low priority activities. The requirements of this family allow the TSF to control the use of resources under the control of the TSF by users and subjects such that high priority activities under the control of the TSF will always be accomplished without interference or delay due to low priority activities, i.e. time critical tasks will not be delayed by tasks that are less time critical. This family can be applicable to several types of resources. Processing capacity, and communication channel capacity. The Priority of Service mechanism can be passive or active. In a passive Priority of Service system, the system will select the task with the highest priority when given a choice between two waiting applications. While using passive Priority of Service mechanisms, when a low priority task is running, it cannot be interrupted by a high priority task. While using an active Priority of Service mechanisms, lower priority tasks can be interrupted by new high priority tasks. The audit requirement states that all reasons for rejection should be audited. It is left to the developer to argue that an operation is not rejected but delayed. This component defines priorities for a subject, and the resources for which this priority will be used. If some subject attempts to act on a resource controlled by the Priority of Service requirements, the access and/or time of access will be dependent on the subject's priority, the priority of the currently acting subject, and the priority of the subjects still in the queue. , provides priorities for a subject's use of a subset of the resources under the control of the TSF. Assignment of priorities to each subject in the TSF Rejection of operation based on the use of priority within an allocation All attempted uses of the allocation function which involves the priority of the service functions The TSF shall assign a priority to each subject in the TSF. The TSF shall ensure that each access to controlled resources the author of a PP, PP-Module, functional package or ST should specify the list of controlled resources for which the TSF enforces priority of service. shall be mediated on the basis of the subjects assigned priority. This component defines priorities for a subject. All shareable resources under the control of the TSF will be subjected to the Priority of Service mechanism. If some subject attempts to take action on a shareable TSF resource, the access and/or time of access will be dependent on the subject's priority, the priority of the currently acting subject, and the priority of the subjects still in the queue. , provides priorities for a subject's use of all of the resources under the control of the TSF. The TSF shall assign a priority to each subject in the TSF. The TSF shall ensure that each access to all shareable resources shall be mediated on the basis of the subjects assigned priority. The requirements of this family allow the TSF to control the use of resources by users and subjects such that denial of service will not occur because of unauthorized monopolization of resources. The requirements of this family allow the TSF to control the use of resources under the control of the TSF by users and subjects such that unauthorized denial of service will not take place by means of monopolization of resources by other users or subjects. Resource allocation rules allow the creation of quotas or other means of defining limits on the amount of resource space or time that may be allocated on behalf of a specific user or subjects. These rules may, for example: Provide for object quotas that constrain the number and/or size of objects a specific user may allocate; Control the allocation/deallocation of preassigned resource units where these units are under the control of the TSF. In general, these functions will be implemented through the use of attributes assigned to users and resources. The objective of these components is to ensure a certain amount of fairness among the users and subjects. A single user should not allocate all the available space. Since resource allocation often goes beyond the lifespan of a subject (i.e. files often exist longer than the applications that generated them), and multiple instantiations of subjects by the same user should not negatively affect other users too much, the components allow that the allocation limits are related to the users. In some situations, the resources are allocated by a subject. Main memory or CPU cycles. In those instances, the components allow that the resource allocation be on the level of subjects. This family imposes requirements on resource allocation, not on the use of the resource itself. The audit requirements therefore, as stated, also apply to the allocation of the resource, not to the use of the resource. This component provides requirements for quota mechanisms that apply to only a specified set of the shareable resources in the TOE. The requirements allow the quotas to be associated with a user, possibly assigned to groups of users or subjects as applicable to the TOE. , provides requirements for quota mechanisms that ensure that users and subjects will not monopolize a controlled resource. Specifying maximum limits for a resource for groups and/or individual users and/or subjects by an administrator Rejection of allocation operation due to resource limits All attempted uses of the resource allocation functions for resources that are under control of the TSF The TSF shall enforce maximum quotas of the following resources: controlled resources the author of a PP, PP-Module, functional package or ST should specify the list of controlled resources for which maximum resource allocation limits are required. that individual user defined group of users subjects examples of controlled resources include processes, disk space, memory, and bandwidth. can use simultaneously over a specified period of time If all resources under the control of the TSF need to be included, the words "all TSF resources" may be specified. . This component provides requirements for quota mechanisms that apply to a specified set of the shareable resources in the TOE. The requirements allow the quotas to be associated with a user, or possibly assigned to groups of users as applicable to the TOE. , provides requirements for quota mechanisms that ensure that users and subjects will always have at least a minimum of a specified resource and that they will not be able to monopolize a controlled resource. Specifying minimum and maximum limits for a resource for groups and/or individual users and/or subjects by an administrator The TSF shall enforce maximum quotas of the following resources controlled resources the author of a PP, PP-Module, functional package or ST should select whether the maximum quotas apply to individual users, to a defined group of users, or subjects or any combination of these. that individual user defined group of users subjects the author of a PP, PP-Module, functional package or ST should select whether the maximum quotas are applicable to any given time (simultaneously), or over a specific time interval. can use simultaneously over a specified period of time . The TSF shall ensure the provision of minimum quantity of each controlled resource the author of a PP, PP-Module, functional package or ST selects whether the minimum quotas apply to individual users, to a defined group of users, or subjects or any combination of these. that is available for an individual user defined group of users subjects the author of a PP, PP-Module, functional package or ST selects whether the minimum quotas are applicable to any given time (simultaneously), or over a specific time interval. to use simultaneously over a specified period of time . This family specifies functional requirements for controlling the establishment of a user's session. The establishment of a user's session typically consists of the creation of one or more subjects that perform operations in the TOE on behalf of the user. At the end of the session establishment procedure, provided the TOE access requirements are satisfied, the created subjects bear the attributes determined by the identification and authentication functions. This family specifies functional requirements for controlling the establishment of a user's session. A user session is defined as the period starting at the time of the identification/authentication, or if more appropriate, the start of an interaction between the user and the system, up to the moment that all subjects (resources and attributes) related to that session have been deallocated. This family defines requirements to limit the scope of session security attributes that a user can select for a session. This family defines requirements that will limit the session security attributes a user may select, and the subjects to which a user may be bound, based on: The method of access, the location or port of access, and/or the time. Time-of-day, day-of-week. This family provides the capability for a PP, PP-Module, functional package or ST author to specify requirements for the TSF to place limits on the domain of an authorized user's security attributes based on an environmental condition. A user can be allowed to establish a "secret session" during normal business hours but outside those hours the same user can be constrained to only establishing "unclassified sessions". The identification of relevant constraints on the domain of selectable attributes may be achieved through the use of the selection operation. These constraints may be applied on an attribute-by-attribute basis. When there exists a need to specify constraints on multiple attributes this component will need to be replicated for each attribute. Examples of attributes that can be used to limit the session security attributes are: the method of access can be used to specify in which type of environment the user will be operating (such as file transfer protocol, terminal, vtam); the location of access can be used to constrain the domain of a user's selectable attributes based on a user's location or port of access. This capability is of particular use in environments where dial-up facilities or network facilities are available; the time of access can be used to constrain the domain of a user's selectable attributes. For example, ranges may be based upon time-of-day, day-of-week, or calendar dates. This constraint provides some operational protection against user actions that can occur at a time where proper monitoring or where proper procedural measures may not be in place. No component notes or rationale have been provided. , provides the requirement for a TOE to limit the scope of the session security attributes during session establishment. Management of the scope of the session security attributes by an administrator All failed attempts at selecting session security attributes All attempts at selecting session security attributes Capture of the values of each of the session security attributes The TSF shall restrict the scope of the session security attributes session security attributes the author of a PP, PP-Module, functional package or ST specifies the set of session security attributes that are to be constrained. , based on attributes examples of these session security attributes are user clearance level, integrity level and roles. . This family defines requirements to place limits on the number of concurrent sessions that belong to the same user. This family defines how many sessions a user may have at the same time (concurrent sessions). This number of concurrent sessions may either be set for a group of users or for each individual user. This component allows the system to limit the number of sessions in order to effectively use the resources of the TOE. , provides limitations that apply to all users of the TSF. Management of the maximum allowed number of concurrent user sessions by an administrator Rejection of a new session based on the limitation of multiple concurrent sessions Capture of the number of currently concurrent user sessions and the user security attribute(s) The TSF shall restrict the maximum number of concurrent sessions that belong to the same user. The TSF shall enforce, by default, a limit of default number the author of a PP, PP-Module, functional package or ST specifies the default number of maximum concurrent sessions to be used. sessions per user. This component provides additional capabilities over those of , by allowing further constraints to be placed on the number of concurrent sessions that users are able to invoke. These constraints are in terms of a user's security attributes, such as a user's identity, or membership of a role. extends by requiring the ability to specify limitations on the number of concurrent sessions based on the related security attributes. Management of the rules that govern the maximum allowed number of concurrent user sessions by an administrator The TSF shall restrict the maximum number of concurrent sessions that belong to the same user according to the rules rules for the number of maximum concurrent sessions the author of a PP, PP-Module, functional package or ST specifies the rules that determine the maximum number of concurrent sessions. . The TSF shall enforce, by default, a limit of default number the author of a PP, PP-Module, functional package or ST specifies the default number of maximum concurrent sessions to be used. sessions per user. This family defines requirements for the TSF to provide the capability for TSF-initiated and user-initiated locking, unlocking, and termination of interactive sessions. This family defines requirements for the TSF to provide the capability for TSF-initiated and user-initiated locking, unlocking, and termination of interactive sessions. When a user is directly interacting with subjects in the TOE (interactive session), the user's terminal is vulnerable if left unattended. This family provides requirements for the TSF to disable (lock) the terminal or terminate the session after a specified period of inactivity, and for the user to initiate the disabling (locking) of the terminal or terminate the session. To reactivate the terminal, an event specified by the author of a PP, PP-Module, functional package or ST, such as the user re-authentication must occur. A user is considered inactive, if he/she has not provided any stimulus to the TOE for a specified period of time. PP, PP-Module, functional package or ST authors consider whether should be included. In that case, the function "session locking" shall be included in the operation in . , provides the capability for the TSF to lock an active user session after a specified period of time. Locking a terminal would prevent any further interaction with an existing active session through the use of the locked terminal. If display devices are overwritten, the replacement contents need not be static (i.e. "screen savers" are permitted). This component allows the author of a PP, PP-Module, functional package or ST to specify what events will unlock the session. These events may be related to the terminal, the user, or time. Examples of events include: terminal related: a fixed set of keystrokes to unlock the session; user related: reauthentication; time related: after 15 min. includes system-initiated locking of an interactive session after a specified period of user inactivity. Specification of the time of user inactivity after which lock-out occurs for an individual user Specification of the default time of user inactivity after which lock-out occurs Management of the events that occur prior to unlocking the session Locking of an interactive session by the session locking mechanism Successful unlocking of an interactive session Any attempts at unlocking an interactive session The TSF shall lock an interactive session after time interval of user inactivity the author of a PP, PP-Module, functional package or ST specifies the interval of user inactivity that will trigger the locking of an interactive session. If requested, the author of a PP, PP-Module, functional package or ST can, through the assignment, specify that the time interval is left to the authorized administrator or the user. The management functions in can specify the capability to modify this time interval, making it the default value. by: clearing or overwriting display devices, making the current contents unreadable; disabling any activity of the user's data access/display devices other than unlocking the session. The TSF shall require the following events to occur prior to unlocking the session: events to occur the author of a PP, PP-Module, functional package or ST specifies the event(s) that should occur before the session is unlocked. . , provides the capability for an authorized user to lock and unlock his/her own interactive session. This would provide authorized users with the ability to effectively block further use of their active sessions without having to terminate the active session. If devices are overwritten, the replacement contents need not be static (i.e. "screen savers" are permitted). , provides capabilities for the user to lock and unlock the user's own interactive sessions. Management of the events that occur prior to unlocking the session The TSF shall allow user-initiated locking of the user's own interactive session, by: clearing or overwriting display devices, making the current contents unreadable; disabling any activity of the user's data access/display devices other than unlocking the session. The TSF shall require the following events to occur prior to unlocking the session: events to occur the author of a PP, PP-Module, functional package or ST specifies the event(s) that shall occur before the session is unlocked. . requires that the TSF terminate an interactive user session after a period of inactivity. The author of a PP, PP-Module, functional package or ST should be aware that a session may continue after the user terminated his/her activity. This requirement would terminate this background subject after a period of inactivity of the user without regard to the status of the subject. An example of a continuing session after a user terminated activity is background processing. , provides requirements for the TSF to terminate the session after a specified period of user inactivity. Specification of the time of user inactivity after which termination of the interactive session occurs for an individual user Specification of the default time of user inactivity after which termination of the interactive session occurs Termination of an interactive session by the session locking mechanism The TSF shall terminate an interactive session after a time interval of user inactivity the author of a PP, PP-Module, functional package or ST specifies the interval of user inactivity that will trigger the termination of an interactive session. If requested, the author of a PP, PP-Module, functional package or ST can, through the assignment, specify that the interval is left to the authorized administrator or the user. The management functions in can specify the capability to modify this time interval, making it the default value. . , provides the capability for an authorized user to terminate his/her interactive session. The author of a PP, PP-Module, functional package or ST should be aware that a session can continue after the user terminated his/her activity. An example of a continuing session after a user terminated activity is background processing. This requirement would allow the user to terminate this background subject without regard to the status of the subject. , provides capabilities for the user to terminate the user's own interactive sessions. Termination of an interactive session by the user The TSF shall allow user-initiated termination of the user's own interactive session. This family defines requirements to display a configurable advisory warning message to users regarding the appropriate use of the TOE. Prior to identification and authentication, TOE access requirements provide the ability for the TOE to display an advisory warning message to potential users pertaining to appropriate use of the TOE. This component requires that there is an advisory warning regarding the unauthorized use of the TOE. A PP, PP-Module, functional package or ST author can refine the requirement to include a default banner. , provides the requirement for a TOE Access Banner. This banner is displayed prior to the establishment dialogue for a session. Maintenance of the banner by the authorized administrator Before establishing a user session, the TSF TOE platform shall display an description of the message message. This family defines requirements for the TSF to display to a user, upon successful session establishment, a history of successful and unsuccessful attempts to access the user's account. This family defines requirements for the TSF to display to users, upon successful session establishment to the TOE, a history of unsuccessful attempts to access the account. This history can include the date, time, means of access, and port of the last successful access to the TOE, as well as the number of unsuccessful attempts to access the TOE since the last successful access by the identified user. This family can provide authorized users with information that can indicate the possible misuse of their user account. This component requests that the user is presented with the information. The user should be able to review the information but is not forced to do so. A user can create scripts that ignore this information and start other processes. , provides the requirement for a TOE to display information related to previous attempts to establish a session. Upon successful session establishment, the TSF shall display the date time method location the author of a PP, PP-Module, functional package or ST selects the security attributes of the last successful session establishment that will be shown at the user interface. The items are: Date, time, method of access, and/or location. of the last successful session establishment to the user. Upon successful session establishment, the TSF shall display the date time method location the author of a PP, PP-Module, functional package or ST selects the security attributes of the last unsuccessful session establishment that will be shown at the user interface. The items are: Date, time, method of access, and/or location. of the last unsuccessful attempt to session establishment and the number of unsuccessful attempts since the last successful session establishment. The TSF shall not erase the access history information from the user interface without giving the user an opportunity to review the information. This family defines requirements to deny a user permission to establish a session with the TOE. This family defines requirements to deny a user permission to establish a session with the TOE based on attributes such as the location or port of access, the user's security attribute, ranges of time or combinations of parameters. Security attribute: identity, clearance level, integrity level, membership in a role. Ranges of time: time-of-day, day-of-week, calendar dates. This family provides the capability for the author of a PP, PP-Module, functional package or ST to specify requirements for the TOE to place constraints on the ability of an authorized user to establish a session with the TOE. The identification of relevant constraints can be achieved through the use of the selection operation. Examples of attributes that can be used to specify the session establishment constraints are: The location of access can be used to constrain the ability of a user to establish an active session with the TOE, based on the user's location or port of access. This capability is of particular use in environments where dial-up facilities or network facilities are available. The user's security attributes can be used to place constraints on the ability of a user to establish an active session with the TOE. For example, these attributes would provide the capability to deny session establishment based on any of the following: a user's identity; a user's clearance level; a user's integrity level; a user's membership in a role. This capability is particularly relevant in situations where authorization or login may take place at a different location from where TOE access checks are performed. The time of access can be used to constrain the ability of a user to establish an active session with the TOE based on ranges of time. For example, ranges may be based upon time-of-day, day-of-week, or calendar dates. This constraint provides some operational protection against actions that can occur at a time where proper monitoring or where proper procedural measures may not be in place. No component rationale or application notes have been provided for this component. , provides requirements for denying users access to the TOE based on attributes. Management of the session establishment conditions by the authorized administrator Denial of a session establishment due to the session establishment mechanism All attempts at establishment of a user session Capture of the value of the selected access parameters The TSF shall be able to deny session establishment based on attributes the author of a PP, PP-Module, functional package or ST specifies the attributes that can be used to restrict the session establishment. . Families in this class provide requirements for a trusted communication path between users and the TSF, and for a trusted communication channel between the TSF and other trusted IT products. Trusted paths and channels have the following general characteristics: the communications path is constructed using internal and external communications channels (as appropriate for the component) that isolate an identified subset of TSF data and commands from the remainder of the TSF and user data; use of the communications path can be initiated by the user and/or the TSF (as appropriate for the component); the communications path is capable of providing assurance that the user is communicating with the correct TSF, and that the TSF is communicating with the correct user (as appropriate for the component). In this paradigm, a trusted channel is a communication channel that can be initiated by either side of the channel and provides non-repudiation characteristics with respect to the identity of the sides of the channel. A trusted path provides a means for users to perform functions through an assured direct interaction with the TSF. Trusted path is usually desired for user actions such as initial identification and/or authentication but can also be desired at other times during a user's session. Trusted path exchanges can be initiated by a user or the TSF. User responses via the trusted path are guaranteed to be protected from modification by or disclosure to untrusted applications. Families describing the use of commonly used communication protocols used in the provision of trusted channels and paths are also given. Users often need to perform functions through direct interaction with the TSF. A trusted path provides confidence that a user is communicating directly with the TSF whenever it is invoked. A user's response via the trusted path guarantees that untrusted applications cannot intercept or modify the user's response. Similarly, trusted channels are one approach for secure communication between the TSF and another trusted IT product. Absence of a trusted path can allow breaches of accountability or access control in environments where untrusted applications are used. These applications can intercept user-private information, such as passwords, and use it to impersonate other users. As a consequence, responsibility for any system actions cannot be reliably assigned to an accountable entity. Also, these applications can output erroneous information on an unsuspecting user's display, resulting in subsequent user actions that can be erroneous and can lead to a security breach. This family defines requirements for the creation of a trusted channel between the TSF and other trusted IT products for the performance of security critical operations. The components of this family may be included whenever there are requirements for the secure communication of user or TSF data between the TOE and other trusted IT products. This family defines the rules for the creation of a trusted channel connection that goes between the TSF and another trusted IT product for the performance of security critical operations between the products. An example of such a security critical operation is the updating of the TSF authentication database by the transfer of data from a trusted product whose function is the collection of audit data. This component is used when a trusted communication channel between the TSF and another trusted IT product is required. requires that the TSF provide a trusted communication channel between itself and another trusted IT product. Configuring the actions that require trusted channel, if supported Failure of the trusted channel functions Identification of the initiator and target of failed trusted channel functions All attempted uses of the trusted channel functions Identification of the initiator and target of all trusted channel functions The TSF shall provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. The TSF shall permit the TSF another trusted IT product the author of a PP, PP-Module, functional package or ST specifies whether the local TSF, another trusted IT product, or both shall have the capability to initiate the trusted channel. to initiate communication via the trusted channel. The TSF shall initiate communication via the trusted channel for list of functions for which a trusted channel is required the author of a PP, PP-Module, functional package or ST specifies the functions for which a trusted channel is required. . This family defines requirements for establishing a trusted channel and using the trusted channel to transfer the TSF data or user data securely. This family defines the rules for the creation of a trusted channel connection that goes between the TSF and another trusted IT product for the protection of data transfers. In contrast with or , is concerned with security details of the protocol used for a channel and provides a focus for protocol properties that can otherwise be split between a larger number of separate SFRs. It can improve clarity of a PP, PP-Module, functional package or ST by highlighting mechanisms within the protocol that may then be linked to cryptographic functions described in other SFRs (such as ). The components of are not hierarchical but are intended to be used together to separately specify different aspects of a trusted channel, such as its confidentiality and integrity protection features. There is no dependency from to because any mechanisms for security of the shared secret establishment will be part of the mechanism described in itself. In cases where some cryptographic operations used in the trusted channel protocol are performed outside the TOE, and/or can be omitted from a PP, PP-Module, functional package or ST, and the ST author would then need to supply a rationale for the unsatisfied dependencies between components. Separate iterations of the relevant components may be used for different channels where the completion of the SFR needs to be different for each channel. In general, each separate iteration will need to include all three components with its own dependencies' rationale. Where values used in the completion of operations have dependencies between different SFR elements, these need to be made clear in the instantiation of the SFR. A table can be given in which the columns represent the relevant selections and assignments, and the rows define the valid combination of completion values. requires that communication be established in accordance with a defined protocol. Configuring the protocols needed for the trusted channel Configuring the credentials for using the trusted channel Configuring the conditions for initializing and terminating the trusted channel Failure of the trusted channel establishment Identification of the initiator and target of failed trusted channel establishment All attempted uses of the trusted channel Identification of the initiator and target of all trusted channel attempts Other events should be considered according to the specific protocols used. The TSF shall implement trusted channel protocol if selected, the author of a PP, PP-Module, functional package or ST should specify a trusted channel protocol and the defined protocol roles. acting as defined protocol role(s) in accordance with: list of standards Examples of "defined protocol roles" would be "client" or "server" (TLS), "initiator" or "responder" (IKEv2/IPsec), "Trust Center" (ZigBee) or "Key Distribution Centre" (Kerberos). . The TSF shall enforce usage of the trusted channel for purpose(s) of the trusted channel the first assignment is intended to state rules for when the trusted channel is required to be used by the TOE, such as mandating its use for communications with an audit server. This assignment may take the value "None specified" (also with "None specified" in the second assignment) if no specific uses of the channel are mandated for the TOE. in accordance with: list of standards . The TSF shall permit itself its peer the author of a PP, PP-Module, functional package or ST selects which entity is allowed to initiate the establishment of the trusted channel. to initiate communication via the trusted channel. The TSF shall enforce the following rules for the trusted channel: rules governing operation and use of the trusted channel and/or its protocol . The TSF shall enforce the following static protocol options: list of options and references to standards in which each is defined the assignment is intended to state rules related to implementation of the protocol(s). It may take the value "None specified" if no rules are required, or if the standards referenced in other elements of the SFR include the relevant rules and no specific evaluator check is required for the context in which the SFR is being used. . The TSF shall negotiate one of the following protocol configurations with its peer: list of configurations and reference to standards in which each is defined the assignment is intended to state rules related to negotiable aspects of the protocol, when intending to narrow the options provided by the TOE compared to the standard that defines the protocol. . In , the "list of rules for carrying out the authentication" may be used to limit available parameters for the authentication mechanisms. Rules can be stated for the format (e.g. FQDN or IP address, use of wildcards) or prioritization of identifiers when alternative sources of an identifier are available in the authentication data exchanged. requires that keys be securely established between the peers. Configuring the parameters for shared secrets Configuring the parameters for cryptographic key derivation Authentication failures during channel establishment All authentication attempts The TSF shall establish a shared secret with its peer using one of the following mechanisms: list of key establishment mechanisms The author of a PP, PP-Module, functional package or ST provides a list of key establishment mechanisms. . The TSF shall authenticate its peer itself to its peer the assignments include providing a list of authentication mechanisms used during the authentication and a list of rules used during the authentication. using one of the following mechanisms: list of authentication mechanisms and according to the following rules: list of rules for carrying out the authentication . The TSF shall use key derivation function to derive the following cryptographic keys from a shared secret: list of cryptographic keys . The component addresses protection (confidentiality and integrity) of data in transit through a trusted channel. requires that data in transit be protected. Configuring the encryption and integrity mechanisms used by the trusted channel Failures when attempting to verify channel properties in ftp_pro.3.2 The TSF shall protect data in transit from unauthorised disclosure using one of the following mechanisms: list of encryption mechanisms the author of a PP, PP-Module, functional package or ST completes the assignment by specifying lists of encryption and integrity protection mechanisms. . The TSF shall protect data in transit from modification deletion insertion replay other the author of a PP, PP-Module, functional package or ST selects the attacks that are mitigated by the TSF. the author of a PP, PP-Module, functional package or ST completes the assignment by specifying lists of encryption and integrity protection mechanisms. using one of the following mechanisms: list of integrity protection mechanisms . This family defines the requirements to establish and maintain trusted communication to or from users and the TSF. A trusted path can be required for any security-relevant interaction. Trusted path exchanges can be initiated by a user during an interaction with the TSF, or the TSF can establish communication with the user via a trusted path. This family defines the requirements to establish and maintain trusted communication to or from users and the TSF. A trusted path may be required for any security-relevant interaction. Trusted path exchanges may be initiated by a user during an interaction with the TSF, or the TSF may establish communication with the user via a trusted path. This component is used when trusted communication between a user and the TSF is required, either for initial authentication purposes only or for additional specified user operations. requires that a trusted path between the TSF and a user be provided for a set of events defined by a PP, PP-Module, functional package or ST author. The user and/or the TSF can have the ability to initiate the trusted path. Configuring the actions that require trusted path, if supported Failures of the trusted path functions Identification of the user associated with all trusted path failures, if available All attempted uses of the trusted path functions Identification of the user associated with all trusted path invocations, if available The TSF shall provide a communication path between itself and remote local the author of a PP, PP-Module, functional package or ST specifies whether the trusted path is to be extended to remote and/or local users. users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from modification disclosure other types of integrity or confidentiality violation the author of a PP, PP-Module, functional package or ST specifies whether the trusted path shall protect the data from modification, disclosure, and/or other types of integrity or confidentiality violation. if selected, the author of a PP, PP-Module, functional package or ST identifies any additional types of integrity or confidentiality violation against which the trusted path shall protect the data. . The TSF shall permit the TSF local users remote users the author of a PP, PP-Module, functional package or ST specifies whether the TSF, local users, and/or remote users are able to initiate the trusted path. to initiate communication via the trusted path. The TSF shall require the use of the trusted path for initial user authentication other services for which trusted path is required the author of a PP, PP-Module, functional package or ST specifies whether the trusted path is to be used for initial user authentication and/or for other specified services. if selected, the author of a PP, PP-Module, functional package or ST identifies other services for which trusted path is required, if any. .