| Clause # | Title | Description on how to apply the document |
| 6.x | XXX Mechanism | Mechanism for each specific item (e.g., external interface or security asset) |
| 6.x.1 | XXX-1 Applicability of mechanisms | Applicability of the mechanism |
| 6.x.1.1 | Requirement | For each specific item determine and assess if the mechanism is required.NOTE A mechanism might combine applicability and appropriateness in a single requirement. |
| 6.x.1.2 | Rationale |
| 6.x.1.3 | Guidance |
| 6.x.1.4 | Assessment criteria |
| 6.x.1.4.1 | | Assessment objective |
| 6.x.1.4.2 | | Implementation categories |
| 6.x.1.4.3 | | Required information |
| 6.x.1.4.4 | | Conceptual assessment | |
| 6.x.1.4.5 | | Functional completeness assessment |
| 6.x.1.4.6 | | Functional sufficiency assessment |
| 6.x.2 | XXX-2 Appropriate mechanisms | Appropriateness of the mechanism |
| 6.x.2.1 | Requirement | For each specific item for which the mechanism is required as determined by XXX-1, determine and assess whether the mechanism is implemented properly. NOTE A mechanism might have multiple appropriateness sub-clauses to focus on specific properties. |
| 6.x.2.2 | Rationale |
| 6.x.2.3 | Guidance |
| 6.x.2.4 | Assessment criteria |
| 6.x.2.4.1 | | Assessment objective |
| 6.x.2.4.2 | | Implementation categories |
| 6.x.2.4.3 | | Required information |
| 6.x.2.4.4 | | Conceptual assessment |
| 6.x.2.4.5 | | Functional completeness assessment |
| 6.x.2.4.6 | | Functional sufficiency assessment |
| 6.x.y | XXX-# Supporting Requirements | Applicability and appropriateness of supporting requirements for the mechanism |
| 6.x.y.1 | Requirement | For each specific item for which the mechanism is required as determined by XXX-1, determine and assess if the supporting requirement needs to be implemented (there might be specific conditions, for instance if the equipment is a toy) and if it needs to be implemented, whether it is implemented properly. NOTE Some chapters contain multiple requirements, which leads to slight deviations in terms of numbering. |
| 6.x.y.2 | Rationale |
| 6.x.y.3 | Guidance |
| 6.x.y.4 | Assessment criteria |
| 6.x.y.4.1 | | Assessment objective |
| 6.x.y.4.2 | | Implementation categories |
| 6.x.y.4.3 | | Required information |
| 6.x.y.4.4 | | Conceptual assessment |
| 6.x.y.4.5 | | Functional completeness assessment |
| 6.x.y.4.6 | | Functional sufficiency assessment |
The assessments are conducted by examining the documented assessment cases, not all assessment cases might be provided for every mechanism:
— Conceptual assessment
Examine if the provided documentation and rationale provide the required evidence (for example the rationale why a mechanism is not applicable for a specific network interface).
— Functional completeness assessment
Examine and test if the provided documentation is complete (for example use network scanners to verify that all external interfaces are properly identified, documented and assessed)
— Functional sufficiency assessment
Examine and test if the implementation is adequate (for example run fuzzing tools on a network interface to check if it is resilient to attacks with malformed data)
Each of the assessments is further divided into the following sub-clauses which might use a decision tree to guide the assessment:
— Assessment purpose
— Preconditions
- Assessment units
— Assignment of verdict
Required information lists the information to be provided through technical documentation. This document does not require each required information element to be provided as a separate document.
For the section assessment criteria, the following identifiers with the defined syntax are used to structure the elements which are needed to perform an assessment:
— Required information
E.<Type>.<MechanismAbbreviation-<Nr>>.<CategoryName>
Identifier for the category of the required information excluding DTs
— Required information for decision trees
E.<Type>.DT.<MechanismAbbreviation-<Nr>>
Identifier for the category of the required information in the context of DTs
— Implementation Category
IC.<MechanismAbbreviation-<Nr>>.<ImplemenationCategoryName>
Identifier for the implementation category
— Assessment Unit
AU.<MechanismAbbreviation-<Nr>>.<AssessmentUnitName>
Identifier for the assessment unit
— Decision Tree Nodes
DT.<MechanismAbbreviation-<Nr>>.DN-<Number>
Identifier for a specific node inside the DT
The placeholders are used as follows:
— <Type>: “Info” or “Just” to indicate the kind of required documentation which could by information” or justification.
— <CategoryName>: Name of the category for the required documentation. A <CategoryName> could contain additional Sub-Category-Names divided with "." .
— <ImplemenationCategoryName>: Name of the implementation category which describes the defined implementation.
— <AssessmentUnitName>: Name of the assessment unit for a specific implementation category.
— <MechanismAbbreviation-<Nr>>: Abbreviation of the name from the specific requirement which belongs to the assessment criteria.
# 6 Requirements
# 6.1[ACM] Access control mechanism
# 6.1.1 [ACM-1] Applicability of access control mechanisms
# 6.1.1.1 Requirement
The equipment shall use access control mechanisms to manage entities' access to security assets and privacy assets, except for access to security assets or privacy assets where:
— public accessibility is the equipment’s intended functionality; or
— legal implications do not allow for access control mechanisms.
— physical or logical measures in the equipment’s targeted operational environment limit their accessibility to authorized entities; or
# 6.1.1.2 Rationale
Security assets and privacy assets might be exposed to unauthorized access attempts. Access control mechanisms limit the ability of any unauthorized entity to access these assets.
# 6.1.1.3 Guidance
The requirement does not demand access control mechanisms on assets that it does not cover (for example, the dispense button on a coffee machine). Further it does not demand access control mechanisms for security assets or privacy assets that are in principle covered, but where the intended equipment functionality is to be generally accessible by the public or where the intended operational environment of use ensures that only authorized access is possible. If the equipment relies on the access control given by the intended operational environment, it is to be ensured that this access control is appropriate as described in ACM-2.
In general, full public accessibility to privacy assets cannot be considered as a reasonable intended equipment functionality, especially concerning children’s privacy and childcare. However, specific scenarios involving public accessibility to privacy assets may be considered as intended equipment functionality if part of clearly advertised functionality or is communicated (to non-child users) via UNM.
Radio interfaces might be accessible even if the equipment is in an environment preventing physical manipulation by an unauthorized entity, for instance a wireless network is often accessible from outside a user’s home.
For example, depending on the equipment’s technical properties, intended equipment functionality and intended operational environment of use access control mechanisms might not be necessary for relevant security assets or privacy assets where:
— all entities with access to the equipment (the equipment is intended to be operated in an area which has physical access control) are authorized to access these security assets or privacy assets (for example, the WPS button on a home router);
— the equipment’s functionality only provides information (on security assets or privacy assets) that is intended to be publicly accessible (for instance broadcasting short-range wireless technology advertising beacons).
Access control mechanisms need properties to tie access rights to. Such properties can amongst others be:
— verified claims of entities (for instance being owner of a user account, member of specific group, authorized by another entity);
certain states of the equipment or the equipment’s environment (for instance an electronic flight bag might have different access rights for a local user when it is operated in the air, than when it is stored at the ground);
— the external interface an access is performed from (for instance a local access, where physical access control is obviously in place, might have different access rights than a remote access);
— various combinations of the properties mentioned, as well as additional ones.
# 6.1.1.4 Assessment criteria
# 6.1.1.4.1 Assessment objective
The assessment addresses the requirement ACM-1.
# 6.1.1.4.2 Implementation categories
Not applicable.
# 6.1.1.4.3 Required information
[E.Info.ACM-1.SecurityAsset]: Description of each security asset that is accessible by entities, including:
— possible entities’ accesses to the security asset on the equipment; and
(if access control by the equipment is absent for public accessibility of the security asset is the equipment’s intended functionality) [E.Info.ACM-1.SecurityAsset.PublicAccess]: Description of the equipment’s intended functionality concerning the public accessibility of the security asset; and
— (if access control by the equipment is absent because physical or logical measures in the equipment’s targeted operational environment exits, that limit accessibility to authorized entities) [E.Info.ACM-1.SecurityAsset.Environment]: Description of:
o physical or logical access control measures in the equipment’s targeted operational environment; and
o how entities are authenticated/authorized in the equipment’s targeted operational environment; and
— (if legal implications do not allow for access control mechanisms) [E.Info.ACM-1.SecurityAsset.Legal]: References to all corresponding paragraph(s) or passages in all relevant legal documents, including a description on how this is applicable for the equipment or affected asset; and
— (if access control mechanisms are claimed to be required for entities access to the security asset) [E.Info.ACM-1.SecurityAsset.ACM]: Description of each access control mechanism that manages entities’ access to the security asset.
[E.Info.ACM-1.PrivacyAsset]: Description of each privacy asset that is accessible by entities, including:
— possible entities’ accesses to the privacy asset on the equipment; and
(if access control by the equipment is absent for public accessibility of the privacy asset is the equipment’s intended functionality) [E.Info.ACM-1.PrivacyAsset.PublicAccess]: Description of the equipment’s intended functionality concerning the public accessibility of the privacy asset; and
— (if access control by the equipment is absent because physical or logical measures in the equipment’s targeted operational environment exits, that limit accessibility to authorized entities) [E.Info.ACM-1.PrivacyAsset.Environment]: Description of:
o physical or logical access control measures in the equipment’s targeted operational environment; and
o how entities are authenticated/authorized in the equipment’s targeted operational environment; and
— (if legal implications do not allow for access control mechanisms) [E.Info.ACM-1.PrivacyAsset.Legal]: References to all corresponding paragraph(s) or passages in all relevant legal documents, including a description on how this is applicable for the equipment or affected asset; and
— (if access control mechanisms are claimed to be required for entities access to the privacy asset) [E.Info.ACM-1.PrivacyAsset.ACM]: Description of each access control mechanism that manages entities’ access to the privacy asset.
[E.Info.DT.ACM-1]: Description of the selected path through the decision tree in Figure 1 for each security asset and privacy asset documented in [E.Info.ACM-1.SecurityAsset] and [E.Info.ACM-1.PrivacyAsset], respectively.
[E.Just.DT.ACM-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.ACM-1], with the following properties:
(if a decision from [DT.ACM-1.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.ACM-1.DN-1] is based on [E.Info.ACM-1.SecurityAsset.PublicAccess] or [E.Info.ACM-1.PrivacyAsset.PublicAccess]; and
(if a decision from [DT.ACM-1.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.ACM-1.DN-2] is based on [E.Info.ACM-1.SecurityAsset.Environment] or [E.Info.ACM-1.PrivacyAsset.Environment]; and
(if a decision from [DT.ACM-1.DN-3] results in “NOT APPLICABLE”) the justification for the decision [DT.ACM-1.DN-3] is based on [E.Info.ACM-1.SecurityAsset.Legal] or [E.Info.ACM-1.PrivacyAsset.Legal]; and
— the justification for the decision [DT.ACM-1.DN-4] is based on [E.Info.ACM-1.SecurityAsset.ACM] or [E.Info.ACM-1.PrivacyAsset.ACM].
# 6.1.1.4.4 Conceptual assessment
# 6.1.1.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether access control mechanisms are implemented when they are required per ACM-1.
# 6.1.1.4.4.2 Preconditions
None.
# 6.1.1.4.4.3 Assessment units
Figure 1 — Decision Tree for requirement ACM-1
For each security asset documented in [E.Info.ACM-1.SecurityAsset] and each privacy asset documented in [E.Info.ACM-1.PrivacyAsset], check whether the path through the decision tree documented in [E.Info.DT.ACM-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.ACM-1], examine its justification documented in [E.Just.DT.ACM-1].
# 6.1.1.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
at least one path through the decision tree documented in [E.Info.DT.ACM-1] ends with “PASS”; and
− no path through the decision tree documented in [E.Info.DT.ACM-1] ends with “FAIL”; and
the information provided in [E.Just.DT.ACM-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.ACM-1].
The verdict FAIL for the assessment case is assigned if:
− all path through the decision tree documented in [E.Info.DT.ACM-1] ends with “FAIL”; or
a justification provided in [E.Just.DT.ACM-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.ACM-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.1.4.5 Functional completeness assessment
# 6.1.1.4.5.1 Assessment purpose
The purpose of the functional assessment is to verify that all the security assets and privacy assets that are accessible by entities, are documented in [E.Info.ACM-1.PrivacyAsset] or [E.Info.ACM-1.SecurityAsset].
# 6.1.1.4.5.2 Preconditions
The equipment is in an operational state.
# 6.1.1.4.5.3 Assessment units
Functionally assess whether there are security assets, that are accessible by entities, in the equipment, which are not documented in [E.Info.ACM-1.SecurityAsset] and whether there are network assets, that are accessible by entities, in the equipment, which are not documented in [E.Info.ACM-1.PrivacyAsset], e.g. by inspecting all parts of the software such as built-in software, installed applications and interfaces for connected peripherals.
# 6.1.1.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if allsecurity assets that are found are documented in [E.Info.ACM-1.SecurityAsset] and all privacy assets found are documented in [E.Info.ACM-1.PrivacyAsset].
The verdict FAIL for the assessment case is assigned if a security asset that is found which is not documented in [E.Info.ACM-1.SecurityAsset] or a privacy asset is found which is not documented in [E.Info.ACM-1.PrivacyAsset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.1.4.6 Functional sufficiency assessment
# 6.1.1.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether access control mechanisms are implemented when it is required per ACM-1.
# 6.1.1.4.6.2 Preconditions
The equipment is in an operational state.
# 6.1.1.4.6.3 Assessment units
For each security asset documented in [E.Info.ACM-1.SecurityAsset] and each network asset documented in [E.Info.ACM-1.PrivacyAsset] functionally confirm the existence of access control mechanisms according to [E.Info.ACM-1.SecurityAsset.ACM] and [E.Info.ACM-1.PrivacyAsset.ACM] by accessing the assets following [E.Info.ACM-1.PrivacyAsset.PublicAccess] and [E.Info.ACM-1.SecurityAsset.PublicAccess].
# 6.1.1.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an access control mechanism documented in [E.Info.ACM-1.SecurityAsset.ACM] or [E.Info.ACM-1.PrivacyAsset.ACM] is not implemented.
The verdict FAIL for the assessment case is assigned if there is evidence that an access control mechanism documented in [E.Info.ACM-1.SecurityAsset.ACM] or [E.Info.ACM-1.PrivacyAsset.ACM] is not implemented.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.2 [ACM-2] Appropriate access control mechanisms
# 6.1.2.1 Requirement
Access control mechanisms that are required per ACM-1 shall ensure that only authorized entities have access to the protected security assets and privacy assets.
# 6.1.2.2 Rationale
Security assets and privacy assets might be exposed by unauthorized access attempts. Appropriate access control mechanisms ensure these assets are protected from unauthorized access.
# 6.1.2.3 Guidance
This requirement is intended to ensure that the access control mechanisms used to protect the relevant security assets and privacy assets are chosen and configured such that unauthorized access is denied. With a variety of asset access methods and control mechanisms (for instance display on a wearable’s screen), equipment use-cases and operational environments, it is difficult to specify a generic model for entities and associated access rights.
Whether an access control mechanism can deny unauthorized access, always depends on external assumptions that need to be fulfilled. For example, that the sharing of passwords or unauthorized physical access are not permitted.
Depending on the equipment’s technical properties, intended operational environment of use, the access control mechanisms use appropriate properties to tie access rights to and that all involved entities are provided with authorization information.
When access control mechanisms rely on authentication mechanisms, see AUM, for example:
— an authorized entity, e.g., specific human, owner of a user account, device or service, can after authentication access their security asset or privacy asset, such as changing security configuration; or
— a member of specific authorized groups can after authentication access a security assert or privacy asset; or
— an entity, authorized by another entity authorized to do so, can access a specific security asset or privacy asset.
For the determination of the appropriate access control mechanisms on security assets and privacy assets the following aspects are important:
— the risk associated with an entity’s access to a security asset or privacy asset,
— the form of access an equipment’s functionality allows to a security asset or privacy asset,
— the interface the security asset or privacy asset is accessed through and
— the impact of access control provided by the intended operational environment of use.
For the determination of entities’ access rights on security assets or privacy assets (authorized entities for certain access on assets), the following aspects are important:
— the risk associated with an entity’s access to a security asset or privacy asset,
— the “need-to-know principle”: Does an entity need to obtain some information from a security asset or privacy asset,
— the “need-to-use principle”: Does an entity have a valid need to use a functionality based on a security asset or privacy asset,
— the “least privileges principle”: everything is forbidden unless permitted
— the equipment’s clearly advertised functionality e.g., concerning accessibility of security assets or privacy assets or interoperability with components of an existing infrastructure.
For determining children’s access rights to privacy assets or, other entities' access rights to children’s privacy assets, the needs and capabilities of children are important aspects to be taken into account.
Moreover, in the case of the usage of potentially privacy compromising access rights, the equipment might depend on its capabilities and the intended equipment functionality, provide functionality to make the user aware of the execution of such access rights (for instance a symbol is displayed on a screen when the equipment’s voice recording or geolocation functionality is used by an application).
# 6.1.2.4 Assessment criteria
# 6.1.2.4.1 Assessment objective
The assessment addresses the requirement ACM-2.
# 6.1.2.4.2 Implementation categories
[IC.ACM-2.RBAC]: The methods to validate the appropriateness of the access control mechanism solely rely on role-based access control.
[IC.ACM-2.DAC]: The methods to validate the appropriateness of the access control mechanism solely rely on discretionary access control.
[IC.ACM-2.MAC]: The methods to validate the appropriateness of the access control mechanism solely rely on mandatory access control.
[IC.ACM-2.Generic]: The methods to validate the appropriateness of the access control mechanism do not solely rely on any of the methods described in ACM-2-RBAC, ACM-2-DAC or ACM-2-MAC.
# 6.1.2.4.3 Required information
[E.Info.ACM-2.SecurityAsset]: Description of each security asset for which ACM-1 requires access control mechanisms, including:
[E.Info.ACM-2.SecurityAsset.ACM]: Description of the access control mechanisms required per ACM-1 that manages entities' access to the security asset and of how the mechanisms ensure that only authorized entities have access to the security asset based on the implementation category.
[E.Info.ACM-2.PrivacyAsset]: Description of each privacy asset for which ACM-1 requires access control mechanisms, including:
[E.Info.ACM-2.PrivacyAsset.ACM]: Description of the access control mechanisms required per ACM-1 that manages entities' access to the privacy asset and of how the mechanisms ensure that only authorized entities have access to the privacy asset based on the implementation category.
[E.Info.DT.ACM-2]: Description of the selected path through the decision tree in Figure 2 for each security asset documented in [E.Info.ACM-2.SecurityAsset] and privacy asset documented in [E.Info.ACM-2.PrivacyAsset] .
[E.Just.DT.ACM-2]: Justification for the selected path through the decision tree documented in [E.Info.DT.ACM-2], with the following property:
— the justification for the decision [DT.ACM-2.DN-1] is based on [E.Info.ACM-2.PrivacyAsset.ACM] or [E.Info.ACM-2.SecurityAsset.ACM].
NOTE A justification includes a description of the entities, their access rights on the respective security asset or privacy asset and means how the access control mechanisms ensure that only authorised access to the respective asset is granted.
# 6.1.2.4.4 Conceptual assessment
# 6.1.2.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the access control mechanisms that are required per ACM-1 are implemented as required per ACM-2.
# 6.1.2.4.4.2 Preconditions
None.
# 6.1.2.4.4.3 Assessment units
Figure 2 — Decision Tree for requirement ACM-2
For each security asset documented in [E.Info.ACM-2.SecurityAsset] and each privacy asset documented in [E.Info.ACM-2.PrivacyAsset], check whether the path through the decision tree documented in [E.Info.DT.ACM-2] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.ACM-2], examine its justification documented in [E.Just.DT.ACM-2].
# 6.1.2.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.ACM-2] end with “PASS”; and
— the information provided in [E.Just.DT.ACM-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.ACM-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.ACM-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.ACM-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.ACM-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.2.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the access control mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.1.2.4.6 Functional sufficiency assessment
# 6.1.2.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the access control mechanisms are implemented as required per ACM-2.
# 6.1.2.4.6.2 Assessment units
For each security asset documented in [E.Info.ACM-2.SecurityAsset] and privacy asset documented in [E.Info.ACM-2.PrivacyAsset]:
[AU.ACM-2.RBAC]: If the access control mechanisms documented in [E.Info.ACM-2.SecurityAsset.ACM] or [E.Info.ACM-2.PrivacyAsset.ACM] belong to [IC.ACM-2.RBAC]), functionally confirm that:
— roles are assigned to each user with associated authorization; and
— least privileges are associated with the roles; and
— the security asset or privacy asset is only accessible by authorized users given by their role; and
— changes in roles can only be performed by authorized users.
[AU.ACM-2.DAC]: If the access control mechanisms documented in [E.Info.ACM-2.SecurityAsset.ACM] or [E.Info.ACM-2.PrivacyAsset.ACM] belong to [IC.ACM-2.DAC], functionally confirm that:
— identities are assigned to each user with associated authorization; and
— least privileges are associated with the identities; and
— the security asset or privacy asset is only accessible by authorized users given by their identity; and
— changes in identities can only be performed by authorized users.
[AU.ACM-2.MAC]: If the access control mechanisms documented in [E.Info.ACM-2.SecurityAsset.ACM] or [E.Info.ACM-2.PrivacyAsset.ACM] belong to [IC.ACM-2.MAC], functionally confirm that:
— the security asset or privacy asset is only accessible by authorized users after clearance was issued by the operating system and/or system administrator; and
— the issuance of clearance is associated with the principle of least privileges; and
— changing the operating system and/or system administrator that is responsible for the issuance of clearance to the user can only be performed by the authorized system administrator.
[AU.ACM-2.Generic]: If the access control mechanisms documented in [E.Info.ACM-2.SecurityAsset.ACM] or [E.Info.ACM-2.PrivacyAsset.ACM] belong to [IC.ACM-2.Generic], functionally confirm that:
— the security asset or privacy asset is only accessible by authorized users; and
— the principle of least privileges for users is followed; and
— changing settings related to the access control mechanism or changes of privileges of users are only allowed to be performed by authorized users.
# 6.1.2.4.6.3 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each security asset documented in [E.Info.ACM-2.SecurityAsset] and privacy asset documented in [E.Info.ACM-2.PrivacyAsset] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for any security asset documented in [E.Info.ACM-2.SecurityAsset] or privacy asset documented in [E.Info.ACM-2.PrivacyAsset] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.3 [ACM-3] Default access control for children in toys
# 6.1.3.1 Requirement
If the equipment is a toy, for each privacy function where children can access external content and children’s access is managed by access control mechanisms required per ACM-1, the access control mechanisms shall by default ensure that children’s access to external content via the privacy function is restricted to content from authorized entities.
# 6.1.3.2 Rationale
Content from external sources that is accessed by children can be used for unauthorized communication, interaction or otherwise compromise the children’s privacy. Restricting children’s access by default to authorized entities only, supports avoiding related hazards.
# 6.1.3.3 Guidance
Privacy functions that allow children to access content can amongst others be:
— chat functions,
— voice or video call functions,
— functions that display content from external sources.
In order to ensure that children’s default access to content from external sources is restricted to content from authorized entities, it is amongst others possible:
— to deny all children’s access to external sources; or
— to deny all children’s access to external sources, unless it is explicitly on a allow-list which is created after ensuring that it contains only access to content from authorized entities.
# 6.1.3.4 Assessment criteria
# 6.1.3.4.1 Assessment objective
The assessment addresses the requirement ACM-3.
# 6.1.3.4.2 Implementation categories
[IC.ACM-3.RBAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-3.ACM] solely rely on role-based access control and ensure that children’s access to external content via the privacy function, is restricted to content from authorized entities.
[IC.ACM-3.DAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-3.ACM] solely rely on discretionary access control and ensure that children’s access to external content via the privacy function, is restricted to content from authorized entities.
[IC.ACM-3.MAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-3.ACM] solely rely on mandatory access control and ensure that children’s access to external content via the privacy function, is restricted to content from authorized entities.
[IC.ACM-3.Generic]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-3.ACM] do not solely rely on any of the methods described in ACM-3-RBAC, ACM-3-DAC or ACM-3-MAC and ensure that children’s access to external content via the privacy function, is restricted to content from authorized entities.
# 6.1.3.4.3 Required information
[E.Info.ACM-3.PrivacyAsset]: Description of each privacy function where children can access external content, including:
— [E.Info.ACM-3.PrivacyAsset.TrustedSources]: List of authorized entities providing external content suitable for children.
[E.Info.ACM-3.ACM]: Description of each access control mechanism that is required per ACM-1 and that manages children’s access for each privacy function documented in [E.Info.ACM-3.PrivacyAsset], including:
— Description on how the restriction of children’s access to content from authorized entities only is implemented.
[E.Info.DT.ACM-3]: Description of the selected path through the decision tree in Figure 3 for each privacy function where children’s access is managed by access control mechanisms documented in [E.Info.ACM-3.ACM].
[E.Just.DT.ACM-3]: Justification for each selected path through the decision tree for each privacy function where children’s access is managed by access control mechanisms documented in [E.Info.DT.ACM-3] with the following property:
— the justification [DT.ACM-3.DN-2] is based on [E.Info.ACM-3.ACM] and [E.Info.ACM-3.PrivacyAsset.TrustedSources].
# 6.1.3.4.4 Conceptual assessment
# 6.1.3.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the access control mechanisms for children’s access on privacy functions are implemented as required per ACM-3.
# 6.1.3.4.4.2 Preconditions
None.
# 6.1.3.4.4.3 Assessment units
Figure 1 — Decision Tree for requirement ACM-3
For each privacy function where children can access external content as documented in [E.Info.ACM-3.PrivacyAsset] and where access is managed by access control mechanisms according to [E.Info.ACM-3.ACM], check whether the path through the decision tree documented in [E.Info.DT.ACM-3] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.ACM-3], examine its justification documented in [E.Just.DT.ACM-3].
# 6.1.3.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.ACM-3] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.ACM-3] ends with “FAIL”; and
— the information provided in [E.Just.DT.ACM-3] are correct justifications for all paths through the decision tree documented in [E.Info.DT.ACM-3].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.ACM-3] ends with “FAIL”; or
— a justification provided in [E.Just.DT.ACM-3] is not correct or missing for a path through the decision tree documented in [E.Info.DT.ACM-3].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.3.4.5 Functional completeness assessment
# 6.1.3.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the documentation of privacy functions where children can access external content is complete.
# 6.1.3.4.5.2 Preconditions
The equipment is in an operational state.
# 6.1.3.4.5.3 Assessment units
Functionally assess whether there are privacy functions that allow children to access external content, which are not listed in [E.Info.ACM-3.PrivacyAsset] by performing the following steps:
1) List all equipment’s privacy functions where children can access external content, e.g., by inspecting all parts of the software such as checking the internet browser settings, examining the app store access, inspect installed apps, investigate built-in or installed parental controls.
2) Compare the list from step 1 of functionally identified privacy functions with the list of privacy functions given by [E.Info.ACM-3.PrivacyAsset] and highlight any mismatch.
# 6.1.3.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all discovered privacy functions, where children can access external content, are documented in [E.Info.ACM-3.PrivacyAsset].
The verdict FAIL for the assessment case is assigned if one discovered privacy function, where children can access external content, is not documented in [E.Info.ACM-3.PrivacyAsset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.3.4.6 Functional sufficiency assessment
# 6.1.3.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether by default the access control mechanisms ensure that children’s access to external content via the privacy function, is restricted to content from authorized entities.
# 6.1.3.4.6.2 Preconditions
The equipment is in an operational state.
# 6.1.3.4.6.3 Assessment units
[AU.ACM-3.RBAC]: If the access control mechanisms documented in [E.Info.ACM-3.ACM] belong to [IC.ACM-3.RBAC]), functionally confirm that:
— children are assigned to associated roles that only allow to access content from authorized entities via the privacy function that allows access to external content; and
— least privileges are associated with the children’s role; and
— changes in roles can only be performed by authorized users.
[AU.ACM-3.DAC]: If the access control mechanisms documented in [E.Info.ACM-3.ACM] belong to [IC.ACM-3.DAC]), functionally confirm that:
— children are assigned to associated identities that only allow to access content from authorized entities via the privacy function that allows access to external content; and
— least privileges are associated with the children’s identity; and
— changes in identities can only be performed by authorized users.
[AU.ACM-3.MAC]: If the access control mechanisms documented in [E.Info.ACM-3.ACM] belong to [IC.ACM-3.MAC]), functionally confirm that:
— children are only issued with clearance by the operating system and/or system administrator when trying to access content from authorized entities via the privacy function that allows access to external content; and
— the issuance of clearance is associated with the principle of least privileges; and
— changing the operating system and/or system administrator that is responsible for the issuance of clearance to the user can only be performed by the authorized system administrator.
[AU.ACM-3.Generic]: If the access control mechanisms documented in [E.Info.ACM-3.ACM] belong to [IC.ACM-3.Generic]), functionally confirm that:
— children can only access content from authorized entities via the privacy function that allows access to external content; and
— the principle of least privileges for children is followed; and
— changing settings related to the access control mechanism or changes of privileges of children are only allowed to be performed by authorized users.
# 6.1.3.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each access control mechanism documented in [E.Info.ACM-3.ACM] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for an access control mechanism documented in [E.Info.ACM-3.ACM] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.4 [ACM-4] Default access control to children’s privacy assets for toys and childcare equipment
# 6.1.4.1 Requirement
If the equipment is a toy or childcare equipment, any children’s privacy function and personal information access control mechanisms required per ACM-1 shall by default restrict, apart from the child’s or their parental/guardians, any third-party access to the children’s privacy function and personal information processed by the equipment, except for authorised accesses which are required for the equipment’s intended functionality.
# 6.1.4.2 Rationale
Exposing privacy functions or personal information to third parties by default can compromise children’s privacy, even when consent is given. Restricting third parties’ default access rights to children’s privacy function and personal information to that are necessary for the operation of the equipment, supports privacy protection.
# 6.1.4.3 Guidance
If privacy assets are protected by several access control mechanisms, the default configuration of all these access control mechanisms can contribute to the privacy assets’ default accessibility.
It might be necessary for external entities such as cloud services in control of the equipment’s manufacturer to access children’s personal information, for the equipment’s intended functionality. An example is a child watch where parents can track the location history of the watch which is recorded on a cloud service independent of the watches current network connectivity status.
With children being vulnerable to cyber-crime, designers of default settings are strongly advised to consider the best interests of children.
# 6.1.4.4 Assessment criteria
# 6.1.4.4.1 Assessment objective
The assessment addresses the requirement ACM-4.
# 6.1.4.4.2 Implementation categories
[IC.ACM-4.RBAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-4.ACM] solely rely on role-based access control and ensure that other entities’ third-parties’ access to the children’s privacy function and personal information processed by the equipment privacy assets is restricted to the necessary for the operation of the equipment.
[IC.ACM-4.DAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-4.ACM] solely rely on discretionary access control and ensure that other entities’ thirdparties’ access to the children’s privacy function and personal information processed by the equipment privacy assets is restricted to the necessary for the operation of the equipment.
[IC.ACM-4.MAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-4.ACM] solely rely on mandatory access control and ensure that other entities’ thirdparties’ access to the children’s privacy function and personal information processed by the equipment privacy assets is restricted to the necessary for the operation of the equipment.
[IC.ACM-4.Generic]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-4.ACM] do not solely rely on any of the methods described in ACM-4-RBAC, ACM-4-DAC or ACM-4-MAC and ensure that other entities’ third-parties’ access to the children’s privacy function and personal information processed by the equipment privacy assets is restricted to the necessary for the operation of the equipment.
# 6.1.4.4.3 Required information
[E.Info.ACM-4.PrivacyAsset]: Description of each children’s privacy function and personal information processed by the equipment which can be accessed by entities other than the children or their parents/guardians.
[E.Info.ACM-4.ACM]: Description of each access control mechanism that is required per ACM-1 and that manages third-parties other than the children or their parents’/guardians’ access, for each children’s privacy function and personal information processed by the equipment, including:
— description on how third-party accesses are managed in the default configuration; and
— description on how restrictions on third-party accesses are implemented; and
(if authorised accesses which are required for the equipment’s intended functionality) [E.Info.ACM-4.AuthorisedAccess]: List of all authorised third-parties, including:
— List of all assets documented in [E.Info.ACM-4.PrivacyAsset] that can be accessed by the third party for each authorised third-party; and
— description on how the equipment’s intended functionality depends on the authorised access of affected assets documented in [E.Info.ACM-4.PrivacyAsset] for each authorised third-party.
[E.Info.DT.ACM-4]: Description of the selected path through the decision tree in Figure 4 for each of the children’s privacy function and personal information processed by the equipment documented in [E.Info.ACM-4.PrivacyAsset], where access for third-parties other than the children or their parents or guardians, is managed by access control mechanisms documented in [E.Info.ACM-4.ACM].
[E.Just.DT.ACM-4]: Justification for each selected path through the decision tree documented in [E.Info.DT.ACM-4] with the following properties:
— (if a decision from [DT.ACM-4.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.ACM-4.DN-2] is based on [E.Info.ACM-4.AuthorisedAccess]; and
— the justification for the decision [DT.ACM-4.DN-3] is based on [E.Info.ACM-4.ACM].
# 6.1.4.4.4 Conceptual assessment
# 6.1.4.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the access control mechanisms are implemented as required per ACM-4.
# 6.1.4.4.4.2 Preconditions
None.
# 6.1.4.4.4.3 Assessment units
Figure 4 — Decision Tree for requirement ACM-4
For children’s privacy function and personal information processed by the equipment which can be accessed by third-parties, other than the children or their parents/guardians documented in [E.Info.ACM-4.PrivacyAsset] and where access is managed by access control mechanisms according to [E.Info.ACM-4.ACM], check whether the path through the decision tree documented in [E.Info.DT.ACM-4] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.ACM-4], examine its justification documented in [E.Just.DT.ACM-4].
# 6.1.4.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
-at least one path through the decision tree documented in [E.Info.DT.ACM-4] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.ACM-4] ends with “FAIL”; and
— the information provided in [E.Just.DT.ACM-4] are correct justifications for all paths through the decision tree documented in [E.Info.DT.ACM-4].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.ACM-4] ends with “FAIL”; or
— a justification provided in [E.Just.DT.ACM-4] is not correct or missing for a path through the decision tree documented in [E.Info.DT.ACM-4].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.4.4.5 Functional completeness assessment
# 6.1.4.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the documentation of children’s privacy function and personal information processed by the equipment which can be accessed by third-parties other than the children or their parents/guardians, is complete.
# 6.1.4.4.5.2 Preconditions
The equipment is in an operational state.
# 6.1.4.4.5.3 Assessment units
Functionally assess whether there are children’s privacy function and personal information on the equipment which can be accessed by third-parties other than the children or their parents/guardians., which are not listed in [E.Info.ACM-4.PrivacyAsset] by performing the following steps:
1) List all equipment’s children’s privacy functions and personal information on the equipment which can be accessed by third-parties other than the children or their parents/guardians, e.g. by inspecting all parts of the software such as checking the internet browser settings, examining the app store access, inspect installed apps, investigate built-in or installed parental controls.
2) Compare the list from step 1 with the list given by [E.Info.ACM-4.PrivacyAsset] and highlight any privacy function or personal information on the equipment that has been identified/found and that is not listed in [E.Info.ACM-4.PrivacyAsset].
# 6.1.4.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all the children’s privacy function and personal information processed by the equipment which can be accessed by third-parties other than the children or their parents/ guardians, are documented in [E.Info.ACM-4.PrivacyAsset].
The verdict FAIL for the assessment case is assigned if a discovered children’s privacy function and personal information processed by the equipment which can be accessed by third-parties other than the children or their parents/ guardians, is not documented in [E.Info.ACM-4.PrivacyAsset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.4.4.6 Functional sufficiency assessment
# 6.1.4.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether by default the access control mechanisms ensure that other entities’ third-parties’ access to the children’s privacy function and personal information processed by the equipment privacy assets is restricted to the necessary for the operation of the equipment.
# 6.1.4.4.6.2 Assessment units
[AU.ACM-4.RBAC]: If the access control mechanisms documented in [E.Info.ACM-4.ACM] belong to [IC.ACM-4.RBAC]), functionally confirm that, functionally confirm that:
— other entities’ third-parties’ are assigned to associated roles that restrict access to the children’s privacy function and personal information processed by the equipment’s privacy assets to the necessary for the operation of the equipment; and
— least privileges are associated with the other entities’ third-parties’ role; and
— changes in roles can only be performed by authorized users.
[AU.ACM-4.DAC]: If the access control mechanisms documented in [E.Info.ACM-4.ACM] belong to [IC.ACM-4.DAC]), functionally confirm that:
— other entities’ third-parties’ are assigned to associated identities that restrict access to the children’s privacy function and personal information processed by the equipment’s privacy assets to the necessary for the operation of the equipment; and
— least privileges are associated with the other entities’ third-parties’ identity; and
— changes in identities can only be performed by authorized users.
[AU.ACM-4.MAC]: If the access control mechanisms documented in [E.Info.ACM-4.ACM] belong to [IC.ACM-4.MAC]), functionally confirm that:
other entities’ third-parties’ that want to access to the children’s privacy function and personal information processed by the equipment’s privacy assets are only issued with clearance by the operating system and/or system administrator if necessary for the operation of the equipment; and
— the issuance of clearance is associated with the principle of least privileges; and
— changing the operating system and/or system administrator that is responsible for the issuance of clearance to the user can only be performed by the authorized system administrator.
[AU.ACM-4.Generic]: If the access control mechanisms documented in [E.Info.ACM-4.ACM] belong to [IC.ACM-4.Generic]), functionally confirm that:
— other entities’ third-parties’ can only access children’s privacy function and personal information processed by the equipment’s privacy assets if necessary for the operation of the equipment; and
— the principle of least privileges for other entities’ third-parties is followed; and
— changing settings related to the access control mechanism or changes of privileges of other entities’ third-parties’ are only allowed to be performed by authorized users.
# 6.1.4.4.6.3 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each access control mechanism documented in [E.Info.ACM-4.ACM] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for an access control mechanism documented in [E.Info.ACM-4.ACM] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.5 [ACM-5] Parental/Guardian access controls for children in toys
# 6.1.5.1 Requirement
If the equipment is a toy, for each security and privacy asset that is accessible by children, any access control mechanism required per ACM-1 managing the children’s access, shall be configurable by an authorized entity to restrict children’s access to the protected security and privacy assets.
# 6.1.5.2 Rationale
Bearing in mind protection needs and evolving capacities of children, especially to judge the consequences of privacy and security configuration, it is necessary that parents or guardians can limit the possible access to security and privacy assets of their children, in order to avoid any hazard related to their privacy.
# 6.1.5.3 Guidance
The requirement demands that children’s access to security and privacy assets can be restricted by an authorized entity typically represented by the children’s parents or guardians.
For example, when the ability to pair a toy using a short-range wireless technology interface with a mobile phone can be controlled by a parent/guardian they can avoid that that the children initiate a pairing with malicious intent. However, a parent/ guardians could give a child the permission to initiate a pairing with a mobile phone.
It is important that access control configuration by parents/guardians can be done easily.
# 6.1.5.4 Assessment criteria
# 6.1.5.4.1 Assessment objective
The assessment addresses the requirement ACM-5.
# 6.1.5.4.2 Implementation categories
[IC.ACM-5.RBAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-5.ACM] solely rely on role-based access control and are configurable by an authorized entity to restrict children’s access to the security assets and privacy assets that are accessible by children.
[IC.ACM-5.DAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-5.ACM] solely rely on discretionary access control and are configurable by an authorized entity to restrict children’s access to the security assets and privacy assets that are accessible by children.
[IC.ACM-5.MAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-5.ACM] solely rely on mandatory access control and are configurable by an authorized entity to restrict children’s access to the security assets and privacy assets that are accessible by children.
[IC.ACM-5.Generic]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-5.ACM] do not solely rely on any of the methods described in ACM-5-RBAC, ACM-5-DAC or ACM-5-MAC and are configurable by an authorized entity to restrict children’s access to the security assets and privacy assets that are accessible by children.
# 6.1.5.4.3 Required information
[E.Info.ACM-5.SecurityAsset]: Description of each security asset that is accessible by children.
[E.Info.ACM-5.PrivacyAsset]: Description of each privacy asset that is accessible by children.
[E.Info.ACM-5.ACM]: Description of each access control mechanism that is required per ACM-1 and that manages children’s access for each security asset documented in [E.Info.ACM-5.SecurityAsset] and privacy asset documented in [E.Info.ACM-5.PrivacyAsset] processed by the equipment, including:
— Description on how an entity is authorized to restrict children’s access to the protected security and privacy assets; and
— description on how these restrictions are implemented.
[E.Info.DT.ACM-5]: Description of the selected path through the decision tree in Figure 5 for each security asset and privacy asset where children’s access is managed by access control mechanisms documented in [E.Info.ACM-5.ACM].
[E.Just.DT.ACM-5]: Justification for each selected path through the decision tree documented in [E.Info.DT.ACM-5] with the following property:
— the justification for the decision [DT.ACM-5.DN-2] is based on [E.Info.ACM-5.ACM].
# 6.1.5.4.4 Conceptual assessment
# 6.1.5.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the access control mechanisms managing the children’s access are configurable by an authorized entity to restrict children’s access to the managed security assets and privacy assets.
# 6.1.5.4.4.2 Preconditions
None.
# 6.1.5.4.4.3 Assessment units
Figure 5 — Decision Tree for requirement ACM-5
For each security asset and privacy asset which can be accessed by children as documented in [E.Info.ACM-5.SecurityAsset] and [E.Info.ACM-5.PrivacyAsset] and where children’s access is managed by access control mechanisms according to [E.Info.ACM-5.ACM] check whether the path through the decision tree documented in [E.Info.DT.ACM-5] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.ACM-5], examine its justification documented in [E.Just.DT.ACM-5].
# 6.1.5.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.ACM-5] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.ACM-5] ends with “FAIL”; and
— the information provided in [E.Just.DT.ACM-5] are correct justifications for all paths through the decision tree documented in [E.Info.DT.ACM-5].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.ACM-5] ends with “FAIL”; or
— a justification provided in [E.Just.DT.ACM-5] is not correct or missing for a path through the decision tree documented in [E.Info.DT.ACM-5].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.5.4.5 Functional completeness assessment
# 6.1.5.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the documentation of security asset and privacy assets that are accessible by children is complete.
# 6.1.5.4.5.2 Preconditions
The equipment is in an operational state.
# 6.1.5.4.5.3 Assessment units
Functionally assess whether there are security assets that are accessible by children, which are not documented in [E.Info.ACM-5.SecurityAsset] and whether there are privacy assets that are accessible by children, which are not documented in [E.Info.ACM-5.PrivacyAsset] by performing the following steps:
1) List all security assets and privacy assets that are accessible by children, e.g., by examining installed apps, check internet and browser settings, inspect app store access, analyse parental control settings, assess data sharing and storage.
2) Compare the list from step 1 with the list given by [E.Info.ACM-5.SecurityAsset] and [E.Info.ACM-5.PrivacyAsset] and highlight any security asset or privacy asset on the equipment that has been identified/found and that is neither listed in [E.Info.ACM-5.PrivacyAsset] nor in [E.Info.ACM-5.SecurityAsset].
# 6.1.5.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all discovered security assets that are accessible by children, are documented in [E.Info.ACM-5.SecurityAsset] and all discovered privacy assets that are accessible by children, are documented in [E.Info.ACM-5.PrivacyAsset].
The verdict FAIL for the assessment case is assigned if discovered security assets that are accessible by children, are not documented in [E.Info.ACM-5.SecurityAsset] or if discovered privacy assets that are accessible by children, are not documented in [E.Info.ACM-5.PrivacyAsset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.5.4.6 Functional sufficiency assessment
# 6.1.5.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether security assets and privacy asset that are accessible by children and where children’s access is managed by access control mechanisms are configurable by an authorized entity to restrict children’s access.
# 6.1.5.4.6.2 Assessment units
[AU.ACM-5.RBAC]: If the access control mechanisms documented in [E.Info.ACM-5.ACM] belong to [IC.ACM-5.RBAC]), functionally confirm that:
— all users are assigned to associated roles; and
— least privileges are associated with users’ roles so that only an authorized entity is able to configure the role-based access control mechanisms to restrict children’s access to the managed security assets and privacy assets, as justified in [E.Just.DT.ACM-5]; and
— changes in roles can only be performed by authorized users.
[AU.ACM-5.DAC]: If the access control mechanisms documented in [E.Info.ACM-5.ACM] belong to [IC.ACM-5.DAC]), functionally confirm that:
— all users are assigned to associated identities; and
least privileges are associated with users’ identities so that only an authorized entity is able to configure the discretionary access control mechanisms to restrict children’s access to the managed security assets and privacy assets, as justified in [E.Just.DT.ACM-5]; and
— changes in identities can only be performed by authorized users.
[AU.ACM-5.MAC]: If the access control mechanisms documented in [E.Info.ACM-5.ACM] belong to [IC.ACM-5.MAC]), functionally confirm that:
— All users are only issued with clearance by the operating system and/or system administrator to configure the mandatory access control to restrict children’s access to the managed security assets and privacy assets, as justified in [E.Just.DT.ACM-5], if this user is an authorized user; and
— the issuance of clearance is associated with the principle of least privileges; and
— changing the operating system and/or system administrator that is responsible for the issuance of clearance to the user can only be performed by the authorized system administrator.
[AU.ACM-5.Generic]: If the access control mechanisms documented in [E.Info.ACM-4.ACM] belong to [IC.ACM-4.RBAC]), functionally confirm that:
— users are only allowed to configure access control mechanisms to restrict children’s access to the managed security assets and privacy assets if this user is an authorized user; and
— the principle of least privileges for all users is followed; and
— changing settings related to the access control mechanism or changes of privileges of users are only allowed to be performed by authorized users.
# 6.1.5.4.6.3 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each access control mechanism documented in [E.Info.ACM-5.ACM] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for an access control mechanism documented in [E.Info.ACM-5.ACM] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.6 [ACM-6] Parental/Guardian access controls for other entities’ access to managed children’s privacy assets in toys
# 6.1.6.1 Requirement
If the equipment is a toy, for each children’s privacy asset that is accessible by entities, other than the children or their parents or guardians, and where those other entities’ access is managed by access control mechanisms required per ACM-1, the access control mechanisms shall be configurable by an authorized entity to restrict the other entities’ access to the managed children’s privacy assets.
# 6.1.6.2 Rationale
Bearing in mind the protection needs and evolving capacities of children, it is necessary that parents or guardians can limit entities’ access to children’s privacy assets, in order to avoid any hazard related to their privacy.
# 6.1.6.3 Guidance
The requirement demands that entities’ access to children’s privacy assets can be restricted by an authorized entity, who is typically represented by the children’s parents or guardians.
For example, parents/guardians can limit the access of third parties and other potentially malicious actors, who could remotely access the equipment functionality, for observation, remote communication or control and other related hazards for children.
It is important that access control configuration by guardians can be done easily.
# 6.1.6.4 Assessment criteria
# 6.1.6.4.1 Assessment objective
The assessment addresses the requirement ACM-6.
# 6.1.6.4.2 Implementation categories
[IC.ACM-6.RBAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-6.ACM] solely rely on role-based access control and whether this underlying access control, that manages access to children’s privacy assets that are accessible by entities other than the children or their parents or guardians, is configurable by an authorized entity.
[IC.ACM-6.DAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-6.ACM] solely rely on discretionary access control and whether this underlying access control, that manages access to children’s privacy assets that are accessible by entities other than the children or their parents or guardians, is configurable by an authorized entity.
[IC.ACM-6.MAC]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-6.ACM] solely rely on mandatory access control and whether this underlying access control, that manages access to children’s privacy assets that are accessible by entities other than the children or their parents or guardians, is configurable by an authorized entity.
[IC.ACM-6.Generic]: The methods to validate whether by default the access control mechanisms documented in [E.Info.ACM-6.ACM] do not solely rely on any of the methods described in ACM-6-RBAC, ACM-6-DAC or ACM-6-MAC and whether this underlying access control, that manages access to children’s privacy assets that are accessible by entities other than the children or their parents or guardians, is configurable by an authorized entity.
# 6.1.6.4.3 Required information
[E.Info.ACM-6.PrivacyAsset]: Description of each children’s privacy asset that is accessible by entities, other than the children or their parents or guardians.
[E.Info.ACM-6.ACM]: Description of each access control mechanism that is required per ACM-1 and that manages entities, other than the children or their parents or guardians, access to children’s privacy assets documented in [E.Info.ACM-6.PrivacyAsset], including:
— Description on how entities are authorised to configure the access control mechanism to restrict other entities access to the managed children’s privacy assets; and
— description on how the restrictions to access the managed children’s privacy assets are implemented.
[E.Info.DT.ACM-6]: Description of the selected path through the decision tree in Figure 6 for each children’s privacy asset that is accessible by entities, other than the children or their parents or guardians documented in [E.Info.ACM-6.PrivacyAsset] and where the other entities’ access is managed by access control mechanisms documented in [E.Info.ACM-6.ACM].
[E.Just.DT.ACM-6]: Justification for each selected path through the decision tree documented in [E.Info.DT.ACM-6] with the following property:
— the justification for the decision [DT.ACM-6.DN-2] is based on [E.Info.ACM-6.ACM].
# 6.1.6.4.4 Conceptual assessment
# 6.1.6.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the access control mechanisms are configurable by an authorized entity to restrict other entities’ access to the managed children’s privacy assets.
# 6.1.6.4.4.2 Preconditions
None.
# 6.1.6.4.4.3 Assessment units
Figure 6 — Decision Tree for requirement ACM-6
For each children’s privacy asset that is accessible by entities, other than the children or their parents or guardians, documented in [E.Info.ACM-6.PrivacyAsset] and where the other entities’ access is managed by access control mechanisms according to [E.Info.ACM-6.ACM], check whether the path through the decision tree documented in [E.Info.DT.ACM-6] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.ACM-6], examine its justification documented in [E.Just.DT.ACM-6].
# 6.1.6.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.ACM-6] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.ACM-6] ends with “FAIL”; and
— the information provided in [E.Just.DT.ACM-6] are correct justifications for all paths through the decision tree documented in [E.Info.DT.ACM-6].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.ACM-6] ends with “FAIL”; or
— a justification provided in [E.Just.DT.ACM-6] is not correct or missing for a path through the decision tree documented in [E.Info.DT.ACM-6].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.6.4.5 Functional completeness assessment
# 6.1.6.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the documentation of children’s privacy assets documented in [E.Info.ACM-6.PrivacyAsset] that are accessible by entities, other than the children or their parents or guardians, is complete.
# 6.1.6.4.5.2 Preconditions
The equipment is in an operational state.
# 6.1.6.4.5.3 Assessment units
Functionally assess whether there are children’s privacy assets that are accessible by entities, other than the children or their parents or guardians, which are not documented in [E.Info.ACM-6.PrivacyAsset] by performing the following steps:
1) List all privacy assets that are accessible by entities, other than the children or their parents or guardians, e.g., by examining app permissions and their terms and privacy policies, review network and internet connections, inspect equipment settings, review web browser history and settings, check potential data access points such as photo libraries, location logs, communication and social media apps.
2) Compare the list from step 1 with the list given by [E.Info.ACM-6.PrivacyAsset] and highlight any privacy asset on the equipment that has been identified/found and that is not listed in [E.Info.ACM-6.PrivacyAsset].
# 6.1.6.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all discovered children’s privacy assets that are accessible by entities, other than the children or their parents or guardians, are documented in [E.Info.ACM-6.PrivacyAsset].
The verdict FAIL for the assessment case is assigned if a discovered children’s privacy asset that is accessible by entities, other than the children or their parents or guardians, is not documented in [E.Info.ACM-6.PrivacyAsset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.1.6.4.6 Functional sufficiency assessment
# 6.1.6.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether children’s privacy assets that are accessible by entities, other than the children or their parents or guardians, are managed by access control mechanisms that are configurable by an authorized entity to restrict other entities’ access.
# 6.1.6.4.6.2 Assessment units
[AU.ACM-6.RBAC]: If the access control mechanisms documented in [E.Info.ACM-6.ACM] belong to [IC.ACM-6.RBAC]), functionally confirm that :
— all users are assigned to associated roles; and
— least privileges are associated with users’ roles so that only an authorized entity is able to configure the role-based access control mechanisms to restrict the other entities’ access to the managed children’s privacy assets, as justified in [E.Just.DT.ACM-6]; and
— changes in roles can only be performed by authorized users.
[AU.ACM-6.DAC]: If the access control mechanisms documented in [E.Info.ACM-6.ACM] belong to [IC.ACM-6.DAC]), functionally confirm that:
— All users are assigned to associated identities; and
— least privileges are associated with users’ identities so that only an authorized entity is able to configure the discretionary access control mechanisms to restrict access to the other entities’ access to the managed children’s privacy assets, as justified in [E.Just.DT.ACM-6]; and
— changes in identities can only be performed by authorized users.
[AU.ACM-6.MAC]: If the access control mechanisms documented in [E.Info.ACM-6.ACM] belong to [IC.ACM-6.MAC]), functionally confirm that:
users are only issued with clearance by the operating system and/or system administrator to configure the mandatory access control to restrict other entities’ access to the children’s managed security and privacy assets, as justified in [E.Just.DT.ACM-6], if this user is an authorized user; and
— the issuance of clearance is associated with the principle of least privileges; and
— changing the operating system and/or system administrator that is responsible for the issuance of clearance to the user can only be performed by the authorized system administrator.
[AU.ACM-6.Generic]: If the access control mechanisms documented in [E.Info.ACM-6.ACM] belong to [IC.ACM-6.Generic]), functionally confirm that:
— users are only allowed to configure access control mechanisms to restrict other entities’ access to the children’s managed privacy assets if this user is an authorized user; and
— the principle of least privileges for all users is followed; and
— changing settings related to the access control mechanism or changes of privileges of users are only allowed to be performed by authorized users.
# 6.1.6.4.6.3 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each access control mechanism documented in [E.Info.ACM-6.ACM] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for an access control mechanism documented in [E.Info.ACM-6.ACM] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2[AUM] Authentication mechanism
# 6.2.1 [AUM-1] Applicability of authentication mechanisms
# 6.2.1.1 [AUM-1-1] Requirement network interface
Access control mechanisms required per ACM-1 shall use authentication mechanisms for managing entities’ access via network interfaces that allow to:
— read confidential personal information, confidential privacy function configuration or confidential security parameters; or
— modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or
— use privacy functions or security functions,
except for access:
— to personal information, privacy functions or privacy function configuration where the absence of authentication is required for the intended equipment functionality; or
— via networks where physical or logical measures in the equipment’s targeted operational environment limit accessibility to authorised entities.
# 6.2.1.2 [AUM-1-2] Requirement user interface
Access control mechanisms required per ACM-1 shall use authentication mechanisms for managing entities’ access via user interfaces that allow to:
— read confidential personal information, confidential privacy function configuration or confidential security parameters; or
— modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or
— use privacy functions or security functions,
except for access:
— where physical or logical measures in the equipment’s targeted operational environment limit accessibility to authorized entities;
and except for read only access to personal information, privacy functions or privacy function configuration where access without authentication is needed:
— to enable the intended equipment functionality or
— because legal implications do not allow for authentication mechanisms.
# 6.2.1.3 Rationale
The equipment needs to provide an authentication mechanism such that the corresponding access control mechanism prevents unauthorized access to security and privacy assets that are relevant to user’s privacy from entities which are not who or what they claim to be.
# 6.2.1.4 Guidance
Authentication mechanisms might use different layers (e.g., application or network layer) for verifying the validity of entities’ claims. The management of associated access rights for entities are addressed by access control mechanisms.
There are different kinds of entities that can interact with the equipment, e.g.:
— a specific human, owner of a user account, device or service; or
— a member of specific groups such as an authorized group to access a specific equipment’s resource; or
— authorised by another entity to access a specific equipment’s resource.
Typically, the verification of an entity is based on examining evidence from one or more elements of the categories:
— knowledge (something you know); and
— possession (something you have); and
— inherence (something you are).
A trust relation to a network (e.g., an entity owns a shared secret like Wi-Fi credentials) could be used to authenticate an entity.
Authentication might not be needed for all accesses to security assets or privacy assets.
Examples of access where authentication might not be mandatory are amongst others:
— reading information which is clearly advertised as publicly accessible information related to the intended equipment functionality; or
— reading a public key.
Examples of physical or logical measures in the targeted environment that provide confidence in the correctness of an entity’s claim might be amongst others:
— physical access control that only allows authorized access to the inside of personal road vehicles or watercrafts; or
— physical access control that only allows authorized access e.g., to a WPS button of a home gateway to attach other devices to a Wi-Fi network within a private house.
# 6.2.1.5 Assessment criteria network interface
# 6.2.1.5.1 Assessment objective
The assessment addresses the requirement AUM-1-1.
# 6.2.1.5.2 Implementation categories
Not applicable.
# 6.2.1.5.3 Required information
[E.Info.AUM-1-1.ACM]: Description of each access control mechanism required per ACM-1 for managing entities’ access over network interfaces that allow to read confidential personal information, confidential privacy function configuration or confidential security parameters; or modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or use privacy functions or security functions, including:
— [E.Info.AUM-1-1.ACM.NetworkInterface]: Description of the network interfaces for the managed access; and
— [E.Info.AUM-1-1.ACM.ManagedAccessPrivacyAsset]: Description of the managed access to privacy assets via network interfaces; and
— [E.Info.AUM-1-1.ACM.ManagedAccessSecurityAsset]: Description of the managed access to security assets via network interfaces; and
— (if absence of authentication for access to privacy functions or privacy function configuration via network interfaces is required for the equipment’s intended functionality) [E.Info.AUM-1- 1.ACM.IntendedFunctionality]: A description of
o the unauthenticated accessible privacy functions or privacy function configuration; and
o the equipment’s intended functionality; and
o its properties that require the absence of authentication for access to the privacy functions or privacy function configuration; and
— (if authentication is absent for access via networks where access is limited to authorised entities) [E.Info.AUM-1-1.ACM.TrustedNetwork]: Description the networks and the physical or logical measures in the equipment’s targeted operational environment that limit access to authorized entities; and
— (if authentication is required per AUM-1-1) [E.Info.AUM-1- 1.ACM.AuthenticationMechanism]: Description of the implemented authentication mechanisms.
[E.Info.DT.AUM-1-1]: Description of the selected path through the decision tree in Figure 7 for each access control mechanism documented in [E.Info.AUM-1-1.ACM].
[E.Just.DT.AUM-1-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.AUM-1-1] with the following properties:
(if a decision from [DT.AUM-1-1.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.AUM-1-1.DN-1] is based on [E.Info.AUM-1-1.ACM.IntendedFunctionality]; and
— (if a decision from [DT.AUM-1-1.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.AUM-1-1.DN-2] is based on [E.Info.AUM-1-1.ACM.TrustedNetwork]; and
— the justification for the decision [DT.AUM-1-1.DN-3] is based on [E.Info.AUM-1-1.ACM].
# 6.2.1.5.4 Conceptual assessment
# 6.2.1.5.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the authentication mechanisms are implemented when it is required per AUM-1-1.
# 6.2.1.5.4.2 Preconditions
None.
# 6.2.1.5.4.3 Assessment units
Figure 7 — Decision Tree for requirement AUM-1-1
For each access control mechanism documented in [E.Info.AUM-1-1.ACM], check whether the path through the decision tree documented in [E.Info.DT.AUM-1-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.AUM-1-1], examine its justification documented in [E.Just.DT.AUM-1-1].
# 6.2.1.5.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.AUM-1-1] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.AUM-1-1] ends with “FAIL”; and
— the information provided in [E.Just.DT.AUM-1-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.AUM-1-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.AUM-1-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.AUM-1-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.AUM-1-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.1.5.5 Functional completeness assessment
# 6.2.1.5.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether there are access control mechanisms on the equipment for managing entities’ access over network interfaces that allow to read confidential network function configuration or confidential security parameters; or modify sensitive network function configuration or sensitive security parameters; or use network functions or security functions that are not described in [E.Info.AUM-1-1.ACM].
# 6.2.1.5.5.2 Preconditions
The equipment is in an operational state.
# 6.2.1.5.5.3 Assessment units
Functionally assess whether there are access control mechanisms required per ACM-1 for managing entities’ access over network interfaces that allow to read confidential personal information, confidential privacy function configuration or confidential security parameters; or modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or use privacy functions or security functions that are not described in [E.Info.AUM-1-1.ACM].
# 6.2.1.5.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an access control mechanism required per ACM-1 for managing entities’ access over network interfaces that allow to read confidential personal information, confidential privacy function configuration or confidential security parameters; or modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or use privacy functions or security functions, is found that is not documented in [E.Info.AUM-1-1.ACM].
The verdict FAIL for the assessment case is assigned if there is evidence that an access control mechanism required per ACM-1 for managing entities’ access over network interfaces that allow to read confidential personal information, confidential privacy function configuration or confidential security parameters; or modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or use privacy functions or security functions, is found that is not documented in [E.Info.AUM-1-1.ACM].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.1.5.6 Functional sufficiency assessment
# 6.2.1.5.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the documented authentication mechanisms required per AUM-1-1 are implemented.
# 6.2.1.5.6.2 Preconditions
The equipment is in an operational state.
# 6.2.1.5.6.3 Assessment units
For each access control mechanisms documented in [E.Info.AUM-1-1.ACM], each managed access via network interfaces to privacy assets documented in [E.Info.AUM-1-1.ACM.ManagedAccessPrivacyAsset] and each managed access via network interfaces to security assets documented in [E.Info.AUM-1-
1.ACM.ManagedAccessSecurityAsset], access the corresponding assets and check whether the authentication mechanism is implemented.
# 6.2.1.5.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an authentication mechanism documented in [E.Info.AUM-1-1.ACM.AuthenticationMechanism] is not implemented.
The verdict FAIL for the assessment case is assigned if there is evidence that an authentication mechanism documented in [E.Info.AUM-1-1.ACM.AuthenticationMechanism] is not implemented.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.1.6 Assessment criteria user interface
# 6.2.1.6.1 Assessment objective
The assessment addresses the requirement AUM-1-2.
# 6.2.1.6.2 Implementation categories
Not applicable.
# 6.2.1.6.3 Required information
[E.Info.AUM-1-2.ACM]: Description of each access control mechanism required per ACM-1 for managing entities’ access over user interfaces that allow to read confidential personal information, confidential privacy function configuration or confidential security parameters; or modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or use privacy functions or security functions, including:
— A description of the user interfaces for the managed access; and
— [E.Info.AUM-1-2.ACM.ManagedAccessPrivacyAsset]: Description of the managed access to privacy assets via user interfaces; and
— [E.Info.AUM-1-2.ACM.ManagedAccessSecurityAsset]: Description of the managed access to security assets via user interfaces; and
— (if physical or logical measures in the targeted environment provide confidence in the correctness of an entity’s claim) [E.Info.AUM-1-2.ACM.IntendedEnvironment]: Description of the physical or logical measures in the targeted environment; and
— (if authentication is required per AUM-1-2) [E.Info.AUM-1- 2.ACM.AuthenticationMechanism]: Description of the implemented authentication mechanisms; and
— (if authentication is absent for read only access to personal information, privacy functions or privacy function configuration where access without authentication is needed to enable the intended equipment functionality) [E.Info.AUM-1-2.ACM.ReadOnlyFunctionality]: Description of the equipment’s intended functionality concerning the absence of authentication for read only access to affected assets via user interfaces; and
— (if authentication is absent for read only access to personal information, privacy functions or privacy function configuration where legal implications do not allow for authentication mechanisms) [E.Info.AUM-1-2.ACM.ReadOnlyLegal]: References to all corresponding
paragraph(s) or passages in all relevant legal documents, including a description on how this is applicable for the equipment or affected asset.
[E.Info.DT.AUM-1-2]: Description of the selected path through the decision tree in Figure 8 for each access control mechanism documented in [E.Info.AUM-1-2.ACM].
[E.Just.DT.AUM-1-2]: Justification for the path through the decision tree documented in [E.Info.DT.AUM-1-2] with the following properties:
— (if decision from [DT.AUM-1-2.DN-1] results in “NOT APPLICABLE) the justification for the decision [DT.AUM-1-2.DN-1] is based on [E.Info.AUM-1-2.ACM.IntendedEnvironment]; and
— (if decision from [DT.AUM-1-2.DN-2] results in “NOT APPLICABLE) the justification for the decision [DT.AUM-1-2.DN-2] is based on [E.Info.AUM-1-2.ACM.ReadOnlyFunctionality]; and
— (if decision from [DT.AUM-1-2.DN-3] results in “NOT APPLICABLE) the justification for the decision [DT.AUM-1-2.DN-3] is based on [E.Info.AUM-1-2.ACM.ReadOnlyLegal]; and
— the justification for the decision [DT.AUM-1-2.DN-4] is based on [E.Info.AUM-1-2.ACM].
# 6.2.1.6.4 Conceptual assessment
# 6.2.1.6.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether an authentication mechanism is implemented when it is required per AUM-1-2.
# 6.2.1.6.4.2 Preconditions
None.
# 6.2.1.6.4.3 Assessment units
Figure 8 — Decision Tree for requirement AUM-1-2
For each access control mechanism documented in [E.Info.AUM-1-2.ACM], check whether the path through the decision tree documented in [E.Info.DT.AUM-1-2] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.AUM-1-2], examine its justification documented in [E.Just.DT.AUM-1-2].
# 6.2.1.6.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.AUM-1-2] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.AUM-1-2] ends with “FAIL”; and
— the information provided in [E.Just.DT.AUM-1-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.AUM-1-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.AUM-1-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.AUM-1-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.AUM-1-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.1.6.5 Functional completeness assessment
# 6.2.1.6.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether there are access control mechanisms on the equipment for managing entities’ access over user interfaces that allow to read confidential personal information, confidential privacy function configuration or confidential security parameters; or modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or use privacy functions or security functions that are not described in [E.Info.AUM-1-2.ACM].
# 6.2.1.6.5.2 Preconditions
The equipment is in an operational state.
# 6.2.1.6.5.3 Assessment units
Functionally assess whether there are access control mechanisms required per ACM-1 for managing entities’ access over user interfaces that allow to read confidential personal information, confidential privacy function configuration or confidential security parameters; or modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or use privacy functions or security functions that are not described in [E.Info.AUM-1-2.ACM].
# 6.2.1.6.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an access control mechanism required per ACM-1 for managing entities’ access over user interfaces that allow to read confidential personal information, confidential privacy function configuration or confidential security parameters; or modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or use privacy functions or security functions, is found that is not documented in [E.Info.AUM-1-2.ACM].
The verdict FAIL for the assessment case is assigned if there is evidence that an access control mechanism required per ACM-1 for managing entities’ access over user interfaces that allow to read confidential personal information, confidential privacy function configuration or confidential security parameters; or modify sensitive personal information, sensitive privacy function configuration or sensitive security parameters; or use privacy functions or security functions, is found that is not documented in [E.Info.AUM-1-2.ACM].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.1.6.6 Functional sufficiency assessment
# 6.2.1.6.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the documented authentication mechanisms required per AUM-1-2 are implemented.
# 6.2.1.6.6.2 Preconditions
The equipment is in an operational state.
# 6.2.1.6.6.3 Assessment units
For each access control mechanism documented in [E.Info.AUM-1-2.ACM], each managed access via user interfaces to privacy assets documented in [E.Info.AUM-1-2.ACM.ManagedAccessPrivacyAsset] and each managed access via user interfaces to security assets documented in [E.Info.AUM-1- 2.ACM.ManagedAccessSecurityAsset], access the corresponding security assets and privacy assets and check whether the authentication mechanism is implemented.
# 6.2.1.6.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an authentication mechanism documented in [E.Info.AUM-1-2.ACM.AuthenticationMechanism] is not implemented.
The verdict FAIL for the assessment case is assigned if there is evidence that an authentication mechanism documented in [E.Info.AUM-1-2.ACM.AuthenticationMechanism] is not implemented.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.2 [AUM-2] Appropriate authentication mechanisms
# 6.2.2.1 [AUM-2-1] Requirement one factor authentication
Authentication mechanisms that are required per AUM-1-1 (network interface) or AUM-1-2 (user interface) shall verify an entity’s claim based on examining evidence from at least one element of the categories knowledge, possession and inherence (one factor authentication).
# 6.2.2.2 [AUM-2-2] Requirement two factor authentication
If the primary equipment’s intended functionality is specifically processing personal information of special categories, for each access to personal information of special categories via user interfaces over network interface the authentication mechanisms shall support the verification of an entity’s claim based on evidence derived from at least two different elements of the categories knowledge, possession and inherence (two factor authentication).
# 6.2.2.3 Rationale
One factor authentication is suitable to prevent unauthorized access to security assets or privacy assets that are relevant to user’s privacy from entities which are not who or what they claim to be. The management of associated access rights for entities is enforced by access control mechanism.
If the primary equipment’s intended functionality is to specifically process personal information of special categories, the disclosure of such data could have serious consequences. In this case the possibility to use two factor authentication for accesses via user interfaces over network interfaces is required.
# 6.2.2.4 Guidance
Examples for a verification of an entity’s claim based on examining evidence from one element of the categories, knowledge, possession and inherence, are:
— PIN-Code used for user interface
— 1-Factor (e.g., password based) of each incoming connection on a user or network interface
— fingerprint biometrics or face recognition for a user interface
- verifying the possession of a private key that matches to a trusted certificate
— trust relation to a network (e.g., based on a common secret) established at on-boarding.
Examples for a verification of an entity’s claim based on evidence derived from at least two different elements of the categories, knowledge, possession and inherence, are:
— Password + OTP
— PIN + Smartcard
— Password + Token
If a user is accessing the equipment through a software application running on another device, such as a maintenance application running on a server or laptop, this can, depending on the architecture, be considered a software process accessing the equipment. Hence, the authentication for software processes can apply. Strong authentication, including possibly multi-factor authentication, can be used for the user to authenticate to the external software application. It is also possible to use cryptographic measures to create a trust relationship between the equipment and another device such that the possession of the other device can be considered as one authentication factor. The two-factor authentication to access the equipment might be ensured through another device in the operational environment of the equipment.
Here, the primary equipment’s intended functionality for specifically processing personal information of special categories means that equipment cannot be used for its intended functionality without processing personal information of special categories. It is therefore specifically designed to process such data.
Equipment whose intended functionality is to process any data which only could possibly include personal information of special categories such as desktop pcs, smartphones, cameras or printers needs only foresee protection for personal data. Generally, when designing equipment to store personal data, it is reasonable to consider providing multifactor authentication.
Considering possible constraints of human users with disabilities is an important aspect for implementing appropriate authentication mechanisms. Examples of considerations when selecting authentication mechanisms include:
— transferring the authentication information to and from a relevant assistive technology,
enabling a dual or shared use when the equipment is in use by a user and a support worker (and/or parent and child),
— offering alternative authentication mechanisms so that they are useable by a user with specific learning impairments (including dyslexia) and do not trigger negative feelings (e.g., by avoiding specifying family or personal information which may be distressing or not relevant for the end user).
At the time of publishing the present document long passwords like “WeihnachtsmarkTElephanT CarpeT2023@Bon(n)” are considered stronger passwords than short passwords like “P@ssw0rd!” and more guidance on current best practice on passwords can be found in NIST Special Publication 800-63B [10], ISO/IEC EN 27002:2022 [3], ISO/IEC EN 24760 [4], IEC EN 62443-4-2 [2] and ETSI EN 303 645 [6].
# 6.2.2.5 Assessment criteria one factor authentication
# 6.2.2.5.1 Assessment objective
The assessment addresses the requirement AUM-2-1.
# 6.2.2.5.2 Implementation categories
Not applicable.
# 6.2.2.5.3 Required information
[E.Info.AUM-2-1.AuthenticationMechanism]: Description of each authentication mechanism required per AUM-1-1 (network interface) or AUM-1-2 (user interface) including:
— [E.Info.AUM-2-1.AuthenticationMechanism.AuthFactor]: Description of the authenticators including their categories (knowledge, possession and inherence).
[E.Info.DT.AUM-2-1]: Description of the selected path through the decision tree in Figure 9 for each authentication mechanism that is documented in [E.Info.AUM-2-1.AuthenticationMechanism].
[E.Just.DT.AUM-2-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.AUM-2-1] with the following property:
the justification for the decision [DT.AUM-2-1.DN-1] is based on [E.Info.AUM-2- 1.AuthenticationMechanism.AuthFactor].
# 6.2.2.5.4 Conceptual assessment
# 6.2.2.5.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the authentication mechanisms that are required per AUM-1-1 (network interface) or AUM-1-2 (user interface) are implemented as required per AUM-2-1.
# 6.2.2.5.4.2 Preconditions
None.
# 6.2.2.5.4.3 Assessment units
Figure 9 — Decision Tree for requirement AUM-2-1
For each authentication mechanism documented in [E.Info.AUM-2-1.AuthenticationMechanism], check whether the path through the decision tree documented in [E.Info.DT.AUM-2-1] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.AUM-2-1], examine its justification documented in [E.Just.DT.AUM-2-1].
# 6.2.2.5.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.AUM-2-1] end with “PASS”; and
— the information provided in [E.Just.DT.AUM-2-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.AUM-2-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.AUM-2-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.AUM-2-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.AUM-2-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.2.5.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the authentication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.2.2.5.6 Functional sufficiency assessment
# 6.2.2.5.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the authentication mechanisms that are required per AUM-1-1 (network interface) or AUM-1-2 (user interface) are implemented as documented in [E.Info.AUM-2-1.AuthenticationMechanism.AuthFactor].
# 6.2.2.5.6.2 Preconditions
The equipment is in an operational state.
# 6.2.2.5.6.3 Assessment units
For each authentication mechanism that is required per AUM-1-1 (network interface) or AUM-1-2 (user interface) documented in [E.Info.AuthenticationMechanism.AUM-2-1], perform the authentication and check whether the authentication mechanism is implemented as documented.
# 6.2.2.5.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an authentication mechanism’s implementation deviates from [E.Info.AUM-2-1.AuthenticationMechanism].
The verdict FAIL for the assessment case is assigned if there is evidence that an authentication mechanism’s implementation deviates from [E.Info.AUM-2-1.AuthenticationMechanism].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.2.6 Assessment criteria two factor authentication
# 6.2.2.6.1 Assessment objective
The assessment addresses the requirement AUM-2-2.
# 6.2.2.6.2 Implementation categories
Not applicable.
# 6.2.2.6.3 Required information
(If the primary equipment’s intended functionality is specifically processing personal information of special categories) [E.Info.AUM-2-2.AuthenticationMechanism]: Description of each authentication mechanism required per AUM-1-1 (network interface) or AUM-1-2 (user interface) and used for access to personal information of special categories via user interfaces over network interface including:
— [E.Info.AUM-2-2.AuthenticationMechanism.AuthFactor]: Description of the authenticators including their categories (knowledge, possession and inherence).
[E.Info.DT.AUM-2-2]: Description of the selected path through the decision tree in Figure 10 for each authentication mechanism documented in [E.Info.AUM-2-2.AuthenticationMechanism].
[E.Just.DT.AUM-2-2]: Justification for the selected path through the decision tree documented in [E.Info.DT.AUM-2-2] with the following property:
— the justification for the decision [DT.AUM-2-2.DN-2] is based on [E.Info.AUM-2- 2.AuthenticationMechanism] and [E.Info.AUM-2-2.AuthenticationMechanism.AuthFactor] .
# 6.2.2.6.4 Conceptual assessment
# 6.2.2.6.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the authentication mechanism required per AUM-1-1 (network interface) or AUM-1-2 (user interface) is implemented as required per AUM-2-2.
# 6.2.2.6.4.2 Preconditions
None.
# 6.2.2.6.4.3 Assessment units
Figure 10 — Decision Tree for requirement AUM-2-2
For each authentication mechanism documented in [E.Info.AUM-2-2.AuthenticationMechanism], check whether the path through the decision tree documented in [E.Info.DT.AUM-2-2] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.AUM-2-2], examine its justification documented in [E.Just.DT.AUM-2-2].
# 6.2.2.6.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.AUM-2-2] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.AUM-2-2] ends with “FAIL”; and
— the information provided in [E.Just.DT.AUM-2-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.AUM-2-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.AUM-2-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.AUM-2-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.AUM-2-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.2.6.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the authentication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.2.2.6.6 Functional sufficiency assessment
# 6.2.2.6.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the authentication mechanisms that are required per AUM-1-1 (network interface) or AUM-1-2 (user interface) are implemented as documented in [E.Info.AUM-2-2.AuthenticationMechanism.AuthFactor].
# 6.2.2.6.6.2 Preconditions
The equipment is in an operational state.
# 6.2.2.6.6.3 Assessment units
For each authentication mechanism that is required per AUM-1-1 (network interface) or AUM-1-2 (user interface) documented in [E.Info.AUM-2-2.AuthenticationMechanism], activate two factor authentication, perform the authentication and check whether the authentication mechanism is implemented as documented.
# 6.2.2.6.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an authentication mechanism’s implementation deviates from [E.Info.AUM-2-2.AuthenticationMechanism].
The verdict FAIL for the assessment case is assigned if there is evidence that an authentication mechanism’s implementation deviates from [E.Info.AUM-2-2.AuthenticationMechanism].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.3 [AUM-3] Authenticator validation
# 6.2.3.1 Requirement
Authentication mechanisms that are required per AUM-1-1 (network interface) or AUM-1-2 (user interface) shall validate all relevant properties of the used authenticators, dependent on the available information in the operational environment of use.
# 6.2.3.2 Rationale
Even when the equipment provides an authentication mechanism, the risk is given that an attacker uses typical design weaknesses to overcome it. The usage of forged or partially forged authenticators are often used for an attack against such a mechanism. Therefore, the security design of the mechanisms needs techniques to resist forged authenticators, for example manipulated PKI certificates.
# 6.2.3.3 Guidance
The authenticator and its attributes vary depending on the authentication mechanism. For the validation of the authenticator, best practice ought to be applied for the corresponding authentication mechanism.
This is necessary in order to detect and prevent the use of an authenticator that is invalid. For example, if the equipment only validates the common name of a PKI certificate without further validation of the complete certificate information, then a correspondingly forged authenticator would be accepted. In this example, the relevant properties of the authenticator are the signatures and public keys of the trust chain, the revocation status and in many cases also the validity of the certificate. The set of relevant properties can differ depending on whether the equipment is actually internet connected or not. For example, offline equipment probably does not have access to a reliable time source or to certificate revocation information.
Another example for insufficient validation of authenticators is, if only parts of the password is checked. This would weaken the strength of the password, facilitating brute force attacks on the corresponding authentication mechanism.
# 6.2.3.4 Assessment criteria
# 6.2.3.4.1 Assessment objective
The assessment addresses the requirement AUM-3.
# 6.2.3.4.2 Implementation categories
[IC.AUM-3.Password]: The authenticator is a password.
[IC.AUM-3.CertificatePrivateKey]: The authenticator is a private key associated to a certificate trusted by the equipment.
NOTE A certificate can be trusted be the equipment for example via a chain of trust to a preinstalled root certificate of a PKI or by certificate pinning.
[IC.AUM-3.Generic]: The authenticator is different from [IC.AUM-3.Password] or [IC.AUM-3.CertificatePrivateKey].
EXAMPLE Biometrics, Secure Shell (SSH) keys, symmetric keys
# 6.2.3.4.3 Required information
[E.Info.AUM-3.AUM]: Description of each authentication mechanism required per AUM-1-1 (network interface) or AUM-1-2 (user interface), including:
— [E.Info.AUM-3.AUM.AuthVal]: Description how the validation of the authenticator is performed including its implementation category and the relevant properties; and
— [E.Info.AUM-3.AUM.AuthEnv]: Description of the available information about the authenticator in the operational environment of use.
[E.Info.DT.AUM-3]: Description of the selected path through the decision tree in Figure 11 for each authentication mechanism that is documented in [E.Info.AUM-3.AUM].
[E.Just.DT.AUM-3]: Justification for the selected path through the decision tree documented in [E.Info.DT.AUM-3] with the following property:
— the justification for the decision [DT.AUM-3.DN-1] is based on [E.Info.AUM-3.AUM.AuthVal] and [E.Info.AUM-3.AUM.AuthEnv].
# 6.2.3.4.4 Conceptual assessment
# 6.2.3.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the authentication mechanisms validate all relevant properties of the authenticator as documented in [E.Info.AUM-3.AUM]. This assessment is conducted on each path to security assets and/or privacy assets required by AUM-1- 1 or AUM-1-2.
# 6.2.3.4.4.2 Preconditions
None.
# 6.2.3.4.4.3 Assessment units
Figure 11 — Decision Tree for requirement AUM-3
For each authentication mechanism documented in [E.Info.AUM-3.AUM], check whether the path through the decision tree documented in [E.Info.DT.AUM-3] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.AUM-3], examine its justification documented in [E.Just.DT.AUM-3].
# 6.2.3.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.AUM-3] end with “PASS”; and
— the information provided in [E.Just.DT.AUM-3] are correct justifications for all paths through the decision tree documented in [E.Info.DT.AUM-3].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.AUM-3] ends with “FAIL”; or
— a justification provided in [E.Just.DT.AUM-3] is not correct or missing for a path through the decision tree documented in [E.Info.DT.AUM-3].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.3.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the authentication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.2.3.4.6 Functional sufficiency assessment
# 6.2.3.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the authentication mechanism required per AUM-1-1 or AUM-1-2 validates all required properties.
# 6.2.3.4.6.2 Preconditions
The equipment is in an operational state.
# 6.2.3.4.6.3 Assessment units
For each authentication mechanism documented in [E.Info.AUM-3.AUM]:
[AU.AUM-3.Password]: If the authenticator belongs to [IC.AUM-3.Password], functionally confirm the validation of the relevant properties of the authenticator documented in [E.Info.AUM-3.AUM.AuthVal] by examining whether:
— incorrect passwords can be used for successful authentication; and
(if the confidentiality of the messages exchanged during authentication via network interfaces is not protected) a replay of an recorded successful authentication attempt can be used for successful authentication; and
— parts of the correct password can be used for authentication; and
— (if different user accounts exist or can be created) passwords of other entities can be used for authentication.
[AU.AUM-3.CertificatePrivateKey]: If the authenticator belongs to [IC.AUM-3.CertificatePrivateKey], functionally confirm the validation of the relevant properties of the authenticator documented in [E.Info.AUM-3.AUM.AuthVal] by examining whether:
— incorrect private keys to a trusted certificate can be used for successful authentication; and
(if the confidentiality of the messages exchanged during authentication via network interfaces is not protected) a replay of an recorded successful authentication attempt can be used for successful authentication; and
— valid private keys to untrusted or invalid certificates can be used for successful authentication; and
NOTE untrusted or invalid certificates can be certificates revoked by the certificate authority, expired certificates, certificates with an invalid chain of trust e.g., generated by an untrusted entity containing an expected “Common Name” (CN) entry.
— (if different user accounts exist or can be created) private keys to a trusted certificate of other entities can be used for authentication.
[AU.AUM-3.Generic]: If the authenticator belongs to [IC.AUM-3.Generic], functionally confirm the validation of the relevant properties of the authenticator documented in [E.Info.AUM-3.AUM.AuthVal] by examining whether:
— incorrect authenticators can be used for successful authentication; and
— (if the confidentiality of the messages exchanged during authentication via network interfaces is not protected) a replay of an recorded successful authentication attempt can be used for successful authentication; and
— (if different user accounts exist or can be created) authenticators of other entities can be used for authentication.
# 6.2.3.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each authentication mechanism documented in [E.Info.AUM-3.AUM] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for an authentication mechanism documented in [E.Info.AUM-3.AUM] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.4 [AUM-4] Changing authenticators
# 6.2.4.1 Requirement
Authentication mechanisms that are required per AUM-1-1 or AUM-1-2 shall allow for changing the authenticator except for authenticators where conflicting security goals do not allow for a change.
# 6.2.4.2 Rationale
Static authenticators can be a security risk for the equipment, e.g., increased vulnerability to brute force and eavesdropping attacks. Therefore, the support for changing authenticators on the equipment is needed as a countermeasure.
# 6.2.4.3 Guidance
An authorised entity needs the possibility to change the authenticator. The procedure can vary depending on the authentication mechanism used.
— The equipment provides a functionality to the authorised entity, e.g., user, to change the authenticator on the equipment.
— The authenticator, e.g., token, is renewed or changed by the manufacturer and the equipment accepts the changed authenticator because the trust chain is still valid.
— The authenticator is updated using a secure update mechanism.
In case of machine interfaces new pairing can be necessary. The integration of the change of the authenticator in the normal workflow simplifies the procedure for the user. This procedure depends on the selected authenticator (e.g., fingerprint, password or token)
There can be use cases where a static authenticator is acceptable, such as a root of trust where the confidentiality of the corresponding cryptographic key is ensured by the manufacturer. In such an example the manufacturer typically provides tokens to authorized entities that are all linked to the same root of trust.
There can also be exceptions, where the overall risk of changing an authenticator, e.g., due to complexity, outweighs the risk associated with the security assets or privacy assets when using static authenticators. In such cases, it's important to consider best practice security design principles to minimize the risk associated with the static authenticator, for example, by avoiding the use of global authenticators.
Depending on the intended equipment functionality it might be needed to ensure the availability of the equipment functionality due a deferral option, e.g., not forcing the update of a password whilst driving a car.
# 6.2.4.4 Assessment criteria
# 6.2.4.4.1 Assessment objective
The assessment addresses the requirement AUM-4.
# 6.2.4.4.2 Implementation categories
Not applicable.
# 6.2.4.4.3 Required information
[E.Info.AUM-4.AUM]: Description of each authentication mechanism required per AUM-1-1 (network interface) and AUM-1-2 (user interface), including:
(if conflicting security goals do not allow for a change) [E.Info.AUM-4.AUM.ConfSecGoals]: Description of the conflicting security goals from the security concept of the equipment concerning the change of the authenticator; and
[E.Info.AUM-4.AUM.AuthChange]: Description for each authentication mechanism documented in [E.Info.AUM-4.AUM] how the change of the authenticator is performed under consideration of the security concept of the equipment.
[E.Info.DT.AUM-4]: Description of the selected path through the decision tree in Figure 12 for each authenticator change functionality documented in [E.Info.AUM-4.AUM.AuthChange].
[E.Just.DT.AUM-4]: Justification for the selected path through the decision tree documented in [E.Info.DT.AUM-4] with the following properties:
— the justification for the decision [DT.AUM-4.DN-1] is based on [E.Info.AUM-4.AUM.ConfSecGoals]; and
— the justification for the decision [DT.AUM-4.DN-2] is based on [E.Info.AUM-4.AUM.AuthChange].
# 6.2.4.4.4 Conceptual assessment
# 6.2.4.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the authenticator used by the authentication mechanisms documented in [E.Info.AUM-4.AUM] can be changed.
# 6.2.4.4.4.2 Preconditions
None.
# 6.2.4.4.4.3 Assessment units
Figure 12 — Decision Tree for requirement AUM-4
For each authenticator change functionality documented in [E.Info.AUM-4.AUM], check whether the path through the decision tree documented in [E.Info.DT.AUM-4] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.AUM-4], examine its justification documented in [E.Just.DT.AUM-4].
# 6.2.4.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.AUM-4] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.AUM-4] ends with “FAIL”; and
— the information provided in [E.Just.DT.AUM-4] are correct justifications for all paths through the decision tree documented in [E.Info.DT.AUM-4].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.AUM-4] ends with “FAIL”; or
— a justification provided in [E.Just.DT.AUM-4] is not correct or missing for a path through the decision tree documented in [E.Info.DT.AUM-4].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.4.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the authentication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.2.4.4.6 Functional sufficiency assessment
# 6.2.4.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the documented authentication mechanisms that are required per AUM-1-1 (network interface) or AUM-1-2 (user interface) allow for changing the authenticator as documented in [E.Info.AUM-4.AUM.AuthChange].
# 6.2.4.4.6.2 Preconditions
The equipment is in an operational state.
# 6.2.4.4.6.3 Assessment units
For each authentication mechanism that is required per AUM-1-1 (network interface) or AUM-1-2 (user interface) documented in [E.Info.AUM-4.AUM], functionally confirm the ability to change authenticator as documented in [E.Info.AUM-4.AUM.AuthChange] by
— checking whether the newly assigned authenticator grants access on each path to security assets and/or privacy assets; and
— checking whether the previous authenticator does no longer grant access on any path to security assets and/or privacy assets
after changing the authenticator.
# 6.2.4.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an implementation of changing an authenticator deviates from [E.Info.AUM-4.AUM.AuthChange].
The verdict FAIL for the assessment case is assigned if there is evidence that an implementation of changing an authenticator deviates from [E.Info.AUM-4.AUM.AuthChange].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.5 [AUM-5] Password strength
# 6.2.5.1 [AUM-5-1] Requirement for factory default passwords
If factory default passwords are used by an authentication mechanism that is required per AUM-1-1 or AUM-1-2, they shall:
— be unique per equipment; and
— follow best practice concerning strength;
or
— be enforced to be changed by the user before or on first use.
NOTE The user may choose to not use any password.
# 6.2.5.2 [AUM-5-2] Requirement for non-factory default passwords
If passwords other than factory default passwords are used by an authentication mechanism required per AUM-1-1 or AUM-1-2, they shall:
— be enforced to be set by the user before or on first use and before the equipment is logically connected to a network; or
— be defined by an authorized entity within a network where access is limited to authorised entities; or
— be generated by the equipment using best practice concerning strength and only communicated to an authorized entity within a network where access is limited to authorised entities.
NOTE The user can choose to not use any password.
# 6.2.5.3 Rationale
Weak passwords like universal passwords represent one of the most exploited attack vectors for equipment. There is a wide range of malware that uses such passwords to automatically compromise equipment. Hence, it is imperative to enforce distinct passwords when set at the factory or user/entitydefined passwords for each piece of equipment during their initial setup.
# 6.2.5.4 Guidance
There is a variety of techniques to avoid universal passwords, examples are:
— The equipment password for the factory default state is printed on a sticker under the equipment casing. The password is created by using a True Random Number Generator or another cryptographically secure pseudorandom number generator (CSPRNG) implementation.
— The equipment prompts a user to create a password on the first use.
It is highly recommended to follow well established standards for the secure generation of random numbers used to generate secure passwords. There are numerous well-recognised publicly available standards for random number generation mechanisms which have undergone peer review. Well established examples for such standards are NIST SP 800-90A Rev.1 [11], NIST SP 800-90B[12], NIST SP 800-90C[13], BSI AIS31[19].
Guidance on best practice on passwords can be found in NIST SP 800-63B [10],
ISO/IEC EN 27002:2022 [3], ISO/IEC EN 24760 [4], IEC EN 62443-4-2 [2] and ETSI EN 303 645 [6]
Unique relates to not systematically reused or deducible for another equipment of the same product type and cannot be easily derived from equipment properties (e.g., manufacturer name, model name or Media Access Control (MAC) address). Established random generator can be used to generate practically unique passwords.
When enforcing a password change, safety aspects are also relevant, such as not forcing a password change while driving a car.
# 6.2.5.5 Assessment criteria for factory default passwords
# 6.2.5.5.1 Assessment objective
The assessment addresses the requirement AUM-5-1.
# 6.2.5.5.1 Implementation Categories
[IC.AUM-5-1.UniqueBestPractice]: The user is not enforced to change a factory default password on or before first use and a password is unique per equipment and follows best practice concerning strength.
[IC.AUM-5-1.EnforceSettingFirstUse]: The user is enforced to change a factory default password on or before first use.
# 6.2.5.5.2 Required information
[E.Info.AUM-5-1.AUM]: Description of each authentication mechanism required per AUM-1-1 (network interface) or AUM-1-2 (user interface) that uses factory default passwords, including:
— [E.Info.AUM-5-1.AUM.PwdProperty]: Description for each authentication mechanism’s factory default password:
(if the implementation is based on [IC.AUM-5-1.UniqueBestPractice]) of how uniqueness and best practice concerning password strengths is implemented for the password with regard to the underlying use case of the authentication; and
— (if the implementation is based on [IC.AUM-5-1.EnforceSettingFirstUse]) of how the change of the password is enforced on or before first use.
[E.Info.DT.AUM-5-1]: Description of the selected path through the decision tree in Figure 13 for each authentication mechanism that is documented in [E.Info.AUM-5-1.AUM].
[E.Just.DT.AUM-5-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.AUM-5-1] with the following properties:
— the justification for the decisions [DT.AUM-5-1.DN-1], [DT.AUM-5-1.DN-2] and [DT.AUM-5- 1.DN-3] are based on [E.Info.AUM-5-1.AUM.PwdProperty].
# 6.2.5.5.3 Conceptual assessment
# 6.2.5.5.3.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the authentication mechanisms required by AUM-1-1 or AUM-1-2 are implemented as required per AUM-5-1.
# 6.2.5.5.3.2 Preconditions
None.
# 6.2.5.5.3.3 Assessment units
Figure 13 — Decision Tree for requirement AUM-5-1
For each authentication mechanism documented in [E.Info.AUM-5-1.AUM], check whether the path through the decision tree documented in [E.Info.DT.AUM-5-1] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.AUM-5-1], examine its justification documented in [E.Just.DT.AUM-5-1].
# 6.2.5.5.3.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.AUM-5-1] end with “PASS”; and
— the information provided in [E.Just.DT.AUM-5-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.AUM-5-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.AUM-5-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.AUM-5-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.AUM-5-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.5.5.4 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the authentication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.2.5.5.5 Functional sufficiency assessment
# 6.2.5.5.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the authentication mechanisms required by AUM-1-1 or AUM-1-2 are implemented as required per AUM-5-1.
# 6.2.5.5.5.2 Preconditions
The equipment is in the factory default state and not commissioned.
(If the method documented in [E.Info.AUM-5-1.AUM.PwdProperty] belongs to [IC.AUM-5- 1.UniqueBestPractice]) The equipment’s actual factory default password is available.
# 6.2.5.5.5.3 Assessment units
For each authentication mechanism documented in [E.Info.AUM-5-1.AUM]:
[AU.AUM-5-1.UniqueBestPractice]: If the method documented in [E.Info.AUM-5-1.AUM.PwdProperty] belongs to [IC.AUM-5-1.UniqueBestPractice], functionally confirm the implementation of the methods documented in [E.Info.AUM-5-1.AUM.PwdProperty] by:
— comparing the actual factory default passwords with the description of the implementation provided in [E.Info.AUM-5-1.AUM.PwdProperty]; and
— putting the equipment into service according to the installation instructions and verifying that the actual factory default passwords are valid.
[AU.AUM-5-1.EnforceSettingFirstUse]: If the method documented in [E.Info.AUM-5-1.AUM.PwdProperty] belongs to [IC.AUM-5-1.EnforceSettingFirstUse]), functionally confirm the implementation of the methods documented in [E.Info.AUM-5-1.AUM.PwdProperty] by:
— putting the equipment into service according to the installation instructions; and
— using the factory default passwords.
# 6.2.5.5.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an implementation of an authentication mechanism’s factory default password deviates from [E.Info.AUM-5- 1.AUM.PwdProperty].
The verdict FAIL for the assessment case is assigned if there is evidence that an implementation of an authentication mechanism’s factory default password deviates from [E.Info.AUM-5- 1.AUM.PwdProperty].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.5.6 Assessment criteria for non-factory default passwords
# 6.2.5.6.1 Assessment objective
The assessment addresses the requirement AUM-5-2.
# 6.2.5.6.1 Implementation Categories
[IC.AUM-5-2.SettingFirstUse]: The user is enforced to set a non-factory default password on or before first use before the equipment is logically connected to a network.
[IC.AUM-5-2.DefinedAuthEntity]: An authorized entity defines a non-factory default password within a network where access is limited to authorised entities.
[IC.AUM-5-2.EquipmentGenerated]: A non-factory default password is generated by the equipment using best practice concerning strength and only communicated to an authorized entity within a network where access is limited to authorised entities.
# 6.2.5.6.2 Required information
[E.Info.AUM-5-2.AUM]: Description of each authentication mechanism required per AUM-1-1 (network interface) or AUM-1-2 (user interface) that uses non-factory default passwords, including:
— [E.Info.AUM-5-2.AUM.PwdProperty]: Description for each authentication mechanism’s nonfactory default password:
o (if the implementation is based on [IC.AUM-5-2.SettingFirstUse]) of how the setting of the password is enforced and the means to prevent logical network connection before setting the password; and
O (if the implementation is based on [IC.AUM-5-2.DefinedAuthEntity]) of how the definition of the password is restricted to authorized entities and the means to prevent their definition within a network where access is not limited to authorised entities; and
o (if the implementation is based on [IC.AUM-5-2.EquipmentGenerated]) of how best practice concerning password strengths is implemented with regard to the underlying use case of the authentication and the means to prevent their communication to unauthorized entities or within a network where access is not limited to authorised entities.
[E.Info.DT.AUM-5-2]: Description of the selected path through the decision tree in Figure 14 for each authentication mechanism that is documented in [E.Info.AUM-5-2.AUM].
[E.Just.DT.AUM-5-2]: Justification for the selected path through the decision tree documented in [E.Info.DT.AUM-5-2] with the following property:
— the justification for the decisions [DT.AUM-5-2.DN-1], [DT.AUM-5-2.DN-2] and [DT.AUM-5- 2.DN-3] are based on [E.Info.AUM-5-2.AUM.PwdProperty].
# 6.2.5.6.3 Conceptual assessment
# 6.2.5.6.3.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the authentication mechanisms required by AUM-1-1 or AUM-1-2 are implemented as required per AUM-5-2.
# 6.2.5.6.3.2 Preconditions
None.
# 6.2.5.6.3.3 Assessment units
Figure 14 — Decision Tree for requirement AUM-5-2
For each authentication mechanism documented in [E.Info.AUM-5-2.AUM], check whether the path through the decision tree documented in [E.Info.DT.AUM-5-2] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.AUM-5-2], examine its justification documented in [E.Just.DT.AUM-5-2].
# 6.2.5.6.3.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.AUM-5-2] end with “PASS”; and
— the information provided in [E.Just.DT.AUM-5-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.AUM-5-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.AUM-5-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.AUM-5-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.AUM-5-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.5.6.4 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the authentication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.2.5.6.5 Functional sufficiency assessment
# 6.2.5.6.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the authentication mechanisms required by AUM-1-1 or AUM-1-2 are implemented as required per AUM-5-2.
# 6.2.5.6.5.2 Preconditions
The equipment is in the factory default state and not commissioned.
# 6.2.5.6.5.3 Assessment units
For each authentication mechanism documented in [E.Info.AUM-5-2.AUM]:
[AU.AUM-5-2.SettingFirstUse]: If the method documented in [E.Info.AUM-5-2.AUM.PwdProperty] belongs to [IC.AUM-5-2.SettingFirstUse], functionally confirm the implementation of the methods documented in [E.Info.AUM-5-2.AUM.PwdProperty] by:
— observing the equipment’s network’s logical connectivity; and
— putting the equipment into service according to the installation instructions; and
— using non-factory default passwords.
[AU.AUM-5-2.DefinedAuthEntity]: If the method documented in [E.Info.AUM-5-2.AUM.PwdProperty] belongs to [IC.AUM-5-2.DefinedAuthEntity], functionally confirm the implementation of the methods documented in [E.Info.AUM-5-2.AUM.PwdProperty] by:
— putting the equipment into service according to the installation instructions; and
— (if the equipment can connect to network where access is not limited to authorised entities) defining the non-factory default passwords as an authorized entity via a network where access is not limited to authorised entities; and
— defining the non-factory default passwords as an unauthorized entity; and
— defining the non-factory default passwords as an authorized entity via a network where access is limited to authorised entities or via a non-network interface.
[AU.AUM-5-2.EquipmentGenerated]: If the method documented in [E.Info.AUM-5-2.AUM.PwdProperty] belongs to [IC.AUM-5-2.EquipmentGenerated], functionally confirm the implementation of the methods documented in [E.Info.AUM-5-2.AUM.PwdProperty] by:
— putting the equipment into service according to the installation instructions; and
— initialising the generation of passwords; and
— receiving the password as unauthorized entity; and
— (if the equipment can connect to network where access is not limited to authorised entities) receiving the password as authorized entity via a network where access is not limited to authorised entities; and
— defining the non-factory default passwords as an authorized entity via a network where access is limited to authorised entities or via a non-network interface.
— comparing the generated passwords with the description of the implementation provided in [E.Info.AUM-5-2.AUM.PwdProperty].
# 6.2.5.6.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an implementation of an authentication mechanism’s non-factory default password deviates from [E.Info.AUM-5- 2.AUM.PwdProperty].
The verdict FAIL for the assessment case is assigned if there is evidence that an implementation of an authentication mechanism’s non-factory default password deviates from [E.Info.AUM-5- 2.AUM.PwdProperty].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.6 [AUM-6] Brute force protection
# 6.2.6.1 Requirement
Authentication mechanisms required per AUM-1-1 or AUM-1-2 shall be resilient against brute force attacks.
# 6.2.6.2 Rationale
An attacker can try to use mass authentication attempts to overcome an authentication mechanism or to impact equipment availability. Therefore, techniques are required to mitigate the impact of such an attack.
# 6.2.6.3 Guidance
Techniques for brute force protection of authentication mechanisms include e.g.:
— Time delays between consecutive failed attempts to authenticate;
— A limited number of failed authentication attempts followed by a suspension period where no login is allowed;
— Multi-factor authentication;
— Appropriate strength for authentication values based on best practice cryptography;
— Machine-to-machine authentication might implement mitigation measures such as:
— long password (more than 16 characters and high complexity);
— list of allowed IP addresses;
— warning/logging mechanism in machine-to-machine interface.
— Depending on the implemented techniques, related risks concerning "resource exhaustion" and “denial of service” need to be considered.
Consideration is to be given to mitigating the impact of repeated attempts to gain illegitimate authentication and mitigate the blocking of legitimate access by triggering the preceding defence mechanism.
See NIST 800-63 series [9].
# 6.2.6.4 Assessment criteria
# 6.2.6.4.1 Assessment objective
The assessment addresses the requirement AUM-6.
# 6.2.6.4.2 Implementation Categories
[IC.AUM-6.TimeDelay]: The methods for resilience against brute force attacks rely on time delays between authentication attempts.
[IC.AUM-6.LimitedAttemps]: The methods for resilience against brute force attacks rely on a limited number of authentication attempts.
[IC.AUM-6.AuthenticatorComplexity]: The methods for resilience against brute force attacks rely on authenticator complexity.
EXAMPLE mandatory multi factor authentication, enforce CCKs with a minimum-security strength of 112-bits
[IC.AUM-6.Generic]: The methods for resilience against brute force attacks rely on methods other than [IC.AUM-6.TimeDelay], [IC.AUM-6.LimitedAttemps] or [IC.AUM-6.AuthenticatorComplexity].
# 6.2.6.4.3 Required information
[E.Info.AUM-6.AUM]: Description of each authentication mechanism required per AUM-1-1 (network interface) or AUM-1-2 (user interface), including:
— [E.Info.AUM-6.AUM.BFProtection]: Description how the resilience against brute force attacks is ensured, considering the implementation categories.
[E.Info.DT.AUM-6]: Description of the selected path through the decision tree in Figure 15 for each authentication mechanism that is documented in [E.Info.AUM-6.AUM].
[E.Just.DT.AUM-6]: Justification for the selected path through the decision tree documented in [E.Info.DT.AUM-6] with the following property:
— the justification for the decision [DT.AUM-6.DN-1] is based on [E.Info.AUM-6.AUM.BFProtection].
# 6.2.6.4.4 Conceptual assessment
# 6.2.6.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the authentication mechanisms required by AUM-1-1 or AUM-1-2 have the capability as required per AUM-6.
# 6.2.6.4.4.2 Preconditions
None.
# 6.2.6.4.4.3 Assessment units
Figure 15 — Decision Tree for requirement AUM-6
For each authentication mechanism documented in [E.Info.AUM-6.AUM], check whether the path through the decision tree documented in [E.Info.DT.AUM-6] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.AUM-6], examine its justification documented in [E.Just.DT.AUM-6].
# 6.2.6.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.AUM-6] end with “PASS”; and
— the information provided in [E.Just.DT.AUM-6] are correct justifications for all paths through the decision tree documented in [E.Info.DT.AUM-6].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.AUM-6] ends with “FAIL”; or
— a justification provided in [E.Just.DT.AUM-6] is not correct or missing for a path through the decision tree documented in [E.Info.DT.AUM-6].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.2.6.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the authentication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.2.6.4.6 Functional sufficiency assessment
# 6.2.6.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the authentication mechanisms required by AUM-1-1 or AUM-1-2 comply with the requirement for AUM-6.
# 6.2.6.4.6.2 Preconditions
The equipment is in an operational state.
# 6.2.6.4.6.3 Assessment units
For each authentication mechanism documented in [E.Info.AUM-6.AUM]:
[AU.AUM-6.TimeDelay]: If the method documented in [E.Info.AUM-6.AUM.BFProtection] belongs to [IC.AUM-6.TimeDelay], functionally confirm the implementation of the methods documented in [E.Info.AUM-6.AUM.BFProtection] by:
— repeatedly performing authentication attempts using erroneous authenticators; and
— measuring the time delays enforced by the equipment between consecutive failed attempts.
[AU.AUM-6.LimitedAttemps]: If the method documented in [E.Info.AUM-6.AUM.BFProtection] belongs to [IC.AUM-6.LimitedAttemps], functionally confirm the implementation of the methods documented in [E.Info.AUM-6.AUM.BFProtection] by:
— repeatedly performing authentication attempts using erroneous authenticators; and
— counting the number consecutive failed attempts before the equipment prevents further attempts.
[AU.AUM-6.AuthenticatorComplexity]: If the method documented in [E.Info.AUM-6.AUM.BFProtection] belongs to [IC.AUM-6.AuthenticatorComplexity], functionally confirm the implementation of the methods documented in [E.Info.AUM-6.AUM.BFProtection] by:
— trying to assign an authenticator that does not meet the complexity criteria documented in [E.Info.AUM-6.AUM.BFProtection]; and
— performing a brute force attack on the authentication mechanism.
[AU.AUM-6.Generic]: If the method documented in [E.Info.AUM-6.AUM.BFProtection] belongs to [IC.AUM-6.Generic], functionally confirm the implementation of the methods documented in [E.Info.AUM-6.AUM.BFProtection] by:
— performing a brute force attack on the authentication mechanism.
# 6.2.6.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each authentication mechanism documented in [E.Info.AUM-6.AUM] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for an authentication mechanism documented in [E.Info.AUM-6.AUM] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.3[SUM] Secure update mechanism
# 6.3.1 [SUM-1] Applicability of update mechanisms
# 6.3.1.1 Requirement
The equipment shall provide at least one update mechanism for updating software, including firmware, affecting security assets and/or privacy assets, except for software:
— where functional safety implications do not allow updatability; or
— which is immutable; or
— where alternative measures protect the affected security assets and/or privacy assets during the entire lifecycle of the equipment.
# 6.3.1.2 Rationale
Having the ability to provide and deploy software updates through an update mechanism is an essential capability. It helps in maintaining equipment, addressing security vulnerabilities, and preventing potential exploitation that could compromise the equipment. Such compromises can pose risks to the network, disrupt its functioning, or lead to the misuse of network resources, resulting in an unacceptable degradation of service.
However, some parts of the software might be immutable and therefore not updatable for technology reasons or functional safety implications do not allow their updatability. Vulnerabilities might also be mitigated by alternative measures, such as exchanging vulnerable equipment throughout the entire life cycle or being securely mitigated by other equipment that ensures the protection of the security assets and privacy assets.
# 6.3.1.3 Guidance
There might be more than one update mechanism for parts of the software. However, this requirement demands at least one update mechanism for each software affecting security assets and/or network assets where no except criteria applies.
Not all software on the equipment can be updatable. This can include software stored in non-updatable memory due to the technology or to satisfy functional safety requirements or legal requirements.
There are cases where alternative measures exist to prevent harm from potential publicly known exploitable vulnerabilities in parts of the software or where an exploitable vulnerability in its software might not endanger the security assets or privacy assets to be protected. For instance:
— equipment having a replacement strategy, e.g., for equipment with limited resources such as sensors that would have to work on battery for many years; or
— equipment or parts of the software, which can and are foreseen to be securely isolated; or
— the system of which the equipment is part of mitigates the exploit of any vulnerability.
Where it is possible, it is good practice to implement a software update mechanism that allows for separate security related software updates and application software updates.
# 6.3.1.4 Assessment criteria
# 6.3.1.4.1 Assessment objective
The assessment addresses the requirement SUM-1.
# 6.3.1.4.2 Implementation categories
Not applicable.
# 6.3.1.4.3 Required information
[E.Info.SUM-1.PartOfSoftw]: Description of each part of the software affecting the security assets and/or privacy assets including:
— (if the part of the software is not updatable for functional safety implications) [E.Info.SUM-1.PartOfSoftw.FuncSaftyImp]: Description of:
o the functional safety requirements and their source; and
o the software’s function relation to the functional safety requirements
— (if the part of the software is not updatable because it is immutable) [E.Info.SUM-1.PartOfSoftw.Immutable]: Description of the methods that ensure that the part of the software is immutable; and
— (if the part of the software is not updatable because alternative measures exist) [E.Info.SUM-1.PartOfSoftw.AltMeasures]: Description of:
o the security assets and/or privacy assets the part of the software affects; and
o the alternative measures that protect the affected security assets and/or privacy assets esp. in case of a publicly known exploitable vulnerability affecting the security assets and/or privacy assets; and
o the expected life cycle of the equipment
— (if the part of the software is updatable) [E.Info.SUM-1.PartOfSoftw.SUM]: Description of the update mechanisms that can update the part of the software.
NOTE The present document does not determine the granularity of the separation of the software into components. A suitable separation with respect to efforts in documentation considers the coverage of the parts of the software by certain update mechanisms.
[E.Info.DT.SUM-1]: Description of the selected path through the decision tree in Figure 16 for each part of the software documented in [E.Info.SUM-1.PartOfSoftw].
[E.Just.DT.SUM-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.SUM-1] with the following properties:
— (if a decision from [DT.SUM-1.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.SUM-1.DN-1] is based on [E.Info.SUM-1.PartOfSoftw.FuncSaftyImp]; and
— (if a decision from [DT.SUM-1.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.SUM-1.DN-2] is based on [E.Info.SUM-1.PartOfSoftw.Immutable]; and
— (if a decision from [DT.SUM-1.DN-3] results in “NOT APPLICABLE”) the justification for the decision [DT.SUM-1.DN-3] is based on [E.Info.SUM-1.PartOfSoftw.AltMeasures].
# 6.3.1.4.4 Conceptual assessment
# 6.3.1.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether an update mechanism is implemented when it is required per SUM-1.
# 6.3.1.4.4.2 Preconditions
None.
# 6.3.1.4.4.3 Assessment units
Figure 16 — Decision Tree for requirement SUM-1
For each part of the software documented in [E.Info.SUM-1.PartOfSoftw], check whether the path through the decision tree documented in [E.Info.DT.SUM-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.SUM-1], check that its justification documented in [E.Just.DT.SUM-1] describes the security assets and/or privacy assets affected by the software as well as whether the software is updatable and, when not, the reasons.
# 6.3.1.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.SUM-1] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.SUM-1] ends with “FAIL”; and
— the information provided in [E.Just.DT.SUM-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SUM-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SUM-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.SUM-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SUM-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.3.1.4.5 Functional completeness assessment
None.
# 6.3.1.4.6 Functional sufficiency assessment
# 6.3.1.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the equipment supports update mechanisms for parts of the software affecting security assets and/or privacy assets as documented in [E.Info.SUM-1.PartOfSoftw.SUM].
# 6.3.1.4.6.2 Preconditions
The equipment is in an operational state.
For each update mechanism described in [E.Info.SUM-1.PartOfSoftw.SUM], the manufacturer provides updated software (in the following: SW-a) which is integrity-protected and authenticity-protected using a mechanism that the equipment natively supports.
# 6.3.1.4.6.3 Assessment units
For each update mechanism documented in [E.Info.SUM-1.PartOfSoftw.SUM] which ends with a PASS verdict in the SUM-1 conceptual assessment, install SW-a on the equipment.
# 6.3.1.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that an installation of SW-a is not successful for an update mechanism documented in [E.Info.SUM-1.PartOfSoftw.SUM].
The verdict FAIL for the assessment case is assigned if there is evidence that an installation of SW-a is not successful for an update mechanism documented in [E.Info.SUM-1.PartOfSoftw.SUM].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.3.2 [SUM-2] Secure updates
# 6.3.2.1 Requirement
Each update mechanism as required per SUM-1 shall only install software whose integrity and authenticity are valid at the time of the installation.
# 6.3.2.2 Rationale
A secure software update mechanism ensures that the software that controls the equipment is not tampered via attacks on the update mechanism.
# 6.3.2.3 Guidance
A common approach for confirming that an update is valid is to verify, cryptographically, its integrity and authenticity based on a trust anchor. This can be done on the equipment or by another equipment that is trusted to perform this verification. For the latter the verified update is typically sent over a secure channel to the equipment, securely installed on the equipment.
NOTE A “Secure channel” typically preserves the security properties of the communicated information and can also include authorized and authenticated personnel providing the validated software update locally (example of technical or organisational measures).
A manufacturer can provide a secure method to install alternative software not provided by the manufacturer themselves, for example allowing a user to install alternative software on a home router.
It is a security best practice to prevent downgrading the software to an older version.
Due to some security update the product might return to default setting requiring to re-enter credentials and configuration data.
The use of SCM-3 is appropriate when a software update contains confidential cryptographic keys.
# 6.3.2.4 Assessment criteria
# 6.3.2.4.1 Assessment objective
The assessment addresses the requirement SUM-2.
# 6.3.2.4.2 Implementation categories
[IC.SUM-2.AuthIntVal.Sign]: The methods to validate the software’s integrity and authenticity solely rely on digital signatures for software updates by authorized entities.
[IC.SUM-2.AuthIntVal.SecChan]: The methods to validate the software’s integrity and authenticity solely rely on a secure communication mechanism to the authorized software update’s source as required per SCM-1 and SCM-2.
[IC.SUM-2.AuthIntVal.AccContMech]: The methods to validate the software’s integrity and authenticity solely rely on access control mechanisms that only allow updates by authorized entities as required per ACM-1 combined with hash-protected software update.
[IC.SUM-2.AuthIntVal.Generic]: The methods to validate the software’s integrity and authenticity are different from [IC.SUM-2.AuthIntVal.Sign], [IC.SUM-2.AuthIntVal.SecChan] or [IC.SUM-2.AuthIntVal.AccContMech].
# 6.3.2.4.3 Required information
[E.Info.SUM-2.SUM]: Description of each update mechanism that can update a part of the software documented in [E.Info.SUM-1.PartOfSoftw] including:
(if the implementation is based on [IC.SUM-2.AuthIntVal.Sign]) [E.Info.SUM-2.SUM.Sign]: Description of the digital signature scheme used with a description of the underlying best practice cryptography as per [E.Info.CRY-1.Assets.Cryptography]; and
— (if the implementation is based on [IC.SUM-2.AuthIntVal.SecChan]) [E.Info.SUM-2.SUM.SecChan]: Description of the secure communication mechanism referring to [E.Info.SCM-1.SCM] with a description of the underlying best practice cryptography as per [E.Info.CRY-1.Assets.Cryptography]; and
(if the implementation is based on [IC.SUM-2.AuthIntVal.AccContMech]) [E.Info.SUM-2.SUM.AccContMech]: Description of the access control mechanism referring to [E.Info.ACM-2.SecurityAsset.ACM] and of the hash function referring to [E.Info.CRY-1.Assets.Cryptography]; and
— (if the implementation is based on [IC.SUM-2.AuthIntVal.Generic]) [E.Info.SUM-2.SUM.Generic]: Description of the methods used to validate the software’s integrity and authenticity.
[E.Info.DT.SUM-2]: Description of the selected path through the decision tree in Figure 17 for each update mechanism documented in [E.Info.SUM-2.SUM].
[E.Just.DT.SUM-2]: Justification for the selected path through the decision tree documented in [E.Info.DT.SUM-2] with the following properties:
— (if the implementation is based on [IC.SUM-2.AuthIntVal.Sign]) the justification for the decision [DT.SUM-2.DN-1] is based on [E.Info.SUM-2.SUM.Sign]; and
— (if the implementation is based on [IC.SUM-2.AuthIntVal.SecChan]) the justification for the decision [DT.SUM-2.DN-1] is based on [E.Info.SUM-2.SUM.SecChan]; and
— (if the implementation is based on [IC.SUM-2.AuthIntVal.AccContMech]) the justification for the decision [DT.SUM-2.DN-1] is based on [E.Info.SUM-2.SUM.AccContMech]; and
— (if the implementation is based on [IC.SUM-2.AuthIntVal.Generic]) the justification for the decision [DT.SUM-2.DN-1] is based on [E.Info.SUM-2.SUM.Generic].
# 6.3.2.4.4 Conceptual assessment
# 6.3.2.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the update mechanisms as required per SUM-1 only install software as required per SUM-2.
# 6.3.2.4.4.2 Preconditions
None.
# 6.3.2.4.4.3 Assessment units
Figure 17 — Decision Tree for requirement SUM-2
For each update mechanism documented in [E.Info.SUM-2.SUM], check whether the path through the decision tree documented in [E.Just.DT.SUM-2] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.SUM-2], check that its justification documented in [E.Just.DT.SUM-2] describes, based on references to [E.Info.SUM-2.SUM.Sign], the methods to ensure the validity of the software’s integrity and authenticity at the time of installation.
# 6.3.2.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.SUM-2] end with “PASS”; and
— the information provided in [E.Just.DT.SUM-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SUM-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SUM-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.SUM-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SUM-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.3.2.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the secure update mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.3.2.4.6 Functional sufficiency assessment
# 6.3.2.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the update mechanisms for parts of the software affecting security assets and/or privacy assets only install software whose integrity and authenticity are valid at the time of the installation as documented in [E.Info.SUM-2.SUM].
# 6.3.2.4.6.2 Preconditions
The equipment is in an operational state.
# 6.3.2.4.6.3 Assessment units
For each update mechanism documented in [E.Info.SUM-2.SUM]:
[AU.SUM-2.Sign]: When the implementation is based on [IC.SUM-2.AuthIntVal.Sign], functionally confirm that:
— it is implemented using best practice cryptography according to CRY-1; and
— an unsigned software update is not installed; and
— a software update with a modified signature is not installed; and
— a modified software update with a valid signature for the unmodified software update is not installed; and
— a software update with a signature from an unauthorized entity is not installed.
[AU.SUM-2.SecChan]: When the implementation is based on [IC.SUM-2.AuthIntVal.SecChan], functionally confirm that:
— it is implemented using the secure communication mechanism according to SCM; and
— a software update from an unauthorized source is not installed; and
— the secure communication channel does not allow to impersonate the authorized software updates source via a man-in-the-middle attack; and
— a software update that is modified during communication is not installed.
[AU.SUM-2.AccContMech]: When the implementation is based on [IC.SUM-2.AuthIntVal.AccContMech], functionally confirm that:
— it is implemented using the access control mechanism according to ACM; and
— a modified software update with a valid hash for the unmodified software update is not installed; and
— a software update with a hash generated by an unsupported hash function is not installed; and
— a software update provided by an unauthorized entity is not installed.
[AU.SUM-2.Generic]: When the implementation is based on [IC.SUM-2.AuthIntVal.Generic], functionally confirm that:
— a software update whose integrity is not valid is not installed and
— a software update whose authenticity is not valid is not installed.
# 6.3.2.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each update mechanism documented in [E.Info.SUM-2.SUM] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for an update mechanism documented in [E.Info.SUM-2.SUM] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.3.3 [SUM-3] Automated updates
# 6.3.3.1 Requirement
When the equipment is internet-connected, each update mechanism that is required per SUM-1 shall be capable of updating the software:
— without human intervention at the equipment; or
— via scheduling the installation of an update under human approval; or
— via triggering the installation of an update under human approval or supervision where there is the need to prevent any unexpected damage in the operational environment.
# 6.3.3.2 Rationale
In case of an existing publicly known exploitable vulnerability in the equipment, that can compromise security assets and privacy assets, an automated update mechanism can ensure that an available security update that addresses this vulnerability is applied without or with minimal human intervention preventing the vulnerability exploitation.
# 6.3.3.3 Guidance
This requirement demands at least one automated update mechanism for each software where SUM-1 requires an update mechanism.
NOTE 1 One automated update mechanism can be used to update multiple parts of the software.
Automated updates are carried out by machines without needing or with minimal human control or intervention.
Automatic updates are a step further where the equipment makes decisions and executes updates on its own without human intervention.
In specific cases involving safety or time-critical aspects, or dependency on compatibility of the updates in a network, the update can require some precautions and/or on-site verifications before it is initiated and therefore cannot be performed in an automatic way so that the operation of the application is not affected. In such cases, human intervention to trigger or schedule the update is needed.
In case the installation of the new software version fails, e.g., validation of the software image(s) is unsuccessful, a best practice is to apply a roll-back policy to re-activate the previous software version, unless not enough memory is available to store the update.
Triggering the installation of an update under human approval can for example consist of displaying a notification that an update is available and prompting the user to install the update via a secure update mechanism.
Simple automated updates from a user’s perspective improve the distribution rate of security updates.
NOTE 2 “Simple from a user’s perspective” can include:
— simple configuration of notifications related to the secure update mechanism,
— simple configuration of the update mechanism
— simple provision of a consent to fully automatic updates
Where fully automatic update mechanisms are possible, asking for user’s consent to activate it when putting the equipment into service, improves the distribution rate of security updates.
Checking the availability of new security updates after initialization and regularly improves the distribution rate of security updates.
# 6.3.3.4 Assessment criteria
# 6.3.3.4.1 Assessment objective
The assessment addresses the requirement SUM-3.
# 6.3.3.4.2 Implementation categories
Not applicable.
# 6.3.3.4.3 Required information
[E.Info.SUM-3.SUM]: Description of each update mechanism required per SUM-1, including:
— [E.Info.SUM-3.SUM.Automation]: Description of the means to automate the update mechanism.
[E.Info.DT.SUM-3]: Description of the selected path through the decision tree in Figure 18 for each update mechanism documented in [E.Info.SUM-3.SUM].
[E.Just.DT.SUM-3]: Justification for the selected path through the decision tree documented in [E.Info.DT.SUM-3] with the following properties:
— the justification for the decisions [DT.SUM-3.DN-2], [DT.SUM-3.DN-3] and [DT.SUM-3.DN-4] is based on [E.Info.SUM-3.SUM.Automation].
# 6.3.3.4.4 Conceptual assessment
# 6.3.3.4.4.1 Assessment purpose
The purpose of this assessment case is to determine whether each update mechanism supports automated updates as documented in [E.Info.SUM-3.SUM.Automation] as required per SUM-3.
# 6.3.3.4.4.2 Preconditions
None.
# 6.3.3.4.4.3 Assessment units
Figure 2 — Decision Tree for requirement SUM-3
For each update mechanism, check whether the path through the decision tree documented in [E.Info.DT.SUM-3] ends with “PASS” or “FAIL”.
For each path through the decision tree documented in [E.Info.DT.SUM-3], examine its justification documented in [E.Just.DT.SUM-3].
# 6.3.3.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.SUM-3] end with “PASS”; and
— the information provided in [E.Just.DT.SUM-3] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SUM-3].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SUM-3] ends with “FAIL”; or
— a justification provided in [E.Just.DT.SUM-3] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SUM-3].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.3.3.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the secure update mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.3.3.4.6 Functional sufficiency assessment
# 6.3.3.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the update mechanisms for parts of the software affecting security assets and/or privacy assets are automated as documented in [E.Info.SUM-3.SUM.Automation].
# 6.3.3.4.6.2 Preconditions
The equipment is in an operational state.
The manufacturer provides the means to perform automated updates.
# 6.3.3.4.6.3 Assessment units
For each update mechanism documented in [E.Info.SUM-3.SUM] functionally assess whether the automation implementation deviates from [E.Info.SUM-3.SUM.Automation] by:
— checking the software version on the equipment; and
— making a software update available at the source holding security updates; and
— checking whether the equipment performs the software update:
o without human intervention at the equipment; or
o via scheduling the installation of an update under human approval; or
o via triggering the installation of an update under human approval; and
— checking on the equipment that the software version has been updated to a new version number.
# 6.3.3.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that the implementation of an update mechanism required per SUM-1 deviates from [E.Info.SUM-3.SUM].
The verdict FAIL for the assessment case is assigned if there is evidence that the implementation of an update mechanism required per SUM-1 deviates from [E.Info.SUM-3.SUM].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.4[SSM] Secure storage mechanism
# 6.4.1 [SSM-1] Applicability of secure storage mechanisms
# 6.4.1.1 Requirement
The equipment shall always use secure storage mechanisms for protecting the security assets and privacy assets persistently stored on the equipment, except for persistently stored security assets and privacy assets where:
— the physical or logical measures in the target environment ensures the security asset or privacy asset stored on the equipment accessibility is limited to authorized entities.
# 6.4.1.2 Rationale
Secure storage mechanisms protect security assets and privacy assets from unauthorized access. If security assets or privacy assets are not appropriately secured, an attacker can access, tamper or delete the assets and compromise the equipment, which might lead to exposure of personal information.
# 6.4.1.3 Guidance
The security assets and privacy assets can be protected by e.g.:
— cryptographic measures like encryption to ensure confidentiality,
— cryptographic measures like digital signatures to ensure integrity and authenticity,
— access control using authentication or authorisation,
— hardware protection measures,
— physical protection measures.
The appropriate protection mechanism depends on the risks associated with the security assets and privacy assets to be stored and this might depend on:
— the criticality of the security assets and privacy assets;
— the amount of security assets and privacy assets;
— the duration for which the security assets and privacy assets need to be stored;
— the intended operational environment of use.
Removable storage that is not part of the equipment at the moment of placement on the market is not considered to be persistent storage but a storage that is meant to be used to move security assets or privacy assets between different equipment. Physical access to the equipment is required to remove such a storage from the equipment. This ensures access to the stored security assets or privacy assets is only available to authorized entities having physical access to the equipment.
Persistently stored data, not listed as security assets or privacy assets, may be protected by the secured storage mechanism but they are out of scope of this requirement.
# 6.4.1.4 Assessment criteria
# 6.4.1.4.1 Assessment objective
The assessment addresses the requirement SSM-1.
# 6.4.1.4.2 Implementation categories
Not applicable.
# 6.4.1.4.3 Required information
[E.Info.SSM-1.SecurityAsset]: Description of each security asset persistently stored on the equipment, including for each of its persistent storage:
— (if a secure storage mechanism is claimed to be not required because physical or logical measures in the environment’s target operational environment ensure that the stored security asset’s accessibility is limited to authorized entities) [E.Info.SSM-1.SecurityAsset.Environment]: Description of:
o physical or logical measures in the equipment’s targeted operational environment; and
o how entities are authenticated/authorized in the equipment’s targeted operational environment; and
— (if the persistent storage is provided by a secure storage mechanism) [E.Info.SSM-1.SecurityAsset.SSM]: Description of the secure storage mechanism.
[E.Info.SSM-1.PrivacyAsset]: Description of each privacy asset persistently stored on the equipment, including for each of its persistent storage:
— (if a secure storage mechanism is claimed to be not required because physical or logical measures in the environment’s target operational environment ensure that the stored privacy asset’s accessibility is limited to authorized entities) [E.Info.SSM-1.PrivacyAsset.Environment]: Description of:
o physical or logical measures in the equipment’s targeted operational environment; and
O how entities are authenticated/authorized in the equipment’s targeted operational environment; and
— (if the persistent storage is claimed to be required by a secure storage mechanism) [E.Info.SSM-1.PrivacyAsset.SSM]: Description of the secure storage mechanism.
[E.Info.DT.SSM-1]: Description of the selected path through the decision tree in Figure 19 for each security asset and privacy asset documented in [E.Info.SSM-1.SecurityAsset] and [E.Info.SSM-1.PrivacyAsset].
[E.Just.DT.SSM-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.SSM-1] with the following properties:
(if a decision from [DT.SSM-1.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.SSM-1.DN-1] is based on [E.Info.SSM-1.SecurityAsset.Environment] or [E.Info.SSM-1.PrivacyAsset.Environment]; and
— the justification for the decision [DT.SSM-1.DN-2] is based on [E.Info.SSM-1.SecurityAsset.SSM] or [E.Info.SSM-1.PrivacyAsset.SSM].
# 6.4.1.4.4 Conceptual assessment
# 6.4.1.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether secure storage mechanisms are implemented when it is required per SSM-1.
# 6.4.1.4.4.2 Preconditions
None.
# 6.4.1.4.4.3 Assessment units
Figure 19 — Decision tree for requirement SSM-1
For each security asset and privacy asset documented in [E.Info.SSM-1.SecurityAsset] and [E.Info.SSM-1.PrivacyAsset], check whether the path through the decision tree documented in [E.Info.DT.SSM-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.SSM-1], examine its justification documented in [E.Just.DT.SSM-1].
# 6.4.1.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.SSM-1] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.SSM-1] ends with “FAIL”; and
— the information provided in [E.Just.DT.SSM-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SSM-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SSM-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.SSM-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SSM-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.4.1.4.5 Functional completeness assessment
# 6.4.1.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether security assets documented in [E.Info.SSM-1.SecurityAsset] and privacy assets documented in [E.Info.SSM-1.PrivacyAsset] are complete.
# 6.4.1.4.5.2 Preconditions
The equipment is in an operational state.
# 6.4.1.4.5.3 Assessment units
Functionally assess whether there are security assets persistently stored on the equipment, which are not listed in [E.Info.SSM-1.SecurityAsset].
Functionally assess whether there are privacy assets persistently stored on the equipment, which are not listed in [E.Info.SSM-1.PrivacyAsset].
# 6.4.1.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all persistently stored security assets found are documented in [E.Info.SSM-1.SecurityAsset] and all privacy assets persistently stored found are documented in [E.Info.SSM-1.PrivacyAsset].
The verdict FAIL for the assessment case is assigned if a persistently stored security asset is found which is not documented in [E.Info.SSM-1.SecurityAsset] or a persistently stored privacy asset is found which is not documented in [E.Info.SSM-1.PrivacyAsset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.4.1.4.6 Functional sufficiency assessment
# 6.4.1.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether secure storage mechanisms are implemented when required per SSM-1.
# 6.4.1.4.6.2 Preconditions
The equipment is in an operational state.
# 6.4.1.4.6.3 Assessment units
For each security asset documented in [E.Info.SSM-1.SecurityAsset], functionally confirm it is persistently stored solely via secure storage mechanisms documented in [E.Info.SSM-1.SecurityAsset.SSM].
For each privacy asset documented in [E.Info.SSM-1.PrivacyAsset], functionally confirm it is persistently stored solely via secure storage mechanisms documented in [E.Info.SSM-1.PrivacyAsset.SSM].
# 6.4.1.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that:
— a security asset is persistently stored other than via secure storage mechanisms documented in [E.Info.SSM-1.SecurityAsset.SSM]; and
— a privacy asset is persistently stored other than via secure storage mechanisms documented in a [E.Info.SSM-1.PrivacyAsset.SSM].
The verdict FAIL for the assessment case is assigned if there is evidence that:
— a security asset is persistently stored other than via secure storage mechanisms documented in [E.Info.SSM-1.SecurityAsset.SSM]; or
— a privacy asset is persistently stored other than via secure storage mechanisms documented in a [E.Info.SSM-1.PrivacyAsset.SSM].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.4.2 [SSM-2] Appropriate integrity protection for secure storage mechanisms
# 6.4.2.1 Requirement
Each secure storage mechanism that is required per SSM-1 shall protect the integrity of security assets and privacy assets it stores persistently.
# 6.4.2.2 Rationale
When stored, security assets and privacy assets require protection against tampering. If the integrity of the security asset or privacy assets stored is not appropriately secured, an attacker can manipulate those assets, which might lead to violation of personal rights, e.g., misuse of personal information, false attribution, etc.
The integrity protection applies for encrypted as well as for unencrypted storage.
# 6.4.2.3 Guidance
Data can be protected from tampering by for instance:
— cryptographic measures like digital signatures,
— access control,
— hardware protection measures,
— physical protection measures.
# 6.4.2.4 Assessment criteria
# 6.4.2.4.1 Assessment objective
The assessment addresses the requirement SSM-2.
# 6.4.2.4.2 Implementation categories
[IC.SSM-2.DigitalSignature]: The method to ensure the integrity of stored security assets or privacy assets is based on digital signatures derived using a cryptographic secret provisioned during manufacturing, commissioning, or normal operation of an equipment.
[IC.SSM-2.AccessControl]: The method to ensure the integrity of stored security assets or privacy assets is using access control mechanisms that deny unauthorized modification.
[IC.SSM-2.OTProgrammable]: The method to ensure the integrity of stored security assets or privacy assets is based one-time programmable memory.
[IC.SSM-2.HardwareProtection]: The method to ensure the integrity of stored security assets or privacy assets is based on hardware protecting the memory.
[IC.SSM-2.Generic]: The methods to ensure the integrity and of stored security assets and privacy assets do not solely rely on [IC.SSM-2.DigitalSignature], [IC.SSM-2.AccessControl], [IC.SSM-2.OTProgrammable] or [IC.SSM-2.HardwareProtection].
# 6.4.2.4.3 Required information
[E.Info.SSM-2.SSM]: Description of each secure storage mechanism, including
— a list of all security assets and privacy assets it stores persistently; and
— (if the SSM implementation is based on [IC.SSM-2.DigitalSignature]) [E.Info.SSM-2.SSM.DigitalSignature]: Description of how integrity protection is realized using digital signature including:
o a description of the digital signature mechanism and the cryptography for the security assets and privacy assets it stores persistently; and
O a description of how the cryptographic secret used to derive the signature is provisioned onto or generated by the equipment; and
— (if the SSM implementation is based on [IC.SSM-2.AccessControl]) [E.Info.SSM-2.SSM.AccessControl]: Description of how integrity protection is realized using access control mechanisms, including:
o a description of the access control mechanisms and the corresponding access rights for the security assets and privacy assets it stores persistently; and
— (if the SSM implementation is based on IC.SSM-2.OTProgrammable) [E.Info.SSM-2.SSM.OTProgrammable]: Description of how integrity protection is realized using one-time programmable memory, including:
o a description of what type of one-time programmable memory is used for the security assets and privacy assets it stores persistently; and
— (if the SSM implementation is based on [IC.SSM-2.HardwareProtection]) [E.Info.SSM-2.SSM.HardwareProtection]: Description of how integrity protection is realized using hardware protection including:
o a description of what hardware protection is used for the security assets and privacy assets it stores persistently; and
(if the SSM implementation is based on [IC.SSM-2.Generic]) [E.Info.SSM-2.SSM.Generic]: Description of the integrity protection mechanism used to protect the security assets or privacy assets; and
— if it is claimed that the secure storage mechanism is compliant with recognised security standards or certification schemes, provide evidence to the recognised security standard or certification schemes the secure storage mechanism complies to.
NOTE The information above may not always be available to the manufacturer when the secure storage mechanism provided by a supplier which will not disclose such information for security reasons while providing all necessary security instructions to use the secure storage mechanism.
[E.Info.DT.SSM-2]: Description of the selected path through the decision tree in Figure 20 for each secure storage mechanism described in [E.Info.SSM-2.SSM].
[E.Just.DT.SSM-2]: Justification for the selected path through the decision tree documented in [E.Info.DT.SSM-2] with the following properties:
— (if the implementation is based on [IC.SSM-2.DigitalSignature]) the justification for the decision [DT.SSM-2.DN-1] is based on [E.Info.SSM-2.SSM.DigitalSignature]; and
(if the implementation is based on [IC.SSM-2.AccessControl]) the justification for the decision [DT.SSM-2.DN-1] is based on [E.Info.SSM-2.SSM.AccessControl]; and
— (if the implementation is based on [IC.SSM-2.OTProgrammable]) the justification for the decision [DT.SSM-2.DN-1] is based on [E.Info.SSM-2.SSM.OTProgrammable]; and
— (if the implementation is based on [IC.SSM-2.HardwareProtection]) the justification for the decision [DT.SSM-2.DN-1] is based on [E.Info.SSM-2.SSM.HardwareProtection]; and
— (if the implementation is based on [IC.SSM-2.Generic]) the justification for the decision [DT.SSM-2.DN-1] is based on [E.Info.SSM-2.SSM.Generic].
# 6.4.2.4.4 Conceptual assessment
# 6.4.2.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether secure storage mechanisms required by SSM-1 are implemented as required per SSM-2.
# 6.4.2.4.4.2 Preconditions
None.
# 6.4.2.4.4.3 Assessment units
Figure 20 — Decision tree for requirement SSM-2
For each secure storage mechanism in [E.Info.SSM-2.SSM] check whether the path through the decision tree documented in [E.Info.DT.SSM-2] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.SSM-2], examine its justification documented in [E.Just.DT.SSM-2].
# 6.4.2.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.SSM-2] end with “PASS”; and
— the information provided in [E.Just.DT.SSM-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SSM-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SSM-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.SSM-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SSM-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.4.2.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the secure storage mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.4.2.4.6 Functional sufficiency assessment
# 6.4.2.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the secure storage mechanisms required per SSM-1 provide the required integrity protection.
# 6.4.2.4.6.2 Preconditions
The equipment is in an operational state.
# 6.4.2.4.6.3 Assessment units
For each secure storage mechanism documented in [E.Info.SSM-2.SSM]:
[AU.SSM-2.DigitalSignature]: if the secure storage mechanism’s implementation is based on [IC.SSM-2.DigitalSignature], functionally confirm that:
— it is implemented according to [E.Info.SSM-2.SSM.DigitalSignature]; and
— the secret used to digitally sign the security assets or privacy assets cannot be intercepted, deduced, or extracted; and
— a modification of the security assets and privacy assets without valid signature is detected by the secure storage mechanism.
[AU.SSM-2.AccessControl]: if the secure storage mechanism’s implementation is based on [IC.SSM-2.AccessControl], functionally confirm that:
— it is implemented according to [E.Info.SSM-2.SSM.AccessControl]; and
— an unauthorized modification of the stored security assets and privacy assets is denied.
[AU.SSM-2.OTProgrammable]: if the secure storage mechanism’s implementation is based on [IC.SSM-2.OTProgrammable], functionally confirm that:
— it is implemented according to [E.Info.SSM-2.SSM.OTProgrammable]; and
— a modification of the security assets and privacy assets is not possible.
[AU.SSM-2.HardwareProtection]: if the secure storage mechanism’s implementation is based on [IC.SSM-2.HardwareProtection], functionally confirm that:
— it is implemented according to [E.Info.SSM-2.SSM.HardwareProtection]; and
— an unauthorized modification of the security assets and privacy assets is not possible or can be detected by the secure storage mechanism.
[AU.SSM-2.Generic]: if the secure storage mechanism’s implementation is based on [IC.SSM-2.Generic], functionally confirm:
— it is implemented according to [E.Info.SSM-2.SSM.Generic]; and
— an unauthorized modification of the security assets or privacy assets is not possible or can be detected by the secure storage mechanism.
# 6.4.2.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each secure storage mechanism documented in [E.Info.SSM-2.SSM] the confirmations in the implementation category dependent assessment units are successful.
The verdict FAIL for the assessment case is assigned if for any secure storage mechanism documented in [E.Info.SSM-2.SSM] a confirmation in the implementation category dependent assessment units is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.4.3 [SSM-3] Appropriate confidentiality protection for secure storage mechanisms
# 6.4.3.1 Requirement
Each secure storage mechanism that is required per SSM-1 shall protect the secrecy of confidential personal information, confidential privacy function configuration, and confidential security parameter persistently stored on the equipment.
# 6.4.3.2 Rationale
When stored, confidential personal information, confidential privacy function configuration, and confidential security parameter require protection from exposure. If such information is not appropriately secured, an attacker can access and misuse the equipment and stored data, which might lead to the exposure of personal information.
# 6.4.3.3 Guidance
Data can be protected from exposure by e.g.:
— cryptographic measures like encryption,
— access control,
— hardware protection measures.
# 6.4.3.4 Assessment criteria
# 6.4.3.4.1 Assessment objective
The assessment addresses the requirement SSM-3.
# 6.4.3.4.2 Implementation categories
[IC.SSM-3.Encryption]: The method to ensure the secrecy of stored confidential personal information, confidential privacy function configuration, and confidential security parameter is based on encryption using a secret provisioned during manufacturing, derived during commissioning or normal operation of an equipment.
[IC.SSM-3.AccessControl]: The method to ensure the secrecy of the stored confidential personal information, confidential privacy function configuration, and confidential security parameter is using access control mechanisms that deny unauthorized reading.
[IC.SSM-3.HardwareProtection]: The method to ensure the secrecy of stored confidential personal information, confidential privacy function configuration, and confidential security parameter based on hardware protection (e.g. scrambling, obfuscation, etc.).
[IC.SSM-3.Generic]: The methods to ensure the secrecy of stored confidential personal information, confidential privacy function configuration, and confidential security parameter do not solely rely on [IC.SSM-3.Encryption], [IC.SSM-3.AccessControl] or [IC.SSM-3.HardwareProtection].
# 6.4.3.4.3 Required information
[E.Info.SSM-3.SSM]: Description of each secure storage mechanism that persistently stores confidential personal information, confidential privacy function configuration or confidential security parameter, including:
— [E.Info.SSM-3.SSM.Asset]: List of all confidential personal information, confidential privacy function configuration and confidential security parameter it stores persistently; and
— (if the SSM implementation is based on [IC.SSM-3.Encryption]) [E.Info.SSM-3.SSM.Encryption]: Description of how secrecy is realized using encryption including:
o the encryption mechanism and the cryptography that are used to protect the confidentiality of the confidential personal information, confidential privacy function configuration and confidential security parameter it stores persistently; and
o how the secret used to encrypt the asset was provisioned or derived; and
— (if the SSM implementation is based on [IC.SSM-3.AccessControl]) [E.Info.SSM-3.SSM.AccessControl]: Description of how secrecy is realized using access control mechanisms including:
o a description of the access control mechanisms including the corresponding access rights for the confidential personal information, confidential privacy function configuration and confidential security parameter it stores persistently; and
— (if the SSM implementation is based on [IC.SSM-3.HardwareProtection]) [E.Info.SSM-3.SSM.HardwareProtection]: Description of how secrecy is realized using hardware protection including:
a description of what hardware protection is used for the confidential personal information, confidential privacy function configuration and confidential security parameter it stores persistently; and
(if the SSM implementation is based on [IC.SSM-3.Generic]) [E.Info.SSM-3.SSM.Generic]: Description of the confidentiality protection mechanism used to protect the secrecy of confidential personal information, confidential privacy function configuration or confidential security parameter it stores persistently; and
— if it is claimed that the secure storage mechanism is compliant with recognised security standards or certification schemes, provide evidence to the recognised security standard or certification schemes the secure storage mechanism complies to.
NOTE The information above may not always be available to the manufacturer when the secure storage mechanism is provided by a supplier which will not disclose such information for security reasons while providing all necessary security instructions to use the generation mechanism.
[E.Info.DT.SSM-3]: Description of the selected path through the decision tree in Figure 21 for each secure storage mechanism described in [E.Info.SSM-3.SSM].
[E.Just.DT.SSM-3]: Justification for the selected path through the decision tree documented in [E.Info.DT.SSM-3] with the following properties:
— (if the implementation is based on [IC.SSM-3.Encryption]) the justification for the decision [DT.SSM-3.DN-1] is based on [E.Info.SSM-3.SSM.Encryption]; and
(if the implementation is based on [IC.SSM-3.AccessControl]) the justification for the decision [DT.SSM-3.DN-1] is based on [E.Info.SSM-3.SSM.AccessControl]; and
— (if the implementation is based on [IC.SSM-3.HardwareProtection]) the justification for the decision [DT.SSM-3.DN-1] is based on [E.Info.SSM-3.SSM.HardwareProtection]; and
— (if the implementation is based on [IC.SSM-3.Generic]) the justification for the decision [DT.SSM-3.DN-1] is based on [E.Info.SSM-3.SSM.Generic].
# 6.4.3.4.4 Conceptual assessment
# 6.4.3.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether secure storage mechanisms required by SSM-1 that persistently store confidential personal information, confidential privacy function configuration or confidential security parameter are implemented as required per SSM-3.
# 6.4.3.4.4.2 Preconditions
None.
# 6.4.3.4.4.3 Assessment units
Figure 21 — Decision tree for requirement SSM-3
For each secure storage mechanism in [E.Info.SSM-3.SSM] check whether the path through the decision tree documented in [E.Info.DT.SSM-3] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.SSM-3], examine its justification documented in [E.Just.DT.SSM-3].
# 6.4.3.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.SSM-3] end with “PASS”; and
— the information provided in [E.Just.DT.SSM-3] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SSM-3].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SSM-3] ends with “FAIL”; or
— a justification provided in [E.Just.DT.SSM-3] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SSM-3].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.4.3.4.5 Functional completeness assessment
# 6.4.3.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the assets documented in [E.Info.SSM-3.SSM.Asset] are complete.
# 6.4.3.4.5.2 Preconditions
The equipment is in an operational state.
# 6.4.3.4.5.3 Assessment units
Functionally assess whether there are confidential security parameters, confidential personal information or confidential privacy function configurations persistently stored on the equipment, which are not listed in [E.Info.SSM-3.SSM.Asset].
# 6.4.3.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all persistently stored confidential security parameters found, all persistently stored confidential personal information found and all persistently stored confidential privacy function configurations found are documented in [E.Info.SSM-3.SSM.Asset].
The verdict FAIL for the assessment case is assigned if a persistently stored confidential security parameter is found or a persistently stored personal information is found or a persistently stored confidential privacy function configuration is found which is not documented in [E.Info.SSM-3.SSM.Asset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.4.3.4.6 Functional sufficiency assessment
# 6.4.3.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the secure storage mechanisms required per SSM-1 that persistently store confidential security parameters, confidential personal information or confidential privacy function configuration provide the required confidentiality protection.
# 6.4.3.4.6.2 Preconditions
The equipment is in an operational state.
# 6.4.3.4.6.3 Assessment units
For each secure storage mechanism documented in [E.Info.SSM-3.SSM]:
[AU.SSM-3.Encryption]: if the secure storage mechanism’s implementation is based on [IC.SSM-3.Encryption], functionally confirm that:
— it is implemented according to [E.Info.SSM-3.SSM.Encryption]; and
— the secret used to encrypt the confidential security parameters, confidential personal information or confidential privacy function configuration cannot be intercepted, deducted, or extracted; and
— reading confidential security parameters, confidential personal information and confidential privacy function configuration without access to the secret used for decryption is not possible.
[AU.SSM-3.AccessControl]: if the secure storage mechanism’s implementation is based on [IC.SSM-3.AccessControl], functionally confirm:
— it is implemented according to [E.Info.SSM-3.SSM.AccessControl]; and
— an unauthorized reading of the stored confidential security parameters, confidential personal information and confidential privacy function configuration is denied.
[AU.SSM-3.HardwareProtection]: if the secure storage mechanism’s implementation is based on [IC.SSM-3.HardwareProtection], functionally confirm:
— it is implemented according to [E.Info.SSM-3.SSM.HardwareProtection]; and
— the mechanism used to protect the confidentiality of the stored confidential security parameters, confidential personal information and confidential privacy function configuration cannot be broken or bypassed; and
— an unauthorized reading of the stored confidential security parameters, confidential personal information and confidential privacy function configuration is not possible.
[AU.SSM-3.Generic]: if the secure storage mechanism’s implementation is based on [IC.SSM-3.Generic], functionally confirm:
— it is implemented according to [E.Info.SSM-3.SSM.Generic]; and an unauthorized reading of the stored confidential security parameters, confidential personal information and confidential privacy function configuration is not possible.
# 6.4.3.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each secure storage mechanism documented in [E.Info.SSM-3.SSM] the confirmations in the implementation category dependent assessment units are successful.
The verdict FAIL for the assessment case is assigned if for any secure storage mechanism documented in [E.Info.SSM-3.SSM] a confirmation in the implementation category dependent assessment units is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.5[SCM] Secure communication mechanism
# 6.5.1 [SCM-1] Applicability of secure communication mechanisms
# 6.5.1.1 Requirement
The equipment shall always use secure communication mechanisms for communicating security assets and privacy assets with other entities via network interfaces, except for:
— communicating security assets or privacy assets whose transfer is protected by physical or logical measures in the targeted environment that ensure that security assets or privacy assets are not exposed to unauthorised entities; or
— communicating security assets whose exposure is part of establishing or managing a connection combined with additional measures to authenticate the connection or trust relation.
# 6.5.1.2 Rationale
The security assets or privacy assets of the equipment may be communicated to other communication partners for example when using web services. Ongoing communication, potentially enables an attacker having access to the communication to eavesdrop, manipulate or replay the communication, especially when using wireless technologies. The equipment needs to ensure that the communication is protected against those attacks using secure communication mechanisms.
# 6.5.1.3 Guidance
There are various technologies that can be applied to secure the communication (see also CRY-1) of the equipment. Best practice communication protocols with corresponding configuration ought to be applied to protect the communication against eavesdropping, manipulation, and replay. Typical measures therefore are a combination of authentication, integrity protection, encryption and replay protection. The measures can for example be applied to the communication channel or used for end-to-end protection. The equipment needs to offer best practice communication protocols to other communication partners by default. The way in which the initial relationship of trust is established between the equipment and another entity is crucial for the security of the subsequent communication.
It is strongly advised not to use protocols without or with weak security functionality for communication. For inevitable interoperability reasons, a deviation from this might be necessary. For the usage of such protocols, it needs to be foreseeable for the manufacturer that additional security measures are applied for example:
— The target environment of the equipment is an area which is only accessible for authorized persons and the radio communication range is short enough to render connection attempts from outside the building impractical. Typical examples for such areas are industrial sites or locked building service rooms in tenements.
— The target environment of the equipment is a specific network infrastructure using a virtual private network which tunnels the insecure protocol of the equipment.
Generally, it is recommended that the equipment notifies the user when an insecure communication is performed.
For equipment in local or personal networks (e.g., wearables) with limited user interface which does not allow to perform more complex pairing procedures, pairing protocols might be vulnerable to man-in-themiddle attacks. Here the attack vector needs to be reduced with additional measures (possession, knowledge or inherence) for the establishment of a connection, e.g., a limited time slot for a user interaction which is necessary to complete the pairing.
A network address exposed by a protocol is an example for data that might be personal information, which cannot be protected on the network layer.
# 6.5.1.4 Assessment criteria
# 6.5.1.4.1 Assessment objective
The assessment addresses the requirement SCM-1.
# 6.5.1.4.2 Implementation categories
Not applicable.
# 6.5.1.4.3 Required information
[E.Info.SCM-1.NetworkInterface]: Description of each network interface including:
— the description of the physical characteristics including:
o (in case of a radio interface) [E.Info.SCM-1.NetworkInterface.Radio]: Technology used, the occupied radio spectrum, the transmission power used on the radio interface and the modes of operation that are implemented; or
o (in case of a wired interface) [E.Info.SCM-1.NetworkInterface.Wired]: Electrical characteristics used on the wired interface and the modes of operation that are implemented; or
0 (in case of an optical interface) [E.Info.SCM-1.NetworkInterface.Optical]: Optical technology used on the interface and the modes of operation that are implemented; or
(in case of an acoustic interface) [E.Info.SCM-1.NetworkInterface.Acoustic]: Acoustic technology used on the interface and the modes of operation that are implemented; and
— the description of the logical characteristics including:
o [E.Info.SCM-1.NetworkInterface.Protocol]: Description of all communication protocols implemented on the interface documented in [E.Info.SCM-
1.NetworkInterface.Radio], [E.Info.SCM-1.NetworkInterface.Wired], [E.Info.SCM-1.NetworkInterface.Optical] or [E.Info.SCM-1.NetworkInterface.Acoustic] and the modes of operation that are implemented, the version of the protocol and, if applicable, the SW library that is used for the implementation; and
— the description of the configuration including:
applied configuration for the equipment and the available options to change the interface’s physical or logical behaviour.
[E.Info.SCM-1.SecurityAsset]: Description of each stored security asset that is communicated over network interfaces documented in [E.Info.SCM-1.NetworkInterface] and for which confidentiality, integrity or authenticity is needed in order to protect the equipment’s privacy assets, including:
(if a classification of the security assets is applicable) [E.Info.SCM-1.SecurityAsset.Class]: Security asset classification (e.g. root keys, master keys, wrapper keys or public keys) where security assets may be listed in groups as a single category if they are part of the same use case and the same security level; and
[E.Info.SCM-1.SecurityAsset.Com]: Description of the use case where the asset is communicated (e.g. pairing with base station) over a network interface documented in [E.Info.SCM-1.NetworkInterface]; and
— [E.Info.SCM-1.SecurityAsset.NetworkInterface]: Network interface used for communication of the security asset (from [E.Info.SCM-1.NetworkInterface]); and
(if transfer is protected by physical and logical measures in the targeted environment) [E.Info.SCM-1.SecurityAsset.TrustedEnv]: Description of the physical or logical measures in the equipment’s targeted operational environment that ensure that the assets are not exposed to unauthorised entities; and
— (if the assets are part of establishing or managing the connection) [E.Info.SCM-1.SecurityAssets.AddMeasures]: Description of the implemented additional measures to authenticate the connection or trust relation.
[E.Info.SCM-1.PrivacyAsset]: Description of each privacy asset that is communicated over network interfaces documented in [E.Info.SCM-1.NetworkInterface] and for which confidentiality, integrity or authenticity protection is needed, including:
(if a classification of the privacy assets is applicable) [E.Info.SCM-1.PrivacyAsset.Class]: Privacy asset classification (e.g., personal information, location, sensitive personal information); privacy assets may be listed in groups as a single category if they are part of the same use case and the same security level; and
[E.Info.SCM-1.PrivacyAsset.Com]: Description of the use case where the asset is communicated (e.g. pairing with base station) over a network interface documented in [E.Info.SCM-1.NetworkInterface]; and
[E.Info.SCM-1.PrivacyAsset.NetInterface]: Network interface used for communication of the privacy asset (from [E.Info.SCM-1.NetworkInterface]); and
(if transfer is protected by physical and logical measures in the targeted environment) [E.Info.SCM-1.PrivacyAsset.TrustedEnv]: Description of the physical or logical measures in the equipment’s targeted operational environment that ensures the assets are not exposed to unauthorised entities; and
— (if the assets are part of establishing or managing the connection) [E.Info.SCM-1.PrivacyAssets.AddMeasures]: Description of the implemented additional measures to authenticate the connection or trust relation.
[E.Info.SCM-1.SCM]: Description of each secure communication mechanism that is used to communicate security assets documented in [E.Info.SCM-1.SecurityAsset] and privacy assets documented in [E.Info.SCM-1.PrivacyAsset] over the network interfaces documented in [E.Info.SCM-1.NetworkInterface], including:
— [E.Info.SCM-1.SCM.Protocol]: Communication protocols where the mechanism is applied (from [E.Info.SCM-1.NetworkInterface.Protocol]); and
[E.Info.SCM-1.SCM.States]: Equipment states where the communication of security assets documented in [E.Info.SCM-1.SecurityAsset] and privacy assets documented in [E.Info.SCM-1.PrivacyAsset] occurs; and
[E.Info.SCM-1.SCM.SecObjectives]: Security objectives considering the intended functionality of the equipment and the analysed threats and potentially successful attack scenarios (e.g. exposure of data, manipulation of data, unauthorised control of the equipment); and
— (if the equipment supports establishment or management of a connection) Details of the establishment or management procedure.
[E.Info.DT.SCM-1]: Description of the selected path through the decision tree in Figure 22 for each of the relevant network interfaces documented in [E.Info.SCM-1.NetworkInterface].
NOTE Multiple valid paths may need to be documented due to the classification of security assets or privacy assets and the equipment states documented in [E.Info.SCM-1.SCM.States].
[E.Just.DT.SCM-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.SCM-1] with the following properties:
— (if a decision from [DT.SCM-1.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.SCM-1.DN-2] is based on [E.Info.SCM-1.SecurityAsset.TrustedEnv] and [E.Info.SCM-1.PrivacyAsset.TrustedEnv]; and
(if a decision from [DT.SCM-1.DN-3] results in “NOT APPLICABLE”) the justification for the decision [DT.SCM-1.DN-3] is based on [E.Info.SCM-1.SecurityAssets.AddMeasures] and [E.Info.SCM-1.PrivacyAssets.AddMeasures].
# 6.5.1.4.4 Conceptual assessment
# 6.5.1.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether secure communication mechanisms are implemented when it is required to protect the security assets documented in [E.Info.SCM-1.SecurityAsset] or privacy assets documented in [E.Info.SCM-1.PrivacyAsset] when communicated over network interfaces as required per SCM-1.
# 6.5.1.4.4.2 Preconditions
None.
# 6.5.1.4.4.3 Assessment units
Figure 22 — Decision Tree for requirement SCM-1
For each network interface documented in [E.Info.SCM-1.NetworkInterface], check whether the path through the decision tree documented in [E.Info.DT.SCM-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.SCM-1], examine its justification documented in [E.Just.DT.SCM-1].
# 6.5.1.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.SCM-1] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.SCM-1] ends with “FAIL”; and
— the information provided in [E.Just.DT.SCM-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SCM-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SCM-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.SCM-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SCM-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.5.1.4.5 Functional completeness assessment
# 6.5.1.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the documentation is complete.
# 6.5.1.4.5.2 Preconditions
The equipment is in an operational state.
# 6.5.1.4.5.3 Assessment units
Using up-to-date evaluation methods, functionally assess whether there are stored security assets communicated, which are not listed in [E.Info.SCM-1.SecurityAsset].
Using up-to-date evaluation methods, functionally assess whether there are privacy assets communicated, which are not listed in [E.Info.SCM-1.PrivacyAsset].
# 6.5.1.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all communicated stored security assets found are documented in [E.Info.SCM-1.SecurityAsset] and all privacy assets found are documented in [E.Info.SCM-1.PrivacyAsset].
The verdict FAIL for the assessment case is assigned if a communicated stored security asset is found which is not documented in [E.Info.SCM-1.SecurityAsset] or a privacy asset is found which is not documented in [E.Info.SCM-1.PrivacyAsset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.5.1.4.6 Functional sufficiency assessment
# 6.5.1.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the secure communication mechanisms are implemented when they are required.
# 6.5.1.4.6.2 Preconditions
The equipment is in an operational state.
# 6.5.1.4.6.3 Assessment units
For each security asset documented in [E.Info.SCM-1.SecurityAsset] and for each privacy asset documented in [E.Info.SCM-1.PrivacyAsset], functionally confirm, using up-to-date evaluation methods, the existence of secure communication mechanisms according to [E.Info.SCM-1.SCM].
# 6.5.1.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that a secure communication mechanism documented in [E.Info.SCM-1.SCM] is not implemented.
The verdict FAIL for the assessment case is assigned if there is evidence that a secure communication mechanism documented in [E.Info.SCM-1.SCM] is not implemented.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.5.2 [SCM-2] Appropriate integrity and authenticity protection for secure communication mechanisms
# 6.5.2.1 Requirement
Each secure communication mechanism that is required per SCM-1 shall apply best practices to protect the integrity and authenticity of the security assets and privacy assets communicated, except for communicating security assets or privacy assets where:
— a deviation from best practice for integrity or authenticity protection is required for interoperability reasons.
# 6.5.2.2 Rationale
During communication security assets and privacy assets require protection against manipulation. An attacker having gained access to the network might intercept and tamper the communication (man-inthe-middle attack). The equipment needs to ensure that the communication is protected against those attacks by using integrity and authenticity protection measures. The protection could be realized by the protocol used to communicate the security assets or privacy assets or by an additional protocol/additional measures.
The integrity and authenticity protection applies for encrypted as well as for unencrypted communications.
# 6.5.2.3 Guidance
In the context of secure communication, “best practice” addresses that approved protocols with corresponding configuration (see also CRY-1) are used and that the implementation of the protocol is regularly reviewed for vulnerabilities (see GEC-1).
The aim is to protect the communication against manipulation. Typical measures are a combination of authentication and integrity protection. The way in which the initial relationship of trust is established between the equipment and another entity is crucial for the security of the communication. The measures can for example be applied to the communication channel or used for “end-to- end” protection. Further, integrity and authenticity protection of communicated is typically realized by using Cipher-based Message Authentication Code (MAC) techniques.
A deviation from best practice is only possible for interoperability reasons within the intended equipment functionality. In this case compensating logical or physical measures need to be considered to ensure a comparable level of security.
The equipment needs to offer best practice to other communication partners by default, even if other protocols might also be needed for interoperability reasons. Appropriate measures may differ between the underlying use cases of the communication to fulfil the intended equipment functionality.
Examples for approved protocols which can be used to implement secure communication when best practice configuration (see also CRY-1) is applied are:
— Transport Layer Security (TLS)
— Wi-Fi Protected Access (WPA)
— Password Authenticated Connection Establishment (PACE)
— Symmetrical Cipher Methods (e.g., Advanced Encryption Standard – AES)
Insecure communication is often not caused by flaws in the protocol but by errors in its implementation. Therefore, requirement GEC-1 is important.
# 6.5.2.4 Assessment criteria
# 6.5.2.4.1 Assessment objective
The assessment addresses the requirement SCM-2.
# 6.5.2.4.2 Implementation categories
[IC.SCM-2.ManufSecret]: The method is to introduce the (initial) secret used to ensure integrity and authenticity of communicated privacy assets and security assets the production of the equipment. The secret is individual for an equipment and is only used inside it. The protection of integrity and authenticity itself is realized as channel or message based with a message authentication code based on the secret.
[IC.SCM-2.SecChanExchange]: The method to exchange initial secrets relies on an independent channel: The (initial) secret used to ensure integrity and authenticity of communicated privacy assets and security assets is solely exchanged via a second channel which is independent from the communication mechanism. The protection of integrity and authenticity itself is realized as channel or message based with a message authentication code based on the secret.
EXAMPLE Input of a shared key through a QR Code or manual entry of a secret
[IC.SCM-2.PKI-based]: The method to authenticate the certificate used to ensure integrity and authenticity of communicated privacy assets and security assets is solely based on the signature of the certificate issued by a trusted PKI. The protection of integrity and authenticity itself is realized channel or message based with a message authentication code based on the secret.
EXAMPLE Usage of X.509 PKI-Certificates for TLS
[IC.SCM-2.ThirdPartyTrust]: The method to authenticate the (initial) secret used to ensure integrity and authenticity of communicated privacy assets and security is solely based on an existing trust relation to a third party which confirms the authenticity of the secret. The protection of integrity and authenticity itself is realized channel or message based with a message authentication code based on the secret.
EXAMPLE Kerberos protocol
[IC.SCM-2.Generic]: The methods to ensure integrity and authenticity of communicated privacy assets (documented in [E.Info.SCM-2.PrivacyAsset]) and security assets do not solely rely on any of the methods described before in this section.
# 6.5.2.4.3 Required information
[E.Info.SCM-2.SecurityAsset]: Description of each stored security asset that is communicated over network interfaces documented in [E.Info.SCM-2.NetworkInterface] and for which integrity or authenticity protection is needed in order to protect the equipment’s privacy assets, including:
— [E.Info.SCM-2.SecurityAsset.Com]: Description of the use case where the asset is communicated (e.g. pairing with base station) over a network interface documented in [E.Info.SCM-2.NetworkInterface].
NOTE 1 The information of [E.Info.SCM-2.SecurityAsset] is a subset of [E.Info.SCM-1.SecurityAsset].
[E.Info.SCM-2.PrivacyAsset]: Description of each privacy asset that are communicated over network interfaces documented in [E.Info.SCM-2.NetworkInterface] and for which integrity or authenticity protection is needed:
[E.Info.SCM-2.PrivacyAsset.Com]: Description of the use case where the asset is communicated (e.g. registration at a specific webservice) over a network interface documented in [E.Info.SCM-2.NetworkInterface].
NOTE 2 This information of [E.Info.SCM-2.PrivacyAsset] is a subset of [E.Info.SCM-1.PrivacyAsset].
[E.Info.SCM-2.NetworkInterface]: Description of all network interfaces of the equipment, including
[E.Info.SCM-2.NetworkInterface.Protocol]: All communication protocols implemented and the modes of operation that are implemented, the version of the protocol and, if applicable, the SW library that is used for the implementation.
[E.Info.SCM-2.SCM]: Description of each secure communication mechanism that is required per SCM-1 for the integrity and authenticity protection of communicated privacy assets documented in [E.Info.SCM-2.PrivacyAsset] or security assets documented in [E.Info.SCM-2.SecurityAsset], including:
[E.Info.SCM-2.SCM.Capabilities]: Description of the security mechanisms and cryptographic modes that are used to protect the integrity and authenticity of security assets documented in [E.Info.SCM-2.SecurityAsset] or privacy assets documented in [E.Info.SCM-2.PrivacyAsset] while communicated over network interfaces security; and
(if the SCM implementation is based on [IC.SCM-2.ManufSecret]) [E.Info.SCM-2.SCM.ManufSecret]: Description of how the initial trust is achieved for integrity and authenticity protection and how it is implemented in the protocol documented in [E.Info.SCM-2.NetworkInterface.Protocol]; and
— (if the SCM implementation is based on [IC.SCM-2.SecChanExchange]) [E.Info.SCM-2.SCM.SecChanExchange]: Description of how the second channel is realized and how the secret is used for integrity and authenticity protection and how it is implemented in the protocol documented in [E.Info.SCM-2.NetworkInterface.Protocol]; and
(if the SCM implementation is based on [IC.SCM-2.PKI-based]) [E.Info.SCM-2.SCM.PKI-based]: Description of how the PKI-certificates are validated and how this is implemented for integrity and authenticity protection in the protocol documented in [E.Info.SCM-2.NetworkInterface.Protocol]; and
— (if the SCM implementation is based on [IC.SCM-2.ThirdPartyTrust]) [E.Info.SCM-2.SCM.ThirdPartyTrust]: Description of how the existing trust relation to a third party which confirms the authenticity of the secret is realized and how this is implemented for integrity and authenticity protection in the protocol documented in [E.Info.SCM-2.NetworkInterface.Protocol]; and
(if the SCM implementation is based on [IC.SCM-2.Generic]) [E.Info.SCM-2.SCM.Generic]: Description of how integrity and authenticity protection is realized in the protocol documented in [E.Info.SCM-2.NetworkInterface.Protocol]; and
— (if available) [E.Info.SCM-2.SCM.ImplDetail]: Refer to versioned standards or specifications where the selected implementation category is defined and, if applicable, the SW library that is used for the implementation; and
[E.Info.SCM-2.SCM.CCK]: The description of the properties of the confidential cryptographic keys used for integrity and authenticity protection (see CRY-1); and
— [E.Info.SCM-2.SCM.ThreatProtection]: The description on how the mechanism protects against the following security threats:
— Spoofing; and
— Tampering.
[E.Info.DT.SCM-2]: Description of the selected path through the decision tree in Figure 23 for each secure communication mechanism documented in [E.Info.SCM-2.SCM].
NOTE 3 Multiple valid paths may need documentation due to the classification of security assets or privacy assets and the equipment states documented in [E.Info.SCM-2.SCM]
[E.Just.DT.SCM-2]: Justification for the selected path through the decision tree documented in [E.Info.DT.SCM-2] with the following properties:
— the justification for the decision [DT.SCM-2.DN-1] is especially based on [E.Info.SCM-2.SecurityAsset.Com], [E.Info.SCM-2.PrivacyAsset.Com], [E.Info.SCM-2.SCM.ThreatProtection] and [E.Info.SCM-2.SCM.Capabilities]; and
(if a decision from [DT.SCM-2.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.SCM-2.DN-2] is especially based on [E.Info.SCM-2.SecurityAsset.Com], [E.Info.SCM-2.PrivacyAsset.Com] and [E.Info.SCM-2.SCM.Capabilities].
# 6.5.2.4.4 Conceptual assessment
# 6.5.2.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether each secure communication mechanism of the equipment is protecting the integrity and authenticity of security assets and privacy assets as required per SCM-2.
# 6.5.2.4.4.2 Preconditions
None.
# 6.5.2.4.4.3 Assessment units
Figure 23 — Decision Tree for requirement SCM-2
For each secure communication mechanism in [E.Info.SCM-2.SCM], and for each equipment state documented, check whether the path through the decision tree documented in [E.Info.DT.SCM-2] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.SCM-2], examine its justification documented in [E.Just.DT.SCM-2].
# 6.5.2.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.SCM-2] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.SCM-2] ends with “FAIL”; and
— the information provided in [E.Just.DT.SCM-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SCM-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SCM-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.SCM-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SCM-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.5.2.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the secure communication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.5.2.4.6 Functional sufficiency assessment
# 6.5.2.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the security assets and privacy assets communicated are protected against unnoticed tampering.
# 6.5.2.4.6.2 Preconditions
The equipment is in an operational state.
# 6.5.2.4.6.3 Assessment units
For each security asset documented in [E.Info.SCM-2.SecurityAsset] and privacy asset documented in [E.Info.SCM-2.PrivacyAsset], functionally confirm, using up-to-date evaluation methods, that integrity and authenticity protection is ensured by the communication mechanisms according to [E.Info.SCM-2.SCM] considering the equipment states documented, applying the documented implementation categories:
[AU.SCM-2.ManufSecret]: For [IC.SCM-2.ManufSecret], functionally confirm, as documented in [E.Info.SCM-2.SCM.ManufSecret], that:
— the secret introduced during production cannot be intercepted while the equipment is communicating via network; and
— a manipulated message is not accepted as being of integrity; and
— an unauthorized message is not accepted as authentic; and
-a successful MitM attack is not possible in case that channel-based communication is used.
[AU.SCM-2.SecChanExchange]: For [IC.SCM-2.SecChanExchange], functionally confirm, as documented in [E.Info.SCM-2.SCM.SecChanExchange], that:
— the secret cannot be intercepted using the assessed communication mechanism; and
— a manipulated message is not accepted as being of integrity; and
— an unauthorized message is not accepted as authentic; and
— a successful MitM attack is not possible in case that channel-based communication is used.
[AU.SCM-2.PKI-based]: For [IC.SCM-2.PKI-based], functionally confirm, as documented in [E.Info.SCM-2.SCM.PKI-based], that:
— a forged certificate is not accepted; and
— a manipulated message is not accepted as being of integrity; and
— an unauthorized message is not accepted as authentic; and
— a successful MitM attack is not possible in case that channel-based communication is used.
[AU.SCM-2.ThirdPartyTrust]: For [IC.SCM-2.ThirdPartyTrust], functionally confirm, as documented in [E.Info.SCM-2.SCM.ThirdPartyTrust], that:
— the response of the third party cannot be manipulated; and
— a manipulated message is not accepted as being of integrity; and
— an unauthorized message is not accepted as authentic; and
— a successful MitM attack is not possible in case that channel-based communication is used.
[AU.SCM-2.Generic]: For [IC.SCM-2.Generic], functionally confirm that:
— secrets used for the protection of authenticity and integrity cannot be intercepted and misused; and
— a manipulated message is not accepted as being of integrity; and
— an unauthorized message is not accepted as authentic; and
一a successful MitM attack is not possible in case that channel-based communication is used.
# 6.5.2.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each secure communication mechanism documented in [E.Info.SCM-2.SCM] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for a secure communication mechanism documented in [E.Info.SCM-2.SCM] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.5.3 [SCM-3] Appropriate confidentiality protection for secure communication mechanisms
# 6.5.3.1 Requirement
Each secure communication mechanism that is required per SCM-1 shall apply best practices to protect the confidentiality of communicated privacy assets and security assets where confidentiality protection of those is needed, except for communicating security assets or privacy assets where:
— a deviation from best practice for protecting confidentiality is required for interoperability reasons.
# 6.5.3.2 Rationale
During communication, generally security assets and privacy assets require protection against eavesdropping. An attacker having gained access to the network over which the equipment communicates security assets or privacy assets might monitor the communication. The equipment needs to ensure that the communication is protected against those attacks by providing confidentiality.
# 6.5.3.3 Guidance
In the context of secure communication, “best practice” addresses that approved protocols with corresponding configuration (especially concerning the integrated cryptography, see CRY-1) are used and that the implementation of the protocol is regularly reviewed for vulnerabilities (see GEC-1).
There are various security mechanisms that can be applied to secure the confidentiality of the communication (see also CRY-1). Best practice configuration ought to be applied to protect the communication from eavesdropping. This is typically achieved by symmetric encryption schemes. Those schemes can be applied to the communication channel or used for “end-to-end” protection. It is recommended to provide confidentiality by default between the communicating entities to use best practice cryptography. If there is the necessity for deviating from best practices (e.g., due to interoperability reasons) the resulting risks towards “best practice security” ought to be assessed. Appropriate measures may differ between the underlying use cases of the communication to fulfil the intended equipment functionality.
A deviation from best practice is only possible for interoperability reasons within the intended equipment functionality. In this case compensating logical or physical measures need to be considered to ensure a comparable level of security.
If confidentiality needs to be preserved for a long period of time it is recommended to use cryptography and cryptographic protocols best practices which enforce perfect forward secrecy for privacy assets and security assets communicated.
The cryptographic schemes used to protect the confidentiality of the data communicated is determined in the requirement CRY-1.
NOTE Authenticated encryption (AE) can be used to assure data confidentiality and authenticity in one cryptographic scheme. Those schemes can be used to address the requirement SCM-2 as well.
# 6.5.3.4 Assessment criteria
# 6.5.3.4.1 Assessment objective
The assessment addresses the requirement SCM-3.
# 6.5.3.4.2 Implementation categories
[IC.SCM-3.MessageEnc]: The sending entity and the receiving entity have already exchanged a secret via a trust relation which builds the basis for the encryption. The method is that each message encapsulates the content-encryption key to decrypt the payload of the message. This key is encrypted symmetrically or asymmetrically with the existing secret. An authorized receiving entity can only decrypt the payload, if it holds the key to decrypt the content-encryption key before.
[IC.SCM-3.ChannelEnc]: The sending entity and the receiving entity have already exchanged a secret via a trust relation which builds the basis for the encryption. The method is that the equipment and the receiving entity possess the same symmetric key which is used to decrypt and encrypt the payload of communicated messages.
[IC.SCM-3.Generic]: The methods to ensure the confidentiality of communicated privacy assets and security assets do not solely rely on any of the methods described before in this section.
# 6.5.3.4.3 Required information
[E.Info.SCM-3.SecurityAsset]: Description of each stored security asset that is communicated over network interfaces documented in [E.Info.SCM-3.NetworkInterface] and for which confidentiality is needed in order to protect the equipment’s privacy assets, including:
— [E.Info.SCM-3.SecurityAsset.Com]: Description of the use case where the asset is communicated (e.g. pairing with base station) over a network interface documented in [E.Info.SCM-3.NetworkInterface].
NOTE 1 The information of [E.Info.SCM-3.SecurityAsset] is a subset of [E.Info.SCM-1.SecurityAsset].
[E.Info.SCM-3.PrivacyAsset]: Description of all privacy assets that are communicated over network interfaces documented in [E.Info.SCM-3.NetworkInterface] and for which confidentiality is needed, including:
[E.Info.SCM-3.PrivacyAsset.Com]: Description of the use case where the asset is communicated (e.g. registration at a specific web service) over a network interface documented in [E.Info.SCM-3.NetworkInterface].
NOTE 2 The information of [E.Info.SCM-3.PrivacyAsset] is a subset of [E.Info.SCM-1.PrivacyAsset].
[E.Info.SCM-3.NetworkInterface]: Description of all network interfaces of the equipment, including
[E.Info.SCM-3.NetworkInterface.Protocol]: All communication protocols implemented and the modes of operation that are implemented, the version of the protocol and, if applicable, the SW library that is used for the implementation.
[E.Info.SCM-3.SCM]: Description of each secure communication mechanism that is required per SCM-1 for confidentiality protection of privacy assets documented in [E.Info.SCM-3.PrivacyAsset] or privacy assets documented in [E.Info.SCM-3.PrivacyAsset], including:
[E.Info.SCM-3.SCM.Capabilities]: Description of the security mechanisms and cryptographic modes that are used to protect the confidentiality of security assets documented in [E.Info.SCM-3.SecurityAsset] or privacy assets documented in [E.Info.SCM-3.PrivacyAsset] while communicated over network interfaces; and
(if the SCM implementation is based on [IC.SCM-3.MessageEnc]) [E.Info.SCM-3.SCM.MessageEnc]: Description of how the content-encryption key is generated and encrypted for confidentiality protection and how it is implemented in the protocol documented in [E.Info.SCM-3.NetworkInterface.Protocol]; and
— (if the SCM implementation is based on [IC.SCM-3.ChannelEnc]) [E.Info.SCM-3.SCM.ChannelEnc]: Description of how the session key is generated and used for confidentiality protection and how it is implemented in the protocol documented in [E.Info.SCM-3.NetworkInterface.Protocol]; and
(if the SCM implementation is based on [IC.SCM-3.Generic]) [E.Info.SCM-3.SCM.Generic]: Description of how confidentiality protection is realized in the protocol documented in [E.Info.SCM-3.NetworkInterface.Protocol]; and
— (if available) [E.Info.SCM-3.SCM.ImplDetail]: Refer to versioned standards or specifications where the selected implementation category is defined and, if applicable, the SW library that is used for the implementation; and
— [E.Info.SCM-3.SCM.CCK]: the properties of the confidential cryptographic keys used for confidentiality protection (see CRY-1); and
— [E.Info.SCM-3.SCM.ThreatProtection]: How the mechanism at least protects against the following security threats:
o Information disclosure; and
o Elevation of privilege.
[E.Info.DT.SCM-3]: Description of the selected path through the decision tree in Figure 24 for each secure communication mechanism documented in [E.Info.SCM-3.SCM].
NOTE 3 Multiple valid paths may need to be documented due to the classification of security assets or privacy assets and the equipment states documented in [E.Info.SCM-3.SCM].
[E.Just.DT.SCM-3]: Justification for the selected path through the decision tree documented in [E.Info.DT.SCM-3] with the following properties:
— The justification for the decision [DT.SCM-3.DN-1] is especially based on [E.Info.SCM-3.SecurityAsset.Com], [E.Info.SCM-3.PrivacyAsset.Com], [E.Info.SCM-3.SCM.ThreatProtection] and [E.Info.SCM-3.SCM.Capabilities]; and
(if a decision from [DT.SCM-3.DN-2] results in “NOT APPLICABLE”) The justification for the decision [DT.SCM-3.DN-2] is especially based on [E.Info.SCM-3.SecurityAsset.Com], [E.Info.SCM-3.PrivacyAsset.Com] and [E.Info.SCM-3.SCM.Capabilities].
# 6.5.3.4.4 Conceptual assessment
# 6.5.3.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether each secure communication mechanism of the equipment is protecting the confidentiality of privacy assets (documented in [E.Info.SCM-3.PrivacyAsset]) and security assets (documented in [E.Info.SCM-3.SecurityAsset]) while communicated as required per SCM-3.
# Preconditions
None.
# 6.5.3.4.4.2 Assessment units
Figure 24 — Decision tree for requirement SCM-3
For each secure communication mechanism documented in [E.Info.SCM-3.SCM], and for each equipment state documented, check whether the path through the decision tree documented in [E.Info.DT.SCM-3] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.SCM-3], examine its justification documented in [E.Just.DT.SCM-3].
# 6.5.3.4.4.3 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.SCM-3] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.SCM-3] ends with “FAIL”; and
— the information provided in [E.Just.DT.SCM-3] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SCM-3].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SCM-3] ends with “FAIL”; or
— a justification provided in [E.Just.DT.SCM-3] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SCM-3].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.5.3.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the secure communication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.5.3.4.6 Functional sufficiency assessment
# 6.5.3.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the security assets and privacy assets communicated are protected against eavesdropping.
# 6.5.3.4.6.2 Preconditions
The equipment is in an operational state.
# 6.5.3.4.6.3 Assessment units
Perform a legitimate communication for each security asset documented in [E.Info.SCM-3.SecurityAsset] and privacy asset documented in [E.Info.SCM-3.PrivacyAsset], between the equipment and an authorised communication endpoint. Functionally confirm, using up-to-date evaluation methods, that confidentiality protection is ensured by the communication mechanisms according to [E.Info.SCM-3.SCM] considering the equipment states documented, applying the documented implementation categories:
[AU.SCM-3.MessageEnc]: For [IC.SCM-3.MessageEnc], functionally confirm, as documented in [E.Info.SCM-3.SCM.MessageEnc], that:
— the key inside the message which is used to encrypt the payload cannot be disclosed; and
— the communicated security assets and privacy assets cannot be eavesdropped.
[AU.SCM-3.ChannelEnc]: For [IC.SCM-3.ChannelEnc], functionally confirm, as documented in [E.Info.SCM-3.SCM.ChannelEnc], that:
— the key which is used to encrypt the messages inside the communication channel cannot be intercepted; and
— the communicated security assets and privacy assets cannot be eavesdropped.
[AU.SCM-3.Generic]: For [IC.SCM-3.Generic], functionally confirm, as documented in [E.Info.SCM-3.SCM.Generic], that:
— the secret used to encrypt the message cannot be intercepted or eavesdropped; and
— the encrypted content of the message cannot be eavesdropped or disclosed.
# 6.5.3.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each secure communication mechanism documented in [E.Info.SCM-3.SCM] the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for an secure communication mechanism documented in [E.Info.SCM-3.SCM] a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.5.4 [SCM-4] Appropriate replay protection for secure communication mechanisms
# 6.5.4.1 Requirement
Each secure communication mechanism that is required per SCM-1 shall apply best practices to protect the security assets and the privacy assets communicated against replay attacks, except for communicating security assets or privacy assets where:
— a duplicate transfer does not impose a threat of a replay attack; or
— a deviation from best practice for replay protection is required for interoperability reasons.
# 6.5.4.2 Rationale
A replay attack is a form of network attack in which valid data transmission is maliciously repeated. An attacker having gained access to the network might record the communication and replay it unchanged, causing undesired effects at the receiving entity. A replay attack poses a threat in particular if authentication can be undermined or unauthorized control commands can be submitted.
For example, if, during a login process of a user the password is communicated encrypted, but without replay protection (especially session hijacking protection), an attacker may be able to replay the encrypted login part of the communication, and thus gain maliciously authorized access to the system. A session hijacking attack consists of the exploitation of the web session control mechanism, which is normally managed for a session token.
The equipment needs to protect the communication against that class of attacks.
Based on a risk assessment use cases might be identified for which a replay protection might not be needed, e.g., when the data communicated does not lead to a state change at the receiving entity. For example, the request to retrieve an X.509 certificate from a server might not pose a risk for a replay attack.
# 6.5.4.3 Guidance
Replay attacks can typically be prevented by tagging each message of a communication session with a session ID and a counter. The session ID prevents replay attacks of the complete communication, while the counter prevents the replay of a specific messages within a communication session. Further, timestamps or a one-time encryption technique can be used to prevent replay attacks. Nevertheless, the implementation of replay attack protection is complex. Therefore, the usage of approved protocols which provide already replay attack protection needs to be considered first. Examples for approved protocols which can be used to implement secure communication when best practice configuration (see also CRY-1) is applied are:
— Transport Layer Security (TLS)
— Secure Socket Shell (SSH)
— Internet Protocol Security (IPsec)
# 6.5.4.4 Assessment criteria
# 6.5.4.4.1 Assessment objective
The assessment addresses the requirement SCM-4.
# 6.5.4.4.2 Implementation categories
[IC.SCM-4.SeqNumb]: The sending entity and the receiving entity have already exchanged a secret via a trust relation which builds the basis for the message authentication code to ensure the integrity of the communication. The method is that a unique sequence number is assigned to each message transmitted. When the recipient receives a message, it checks the sequence number to ensure that it has not been received before. If the sequence number has already been seen, the message is discarded as a replay attack.
NOTE 1 To protect against MitM Attacks the authenticity of the sequence number can be ensured by using it as input to the function generating the message authentication code (MAC).
[IC.SCM-4.TimeStamp]: The sending entity and the receiving entity have already exchanged a secret via a trust relation which builds the basis for the message authentication code to ensure the integrity of the communication. The method is that the equipment integrates timestamps in messages to ensure that they are not being replayed at a later point in time. The recipient checks the timestamp to make sure that the message was not generated too far in the past or future.
NOTE 2 To protect against MitM Attacks the authenticity of the timestamp can be ensured by using it as input to the function generating the message authentication code (MAC).
[IC.SCM-4.OneTimeEncKey]: The sending entity and the receiving entity have already exchanged a secret via a trust relation which builds the basis for the message authentication code to ensure the integrity of the communication. The method is that the equipment and the receiver establish a completely random session key, which is a type of code that is only valid for one transaction and cannot be reused.
[IC.SCM-4.Generic]: The methods to avoid replay attacks concerning communicated privacy assets security assets do not solely rely on any of the methods described before in this section.
# 6.5.4.4.3 Required information
[E.Info.SCM-4.SecurityAsset]: Description of each stored security asset that is communicated over network interfaces documented in [E.Info.SCM-4.NetworkInterface] and for which replay protection is needed in order to protect the equipment’s privacy assets, including:
— [E.Info.SCM-4.SecurityAsset.Com]: Description of the use case where the asset is communicated (e.g. pairing with base station) over a network interface documented in [E.Info.SCM-4.NetworkInterface].
NOTE 3 The information of [E.Info.SCM-4.SecurityAsset] is a subset of [E.Info.SCM-1.SecurityAsset].
[E.Info.SCM-4.PrivacyAsset]: Description of each privacy asset that is communicated over network interfaces documented in [E.Info.SCM-4.NetworkInterface] and for which replay protection is needed, including:
— [E.Info.SCM-4.PrivacyAsset.Com]: Description of the use case where the asset is communicated (e.g. pairing with base station) over a network interface documented in [E.Info.SCM-4.NetworkInterface].
NOTE 4 The information of [E.Info.SCM-4.PrivacyAsset] is a subset of [E.Info.SCM-1.PrivacyAsset].
[E.Info.SCM-4.NetworkInterface]: Description of each network interface of the equipment, including:
— [E.Info.SCM-4.NetworkInterface.Protocol]: All communication protocols implemented and the modes of operation that are implemented, the version of the protocol and, if applicable, the SW library that is used for the implementation.
[E.Info.SCM-4.SCM]: Description of each secure communication mechanism that is required per SCM-1 for replay protection of privacy assets documented in [E.Info.SCM-4.PrivacyAsset] or security assets documented in [E.Info.SCM-4.SecurityAsset], including:
[E.Info.SCM-4.SCM.Capabilities]: Description of the security mechanisms and cryptographic modes that are used to avoid replay attacks on communication containing security assets documented in [E.Info.SCM-4.SecurityAsset] or privacy assets documented in [E.Info.SCM-4.PrivacyAsset]; and
(if the SCM implementation is based on [IC.SCM-4.SeqNumb]) [E.Info.SCM-4.SCM.SeqNumb]: Description of how the sequence numbers are used and integrated in the message authentication code for replay protection and how it is implemented in the protocol documented in [E.Info.SCM-4.NetworkInterface.Protocol]; and
— (if the SCM implementation is based on [IC.SCM-4.TimeStamp]) [E.Info.SCM-4.SCM.TimeStamp]: Description of how the time stamps are used and integrated in the message authentication code for replay protection and how it is implemented in the protocol documented in [E.Info.SCM-4.NetworkInterface.Protocol]; and
— (if the SCM implementation is based on [IC.SCM-4.OneTimeEncKey]) [E.Info.SCM-4.SCM.OneTimeEncKey]: Description of how the one-time encryption key is generated and used for replay protection and how it is implemented in the protocol documented in [E.Info.SCM-4.NetworkInterface.Protocol]; and
(if the SCM implementation is based on [IC.SCM-4.Generic]) [E.Info.SCM-4.SCM.Generic]: Description of how replay protection is realized in the protocol documented in [E.Info.SCM-4.NetworkInterface.Protocol]; and
— (if standards or specifications where the selected implementation category is defined are available) [E.Info.SCM-4.SCM.ImplDetail]: Reference to versioned standards or specifications where the selected implementation category is defined and, if applicable, the SW library that is used for the implementation; and
— [E.Info.SCM-4.SCM.Repudiation]: Description of how the mechanism at least protects against the security threat “Repudiation”.
[E.Info.DT.SCM-4]: Description of the selected path through the decision tree in Figure 25 for each communication mechanism documented in [E.Info.SCM-4.SCM].
NOTE 5 Multiple valid paths may need to be documented due to the classification of security assets or privacy assets and the equipment states documented in [E.Info.SCM-4.SCM].
[E.Just.DT.SCM-4]: Justification for the selected path through the decision tree documented in [E.Info.DT.SCM-4] with the following properties:
— (if a decision from [DT.SCM-4.DN-1] results in “NOT APPLICABLE”) The justification for the decision [DT.SCM-4.DN-1] is based on [E.Info.SCM-4.SecurityAsset.Com], [E.Info.SCM-4.PrivacyAsset.Com], [E.Info.SCM-4.SCM.Capabilities] and [E.Info.SCM-4.SCM.Repudiation]; and (if a decision from [DT.SCM-4.DN-3] results in “NOT APPLICABLE”) The justification for the decision [DT.SCM-4.DN-3] is especially based on [E.Info.SCM-4.SecurityAsset.Com], [E.Info.SCM-4.PrivacyAsset.Com] and [E.Info.SCM-4.SCM.Capabilities].
# 6.5.4.4.4 Conceptual assessment
# 6.5.4.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether each secure communication mechanism of the equipment is protecting the communication of security assets and privacy assets communicated against replay attacks as required per SCM-4.
# 6.5.4.4.4.2 Preconditions
None.
# 6.5.4.4.4.3 Assessment units
Figure 3 — Decision tree for requirement SCM-4
For each secure communication mechanism in [E.Info.SCM-4.SCM], and for each equipment state documented, check whether the path through the decision tree documented in [E.Info.DT.SCM-4] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.SCM-4], examine its justification documented in [E.Just.DT.SCM-4].
# 6.5.4.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.SCM-4] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.SCM-4] ends with “FAIL”; and
— the information provided in [E.Just.DT.SCM-4] are correct justifications for all paths through the decision tree documented in [E.Info.DT.SCM-4].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.SCM-4] ends with “FAIL”; or — a justification provided in [E.Just.DT.SCM-4] is not correct or missing for a path through the decision tree documented in [E.Info.DT.SCM-4].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.5.4.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the secure communication mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.5.4.4.6 Functional sufficiency assessment
# 6.5.4.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the security assets and privacy assets communicated are protected against replay attacks.
# 6.5.4.4.6.2 Preconditions
The equipment is in an operational state.
# 6.5.4.4.6.3 Assessment units
Perform a legitimate communication for each security asset documented in [E.Info.SCM-4.SecurityAsset] and privacy asset documented in [E.Info.SCM-4.PrivacyAsset], between the equipment and an authorised communication endpoint. The communication sequences are recorded. Functionally confirm, using upto-date evaluation methods, that replay protection is ensured by the communication mechanisms according to [E.Info.SCM-4.SCM] considering the equipment states documented, applying the documented implementation categories:
[AU.SCM-4.SeqNumb]: For [IC.SCM-4.SeqNumb], functionally confirm, as documented in [E.Info.SCM-4.SCM.SeqNumb], that:
— the incoming message (part of the communication of security assets and privacy assets) with a repeating sequence number is not accepted.
[AU.SCM-4.TimeStamp]: For [IC.SCM-4.TimeStamp], functionally confirm, as documented in [E.Info.SCM-4.SCM.TimeStamp], that:
— the incoming message (part of the communication of security assets and privacy assets) with an irregular timestamp is not accepted.
[AU.SCM-4.OneTimeEncKey]: For [IC.SCM-4.OneTimeEncKey], functionally confirm, as documented in [E.Info.SCM-4.SCM.OneTimeEncKey], that:
— the encryption key cannot be intercepted; and
— that the duplicate (binary copy) of an already accepted message (part of the communication of security assets and privacy assets) is not accepted again.
[AU.SCM-4.Generic]: For [IC.SCM-4.Generic], functionally confirm, as documented in [E.Info.SCM-4.SCM.Generic], that:
— that the duplicate (binary copy) of an already accepted message (part of the communication of security assets and privacy assets) is not accepted again.
# 6.5.4.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each secure communication mechanism documented in [E.Info.SCM-4.SCM] with the corresponding methods to ensure replay protection for the communication of security assets and privacy assets the confirmations in the implementation category dependent assessment unit are successful.
The verdict FAIL for the assessment case is assigned if for any secure communication mechanism documented in [E.Info.SCM-4.SCM] with the corresponding methods to ensure replay protection for the communication of security assets and privacy assets a confirmation in the implementation category dependent assessment unit is not successful.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.6[LGM] Logging mechanism
# 6.6.1 [LGM-1] Applicability of logging mechanisms
# 6.6.1.1 Requirement
The equipment shall use logging mechanisms for internal activities that are relevant to privacy assets and their protection (referred to as events), except for:
— internal activities where a legal obligation prohibits logging.
# 6.6.1.2 Rationale
To provide information about such Events, the equipment will generate relevant logs. Such log information can be of support to help to identify, e.g. potential unusual equipment behaviour, security/data breaches.
# 6.6.1.3 Guidance
The manufacturer determines the purpose (and audience) for which logs might be created, what data might be collected and logged, and any log-specific requirements for protecting and handling the log data, e.g. provide the data to a SIEM (Security information and event management).
A subset of the events identified is typically configured to be collected by default. The manufacturer can allow the end user to change this logging configuration.
The following are typical examples of events to be logged:
— activities on the privacy assets such as adding, editing, combining, removing/archiving, deleting, changing of password, permitted or denied access attempts,
— change on settings which can lessen or improve data protection,
— activation or deactivation of security relevant sensors.
Examples of logging events are:
— activities on the privacy assets such as access, add, edit, remove/archive, delete,
— unauthorized access attempts.
Personal data captured in the logs are to be minimised to those absolutely necessary to support investigators investigating security breaches.
Products might be designed to prevent an attempt by an attacker to execute an unauthorized physical action. Nevertheless, detection, tamper logging and response are essential in the event of a tampering Event occurring.
Further details on logging can be seen in standards such as ISO/IEC27002 [3], Third edition, 2022-02, section 8.15.
NOTE 1 the following events might be logged: successful and rejected system access events; changes to personal data, traffic data or location data; files accessed and the type of access, including deletion of important data files.
NOTE 2 event logs might include, where applicable, user IDs, system activities, time stamp and details of relevant Events, equipment identity, system identifier and locations, network addresses and protocols.
# 6.6.1.4 Assessment criteria
# 6.6.1.4.1 Assessment objective
The assessment addresses the requirement clause LGM-1.
# 6.6.1.4.2 Implementation categories
Not applicable.
# 6.6.1.4.3 Required information
[E.Info.LGM-1.PrivacyAssetEvent]: Description of each internal activity that is relevant for privacy assets and their protection, including:
— (if a legal obligation prohibits logging of the internal activity) [E.Info.LGM-1.PrivacyAssetEvent.Legal]: References to all corresponding paragraph(s) or passages in all relevant legal documents, including a description on how this is applicable for the equipment’s internal activity; and
— (if no legal obligation prohibits logging of the internal activity) [E.Info.LGM-1.PrivacyAssetEvent.LGM]: Description of the logging mechanism used to log the event.
[E.Info.DT.LGM-1]: Description of the selected path through the decision tree in Figure 26 for each event documented in [E.Info.LGM-1.PrivacyAssetEvent].
[E.Just.DT.LGM-1]: Justification for each selected path through the decision tree documented in [E.Info.DT.LGM-1] with the following properties:
— (if a decision from [DT.LGM-1.DN-1] results in “NOT APPLICABLE”) the justification for the decision DT.LGM-1.DN-1 is based on [E.Info.LGM-1.PrivacyAssetEvent.Legal]; and
— the justification for the decision [DT.LGM-1.DN-2] is based on [E.Info.LGM-1.PrivacyAssetEvent.LGM].
# 6.6.1.4.4 Conceptual assessment
# 6.6.1.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether a logging mechanism is implemented when it is required per LGM-1.
# 6.6.1.4.4.2 Preconditions
None.
# 6.6.1.4.4.3 Assessment units
Figure 26 — Decision Tree for requirement LGM-1
For each event documented in [E.Info.LGM-1.PrivacyAssetEvent], check whether the path through the decision tree documented in [E.Info.DT.LGM-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.LGM-1], examine its justification documented in [E.Just.DT.LGM-1].
# 6.6.1.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.LGM-1] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.LGM-1] ends with “FAIL”; and
— the information provided in [E.Just.DT.LGM-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.LGM-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.LGM-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.LGM-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.LGM-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.6.1.4.5 Functional completeness assessment
None.
# 6.6.1.4.6 Functional sufficiency assessment
# 6.6.1.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether logging mechanisms are implemented when required per LGM-1.
# 6.6.1.4.6.2 Preconditions
The equipment is in an operational state.
# 6.6.1.4.6.3 Assessment units
For each event documented in [E.Info.LGM-1.PrivacyAssetEvent], functionally confirm whether the events are logged by logging mechanisms documented in [E.Info.LGM-1.PrivacyAssetEvent.LGM] by:
— generating the event; and
— accessing related log data.
# 6.6.1.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that a logging mechanism documented in [E.Info.LGM-1.PrivacyAssetEvent.LGM] is not implemented.
The verdict FAIL for the assessment case is assigned if there is evidence that a logging mechanism documented in [E.Info.LGM-1.PrivacyAssetEvent.LGM] is not implemented.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.6.2 [LGM-2] Persistent storage of log data
# 6.6.2.1 Requirement
Logging mechanisms that are required per LGM-1 shall store log data for related events in the equipment’s persistent storage, except for events where:
— related log data is stored outside the equipment.
# 6.6.2.2 Rationale
Event logs have to be persistent after power cycling of the equipment to prevent their accidental or deliberate erasure.
# 6.6.2.3 Guidance
None.
# 6.6.2.4 Assessment criteria
# 6.6.2.4.1 Assessment objective
The assessment addresses the requirement LGM-2.
# 6.6.2.4.2 Implementation categories
Not applicable.
# 6.6.2.4.3 Required information
[E.Info.LGM-2.LGM]: Description of each logging mechanism that is required per LGM-1, including:
— a description of the logged events, including:
o (if log data storage in equipment’s persistent storage is claimed to be required) [E.Info.LGM-2.LGM.InternalStorage]: The storage location of log data for related events on the equipment and a description of how persistence of the stored log data is ensured; and
o (if log data storage in equipment’s persistent storage is claimed to be not required because storage happens outside the equipment) [E.Info.LGM-2.LGM.ExternalStorage]: Description of the equipment’s functionality to support storage of log data outside the equipment.
[E.Info.DT.LGM-2]: Description of the selected path through the decision tree in Figure 27 for each logging mechanism documented in [E.Info.LGM-2.LGM].
[E.Just.DT.LGM-2]: Justification for each selected path through the decision tree documented in [E.Info.DT.LGM-2] with the following properties:
— (if a decision from [DT.LGM-2.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.LGM-2.DN-1] is based on [E.Info.LGM-2.LGM.ExternalStorage]; and
— the justification for the decision [DT.LGM-2.DN-2] is based on [E.Info.LGM-2.LGM.InternalStorage].
# 6.6.2.4.4 Conceptual assessment
# 6.6.2.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the logging mechanisms that are required per LGM-1 store log data persistently as required per LGM-2.
# 6.6.2.4.4.2 Preconditions
None.
# 6.6.2.4.4.3 Assessment units
Figure 27 — Decision Tree for requirement LGM-2
For each logging mechanism documented in [E.Info.LGM-2.LGM] check whether the path through the decision tree documented in [E.Info.DT.LGM-2] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.LGM-2], examine its justification documented in [E.Just.DT.LGM-2].
# 6.6.2.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.LGM-2] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.LGM-2] ends with “FAIL”; and
— the information provided in [E.Just.DT.LGM-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.LGM-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.LGM-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.LGM-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.LGM-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.6.2.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the logging mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.6.2.4.6 Functional sufficiency assessment
# 6.6.2.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether logging mechanisms are implemented as documented in [E.Info.LGM-2.LGM].
# 6.6.2.4.6.2 Preconditions
The equipment is in an operational state.
# 6.6.2.4.6.3 Assessment units
For each logging mechanism documented in [E.Info.LGM-2.LGM] where [E.Info.LGM-2.LGM.InternalStorage] indicates that log data for related events is stored in equipment’s persistent storage, functionally confirm that the log data for the related events is stored in equipment’s persistent storage by:
— generating the events; and
— accessing the equipment’s storage location of related log data and checking that the log data is present.
# 6.6.2.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that the processing of log data for related events deviates from [E.Info.LGM-2.LGM.InternalStorage].
The verdict FAIL for the assessment case is assigned if there is evidence that the processing of log data for related events deviates from [E.Info.LGM-2.LGM.InternalStorage].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.6.3 [LGM-3] Minimum number of persistently stored events
# 6.6.3.1 Requirement
All log data stored in equipment’s persistent storage by logging mechanisms that are required per LGM-1 shall always include:
— a minimum number of the latest events; and
— the latest event.
# 6.6.3.2 Rationale
A minimum number of events to be retained is required to ensure that sufficient audit trail exists for investigations to be carried out effectively.
# 6.6.3.3 Guidance
According to the intended functionality of the equipment, the minimum number of Events that are stored on the equipment is typically found in user documentation.
Legal obligations regarding retention times and minimum number of stored events have to be followed.
# 6.6.3.4 Assessment criteria
# 6.6.3.4.1 Assessment objective
The assessment addresses the requirement LGM-3.
# 6.6.3.4.2 Implementation categories
Not applicable.
# 6.6.3.4.3 Required information
[E.Info.LGM-3.Events]: Description of the logged events, where related log data is persistently stored on the equipment.
[E.Info.LGM-3.Quantity]: Minimum number of the latest events for which log data can be persistently stored on the equipment simultaneously and a description of the log data’s storage locations.
[E.Info.DT.LGM-3]: Description of the selected path through the decision tree in Figure 28.
[E.Just.DT.LGM-3]: Justification for the selected path through the decision tree documented in [E.Info.DT.LGM-3] with the following property:
— the justification for the decision [DT.LGM-3.DN-1] is based on [E.Info.LGM-3.Quantity]
# 6.6.3.4.4 Conceptual assessment
# 6.6.3.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the minimum number of persistently stored logged events is defined as required per LGM-3.
# 6.6.3.4.4.2 Preconditions
None.
# 6.6.3.4.4.3 Assessment units
Figure 28 — Decision Tree for requirement LGM-3
Check whether the path through the decision tree documented in [E.Info.DT.LGM-3] ends with “PASS”.
For the path through the decision tree documented in [E.Info.DT.LGM-3], examine its justification documented in [E.Just.DT.LGM-3].
# 6.6.3.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.LGM-3] end with “PASS”; and
— the information provided in [E.Just.DT.LGM-3] are correct justifications for all paths through the decision tree documented in [E.Info.DT.LGM-3].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.LGM-3] ends with “FAIL”; or
— a justification provided in [E.Just.DT.LGM-3] is not correct or missing for a path through the decision tree documented in [E.Info.DT.LGM-3].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.6.3.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the logging mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.6.3.4.6 Functional sufficiency assessment
# 6.6.3.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the number of latest events for which log data can be persistently stored on the equipment simultaneously documented in [E.Info.LGM-3.Quantity] can be persistently stored by the equipment.
# 6.6.3.4.6.2 Preconditions
The equipment is in an operational state.
# 6.6.3.4.6.3 Assessment units
Functionally confirm the minimum number of logged events documented in [E.Info.LGM-3.Quantity] by
generating events documented in [E.Info.LGM-3.Events] to reach the minimum number of logged events documented in [E.Info.LGM-3.Quantity]; and
— accessing the equipment’s storage location of related log data and counting the number of logged events.
# 6.6.3.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that the number of logged events persistently storable on the equipment simultaneously can be lower than documented in [E.Info.LGM-3.Quantity].
The verdict FAIL for the assessment case is assigned if there is evidence that the number of logged events persistently storable on the equipment simultaneously can be lower than documented in [E.Info.LGM-3.Quantity].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.6.4 [LGM-4] Time-related information of persistently stored dog data
# 6.6.4.1 Requirement
All log data stored in equipment’s persistent storage by logging mechanisms that are required per LGM-1 shall include:
— a timestamp if real time is available on the equipment; and
— time-related information if real time is not available on the equipment.
# 6.6.4.2 Rationale
A timestamp or time-related information incorporating the time of occurrence of each event is needed to aid investigations to understand the temporal order of the events and to compare with logs on other equipment.
# 6.6.4.3 Guidance
Time-related information might be the period of time, in seconds, since power up of the equipment, or simply the sequence of events.
# 6.6.4.4 Assessment criteria
# 6.6.4.4.1 Assessment objective
The assessment addresses the requirement LGM-4.
# 6.6.4.4.2 Implementation categories
Not applicable.
# 6.6.4.4.3 Required information
[E.Info.LGM-4.Events]: Description of the logged events, where related log data is persistently stored on the equipment.
[E.Info.LGM-4.LGM]: Description of each logging mechanism that is required per LGM-1 that generates log data stored in equipment’s persistent storage, including:
(if real time information can be available on the equipment) [E.Info.LGM-4.LGM.Timestamp]: Description of each real time source and the corresponding timestamp included in the persistently stored log data; and
— (if real time information is not reliably available on the equipment) [E.Info.LGM-4.LGM.Timerelated]: Description of the time-related information included in the persistently stored log data.
[E.Info.DT.LGM-4]: Description of the selected path through the decision tree in Figure 29 for each logging mechanism documented in [E.Info.LGM-4.LGM].
[E.Just.DT.LGM-4]: Justification for each selected path through the decision tree documented in [E.Info.DT.LGM-4] with the following properties:
— the justification for the decision [DT.LGM-4.DN-1] is based on [E.Info.LGM-4.LGM.Timestamp]; and
— the justification for the decision [DT.LGM-4.DN-2] is based on [E.Info.LGM-4.LGM.Timerelated].
# 6.6.4.4.4 Conceptual assessment
# 6.6.4.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether logged events have the information required per LGM-4.
# 6.6.4.4.4.2 Preconditions
None.
# 6.6.4.4.4.3 Assessment units
Figure 29 — Decision Tree for requirement LGM-4
For each logging mechanism documented in [E.Info.LGM-4.LGM], check whether the path through the decision tree documented in [E.Info.DT.LGM-4] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.LGM-4], examine its justification documented in [E.Just.DT.LGM-4].
# 6.6.4.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.LGM-4] end with “PASS”; and
— the information provided in [E.Just.DT.LGM-4] are correct justifications for all paths through the decision tree documented in [E.Info.DT.LGM-4].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.LGM-4] ends with “FAIL”; or — a justification provided in [E.Just.DT.LGM-4] is not correct or missing for a path through the decision tree documented in [E.Info.DT.LGM-4].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.6.4.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the logging mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.6.4.4.6 Functional sufficiency assessment
# 6.6.4.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the logging mechanisms are implemented as documented in [E.Info.LGM-4.LGM] regarding its timestamps and time-related information.
# 6.6.4.4.6.2 Preconditions
The equipment is in an operational state.
# 6.6.4.4.6.3 Assessment units
(If the equipment can operate with real time information available) For each logging mechanism documented in [E.Info.LGM-4.LGM], functionally confirm that log data persistently stored on the equipment includes timestamps as documented in [E.Info.LGM-4.LGM.Timestamp] when real time information is available by:
— ensuring that real time information is available to the equipment; and
— generating events documented in [E.Info.LGM-4.Events]; and
— accessing the equipment’s storage location of related log data and checking that there are timestamps.
(If the equipment can operate with real time information not available) For each logging mechanism documented in [E.Info.LGM-4.LGM], functionally confirm that log data persistently stored on the equipment includes time-related information as documented in [E.Info.LGM-4.LGM.Timerelated] when real time information is not available by:
— ensuring that real time information is not available to the equipment; and
— generating events documented in [E.Info.LGM-4.Events]; and
— accessing the equipment’s storage location of related log data and checking that there is timerelated information.
# 6.6.4.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if for each logging mechanism documented in [E.Info.LGM-4.LGM] there is no evidence that:
— persistently stored log data does not include a timestamp when real time information is available; and
persistently stored log data does not include time-related information when real time information is not available.
The verdict FAIL for the assessment case is assigned if for a logging mechanism documented in [E.Info.LGM-4.LGM] there is evidence that:
— persistently stored log data does not include a timestamp when real time information is available; or
persistently stored log data does not include time-related information when real time information is not available.
# 6.7[DLM] Deletion mechanism
# 6.7.1 [DLM-1] Applicability of deletion mechanisms
# 6.7.1.1 Requirement
The equipment shall provide a deletion mechanism that allows a user to delete their personal data and sensitive security parameters stored on the equipment.
# 6.7.1.2 Rationale
This requirement is needed to prevent the risk of exposing personal data regarding disposal or replacement of the equipment.
# 6.7.1.3 Guidance
The user is generally the individual who uses the equipment. A user deletes his/her own personal data.
An authorized user is someone who's been granted access to the equipment by a user. An authorized user deletes personal data to which he/she has access.
However, there are cases where another user with administrator rights, separate from the user whose personal data is stored on the equipment, is responsible for the user management of the equipment. In such cases, the user with administrator rights has supervisory responsibility to delete the personal information of the user on behalf of the user. A user with administrator rights deletes personal data to which he/she has access.
In some cases the user with administrator rights is not the user, however the user with administrator rights will have the responsibility of ensuring the protection of the user’s personal information. In these cases, the deletion mechanism ought to be implemented in such a way that only the user with administrator rights is able to use the deletion mechanism.
If there are multiple users, a user can delete their own data and a user with administrator rights can delete data of all users.
A power up cycle may be used to assure that personal data is persistently deleted.
Any undue delay in deletion, or completion of partial (e.g., previously interrupted) erasure, could leave user’s personal information at risk of being recoverable.
In the context of this provision the expression “delete” means that depending on the risks there can be different technical solutions to appropriately render the personal information permanently unrecoverable.
NOTE 1Tthis could be a software function that resets the device to its factory settings and erases securely by default the encryption key and generates a new one ensuring that it deletes all this personal information.
The aim of the deletion mechanism is that it:
— is resilient against interruptions; and
NOTE 2 Resilience means that the equipment’s deletion mechanism completes when resuming after the interruption.
— is resistant to tampering, such as unauthorised attempt to trigger unauthorised deletion, or such as unauthorised attempt to prevent the authorised deletion; and
— protects against unintentional triggering by the user; and
— is appropriately simple for the user to find and activate.
Examples of use cases where a user with administrator rights, other than a user of an equipment, is required:
— a separate entity might need to be involved in the launch of the requested deletion of the user’s personal information;
— the deletion might require that the approval of the deletion is contingent on the authorisation of the owner of the equipment;
— use cases where special authorisation is needed to delete personal data;
— use cases where the deletion is not be permitted to be performed by the owner of personal data when this data is essential for operational reasons (e.g., industrial context).
Examples of other standards:
ETSI EN 303 645 [6] and ETSI TS 103 701 [7] refer to simple deletion / delete data easily, whereby TS 103 701 describes “simple” as “in a manner that is understandable for a user with limited technical knowledge”.
NOTE 3 Appropriately refers to the level of expertise of the user, the sensitivity of the data, and other factors affecting the access to the triggering of the deletion mechanism.
NOTE 4 ISO/IEC 27555:2021[5]E Guidelines on personally identifiable information deletion (Project 1.27.142) may include useful additional information.
# 6.7.1.4 Assessment criteria
# 6.7.1.4.1 Assessment objective
The assessment addresses the requirement DLM-1.
# 6.7.1.4.2 Implementation categories
Not applicable.
# 6.7.1.4.3 Required information
[E.Info.DLM-1.PersonalData]: Description of the personal data that can be stored on the equipment.
[E.Info.DLM-1.SenSecParam]: Description of the sensitive security parameters that can be stored on the equipment.
[E.Info.DLM-1.DLM]: Description of each deletion mechanism including a description on whether the deletion mechanism ensures that personal data and/or sensitive security parameters stored on the equipment can be deleted, for the purpose of disposal or replacement of the equipment:
— by users; or
— when an authorised entity has supervisory responsibility to delete the personal data and/or sensitive security parameter on behalf of the user, by this entity.
[E.Info.DT.DLM-1]: Description of the selected path through the decision tree in Figure 30 for each personal information stored on the equipment documented in [E.Info.DLM-1.PersonalData].
[E.Just.DT.DLM-1]: Justification for the selected path through the decisions documented in [E.Info.DT.DLM-1] with the following property:
— the justification for the decision [DT.DLM-1.DN-1] is based on [E.Info.DLM-1.DLM].
# 6.7.1.4.4 Conceptual assessment
# 6.7.1.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether a deletion mechanism is implemented when it is required per DLM-1.
# 6.7.1.4.4.2 Preconditions
None.
# 6.7.1.4.4.3 Assessment units
Figure 30 — Decision Tree for requirement DLM-1
For each personal data documented in [E.Info.DLM-1.PersonalData] and for each sensitive security parameter documented in [E.Info.DLM-1.SenSecParam], check whether the path through the decision tree documented in [E.Info.DT.DLM-1] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.DLM-1], examine its justification documented in [E.Just.DT.DLM-1].
# 6.7.1.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.DLM-1] end with “PASS”; and
— the information provided in [E.Just.DT.DLM-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.DLM-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.DLM-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.DLM-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.DLM-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.7.1.4.5 Functional completeness assessment
# 6.7.1.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether personal data documented in [E.Info.DLM-1.PersonalData] or sensitive security parameters documented in [E.Info.DLM-1.SenSecParam] are complete.
# 6.7.1.4.5.2 Preconditions
The equipment is in an operational state.
# 6.7.1.4.5.3 Assessment units
Functionally assess whether there is personal data and whether there are places for storing personal data on the equipment that are not described in [E.Info.DLM-1.PersonalData].
Functionally assess whether there are sensitive security parameters and whether there are places for storing sensitive security parameters on the equipment that are not described in [E.Info.DLM-1.SenSecParam].
# 6.7.1.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all personal data found is documented in [E.Info.DLM-1.PersonalData] and all sensitive security parameters found are documented in [E.Info.DLM-1.SenSecParam].
The verdict FAIL for the assessment case is assigned if there is personal data on the equipment that is not documented in [E.Info.DLM-1.PersonalData] or if there is a sensitive security parameter on the equipment that is not documented in [E.Info.DLM-1.SenSecParam].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.7.1.4.6 Functional sufficiency assessment
# 6.7.1.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether deletion mechanisms are implemented when required per DLM-1.
# 6.7.1.4.6.2 Preconditions
The equipment is in an operational state.
# 6.7.1.4.6.3 Assessment units
For each deletion mechanism documented in [E.Info.DLM-1.DLM], functionally confirm that the deletion mechanism is used on the equipment.
# 6.7.1.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that a deletion mechanism documented in [E.Info.DLM-1.DLM] is not used.
The verdict FAIL for the assessment case is assigned if there is evidence that a deletion mechanism documented in [E.Info.DLM-1.DLM] is not used.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.8[UNM] User notification mechanism
# 6.8.1 [UNM-1] Applicability of user notification mechanisms
# 6.8.1.1 Requirement
The equipment shall provide user notification mechanism(s) for informing the user of the equipment about changes affecting the protection or privacy of personal information, except for changes where:
— other methods of informing the user exist, which do not involve the equipment.
# 6.8.1.2 Rationale
The objective is to ensure transparency to the user of the equipment if changes occur that may affect the protection and privacy of personal information which is collected, stored, or processed by the equipment.
The transparency allows the user of the equipment to consider further actions or updates.
Notifying a user in a timely manner allows them to make an informed decision how to handle those changes.
# 6.8.1.3 Guidance
The user is generally the individual who uses the equipment.
A notification sent or displayed by the notification mechanism may be a text message, vocal message, links or any other equivalent communication to the user, the information on notification policy could be also provided in advance in user documentation.
In the context of this requirement, a user is a natural person who may be either the operator or owner of the equipment.
Changes that may affect data protection and privacy could be:
— the collection and processing of additional categories of personal information prior to the state of the change,
— additional processing operation involving personal information,
— deactivation or major changes of security controls or logging settings intended for the protection of the personal information,
— changes to the types and parameters of processing of personal information, when they impact the level of privacy protection afforded by said processing and parameters.
Providing notification in timely manner depends on the capabilities and status of the equipment, where the meaning of “timely” varies depending on the importance of the change and equipment notification mechanism as well as other factors. For example, if the equipment is offline, it may not be able to provide notification to a remote user and the notification would be sent on a best effort basis.
# 6.8.1.4 Assessment criteria
# 6.8.1.4.1 Assessment objective
The assessment addresses the requirement UNM-1.
# 6.8.1.4.2 Implementation categories
Not applicable.
# 6.8.1.4.3 Required information
[E.Info.UNM-1.PersonalInformation]: Description of each personal information that can be stored on the equipment, including:
— [E.Info.UNM-1.PersonalInformation.UseCase]: Description of each use case where changes can affect the protection or privacy of the personal information, including:
o [E.Info.UNM-1.PersonalInformation.UseCase.Notification]: Description of the user notification mechanism that notifies the user about this change; or
(if there is another method to inform the user, which do not involve the equipment) [E.Info.UNM-1.PersonalInformation.UseCase.OtherInfo]: Description of other method(s) to inform the user not involving the equipment.
[E.Info.DT.UNM-1]: Description of the selected path through the decision tree in Figure 31 for the assessment of UNM-1 for each user notification mechanism documented in [E.Info.UNM-1.PersonalInformation.UseCase.Notification].
[E.Just.DT.UNM-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.UNM-1] with the following properties:
(if a decision from [DT.UNM-1.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.UNM-1.DN-1] is based on [E.Info.UNM-1.PersonalInformation.UseCase.OtherInfo]; and
— the justification for the decision [DT.UNM-1.DN-2] is based on [E.Info.UNM-1.PersonalInformation.UseCase.Notification] .
# 6.8.1.4.4 Conceptual assessment
# 6.8.1.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether one or more notification mechanisms are implemented when they are required per UNM-1.
# 6.8.1.4.4.2 Preconditions
None.
# 6.8.1.4.4.3 Assessment units
Figure 31 — Decision Tree for requirement UNM-1
For each described use case documented in [E.Info.UNM-1.PersonalInformation.UseCase] check whether the path through the decision tree documented in [E.Info.DT.UNM-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.UNM-1], examine its justification documented in [E.Just.DT.UNM-1].
# 6.8.1.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.UNM-1] ends with "PASS"; and
— no path through the decision tree documented in [E.Info.DT.UNM-1] ends with “FAIL”; and
— the information provided in [E.Just.DT.UNM-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.UNM-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.UNM-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.UNM-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.UNM-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.8.1.4.5 Functional completeness assessment
# 6.8.1.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the list of use cases documented in [E.Info.UNM-1.PersonalInformation.UseCase] and the list of personal information that can be stored on the equipment documented in [E.Info.UNM-1.PersonalInformation] is complete.
# 6.8.1.4.5.2 Preconditions
The equipment is in an operational state.
# 6.8.1.4.5.3 Assessment units
Functionally assess whether there is personal information on the equipment that is not described in [E.Info.UNM-1.PersonalInformation].
Functionally assess whether there is a use case for changing personal information on the equipment that is not described in [E.Info.UNM-1.PersonalInformation.UseCase].
# 6.8.1.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all personal information found is documented in [E.Info.UNM-1.PersonalInformation] and all use cases found are documented in [E.Info.UNM-1.PersonalInformation.UseCase].
The verdict FAIL for the assessment case is assigned if there is personal information on the equipment that is not documented in [E.Info.UNM-1.PersonalInformation] or if there is a use case found that is not documented in [E.Info.UNM-1.PersonalInformation.UseCase].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.8.1.4.6 Functional sufficiency assessment
# 6.8.1.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the notification for each change is implemented where it is required as per UNM-1.
# 6.8.1.4.6.2 Preconditions
The equipment is in an operational state.
# 6.8.1.4.6.3 Assessment units
Functionally confirm the existence/usage of at least one user notification mechanism documented in [E.Info.UNM-1.PersonalInformation.UseCase.Notification] for each use case documented in [E.Info.UNM-1. PersonalInformation.UseCase].
# 6.8.1.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that a use case documented in [E.Info.UNM-1.PersonalInformation.UseCase] is not covered by a user notification mechanism documented in [E.Info.UNM-1.PersonalInformation.UseCase.Notification].
The verdict FAIL for the assessment case is assigned if there is evidence that a use case documented in [E.Info.UNM-1.PersonalInformation.UseCase] is not covered by a user notification mechanism documented in [E.Info.UNM-1.PersonalInformation.UseCase.Notification].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.8.2 [UNM-2] Appropriate user notification content
# 6.8.2.1 Requirement
The content of a notification provided by a user notification mechanism that is required per UNM-1 shall include at least:
— a description of a change; and
— a description of how a change will affect the protection and privacy of personal information.
# 6.8.2.2 Rationale
Transparent and comprehensible information allows the user of the equipment to understand what the changes are that affect data protection and privacy of personal information.
# 6.8.2.3 Guidance
Reflection of the content of a notification is an explanation to the user of the equipment that describes how the changes affect data protection and privacy of personal information.
The content of a notification needs to be in a precise, transparent, comprehensible and easily accessible form.
Any information for children needs to be provided concisely, prominently, and using clear language suited to the age of children.
# 6.8.2.4 Assessment criteria
# 6.8.2.4.1 Assessment objective
The assessment addresses the requirement UNM-2.
# 6.8.2.4.2 Implementation categories
Not applicable.
# 6.8.2.4.3 Required information
[E.Info.UNM-2.Notifications]: Description of each user notification mechanism that is required per UNM-1, including:
— [E.Info.UNM-2.Notifications.UseCase]: Description of each use case where notifications are provided by the user notification mechanisms , including:
o [E.Info.UNM-2.Notifications.UseCase.Content]: Description of the content of the notifications for the use case.
[E.Info.DT.UNM-2]: Description of the selected path through the decision tree in Figure 32 for each user notification mechanism documented in [E.Info.UNM-2.Notifications].
[E.Just.DT.UNM-2]: Justification for the selected path through the decision tree documented in [E.Info.DT.UNM-2] with the following property:
— the justification for the decision [DT.UNM-2.DN-1] is based on [E.Info.UNM-2.Notifications.UseCase.Content].
# 6.8.2.4.4 Conceptual assessment
# 6.8.2.4.4.1 Assessment purpose
The purpose of this assessment case is a conceptual assessment whether a notification includes the required content documented in [E.Info.UNM-2.Notifications.UseCase.Content] as required per UNM-2.
# 6.8.2.4.4.2 Preconditions
None.
# 6.8.2.4.4.3 Assessment units
Figure 32 — Decision Tree for requirement UNM-2
For each user notification mechanism documented in [E.Info.UNM-2.Notifications], check whether the path through the decision tree documented in [E.Info.DT.UNM-2] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.UNM-2], examine its justification documented in [E.Just.DT.UNM-2].
# 6.8.2.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.UNM-2] end with “PASS”; and
— the information provided in [E.Just.DT.UNM-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.UNM-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.UNM-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.UNM-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.UNM-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.8.2.4.5 Functional completeness assessment
The functional completeness assessment is covered by the functional sufficiency assessment of the user notification mechanism’s applicability.
Therefore, this functional completeness assessment is not necessary.
# 6.8.2.4.6 Functional sufficiency assessment
# 6.8.2.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether a notification includes the content as required per UNM-2.
# 6.8.2.4.6.2 Preconditions
The equipment is in an operational state.
# 6.8.2.4.6.3 Assessment units
Functionally confirm that the content of each user notification mechanism documented in [E.Info.UNM-2.Notifications] includes content as required per UNM-2.
# 6.8.2.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that a user notification mechanism implementation deviates from [E.Info.UNM-2.Notifications].
The verdict FAIL for the assessment case is assigned if there is evidence that a user notification mechanism implementation deviates from [E.Info.UNM-2.Notifications].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.9[CCK] Confidential cryptographic keys
# 6.9.1 [CCK-1] Appropriate CCKs
# 6.9.1.1 Requirement
Confidential cryptographic keys that are preinstalled or generated by the equipment during its use shall support a minimum security strength of 112-bits, except for:
— CCKs that are solely used by a specific security mechanism, where a deviation is identified and justified under the terms of sections ACM or AUM or SCM or SUM or SSM.
NOTE 1 Confidential cryptographic key is a defined term. Other secrets, whose disclosure cannot be used to compromise the user’s or subscriber’s privacy, such as secrets solely protecting intellectual property are not covered by the definition of confidential cryptographic key.
NOTE 2 The requirement refers to all confidential cryptographic keys chosen by the equipment manufacturer either directly or imposed by a protocol. For instance, the manufacturer directly chooses/configures the cipher suite of TLS protocol to be used by the device, other protocols may impose one single option for cryptographic algorithms and their respective keys.
# 6.9.1.2 Rationale
The equipment can use cryptography and therefore CCKs for many and different purposes like for authentication to enforce access control to security assets or privacy assets, for protecting the confidentiality or integrity of security assets or privacy assets at rest or when communicated to another entity or for the derivation of other CCKs. If the confidentiality of a CCK is compromised the security assets and privacy assets protected by the CCK can get compromised too. A CCK of an equipment generated for an algorithm used for cryptographic protection is appropriate when a successful attack on it does not affect other CCKs used or generated by this equipment or by other equipment and the algorithm has an adequate security strength using this CCK to resist attacks proportionate to its use and targeting to break its confidentiality.
# 6.9.1.3 Guidance
The security strength supported by a CCK depends mainly on 3 parameters:
— the entropy of the RNG used for their generation; and
— its effective length (see BSI TR-02102-1 [20]); and
— on the cryptographic algorithm with which it is used.
Another important aspect which is related to the needed security strength supported by a CCK is the lifetime of the CCK. Long term CCKs which are stored and used repeatedly for a long period of time would need a longer in time resistance against attacks compared to short term CCKs which are usually generated on the equipment and only used for a short time. For instance, session keys used for a single communication session to encrypt the transferred security assets or privacy assets are a typical example for short term keys. However perfect forward secrecy is an aspect that usually is taken into account for the security of session keys and so these are usually generated/derived with adequate cryptographic mechanisms so that session keys of past sessions cannot be compromised.
Refer to CRY-1 for guidance on best practice.
Additional good security practices need also to be taken into account. For instance, it is a good security practice to use one CCK for a single purpose. Special care is to be taken for CCKs which are not used anymore, for instance these are to be deleted. It is recommended to follow recognised best practices for that, see CRY-1 requirement. It is also recommended that the same CCK is not replicated and used on the different specimens/units of this equipment.
There may be cases where deviations from the minimum security strength of 112 bits of CCKs is justified. For instance, CCKs which are derived from human generated passwords may not provide 112 bits of security strength. Password key derivation is used in applications and protocols because they are practical and provide adequate security for their use case. There might be also cases where for interoperability reasons security measures dictates the deviation of the minimum security strength of 112 bits to be provided by CCKs. This can be due to the need for “interoperability support” (e.g., see SCM-1) or the need for usage of standardized and widely used communication protocols that deviate from the best practices.
For such deviations the resulting risks towards “the protection of the privacy assets and/or security assets” needs to be assessed.
# 6.9.1.4 Assessment criteria
# 6.9.1.4.1 Assessment objective
The assessment addresses the requirement CCK-1.
# 6.9.1.4.2 Implementation categories
Not applicable.
# 6.9.1.4.3 Required information
[E.Info.CCK-1.CCK]: For each confidential cryptographic key (whether preinstalled or generated by the equipment during its use), describe:
— The cryptographic algorithms for the confidential cryptographic key and the key length of confidential cryptographic key’s implementation; and
(if the confidential cryptographic key is solely used by a specific security mechanism, where a deviation is identified and justified under the terms of sections ACM or AUM or SCM or SUM or SSM)[E.Info.CCK-1.CCK.Deviation]: Reference to the corresponding justification and to the required information the justification is based on; and
— [E.Info.CCK-1.CCK.SecurityStrength]: The security strength and the reference of the lookup tables used in the assessment.
NOTE for example with reference to security strength definitions in SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms [24] or NIST Special Publications 800-57 [8] or 800-131A [15].
[E.Info.DT.CCK-1]: Description of the selected path through the decision tree in Figure 33 for each confidential cryptographic key documented in [E.Info.CCK-1.CCK].
[E.Just.DT.CCK-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.CCK-1] with the following properties:
— (if a decision from [DT.CCK-1.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.CCK-1.DN-2] is based on [E.Info.CCK-1.CCK.Deviation]; and
— the justification for the decision [DT.CCK-1.DN-1] is based on [E.Info.CCK-1.CCK] and [E.Info.CCK-1.CCK.SecurityStrength].
# 6.9.1.4.4 Conceptual assessment
# 6.9.1.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether confidential cryptographic keys are implemented as required per CCK-1.
# 6.9.1.4.4.2 Preconditions
None.
# 6.9.1.4.4.3 Assessment units
Figure 33 — Decision Tree for requirement CCK-1
For each confidential cryptographic key documented in [E.Info.CCK-1.CCK], check whether the path through the decision tree documented in [E.Info.DT.CCK-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.CCK-1], examine its justification documented in [E.Just.DT.CCK-1].
# 6.9.1.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.CCK-1] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.CCK-1] ends with “FAIL”; and
— the information provided in [E.Just.DT.CCK-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.CCK-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.CCK-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.CCK-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.CCK-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.9.1.4.5 Functional completeness assessment
# 6.9.1.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the documentation of CCKs is complete.
# 6.9.1.4.5.2 Preconditions
The equipment is in an operational state.
# 6.9.1.4.5.3 Assessment units
Functionally assess whether there are CCK preinstalled or generated by the equipment, which are not documented in [E.Info.CCK-1.CCK].
# 6.9.1.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all CCKs found are documented in [E.Info.CCK-1.CCK].
The verdict FAIL for the assessment case is assigned if a CCK is found which is not documented in [E.Info.CCK-1.CCK].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.9.1.4.6 Functional sufficiency assessment
# 6.9.1.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether the confidential cryptographic keys documented [E.Info.CCK-1.CCK] are implemented as documented.
NOTE The assessment of the bit length is only a necessary condition and does not constitute a complete functional sufficiency assessment for security strength.
# 6.9.1.4.6.2 Preconditions
The equipment is in an operational state.
# 6.9.1.4.6.3 Assessment units
For each confidential cryptographic key documented in [E.Info.CCK-1.CCK] functionally assess whether the CCK’s length as documented in [E.Info.CCK-1.CCK] is implemented in accordance with [E.Info.CCK-1.CCK.SecurityStrength].
# 6.9.1.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that any CCK’s length documented in [E.Info.CCK-1.CCK] deviates from their documentation.
The verdict FAIL for the assessment case is assigned if there is evidence that a CCK’s length documented in [E.Info.CCK-1.CCK] deviates from the documentation.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.9.2 [CCK-2] CCK generation mechanisms
# 6.9.2.1 Requirement
The generation of confidential cryptographic keys shall adhere to best practice cryptography, except for:
— the generation of CCKs for a specific security mechanism, where a deviation is identified and justified under the terms of sections ACM or AUM or SCM or SUM or SSM.
NOTE Confidential cryptographic key is a defined term. Other secrets, whose disclosure cannot be used to compromise the user’s or subscriber’s privacy, such as secrets solely protecting intellectual property are not covered by the definition of confidential cryptographic key.
# 6.9.2.2 Rationale
CCKs that are generated by the equipment and used to protect security assets or privacy assets, need to be generated appropriately in order to prevent successful attacks based on CCKs with insufficient security strength. An appropriate CCK generation mechanism ensures that CCKs have the necessary properties based on the associated risks and the operational conditions of the equipment.
# 6.9.2.3 Guidance
The security strength of a CCK is largely determined by the random number source (the main source of entropy) and the random number generator and the key generation/derivation algorithm which generate it.
Risks related to poor choices of random source, random number generators and key derivation can make a CCKs subject to attacks like
— guessing a CCK; or
— brute forcing a CCK; or
一reconstructinga CCKbased on accessible information.
It is therefore essential that the CCK generation mechanism will not generate CCKs with insufficient security strength. A robust CCK generation mechanism relies on a secure RNG providing random numbers with sufficient entropy. It is a very complex task to create a securely robust CCK generation mechanism and the underlying RNG. It is highly recommended to follow well recognised standards for this purpose.
NOTE 1 There are various well-recognised standards for key generation mechanisms. For instance, recognised best practices for Random Number Generators are NIST SP800-90A[11], NIST SP800-90B[12], NIST SP800- 90C[13], BSI AIS20 [42], BSI AIS31[19], ISO/IEC 18031 [43].
NOTE 2 Examples for well recognised best practices for key derivation are for instance described at SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms [24]. Alternatives are available here: ISO/IEC 11770 [28], NIST SP 800-108r1[14], NIST SP 800-132[16].
# 6.9.2.4 Assessment criteria
# 6.9.2.4.1 Assessment objective
The assessment addresses the requirement CCK-2.
# 6.9.2.4.2 Implementation categories
Not applicable.
# 6.9.2.4.3 Required information
[E.Info.CCK-2.Generation]: Description of each generation mechanism for confidential cryptographic keys, including the following details:
— [E.Info.CCK-2.Generation.CCK]: Specification of the confidential cryptographic keys the mechanism generates and whether their generation adheres to best practice cryptography; and
— (if the generation mechanism for CCK relies on a random number source and is used for the generation of confidential cryptographic key that adhere to best practice cryptography)
o specify the best practices followed by the random number source; and
o explain why the random number source provides sufficient security strength; and
o explain how the random number source is configured and initialised; and
o if it is claimed that the CCK is compliant with recognised security standards or certification schemes, provide evidence to the recognised security standard or certification schemes the CCK complies to; and
— (if the generation mechanism for CCK relies on a random number generator and is used for the generation of confidential cryptographic key that adhere to best practice cryptography):
specify whether it is a deterministic or a non-deterministic random number generator; and
o specify the best practices followed by the random number generator; and
o specify why the random number generator provides sufficient security strength; and
o explain how the random number generator is configured and initialised; and
if it is claimed that the CCK is compliant with recognised security standards or certification schemes, provide evidence to the recognised security standard or certification schemes the CCK complies to; and
— (if the generation mechanism for CCK relies on a derivation mechanism/ establishment mechanism and is used for the generation of confidential cryptographic key that adhere to best practice cryptography):
0 specify the best practices followed by the derivation mechanism/ establishment mechanism; and
o specify the key derivation/generation algorithm used for that; and
(if the generation mechanism generates confidential cryptographic keys used solely by a specific security mechanism, where a deviation from best practice cryptography is identified and justified under the terms of sections ACM or AUM or SCM or SUM or SSM)[E.Info.CCK-2.Generation.Deviation]:
0 reference the corresponding justification and to the required information the justification is based on.
NOTE The information above may not always be available to the manufacturer when the generation mechanism is provided by a supplier which will not disclose such information for security reasons while providing all necessary security instructions to use the generation mechanism.
[E.Info.DT.CCK-2]: Description of the selected path through the decision tree in Figure 34 for each generation mechanism for confidential cryptographic keys documented in [E.Info.CCK-2.Generation].
[E.Just.DT.CCK-2]: Justification for the selected path through the decision tree documented in [E.Info.DT.CCK-2] with the following properties:
— (if a decision from [DT.CCK-2.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.CCK-2.DN-1] is based on [E.Info.CCK-2.Generation.Deviation]; and
— the justification for the decision [DT.CCK-2.DN-2] is based on [E.Info.CCK-2.Generation].
# 6.9.2.4.4 Conceptual assessment
# 6.9.2.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether all confidential cryptographic key generation mechanisms listed in [E.Info.CCK-2.Generation] are as required per CCK-2.
# 6.9.2.4.4.2 Preconditions
None.
# 6.9.2.4.4.3 Assessment units
Figure 34 — Decision Tree for requirement CCK-2
For each generation mechanism of confidential cryptographic keys on the equipment documented in [E.Info.CCK-2.Generation], check whether the path through the decision tree documented in [E.Info.DT.CCK-2] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.CCK-2], examine its justification documented in [E.Just.DT.CCK-2].
# 6.9.2.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.CCK-2] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.CCK-2] ends with “FAIL”; and
— the information provided in [E.Just.DT.CCK-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.CCK-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree end with “FAIL”; or
— a justification provided in [E.Just.DT.CCK-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.CCK-2].
The verdict NOT APPLICABLE is assigned otherwise.
# 6.9.2.4.5 Conceptual completeness assessment of documentation
# 6.9.2.4.5.1 Assessment purpose
The purpose of this assessment case is to conceptually assess whether all generation mechanisms for confidential cryptographic keys on the equipment are documented in [E.Info.CCK-2.Generation].
# 6.9.2.4.5.2 Preconditions
None.
# 6.9.2.4.5.3 Assessment units
Check that there is no evidence for generation mechanisms for confidential cryptographic keys on the equipment that are not documented in [E.Info.CCK-2.Generation] through a consistency check with [E.Info.CCK-1.CCK].
# 6.9.2.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that there are generation mechanisms for confidential cryptographic keys that are not documented in [E.Info.CCK-2.Generation].
The verdict FAIL for the assessment case is assigned if there is any evidence that there are generation mechanisms for confidential cryptographic keys that are not documented in [E.Info.CCK-2.Generation].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.9.2.4.6 Functional sufficiency assessment
There is significant complexity surrounding the validation of cryptographic key generation mechanisms and typically they will be implemented by a third party with significant cryptographic expertise, who is unlikely to share details of such key generation processes. Given these considerations, no functional sufficiency assessment is provided for this requirement.
# 6.9.3 [CCK-3] Preventing static default values for preinstalled CCKs
# 6.9.3.1 Requirement
Preinstalled confidential cryptographic keys shall be practically unique per equipment, except for:
— CCKs that are only used for establishing initial trust relationships under conditions controlled by an authorized entity; or
— CCKs that are shared parameters required for the equipment’s intended functionality.
NOTE Confidential cryptographic key is a defined term. Other secrets, whose disclosure cannot be used to compromise the user’s or subscriber’s privacy, such as secrets solely protecting intellectual property are not covered by the definition of confidential cryptographic key.
# 6.9.3.2 Rationale
Equipment can use cryptography and therefore CCKs to protect the security assets and privacy assets on the equipment. The CCKs are sometimes predefined, e.g. in the manufacturing process. CCKs used for the above-mentioned purpose need to be appropriate to prevent successful attacks based on CCKs with insufficient strength, especially when preinstalled.
# 6.9.3.3 Guidance
CCKs can be preinstalled on the equipment during manufacturing. Preinstalled CCKs that are unique per equipment instance and resist brute force attacks can mitigate cyber security risk associated with the specific use of the CCK.
Unique relates to not systematically reused or deducible for another equipment of the same product type and cannot be easily derived from equipment properties (e.g., manufacturer name, model name or Media Access Control (MAC) address). Established random generator can be used to generate practically unique cryptographic keys.
In some cases, keys are only used for establishing initial trust relationships under conditions controlled by an authorized entity or the key as shared parameter is essential to the equipment’s operation, e.g., software updates or configuration of the migration for network equipment. In such cases the use of static keys can be applicable.
# 6.9.3.4 Assessment criteria
# 6.9.3.4.1 Assessment objective
The assessment addresses the requirement CCK-3.
# 6.9.3.4.2 Implementation categories
Not applicable.
# 6.9.3.4.3 Required information
[E.Info.CCK-3.CCK]: Description of each preinstalled confidential cryptographic key on the equipment, including:
— (if practically uniqueness of the confidential cryptographic key is claimed to be not required because it is only used for establishing initial trust relationships under conditions controlled by an authorized entity)[E.Info.CCK-3.CCK.Controlled]: Description of:
o the initial trust relationship to be established by the confidential cryptographic key; and
o the conditions controlled by an authorized entity; and
(if practically uniqueness of the confidential cryptographic key is claimed to be not required because it is a shared parameter required for the equipment’s intended functionality)[E.Info.CCK-3.CCK.Shared]: Description of the equipment’s functionalities that require the confidential cryptographic key being a shared parameter; and
— (if the CCK is claimed to be practically unique per equipment) [E.Info.CCK-3.CCK.Unique]: Description of the methods that result in the CCK being practically unique per equipment.
[E.Info.DT.CCK-3]: Description of the selected path through the decision tree shown in Figure 35 for each preinstalled CCK documented in [E.Info.CCK-3.CCK].
[E.Just.DT.CCK-3]: Justification for the selected path through the decision tree documented in [E.Info.DT.CCK-3] with the following properties:
— (if a decision from [DT.CCK-3.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.CCK-3.DN-2] is based on [E.Info.CCK-3.CCK.Controlled]; and
— (if a decision from [DT.CCK-3.DN-3] results in “NOT APPLICABLE”) the justification for the decision [DT. CCK-3.DN-3] is based on [E.Info.CCK-3.CCK.Shared]; and
— the justification for the decision [DT.CCK-3.DN-1] is based on [E.Info.CCK-3.CCK.Unique].
# 6.9.3.4.4 Conceptual assessment case
# 6.9.3.4.4.1 Assessment purpose
The purpose of this assessment case is the conceptual assessment whether preinstalled confidential cryptographic keys are implemented as required per CCK-3.
# 6.9.3.4.4.2 Preconditions
None.
# 6.9.3.4.4.3 Assessment units
Figure 4 — Decision Tree for requirement CCK-3
For each confidential cryptographic key documented in [E.Info.CCK-3.CCK], check whether the path through the decision tree documented in [E.Info.DT.CCK-3] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.CCK-3], examine its justification documented in [E.Just.DT.CCK-3].
# 6.9.3.4.4.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.CCK-3] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.CCK-3] ends with “FAIL”; and
— the information provided in [E.Just.DT.CCK-3] are correct justifications for all paths through the decision tree documented in [E.Info.DT.CCK-3].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.CCK-3] ends with “FAIL”; or
— a justification provided in [E.Just.DT.CCK-3] is not correct or missing for a path through the decision tree documented in [E.Info.DT.CCK-3].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.9.3.4.5 Functional completeness assessment
# 6.9.3.4.5.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether all preinstalled CCKs are documented.
# 6.9.3.4.5.2 Preconditions
The equipment is in the factory default state.
# 6.9.3.4.5.3 Assessment units
Functionally assess whether there are preinstalled CCKs on the equipment which are not documented in [E.Info.CCK-3.CCK].
# 6.9.3.4.5.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if all preinstalled CCK found are documented in [E.Info.CCK-3.CCK].
The verdict FAIL for the assessment case is assigned if a preinstalled CCK found is not documented in [E.Info.CCK-3.CCK].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.9.3.4.6 Functional sufficiency assessment
# 6.9.3.4.6.1 Assessment purpose
The purpose of this assessment case is the functional assessment whether preinstalled CCKs that are claimed to be practically unique per equipment are sufficiently independent from each other.
# 6.9.3.4.6.2 Preconditions
Two instances of the equipment are in a factory default state.
# 6.9.3.4.6.3 Assessment units
For each CCK documented in [E.Info.CCK-3.CCK], where [E.Info.CCK-3.CCK.Unique] indicates that the CCK is claimed to be practically unique per equipment, functionally assess that the respective CCKs of the two equipments are practically unique by:
— (if the CCKs are accessible) comparing the CCKs and confirming that they are not the same and there is no obvious way to derive one from the other; and
— (if the CCKs are not accessible but come together with associated accessible public cryptographic keys, e.g. private/public key pairs, comparing the associated public cryptographic keys and confirming that they are not the same.
NOTE The specific functional test may not always be possible for each CCK as usually not all CCKs will be accessible or have an associated accessible public cryptographic key.
# 6.9.3.4.6.4 Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that a CCK documented in [E.Info.CCK-3.CCK], where [E.Info.CCK-3.CCK.Unique] indicates that the CCK is claimed to be practically unique per equipment is not practically unique per equipment.
The verdict FAIL for the assessment case is assigned if there is evidence that a CCK documented in [E.Info.CCK-3.CCK], where [E.Info.CCK-3.CCK.Unique] indicates that the CCK is claimed to be practically unique per equipment is not practically unique per equipment.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10 [GEC] General equipment capabilities
# 6.10.1 [GEC-1] Up-to-date software and hardware with no publicly known exploitable vulnerabilities
# 6.10.1.1 Requirement
The equipment shall not include publicly known exploitable vulnerabilities that, if exploited, affect security assets and privacy assets, except for vulnerabilities:
— that cannot be exploited in the specific conditions of the equipment; or
— that have been mitigated to an acceptable residual risk; or
— that have been accepted on a risk basis.
# 6.10.1.2 Rationale
Equipment can consist of hardware and software provided by different providers and the manufacturer might have insufficient visibility into the security practices of these providers.
It is essential that the manufacturer can identify publicly known exploitable vulnerabilities in the hardware and in the software, both commercial and open-source software, used in the equipment and can handle these vulnerabilities.
# 6.10.1.3 Guidance
To facilitate software vulnerability monitoring, the manufacturer of the equipment keeps technical documentation of the software of the equipment, including both open-source software and commercial off the shelf components. Likewise, technical documentation of hardware can assist in the identification of the hardware vulnerabilities.
To identify the publicly known exploitable vulnerabilities in the hardware and software of the equipment, the manufacturer consults a public vulnerability database (e.g. NIST National Vulnerabilities Database https://nvd.nist.gov/ and existing National European Vulnerabilities Databases).
Different factors the manufacturer considers when assessing the publicly known exploitable vulnerabilities, include, but are not limited to:
— attack surface of the equipment and vectors/paths by which an attacker can gain access to the equipment to exploit the vulnerability;
— the evidence that the vulnerability has been actively exploited or it already has documented proof-of-concept or code exploits;
— the security capabilities and mechanisms implemented in the equipment which can mitigate the exploitation of the vulnerability;
— the “intended equipment functionality”;
— the equipment’s “intended operational environment of use” including the threat environment and the security capabilities and additional countermeasures provided by the environment which can mitigate or remediate the exploitation of the vulnerability.
# 6.10.1.4 Assessment criteria
# 6.10.1.4.1 Assessment objective
The assessment addresses the requirement GEC-1.
# 6.10.1.4.2 Implementation categories
Not applicable.
# 6.10.1.4.3 Required information
[E.Info.GEC-1.SecurityAsset]: Description of each security asset of the equipment.
[E.Info.GEC-1.PrivacyAsset]: Description of each privacy asset of the equipment.
[E.Info.GEC-1.SoftwareDocumentation]: Description of the software of the equipment, including their versions, that affect the security assets and the privacy assets documented in [E.Info.GEC-1.SecurityAsset] and [E.Info.GEC-1.PrivacyAsset].
[E.Info.GEC-1.HardwareDocumentation]: Description of the hardware of the equipment that affect the security assets and the privacy assets documented in [E.Info.GEC-1.SecurityAsset] and [E.Info.GEC-1.PrivacyAsset].
[E.Info.GEC-1.ListOfVulnerabilities]: Description of all publicly known exploitable vulnerabilities in the hardware and software that affect the security assets and the privacy assets documented in [E.Info.GEC-1.SecurityAsset] and [E.Info.GEC-1.PrivacyAsset]. The document includes also the source of the vulnerabilities’ information. Further a justification is given for each vulnerability that affects privacy assets and security assets about the remediation, mitigation and non-exploitation of the listed hardware or software publicly known exploitable vulnerabilities, including:
— (if the vulnerability is remediated) [E.Info.GEC-1.ListOfVulnerabilities.Remediated]: The measures implemented to remediate the vulnerability; and
— (if the vulnerability cannot be exploited in the specific conditions of the equipment) [E.Info.GEC-1.ListOfVulnerabilities.SpecificCondition]: The description of specific conditions in which the vulnerability cannot be exploited; and
— (if the vulnerability is mitigated) [E.Info.GEC-1.ListOfVulnerabilities.Mitgated]: The description of the measures for the mitigation; and
— (if the vulnerability is accepted) [E.Info.GEC-1.ListOfVulnerabilities.Accepted]: The description of the acceptance of the vulnerability on a risk basis.
[E.Info.DT.GEC-1]: Description of the selected path through the decision tree in Figure 36 for each software and hardware documented in [E.Info.GEC-1.SoftwareDocumentation] and [E.Info.GEC-1.HardwareDocumentation] where publicly known exploitable vulnerabilities exist.
[E.Just.DT.GEC-1]: Justification for the selected path through the decision tree documented in [E.Info.DT.GEC-1] with the following properties:
— the justification for the decision [DT.GEC-1.DN-1] is based on [E.Info.GEC-1.ListOfVulnerabilities]; and
(if a decision from [DT.GEC-1.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.GEC-1.DN-2] is based on [E.Info.GEC-1.ListOfVulnerabilities] and [E.Info.GEC-1.ListOfVulnerabilities.Remediated]; and
(if a decision from [DT.GEC-1.DN-3] results in “NOT APPLICABLE”) the justification for the decision [DT.GEC-1.DN-3] is based on [E.Info.GEC-1.ListOfVulnerabilities.SpecificCondition]; and
— (if a decision from [DT.GEC-1.DN-4] results in “NOT APPLICABLE”) the justification for the decision [DT.GEC-1.DN-4] is based on [E.Info.GEC-1.ListOfVulnerabilities.Mitgated]; and
— the justification for the decision [DT.GEC-1.DN-5] is based on [E.Info.GEC-1.ListOfVulnerabilities.Accepted].
# 6.10.1.4.4 Conceptual assessment
# 6.10.1.4.4.1Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the hardware or software publicly known exploitable vulnerabilities present in the hardware and software of the equipment under test, in factory default state, are not able to affect privacy assets or security assets, if exploited as required per GEC-1.
# 6.10.1.4.4.2Preconditions
None.
# 6.10.1.4.4.3 Assessment units
Figure 36 — Decision tree for requirement GEC-1
For each software in [E.Info.GEC-1.SoftwareDocumentation] and hardware documented in [E.Info.GEC-1.HardwareDocumentation], check whether the path through the decision tree documented in [E.Info.DT.GEC-1] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.GEC-1], examine its justification documented in [E.Just.DT.GEC-1].
# 6.10.1.4.4.4Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.GEC-1] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.GEC-1] ends with “FAIL”; and
— the information provided in [E.Just.DT.GEC-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.GEC-1].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.GEC-1] ends with “FAIL”; or
— a justification provided in [E.Just.DT.GEC-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.GEC-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.1.4.5 Functional completeness assessment
# 6.10.1.4.5.1Assessment purpose
The purpose of this assessment case is the functional assessment of the equipment under test to verify the completeness of the documentation: that the vulnerabilities present in the equipment which affect privacy assets or security assets are only those listed in [E.Info.GEC-1.ListOfVulnerabilities].
# 6.10.1.4.5.2Preconditions
The equipment is in an operational state.
The date for the source of the vulnerabilities to be used in the assessment of the list of publicly known exploitable vulnerabilities is recent.
# 6.10.1.4.5.3 Assessment units
Using up-to-date evaluation methods, functionally assess whether there are publicly known hardware vulnerabilities that affect the security assets and the privacy assets, which are not listed in [E.Info.GEC-1.ListOfVulnerabilities].
Using up-to-date evaluation methods, functionally assess whether there are publicly known software vulnerabilities that affect the security assets and the privacy assets, which are not listed in [E.Info.GEC-1.ListOfVulnerabilities].
NOTE Various software tools and measuring devices are available to automatically search for software and hardware vulnerabilities.
# 6.10.1.4.5.4Assignment of verdict
The verdict PASS for the assessment case is assigned if all found publicly known software and hardware vulnerabilities that affect the security assets and the privacy assets are documented in [E.Info.GEC-1.ListOfVulnerabilities].
The verdict FAIL for the assessment case is assigned if a publicly known software or hardware vulnerability that affects a security asset or a privacy asset is not documented in [E.Info.GEC-1.ListOfVulnerabilities].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.1.4.6 Functional sufficiency assessment
# 6.10.1.4.6.1Assessment purpose
The purpose of this assessment case is the functional assessment if the vulnerabilities present in the equipment which are listed in [E.Info.GEC-1.ListOfVulnerabilities] are not able to affect security assets or privacy assets, if exploited.
# 6.10.1.4.6.2Preconditions
The equipment is in an operational state.
The date for the source of the vulnerabilities to be used in the assessment of the list of publicly known exploitable vulnerabilities is recent.
# 6.10.1.4.6.3 Assessment units
Functionally assess whether the measures described in [E.Info.GEC-1.ListOfVulnerabilities] are implemented considering also the specific conditions for the exploitability defined in [E.Info.GEC-1.ListOfVulnerabilities] to ensure that the vulnerabilities are not able to affect security assets and privacy assets, if exploited.
NOTE For a lot of vulnerabilities Pentest tools are available to verify their exploitability.
# 6.10.1.4.6.4Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that measures to ensure that vulnerabilities are not able to affect security assets and privacy assets, if exploited, have not been implemented as described in [E.Info.GEC-1.ListOfVulnerabilities] considering also the specific conditions for the exploitability defined in [E.Info.GEC-1.ListOfVulnerabilities].
The verdict FAIL is assigned if there is evidence that measures to ensure that vulnerabilities are not able to affect security assets and privacy assets, if exploited, have not been implemented as described in [E.Info.GEC-1.ListOfVulnerabilities] considering also the specific conditions for the exploitability defined in [E.Info.GEC-1.ListOfVulnerabilities].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.2 [GEC-2] Limit exposure of services via related network interfaces
# 6.10.2.1 Requirement
In factory default state the equipment shall only expose
— network interfaces; and
— services via network interfaces
affecting security assets and privacy assets which are necessary for equipment setup or for basic operation of the equipment.
# 6.10.2.2 Rationale
An important factor for reducing the potential risk that the network resource of the equipment becomes compromised for instance to harm the network, are exposed services. Therefore, these exposed services need to be limited to those that are necessary for equipment setup and to operate the equipment in the intended operational environment of use.
# 6.10.2.3 Guidance
The configuration of the equipment can vary depending on the purpose of the equipment.
Generally, a differentiation is to be made between two types of equipment:
Multipurpose equipment, e.g., smartphones, laptops: Offered services and functionality of multipurpose equipment are only under the control of the manufacturer until the equipment is placed on the market; and
Equipment with a controlled fixed functionality, e.g., sensors, routers: Offered services and functionality of the equipment are embedded in an equipment-specific software which is provided by the manufacturer.
In case of equipment with a controlled fixed functionality only network interfaces or services (via network interfaces) are allowed in factory default state to be exposed which are essential to setup or use this functionality.
A multipurpose equipment has no specific intended use but is typically delivered by the manufacturer with a defined set of pre-installed applications. Further, the equipment provides an operational system for the following typical use cases in the factory default state:
— Manage/control the hardware of the equipment,
— Usage of the pre-installed applications,
— Installation of additional applications,
— Installation of software update.
These use cases define the permitted scope for the exposed network interfaces and services (via network interfaces).
Affecting security assets means that if the network interface or the service (via network interfaces) is compromised it can have an impact on the security of the equipment.
# 6.10.2.4 Assessment criteria
# 6.10.2.4.1 Assessment objective
The assessment addresses the requirement GEC-2.
# 6.10.2.4.2 Implementation categories
Not applicable.
# 6.10.2.4.3 Required information
[E.Info.GEC-2.NetworkInterface.Exposure]: Description of each network interface and exposed service (via network interfaces) in factory default state of the equipment, including information if they are required for the basic operation or for the setup of the equipment or if they are optional.
(if the equipment implements a setup process) [E.Info.GEC-2.Setup]: Documentation how to setup the equipment.
[E.Info.GEC-2.SecurityAsset]: Description of each security asset that is accessible via network interfaces.
[E.Info.GEC-2.PrivacyAsset]: Description of each privacy asset that is accessible via network interfaces.
[E.Info.DT.GEC-2]: Description of the selected path through the decision tree in Figure 37 for each network interface and service (via network interfaces) as documented in [E.Info.GEC-2.NetworkInterface.Exposure].
[E.Just.DT.GEC-2]: Justification for each selected path through the decision tree documented in [E.Info.DT.GEC-2] with the following properties:
— (if a decision from [DT.GEC-2.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.GEC-2.DN-1] is based on [E.Info.GEC-2.NetworkInterface.Exposure]; and
(if a decision from [DT.GEC-2.DN-2] results in “NOT APPLICABLE”) the justification for the decision [DT.GEC-2.DN-2] is based on [E.Info.GEC-2.SecurityAsset] and [E.Info.GEC-2.PrivacyAsset]; and
— the justification for the decision [DT.GEC-2.DN-3] is based on [E.Info.GEC-2.NetworkInterface.Exposure].
# 6.10.2.4.4 Conceptual assessment
# 6.10.2.4.4.1Assessment purpose
The purpose of this assessment case is the conceptual assessment whether each exposure of network interfaces and services (via network interfaces) which are affecting security assets or privacy assets in factory default state documented in [E.Info.GEC-2.NetworkInterface.Exposure] is restricted to the ones which are necessary for equipment setup or for the basic operation of the equipment as required per GEC-2.
# 6.10.2.4.4.2Preconditions
None.
# 6.10.2.4.4.3Assessment units
Figure 37 — Decision Tree for requirement GEC-2
For each network interface and exposed service (via network interfaces) documented in [E.Info.GEC-2.NetworkInterface.Exposure] check whether the path through the decision tree documented in [E.Info.DT.GEC-2] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.GEC-2], examine its justification documented in [E.Just.DT.GEC-2].
# 6.10.2.4.4.4Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.GEC-2] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.GEC-2] ends with “FAIL”; and — the information provided in [E.Just.DT.GEC-2] are correct justifications for all paths through the decision tree documented in [E.Info.DT.GEC-2].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.GEC-2] ends with “FAIL”; or
— a justification provided in [E.Just.DT.GEC-2] is not correct or missing for a path through the decision tree documented in [E.Info.DT.GEC-2].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.2.4.5 Functional completeness assessment
# 6.10.2.4.5.1Assessment purpose
The purpose of this assessment case is the functional assessment whether in the factory default state only network interfaces or exposed services (via network interfaces) which are required for setup or for the basic operation of the equipment are exposed.
# 6.10.2.4.5.2Preconditions
The equipment is in the factory default state and if available setup or another configuration did not take place until now.
Physical network connections to check the exposure of services via network interfaces are established.
# 6.10.2.4.5.3 Assessment units
Functionally assess whether there are further network interfaces or services (via network interfaces) exposed in factory default state, which are not listed in [E.Info.GEC-2.NetworkInterface.Exposure] or which are not required for setup according to [E.Info.GEC-2.Setup] or to operate the equipment in basic operation.
NOTE Various software tools and measuring devices are available to automatically search for exposed network interfaces or services which are accessible via network interface.
# 6.10.2.4.5.4Assignment of verdict
The verdict PASS is assigned if every discovered network interface or service (via network interfaces) exposed in factory default state, is listed in [E.Info.GEC-2.NetworkInterface.Exposure] and is required for setup according to [E.Info.GEC-2.Setup] or for basic operation of the equipment.
The verdict FAIL is assigned if a network interface or a service (via network interfaces) exposed in factory default state is discovered that is not listed in [E.Info.GEC-2.NetworkInterface.Exposure] or not required for setup according to [E.Info.GEC-2.Setup] or for basic operation of the equipment.
The verdict NOT APPLICABLE is assigned otherwise.
# 6.10.2.4.6 Functional sufficiency assessment
Not applicable.
# 6.10.3 [GEC-3] Configuration of optional services and the related exposed network interfaces
# 6.10.3.1 Requirement
Optional network interfaces or optional services exposed via network interfaces affecting security assets or privacy assets, which are part of the factory default state shall have the option for an authorized user to enable and disable the network interface or service.
# 6.10.3.2 Rationale
This will reduce the attack surface related to network interfaces and to the services exposed via these.
# 6.10.3.3 Guidance
The equipment provides a functionality for an authorized user to configure (enable/disable) the exposed optional services and the related network interfaces which are part the factory default state.
The configuration of network related services ought to be protected according to access control mechanism (ACM) and authentication mechanism (AUM).
# 6.10.3.4 Assessment criteria
# 6.10.3.4.1 Assessment objective
The assessment addresses the requirement GEC-3.
# 6.10.3.4.2 Implementation categories
Not applicable.
# 6.10.3.4.3 Required information
[E.Info.GEC-3.NetworkInterface.Exposure]: Description of each network interface and exposed service (via network interfaces) in factory default state of the equipment, including information if there is an option for an authorized user to enable and disable the network interface or service.
[E.Info.GEC-3.SecurityAsset]: Description of each security asset that is accessible via network interfaces.
[E.Info.GEC-3.PrivacyAsset]: Description of each privacy asset that is accessible via network interfaces.
[E.Info.DT.GEC-3]: Description of the selected path through the decision tree in Figure 38 for each network interface and exposed optional service (via network interfaces) as documented in [E.Info.GEC-3.NetworkInterface.Exposure].
[E.Just.DT.GEC-3]: Justification for each selected path through the decision tree documented in [E.Info.DT.GEC-3] with the following properties:
(if a decision from [DT.GEC-3.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.GEC-3.DN-1] is based on [E.Info.GEC-3.SecurityAsset] and [E.Info.GEC-3.NetworkAsset]; and
— the justification for the decision [DT.GEC-3.DN-2] is based on [E.Info.GEC-3.NetworkInterface.Exposure].
# 6.10.3.4.4 Conceptual assessment
# 6.10.3.4.4.1Assessment purpose
The purpose of this assessment case is the conceptual assessment whether each optional network interface and each exposed optional service (via network interfaces) which is part of the factory default state of the equipment is configurable, at least with the option to enable and disable the service as required per GEC-3.
# 6.10.3.4.4.2 Assessment units
Figure 38 — Decision Tree for requirement GEC-3
For each optional network interface and exposed optional service (via network interfaces) documented in [E.Info.GEC-3.NetworkInterface.Exposure] that is part of the factory default state check whether the path through the decision tree documented in [E.Info.DT.GEC-3] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.GEC-3], examine its justification documented in [E.Just.DT.GEC-3].
# 6.10.3.4.4.3Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.GEC-3] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.GEC-3] ends with “FAIL”; and
— the information provided in [E.Just.DT.GEC-3] are correct justifications for all paths through the decision tree documented in [E.Info.DT.GEC-3].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.GEC-3] ends with “FAIL”; or
— a justification provided in [E.Just.DT.GEC-3] is not correct or missing for a path through the decision tree documented in [E.Info.DT.GEC-3].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.3.4.5 Functional completeness assessment
# 6.10.3.4.5.1Assessment purpose
The purpose of this assessment case is the functional assessment whether all optional network interfaces and exposed optional services (via network interfaces) which are part of the factory default state are configurable, at least with the option to enable and disable the service. Therefore, the completeness of documentation needs to be examined.
# 6.10.3.4.5.2Preconditions
The equipment is in an operational state and if available the setup is done.
The necessary privileges are available for the configuration of the settings of the optional network interfaces or optional services (exposed via network interfaces).
# 6.10.3.4.5.3Assessment units
Functionally assess whether there are optional network interfaces or exposed optional services (via network interfaces), which are not listed in [E.Info.GEC-3.NetworkInterface.Exposure].
# 6.10.3.4.5.4Assignment of verdict
The verdict PASS for the assessment case is assigned if there are no optional network interfaces or optional services (via network interfaces) exposed, which are not listed in [E.Info.GEC-3.NetworkInterface.Exposure].
The verdict FAIL for the assessment case is assigned if there are optional network interfaces or optional services (via network interfaces) exposed, which are not listed in [E.Info.GEC-3.NetworkInterface.Exposure].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.3.4.6 Functional sufficiency assessment
# 6.10.3.4.6.1Assessment purpose
The purpose of this assessment case is the functional assessment whether all optional network interfaces and optional services (via network interfaces) exposed which are part of the factory default state are configurable, at least with the option to enable and disable the service.
# 6.10.3.4.6.2Preconditions
The equipment is in an operational state and if available the setup is done.
The necessary privileges are available for the configuration of the settings of the optional network interfaces or optional services (via network interfaces).
# 6.10.3.4.6.3 Assessment units
For each optional network interface and optional service (via network interface) exposed that is part of the factory default state:
— Functionally assess whether the optional network interfaces and exposed optional services (via network interfaces) which are part of the factory default state and documented in [E.Info.GEC-3.NetworkInterface.Exposure] are configurable; and
— functionally assess if it is possible to at least change the status of the optional network interfaces and exposed optional services (via network interfaces) to enabled and disabled; and
— functionally assess whether the configuration of the settings of the optional network interfaces and exposed optional services (via network interfaces) which are part of the factory default state and listed in [E.Info.GEC-3.NetworkInterface.Exposure] is only possible by authorized users.
# 6.10.3.4.6.4Assignment of verdict
The verdict PASS for the assessment case is assigned if there is evidence that all optional network interfaces or exposed optional services (via network interfaces) are configurable at least with the option to enable and disable the network interface or service or changing the status of the optional network interfaces or exposed optional services (via network interfaces) to enabled or disabled is only possible by an authorized user as described in [E.Info.GEC-3.NetworkInterface.Exposure].
The verdict FAIL for the assessment case is assigned if there is no evidence that all optional network interfaces or exposed optional services (via network interface) are configurable at least with the option to enable and disable the network interface or service or changing the status of the optional network interface or exposed optional services (via network interface) to enabled or disabled is only possible by an authorized user as described in [E.Info.GEC-3.NetworkInterface.Exposure].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.4 [GEC-4] Documentation of exposed network interfaces and exposed services via network interfaces
# 6.10.4.1 Requirement
The equipment’s user documentation shall contain a description of
- all exposed network interfaces; and
— all services exposed via network interfaces,
which are delivered as part of the factory default state.
# 6.10.4.2 Rationale
The equipment itself and the surrounding network needs to be configured properly to assure the functionality of the equipment and to support the security of the network. Therefore, it is important to provide user information regarding the exposed network interfaces and exposed services (via network interfaces) and the intended operational environment of use.
# 6.10.4.3 Guidance
All network interfaces and exposed services (via network interfaces) in factory default state are to be listed in the documentation. For each service, its purpose could be provided as well. The aim is to provide transparency to the user about the connectivity of the equipment. Furthermore, the documentation serves to assess whether the commissioning of the equipment creates potential attack surfaces to the user’s intended environment of use.
# 6.10.4.4 Assessment criteria
# 6.10.4.4.1 Assessment objective
The assessment addresses the requirement GEC-4.
# 6.10.4.4.2 Implementation categories
Not applicable.
# 6.10.4.4.3 Required information
[E.Info.GEC-4.UserDoc.NetworkInterface.Exposure]: User documentation of each exposed network interface and exposed service (via network interfaces) in factory default state of the equipment.
[E.Info.GEC-4.NetworkInterface.Exposure]: Description of each exposed network interface and exposed service (via network interfaces) in factory default state of the equipment.
[E.Info.DT.GEC-4]: Description of the selected path through the decision tree in Figure 39 for each exposed network interface and exposed service (via network interfaces) as documented in [E.Info.GEC-4.NetworkInterface.Exposure].
[E.Just.DT.GEC-4]: Justification for each selected path through the decision tree documented in [E.Info.DT.GEC-4] with the following properties:
— (if a decision from [DT.GEC-4.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.GEC-4.DN-1] is based on [E.Info.GEC-4.NetworkInterface.Exposure]; and
— the justification for the decision [DT.GEC-4.DN-2] is based on [E.Info.GEC-4.UserDoc.NetworkInterface.Exposure].
# 6.10.4.4.4 Conceptual assessment
# 6.10.4.4.4.1Assessment purpose
The purpose of this assessment case is the conceptual assessment whether all network interfaces and services which are exposed via network interfaces and are delivered as part of the factory default state are described in the user documentation as required per GEC-4.
# 6.10.4.4.4.2Preconditions
None.
# 6.10.4.4.4.3 Assessment units
Figure 5 — Decision Tree for requirement GEC-4
For each network interface and exposed service (via network interfaces) in [E.Info.GEC-4.NetworkInterface.Exposure] check whether the path through the decision tree documented in [E.Info.DT.GEC-4] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.GEC-4], examine its justification documented in [E.Just.DT.GEC-4].
# 6.10.4.4.4.4Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.GEC-4] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.GEC-4] ends with “FAIL”; and
— the information provided in [E.Just.DT.GEC-4] are correct justifications for all paths through the decision tree documented in [E.Info.DT.GEC-4].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.GEC-4] ends with “FAIL”; or
— a justification provided in [E.Just.DT.GEC-4] is not correct or missing for a path through the decision tree documented in [E.Info.DT.GEC-4].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.4.4.5 Functional completeness assessment
# 6.10.4.4.5.1Assessment purpose
The purpose of this assessment case is the functional assessment whether the user documentation describes every network interface and exposed service (via network interfaces) which are delivered as part of the factory default state.
# 6.10.4.4.5.2Preconditions
The equipment is in a factory default state.
Network connections to check the exposure of network interfaces and services (via network interfaces) are established.
# 6.10.4.4.5.3 Assessment unit
To assess if the documentation of network interfaces and exposed services (via network interfaces) is complete:
— functionally assess whether there are further network interfaces that are exposed in the factory default state which are not documented in [E.Info.GEC-4.UserDoc.NetworkInterface.Exposure]; and
— functionally assess whether there are further exposed services (via network interfaces) that are not documented in [E.Info.GEC-4.UserDoc.NetworkInterface.Exposure].
NOTE Exposed network interfaces and services can be found with network scanning tools and service scanning tools.
# 6.10.4.4.5.4Assignment of verdict
The verdict PASS for the assessment case is assigned if all network interfaces or exposed services (via network interfaces) in factory default state found are documented in [E.Info.GEC-4.NetworkInterface.Exposure].
The verdict FAIL for the assessment case is assigned if a network interface or an exposed service (via network interfaces) in factory default state is found which is not documented in [E.Info.GEC-4.NetworkInterface.Exposure].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.4.4.6 Functional sufficiency assessment
None.
# 6.10.5 [GEC-5] No unnecessary external interfaces
# 6.10.5.1 Requirement
The equipment shall only expose physical external interfaces if they are necessary for its intended functionality.
# 6.10.5.2 Rationale
Physical external interfaces need to be kept to the minimum in order to minimise the potential attack surface.
# 6.10.5.3 Guidance
In cases where an unnecessary physical external interface is physically protected by its intended operational environment of use, this external interface is considered as not exposed by the equipment. External interfaces that are disabled or blocked are considered as not exposed by the equipment as well.
Physical external interfaces might include external interfaces that are intentionally used for internal system communication as well as user interfaces and machine interfaces.
The intended functionality could cover multiple use-cases and the physical external interfaces exposed need to serve a purpose in at least one of the use-cases.
# 6.10.5.4 Assessment criteria
# 6.10.5.4.1 Assessment objective
The assessment addresses the requirement GEC-5.
# 6.10.5.4.2 Implementation categories
Not applicable.
# 6.10.5.4.3 Required information
[E.Info.GEC-5.PhysicalExternalInterface]: Description of each physical external interface including:
— [E.Info.GEC-5.PhysicalExternalInterface.Purpose]: The purpose of the interface; and
— [E.Info.SCM-1.PhysicalExternalInterface.Type]: Description of the interface type (e.g. USB-C).
[E.Info.GEC-5.IntFunc]: Description of the intended functionality of the equipment.
[E.Info.DT.GEC-5]: Description of the selected path through the decision tree in Figure 40 for each physical external interface documented in [E.Info.GEC-5.PhysicalExternalInterface].
[E.Just.DT.GEC-5]: Justification for the selected path through the decision tree documented in [E.Info.DT.GEC-5], with the following property:
— the justification for the decision [DT.GEC-5.DN-1] is based on [E.Info.GEC-5.PhysicalExternalInterface].
# 6.10.5.4.4 Conceptual assessment
# 6.10.5.4.4.1Assessment purpose
The purpose of this assessment case is the conceptual assessment whether each exposure of physical external interfaces is restricted to the ones which are necessary for its intended functionality as required per GEC-5.
# 6.10.5.4.4.2Preconditions
None.
# 6.10.5.4.4.3 Assessment units
Figure 40 — Decision Tree for requirement GEC-5
For each physical external interface documented in [E.Info.GEC-5.PhysicalExternalInterface] check whether the path through the decision tree documented in [E.Info.DT.GEC-5] ends with “PASS”.
For each path through the decision tree documented in [E.Info.DT.GEC-5], examine its justification documented in [E.Just.DT.GEC-5].
# 6.10.5.4.4.4Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— all paths through the decision tree documented in [E.Info.DT.GEC-5] end with “PASS”; and
— the information provided in [E.Just.DT.GEC-5] are correct justifications for all paths through the decision tree documented in [E.Info.DT.GEC-5].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.GEC-5] ends with “FAIL”; or
— a justification provided in [E.Just.DT.GEC-5] is not correct or missing for a path through the decision tree documented in [E.Info.DT.GEC-5].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.5.4.5 Functional completeness assessment
# 6.10.5.4.5.1Assessment purpose
The purpose of this assessment case is the functional assessment whether only physical external interfaces are exposed which are required for the intended functionality, as documented in [E.Info.GEC-5.PhysicalExternalInterface].
# 6.10.5.4.5.2Preconditions
The equipment is operational.
# 6.10.5.4.5.3 Assessment units
Attempt to reveal any via the equipment exposed physical external interfaces even if the related function is not enabled or documented in [E.Info.GEC-5.PhysicalExternalInterface]:
— Examine equipment documentation such as design documentation, use case documentation and user manual; and
— examine the equipment which physical external interfaces are present on the equipment such as microphones, screens, buttons or slots for extension cards.
For each revealed physical external interface during the examination of documentation and also the examination of the equipment assess the documentation in [E.Info.GEC-5.PhysicalExternalInterface].
# 6.10.5.4.5.4Assignment of verdict
The verdict PASS for the assessment case is assigned if all physical external interfaces found are documented in [E.Info.GEC-5.PhysicalExternalInterface].
The verdict FAIL for the assessment case is assigned if a physical external interface is found that is not documented in [E.Info.GEC-5.PhysicalExternalInterface].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.5.4.6 Functional sufficiency assessment
Not applicable.
# 6.10.6 [GEC-6] Input validation
# 6.10.6.1 Requirement
The equipment shall validate input received via external interfaces if the input has potential impact on security assets and/or privacy assets.
# 6.10.6.2 Rationale
The equipment needs to validate any input which has potential impact to security assets or privacy assets to mitigate potential misuse, corruption, or unauthorized extraction of data on security assets and privacy assets.
Input validation is necessary to validate for instance the syntax, length and content of any input data that is provided as expected input and has the properties that are required to process the data correctly.
Improper input validation is regarded as one of the most common and dangerous software weaknesses which also contributes to several other software weaknesses like out-of-bounds write, and improper neutralization which can lead to various injection vulnerabilities (e.g., SQL injection, OS command injection and path traversal).
Especially data from potentially untrusted sources like any input received via network interfaces, need to be subject to input validation by checking the input for both syntax and semantics correctness. These checks ought to be done as early as possible when processing any input to avoid propagating invalid and perhaps even malicious input.
# 6.10.6.3 Guidance
Improper input validation is one of the root causes for many security vulnerabilities, input can only be successfully processed when it has been established that the input is valid by checking the syntax and semantics of the input, both on the raw data and metadata.
Syntax validation is checking that the input is delivered in the correct structure, for instance:
— the format of a date entry (e.g., dd-mm-yyyy or mm-dd-yyyy);
— the use of a decimal point or comma in a numeric input;
— the length of the input;
— correct headers and structures for various file types (e.g., validate a .ZIP., .BMP or .JPEG file structure);
— a valid json, xml or html file.
Semantics validation is checking that the input is delivered with correct values, for instance:
— a value that is outside the expected range (e.g., a number that is too small or too large, a birthday in the future);
— special characters which are not allowed in a text input, e.g., special escape characters used for SQL injection;
— incorrect data size and offset values in a structure (e.g., an incorrect size might cause a buffer overrun when data is copied without checks, or a negative offset might copy incorrect data from the stack);
— inclusive listing (also known as “allow listing”) is a method which only permits defined input (e.g., specified values or expressions), everything else will be rejected as input.
Using parsers and/or regular expressions are methods to validate for instance text input. A developer could also consider other techniques to ensure an input can be successfully processed such as filtering and encoding.
Further guidance to be considered:
Common Weakness Enumeration: Improper input validation (CWE-20), encoding/escaping (CWE-116), Improper Neutralization of Special Elements (CWE-138) and filtering (CWE-790); https://cwe.mitre.org/data/index.html
— Open Web Application Security Project (OWASP) Input Validation Cheat Sheet; - https://cheatsheetseries.owasp.org/cheatsheets/Input\_Validation\_Cheat\_Sheet.html
— IEC EN 62443-4-2[2] CR 3.5 (Input validation) and
— ETSI EN 303 645[6] 5.13 (Validate input data).
# 6.10.6.4 Assessment criteria
# 6.10.6.4.1 Assessment objective
The assessment addresses the requirement GEC-6.
# 6.10.6.4.2 Implementation categories
Not applicable.
# 6.10.6.4.3 Required information
[E.Info.GEC-6.ExternalInterface]: Description of each external interface including:
[E.Info.GEC-6.ExternalInterface.Capabilities]: Description of any used APIs, protocols, input data types, file formats; and
— [E.Info.GEC-6.ExternalInterface.Validation]: Description how the input for instance via checking syntactic and semantic correctness is validated.
[E.Info.GEC-6.SecurityAsset]: Description of each security asset that is potentially impacted via external interfaces.
[E.Info.GEC-6.PrivacyAsset]: Description of each privacy asset that is potentially impacted via external interfaces.
[E.Info.DT.GEC-6]: Description of the selected path through the decision tree in Figure 41 for each of the external interfaces documented in [E.Info.GEC-6.ExternalInterface].
[E.Just.DT.GEC-6]: Justification for the selected path through the decision tree documented in [E.Info.DT.GEC-6] with the following properties:
(if a decision from [DT.GEC-6.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.GEC-6.DN-1] is based on [E.Info.GEC-6.ExternalInterface] and [E.Info.GEC-6.ExternalInterface.Capabilities]; and
— the justification for the decision [DT.GEC-6.DN-2] is especially based on [E.Info.GEC-6.ExternalInterface], [E.Info.GEC-6.ExternalInterface.Validation] and [E.Info.GEC-6.ExternalInterface.Capabilities].
# 6.10.6.4.4 Conceptual assessment
# 6.10.6.4.4.1Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the input validation functionality of the equipment is applied to the external interfaces and provides appropriate protection of security assets and/or privacy assets against common attacks considering the intended functionality of the equipment as required per GEC-6.
# 6.10.6.4.4.2Preconditions
None.
# 6.10.6.4.4.3 Assessment units
Figure 41 — Decision Tree for requirement GEC-6
For each external interface documented [E.Info.GEC-6.ExternalInterface], check whether the path through the decision tree documented in [E.Info.DT.GEC-6] ends with “PASS” or “NOT APPLICABLE”.
For each path through the decision tree documented in [E.Info.DT.GEC-6], examine its justification documented in [E.Just.DT.GEC-6].
# 6.10.6.4.4.4Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.GEC-6] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.GEC-6] ends with “FAIL”; and
— the information provided in [E.Just.DT.GEC-6] are correct justifications for all paths through the decision tree documented in [E.Info.DT.GEC-6].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.GEC-6] ends with “FAIL”; or
— a justification provided in [E.Just.DT.GEC-6] is not correct or missing for a path through the decision tree documented in [E.Info.DT.GEC-6].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.6.4.5 Functional completeness assessment
# 6.10.6.4.5.1Assessment purpose
The purpose of this assessment case is the functional assessment of the external interfaces of the equipment and the related input mechanisms regarding the completeness of the documentation.
# 6.10.6.4.5.2Preconditions
The equipment is in an operational state and all external interfaces, which are part of the intended functionality, are either enabled or configurable to be enabled, so that each external interface can be tested.
Where authentication is necessary to access an external interface, a means is provided to be able to test the interface.
# 6.10.6.4.5.3 Assessment units
Functionally assess whether there are input methods that are not documented in [E.Info.GEC-6.ExternalInterface] by:
— functionally assessing traffic of network interfaces to reveal input methods, e.g. via network analysing tools; use the information in [E.Info.GEC-6.ExternalInterface] as a guidance; and
— functionally assessing equipment to reveal input methods of external interfaces which are no network interfaces via visual inspection, user manual and design-documentation; and
— following the description in [E.Info.GEC-6.ExternalInterface.Capabilities] to trigger the related input methods, e.g. via generating the described messages (e.g., via a web interface or generic message generating tools, or fuzzing tools).
# 6.10.6.4.5.4Assignment of verdict
The verdict PASS for the assessment case is assigned if all external interfaces found are documented in [E.Info.GEC-6.ExternalInterface].
The verdict FAIL for the assessment case is assigned if an external interface is found that is not documented in [E.Info.GEC-6.ExternalInterface].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.6.4.6 Functional sufficiency assessment
# 6.10.6.4.6.1Assessment purpose
The purpose of this assessment case is the functional assessment of the techniques to verify the implementation of the documented techniques.
# 6.10.6.4.6.2Preconditions
The equipment is in an operational state and all external interfaces, which are part of the intended functionality, are either enabled or configurable to be enabled, so that each external interface can be tested.
Where authentication is necessary to access an external interface, a means is provided to be able to test the interface.
# 6.10.6.4.6.3Assessment units
Functionally assess whether each external interface is resilient against common input attacks considering their functionality and the intended functionality of the equipment by:
following the description in [E.Info.GEC-6.ExternalInterface] as guidance to test the related input methods e.g., via generating malformed or invalid messages (e.g., via a web interface or generic message generating tools, or fuzzing tools): Attempt to corrupt, extract or misuse the security assets described in [E.Info.GEC-6.SecurityAsset] and network assets described in [E.Info.GEC-6.NetworkAsset] by executing specific attacks related to the input mechanisms like SQL injection, Ajax injection, OS command injection or path traversal as well; and
— functionally assessing if the behaviour or output described in [E.Info.GEC-6.ExternalInterface] is generated as documented, use equipment manual or designdocumentation as guidance.
# 6.10.6.4.6.4Assignment of verdict
The verdict PASS for the assessment case is assigned if there is no evidence that any input validation testing was successful to corrupt, extract or misuse any security asset as described in [E.Info.GEC-6.SecurityAsset] or privacy asset as described in [E.Info.GEC-6.PrivacyAsset].
The verdict FAIL for the assessment case is assigned if there is evidence that an input validation testing was successful to corrupt, extract or misuse any security asset as described in [E.Info.GEC-6.SecurityAsset] or privacy asset as described in [E.Info.GEC-6.PrivacyAsset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.7 [GEC-7] Documentation of external sensing capabilities
# 6.10.7.1 Requirement
All external sensing capabilities of the equipment that are related to the user’s or subscriber’s privacy shall be documented for the user.
# 6.10.7.2 Rationale
External sensing functions could be misused to spy out the user of the equipment. If the user is not aware of the sensing capabilities of the equipment it may unintentionally be used in privacy related locations. Documenting the external sensing capabilities makes users aware of what the equipment might technically expose about their privacy. With this awareness, users can adjust their use of the equipment to minimise the risk of their privacy being compromised.
# 6.10.7.3 Guidance
The manufacturer needs to be clear and transparent to the user what can be captured with the sensors present in the equipment. Based on this information the user could, e.g. cover the camera with a sticker. Furthermore, information concerning the sensing capabilities of the equipment during the initial configuration process may be given.
An example for an external sensing capability is a microphone or a camera.
# 6.10.7.4 Assessment criteria
# 6.10.7.4.1 Assessment objective
The assessment addresses the requirement GEC-7.
# 6.10.7.4.2 Implementation categories
Not applicable.
# 6.10.7.4.3 Required information
(If non-network external interfaces are available) [E.Info.GEC-7.NonNetworkInterface]: Description of each non-network external interface of the equipment, that can affect the user’s or subscriber’s privacy.
(if non-network external interfaces can affect the user’s or subscriber’s privacy) [E.Info.GEC-7.UserDoc.NonNetworkInterface]: User documentation describing each non-network external interface of the equipment that can affect the user’s or subscriber’s privacy.
[E.Info.DT.GEC-7]: Description of the selected path through the decision tree in Figure 42 for each nonnetwork external interface as documented in [E.Info.GEC-7.NonNetworkInterface].
[E.Just.DT.GEC-7]: Justification for each selected path through the decision tree documented in [E.Info.DT.GEC-7] with the following properties:
— (if a decision from [DT.GEC-7.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.GEC-7.DN-1] is based on [E.Info.GEC-7.NonNetworkInterface]; and
— the justification for the decision [DT.GEC-7.DN-2] is based on [E.Info.GEC-7.UserDoc.NonNetworkInterface].
# 6.10.7.4.4 Conceptual assessment
# 6.10.7.4.4.1Assessment purpose
The purpose of this assessment case is the conceptual assessment whether all non-network external interfaces which are offering sensing capabilities, and which are related to the users’ or subscriber’s privacy are described in the user documentation as required per GEC-7.
# 6.10.7.4.4.2Preconditions
None.
# 6.10.7.4.4.3Assessment units
Figure 42 — Decision Tree for requirement GEC-7
For each non-network external interface documented in [E.Info.GEC-7.NonNetworkInterface] check whether the path through the decision tree documented in [E.Info.DT.GEC-7] ends with “NOT APPLICABLE” or “PASS”.
For each path through the decision tree documented in [E.Info.DT.GEC-7], examine its justification documented in [E.Just.DT.GEC-7].
# 6.10.7.4.4.4Assignment of verdict
The verdict PASS for the assessment case is assigned if:
— at least one path through the decision tree documented in [E.Info.DT.GEC-7] ends with “PASS”; and
— no path through the decision tree documented in [E.Info.DT.GEC-7] ends with “FAIL”; and
— the information provided in [E.Just.DT.GEC-7] are correct justifications for all paths through the decision tree documented in [E.Info.DT.GEC-7].
The verdict FAIL for the assessment case is assigned if:
— a path through the decision tree documented in [E.Info.DT.GEC-7] ends with “FAIL”; or
— a justification provided in [E.Just.DT.GEC-7] is not correct or missing for a path through the decision tree documented in [E.Info.DT.GEC-7].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.7.4.5 Functional completeness assessment
# 6.10.7.4.5.1Assessment purpose
The purpose of this assessment case is the functional assessment whether all non-network external interfaces that can affect the user’s or subscriber’s privacy, are described in the user documentation.
# 6.10.7.4.5.2Preconditions
The equipment is in an operational state.
# 6.10.7.4.5.3Assessment units
Functionally assess whether there are further non-network external interfaces, that can affect the user’s or subscriber’s privacy, and which are not documented in [E.Info.GEC-7.NonNetworkInterface].
# 6.10.7.4.5.4Assignment of verdict
The verdict FAIL for the assessment case is assigned if all non-network external interfaces found that can affect the user’s or subscriber’s privacy are documented in [E.Info.GEC-7.NonNetworkInterface].
The verdict FAIL for the assessment case is assigned if a non-network external interface found that can affect the user’s or subscriber’s privacy is not documented in [E.Info.GEC-7.NonNetworkInterface].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.10.7.4.6 Functional sufficiency assessment
None.
# 6.11 [CRY] Cryptography
# 6.11.1 [CRY-1] Best practice cryptography
# 6.11.1.1 Requirement
The equipment shall use best practice for cryptography that is used for the protection of the security assets or privacy assets, except for:
— cryptography used for a specific security mechanism, where a deviation is identified and justified under the terms of sections ACM or AUM or SCM or SUM or SSM.
# 6.11.1.2 Rationale
Cryptography that is not strong enough for a use case, e.g., because it is not suitable or broken and used for the protection of security assets or privacy assets poses a security risk to these assets. Using best practices or even more advanced, evidently suitable cryptography supports trust in the cryptographic protection of these assets.
If a cryptographic algorithm is cracked or cryptographic primitives are compromised, it may be necessary to update the equipment accordingly (see requirement SUM) in order to preserve the protection of the security assets and privacy assets the cryptography protects. While there is no absolute guarantee that this does not happen to any cryptography that is considered as best practice, it is more likely that cryptography becomes unsuitable for a certain use case, when there is already evidence that such cryptography might become deprecated within the intended lifetime of the equipment.
However, e.g., if the equipment can itself communicate over the internet and contains a hardware based crypto accelerator, it might not be prepared to update cryptography. In these cases, it is important that there is no evidence that the cryptography will not be best practice within the intended lifetime.
# 6.11.1.3 Guidance
There is various security guidance that can be used to identify best practices for cryptography, see respective ISO/IEC standards, publicly available crypto catalogues provided by SDOs and public authorities such as sogis.eu, “SOGIS agreed Cryptographic Mechanisms” [24], ETSI TS 119 312 Electronic Signatures and Infrastructures; Cryptographic Suites [27] and guidance provided by ENISA and national agencies as the NIST SP800 series [8]- [18] and BSI TR-02102-1[20]
A commonly used cryptographic method for a certain use case, with the lack of evidence for a feasible attack with current readily available techniques, can be considered as best practice.
However, it is also possible to provide evidence, that new cryptography is suitable for a certain use case and can therefore be considered as best practice for cryptography.
Cryptography is often used for protecting the relevant security assets and privacy assets, for example:
— Authentication (see AUM),
— Secure update (see SUM),
— Secure storage (see SSM),
— Secure communication (see SCM),
— Confidential Cryptographic key Generation (see CCK-2).
Cryptographic protection might not be compliant with best practice cryptography if interoperability is required. Legacy mechanism, that are deployed on a large scale are considered to provide an acceptable short – term security and suffer from some security assurance limitations as compared with the identified best practice mechanism in the above referenced crypto- catalogues (see e.g., sogis.eu). For up-to date lists of legacy mechanism and their validity period given by a deprecation deadline, the crypto catalogues are updated on a regular short-term basis (e.g., annually).
If reviewed or evaluated implementations according to the best practice are publicly available, these may be preferable used to deliver network and security functionalities, particularly in the field of cryptography.
To maintain best practices for cryptography within the intended lifetime of the equipment concepts to consider are crypto agility additional to the capability of updating cryptography on the equipment in accordance to SUM to respond to new attacks and new technological developments.
Elements to observe for the preparation of updating cryptography are amongst others:
— cryptographic schemes, protocols, algorithms, constructors and primes,
— the form of sensitive security parameters being used, and
— specific SSPs, such as roots of trust.
For equipment that cannot have their cryptographic algorithms or primitives updated for example if the implementation or part uses a hardware-based root of trust, it is important that the intended lifetime of the equipment does not exceed the recommended usage lifetime of the cryptographic algorithms and primitives used by the equipment.
# 6.11.1.4 Assessment criteria
# 6.11.1.4.1 Assessment objective
The assessment addresses the requirement CRY-1.
# 6.11.1.4.2 Implementation categories
Not applicable.
# 6.11.1.4.3 Required information
[E.Info.CRY-1.Assets]: List of all security assets and privacy assets on the equipment protected by cryptography, including for each cryptography used for cryptographic protection:
— [E.Info.CRY-1.Assets.Cryptography]: Description of the cryptography used for cryptographic protection, including:
o description of each cryptographic protection goal; and
0 evidence to justify that the cryptography is best practice for the cryptographic protection goals
or;
(if a deviation is identified and justified under the terms of sections ACM or AUM or SCM or SUM or SSM)[E.Info.CRY-1.Assets.Deviation]: Reference to the corresponding justification and to the required information the justification is based on.
NOTE 1 The documentation of a cryptographic protection goal includes the security objectives provided by cryptography.
NOTE 2 Cryptography used for cryptographic protection can amongst others include cryptographic schemes, algorithms, constructors and primes.
NOTE 3 Evidence to justify that the cryptography is best practice for the cryptographic protection goals can be based a reference catalogues, e.g., SOGIS Agreed Cryptographic Mechanisms (https://www.sogis.eu) [24], or other evidence, e.g., by cryptoanalysis.
[E.Info.DT.CRY-1]: Description of the selected path through the decision tree in Figure 43 for each security asset and privacy asset described in [E.Info.CRY-1.Assets].
[E.Just.DT.CRY-1]: Justification for each selected path through the decision tree documented in [E.Info.DT.CRY-1] with the following properties:
— (if a decision from [DT.CRY-1.DN-1] results in “NOT APPLICABLE”) the justification for the decision [DT.CRY-1.DN-1] is based on [E.Info.CRY-1.Assets.Deviation]; and
— the justification for the decision [DT.CRY-1.DN-2] is based on [E.Info.CRY-1.Assets.Cryptography].
# 6.11.1.4.4 Conceptual Assessment
# 6.11.1.4.4.1Assessment purpose
The purpose of this assessment case is the conceptual assessment whether the implemented cryptography for protecting security assets or privacy assets is considered as best practice as required per CRY-1.
# 6.11.1.4.4.2Preconditions
None.
# 6.11.1.4.4.3 Assessment units
Figure 43 — Decision Tree for requirement CRY-1
For each security asset and privacy asset documented in [E.Info.CRY-1.Assets], check whether the path through the decision tree documented in [E.Info.DT.CRY-1] ends with “NOT APPLICABLE"or"PASS".
For each path through the decision tree documented in [E.Info.DT.CRY-1], examine its justification documented in [E.Just.DT.AUM-1-1].
# 6.11.1.4.4.4Assignment of verdict
The verdict PASS for the assessment case is assigned if:
− at least one path through the decision tree documented in [E.Info.DT.CRY-1] ends with “PASS”; and
− no path through the decision tree documented in [E.Info.DT.CRY-1] ends with “FAIL”; and
the information provided in [E.Just.DT.CRY-1] are correct justifications for all paths through the decision tree documented in [E.Info.DT.CRY-1].
The verdict FAIL for the assessment case is assigned if:
− all path through the decision tree documented in [E.Info.DT.CRY-1] ends with “FAIL”; or
a justification provided in [E.Just.DT.CRY-1] is not correct or missing for a path through the decision tree documented in [E.Info.DT.CRY-1].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.11.1.4.5 Functional completeness assessment
# 6.11.1.4.5.1Assessment purpose
The purpose of this assessment case is the functional assessment whether the documentation in [E.Info.CRY-1.Assets.Cryptography] is complete.
# 6.11.1.4.5.2Preconditions
The equipment is in an operational state.
# 6.11.1.4.5.3Assessment units
Check whether there is evidence of cryptography used on the equipment for the protection of the security assets or security assets that is not documented in [E.Info.CRY-1.Assets.Cryptography].
NOTE Cryptography introduced by software updates to mitigate vulnerabilities or raise the security level are not to be considered as deviations from the documentation.
# 6.11.1.4.5.4Assignment of verdict
The verdict PASS for the assessment case is assigned if no evidence for cryptography used on the equipment is found that is not documented in [E.Info.CRY-1.Assets.Cryptography].
The verdict FAIL for the assessment case is assigned if any evidence for cryptography used on the equipment is found that is not documented in [E.Info.CRY-1.Assets.Cryptography].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# 6.11.1.4.6 Functional sufficiency assessment
# 6.11.1.4.6.1Assessment purpose
The purpose of this assessment case is the functional assessment whether the cryptography documentation in [E.Info.CRY-1.Assets.Cryptography] is implemented as it is documented.
# 6.11.1.4.6.2Preconditions
The equipment is in an operational state.
# 6.11.1.4.6.3 Assessment units
For each cryptographic protection documented in [E.Info.CRY-1.Assets.Cryptography] check whether there is evidence that the implementation deviates from its documentation.
NOTE Differences due to software updates to mitigate vulnerabilities or raise the security level are not to be considered as deviations from the documentation.
# 6.11.1.4.6.4Assignment of verdict
The verdict PASS for the assessment case is assigned if no evidence for the deviation of cryptography from its documentation in [E.Info.CRY-1.Assets.Cryptography] is found.
The verdict FAIL for the assessment case is assigned if any evidence for the deviation of cryptography from its documentation in [E.Info.CRY-1.Assets.Cryptography] is found.
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
# Annex A (informative)
# Rationale
# A.1 General
This annex provides a rationale for terms and concepts related to this document.
# A.2 Rationale
# A.2.1 Family of standards
This document belongs to a set of three standards to address the essential requirements defined in articles 3.3.d, 3.3e and 3.3.f of Directive 2014/53/EU [36] and activated by the Commission Delegated Regulation (EU) 2022/30 [37]. By using the Radio Equipment Directive, a first step has been made to start to enforce cybersecurity requirements for placing radio equipment on the European market, because a lack of security was and is an increasing concern for society, especially for consumer IoT equipment.
While the three standards focus on different essential requirements (harm to the network, personal data and privacy and protection from (financial) fraud) there are both unique and overlapping requirements in each of them that will require the implementation an increasing number of stronger security controls to protect the network, privacy, and financial assets operating within a developing threat landscape.
Whether one or multiple standards need to be applied to a specific radio equipment is a consideration that is made through a product-relevant risk assessment [38] by the economic operator in order to identify threats and assess risks on the need to fulfil the essential requirements of the Radio Equipment Directive. The RED [39] and Blue guides [38] of the European Commission can provide more guidance on this topic.
# A.2.2 Security by design
Effective security management requires established security by design processes, which is not covered by this document which defines common security requirements for the equipment. Examples of security by design process standards which would aid in the ability to satisfy the security requirements include:
— IEC 62443-4-1[1]: Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements
— NIST 800-160[17]: Systems Security Engineering; Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems
— NIST 800-218[18]: Secure Software Development Framework (SSDF)
— Microsoft Security Development Lifecycle (SDL)
— SAFECode Fundamental Practices for Secure Software Development
— GSMA FS.16 NESAS Development and Lifecycle Security Requirements
# A.2.3 Threat modelling and security risk assessment
STRIDE is an example of a classification scheme, useful for system decomposition, for characterizing identified threats according to the kinds of exploit that are used by the attacker. The STRIDE acronym is formed from the first letter of each of the following threat categories:
Table A.1 — STRIDE
| Req.ID | ETSI EN 303 645 Provision: rationale |
| ACM-1 | Provision 5.5-4.The provision concerns device functionality, which includes security assets and privacy assets.Provision 5.5-5.The provision focuses on security configuration, which is also part of security assets. |
| ACM-2 | Provision 5.5-5.Security assets include security configuration, which is covered by the provision.Provision 5.6-7.Least privilege principle as in the guidance section is ensured. |
| ACM-3 | Not covered in EN 303 645 [6] |
| ACM-4 | Not covered in EN 303 645 [6] |
| ACM-5 | Provision 5.5-5.Security-relevant changes in configuration includes configuration of access control mechanisms. |
| ACM-6 | Provision 5.5-5.Security-relevant changes in configuration includes configuration of access control mechanisms. |
| AUM-1 | Provision 5.5-4.The provision concerns only an initial state.Provision 5.5-5.Security assets include security configuration, which is covered by the provision. |
| AUM-2 and CRY-1 | Provision 5.1-3.The authentication against the device can be assumed to include protection of network assets and security assets by requiring best practice cryptography, incl. authentication mechanisms (which may include PKI-based authentication) |
| AUM-3 | Not covered in EN 303 645 [6] |
| AUM-4 | Provision 5.1-4.The provision covers a change of the authentication mechanisms, which includes authenticator tokens. |
| AUM-5 | Provision 5.1-1.Uniqueness of passwords of different devices is enforced.Provision 5.1-2.Default passwords should be generated by a CSPRNG and therefore not be attackable by automated attacks.Provision 5.1-3.The provision covers the requirement regarding “best practice concerning strength” as it demands use of best practice cryptography. |
| AUM-6 | Provision 5.1-5.Both the provision and requirement demand the protection / mitigation against brute force attacks (incl. mass authentication attacks) |
| SUM-1 | Provision 5.3-1.The provision requires secure updates for each component.Provision 5.3-2.Secure Updates are required if there are no other reasons not to do them (e.g., constrained devices)Provision 5.3-15.The guidance includes a replacement strategy for equipment. |
| SUM-2 | Provision 5.3-9.The provision guarantees the authenticity and integrity of updates.Provision 5.3-10.The provision guarantees the authenticity and integrity of updates, especially via network. |
| SUM-3 | Provision 5.3-3.The guidance includes the simple updatability from a user's perspective.Provision 5.3-4.The provision includes automatic updates without human interaction.Provision 5.3-5.The guidance includes checking for updates after initialisation and periodically.Provision 5.3-6.Primarily, "asking user for consent to activate autoupdates" and "checking for updates after initialisation and periodically" are included in the guidance section. |
| SSM-1 | Provision 5.4-1.Secure storage mechanisms are demanded for security assets (which include security parameters).Provision 5.6-3.The provision only covers physical protection, but "hardware and physical protection" are included in the guidance section. |
| SSM-2 | Provision 5.4-1.The provision also protects security assets (which includes security parameters).Provision 5.4-2.The provision aims to provide protection against integrity loss, such as tampering. The rationale of the prEN includes protection against tampering, but the provision only focuses on hard-coded identity cases. |
| SSM-3 | Provision 5.4-1.Secure storage mechanisms are demanded for security assets (which include security parameters). |
| SCM-1 | Provision 5.5-6.Critical security parameters are protected by the provision, but privacy assets are not necessarily covered.Provision 5.5-7.The provision focuses on confidentiality of security parameters in transit.Provision 5.8-1.The provision focuses on confidentiality of personal data in transit.Provision 5.8-2.The provision focuses on confidentiality of sensitive personal data in transit. |
| SCM-2 | Not covered in EN 303 645 [6] |
| SCM-3 | Provision 5.5-6The provision demands encryption of transmitted critical security parameters.Provision 5.5-7.The provision demands encryption of transmitted critical security parameters.Provision 5.8-1.The provision demands encryption of transmitted personal data.Provision 5.8-2.The provision demands encryption of transmitted sensitive personal data. |
| SCM-4 | Provision 5.5-1.Best practice cryptography includes resiliency against replay attacks (see terms section). |
| LGM-1 | Not covered in EN 303 645 [6] |
| LGM-2 | Not covered in EN 303 645 [6] |
| LGM-3 | Not covered in EN 303 645 [6] |
| LGM-4 | Not covered in EN 303 645 [6] |
| DLM-1 | Provision 5.9-1The guidance section states “The equipment deletion mechanism is resilient resistant to interruptions”, which may include outages.Provision 5.11-1.The provision demands a deletion mechanism. |
| UNM-1 | Provision 6-1.Only changes are concerned in the requirement, the provision covers privacy notifications in general. |
| UNM-2 | Provision 6-1.Only changes are concerned in the requirement, the provision covers privacy notifications in general. |
| CCK-1 | Not covered in EN 303 645 [6] |
| CCK-2 | Provision 5.1-3.Methods for protecting access to security assets shall use best practice cryptography. |
| CCK-3 | Provision 5.1-1.The guidance section includes "security credentials", which includes passwords.Provision 5.4-4.The provision also covers to have unique security parameters. |
| GEC-1 | This requirement is not covered at the level of product requirement. However a manufacturer that complies with the processes Provisions 5.2-1, 5.2-2 and 5.2-3 will be facilitated to fulfil GEC-1 requirement. |
| GEC-2 | Provision 5.6-1.Unnecessary interfaces can be assumed as unused. Thus, both have the same requirements.Provision 5.6-5.Only services for operation and the setup of the device are allowed for both. |
| GEC-3 | Not covered in EN 303 645 [6] |
| GEC-4 | Not covered in EN 303 645 [6] |
| GEC-5 | Provision 5.6-1.Not intended equipment functionality can be considered as unused.Provision 5.6-3.Only physical interfaces are covered by the EN. |
| GEC-6 | Provision 5.13-1.Both the provision and the requirement demand input validation. |
| GEC-7 | Provision 5.8-3.Sensing capabilities are documented. |
| CRY-1 | Provision 5.1-3.The provision concerns authentication mechanisms, which is a part of the requirement.Provision 5.3-7.The provision concerns Secure Updates, which is a part of the requirement.Provision 5.5-1.The provision concerns Secure Communications, which is a part of the requirement.Provision 5.5-2.Reviewed or evaluated cryptography is preferred in the guidance section.Provision 5.5-3.The provision concerns crypto agility, which is considered in the guidance section.Provision 5.8-1The provision concerns personal data communicated, which is part of the requirement.Provision 5.8-2.The provision concerns sensitive personal data communicated, which is part of the requirement. |
# Annex D (informative)
# Mapping with Security Evaluation Standard for IoT Platforms (SESIP)
# D.1 General
This annex provides a mapping illustrating how the results of a SESIP (EN17927:2023) evaluation of connected platforms on which radio equipment are based, can be used as evidence to support radio equipment compliance demonstration to the requirements from the present document.
# D.2 Mapping
| Req.ID | EN17927:2023 SESIP support - evidence of implementation and assessment at equipment element/subcomponent level |
| ACM-1 to ACM-6 | Cryptographic Operation, Cryptographic Key Generation, Cryptographic KeyStore and/or Cryptographic Random Number Generation: those SESIP security claims assess the implementation of secure cryptographic services, which ones can be used by the equipment to implement an access control mechanism.Authenticated access control: this SESIP security claim assesses the implementation of a secure access control mechanism based on authentication, which one can be used directly by the equipment for access control purposes. |
| AUM-1 to AUM-6 | Cryptographic Operation, Cryptographic Key Generation, Cryptographic KeyStore and/or Cryptographic Random number Generation: those SESIP security claims assess the implementation of secure cryptographic services, which ones can be used by the equipment to implement an authentication mechanism.Authenticated access control: this SESIP security claim assesses the implementation of a secure access control mechanism based on authentication, which one can be used directly by the equipment for authentication purposes.An explicit refinement of the requirement can require the validation of authenticator, the ability to change the authenticator, the preventing of static and default values. Protection against brute force and other cryptographic attack is part of the SESIP vulnerability analysis (AVA_VAN.SESIP) evaluation activity. |
| SUM-1 to SUM-3 | Secure Update of platform, Secure Update of Application: this SESIP security claims assess the implementation of a secure update mechanism of the mutable part of the equipment element under evaluation, including the integrity and authenticity verification of the image to be installed/loaded.ALC_FLR: this SESIP evaluation activity assesses that for the equipment element under evaluation a process of flaw remediation is in place to allow the monitoring, the reporting and the correction of security issues which could be found in the field, and which would trigger the use of the secure update mechanism to mitigate the security issue. |
| SSM-1 to SSM-4 | Secure Trusted Storage, Secure Confidential Storage, Secure Encrypted Storage and/or Secure Data Serialization: those SESIP security claims assess the implementation of secure storage mechanisms, including authenticity, integrity and/or confidentiality protections depending on the related stored assets protection needed.Cryptographic KeyStore: This SESIP security claim assesses that the element under evaluation implements a secure storage service for cryptographic material, which one can be used by the radio equipment to store confidential cryptographic keys. |
| SCM-1 to SCM-4 | Secure Communication Support and Secure Communication Enforcement: those SESIP security claims assess the implementation of a secure communication mechanism, including authenticity, integrity, confidentiality and/or replay protections depending on the related transiting assets protection needed. |
| LGM-1 to LGM-4 | Audit Log Generation and Storage: this SESIP security claim assesses the implementation of audit log generation and secure storage by the equipment element under evaluation, which can then be integrated into the final equipment logging mechanism.Explicit refinement can require the handling of minimum numbers of events and time-related information. |
| DLM-1 | Factory Reset of Platform, Decommissioning of Platform and/or Field Return: those SESIP security claims assess that user data is securely erased before some life cycle change which could involve ownership reset or change.Residual Information Purging: this SESIP security claim assesses the implementation of a secure erasing mechanism or user data handled by the equipment element which can be triggered upon need by the equipment upper layers.Secure Uninstall of Application: this SESIP security claim assesses the implementation of secure uninstallation of applications such that all application data is destroyed |
| UNM-1 to UNM-2 | Not applicable |
| CCK-1 to CCK-3 | Cryptographic key generation: this SESIP security claim assesses the implementation of cryptographic key generation which can be used by the radio equipment to address CCK-2.All SESIP security services claim involving cryptographic keys (cryptographic services, secure initialization, secure update, secure communication, secure storage, etc.) are assessed to verify that those keys are securely handled and adhere to best practice cryptography.Explicit refinement of such security services claim can require that no static defaults values are used for confidential cryptographic keys. |
| GEC-1 to GEC-7 | AVA_VAN.SESIP: this SESIP security evaluation activity requires the vulnerability analysis of the claimed security services implementation, during which:- it is verified that the implementation under evaluation does not include publicly known exploitable vulnerabilities and that only needed interfaces are exposed for each life-cycle state.- it is checked that necessary input validation is performed.Secure development: This SESIP security claim assesses that the element under evaluation has been developed following secure development rules, which could include the verification of the exposed attack surfaces. Note that the Radio Equipment Directive only covers product-specific requirements and not process requirements, hence making this activity a complementary action.AGD_OPE/PRE: these SESIP security evaluation activities require the documentation of security services exposed to the users. |
| CRY-1 | All SESIP security services claim assessment involving cryptographic keys (cryptographic services, secure initialization, secure update, secure communication, secure storage, etc.) verify that those keys are securely handled and adhere to best practice cryptography. |
# Annex ZA (informative)
# Relationship between this European Standard and the Delegated Regulation (EU) 2022/30 supplementing Directive 2014/53/EU of the European Parliament and of the Council with regard to the application of the essential requirements referred to in Article 3(3), points (d) (e) and (f), of that Directive aimed to be covered
This European Standard has been prepared under a Commission’s standardization request C(2022) 5637 and its amendment C(2023) 5624 final to provide one voluntary means of conforming to essential requirements of Directive 2014/53/EU [OJ L 153] of the European Parliament and of the Council with regard to the application of the essential requirements referred to in Article 3(3).
In case of differences between terms defined in this European standard and terms defined in that Regulation, the terms defined in the Regulation shall prevail.
Once this standard is cited in the Official Journal of the European Union under that Delegated Regulation (EU) 2022/30, compliance with the normative clauses of this standard given in Table ZA.1 confers, within the limits of the scope of this standard, a presumption of conformity with the corresponding essential requirements of Directive 2014/53/EU and associated EFTA regulations.
Table ZA.1 — Correspondence between this European Standard and Directive 2014/53/EU [OJ L 153]