SIST EN 18031-1:2024
(Main)Common security requirements for radio equipment - Part 1: Internet connected radio equipment
Common security requirements for radio equipment - Part 1: Internet connected radio equipment
This document specifies common security requirements for internet-connected radio equipment. This document provides technical specifications for radio equipment, 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.
Gemeinsame Sicherheitsanforderungen für mit dem Internet verbundene Funkanlagen
Dieses Dokument legt gemeinsame Sicherheitsanforderungen und zugehörige Beurteilungskriterien für mit dem Internet verbundene Funkanlagen[34] (im Folgenden als "Anlagen" bezeichnet) fest.
Exigences de sécurité communes applicables aux équipements radioélectriques connectés à linternet
Le présent document spécifie des exigences de sécurité communes applicables aux équipements radioélectriques connectés à l'internet. Le présent document fournit des spécifications techniques pour les équipements radioélectriques, 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.
Splošne varnostne zahteve za radijsko opremo - 1. del: Radijska oprema, povezana z internetom
Ta dokument določa splošne varnostne zahteve in povezana merila ocenjevanja za radijsko opremo, povezano z internetom [34] (v nadaljnjem besedilu »oprema«).
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-oktober-2024
Splošne varnostne zahteve za radijsko opremo - 1. del: Radijska oprema,
povezana z internetom
Common security requirements for radio equipment - Part 1: Internet connected radio
equipment
Gemeinsame Sicherheitsanforderungen für mit dem Internet verbundene Funkanlagen
Exigences de sécurité communes applicables aux équipements radioélectriques
connectés à linternet
Ta slovenski standard je istoveten z: EN 18031-1: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-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
August 2024
ICS 35.030
English version
Common security requirements for radio equipment -
Part 1: Internet connected radio equipment
Exigences de sécurité communes applicables aux Gemeinsame Sicherheitsanforderungen für
équipements radioélectriques - Partie 1 : Équipements Funkanlagen - Teil 1: Funkanlagen mit
radioélectriques connectés à l'internet Internetanschluss
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.
CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2024 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 18031-1:2024 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Abbreviations . 11
5 Application of this document. 12
6 Requirements . 15
6.1 [ACM] Access control mechanism . 15
6.1.1 [ACM-1] Applicability of access control mechanisms . 15
6.1.2 [ACM-2] Appropriate access control mechanisms . 20
6.2 [AUM] Authentication mechanism . 25
6.2.1 [AUM-1] Applicability of authentication mechanisms . 25
6.2.2 [AUM-2] Appropriate authentication mechanisms . 34
6.2.3 [AUM-3] Authenticator validation . 37
6.2.4 [AUM-4] Changing authenticators. 41
6.2.5 [AUM-5] Password strength . 44
6.2.6 [AUM-6] Brute force protection . 52
6.3 [SUM] Secure update mechanism . 56
6.3.1 [SUM-1] Applicability of update mechanisms. 56
6.3.2 [SUM-2] Secure updates . 59
6.3.3 [SUM-3] Automated updates . 64
6.4 [SSM] Secure storage mechanism . 68
6.4.1 [SSM-1] Applicability of secure storage mechanisms . 68
6.4.2 [SSM-2] Appropriate integrity protection for secure storage mechanisms . 72
6.4.3 [SSM-3] Appropriate confidentiality protection for secure storage mechanisms . 77
6.5 [SCM] Secure communication mechanism . 82
6.5.1 [SCM-1] Applicability of secure communication mechanisms . 82
6.5.2 [SCM-2] Appropriate integrity and authenticity protection for secure communication
mechanisms . 88
6.5.3 [SCM-3] Appropriate confidentiality protection for secure communication
mechanisms . 94
6.5.4 [SCM-4] Appropriate replay protection for secure communication mechanisms . 99
6.6 [RLM] Resilience mechanism. 105
6.6.1 [RLM-1] Applicability and appropriateness of resilience mechanisms . 105
6.7 [NMM] Network monitoring mechanism . 109
6.7.1 [NMM-1] Applicability and appropriateness of network monitoring mechanisms . 109
6.8 [TCM] Traffic control mechanism . 113
6.8.1 [TCM-1] Applicability of and appropriate traffic control mechanisms . 113
6.9 [CCK] Confidential cryptographic keys . 117
6.9.1 [CCK-1] Appropriate CCKs . 117
6.9.2 [CCK-2] CCK generation mechanisms . 121
6.9.3 [CCK-3] Preventing static default values for preinstalled CCKs . 125
6.10 [GEC] General equipment capabilities . 129
6.10.1 [GEC-1] Up-to-date software and hardware with no publicly known exploitable
vulnerabilities . 129
6.10.2 [GEC-2] Limit exposure of services via related network interfaces . 134
6.10.3 [GEC-3] Configuration of optional services and the related exposed network
interfaces . 138
6.10.4 [GEC-4] Documentation of exposed network interfaces and exposed services via
network interfaces . 141
6.10.5 [GEC-5] No unnecessary external interfaces . 144
6.10.6 [GEC-6] Input validation . 147
6.11 [CRY] Cryptography . 152
6.11.1 [CRY-1] Best practice cryptography . 152
Annex A (informative) Rationale . 157
A.1 General . 157
A.2 Rationale . 157
A.2.1 Family of standards . 157
A.2.2 Security by design . 157
A.2.3 Threat modelling and security risk assessment . 158
A.2.4 Functional sufficiency assessment . 159
A.2.5 Implementation categories . 159
A.2.6 Assets . 160
A.2.7 Mechanisms . 161
A.2.8 Assessment criteria . 162
A.2.9 Interfaces . 165
Annex B (informative) Mapping with EN IEC 62443-4-2: 2019 . 168
B.1 General . 168
B.2 Mapping . 168
Annex C (informative) Mapping with ETSI EN 303 645 (Cyber Security for Consumer Internet
of Things: Baseline Requirements) . 171
C.1 General . 171
C.2 Mapping . 171
Annex D (informative) Mapping with Security Evaluation Standard for IoT Platforms (SESIP)
................................................................................................................................................................ 175
D.1 General . 175
D.2 Mapping . 175
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 . 178
Bibliography . 179
European foreword
This document (EN 18031-1: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 [33] 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 assets and network 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 internet-
connected radio equipment [34] (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 [27]]
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 network function configuration
network function configuration whose disclosure can harm the network or its functioning or can lead to
misuse of network resources
3.11
confidential security parameter
security parameter whose disclosure can harm the network or its functioning or can lead to misuse of
network resources
3.12
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 [28]] modified
3.13
device
product external to the equipment
3.14
entity
user, device, equipment or service
3.15
entropy
measure of the disorder, randomness or variability in a closed system
3.16
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.17
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.18
hard-coded
software development practice of embedding data directly into the source code of a program or other
executable object
3.19
initialization
process that configures the network connectivity of the equipment for operation
Note 1 to entry: Initialization can provide the possibility to configure authentication features for a user or for
network access.
3.20
interface
shared boundary across which entities exchange information
3.21
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; or
— a descriptions of equipment’s operational environment of use; or
— a description of equipment’s technical properties such as security measures; or
— an analysis of relevant risks related to the operation of the equipment within its reasonably foreseeable use
and intended equipment functionality.
3.22
machine interface
external interface between the equipment and a service or device
3.23
network asset
sensitive network function configuration or confidential network function configuration or network
functions
3.24
network equipment
equipment that exchanges data between different networks used to permanently connect directly other
devices to the internet
3.25
network function
equipment’s functionality to provide or utilize network resources by itself
3.26
network function configuration
data processed by the equipment that defines the behaviour of the equipment’s network function
3.27
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.28
operational state
state in which the equipment is functioning normally according to the intended equipment functionality
[35] and within its intended operational environment of use
3.29
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 [35] 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.30
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.31
public security parameter
sensitive security parameter that is not confidential
3.32
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 [29]]
3.33
risk
combination of the probability of occurrence of harm and the severity of that harm
[SOURCE: ISO/IEC Guide 51:2014 [30]]
3.34
resource
functional unit or data item needed to perform required operations
[SOURCE: IEC [31]]
3.35
security asset
sensitive security parameter or confidential security parameter or security function
3.36
security function
functionality on the equipment that is relevant to protect it from harming the network or its functioning
or misusing network resources
3.37
security parameter
data processed by the equipment that defines the behaviour of the equipment‘s security function
3.38
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.39
sensitive network function configuration
network function configuration whose manipulation can harm the network or its functioning or can lead
to misuse of network resources
3.40
sensitive security parameter
security parameter whose manipulation can harm the network or its functioning or can lead to misuse of
network resources
3.41
security update
software update that addresses security vulnerabilities through software patches or other mitigations
3.42
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.43
storage mechanism
equipment functionality that allows to store information
3.44
update mechanism
equipment functionality that allows to change equipment’s software
3.45
user interface
external interface between the equipment and a user
3.46
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")
[32]]
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
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
OS operating system
MitM Man-in-the-Middle
NNM network monitoring mechanism
OS operating system
PIN personal identification number
PKI public key infrastructure
RLM resilience mechanism
SCM secure communication mechanism
SDO standards developing organization
SQL structured query language
SSM secure storage mechanism
SSP sensitive security parameter
SUM secure update mechanism
TCM traffic control 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 this
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
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
6.x.2.3 Guidance mechanism is implemented properly.
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
toy) and if it needs to be implemented,
6.x.y.4.1 Assessment objective
whether it is implemented properly.
6.x.y.4.2 Implementation categories
6.x.y.4.3 Required information
Clause # Title Description on how to apply this
document
NOTE Some chapters contain multiple
6.x.y.4.4 Conceptual assessment
requirements, which leads to slight deviations in
6.x.y.4.5 Functional completeness assessment
terms of numbering.
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
network assets, except for access to security assets or network 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 network 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 network assets that are in principle covered, but where the intended
equipment functionality [35] is to be generally accessible by the public or where the intended operational
environment of use ensures that only authorized access is possible.
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 network 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 assets (for example, the WPS
button on a home router);
— the equipment’s functionality only provides information (on security assets or network
assets) that is intended to be publicly accessible (for instance broadcasting Bluetooth
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 exist, 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.NetworkAsset]: Description of each network asset that is accessible by entities, including:
— [E.Info.ACM-1.NetworkAsset.Access]: possible entities’ accesses to the network asset on the
equipment; and
— (if access control by the equipment is absent for public accessibility of the network asset is
the equipment’s intended functionality) [E.Info.ACM-1.NetworkAsset.PublicAccess]:
Description of the equipment’s intended functionality concerning the public accessibility of
the network 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.NetworkAsset.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.NetworkAsset.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 network
asset) [E.Info.ACM-1.NetworkAsset.ACM]: Description of each access control mechanism that
manages entities’ access to the network asset.
[E.Info.DT.ACM-1]: Description of the selected path through the decision tree in Figure 1 for each security
asset and network asset documented in [E.Info.ACM-1.SecurityAsset] and [E.Info.ACM-1.NetworkAsset]
where paths to access the asset exists, 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.NetworkAsset.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.NetworkAsset.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.NetworkAsset.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.NetworkAsset.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 network asset documented
in [E.Info.ACM-1.NetworkAsset], 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:
— a 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 network assets that
are accessible by entities, are documented in [E.Info.ACM-1.NetworkAsset] 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.NetworkAsset],
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 all security assets found are documented in
[E.Info.ACM-1.SecurityAsset] and all network assets found are documented in [E.Info.ACM-
1.NetworkAsset].
The verdict FAIL for the assessment case is assigned if a security asset is found which is not documented
in [E.Info.ACM-1.SecurityAsset] or a network asset is found which is not documented in [E.Info.ACM-
1.NetworkAsset].
The verdict NOT APPLICABLE for the assessment case is assigned otherwise.
6.1.1.4.6 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...