Evaluation Activities - commoncriteria/pp-template GitHub Wiki
Updated 8 January 2025
All Components (and some Elements and Management Functions) have Evaluation Activities (EAs). In XML, EAs are specified within <aactivity>
elements. A typical EA section is structured like this:
<aactivity>
<TSS>
The evaluator shall examine the TSS to determine...<h:p/>
</TSS>
<Guidance>
The evaluator shall examine the Operational Guidance to determine...<h:p/>
</Guidance>
<CustomEA name="KMD">
The evaluator shall examine the KMD to determine...<h:p/>
</CustomEA>
<Tests>
The evaluator shall perform the following tests:...
</Tests>
</aactivity>
Any of the four activities can be included or omitted.
The KMD activities can currently be specified either using the <CustomEA>
tag, or using the <KMD>
tag. In the future, the <KMD>
tag will be deprecated. See below for more information about the <CustomEA>
tag and it's purpose.
In the unlikely event that there are no EAs for a requirement, or if the EAs can be found elsewhere, or they are covered by another requirement, then use the <no-tests>
XML element. For example:
<aactivity>
<no-tests>EAs for this SFR can be found at some other specific place.</no-tests>
</aactivity>
If you leave the <no-tests>
element empty, a "TODO" will be dumped in to your document to remind you to explain why there are no tests.
ASE_TSS.1 requires that the developer provide a TOE Summary Specification (TSS) that describes how the TOE meets each SFR. Other SARs require that the TSS describe how the TOE protects itself against interference, logical tampering, and bypass.
Since the SARs already require that the TSS describe how the TOE meets all the requirements, this activity should be used only to point out specific aspects of the requirement that must be documented in the the TSS.
The language of this activity should read something like:
The evaluator shall examine the TSS to determine...
If there are no additional TSS activities, something like the following language should be used:
There are no additional TSS evaluation activities for this component/element/management function.
The appropriate above text will be produced if you provide an empty <TSS/>
element.
The CC:2022 requires at least two types of Guidance documentation: Operational Guidance and Administrator Guidance. Administrator Guidance contains of instructions for putting the TOE into the evaluated configuration. The Operational Guidance is documentation for users of the system. This activity concerns the Operational Guidance, or the Guidance in general. It is sometimes referred to as "AGD."
AGD_OPE.1 requires that the Operational Guidance describe the following:
- for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings,
- for each user role, how to use the available interfaces provided by the TOE in a secure manner,
- 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,
- 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,
- identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation,
- 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.
If a particular component or element requires additional specific user operational guidance beyond what is already required, then this activity should be used to define the additional guidance.
The language of this activity should read something like:
The evaluator shall examine the Operational Guidance to determine...
If there are no additional Guidance activities, something like the following language should be used:
There are no additional Guidance evaluation activities for this component/element/management function.
The appropriate above text will be produced if you provide an empty <Guidance/>
element.
Custom EAs are categories of EAs that are not part of the CC, but rather are defined by a Technical Community as specific their technology area. Typically, the purpose of custom EAs is to require specification of potentially proprietary information in a non-public document rather than in the TSS or AAR.
The best known custom EA is KMD, which is used to specify documentation of potentially proprietary key management requirements. In fact, KMD EAs are so well-known that it has it's own XML tag <KMD>
. Other PPs use other custom EAs, but until now there has been no way to specify them.
The <KMD>
tag should no longer be used as it will be deprecated in the future. From now on, the <CustomEA>
tag should be used to specify EAs that are not TSS, Guidance, or Tests.
<CustomEA name="KMD">
The evaluator shall examine the KMD to determine blah blah blah...
</CustomEA>
If there are no activities, use an empty tag:
<CustomEA name="Whatever"/>
The framework will generate default text such as:
There are no additional Whatever evaluation activities for this component/element/management function.
The goal of testing is to determine the whether the TOE behaves as described in the ST and as specified in the evaluation evidence (described in the ADV class).
For NIAP PPs, all testing is Independent testing as required by ATE_IND.1. Developer testing is not addressed in NIAP PPs.
All testing is based on ATE_IND.1.2E, which states:
The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
If there are no test activities for this requirement, something like the following language should be used:
There are no test activities for this component/element/management function.
The above text will be produced if you provide an empty <Tests/>
element.
For more on Testing, see Testing.