SIST EN 18031-2:2024
(Main)Common security requirements for radio equipment - Part 2: radio equipment processing data, namely Internet connected radio equipment, childcare radio equipment, toys radio equipment and wearable radio equipment
Common security requirements for radio equipment - Part 2: radio equipment processing data, namely Internet connected radio equipment, childcare radio equipment, toys radio equipment and wearable radio equipment
Common security requirements for radio equipment processing personal data or traffic data or location data being either internet connected radio equipment, radio equipment designed or intended exclusively for childcare; toys and wearable radio equipment. The standard provides technical specifications for radio equipment processing personal data, traffic data or location data, which concerns electrical or electronic products that are capable to communicate over the internet, regardless of whether these products communicate directly or via any other equipment, childcare, toys or wearable radio equipment.
The scope does not apply to 5G network equipment used by providers of public electronic communications networks and publicly available electronic communications services within the meaning of in Directive (EU) 2018/1972 of the European Parliament and of the Council as defined in that Regulation.
Gemeinsame Sicherheitsanforderungen für datenverarbeitende Funkanlagen, namentlich mit dem Internet verbundene Funkanlagen, in der Kinderbetreuung eingesetzte Funkanlagen, in Spielzeug eingesetzte Funkanlagen sowie an einem Teil des menschlichen Körpers oder an Kleidungsstücken getragene Funkanlagen
Exigences de sécurité communes applicables aux équipements radioélectriques - Partie 2 : Équipements radioélectriques qui traitent des données, à savoir les équipements radioélectriques connectés à l’internet, les équipements radioélectriques destinés à la garde d’enfants, les jouets dotés d’équipements radioélectriques et les équipements radioélectriques portables
Exigences de sécurité communes applicables aux équipements radioélectriques qui traitent des données à caractère personnel, des données liées au trafic ou des données de localisation, qu'il s'agisse d'équipements radioélectriques connectés à l'internet, d'équipements radioélectriques conçus ou destinés exclusivement à la garde d'enfants ; aux jouets et aux équipements radioélectriques portables. La norme fournit des spécifications techniques pour les équipements radioélectriques traitant des données à caractère personnel, des données liées au trafic ou des données de localisation, qui portent sur les produits électriques ou électroniques capables de communiquer via l'internet, que ces produits communiquent directement ou par l'intermédiaire d'un autre équipement, équipement radioélectrique destiné à la garde d'enfants, jouet ou équipement radioélectrique portable.
Le domaine d'application ne s'applique pas aux équipements réseau 5G utilisés par les fournisseurs des réseaux publics de communications électroniques et des services de communications électroniques accessibles au public au sens de la Directive (UE) 2018/1972 du Parlement européen et du Conseil, tels qu'ils sont définis dans ce Règlement.
Skupne varnostne zahteve za radijsko opremo - 2. del: Radijska oprema za obdelavo podatkov, in sicer radijska oprema, povezana z internetom, radijska oprema za varstvo otrok, radijska oprema za igrače in nosljiva radijska oprema
Ta dokument določa skupne varnostne zahteve in povezana merila ocenjevanja za radijsko opremo [36] za obdelavo osebnih podatkov [40] ali podatkov o prometu [41] ali podatkov o lokaciji [41], tj. radijsko opremo, povezano
z internetom [37], radijsko opremo, namenjeno ali predvideno izključno za varstvo otrok [37],
radijsko opremo za igrače [39] ter nosljivo radijsko opremo [37] (v nadaljnjem besedilu »oprema«).
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-oktober-2024
Skupne varnostne zahteve za radijsko opremo - 2. del: Radijska oprema za
obdelavo podatkov, in sicer radijska oprema, povezana z internetom, radijska
oprema za varstvo otrok, radijska oprema za igrače in nosljiva radijska oprema
Common security requirements for radio equipment - Part 2: radio equipment processing
data, namely Internet connected radio equipment, childcare radio equipment, toys radio
equipment and wearable radio equipment
Gemeinsame Sicherheitsanforderungen für datenverarbeitende Funkanlagen,
namentlich mit dem Internet verbundene Funkanlagen, in der Kinderbetreuung
eingesetzte Funkanlagen, in Spielzeug eingesetzte Funkanlagen sowie an einem Teil
des menschlichen Körpers oder an Kleidungsstücken getragene Funkanlagen
Exigences de sécurité communes applicables aux équipements radioélectriques - Partie
2 : Équipements radioélectriques qui traitent des données, à savoir les équipements
radioélectriques connectés à l’internet, les équipements radioélectriques destinés à la
garde d’enfants, les jouets dotés d’équipements radioélectriques et les équipements
radioélectriques portables
Ta slovenski standard je istoveten z: EN 18031-2:2024
ICS:
33.060.01 Radijske komunikacije na Radiocommunications in
splošno general
35.030 Informacijska varnost IT Security
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN STANDARD EN 18031-2
NORME EUROPÉENNE
EUROPÄISCHE NORM
August 2024
ICS 33.060.20
English version
Common security requirements for radio equipment - Part
2: radio equipment processing data, namely Internet
connected radio equipment, childcare radio equipment,
toys radio equipment and wearable radio equipment
Exigences de sécurité communes applicables aux Gemeinsame Sicherheitsanforderungen für
équipements radioélectriques - Partie 2 : Équipements datenverarbeitende Funkanlagen, namentlich mit dem
radioélectriques qui traitent des données, à savoir les Internet verbundene Funkanlagen, in der
équipements radioélectriques connectés à l'internet, Kinderbetreuung eingesetzte Funkanlagen, in
les équipements radioélectriques destinés à la garde Spielzeug eingesetzte Funkanlagen sowie an einem Teil
d'enfants, les jouets dotés d'équipements des menschlichen Körpers oder an Kleidungsstücken
radioélectriques et les équipements radioélectriques getragene Funkanlagen
portables
This European Standard was approved by CEN on 1 August 2024.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.
Contents Page
European foreword . 5
Introduction . 6
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 Abbreviations . 12
5 Application of this document. 13
6 Requirements . 16
6.1 [ACM] Access control mechanism . 16
6.1.1 [ACM-1] Applicability of access control mechanisms . 16
6.1.2 [ACM-2] Appropriate access control mechanisms . 21
6.1.3 [ACM-3] Default access control for children in toys . 26
6.1.4 [ACM-4] Default access control to children’s privacy assets for toys and childcare
equipment . 30
6.1.5 [ACM-5] Parental/Guardian access controls for children in toys . 36
6.1.6 [ACM-6] Parental/Guardian access controls for other entities’ access to managed
children’s privacy assets in toys . 40
6.2 [AUM] Authentication mechanism . 45
6.2.1 [AUM-1] Applicability of authentication mechanisms . 45
6.2.2 [AUM-2] Appropriate authentication mechanisms . 55
6.2.3 [AUM-3] Authenticator validation . 61
6.2.4 [AUM-4] Changing authenticators. 65
6.2.5 [AUM-5] Password strength . 68
6.2.6 [AUM-6] Brute force protection . 76
6.3 [SUM] Secure update mechanism . 80
6.3.1 [SUM-1] Applicability of update mechanisms. 80
6.3.2 [SUM-2] Secure updates . 83
6.3.3 [SUM-3] Automated updates . 88
6.4 [SSM] Secure storage mechanism . 91
6.4.1 [SSM-1] Applicability of secure storage mechanisms . 91
6.4.2 [SSM-2] Appropriate integrity protection for secure storage mechanisms . 96
6.4.3 [SSM-3] Appropriate confidentiality protection for secure storage mechanisms . 101
6.5 [SCM] Secure communication mechanism . 106
6.5.1 [SCM-1] Applicability of secure communication mechanisms . 106
6.5.2 [SCM-2] Appropriate integrity and authenticity protection for secure communication
mechanisms . 112
6.5.3 [SCM-3] Appropriate confidentiality protection for secure communication
mechanisms . 118
6.5.4 [SCM-4] Appropriate replay protection for secure communication mechanisms . 123
6.6 [LGM] Logging mechanism . 128
6.6.1 [LGM-1] Applicability of logging mechanisms . 128
6.6.2 [LGM-2] Persistent storage of log data . 131
6.6.3 [LGM-3] Minimum number of persistently stored events . 134
6.6.4 [LGM-4] Time-related information of persistently stored log data . 137
6.7 [DLM] Deletion mechanism. 140
6.7.1 [DLM-1] Applicability of deletion mechanisms . 140
6.8 [UNM] User notification mechanism . 144
6.8.1 [UNM-1] Applicability of user notification mechanisms . 144
6.8.2 [UNM-2] Appropriate user notification content . 148
6.9 [CCK] Confidential cryptographic keys . 150
6.9.1 [CCK-1] Appropriate CCKs . 150
6.9.2 [CCK-2] CCK generation mechanisms . 154
6.9.3 [CCK-3] Preventing static default values for preinstalled CCKs . 159
6.10 [GEC] General equipment capabilities . 163
6.10.1 [GEC-1] Up-to-date software and hardware with no publicly known exploitable
vulnerabilities . 163
6.10.2 [GEC-2] Limit exposure of services via related network interfaces . 168
6.10.3 [GEC-3] Configuration of optional services and the related exposed network
interfaces . 172
6.10.4 [GEC-4] Documentation of exposed network interfaces and exposed services via
network interfaces . 175
6.10.5 [GEC-5] No unnecessary external interfaces . 178
6.10.6 [GEC-6] Input validation . 181
6.10.7 [GEC-7] Documentation of external sensing capabilities . 186
6.11 [CRY] Cryptography . 188
6.11.1 [CRY-1] Best practice cryptography . 188
Annex A (informative) Rationale . 194
A.1 General . 194
A.2 Rationale . 194
A.2.1 Family of standards . 194
A.2.2 Security by design . 194
A.2.3 Threat modelling and security risk assessment . 195
A.2.4 Functional sufficiency assessment . 196
A.2.5 Implementation categories . 196
A.2.6 Assets . 197
A.2.7 Mechanisms . 199
A.2.8 Assessment criteria . 199
A.2.9 Interfaces . 202
Annex B (informative) Mapping with EN IEC 62443-4-2: 2019 . 205
B.1 General . 205
B.2 Mapping . 205
Annex C (informative) Mapping with ETSI EN 303 645 (Cyber Security for Consumer Internet
of Things: Baseline Requirements) . 208
C.1 General . 208
C.2 Mapping . 208
Annex D (informative) Mapping with Security Evaluation Standard for IoT Platforms (SESIP)
................................................................................................................................................................ 214
D.1 General . 214
D.2 Mapping . 214
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 . 217
Bibliography . 218
European foreword
This document (EN 18031-2:2024) has been prepared by Technical Committee CEN/CENELEC JTC 13
“Cybersecurity and Data Protection”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by February 2025, and conflicting national standards shall
be withdrawn at the latest by February 2025.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request addressed to CEN-CENELEC by the
European Commission. The Standing Committee of the EFTA States subsequently approves these
requests for its Member States.
For the relationship with EU Legislation, see informative Annex ZA, which is an integral part of this
document.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
Introduction
Vigilance is required from manufacturers to improve the overall resilience against cybersecurity threats
caused by the increased connectivity of radio equipment [36] and the growing ability of malicious threat
actors to cause harm to users, organizations, and society.
The security requirements presented in this baseline standard are developed to improve the ability of
radio equipment to protect its security and privacy assets against common cybersecurity threats and to
mitigate publicly known exploitable vulnerabilities.
It is important to note that to achieve the overall cybersecurity of radio equipment, defence in depth best
practices will be needed by both the manufacturer and user. In particular, no single measure will suffice
to achieve the given objectives, indeed achieving even a single security objective will usually require a
suite of mechanisms and measures. Throughout this document, the guidance material includes lists of
examples. These examples given are only indicative possibilities, as there are other possibilities that are
not listed, and even using the examples given will not be sufficient unless the mechanisms and measures
chosen are implemented in a coordinated fashion.
1 Scope
This document specifies common security requirements and related assessment criteria for radio
equipment [36] processing personal data [40] or traffic data [41] or location data [41] for either internet
connected radio equipment [37], radio equipment designed or intended exclusively for childcare [37];
toys [39] and wearable radio equipment [37] (hereinafter referred to as "equipment").
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1
access control mechanism
equipment functionality to grant, restrict or deny access to specific equipment’s resources
Note 1 to entry: Access to specific equipment’s resources can amongst others be:
— reading specific data; or
— writing specific data to equipment’s persistent storage; or
— performing a specific equipment functionality such as recording audio.
3.2
authentication
provision of assurance that an entity is who or what it claims to be
Note 1 to entry: An entity can amongst others claim to be:
— 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
— authorized by another entity to access a specific equipment’s resource.
3.3
authentication mechanism
equipment functionality to verify that an entity is who or what it claims to be
Note 1 to entry: Typically, the verification is based on examining evidence from one or more elements of the
categories:
— knowledge; and
— possession; and
— inherence.
3.4
authenticator
something known or possessed, and controlled by an entity that is used for authentication
Note 1 to entry: Typically, it is a physical device or a password.
EXAMPLE A password or token can be used as an authenticator.
3.5
assessment objective
statement, provided as part of the assessment input, which defines the reasons for performing the
assessment
[SOURCE: ISO/IEC 33001:2015, 3.2.6 [29]]
3.6
best practice
measures that have been shown to provide appropriate security for the corresponding use case
3.7
brute force attack
attack on a cryptosystem that employs a trial-and-error search of a set of keys, passwords or other data
3.8
communication mechanism
equipment functionality that allows communication via a machine interface
3.9
confidential cryptographic key
confidential security parameter, excluding passwords, which is used in the operation of a cryptographic
algorithm or cryptographic protocol
3.10
confidential personal information
personal information whose disclosure can compromise the user’s or subscriber’s privacy
3.11
confidential privacy function configuration
privacy function configuration whose disclosure can compromise the user’s or subscriber’s privacy
3.12
confidential security parameter
security parameter whose disclosure can compromise the user’s or subscriber’s privacy
3.13
denial of service
prevention or interruption of authorized access to an equipment resource or the delaying of the
equipment operations and functions
[SOURCE : IEC 62443-1-1 :2019, 3.2.42 [30]] modified
3.14
device
product external to the equipment
3.15
entity
user, device, equipment or service
3.16
entropy
measure of the disorder, randomness or variability in a closed system
3.17
external interface
interface of an equipment that is accessible from outside the equipment
Note 1 to entry: Machine, network, and user interfaces are specific types of external interfaces.
3.18
factory default state
defined state where the configuration settings and configuration of the equipment is set to initial values
Note 1 to entry: A factory default state can include security updates, installed after the equipment being placed on
the market.
3.19
hard-coded
software development practice of embedding data directly into the source code of a program or other
executable object
3.20
initialization
process that configures the network connectivity of the equipment for operation
Note 1 to entry: Initialization may provide the possibility to configure authentication features for a user or for
network access.
3.21
interface
shared boundary across which entities exchange information
3.22
justification
documented information providing evidence that a claim is true under the assumption of common
expertise
Note 1 to entry: Such evidence can be supported for example by:
— a description of the intended equipment functionality,
— a descriptions of equipment’s operational environment of use,
— a description of equipment’s technical properties such as security measures
— an analysis of relevant risks related to the operation of the equipment within its reasonably foreseeable
use and intended equipment functionality.
3.23
log data
record(s) of certain events (of processes) on a computing equipment
3.24
logging mechanism
equipment functionality to log internal activities
3.25
machine interface
external interface between the equipment and a service or device
3.26
network interface
external interface enabling the equipment to have or provide access to a network
Note 1 to entry: Examples for network interfaces are a LAN port (wired) or a wireless network interface enabling
WLAN or short- range wireless communication, e.g., using a 2.4 GHz antenna.
3.27
operational state
state in which the equipment is functioning normally according to the intended equipment functionality
[38] and within its intended operational environment of use
3.28
optional service
service which is not necessary to setup the equipment, and which is not part of the basic functionality but
is still relevant for the intended equipment functionality [38] and is delivered as part of the factory
default.
EXAMPLE An SSH service on the equipment is not required for basic functionality of the equipment, but it can
be used to allow a remote access to the equipment.
3.29
password
sequence of characters (letters, numbers, or other symbols) used to authenticate an entity
Note 1 to entry: Personal identification numbers (PINs) are also considered a form of password.
3.30
personal information
personal data [40], traffic data [41] or location data [41]
3.31
personal information of special categories
personal information that is genetic data, biometric data for the purpose of uniquely identifying a natural
person, data concerning health or data concerning a natural person's sex life or sexual orientation or that
reveals racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union
membership
[SOURCE: based on Article 9(1) of Regulation (EU) 2016/679 of the European parliament and of the
council of 27 April 2016 on the protection of natural persons with regard to the processing of personal
data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection
Regulation) [31]]
3.32
privacy asset
sensitive personal information or confidential personal information or sensitive privacy function
configuration or confidential privacy function configuration or privacy functions
3.33
privacy function
equipment’s functionality that processes personal information
3.34
privacy function configuration
data processed by the equipment that defines the behaviour of the equipment’s privacy functions
3.35
public security parameter
sensitive security parameter that is not confidential
3.36
resilient
able to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or
compromises on systems that use or are enabled by cyber resources.
[SOURCE: NIST SP 800-172 [32]]
3.37
resource
functional unit or data item needed to perform required operations
[SOURCE: IEC [33]]
3.38
risk
combination of the probability of occurrence of harm and the severity of that harm
[SOURCE: ISO/IEC Guide 51:2014 [34]]
3.39
security asset
sensitive security parameter or confidential security parameter or security function
3.40
security function
measure on the equipment that ensures that the personal data and the privacy of the user and of the
subscriber are protected
3.41
security parameter
data processed by the equipment that defines the behaviour of the equipment‘s security function
3.42
security strength
number associated with the amount of work that is required to break a cryptographic algorithm or
system
Note 1 to entry: The amount of work can for example be the number of operations required to break a
cryptographic algorithm or system.
3.43
sensitive personal information
personal information whose manipulation can compromise the user’s or subscriber’s privacy
3.44
sensitive privacy function configuration
privacy function configuration whose manipulation can compromise the user’s or subscriber’s privacy
3.45
sensitive security parameter
security parameter whose manipulation can compromise the user’s or subscriber’s privacy
3.46
security update
software update that addresses security vulnerabilities through software patches or other mitigations
3.47
software
assembly of programs, procedures, rules, documentation, and data, pertaining to the operation of an
equipment
Note 1 to entry: Software also includes firmware.
3.48
storage mechanism
equipment functionality that allows to store information
3.49
update mechanism
equipment functionality that allows to change equipment’s software
3.50
user interface
external interface between the equipment and a user
3.51
vulnerability
weakness, design, or implementation error that can lead to an unexpected, undesirable event
compromising the security of the equipment, network, application, or protocol involved
[SOURCE: (ITSEC) (definition given by ENISA, "computer system" has been replaced by "equipment")
[35]]
4 Abbreviations
ACM access control mechanism
API application programming interface
AU assessment unit
AUM authentication mechanism
CCK confidential cryptographic key(s)
CRY cryptography
CSP confidential security parameter
CWE common weakness enumeration
DHCP dynamic host configuration protocol
DLM deletion mechanism
DN decision node
DoS denial of service
DT decision tree
E evidence
E.Info evidence.information
E.Just evidence.justification
GEC general equipment capabilities
IC implementation category
ICMP Internet control message protocol
IP Internet protocol
LAN local area network
LGM logging mechanism
MitM Man-in-the-Middle
OS operating system
OTP one-time password
PIN personal identification number
PKI public key infrastructure
PSP public security parameter
SCM secure communication mechanism
SDO standards developing organization
SQL structured query language
SSM secure storage mechanism
SSP sensitive security parameter
SUM secure update mechanism
UNM user notification mechanism
USB universal serial bus
WLAN wireless local area network
5 Application of this document
This document uses the concept of mechanisms to instruct the user of this document when to apply
certain security measures. Mechanisms address the applicability and appropriateness through a set of
requirements including assessment criteria. An applicable/non-applicable decision is taken for each of
the items specified. If applicable it is followed by a pass/fail appropriateness decision for each of the items
specified. For example, when checking the applicability of a requirement on external interfaces, then the
decision whether the requirement needs to be fulfilled is determined for each external interface
independently.
The mechanisms and their application are documented using the structure shown in the table below:
Table 1 — Requirements structure
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.
6.x.1.2 Rationale
NOTE A mechanism might combine
6.x.1.3 Guidance
applicability and appropriateness in a single
requirement.
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
Clause # Title Description on how to apply the document
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
6.x.2.2 Rationale
XXX-1, determine and assess whether the
mechanism is implemented properly.
6.x.2.3 Guidance
NOTE A mechanism might have multiple
6.x.2.4 Assessment criteria
appropriateness sub-clauses to focus on specific
6.x.2.4.1 Assessment objective properties.
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
6.x.y.2 Rationale
XXX-1, determine and assess if the
6.x.y.3 Guidance supporting requirement needs to be
implemented (there might be specific
6.x.y.4 Assessment criteria
conditions, for instance if the equipment is a
6.x.y.4.1 Assessment objective toy) and if it needs to be implemented,
whether it is implemented properly.
6.x.y.4.2 Implementation categories
NOTE Some chapters contain multiple
6.x.y.4.3 Required information
requirements, which leads to slight deviations in
terms of numbering.
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..>.
Identifier for the category of the required information excluding DTs
— Required information for decision trees
E..DT.>
Identifier for the category of the required information in the context of DTs
— Implementation Category
IC.>.
Identifier for the implementation category
— Assessment Unit
AU.>.
Identifier for the assessment unit
— Decision Tree Nodes
DT.>.DN-
Identifier for a specific node inside the DT
The placeholders are used as follows:
— : “Info” or “Just” to indicate the kind of required documentation which could by
information” or justification.
— : Name of the category for the required documentation. A
could contain additional Sub-Category-Names divided with "." .
— : Name of the implementation category which describes the
defined implementation.
— : Name of the assessment unit for a specific implementation category.
— >: 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
— physical or logical measures in the equipment’s targeted operational environment limit their
accessibility to authorized entities; or
— legal implications do not allow for access control mechanisms.
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:
— [E.Info.ACM-1.SecurityAsset.Access]: 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 exists, 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:
— [E.Info.ACM-1.PrivacyAsset.Access]: 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 exists, 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 f
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...