Supporting Document Mandatory Technical Document: Evaluation Activities for collaborative Protection Profile Module for Server Applications

See Section 1.1, “Technology Area and Scope of Supporting Document”.

This Supporting Document applies to the evaluation of TOEs claiming conformance with the collaborative PP-Module for Server Applications.

This Supporting Document (SD) is mandatory for evaluations of products that claim conformance to any of the following cPP(s):

Although Evaluation Activities (EAs) are defined mainly for the evaluator to follow, the definitions in this SD aim to provide a common understanding for developers, evaluators and users as to what aspects of the TOE are tested in an evaluation against Collaborative Protection Profile for Application Software, and to what depth the testing is carried out. This common understanding in turn contributes to the goal of ensuring that evaluations against Collaborative Protection Profile for Application Software achieve comparable, transparent and repeatable results. In general, the definition of EAs will also help developers to prepare for evaluation by identifying specific requirements for their TOE. The specific requirements in EAs may in some cases clarify the meaning of SFRs, and may identify particular requirements for the content of Security Targets (STs) (especially the TOE Summary Specification (TSS)), AGD guidance, tests, and possibly required supplementary information (e.g. any examples, such as for entropy analysis or cryptographic key architecture).

EAs can be defined for both SFRs and SARs. These are defined in separate sections of this SD.

If any EA cannot be successfully completed in an evaluation then the overall verdict for the evaluation is a 'fail'. In rare cases there may be acceptable reasons why an EA may be modified or deemed not applicable for a particular TOE, but this must be agreed with the Certification Body for the evaluation.

In general, if all EAs (for both SFRs and SARs) are successfully completed in an evaluation then it would be expected that the overall verdict for the evaluation is a 'pass'. To reach a 'fail' verdict when the EAs have been successfully completed would require a specific justification from the evaluator as to why the EAs were not sufficient for that TOE.

Similarly, at the more granular level of Assurance Components, if the Evaluation Activities for an Assurance Component and all of its related SFR Evaluation Activities are successfully completed in an evaluation then it would be expected that the verdict for the Assurance Component is a 'pass'. To reach a 'fail' verdict for the Assurance Component when these Evaluation Activities have been successfully completed would require a specific justification from the evaluator as to why the Evaluation Activities were not sufficient for that TOE.

All EAs for SFRs defined in this Section include the following items to keep consistency among EAs.

For a distributed TOE, every TOE Component to which an SFR is allocated shall satisfy that requirement, every TOE Component Instance shall exhibit the claimed behavior of its TOE Component in its identified configuration, and every applicable artifact, interface, communication relationship, configuration, and deployment context shall be covered by the EAs at their stated scope. A Component Implementation-Equivalence Class groups named SFR Implementation Instances used by TOE Components and identified security-relevant configurations where applicable; it does not group or eliminate coverage of interfaces or communication relationships. An SFR Implementation Instance is a unique use of an implementation by a TOE Component, in an identified security-relevant configuration where applicable, to satisfy one or more SFRs. Additional Runtime Replicas that deploy that use do not create additional SFR Implementation Instances. Representative execution with complete class-membership verification is not sampling.

The ST shall provide concise traceability from each TOE Component and identified security-relevant configuration, where applicable, to its SFR iteration and, where evidence reuse is claimed, to a class identifier and common TSS description. The ST may identify unambiguous sets of TOE Components and configurations and need not map them to individual EAs. The developer shall provide an implementation-equivalence rationale, which may be separate from the ST, identifying the class members, all SFR iterations covered, and the exact implementation-specific EA paragraphs or test identifiers for which reuse is proposed.

Class members shall have the same security-relevant implementation and version, wrapper or integration behavior, security-relevant build options, implementation configuration and values relevant to the reused activities, role and exercised code path, cryptographic provider where applicable, and immediate platform services and interfaces relevant to the reused activities. Channel-specific certificates, keys, trust-anchor values, endpoint identities, addresses, and similar deployed values may differ when they do not alter the reused implementation behavior and are covered by retained interface- or channel-specific activities. The rationale shall identify peripheral differences reasonably capable of affecting the scoped results and explain why they cannot do so. A common base image, runtime, library name, source repository, or build pipeline alone is not sufficient. When the prerequisites or the effect of a relevant peripheral difference cannot be substantiated, the affected SFR Implementation Instances may not share representative execution for that scope.

The evaluator shall examine objective evidence for every claimed class member and select one or more representative class-member SFR Implementation Instances and, for each, an exact deployed TOE Component Instance through which it will be exercised. The selected SFR Implementation Instances and deployed TOE Component Instances shall collectively expose all behavior relevant to the identified activities. Objective evidence may include artifact identifiers or hashes, dependency manifests, software bills of materials, build records, configuration records, or observed invocation paths. If they do not expose all relevant behavior, the evaluator shall require additional execution or determine that the class is not substantiated for that scope.

The base cPP Supporting Document’s general guidance for Linux-container application payloads applies to every Running-Payload Activity portion of an EA in this Supporting Document. Image, runtime, and orchestrator differences are evaluated separately when they are outside the scope of a running-payload activity. If one of those differences can affect a proposed reused running-payload result, it is also a class-relevant difference and shall be addressed by the implementation-equivalence rationale.

Representative execution eliminates only duplicate execution of the same implementation-specific activity across class members. It does not reduce any test count, parameter combination, supported algorithm, protocol role, configuration, certificate case, negative test, artifact, interface, channel, communication relationship, deployment context, or end-to-end coverage required by the originating EA. A single execution may be cited for more than one SFR Implementation Instance, SFR, or EA only when it demonstrates every applicable objective and the evaluator preserves a separate coverage mapping and verdict for each.

The evaluation report shall identify each class, the membership evidence examined, the representative SFR Implementation Instance or instances selected, the exact deployed TOE Component Instances used for execution, the activities performed, the repetitions not performed, and the artifact-, interface-, channel-, configuration-, deployment-, and end-to-end checks performed separately. Use of this procedure does not deem an EA inapplicable or transfer compliance from one TOE Component or identified configuration to another.

For TLS and similar trusted-channel testing, multiple TOE Components or identified security-relevant configurations may share the complete protocol-implementation test suite only when the SFR Implementation Instances of their substantiated TLS implementation meet the class prerequisites above. Every distinct interface and channel remains subject to the required connection, credential, trust, identity, traffic-protection, interruption, recovery, and integration checks, and all internal repetitions required by the protocol EA shall be performed on the selected TOE Component Instance or instances. TLS termination performed by an operational-environment service mesh or ingress component is an environmental dependency, not a shared TOE implementation, unless that component is explicitly included in the TOE boundary. An operational-environment termination point cannot be credited as satisfying FTP_DIT_EXT.1 or another TOE-implemented channel requirement unless the applicable SFR expressly permits platform-provided functionality.

EAs in this SD provide specific or more detailed guidance to evaluate the type of system, however, it is the CEM work units based on which the evaluator shall perform evaluations.

This Section explains how EAs for SFRs are derived from the particular CEM work units identified in Assessment Strategy to show the consistency and compatibility between the CEM work units and EAs in this SD.

Assessment Strategy for ASE_TSS requires the evaluator to examine that the TSS provides sufficient design descriptions and its verdicts will be associated with the CEM work unit ASE_TSS.1-1. Evaluator verdicts associated with the supplementary information will also be associated with ASE_TSS.1-1, since the requirement to provide such evidence is specified in ASE in the cPP.

Assessment Strategy for AGD_OPE/ADV_FSP requires the evaluator to examine that the AGD guidance provides sufficient information for the administrators/users as it pertains to SFRs, its verdicts will be associated with CEM work units ADV_FSP.1-7, AGD_OPE.1-4, and AGD_OPE.1-5.

Assessment Strategy for ATE_IND requires the evaluator to conduct testing that the iTC has determined that those testing of the TOE in the context of the associated SFR is necessary. While the evaluator is expected to develop tests, there may be instances where it is more practical for the developer to construct tests, or where the developer may have existing tests. Therefore, it is acceptable for the evaluator to witness developer-generated tests in lieu of executing the tests. In this case, the evaluator must ensure the developer’s tests are executing both in the manner declared by the developer and as mandated by the EA. The CEM work units that derive those EAs are: ATE_IND.1-3, ATE_IND.1-4, ATE_IND.1-5, ATE_IND.1-6, and ATE_IND.1-7.