ENISA - 5G Standards

5G
CYBERSECURITY
STANDARDS
Analysis of standardisation requirements in support of
cybersecurity policy
MARCH 2022
0
5G CYBERSECURITY STANDARDS
March 2022
ABOUT ENISA
The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to
achieving a high common level of cybersecurity across Europe. Established in 2004 and
strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity
contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and
processes with cybersecurity certification schemes, cooperates with Member States and EU
bodies, and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge
sharing, capacity building and awareness raising, the Agency works together with its key
stakeholders to strengthen trust in the connected economy, to boost resilience of the Union’s
infrastructure and, ultimately, to keep Europe’s society and citizens digitally secure. More
information about ENISA and its work can be found here: www.enisa.europa.eu.
CONTACT
For contacting the authors please use erika.magonara@enisa.europa.eu
For media enquiries about this paper, please use press@enisa.europa.eu.
AUTHORS
François Cosquer, François Zamora, Alf Zugenmaier
EDITORS
Erika Magonara, Sławomir Górniak – ENISA
ACKNOWLEDGEMENTS
ENISA would like to thank Ms. Elżbieta Andrukiewicz and Mr. Jordi Batalla for their support to
the study, reviews and comments.
LEGAL NOTICE
This publication represents the views and interpretations of ENISA, unless stated otherwise. It
does not endorse a regulatory obligation of ENISA or of ENISA bodies pursuant to the
Regulation (EU) No 2019/881.
ENISA has the right to alter, update or remove the publication or any of its contents. It is
intended for information purposes only and it must be accessible free of charge. All references
to it or its use as a whole or partially must contain ENISA as its source.
Third-party sources are quoted as appropriate. ENISA is not responsible or liable for the content
of the external sources including external websites referenced in this publication.
Neither ENISA nor any person acting on its behalf is responsible for the use that might be made
of the information contained in this publication.
ENISA maintains its intellectual property rights in relation to this publication.
1
March 2022
COPYRIGHT NOTICE
© European Union Agency for Cybersecurity (ENISA), 2022
This publication is licenced under CC-BY 4.0 “Unless otherwise noted, the reuse of this
document is authorised under the Creative Commons Attribution 4.0 International (CC BY 4.0)
licence (https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed,
provided that appropriate credit is given and any changes are indicated”.
For any use or reproduction of photos or other material that is not under the ENISA copyright,
permission must be sought directly from the copyright holders.
ISBN 978-92-9204-568-5 DOI 10.2824/700472
2
March 2022
TABLE OF CONTENTS
EXECUTIVE SUMMARY 6
1. INTRODUCTION 8
1.1 DOCUMENT PURPOSE AND OBJECTIVES 8
1.2 OVERVIEW AND STRUCTURE OF THE STUDY 8
1.3 TARGET AUDIENCE AND PREREQUISITES 9
2. SCOPE, DEFINITIONS, AND CONVENTIONS 10
2.1 THE 5G ECOSYSTEM 10
2.1.1 5G technological and functional domains 10

2.1.2 Technology lifecycle processes 12
2.1.3 5G Stakeholders 13
2.1.4 5G Security domains, objectives and measures 15
2.2 TAXONOMY OF DOCUMENTS CONSIDERED 16
3. POSITIONING AND ASSESSMENT OF REFERENCE DOCUMENTS
IN THE 5G ECOSYSTEM 18
3.1 METHODOLOGY FOR THE ASSESSMENT OF COVERAGE 18
3.2 CONSOLIDATED RESULTS 18
4. IDENTIFICATION OF GAPS IN STANDARDISATION 21
4.1 METHODOLOGY FOR THE IDENTIFICATION OF GAPS IN THE EXISTING LITERATURE 21
4.2 ASSESSMENT OF COVERAGE AND IDENTIFICATION OF GAPS IN STANDARDISATION 21
4.3 OVERVIEW OF GAPS BY SECURITY DOMAIN 27
4.4 OBSERVATIONS ON THE GAPS IN STANDARDISATION 29
4.5 ADDITIONAL LEARNINGS AND OBSERVATIONS 29
5. RECOMMENDATIONS 31
5.1 ADOPT A PROGRESSIVE APPROACH TO 5G STANDARDISATION 31
5.2 HAVE A BROADER VIEW ON THE CREATION OF NEW REFERENCES 31
3
March 2022
5.3 FOSTER THE MATURITY AND THE COMPLETENESS OF THE IDENTIFICATION AND ASSESSMENT OF RISK 31
5.3.1 ENISA’s methodology for sectoral cybersecurity assessment 32
5.4 FINAL OBSERVATIONS 32
6. BIBLIOGRAPHY 33
A.1 DOCUMENT TYPOLOGIES DEFINED BY THE EU REGULATION 37
A.2 DOCUMENT TYPOLOGIES DEFINED BY ISO 37
A.3 REFERENCING THE 5G TECHNICAL AND FUNCTIONAL DOMAINS 39
A.4 REFERENCING THE STAKEHOLDERS 39
A.5 REFERENCING THE EXISTING LITERATURE 42
A.6 DETAILED MAPPING 50
D1 - GOVERNANCE AND RISK MANAGEMENT 51
SO 1 - Information security policy 51

SO 2 - Governance and risk management 52
SO 3 - Security roles and responsibilities 53
SO 4 - Security of third-party dependencies 53
D2 - HUMAN RESOURCES SECURITY 55
SO 5 - Background checks 55
SO 6 - Security knowledge and training 56
SO 7 - Personnel changes 57
SO 8 - Handling violations 57
D3 - SECURITY OF SYSTEMS AND FACILITIES 58
SO 9 - Physical and environmental security 58

SO 10 - Security of supplies 60
SO 11 – Access control to network and information systems 61
SO 12 - Integrity of network and information systems 63
SO 13 - Use of encryption 64
SO14 - Protection of security critical data 65
D4 - OPERATIONS MANAGEMENT 66
SO 15 - Operational procedures 66
SO 16 - Change management 66
SO 17 - Asset management 68
D5 INCIDENT MANAGEMENT 69
SO 18 - Incident management procedures 69

SO 19 - Incident detection capability 70
SO 20 - Incident reporting and communication 71
D6 - BUSINESS CONTINUITY MANAGEMENT 72
SO 21 - Service continuity strategy and contingency plans 72
4
March 2022
SO 22 - Disaster recovery capabilities 73
D7 - MONITORING, AUDITING AND TESTING 74
SO 23 - Monitoring and logging policies 74

SO 24 - Exercise contingency plans 75
SO 25 - Network and information systems testing 76
SO 26 - Security assessments 77
SO 27 - Compliance monitoring 78
D8 - THREAT AWARENESS 79
SO 28 - Threat intelligence 79
SO 29 - Informing users about threats 80
5
March 2022
EXECUTIVE SUMMARY
The ambition of this report is to outline the contribution of standardisation to the mitigation of
technical risks, and therefore to trust and resilience, in the 5G ecosystem. The 5G ecosystem
considered in this report is a multi-dimensional space encompassing not only technological and
functional domains, but also the related technology lifecycle processes and stakeholders.
This report focuses on standardisation from a technical and organisational perspective.

Considerations of the effectiveness of specific standards and of the strategic aspects related to
5G security, although important, are outside the scope of this report.
Accordingly, this report:
• Collects standards, specifications and guidelines 1 relevant to the cybersecurity of the 5G

ecosystem that had been published, either as drafts or in their final versions, by September
2021;
• Positions them within the defined 5G ecosystem by assessing the extent to which they
address security objectives;
• Identifies gaps in standardisation by comparing the existing literature against an ideal
situation of cybersecurity robustness and resilience, where standardisation addresses the
necessary technical and organisational security aspects;
• Formulates recommendations on standardisation in the area of 5G cybersecurity.
The report collects and analyses more than 140 documents and positions them across 150
security measures. The main observations that can be derived from the analysis are the
following.
• All in all, available standards, specifications and guidelines are general. They can be applied
consistently to the 5G technical and functional domains and related lifecycle processes only
after being tailored accordingly.
• 5G-specific standards, specifications and guidelines are available to a greater extent to the
stakeholders of the telecommunication sector than for other stakeholders (e.g. audit
organisations and stakeholders in the connected devices industry).
• 5G-specific standards, specifications and guidelines cover to a greater extent the ‘run’ phase
of a technology lifecycle, whereas other phases would need tailoring.
• Existing knowledge bases on cybersecurity threats and IT-security guidelines can be used for
5G cloud native architectures and architectures relying on APIs (Application Programming
Interface). Although these families of software are well known to the IT industry, their use is
quite recent and constitute drivers of the ‘cloudification’ of the telecom sector.
• The existing literature does not allow for ‘end-to-end’ trust and resilience in the 5G ecosystem.
For example, guidelines for 5G-specific tools and key performance indicators could be needed
to ensure a common understanding of 5G protection and of end-to-end trust and resilience.
Concerning gaps in standardisation, the report finds that only the areas of governance and risk
management as well as the security of human resources present moderate gaps e.g. related to
sector-specific risk management. The other areas considered (e.g. operations management,
1
Section 2.2 explains the taxonomy used by the document. For convenience the report refers to all considered documents
alternatively as ’standards, specifications, guidelines’, ‘existing literature’, ‘reference documents’.
6
March 2022
business continuity management and incident management) present major gaps in

standardisation.
Still, this report recommends the adoption of a progressive approach to 5G standardisation,

which should consider several elements such as the usefulness and necessity of new standards
and their link with strategic objectives. It also notes the importance of fostering the maturity and
the completeness of the identification and assessment of risk by harmonising risk assessment
practices in a way that is inclusive of all stakeholders in the 5G ecosystem.
Finally, this report stresses that, while the technical and organisational standards analysed can
contribute to the security of 5G, they should not be treated as an exhaustive list of measures
guaranteeing security. There are risks that are not covered by standards, for example residual
risks whose cost is neither borne by nor attributable to a specific stakeholder, such as societal
risks resulting from network malfunctions. Indeed, the complexity of 5G calls for a
comprehensive vision of trust and of resilience that goes beyond standardisation. This vision
should be future-proof and not dependent on the variability of assets and configurations in the
network.
7
March 2022
1. INTRODUCTION
1.1 DOCUMENT PURPOSE AND OBJECTIVES

The ambition of this document is to outline the contribution of standardisation to the mitigation of
technical risks, and therefore to trust and resilience, in the 5G ecosystem. Accordingly, the
objectives of the document are:
• to provide an overview of standards, specifications and guidelines 2 relevant to the

cybersecurity of the 5G ecosystem and that had been published, either as drafts or in their
final versions, by September 2021;
• to facilitate the positioning and to assess the applicability of any reference document in the 5G
security environment;
• to formulate recommendations on standardisation in the area of 5G security.
The document focuses on standardisation from a technical and organisational perspective.

Considerations of the effectiveness of specific standards and of the strategic and policy aspects
related to 5G security, although important, are outside the scope of this report.
Note on the relation to other on-going work on 5G cybersecurity carried out by ENISA: this
report is not intended to pre-conceive any work related to the drafting of the European
cybersecurity certification candidate scheme on 5G networks.
1.2 OVERVIEW AND STRUCTURE OF THE STUDY

Businesses and institutions participate in several activities concerning 5G networks and 5G-
dependent processes: their design, construction, operation, introduction to the market, use,
audit and even certification. Altogether, with various degrees of importance, they contribute to
the Digital Single Market.
The EU Cybersecurity Strategy 3, published in 2020, reinstates the importance of trust and
resilience in the Union, to be sustained in the long run for societal purposes and at a systemic
scale. Therefore, cybersecurity risks and the capabilities for their mitigation need to be
considered also from a systemic perspective. To this end, the analysis proposed in the report is
based on a ‘5G Ecosystem’ defined as a multi-dimensional space comprising not only 5G
technological and functional domains but also the related technology lifecycle processes and
stakeholders. The conceived ecosystem is also underpinned by a security dimension. The
ecosystem and its components are described in detail in Section 2 Scope, Definitions and
Conventions.
After having defined the ‘5G Ecosystem’, the document:
• collects existing cybersecurity standards, specifications and guidelines, and positions them
within the defined 5G ecosystem (Section 3 Positioning and Assessment of Reference
Documents in the 5G Ecosystem);
• identifies gaps in standardisation by comparing the existing literature against an ideal
situation of cybersecurity robustness and resilience, where standardisation addresses the
necessary technical and organisational security aspects; and (Section 4 Identification of Gaps
in Standardisation).
2
Section 2.2 explains the taxonomy used by the document. For convenience the report refers to the documents analysed
as, alternatively, ‘reference documents’, ‘references’, ‘existing literature’ or ‘standards, specifications, guidelines’.
3
https://ec.europa.eu/commission/presscorner/detail/en/IP_20_2391
8
March 2022
• formulates recommendations on standardisation in the area of 5G cybersecurity (Section 5

Recommendations).
1.3 TARGET AUDIENCE AND PREREQUISITES

This work is intended for the stakeholders in the 5G ecosystem, in particular standardisation
working groups, industry stakeholders and national cybersecurity agencies across the European
Union.
The reader is invited to get familiar with the concepts of information security risk management
as documented in the ISO/IEC 27005 international standard, as well as the concepts developed
in the following documents:
• ENISA, Guideline on Security Measures under the EECC, 2020,

• ENISA, 5G Supplement to the Guideline on Security Measures under EECC, 2021,
• ENISA, Threat Landscape for 5G Networks, 2019,
• ENISA, Security in 5G Specifications, 2021,
• ENISA, EU Coordinated Risk Assessment of 5G Networks Security, 2019,
• ENISA, Methodology for Sectoral Cybersecurity Assessments, 2021.
An overview of the standardisation organisations active in 5G is contained in ENISA report

‘Security in 5G specifications’ 4.
4
https://www.enisa.europa.eu/publications/security-in-5g-specifications
9
March 2022
2. SCOPE, DEFINITIONS, AND

CONVENTIONS
This section provides the concepts and definitions used to build the ‘5G Ecosystem’ introduced
in Section 1.2 Overview and Structure of the Study. This ecosystem provides a methodological
framework in which it is possible to locate the standards, the specifications and the guidelines
relevant for a given stakeholder group, at a given step of the technology lifecycle, for a given
block of the 5G technical architecture.
2.1 THE 5G ECOSYSTEM

As introduced in section 1.2 Overview and Structure of the Study, the 5G ecosystem is
composed of the following dimensions.
Figure 1: The dimensions of the 5G ecosystem
Building blocks of the 5G Ecosystem Definitions
Essential functions of 5G networks and the related supporting

asset categories, representing 5G technical components and
5G Technological and functional domains
the scope of their interactions.
Processes applied to the lifecycle of 5G services and of 5G-

dependent vertical industrial processes.
Technology lifecycle processes
Entities (either public or private) that are related to 5G

networks and vertical industries.
5G Stakeholders
Security dimension of the 5G ecosystem, represented through

the security domains, objectives and measures of the ENISA
5G Security domains, objectives and measures
Guideline on Security Measures under the EECC and its 5G
supplement.
2.1.1 5G technological and functional domains

The current section outlines the essential functions of 5G networks and the related categories of
supporting assets considered in this report.
The 5G technological and functional domains considered are largely based on the set of planes,
functional blocks and process blocks of the widely acknowledged representation of the generic
5G architecture depicted in the ENISA report ENISA Threat Landscape for 5G Networks
Updated 2020, which in turn relies on the architecture of the 3GPP Technical Specification
23.502 (Release 16). They have been selected because they offer a synthetic overview of 5G
technology and 5G-related processes. For the purpose of this study, only the major blocks
depicted in Figure 2 have been considered.
10
March 2022
Figure 2: The 5G technological and functional domains as represented in ENISA Threat

Landscape for 5G Networks Updated 2020
Figure 3: The 5G technological and functional domains considered by the current study
G Technical and functional domains Definition
5G Use Cases End-to-end services based on 5G, characterised by how they

use and/or transmit data. Example: ‘Vehicle-to-everything’,
eMBB, mMTC, URLLC.
Multi Access Edge Computing (MEC) Services Multi-access computing services used to bring computation
and connectivity closer to the end-user in order to meet the
requirements for data transmission speed and latency.
Physical infrastructure Set of premises including hardware and software for

computation, storage, transmission, as well as the related
technical environment (energy, air conditioning, cable paths,
civil works infrastructures, etc.).
Virtualised Infrastructure Computing, storage and networking capacities on demand.
Radio Access Network (RAN) Logical and hardware components making up the functions of
the radio access network. It includes mainly distribution units
and control units for radio access.
Multi Access Edge Computing (MEC) Infrastructure Infrastructure related to the decentralisation of cloud functions
(storage of data and computing) located closer to the user or
edge device.
5G Core Network, Network Function (CN NF) Central part of the 5G infrastructure which enables new
functions related to multi-access technologies. Its main
11
March 2022
purpose is to deliver services over all kinds of networks

(wireless, fixed, converged).
Data Network (DN) Connectivity to external data, content, services and other
resources available outside the 5G network. The data network
is also used to interconnect different 5G networks, operators
and providers.
Transport Part of the network ensuring the connectivity between the

access and core networks.
Management and Orchestration (MANO) Software, operations tools and the related environment used to
automate operations that relate to the lifecycle of the
infrastructure and service components.
2.1.2 Technology lifecycle processes

Lifecycle processes can be regarded as the heartbeat of all activities based on digital
technologies. This section defines the scope of the technology lifecycle processes considered in
the 5G ecosystem. They are the processes related to the lifecycle of 5G services and of 5G-
dependent vertical industries. To keep the analysis simple, the methodology selects some of the
processes listed in GSMA, GSMA FS.16 - NESAS Development and Lifecycle Security
Requirements v2.0, 2021.
Such processes are considered in a technology environment including (but not limited to):
• 5G technologies given their underlying technological bricks from cloud-native and service-
based architectures,
• their orchestration and their automation,
• their components running on top of virtualised infrastructures requiring orchestration and
automation.
The considered processes encompass the phases shown in Figure 4 below.
Figure 4: The phases of the technology lifecycle processes considered in the 5G ecosystem
Phase Definition
Think All activities related to the design of a service, the design

principles of an infrastructure, as well as the study of their
technological and operational options. The main deliverables of
this phase are (for example) anticipation studies, benchmarks,
opportunity studies, high-level designs and initial risk
assessments.
Build All activities that prepare and execute the building phase of a
service, including the integration of the software parts,
connectivity, application interfaces, data flows and related
protocols. When security is integrated within the ‘Build’
process, the corresponding milestones consist in checking the
robustness of the architecture, its attack surface and updating
the risks accordingly.
Test All activities that verify the compliance with specifications,

robustness or resilience prior or after the ‘go-live’ phase, also
including auditing at any phase of the lifecycle.
Run All activities including the continuous delivery of services,

performance and fault management, problem management,
customer support, etc.
Update Activities that relate to the process also referred to as

‘Transition’, consisting in identifying capacity needs,
requirements for software updates, patch installation, needs for
robustness, adjustments to software and equipment
12
March 2022
configurations, and the on-demand provisioning capabilities

when a customer purchases a service.
End of Life The sequence of steps towards decommissioning or the end of

the lifecycle of a service component.
In this context, it is to be noted that the lifecycle processes apply to a variety of areas and
stakeholders beyond 5G products alone. These lifecycle processes are applicable to systems
other than 5G products, such as IT systems used to operate, test, orchestrate, automate, and
develop service bricks.
The figure below is an example showing where security steps can be implemented in the
lifecycle processes to enable robustness and resilience from an end-to-end perspective.
Figure 5: Representation of the lifecycle processes considered in the 5G ecosystem
2.1.3 5G Stakeholders
The 5G ecosystem relies on several stakeholders that play different roles in its security at
different levels. The set of stakeholders selected for this document focuses on entities (either
public or private) that are related to 5G networks and vertical industries.
The set has been adapted from the EU Coordinated Risk Assessment on 5G Networks Security
and the ENISA Threat Landscape for 5G Networks Updated (2020), as they encompass both
the stakeholders and their role with regards to 5G. They are depicted in the following table.
Figure 5: The categories of the 5G stakeholders considered in the 5G ecosystem
Stakeholder category Definition
Entities that use services that are offered by a service provider

(SP): in the context of 5G, these would be, for example, vertical
industries and their private networks. In addition, consumers of
5G services without a business-relation with a 5G service
5G Service customer or consumer provider (for example, end users) are included in this category.
This category may implement standards, specifications
and guidelines to achieve the security objectives for the
safe use, deployment and operation of 5G networks and/or
services.
13
March 2022
This category encompasses entities that are responsible for

the manufacture, deployment and operation of 5G networks,
such as:
• Mobile Network Operators (MNOs): entities providing
mobile network services to users, operating their
own network, if necessary with the help of third
parties
• Suppliers of mobile networks: entities providing
services or infrastructure to MNOs in order to build
and/or operate their networks (both telecom
equipment manufacturers and other third-party
suppliers, such as cloud infrastructure providers and
network infrastructure providers and managed
services providers)
• Service providers (SP): entities that design, build and
operate services using aggregated network services.
Telecommunications sector (Telecom) Examples include communication service providers
offering traditional telecom services, digital service
providers offering digital services such as enhanced
mobile broadband and IoT to various vertical
industries, or network slice as a service (NSaaS)
providers offering a network slice along with the
services that it may support and configure.
• Virtualisation infrastructure service providers (VISP):
entities that provide virtualised infrastructure services
and design, build, and operate virtualisation
infrastructure(s). The infrastructure comprises
networking (e.g. for mobile transport) and computing
resources (e.g. from computing platforms).
services.
Entities that provide data centre services and that design, build
and operate their data centres. A DCSP differs from a VISP by
offering ‘raw’ resources (i.e. host servers) in rather centralised
locations and simple services for consumption of these raw
resources. A VISP rather offers access to a variety of
Datacentre services providers (DCSP) resources by aggregating multiple technology domains and
making them accessible through a single API.
services.
This category includes manufacturers of connected devices

and related service providers, meaning entities providing
objects or services that will connect to 5G networks (e.g.
smartphones, connected vehicles, e-health) and related
service components hosted in a 5G control plane as defined in
Connected devices industry a service-based architecture or mobile edge computing.
services.
This category includes entities that assess the security of 5G

networks and systems e.g. auditing companies and accredited
Cybersecurity assessment 5G laboratories.
This category audits the implementation of standards,
specifications and guidelines.
This category includes entities that share threat intelligence

and incident-related information, for example information
Cybersecurity information exchange
sharing and analysis centres (ISACs) and cyber security
incident response teams (CSIRTs).
14
March 2022

and guidelines to securely exchange cyber-intelligence.
This category encompasses entities that develop and

Standards development organisations (SDOs),
promote the adoption of standards, specifications and
associations, alliances
guidelines, for example, GSMA and 3GPP.
This category encompasses entities contributing to R&D and

innovation tasks related to all kinds of innovative actions in
areas related to 5G, including verticals. It also includes open
source organisations or communities providing technological
support and guidance in the development of 5G functions and
Research and innovation organisations services, as well as public-private partnerships and innovation
programmes.
This category exposes gaps in standardisation and
creates innovations that can lead to advancements in
standardisation by acting as starting points of new
standards, specifications and guidelines.
Explanatory notes:
• 5G vertical industries working at the ‘Think’ phase of the lifecycle have been included in the
category ‘Research and innovation organisations’.
• 5G vertical industries using 5G services have been considered as service customers, whereas
verticals delivering services to the customers in their own sector have been considered as
service providers.
• Open-source organisations have been included in the category ‘Research and innovation
organisations’ when considered for their development activities at the ‘Think’ phase of the
lifecycle. They have been included in the category ‘Suppliers of MNOs’ when considered for
their support to technologies in production.
2.1.4 5G Security domains, objectives and measures

This section outlines the security dimensions of the 5G ecosystem used in this report. In the
absence of an equally comprehensive framework, the report uses the security domains,
objectives and measures found in the ENISA Guideline on Security Measures under the EECC
and its 5G supplement. The former concern security in general, the latter concern 5G. Although
they target mainly operators, the domains and measures set out in the documents above have
been used as an analytical framework. Still, it is important to stress that the security measures
used are not to be considered as the totality of the measures necessary for the mitigation of
cybersecurity risks in 5G. Security objectives and measures could be added for any sectoral risk
assessment covering a subset of the 5G ecosystem. The table below shows the security
domains and objectives taken into consideration. The mapping of the reference documents is
further broken down into security measures in Annex 6 Detailed mapping.
Figure 6: Security domains and objectives in the Guideline on Security Measures under EECC
and its 5G Supplement
Security domains (D) Security objectives
• Information security policy

• Governance and risk management
D1 – Governance and risk management
• Security roles and responsibilities
• Security of third-party dependencies
• Background checks
D2 – Human resources security • Security knowledge and training
• Personnel changes
15
March 2022
• Handling violations
• Physical and environmental security

• Security of supplies
• Access control to network and information systems
D3 – Security of systems and facilities
• Integrity of network and information systems
• Use of encryption
• Protection of security critical data
• Operational procedures
D4 – Operations management • Change management
• Asset management
• Incident management procedures

D5 – Incident management • Incident detection capability
• Incident reporting and communication
• Service continuity strategy and contingency plans

D6 – Business continuity management
• Disaster recovery capabilities
• Monitoring and logging policies

• Exercise contingency plans
D7 – Monitoring, auditing, and testing • Network and information systems testing
• Security assessments
• Compliance monitoring
• Threat intelligence
D8 – Threat awareness
• Informing users about threats
2.2 TAXONOMY OF DOCUMENTS CONSIDERED

To facilitate the analysis, this report relies on a taxonomy comprising three categories of
documents. Each of the documents considered is assigned to one of the categories below,
according to its related definition:
• Standard: a technical specification, adopted by a recognised standardisation body, for

repeated or continuous application, with which compliance is not compulsory 5. The standards
considered are documents produced by a standardisation body (international, national or
European), and whose content include (but is not limited to) requirements, principles,
description of frameworks or processes and codes of practice.
• ICT Technical specification: a technical specification in the field of information and
communication technologies 6. ICT technical specifications are referred in this document as
‘specifications’.
• Guidelines and Best Practices: documents that explain, interpret and simplify […] standards
or […] standardisation deliverables. These can include user guides, abstracts of standards,
best practice information and awareness-building actions, strategies, and training
programmes 7.
For convenience, the report refers to the documents analysed as, alternatively, ‘reference
documents’, ‘references’, ‘existing literature’ or ‘standards, specifications and guidelines.
5
Standardisation bodies as defined by Regulation (EU) No 1025/2012, 2012), Article 2 paragraph (1)
6
Understood as ‘ICT technical specification’ as defined by Regulation (EU) No 1025/2012, 2012), Article 2 paragraph (5)
7
Definition adapted from Regulation (EU) No 1025/2012, 2012) Chapter IV, Article 15, paragraph 1 Alinea (f). The
reference to ‘European’ standards and standardisation deliverables has been deleted as the current report refers also to
non-European documents.
16
March 2022
Although these categories have been identified solely for the purpose of the study, they are
based on the EU Regulation on European standardisation (Regulation (EU) No 1025/2012,
2012) and of the International Standardisation Organisation (ISO). A reminder of the exact
definitions is given in Annexes 1 and 2 on the taxonomy for standards.
Cybersecurity standards provide an important range of contents: requirements applicable to

ICT-related domains of technology or processes, requirements for management systems,
frameworks and guidelines on security controls about ‘what’ to do.
In turn, reference documents helping the implementation and the ‘how’ to do things relate to
specifications, guidelines, and best practices.
The documents analysed in this report are listed in the Annex 5 Referencing the Existing
Literature. An important part of the 5G-related documents in this study are referred in the report
from ENISA Security in 5G Specifications (2021).
17
March 2022
3. POSITIONING AND
ASSESSMENT OF
REFERENCE DOCUMENTS IN
THE 5G ECOSYSTEM
3.1 METHODOLOGY FOR THE ASSESSMENT OF COVERAGE

This section provides the methodology to position existing standards, specifications and
guidelines in the 5G ecosystem and to assess the extent to which they address the 5G security
environment. It consists of the following steps:
• Using ENISA’s literature and complementary knowledge of the Expert Group missioned for
this study, relevant documents are sampled and grouped into consistent clusters (‘shorthand’)
made up of a selection of standards, specifications, and guidelines. The documents analysed
are listed in the Section 6 Bibliography.
• These clusters are mapped against each security domain, objective and measure of the 5G
ecosystem as described Section 2.1.4 5G Security domains, objectives and measures.
• The relevance and the completeness of the clusters is then analysed from the perspectives of
the three remaining dimensions of the 5G ecosystem, that is its stakeholders (Section 2.1.3
5G Stakeholders); its technical and functional domains (Section 2.1.1 5G technological and
functional domains); and the related technology lifecycle processes (Section 2.1.2 Technology
lifecycle processes).
• The results of the mapping and of the assessment are described in the section Annex 6
Detailed Mapping. A summarised version is contained in section 3.2 Consolidated Results.
3.2 CONSOLIDATED RESULTS

The detailed analysis underlying this report concerns more than 150 security measures and
more than 140 documents which were identified and selected from the available literature. This
detailed and in-depth analysis is provided in section Annex 6 Detailed Mapping.
Given the volume of information and the level of detail, the current section only contains a
summary table, representing the consolidated findings by security domain. A high-level
assessment of the extent to which the analysed literature addresses a given security domain for
each of the dimensions of the 5G ecosystem (i.e. stakeholders, technological and functional
domains, and technology lifecycle processes) is also provided.
Some details may not be obvious in the consolidated results. For example, ‘All’ under the
column ‘Coverage of Stakeholders’ means that the literature analysed is considered relevant for
every entity in the ecosystem. The specific degree or depth of relevance for each category of
stakeholders, technological and functional domains, and technology lifecycle processes is
tackled in the detailed mapping.
18
March 2022
Figure 7: Summary of the coverage of existing literature by security domain
Coverage of the dimensions of the 5G ecosystem

Taxonomy of
Security domain applicable 5G Technological Observations
documents Technology lifecycle
Stakeholders and functional
processes
domains
The documents referred to are, to some extent, relevant to all

dimensions of the 5G ecosystem. However, they are not
specific to 5G. To get their full value, each stakeholder category
D1 – Governance would need to put in a significant effort to tailor them to the
and risk Standards All All All relevant 5G technical and functional domains and technology
management lifecycle processes.
Such an effort requires skills and expertise. Furthermore,
fragmentation in implementation should be avoided.
The documents referred to are to some extent relevant to all

dimensions of the 5G ecosystem. However, they are not
specific to 5G. To get their full value, each stakeholder category
D2 – Human would need to put in a significant effort to tailor them to the
Standards All All All relevant 5G technical and functional domains and technology
resources security
lifecycle processes.
Such an effort requires skills and expertise. Furthermore,
fragmentation in implementation should be avoided
Although general, the documents referred to are especially

Standards Telecommunications relevant for the telecommunications sector and DCSPs. Also,
D3 – Security of
sector they are relevant to all technological and functional domains.
systems and Specifications All Run
They can be tailored with minimal effort to a 5G-specific context
facilities DCSPs
Guidelines in the ‘Run’ phase. Tailoring to the ‘Think’ and ‘Build’ phases
would require significant effort by the stakeholders.
The documents referred to are not specific to 5G, although

especially relevant for the telecommunications sector. To get
Telecommunications their full value, each stakeholder category would need to put in
D4 – Operations sector a significant effort to tailor them to the relevant 5G technical and
Specifications All Run
management functional domains and technology lifecycle processes (at the
‘Think’ and ‘Build’ phases). Such an effort requires skills and
expertise. Furthermore, fragmentation in implementation should
be avoided.
Telecommunications The documents referred to are not specific to 5G, although

D5 – Incident sector especially relevant for the telecommunications sector. To get
Standards All Run their full value, each stakeholder category would need to put in
management
a significant effort to tailor them to the relevant 5G technical and
functional domains and technology lifecycle processes (at the
19
March 2022

be avoided.

their full value, each stakeholder category would need to put in
D6 – Business
Telecommunications a significant effort to tailor them to the relevant 5G technical and
continuity Standards All Run
sector functional domains and technology lifecycle processes (at the
management
be avoided.

D7 – Monitoring, Telecommunications a significant effort to tailor them to the relevant 5G technical and
Standards All Run
auditing, and testing sector functional domains and technology lifecycle processes (at the
be avoided.

D8 – Threat Telecommunications a significant effort to tailor them to the relevant 5G technical and
Guideline All Run
awareness sector functional domains and technology lifecycle processes (at the
‘Think’ and ‘Build’ phases). Such an effort requires practice.
Furthermore, fragmentation in implementation should be
avoided.
20
March 2022
4. IDENTIFICATION OF GAPS
IN STANDARDISATION
4.1 METHODOLOGY FOR THE IDENTIFICATION OF GAPS IN THE

EXISTING LITERATURE
This section presents existing literature addressing each security domain in accordance with
Section 2.1.4 5G Security domains, objectives and measures from the perspective of the
stakeholder considered in accordance with Section 2.1.3 5G Stakeholders and points to the
areas partly covered by existing literature as well as those covered to a limited extent or not at
all.
The identification of these areas relies on expert assessment by the authors of this report. They
have assessed the extent to which the existing literature addresses an ‘ideal situation’ where
5G technical and organisational cybersecurity risks are mitigated and adequate controls to
ensure security are performed thanks to available standards, specifications, and guidelines.
This is therefore the reference against which gaps in standardisation have been identified.
4.2 ASSESSMENT OF COVERAGE AND IDENTIFICATION OF GAPS IN

STANDARDISATION
The assessment of the coverage of the standards, specification and guidelines considered, as
well as the identification of the gaps in standardisation, is conveyed in the form of a table
(Figure 9), which follows the colour coding below:
Figure 8: Colour coding for the representation of the gaps
Colour
Definition
code
Existing literature
The green cells show the existing literature addressing each security domain from the perspective
of the stakeholder considered.
Moderate Gap
The yellow cells indicate the areas where moderate gaps in standardisation have been identified.
A gap is identified as ‘moderate’ when the existing literature addresses the domain partly, meaning
that moderate effort would be required to bridge that gap.
Major gap
The orange cells indicate the areas where major gaps in standardisation have been identified.
A gap is identified as ‘major’ when the existing literature does not address the domain (or only to a
limited extent), meaning that a major effort would be required to bridge that gap.
No gap/Not relevant
The cells that are not coloured indicate areas where no gaps have been identified or only those
that are not relevant for the stakeholder.
For research and innovation organisations, gaps are intended as areas where further work by
these organisations is required.
21
March 2022
For every domain, the table (Figure 9) identifies between brackets the relevant literature as
grouped by the shorthand in Annex 5 Referencing the existing literature, reproduced below for
convenience.
Figure 9: Reference shorthand – each shorthand indicates the areas covered by the selection
of documents
Shorthand Selection of documents concerning:
ISOIEC27K ISO/IEC 27K series
ISOIEC20K IT services process map
SUPPLSEC Security of suppliers
POLTEMPLATES Build security policies
RM Cybersecurity risk management
ENISATL ENISA works related to threats
SP800HR Security related to human resources
IAM Identity and access management.
DEVSECOPS Security in the IT lifecycle
3GPP-All 3GPP technical specifications
NFVSEC Security of network functions virtualisation
eUICC Security in the eUICC domain
CRYPTOTECH Use of cryptographic techniques
PHYSEC Physical and environmental security
HARDEN Technical robustness
VULN Management of vulnerabilities
THREATMOD Threat modelling and security monitoring
SECASSUR Security assurance and related guidelines
AUDIT Audit planning and assessment
BCM Organisational and technical resilience
22
March 2022
Figure 10: Assessment of coverage and evaluation of gaps in standardisation
5G Service
Connected
Datacentre
consumer
Providers
customer
Services
Cybersecurity assessment Cybersecurity information Research and innovation
Telecom
industry
devices
Stakeholders
sector
stakeholders exchange stakeholders organisations*
or
Expose gaps in
standardisation and create
Implement standards, specifications and
Implement standards, innovations that can lead to
guidelines to achieve the security Audit the implementation of
Role in specifications and guidelines advancements in
objectives for the safe use, deployment standards, specifications and
standardisation to securely exchange cyber- standardisation, by acting
and operation of 5G networks and/or guidelines
intelligence as starting points for new
services
standards, specifications
and guidelines
Existing [ISOIEC27K], [ISO20K], [RM], [SP800HR], [SECASSUR] [RM] [RM] [NFVSEC]

literature [ENISATL], [ISOIECSUPPL],
addressing the [POLTEMPLATES] [DEVSECOPS], [HARDEN]
D1 domain
Governance
and risk Moderate gap: • Sector-specific governance and risk 5G risk assessment by third Processes for cross-border
management management parties information exchange to share
Areas partly best practices in governance
covered by • Sector-specific risk register and risk management
existing • Sector-specific ISMS and PIMS
literature implementation
Existing [SP800HR], [IAM] [SP800HR] [SP800HR] [ISOIEC27K], [SP800HR],

literature [IAM]
addressing the
D2
domain
Human
resources Moderate gap: Vertical-specific educational security content, Evaluation methods of human Cross-border process for the Vertical-specific educational
security specifying awareness programmes and resources management exchange of information (e.g. security content, specifying
Areas partly training contents e.g. MOOCs, serious games processes best practices) on the security awareness programmes and
covered by services (note: area that might be addressed of human resources training contents e.g.
existing by soft measures, not standards) MOOCs, serious games
literature services**
Existing [PHYSEC], [IAM], [3GPP-All], [AUDIT], [SECASSUR] [DEVSECOPS], [eUICC],

D3 Security of
literature [SECASSUR], [CRYPTOTECH], [NFVSEC], [CRYPTOTECH]
systems and
Addressing the [eUICC]
facilities
domain
23
March 2022
• Robust configuration and deployment of • Methods for evaluating the • Testbeds environments
Moderate gap:
5G vertical use cases security of 5G verticals and tools**
Areas partly
• Robust configuration of 5G micro • Methods for evaluating the
covered by
services and automation robustness of the
existing
configuration of 5G micro
literature • Security of RAN, Open RAN, ONAP services and automation
Major gap • Information security requirements Audits of the security of

applicable to vendors of 5G solutions orchestration and micro-
Areas not sourcing contracts services (note: area that might
covered (or be addressed by soft measures,
covered to a • Automation of robust configurations and not standards)
limited extent) deployment
by existing
literature
Existing Standards [ISO20K], [RM], [NFVSEC] Standards [ISO20K], [RM], [DEVSECOPS]

literature [AUDIT]
addressing the
domain
High-level requirements for Operations Third party risk assessment of

5G-specific cloud-native and and 5G operations
edge deployments security
Moderate gap: practices
concerning
Areas partly firmware,
covered by data
D4 Operations existing aggregatio
management literature n and
related
component
s
Major gap Requirements to implement Automated • Testbeds environments

the whole lifecycle of 5G- security and tools**
Areas not specific cloud-native and edge evaluation
covered (or deployments such as: for
covered to a centralised management of industrial
limited extent) certificates, interoperable IoT
by existing automation and orchestration,
literature serverless environments
D5 Existing [ISOIEC20K], [ISOIEC27K], [BCM], [ISOIEC20K], [ISOIEC27K], [ISOIEC20K], [ISOIEC27K], [DEVSECOPS]

literature [AUDIT] [BCM], [AUDIT] [BCM], [AUDIT]
Incident addressing the
management domain [THREATMOD], [NFVSEC]
24
March 2022
Evaluation methods for the • Typologies of scenarios for

investigation of incidents and 5G-specific, end-to-end
• Typologies of scenarios for 5G-specific, the chain of custody for incident management,
end-to-end incident management, evidence including severity criteria
Moderate gap: including severity criteria and thresholds and thresholds for
Areas partly for incidents in a 5G context incidents in a 5G context
covered by
existing • Processes for cross-border
literature information exchange to
share best practices in
incident response
Major gap • Automated incident response in a 5G Evaluation methods for the

context performance of automated
Areas not incident response
covered (or
covered to a
limited extent)
by existing
literature
Existing [ISOIEC27K], [VULN], [BCM] [ISOIEC27K], [VULN], [BCM], [ISOIEC27K], [BCM], [AUDIT]
literature [AUDIT]
addressing the
domain
Moderate gap: • 5G-specific business impact analysis • Processes for cross-border

information exchange to
Areas partly • Methodology to assess ICT readiness share best practices in
D6 covered by
• 5G-specific disaster recovery business continuity
Business existing
continuity literature
management
Major gap • Technical disaster recovery plans for 5G Methods for evaluating the ICT
functions and orchestration ICT readiness for business
Areas not continuity
covered (or
covered to a
limited extent)
by existing
literature
D7 Monitoring, Existing [VULN], [HARDEN],[THREATMOD], [AUDIT] [DEVSECOPS]

auditing and literature [DEVSECOPS]
testing Addressing the
domain
25
March 2022
Moderate gap: • Evaluation methods for Process for the cross-sector

monitoring capabilities exchange of information in the
Areas partly area of sharing best practices
covered by the • Evaluation methods for the for monitoring, auditing and
existing capabilities of automated testing
literature testbeds
Major gap • 5G-specific log sources

Areas not • Event correlation for 5G end-to-end
covered (or services and roaming
covered to a
limited extent)
by existing
literature
D8 Existing Knowledge base of risk sources, attack [THREATMOD] [THREATMOD] [DEVSECOPS], [eUICC],
literature methods, best practices of incident [CRYPTOTECH]
Threat addressing the playbooks [THREATMOD], [ISOIEC27K],
awareness domain [RM], [SECASSUR]
Moderate gap: Typologies of threats for 5G-verticals Evaluation methods for the Process for the cross-sector • Prerequisites for
applicable to RAN / Open RAN, APIs, ONAP, capabilities of the effectiveness exchange of information in the standards: new
Areas partly and cloud native technology of threat intelligence and threat area of sharing threat specifications, testbeds
covered by the hunting intelligence environments and tools
existing
literature
Major gap Automatic remediation playbooks

Areas not
covered (or
covered to a
limited extent)
by existing
literature
* Note: For research and innovation organisations, gaps are intended as areas where further work by these organisations is required.
** Note: area that might be addressed by soft measures, not standards.
26
March 2022
4.3 OVERVIEW OF GAPS BY SECURITY DOMAIN

The gaps identified in the previous table can be summarised as follows:
Security domain Moderate gaps Major gaps
• Sector-specific
governance and
risk management
• Sector-specific risk
register
• Sector-specific
ISMS and PIMS
implementation
D1 – Governance and
risk management • 5G risk assessment
by third parties
• Processes for
cross-border
information
exchange to share
best practices in
governance and
risk management
• Vertical-specific
educational
security content,
specifying
awareness
programmes and
training contents
e.g. MOOCs,
serious games
services (note: area
that might be
addressed by soft
measures, not
D2 – Human resources standards).
security
• Methods for
evaluating the
management
processes for
human resources
• Cross-border
process for the
exchange of
information (e.g.
best practices) on
the security of
human resources
• Robust • Information security requirements applicable to vendors of 5G

configuration and solutions sourcing contracts
deployment of 5G
vertical use cases • Automation of robust configurations and deployment
D3 – Security of • Robust • Audits of the security of orchestration and micro-services (note:

systems and facilities configuration of area that might be addressed by soft measures, not standards)
micro services and
automation
• Security of RAN,
Open RAN, ONAP
27
March 2022
• Methods for
evaluating the
security of 5G
verticals
• Methods for
evaluating the
robustness of the
configuration of 5G
micro services and
automation
• High-level • Requirements to implement the whole lifecycle of 5G-specific

requirements for cloud-native and edge deployments such as centralised
5G-specific cloud- management of certificates, interoperable automation and
native and edge orchestration, serverless environments
deployments
• Automated of security evaluation for industrial IoT
• Operations and
D4 – Operations security practices
management concerning
firmware, data
aggregation and
related components
• Third party risk
assessment of 5G
operations
• Typologies of • Automated incident response in a 5G context

scenarios for 5G-
specific, end-to-end • Evaluation methods for the performance of automated incident
incident response
management,
including severity
criteria and
thresholds for
incidents in a 5G
context
D5 – Incident
management • Evaluation methods
for the investigation
of incidents and the
chain of custody for
evidence
• Processes for
cross-border
information
exchange to share
best practices
• 5G-specific • Technical disaster recovery plans for 5G functions and

business impact orchestration
analysis
• Methods for evaluating the ICT readiness for business continuity
• Methodology to
assess ICT
readiness
D6 – Business • 5G-specific disaster
continuity management recovery
• Processes for
cross-border
information
exchange to share
best practices in
business continuity
• Evaluation methods • 5G-specific log sources

for monitoring
capabilities • Event correlation for 5G end-to-end services and roaming
D7 – Monitoring,
auditing, and testing • Evaluation methods
for the capabilities
of automated
testbeds
28
March 2022
• Process for the

cross-sector
exchange of
information in the
area of sharing
best practices for
monitoring, auditing
and testing
• Typologies of • Automatic remediation playbooks

threats for 5G-
verticals applicable
to RAN / Open
RAN, APIs, ONAP,
and cloud native
technology
• Evaluation methods
for the capabilities
D8 – Threat awareness of the effectiveness
of threat
intelligence and
threat hunting
• Process for the
cross-sector
exchange of
information in the
area of sharing
threat intelligence
4.4 OBSERVATIONS ON THE GAPS IN STANDARDISATION
The gap analysis is based on the standards, specifications and guidelines presented in Section
6 Bibliography.
The following should be noted.
• The bibliography relies on a sampled set of documents. Despite the authors’ efforts, there
may exist standards, specifications or guidelines that are not referenced and thus a gap is
reported in error.
• When a partial or major gap is pointed out, the question arises as to whether this area should
be standardised, supported by specifications or guidelines, or whether company-specific
needs make this contextualisation impossible.
Given the above, the present report might over-represent existing gaps in some areas. For
example, in relation to the latter point, one consistent observation is that the lifecycle of open-
source software does not fit well with the processes defined in the standards, specifications,
and guidelines. This is mainly due to the lack of a formal organisational structure that could
support, enforce and finance standardised processes in the open-source community. This is
particularly true for the security domains D1 (Governance and Risk Management), D7
(Monitoring, Auditing and Testing) and D8 (Threat Awareness).
Furthermore, the process for developing security standards is not included in the analysis itself.
The interests of individual players may influence the definition of security standards,
specifications, or guidelines in favour of economic or other trade-offs – sometimes at the cost of
a higher risk. One example is the trade-off between capabilities for legal interception and
security against espionage through end-to-end confidentiality.
4.5 ADDITIONAL LEARNINGS AND OBSERVATIONS
Complementary to the assessment of the coverage of the existing security literature, the
following elements intend to bring a qualitative perspective on the organisational and technical
29
March 2022
areas where the 5G stakeholders can intervene to improve maturity, robustness, and readiness
for resilience.
The following list gathers observations from the initial deployments of 4G that have been shared
in the Telecom industry. These trends continue to be relevant and should be considered in the
context of 5G 8:
• The complexity of simultaneously operating virtualised infrastructure and virtualised

network functions (VNFs) working together;
• The need for consistency between the three key technical domains of VNFs (Virtual
Network Functions), SDN (Software-defined networks) controllers, IaaS (Infrastructure
as a Service) due to their mutual dependencies;
• The reliance on a Linux kernel leading to a systemic risk related to unexpected
changes of configuration or unexpected behaviours at the core of computing and
connectivity capabilities, possibly impacting also new critical functions e.g.
orchestration, containers and microservices;
• The emergence of new solutions to entrust data management on cloud-based and
serverless solutions, based on short-lived assets requiring new approaches for the
observability of actions and for detecting threats;
• New cloud environments impact identity and access management as they are no
longer purely role-based, but attribute-based and context-based;
• The increased need for confidentiality and resilience on connectivity and data storage
in the network and its operation;
• The exploding number of cryptographic certificates to ensure legitimacy and avoid
man-in-the-middle attacks shine a new light on key management;
• The abundance of configurations using text-based descriptors such as JSON and
XML, together with highly distributed processing and storage;
• The effects of the increased importance of IT technologies including the importance of
open source, both at service and infrastructure levels;
• The large number of APIs bringing complexity in ensuring the legitimacy of requests
and the balance between attack surface and the exposure of an application interface;
• Cybersecurity incidents involving the recurring exposure of credentials and secrets in
CI/CD environments;
• The MNOs’ tendency to outsource their network operations and field operations to
third-party service providers entrusted with multiple networks in multiple countries,
which reinforces the importance of connectivity and therefore the inter-dependency
between the ability to operate and the operated assets;
• Outsourcing to ‘tower companies’ (companies taking charge of the radio access sites)
and ‘fibre companies’ (companies that operate fibre access networks), which are now
entrusted with managing several operators simultaneously in several countries.
The above key trends are observed in 4G, but they should be taken into consideration to
improve the coverage of standardisation for the cybersecurity of 5G.
Furthermore, one should take into account the fact that 5G networks are ‘systems of systems’,
whose representation requires automation and abstraction and whose services necessitate end-
to-end quality controls.
8
(Affirmed Networks, 2019)
30
March 2022
5. RECOMMENDATIONS
This section provides the recommendations that result from the previous sections and in
particular from the identification of gaps.
5.1 ADOPT A PROGRESSIVE APPROACH TO 5G STANDARDISATION
The report suggests that a progressive approach to 5G standardisation be undertaken. Such an

approach should start by improving existing literature. The current report could help this effort as
it gives an overview of references and assesses their suitability for a given security measure,
technical and functional domain and/or stakeholder. The creation of new references – if needed
– could be a subsequent step to enhance standardisation coverage.
5.2 HAVE A BROADER VIEW ON THE CREATION OF NEW REFERENCES
The creation of new standards, specifications and guidelines should consider several elements.
• Usefulness and necessity. It should be considered whether the creation of standards,

specifications and guidelines is necessary and/or useful for a specific security measure, for a
specific 5G domain, and/or for a specific stakeholder at a given stage of the lifecycle.
• Link with strategic objectives. It is recommended that a consistent link between any new
reference and the strategic objective it should serve is ensured. For instance, if the objective
of a new reference is to harmonise practices at the European level, local regulations should
be taken into consideration. For example, contextualisation of HR (human resources)
measures must account for local regulations. A special attention shall be brought to provisions
for legal interception.
• Measurability of effectiveness. New references should facilitate the consistent measuring of
the effectiveness of the security measures from an end-to-end service perspective.
• Consideration for new technologies. For example, detection tactics of incidents in 5G should
be tackled also from the perspective of the development and operation of Artificial Intelligence,
and not only from the standpoints of mobile network operators, their managed services
provider, and B2B verticals.
• Thinking beyond standardisation. In some cases, the effectiveness of standards,
specifications or guidelines depends on external factors. For example, because of the open
nature of the development of free and open source software (FOSS), security guidelines and
recommendations should be accompanied by the commitment of resources to development
and audit. Therefore, industry players and public administrations relying on open source
software should be encouraged to actively contribute to continuously improve and maintain
the security of the FOSS-based solutions.
5.3 FOSTER THE MATURITY AND THE COMPLETENESS OF THE

IDENTIFICATION AND ASSESSMENT OF RISK
Section 4 Identification of Gaps in Standardisation points to areas, for each security domain,
that are partly covered by the existing literature, as well as those covered to a limited extent or
not at all. Besides these specific areas, the experts observed a broader gap related to risk
assessment. The existing literature related to risk assessment is not specific to 5G and/or does
not identify and evaluate risks consistently. This leads to a fragmented security landscape which
might be detrimental for the overall security of 5G.
31
March 2022
Therefore, it is important to foster the maturity and the completeness of risk identification and
assessment, by harmonising risk assessment practices in a way that is inclusive of all
stakeholders of the 5G ecosystem. For example, this would imply in particular (but not only)
standardised:
• registers of risks, including from the perspective of the telecommunications sector and service
customers,
• skills and capacities frameworks for third party assessment,
• knowledge bases of threat scenarios,
• requirements for security monitoring,
• assessment methods with an adequate abstraction level,
• requirements for auditing capability, in particular for service providers.
In this context, it is worth mentioning the approach to risk identification outlined in ENISA’s
Methodology for Sectoral Cybersecurity Assessment, and described in the subsequent section.
5.3.1 ENISA’s methodology for sectoral cybersecurity assessment
The European Cybersecurity Act (CSA) obliges to the definition of security and certification
requirements for ICT products, services and processes to be based on the risk associated with
their intended use.
To this end, ENISA has proposed the SCSA methodology (ENISA Methodology for Sectoral
Cybersecurity Assessments, 2021) to support the identification of cybersecurity risks associated
with the intended use of systems in the context of business services and processes, with the
option to involve all stakeholders from sectoral vertical users to the providers of network
infrastructure. SCSA carries out the assessment at sectoral business level involving all relevant
5G stakeholders, their business objectives and their ICT subsystems and processes.
Cybersecurity risks are identified in relation to the business objectives and the risks identified
indicate the security, certification and assurance level requirements for particular ICT products,
services and processes. This can support a balance between the cost that a 5G stakeholder
has to cover for security and assurance and the benefit of protecting his business objectives.
5.4 FINAL OBSERVATIONS
It is to be noted that the prioritisation of new references to be created is outside the scope of
this work and that, in accordance with the previous recommendation, the creation of new
references might not always be necessary and should be part of a progressive approach which
should consider several aspects.
Finally, it is important to stress that, while the technical and organisational standards analysed
can contribute to the security of 5G, they should not be treated as an exhaustive list of
measures guaranteeing security. Besides considerations of the effectiveness of specific
standards that are outside the scope this report, it should be reminded that there are risks that
are not covered by standards, for example residual risks whose cost is neither borne by nor
attributable to a specific stakeholder, such as societal risks resulting from network malfunctions.
The complexity of 5G, as depicted in the previous sections, calls for a comprehensive vision of
trust and of resilience that goes beyond standardisation. This vision should be future-proof and
not dependent on the variability of assets and configurations in the network.
32
March 2022
6. BIBLIOGRAPHY
1. 3GPP (2016): 3GPP 33.117 Catalogue of general security assurance requirements;

Technical Specification.
2. 3GPP (2016): 3GPP 33.401 3GPP System Architecture Evolution (SAE); Security
architecture.
3. 3GPP (2020): 3GPP 33.102 3G security; Security architecture; Technical Specification.
4. 3GPP (2020): 3GPP 33.116 Security Assurance Specification (SCAS) for the MME
network product class.
5. 3GPP (n.d.): 3GPP 33.163 Battery Efficient Security for very low throughput Machine
Type Communication (MTC) devices (BEST).
6. 3GPP (n.d.): 3GPP 33.210 Network Domain Security (NDS); IP network layer security.
7. 3GPP (n.d.): 3GPP 33.310 Network Domain Security (NDS); Authentication Framework
(AF).
8. 3GPP. (n.d.): 3GPP 33.501 Security architecture and procedures for 5G System.
9. 3GPP. (n.d.): TS 33.514 - 5G Security Assurance Specification (SCAS) for the Unified
Data Management (UDM) network product class.
10. ANSI. (2019); ANSI/TIA-569-E ‘Telecommunications Pathways and Spaces’.
11. ANSSI (2018): EBIOS Risk Manager; Paris ANSSI.
12. ASIS (2021): ASIS Physical Asset Protection Guideline; Retrieved from asis.org:
https://www.asisonline.org/publications--resources/standards--guidelines/
13. Carder, J. (2020): How to build a SOC with limited resources.
14. Carder, J. (2020): Security Operation Centers Maturity Model.
15. CIS (2018): CIS Risk Assessment Method.
16. CIS (2021): CIS Controls® v8; Retrieved from https://www.cisecurity.org/controls/v8/
17. Cloud Security Alliance (2015); Best practices for mitigating risks in virtualized
environments.
18. CSIAC (2021): CSIAC evaluation of threat taxonomies; Retrieved from
https://csiac.org/articles/evaluation-of-comprehensive-taxonomies-for-information-
technology-threats/
19. EBIOS C (2021): Oberisk; Retrieved from https://club-ebios.org/site/en/tag/oberisk-en/
20. ENISA (2014): Report on Cyber Crisis Cooperation and Management.
21. ENISA (2016): Threat Taxonomy; Retrieved from
https://www.enisa.europa.eu/topics/threat-risk-management/threats-and-trends/enisa-
threat-landscape/threat-taxonomy/view.
22. ENISA (2019): EU Coordinated Risk Assessment of 5G Networks Security.
23. ENISA (2019): Threat Landscape for 5G Networks.
24. ENISA (2020): ENISA Threat Landscape for 5G Networks Updated.
25. ENISA (2020): Guideline on Security Measures under the EECC.
26. ENISA (2021): 5G Supplement to the Guideline on Security Measures under EECC.
27. ENISA (2021): Methodology for Sectoral Cybersecurity Assessments.
28. ENISA (2021): Security in 5G Specifications.
29. ETSI (2014): ETSI GS NFV-SEC 003 - Network Functions Virtualisation (NFV) - NFV
Security - Security and Trust Guidance.
30. ETSI (2014): Network Functions Virtualisation (NFV);Architectural Framework.
31. ETSI (2017): ETSI GS NFV-SEC 012 - Network Functions Virtualisation (NFV) Release
3; Security; System architecture specification for execution of sensitive NFV
components.
32. ETSI (2017): Network Function Virtualisation (NFV);Reliability; Report on the resilience
of NFV-MANO critical capabilities.
33
March 2022
33. ETSI (2017): Network Functions Virtualisation (NFV) Release 3; Security; Security
Management and Monitoring specification.
34. ETSI (2018): ETSI GS NFV-SEC 014 - Network Functions Virtualisation (NFV) Release
3 - NFV Security - Security Specification for MANO Components.
35. ETSI (2022): ETSI TS 103.465 Smart Secure Platform (SSP); Requirements
Specification.
36. Regulation (EU) No 1025/2012 of the European Parliament and of the Council of 25
October 2012 on European standardisation.
37. Regulation (EU) 2019/881 - Cybersecurity Act; Regulation (EU) 2019/881 on ENISA (the
European Union Agency for Cybersecurity) and on information and communications
technology cybersecurity certification and repealing Regulation (EU) No 526/2013
(Cybersecurity Act).
38. European Commission (2020, December 16): Brussels, Belgium, EU Press Release;
New EU Cybersecurity Strategy and new rules to make physical and digital critical
entities more resilient.
39. Fédération Française des Télécoms (2019): Repository of security objectives for
Virtualised Network Functions (French).
40. GSMA (2019): GSMA FS.11 - SS7 Interconnect Security Monitoring and Firewall
Guidelines.
41. GSMA (2019): GSMA FS.19 - Diameter Interconnect Security.
42. GSMA (2020): GSMA FS.23 - Coordinated Vulnerability Disclosure; Guideline.
43. GSMA (2020): GSMA FS.37 - GPRS Tunnelling Protocol User Security.
44. GSMA (2020): GSMA NG.113 - 5G System Roaming Guidelines.
45. GSMA (2021): GSMA FS.16 - NESAS Development and Lifecycle Security
Requirements v2.0.
46. GSMA (n.d.): PRD FS.04 GSMA SAS Standard for UICC Production.
47. GSMA (n.d.): PRD FS.05 GSMA SAS Methodology for UICC Production.
48. GSMA (n.d.): PRD FS.08 GSMA SAS Standard for Subscription Manager Roles.
49. GSMA (n.d.): PRD FS.09 GSMA SAS Methodology for Subscription Manager Roles.
50. GSMA (n.d.): PRD FS.18 GSMA SAS Consolidated Security Guidelines.
51. GSMA (n.d.): PRD SGP.01 Embedded SIM Remote Provisioning Architecture.
52. GSMA (n.d.): PRD SGP.02 Remote Provisioning Architecture for Embedded UICC;
Technical Specification.
53. GSMA (n.d.): PRD SGP.21 Remote SIM Provisioning (RSP) Architecture.
54. GSMA (n.d.): PRD SGP.22 Remote SIM Provisioning (RSP) Technical Specification.
55. GSMA (n.d.): TS 33.513 - 5G Security Assurance Specification (SCAS); User Plane
Function (UPF); Technical Specification.
56. GSMA (n.d.): TS 33.515 - 5G Security Assurance Specification (SCAS) for the Session
Management Function (SMF) network product class.
57. IETF (2004): IETF RFC 3871 - Operational Security Requirements for Large Internet
Service Provider (ISP) IP Network Infrastructure.
58. Informationstechnik, B. F. (2017): BSI Standard 200-3 - IT Risk Management: Standard.
59. ISO (2010): ISO/IEC 11770-1:2010 - Information technology — Security techniques —
Key management — Part 1: Framework.
60. ISO (2012): ISO/IEC 17024:2012 - Conformity assessment — General requirements for
bodies operating certification of persons.
61. ISO (2012): ISO/IEC 17065:2012 - Conformity assessment — Requirements for bodies
certifying products, processes and services.
62. ISO (2013): ISO/IEC 27001:2013 - Information technology — Security techniques —
Information security management systems — Requirements.
Code of practice for information security controls.
Information security for supplier relationships — Part 3: Guidelines for information and
communication technology supply chain security.
34
March 2022
65. ISO (2013): ISO/IEC TR 20000-5:2013 - Information technology — Service management

— Part 5: Exemplar implementation plan for ISO/IEC 20000-1.
Information security for supplier relationships — Part 1: Overview and concepts.
Information security for supplier relationships — Part 2: Requirements.
68. ISO (2015): ISO 22317:2015 - Societal security — Business continuity management
systems — Guidelines for business impact analysis (BIA).
69. ISO (2015): ISO/IEC 17021-1:2015 - Conformity assessment — Requirements for
bodies providing audit and certification of management systems — Part 1:
Requirements.
Network security — Part 1: Overview and concepts.
71. ISO (2015): ISO/IEC TR 20000-11:2015 - Information technology — Service
management — Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011
and service management frameworks: ITIL®.
A framework for identity management — Part 3: Practice.
Information security incident management — Part 1: Principles of incident management.
Information security for supplier relationships — Part 4: Guidelines for security of cloud
services.
75. ISO (2017): ISO/IEC 20000-6:2017 - Information technology — Service management —
Part 6: Requirements for bodies providing audit and certification of service management
systems.
Competence requirements for information security management systems professionals.
77. ISO (2018): ISO 19011:2018 - Guidelines for auditing management systems.
78. ISO (2018): ISO 21001:2018 - Educational organizations — Management systems for
educational organizations — Requirements with guidance for use.
79. ISO (2018): ISO 22331:2018 - Security and resilience — Business continuity
management systems — Guidelines for business continuity strategy.
80. ISO (2018): ISO 29992:2018 - Assessment of outcomes of learning services —
Guidance.
81. ISO (2018): ISO 31000:2018 - Risk management – Guidelines.
Part 1: Service management system requirements.
83. ISO (2018): ISO/IEC 20000-10:2018 - Information technology — Service management
— Part 10: Concepts and vocabulary.
Information security risk management.
Vulnerability disclosure.
86. ISO (2019): ISO 22301:2019 - Security and Resilience — Business continuity
management systems — Requirements.
Part 2: Guidance on the application of service management systems.
Part 3: Guidance on scope definition and applicability of ISO/IEC 20000-1.
Part 7: Guidance on the integration and correlation of ISO/IEC20000-1:2018 to ISO
9001:2015 and ISO/IEC27001:2013.
90. ISO (2019): ISO/IEC 24760-1:2019 - IT Security and Privacy — A framework for identity
management — Part 1: Terminology and concepts.
35
March 2022
management systems — Guidance on the use of ISO 22301.
Governance of information security.
93. ISO (2021): ISO 22300:2021 - Security and Resilience - Vocabulary.
management systems — Guidelines for developing business continuity plans and
procedures.
95. ITU-T (2016): X.1038 Security requirements and reference architecture for software-
defined networking.
96. LogRythm (2021): Analysis and Detection of Golden SAML Attacks.
97. MITRE (2019): Common Attack Pattern Enumeration and Classification; Retrieved July
16, 2019, from https://capec.mitre.org
98. NIST (2003): SP800-50 - Building an Information Technology Security Awareness and
Training Program; Guideline.
99. NIST (2006): SP800-100 - Information Security Handbook: A Guide for Managers.
Gaithersburg, MD: NIST.
100. NIST (2006): SP800-92 Guide to Computer Security Log Management.
101. NIST (2017): SP800-190 - Application Container Security.
102. NIST (2018): White Paper - Framework for Improving Critical Infrastructure
Cybersecurity.
103. NIST (2019): SP800-204 - Security Strategies for Microservices-based Application
Systems.
104. NIST (2020): SP800-181Rev1 Workforce Framework for Cybersecurity (NICE
Framework).
105. NIST (2020): White Paper - Mitigating the Risk of Software Vulnerabilities by Adopting
a Secure Software Development Framework (SSDF).
106. NIST (2021): NIST SP-800-53A - Assessing Security and Privacy Controls in
Information Systems and Organizations.
107. NIST (2021): SP800-154 Guide to Data-Centric System 3 Threat Modeling.
108. NIST (2021): SP800-204B - Attribute-based Access Control for Microservices-based
Applications using a Service Mesh.
109. NIST (2021): SP800-53A Risk Management Framework - Assessing Security and
Privacy Controls in Information Systems and Organizations. Guideline.
110. NIST (n.d.): SP800-53 Rev. 5.1 and SP 800-53B; Retrieved from nist.org:
https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-
search#!/controls?version=5.1&family=PE
111. OWASP (2017): owasptopten.org; Retrieved from https://www.owasptopten.org/
112. SANS Institute (2021): Security Policy Templates; Retrieved from
https://www.sans.org/information-security-policy/
113. TM Forum (2021): ETOM GB 921 Business Process Framework.
114. W. Bautista Jr (2019): Cyber kill chain and the OODA loop; O’Reilly Editions
36
March 2022
ANNEX – TAXONOMY FOR

STANDARDS
This section acts as a reminder of the definitions of document typologies from the EU regulatory
framework and the ISO.
A.1 DOCUMENT TYPOLOGIES DEFINED BY THE EU REGULATION

The European Union’s Regulation (EU) No 1025/2012, 2012 stipulates the following provisions:
A Technical specification is a document that prescribes technical requirements to be fulfilled

by a product, process, service or system (..).
Depending on the source of such specification, it could be a standard (standard means a

technical specification adopted by a recognised standardisation body for repeated or continuous
application) at the international, regional (e.g. European) or national level.
Additionally, there is the European standardisation deliverable, which refers to any technical
specification other than a European standard adopted by a European standardisation
organisation for repeated or continuous application.
Technical specifications, not being standards nor European standardisation deliverables, could
be identified as equivalent to standards if they meet the requirements set up in Annex II of
Regulation 1025/2012.
If the taxonomy based on EU Regulation 1025/2012 were considered it could look like:
A. Technical specification – document containing the requirements for:

A1 – Technical specification – standard
A2 – Technical specification – European standardisation deliverable considered as a standard
(adopted by one of the European Standards Organisations)
A3 – Technical Specification – standard (according to the rules and principles set up in Annex II
of the Regulation)
B. Document that contains information other than requirements:
B1 – (Name of a Recognised Standardisation Body) standard – Framework
B2 – (Name of a Recognised Standardisation Body) standard – Guidelines
B3 – (Name of a Recognised Standardisation Body) standard – Best practices
B4 – (Name of a Recognised Standardisation Body) standard – Vocabulary
A.2 DOCUMENT TYPOLOGIES DEFINED BY ISO

If we consider the ISO taxonomy we are dealing with the following (according to ISO):
Standard: is a document established by consensus and approved by a recognised body that

provides for common and repeated use rules, guidelines or characteristics for activities or their
results, aimed at the achievement of the optimum degree of order in a given context.
International Standard: is a standard that is adopted by an international standardising or

standards organisation and made available to the public.
37
March 2022
Technical Specification (TS): is a document published by ISO or IEC for which there is, in the
future, the possibility of agreement on an International Standard but for which at present:
• the required support for approval as an International Standard cannot be obtained,

• there is doubt on whether consensus has been achieved,
• the subject matter is still under technical development, or
• there is another reason precluding immediate publication as an International Standard.
Technical Report (TR): is a document published by ISO or IEC containing collected data of a
different kind from that normally published by ISO or IEC.
If the ISO taxonomy were considered it could look like:
A. Standards
A1 – (Name of a Recognised Standardisation Body) Standard – Requirements
A2 – (Name of a Recognised Standardisation Body) Standard – Framework
A3 – (Name of a Recognised Standardisation Body) Standard – Guidelines
A4 – (Name of a Recognised Standardisation Body) Standard – Vocabulary
B. Technical reports
B1 – ISO Technical Report – Guidelines
B2 – ISO Technical Report – Best practices
C. Non-standard documents
C1 – (Name of the Issuer) – Guidelines
C2 – (Name of the Issuer) – Best Practices
38
March 2022
ANNEX – MAPPING
In the detailed analysis, to keep the information in the table manageable, the convention used in
this annex is proposed to refer to one or several stakeholders, one or several documents, under
a common label.
A.3 REFERENCING THE 5G TECHNICAL AND FUNCTIONAL DOMAINS

In the detailed analysis, to keep the information in the table manageable, a convention specific
to this document is proposed to refer to one or several 5G technical and functional domains
under a common label. The table below provides for every 5G domain, the associated label.
5G Technical and functional domains Definition
5G Use cases End-to-end services based on 5G, characterised by how they

use and/or transmit data. Example: ‘Vehicle-to-everything’,
eMBB, mMTC, URLLC.
Multi Access Edge Computing (MEC) Services Multi access computing services used to bring computation
and connectivity closer to the end-user in order to meet the
requirements for data transmission speed and latency.
Physical Infrastructure Set of premises including hardware and software for

computation, storage and transmission as well as the related
technical environment (energy, air conditioning, cable paths,
civil works infrastructures, etc.).
Virtualised Infrastructure Computing, storage and networking capacities on demand.
Radio Access Network (RAN) Logical and hardware components making up the functions of
the radio access network. It includes mainly distribution units
and control units for radio access.
Multi Access Edge Computing (MEC) Infrastructure Infrastructure related to the decentralisation of cloud functions
(storage of data and computing) located closer to the user or
edge device.
5G Core Network, Network Function (CN NF) Central part of the 5G infrastructure which enables new
functions related to multi-access technologies. Its main
purpose is to deliver services over all kinds of networks
(wireless, fixed, converged).
Data Network (DN) Connectivity to external data, content, services and other
resources available outside the 5G network. The data network
is also used to interconnect different 5G networks, operators
and providers.
Transport Part of the network ensuring the connectivity between the

access and core networks.
Management and Orchestration (MANO) Software, operations tools and the related environment used to
automate operations that relate to the lifecycle of the
infrastructure and service components.
A.4 REFERENCING THE STAKEHOLDERS

In the detailed analysis, to keep the information in the table manageable, a convention specific
to this document is proposed to refer to one or several stakeholders under a common label. The
table below provides for every stakeholder category, the list of the concerned stakeholders is
represented by the designation provided in Section 2.1.3 5G Stakeholders.
39
March 2022
Stakeholder category Definition
Entities that use services that are offered by a service provider

(SP). In the context of 5G, these would be, for example,
vertical industries and their private networks. In addition,
consumers of 5G services without a business relation with a
5G service provider (e.g. end users) are included in this
5G Service customer or consumer category.
services.
This category encompasses entities that are responsible for

the manufacture, deployment and operation of 5G networks,
such as:
• Mobile network operators: entities providing mobile
network services to users, operating their own
network, if necessary with the help of third parties.
• Suppliers of mobile networks: entities providing
services or infrastructure to MNOs in order to build
and/or operate their networks (both telecom
equipment manufacturers and other third-party
suppliers, such as cloud infrastructure providers and
network infrastructure providers and managed
services providers).
• Service provider (SP): entities that design, build and
operate services using aggregated network services
Telecommunications sector (Telecom) such as, for example, communication service
providers offering traditional telecom services, digital
service providers offering digital services such as
enhanced mobile broadband and IoT to various
vertical industries, or network slice as a service
(NSaaS) providers offering a network slice along with
the services that it may support and configure.
• Virtualisation infrastructure service providers (VISP):
entities that provide virtualised infrastructure services
and that design, build and operate virtualisation
infrastructure(s). The infrastructure comprises
networking (e.g. for mobile transport) and computing
resources (e.g. from computing platforms).
services.
Entities that provide data centre services and that design, build
and operate their data centres. A DCSP differs from a VISP by
offering ’raw’ resources (i.e. host servers) in rather centralised
locations and simple services for consumption of these raw
resources. A VISP rather offers access to a variety of
Datacentre services providers (DCSP) resources by aggregating multiple technology domains and
making them accessible through a single API.
services.
This category includes manufacturers of connected devices

and related service providers, meaning entities providing
objects or services that will connect to 5G networks (e.g.
smartphones, connected vehicles, e-health) and related
service components hosted in a 5G control plane as defined in
Connected devices industry service-based architecture or mobile edge computing.
services.
40
March 2022
This category includes entities that assess the security of 5G

networks and systems e.g. auditing companies and accredited
Cybersecurity assessment 5G laboratories.
This category audits the implementation of standards,
specifications and guidelines.
This category includes entities that share threat intelligence

and incident-related information, for example information
sharing and analysis centres (ISACs) and cyber security
Cybersecurity information exchange incident response team (CSIRTs).
and guidelines to securely exchange cyber-intelligence.
This category encompasses entities that develop and

Standards development organisations (SDOs),
promote the adoption of standards, specifications and
associations, alliances
guidelines, for example GSMA and 3GPP.
This category encompasses entities contributing to R&D and

innovation tasks related to all kinds of innovative actions in the
areas related to 5G, including verticals. It also includes open
source organisations or communities providing technological
support and guidance in the development of 5G functions and
Research and innovation organisations services, as well as public-private partnerships and innovation
programmes.
This category exposes gaps in standardisation and
creates innovations that can lead to advancements in
standardisation, by acting as starting points for new
standards, specifications and guidelines.
41
March 2022
A.5 REFERENCING THE EXISTING LITERATURE

In the detailed analysis, to keep the information in the detailed analysis table manageable, a
convention specific to this document is proposed for referring to one or several documents
under a common cluster for easy reference.
The clustering choice is based on either the family of documents or common security theme.
The table below provides for every group, the reference shorthand, the descriptive title, the list
of concerned documents based on Section 6 Bibliography, and the document taxonomy from
Section 2.2.
Reference shorthand
References from the bibliography Document taxonomy
Descriptive title
(ISO, ISO/IEC 27001:2013 - Information technology — Security

techniques — Information security management systems —
ISOIEC27K Requirements, 2013)

techniques — Code of practice for information security controls, 2013)
A selection of ISO/IEC Standard
JTC1 SC27 (ISO, ISO/IEC 27005:2018 - Information technology — Security
requirements and code techniques — Information security risk management, 2018)
of practice to setup
information security
processes. (ISO, ISO/IEC 27035-1:2016 - Information technology — Security
techniques — Information security incident management — Part 1:
Principles of incident management, 2016)
(ISO, ISO/IEC 20000-1:2018 - Information technology — Service

management — Part 1: Service management system requirements,
2018)

management — Part 2: Guidance on the application of service
management systems, 2019)

management — Part 3: Guidance on scope definition and applicability
of ISO/IEC 20000-1, 2019)
ISOIEC20K (ISO, ISO/IEC TR 20000-5:2013 - Information technology — Service

management — Part 5: Exemplar implementation plan for ISO/IEC
20000-1, 2013)
Standard
A selection of ISO/IEC management — Part 6: Requirements for bodies providing audit and
processes mapped for certification of service management systems, 2017)
service delivery.
management — Part 7: Guidance onthe integration and correlation of
ISO/IEC20000-1:2018 to ISO 9001:2015 and ISO/IEC27001:2013 ,
2019)

management — Part 10: Concepts and vocabulary, 2018)
(ISO, ISO/IEC TR 20000-11:2015 - Information technology — Service

management — Part 11: Guidance on the relationship between
ISO/IEC 20000-1:2011 and service management frameworks: ITIL®,
2015)
42
March 2022
(TMForum, 2021)
(IETF, 2004)

techniques — Code of practice for information security controls, 2013):
12.1 Operational procedures and responsibilities
(ISO, ISO/IEC 27036-1:2014 - Information technology — Security

techniques — Information security for supplier relationships — Part 1:
Overview and concepts, 2014)

SUPPLSEC Requirements, 2014)

techniques — Information security for supplier relationships — Part 3: Standard
A selection of Guidelines for information and communication technology supply chain
references for the security, 2013)
security of suppliers.
Guidelines for security of cloud services, 2016)
(GSMA, GSMA FS.16 - NESAS Development and Lifecycle Security

Requirements v2.0, 2021)
POLTEMPLATES
(SANS Institute, 2021)

Guideline
A selection of
guidelines to build
security policies

techniques — Information security risk management, 2018)
(ENISA, Methodology for Sectoral Cybersecurity Assessments, 2021)
(Cloud Security Alliance, 2015)
RM
(TMForum, 2021) Standard
A selection of Note: The eTOM consists in a process map reference framework. It’s a
references for useful reference for identifying business processes. However, the
cybersecurity risk eTOM material does not provide any coverage on the implementation of
management and security measures other than their use to identify a scope of
related assessments governance for S01 and a scope of primary assets for SO2.
(ISO, ISO 31000:2018 - Risk management – Guidelines, 2018)
(ANSSI, EBIOS Risk Manager, 2018), Guideline
43
March 2022
(MITRE, Common Attack Pattern Enumeration and Classification,

2019),
(NIST, SP800-53A Risk Management Framework - Assessing Security

and Privacy Controls in Information Systems and Organizations, 2021),
(EBIOS, 2021)
(CIS, CIS Risk Assessment Method, 2018)
(Informationstechnik, 2017)
(ENISA, ENISA Threat Landscape for 5G Networks Updated, 2020)

ENISATL
(ENISA, Threat Landscape for 5G Networks, 2019)
Report
(ENISA, EU Coordinated Risk Assessment of 5G Networks Security,
A selection of 2019)
references for ENISA
works related to threats
(NIST, SP800-50 - Building an Information Technology Security

Awareness and Training Program, 2003)
(NIST, SP800-100 - Information Security Handbook: A Guide for

Managers, 2006)
(NIST, SP800-181Rev1 Workforce Framework for Cybersecurity (NICE

SP800HR Framework), 2020)
(ISO, ISO 29992:2018 - Assessment of outcomes of learning services

— Guidance, 2018)
Guideline
A selection of
references for security (ISO, ISO/IEC 27021:2017 - Information technology — Security
related to human techniques — Competence requirements for information security
resources management systems professionals, 2017)
(ISO, ISO/IEC 17024:2012 - Conformity assessment — General

requirements for bodies operating certification of persons, 2012)
(ISO, ISO 21001:2018 - Educational organizations — Management

systems for educational organizations — Requirements with guidance
for use, 2018)
(ISO, ISO/IEC 24760-1:2019 - IT Security and Privacy — A framework

IAM
for identity management — Part 1: Terminology and concepts, 2019)

techniques — A framework for identity management — Part 3: Practice, Standard
A selection of 2016)
references for identity
and access
(NIST, SP800-204B - Attribute-based Access Control for Microservices-
management
based Applications using a Service Mesh, 2021)
44
March 2022
(ETSI, ETSI GS NFV-SEC 003 - Network Functions Virtualisation (NFV)

- NFV Security - Security and Trust Guidance, 2014)
(ETSI, ETSI GS NFV-SEC 014 - Network Functions Virtualisation (NFV)

Release 3 - NFV Security - Security Specification for MANO
Components and, 2018)
(IETF, 2004)

techniques — Information security management systems —
Requirements, 2013): 12.1 Operational procedures and responsibilities
(NIST, SP800-204 - Security Strategies for Microservices-based

Application Systems, 2019)
DEVSECOPS
(NIST, SP800-190 - Application Container Security, 2017)
(NIST, White Paper - Mitigating the Risk of Software Vulnerabilities by

Guideline
Adopting a Secure Software Development Framework (SSDF), 2020)
A selection of
references for security
(ISO, ISO/IEC/IEEE 29119-1:2013 Software and systems engineering
in the IT lifecycle
— Software testing — Part 1: Concepts and definitions, 2013)
The whole of the 3GPP list from the bibliography.

3GPP-All
Note : 3GPP technical specifications have been considered as technical Specification

3GPP Technical features that are part of the capabilities of the network. 3GPP Technical
specifications from the specifications have been considered as addressing a security measure
library only when they have been deemed valid as a stand-alone input to a
given security measure.

techniques — Network security — Part 1: Overview and concepts,
NFVSEC 2015)
(ETSI, Network Function Virtualisation (NFV);Reliability; Report on the

resilience of NFV-MANO critical capabilities, 2017)
Specification
A selection of
references for the (ETSI, Network Functions Virtualisation (NFV) Release 3; Security;
security of network Security Management and Monitoring specification, 2017)
functions virtualisation
(ETSI, Network Functions Virtualisation (NFV);Architectural Framework,
2014)
45
March 2022
(GSMA, PRD FS.04 GSMA SAS Standard for UICC Production)
(GSMA, PRD FS.05 GSMA SAS Methodology for UICC Production)
(GSMA, PRD FS.08 GSMA SAS Standard for Subscription Manager

Roles)
(GSMA, PRD FS.09 GSMA SAS Methodology for Subscription

eUICC
Manager Roles)
(GSMA, PRD FS.18 GSMA SAS Consolidated Security Guidelines)

Specification
A selection of
(GSMA, PRD SGP.01 Embedded SIM Remote Provisioning
references for security
Architecture)
in the eUICC domain
(GSMA, PRD SGP.02 Remote Provisioning Architecture for Embedded

UICC)
(GSMA, PRD SGP.21 Remote SIM Provisioning (RSP) Architecture)
(GSMA, PRD SGP.22 Remote SIM Provisioning (RSP) Technical

Specification)
(3GPP, 3GPP 33.501 Security architecture and procedures for 5G

System)
(3GPP, 3GPP 33.310 Network Domain Security (NDS); Authentication

Framework (AF))
(3GPP, 3GPP 33.210 Network Domain Security (NDS); IP network

layer security)
(3GPP, 3GPP 33.163 Battery Efficient Security for very low throughput
Machine Type Communication (MTC) devices (BEST))
CRYPTOTECH Specification
techniques — Key management — Part 1: Framework, 2010)
(ETSI, ETSI GS NFV-SEC 012 - Network Functions Virtualisation

A selection of
(NFV)Release 3; Security; System architecture specification for
references for the use of
execution of sensitive NFV components, 2017)
cryptographic
techniques
(ITU-T, 2016)
NIST, 2021, Planning for a Zero Trust Architecture: A Starting Guide for
Administrators
Guideline
46
March 2022
(NIST, SP800-53 Rev. 5.1 and SP 800-53B)
(ASIS, 2021)
PHYSEC
(Informationstechnik, 2017)
Guideline
A selection of
references for physical
techniques — Code of practice for information security controls, 2013)-
and environmental
11.1 Secure areas and 11.2 Equipment
security
(ANSI, 2019)
HARDEN
(CIS, CIS Controls® v8, 2021)
Guideline
(OWASP, 2017)
A selection of
references for technical
robustness
(GSMA, GSMA FS.23 - Coordinated Vulnerability Disclosure, 2020)

Guideline

VULN techniques — Vulnerability disclosure, 2018)
(ISO, ISO/IEC 17960:2015 Information technology — Programming

languages, their environments and system software interfaces — Code
A selection of signing for source code, 2015)
references for the
management of (ISO, ISO/IEC 30111:2019 - Information technology — Security Standard
vulnerabilities techniques — Vulnerability handling processes, 2019)
(ISO, ISO/IEC TS 30104:2015 - Information Technology — Security

Techniques — Physical Security Attacks, Mitigation Techniques and
Security Requirements, 2015)
(ENISA, Threat Taxonomy, 2016)

THREATMOD
(MITRE, Common Attack Pattern Enumeration and Classification, 2019)
(NIST, SP800-92 Guide to Computer Security Log Management, 2006)

A selection of Guideline
references for threat (NIST, SP800-154 Guide to Data-Centric System 3 Threat Modeling,
modelling and security 2021)
monitoring, including
threat intelligence (CSIAC, 2021)
capabilities
(Carder, How to build a SOC with limited resources, 2020)
47
March 2022
(Carder, Security Operation Centers Maturity Model, 2020)
(LogRythm, 2021)
(W. Bautista Jr, 2019)
(NSA & CISA, 2021)

techniques — Code of practice for information security controls, 2013):
6.1.4 Contact with special interest groups and 12.4 Logging and
monitoring,
(GSMA, GSMA FS.11 - SS7 Interconnect Security Monitoring and

Firewall Guidelines, 2019)
(GSMA, GSMA FS.19 - Diameter Interconnect Security, 2019)
(GSMA, GSMA FS.37 - GPRS Tunnelling Protocol User Security, 2020)
SECASSUR The GSMA Network Equipment Security Assurance Scheme

documents:
Same as 3GPP Technical Specifications: 33.166, 33.117, 33.216,

A selection of 33.250, 33.511, 33.512, 33.517, 33.518, 33.519
references for security However, the following GSMA Technical Specifications are Specification
assurance and related contributing:
guidelines (GSMA, TS 33.513 - 5G Security Assurance Specification (SCAS);
User Plane Function (UPF))
(3GPP, TS 33.514 - 5G Security Assurance Specification (SCAS) for
the Unified Data Management (UDM) network product class)
(GSMA, TS 33.515 - 5G Security Assurance Specification (SCAS) for
the Session Management Function (SMF) network product class)

techniques — Governance of information security, 2020)
(ISO, ISO 19011:2018 - Guidelines for auditing management systems,

AUDIT
2018)
(NIST, NIST SP-800-53A - Assessing Security and Privacy Controls in

Information Systems and Organizations, 2021) Standard
A selection of
references for audit
(ISO, ISO/IEC 17021-1:2015 - Conformity assessment —
planning and
Requirements for bodies providing audit and certification of
assessment
management systems — Part 1: Requirements, 2015)
(ISO, ISO/IEC 17065:2012 - Conformity assessment — Requirements

for bodies certifying products, processes and services, 2012)
BCM (TMForum, 2021)
(ISO, ISO/IEC 27002:2013 - Information technology — Security Standard

techniques — Code of practice for information security controls, 2013) -
A selection of 12.3 Backup and 17 Information security aspects of business continuity
references for planning management
and implementing
48
March 2022
organisational and
technical resilience
Business continuity and crisis management standards
(ENISA, Report on Cyber Crisis Cooperation and Management, 2014)
(ISO, ISO 22300:2021 - Security and Resilience - Vocabulary, 2021)
(ISO, ISO 22301:2019 - Security and Resilience — Business continuity

management systems — Requirements, 2019)
(ISO, ISO 22313:2020 - Security and resilience — Business continuity

management systems — Guidance on the use of ISO 22301, 2020)
(ISO, ISO 22317:2015 - Societal security — Business continuity

management systems — Guidelines for business impact analysis (BIA),
2015)

management systems — Guidelines for business continuity strategy,
2018)

management systems — Guidelines for developing business continuity
plans and procedures, 2021)
NIST SP800-160 Developing Cyber-Resilient Systems: A Systems

Security Engineering Approach
(NIST, White Paper - Framework for Improving Critical Infrastructure Guideline

Cybersecurity, 2018)
49
March 2022
A.6 DETAILED MAPPING

This section provides the detailed analysis of standardisation coverage derived from the 5G
domains and lifecycle.
The columns of this table are explained hereunder:
Security Applicable Reference to Coverage of Coverage of 5G Coverage of

measure documents the documents stakeholders technological lifecycle
taxonomy and functional processes
domains
List of the 5G The taxonomy of A group name to A group name A group name Lifecycle
security the reference designate designating referring to the processes
measures per documents. several literature stakeholders of 5G domains covered by the
security domain references the 5G covered by the literature
and objectives This column is identified as ecosystem literature identified. The
as defined in intended to keep matching (but covered by the identified. The lifecycle
Section 2.1.4 5G the reader not necessary literature 5G domains are processes are
Security aware of what fulfilling) the identified. The grouped provided in
domains, the literature purpose of the group names according to Section 2.1.2
objectives and group is about. security are described in Annex 6.A.3 Technology
measures. A standard and measure. The Annex 6.A.4 referencing the lifecycle
a specification group names referencing the 5G technical processes.
tend to express are described in stakeholders and functional
‘What to do’ or Annex 6.A.5 domains
The detailed ‘Security referencing the
mapping features’, existing
distinguishes whereas a literature
general security guideline tends
measures and to provide
5G-specific elements on the
ones. ’How to
implement
security’, closer
to
considerations
of the build and
the run.
This is described
in Section 2.2
Taxonomy of
Documents
Considered
The conventions for the comments used in the detailed analysis are as follows.
‘All’: the reference document is considered applicable to every entity in the ecosystem, at
various degrees and at different depths. The specific degree or depth of applicability to each
entity are not assessed here.
‘Not put into context and not immediately actionable’ means that the reference document is
generic and may be applied to the entity. Further work is required to tailor it to the specific
context.
The coverage of the references has been assessed by considering how they can be used to
serve given security measures. When the reference only mentions the security measure without
providing a specific relevant tool for its implementation, the reference is not mentioned.
50
March 2022
D1 - GOVERNANCE AND RISK MANAGEMENT
SO 1 - Information security policy
Applicable Reference to Coverage of 5G

Coverage of Coverage of
Security measure documents the technological and
stakeholders lifecycle processes
taxonomy documents functional domains
Set a high-level security

policy addressing the Standard All (high level)
security of networks and ISOIEC27K All except All (high level)
services. Guideline opensource IT Security
RM community detailed but not put
Make key personnel aware in 5G context
of the security policy.
Set detailed information

security policies for critical
assets and business
processes. All (but not put into All (but not put into
Standard ISOIEC27K All except
context and not context and not
Make all personnel aware of opensource
Guideline SP800HR immediately immediately
the security policy and what community
actionable) actionable)
it implies for their work.
Review the security policy
following incidents.
Review the information

security policies
periodically, and take into
All (but not put into All (but not put into
account violations, All except
context and not context and not
exceptions, past incidents, Standard ISOIEC27K opensource
immediately immediately
past tests/exercises, and community
incidents affecting other
(similar) providers in the
sector.
51
March 2022
SO 2 - Governance and risk management
Coverage of
Applicable 5G Coverage of
Reference to Coverage of
Security measure documents technological lifecycle
the documents stakeholders
domains
Make a list of the main risks for
security of networks and services,
ISOIEC27K
taking into account the main threats All (but not put All (but not put
Standard RM, All except
for critical assets. into context and into context and
Guideline ENISATL opensource
not immediately not immediately
Report SP800HR community
Make key personnel aware of the actionable) actionable)
main risks and how they are
mitigated.
Set up a risk management

methodology and/or tools based on
industry standards.
All (but not All (but not
Ensure that key personnel use the Standard ISOIEC27K put into put into
All except
risk management methodology and Guideline RM context and context and
opensource
tools. Report ENISATL not not
community
SP800HR immediately immediately
Review the risk assessments actionable) actionable)
following changes or incidents.
Ensure residual risks are accepted
by management.
Review the risk management ISOIEC27K

Standard All except
methodology and/or tools, RM
Guideline opensource All All
periodically, taking into account ENISATL
Report community
changes and past incidents.
Coverage of
5G specific check documents technological lifecycle
the documents Stakeholders
domains
Is the list of identified risks aligned
All except
with the main risks for 5G networks Guideline RM
opensource All All
identified in the Coordinated risk Report ENISATL
community
assessment?
Are threats related to the exposure Need to be

to potentially high-risk suppliers or implemented
Guideline
managed service providers, RM according to Build and
Standard Telecom
including those residing in other ISOIECSUPL Member Run
jurisdictions, taken in States’
consideration? provisions
Has a potential dependency on a

single supplier of 5G equipment Guideline All except
RM Build and
been considered when assessing Standard opensource All
ISOIECSUPL Run
the main risks for security of community
networks and services?
52
March 2022
SO 3 - Security roles and responsibilities
Applicable Coverage of
Reference to Coverage of Coverage of
Security measure documents lifecycle
the documents stakeholders 5G domains
taxonomy processes
Assign security roles and
responsibilities to personnel.
Standard ISOIEC27K Telecom and
All All
Make sure the security roles are Guideline SP800HR DCSP
reachable in case of security
incidents.
Personnel is formally appointed in
security roles.
Guideline
SP800HR All All All
Make personnel aware of the
security roles in your organisation
and when they should be contacted.
Structure of security roles and
responsibilities is regularly reviewed
Guideline SP800HR All All All
and revised, based on changes
and/or past incidents.
SO 4 - Security of third-party dependencies
Coverage of 5G
Applicable Coverage
Reference to the Coverage of technological and
Security measure documents of lifecycle
documents stakeholders functional
taxonomy processes
domains
Include security requirements in All (but not put into

contracts with third-parties, ISOIEC27K SC, Telecom context and not Build and
Standard
including confidentiality and secure SUPPLSEC and DCSP immediately Run
transfer of information. actionable)
Set a security policy for contracts

with third-parties.
Ensure that all procurement of

services/products from third-parties
follows the policy.
All (but not put
Review security policy for third
ISOIEC27K SC, Telecom into context and Build and
parties, following incidents or Standard
SUPPLSEC and DCSP not immediately Run
changes.
actionable)
Demand specific security standards
in third-party supplier’s processes
during procurement.
Mitigate residual risks that are not

addressed by the third party.
Keep track of security incidents

related to or caused by third-parties.
All (but not put
ISOIEC27K SC, Telecom into context and
Periodically review and update Standard Run
SUPPLSEC and DCSP not immediately
security policy for third parties at
actionable)
regular intervals, taking into account
past incidents, changes, etc.
53
March 2022
Coverage of
Security measure (5G-specific) documents technological lifecycle
domains
Does the MNO have security
requirements placed on third parties All (but not put
as part of contractual arrangements ISOIEC27K Telecom and into context and
Standard Build and Run
and is there a mechanism to SUPPLSEC DCSP not immediately
monitor that suppliers are meeting actionable)
said contractual arrangements?
Does the MNO require suppliers to

comply with relevant EU
certification schemes for 5G
All (but not put
network components, customer
ISOIEC27K Telecom and into context and
equipment and/or suppliers’ Standard Build and Run
SUPPLSEC DCSP not immediately
processes or for other non 5G-
actionable)
specific ICT products and services,
such as end-user devices and/or
cloud services?

All (but not put
demonstrate the quality level of
into context
internal information security ISOIEC27K Telecom and
Standard and not Build and Run
processes, including having security SUPPLSEC DCSP
immediately
by design built in the product
actionable)
development process?
All (but not put
into context
adhere to best practices and ISOIEC27K Telecom and
industry standards throughout the SUPPLSEC DCSP
immediately
lifetime of the product?
actionable)
All (but not put
into context
provide support for periodic security ISOIEC27K Telecom and
and penetration testing of its SUPPLSEC DCSP
immediately
products?
actionable)

All (but not put
guarantee there are no intentionally
into context
introduced vulnerabilities in their ISOIEC27K Telecom and
products and to disclose and patch SUPPLSEC DCSP
immediately
any known vulnerabilities in their
actionable)
products without undue delay?
Does the MNO require suppliers to All (but not put
have implemented the security into context
ISOIEC27K Telecom and
requirements of relevant 5G Standard and not Build and Run
SUPPLSEC DCSP
technical specifications and industry immediately
standards by default? actionable)
guarantee adequate protection and All (but not put
non-disclosure of confidential into context
ISOIEC27K Telecom and
information from or about its Standard and not Build and Run
SUPPLSEC DCSP
customers to third parties, in immediately
particular to foreign intelligence or actionable)
security authorities?
All (but not
put into
Does the MNO require its suppliers
ISOIEC27K Telecom and context and
to support the MNO in investigating Standard Build and Run
SUPPLSEC DCSP not
and remedying security incidents?
immediately
actionable)
54
March 2022
D2 - HUMAN RESOURCES SECURITY
SO 5 - Background checks
Coverage of
5G
Applicable Reference to Coverage of
Coverage of technological
Security measure documents the lifecycle
stakeholders and
taxonomy documents processes
functional
domains
All (but not put
Check professional references
into context
of key personnel (system Standard ISOIEC27K Telecom and
and not All
administrators, security officers, Guideline SP800HR DCSP
immediately
guards, etc.).
actionable)
Perform background
All (but not
checks/screening for key
put into
personnel, when needed and
Standard ISOIEC27K Telecom context and
legally permitted. All
Guideline SP800HR and DCSP not
immediately
Set up a policy and procedure
actionable)
for background checks.
Review and update All (but not
policy/procedures for put into
background checks and Standard ISOIEC27K Telecom context and
All
reference checks at regular Guideline SP800HR and DCSP not
intervals, taking into account immediately
changes and past incidents. actionable)
Coverage of
Applicable Reference to 5G Coverage of
Coverage of
Security measure (5G-specific) documents the technological lifecycle
stakeholders
taxonomy documents and functional processes
domains
Does the list of personnel for All (but not put
whom background checks or into context
Standard ISOIEC27K Telecom and
screening have been performed and not All
Guideline SP800HR DCSP
also include contractors and immediately
third-party suppliers? actionable)
Are personnel who will have

access (either physically or All (but not
through management systems) put into
Standard ISOIEC27K
to critical or sensitive Telecom context and
IAM All
components of 5G networks and DCSP not
Guideline SP800HR
security-vetted (as stipulated in immediately
the provisions of the Toolbox actionable)
technical measure TM06)?
55
March 2022
SO 6 - Security knowledge and training
Applicable Reference to Coverage of 5G Coverage of

Coverage of
Security measure documents the technological and lifecycle
stakeholders
taxonomy documents functional domains processes
All (but not put into

Provide key personnel with relevant
Standard ISOIEC27K Telecom and context and not
training and material on security All
Guideline SP800HR DCSP immediately
issues.
actionable)
Implement a program for training,

making sure that key personnel
have sufficient and up-to-date
All (but not put
security knowledge.
Standard ISOIEC27K Telecom and into context and
All
Guideline SP800HR DCSP not immediately
Organise trainings and awareness
actionable)
sessions for personnel on security
topics important for your
organisation.
Review and update the training

programme periodically, taking into
All (but not put
account changes and past
Standard ISOIEC27K Telecom and into context and
incidents. All
Guideline SP800HR DCSP not immediately
actionable)
Test the security knowledge of
personnel.
Applicable Reference to Coverage of 5G Coverage

Coverage of
Security measure (5G-specific) documents the technological and of lifecycle
stakeholders
All (but not put into
Has the training programme been
Telecom and context and not
updated to include coverage of Guideline SP800HR All
DCSP immediately
specialised 5G technical topics?
actionable)
Is there an evidence that the key
All (but not put
personnel who will be in charge of
Telecom and into context and
deploying and operating 5G Guideline SP800HR All
DCSP not immediately
networks have followed the updated
actionable)
training courses?
Is there an evidence that the
personnel who will have access
(either physically or through All (but not put
management systems) to critical or Guideline SP800HR Telecom and into context and
All
sensitive network components are Standard IAM DCSP not immediately
trained and qualified (as stipulated actionable)
in the provisions of the Toolbox
technical measure TM06)?
56
March 2022
SO 7 - Personnel changes
Coverage of
domains
Following changes in personnel

revoke access rights, badges,
equipment etc., if no longer All (but not put
Standard ISOIEC27K
necessary or permitted. Telecom and into context and
IAM All
DCSP not immediately
Guideline SP800HR
Brief and educate new personnel on actionable)
the policies and procedures in
place.
Implement policy/procedures for

personnel changes, taking into
All (but not put
account timely revocation of access
Standard ISOIEC27K into context
rights, badges and equipment. Telecom and
IAM and not All
DCSP
Guideline SP800HR immediately
actionable)
education and training for personnel
in new roles.
Periodically check that the

policy/procedures are effective. All (but not put
Standard ISOIEC27K into context
Telecom and
Review and evaluate IAM and not All
DCSP
policy/procedures for personnel Guideline SP800HR immediately
changes, taking into account actionable)
changes or past incidents.
SO 8 - Handling violations
Coverage of
domains
Hold personnel accountable for All (but not put All (but not put
security incidents caused by Standard ISOIEC27K into context and into context and
All
violations of policies, for example Guideline SP800HR not immediately not immediately
via the employment contract. actionable) actionable)

put into put into
Set up procedures for violations of Standard ISOIEC27K context and context and
All
policies by personnel. Guideline SP800HR not not

put into put into
Periodically review and update the
Standard ISOIEC27K context and context and
disciplinary process, based on All
Guideline SP800HR not not
changes and past incidents.
57
March 2022
D3 - SECURITY OF SYSTEMS AND FACILITIES
SO 9 - Physical and environmental security
Coverage of 5G
Coverage of technological and
stakeholders functional
domains
Prevent unauthorised physical

access to facilities and set up
All except anything
adequate environmental controls, to SC, Telecom
Guideline PHYSEC outside a Run
protect provider assets against and DCSP
datacentre facility
unauthorised access, burglary, fire,
flooding, etc
Implement a policy for physical

security measures and
environmental controls.
All except
Industry standard implementation of SC, Telecom anything outside
Guideline PHYSEC Run
physical and environmental and DCSP a datacentre
controls. facility
Apply reinforced controls for

physical access to critical assets.
Evaluate the effectiveness of

physical and environmental controls
periodically.
All except
SC, Telecom anything outside
Review and update the policy for Guideline PHYSEC Run
and DCSP a datacentre
physical security measures and
facility
environmental controls taking into
incidents.

Coverage of
stakeholders
Are there documented, additional,

risk-based controls for physical
SC, Telecom
security for MEC and base stations Guideline PHYSEC MEC All
and DCSP
included in the policy for physical
security measures?
Are there documented additional,

adequate physical infrastructure
controls (for example perimeter
security for infrastructure and
SC, Telecom Physical
administrative premises, alarms and Guideline PHYSEC All
and DCSP infrastructure
CCTV for detecting and recording
incidents), especially for equipment
locations which are unmanned, in
place?
Are there any controls in place to

allow failsafe remote shutdown (or
data clearing) for stolen equipment
and/or to require re-authentication Guideline PHYSEC All
or configuration after a physical
attack or power failure at base
stations?
58
March 2022
Is there evidence that access

controls are in place for individuals
accessing premises, including
assurance that they are security- Guideline PHYSEC SC, Telecom Physical
All
vetted, trained and qualified and Standard IAM and DCSP infrastructure
that any access, especially by third
parties and contractors, is strictly
monitored?
Do physical security controls

included in the policy for physical
security measures cover (multi- Guideline PHYSEC All
vendor) spare part management, at
least for critical assets?
59
March 2022
SO 10 - Security of supplies
Coverage of 5G
Applicable Reference to Coverage
Coverage of technological and
Security measure documents the of lifecycle
stakeholders functional
domains
Standard ISOIEC27K SC, Telecom Physical

Ensure security of critical supplies. All
Guideline PHYSEC and DCSP infrastructure
Implement a policy for security of

critical supplies.
Implement industry standard

security measures to protect critical Standard ISOIEC27K SC, Telecom Physical
All
supplies and supporting facilities Guideline PHYSEC and DCSP infrastructure
(e.g. passive cooling, automatic
restart after power interruption,
battery backup power, diesel
generators, backup fuel, etc.).
Implement state-of-the-art security

measures to protect critical supplies
(such as active cooling, UP, hot
standby power generators, SLAs
with fuel delivery companies,
redundant cooling and power
Standard ISOIEC27K SC, Telecom Physical
backup systems). All
Guideline PHYSEC and DCSP infrastructure
Review and update policy and
procedures to secure critical
supplies regularly, taking into
incidents.
60
March 2022
SO 11 – Access control to network and information systems
Applicable Coverage of 5G Coverage of

Security measure documents technological and lifecycle
taxonomy functional domains processes
Users and systems have unique IDs

and are authenticated before
accessing services or systems.
3GPP SC, Telecom
Specification All Think, Build
Implement logical access control IAM and DCSP
mechanism for network and
information systems to allow only
authorised use.
Implement policy for protecting

access to network and information
systems, addressing, for example,
roles, rights, responsibilities and
procedures for assigning and
revoking access rights.
Choose appropriate authentication Standard ISOIEC27K

mechanisms, depending on the IAM Think,
type of access. SC, Telecom Build,
All
and DCSP Run
Monitor access to network and
information systems, have a Guideline 3GPP
process for approving exceptions
and registering access violations.
Reinforce controls for remote

access to critical assets of network
and information systems by third
parties.

access control policies and
procedures, and implement cross Standard
ISOIEC27K
checks on access control SC, Telecom
IAM
mechanisms. and DCSP All All
Guideline
SECASSUR
Access control policy and access
control mechanisms are reviewed
and, when needed, revised.
Applicable Coverage of 5G Coverage

Security measure (5G-specific) documents technological and of lifecycle
Are there any additional strict

ISOIEC27K
network access controls applied
Standard IAM
according to the updated risk SC, Telecom
3GPP 33.501; All All
assessment that particularly and DCSP
Specification 33.517; 33.518;
considers 5G network architecture
33.519
elements?
Is there an evidence demonstrating

how the principle of least privilege is
applied (including the explanation
on how various rights in the ISOIEC27K SC, Telecom
Standard All All
network, such as access rights IAM and DCSP
between network functions, network
administrators’ rights and alike are
minimised)?
Is there an evidence showing how

ISOIEC27K SC, Telecom
the principle of segregation of Standard All All
IAM and DCSP
duties is applied?
61
March 2022
Is there an evidence that the access

control policy has been reviewed ISOIEC27K SC, Telecom
Standard All All
and revised in the context of IAM and DCSP
assessment of 5G risks?
Does the (revised) access control
policy include provisions for
restricting and/or strict controlling of
remote access by third parties, ISOIEC27K SC, Telecom
Standard All All
especially by suppliers or managed IAM and DCSP
service providers considered to be
high-risk or accessing the network
from outside of EU?
Do authentication mechanisms
implemented follow general good ISOIEC27K SC, Telecom
Standard All All
practices and industry standards for IAM and DCSP
strong authentication?
Are there controls in place to only

allow temporary access to third
parties and/or remote access and
that no permanent credentials are Standard All All
IAM and DCSP
granted (e.g. temporary or one-time
passwords, usable only for
designated tasks)?
Is there a centralised solution for

Privileged Access Management Standard All All
IAM and DCSP
(PAM) in place1?
62
March 2022
SO 12 - Integrity of network and information systems

Coverage of
stakeholders
Make sure that the software of

network and information systems is
not tampered with or altered, for
instance by using input controls and SC, Telecom
Guideline RM All Build, Run
firewalls. and DCSP
Check for malware on (internal)

network and information systems.
security measures, providing
defence-in-depth against the
tampering and altering of systems.
SC, Telecom
Guideline RM All All
and DCSP
Apply reinforced software integrity,
update and patch management
controls for critical assets in
virtualised networks.
Set up state-of-the-art controls to

protect the integrity of systems.
SC, Telecom
Guideline RM All All
Evaluate and review the and DCSP
effectiveness of measures to
protect the integrity of systems.

Coverage of
5G specific check documents the technological and of lifecycle
stakeholders
Do software patching procedures

follow industry standard best
practices for ensuring that software
SC, Telecom
products or components have not Standard VULN All RUN
and DCSP
been altered (e.g. appropriate
cryptographic methods for integrity
and authenticity protection)?
Are there documented and tested
processes for delivery and SC, Telecom
Standard VULN All RUN
implementation of security patches and DCSP
to vulnerable components?
Are there appropriate physical

protection mechanisms in place to
ensure that hardware products SC, Telecom
Standard VULN All RUN
have not been tampered with (e.g. and DCSP
physical security protection for
equipment transport)?
Are there specific timeframes for

applying security patches to
SC, Telecom
vulnerable components, particularly Standard VULN All RUN
and DCSP
in the case of high and critical
vulnerabilities?
63
March 2022
SO 13 - Use of encryption
Coverage of
Reference to the Coverage of
documents stakeholders
domains
Where appropriate to prevent

and/or minimise the impact of
ISOIEC27K
security incidents on users and on Standard SC, Telecom
3GPP33210 All All
other networks and services, Specification and DCSP
3GPP33501
encrypt data during its storage
and/or transmission via networks.
Implement encryption policy.

3GPP
SC,
Use industry standard encryption 3GPP33210 Think and
Specification Telecom All
algorithms and the corresponding 3GPP33501 Build
and DCSP
recommended lengths of CRYPTOTECH
encryption keys.
Review and update the encryption Build

policy. SC, Run should
3GPP
Specification Telecom All include
CRYPTOTECH
Use state-of-the-art encryption and DCSP lifecycle of
algorithms. certificates

Coverage of
Security measure (5G-specific) documents the technological and lifecycle
stakeholders
Is encryption applied for the Build

concealment and protection of Run should
SC, Telecom
customer security critical data, in Specification 3GPP33501 All include
and DCSP
particular the permanent user lifecycle of
identifiers? certificates
Build
Is encryption applied for the Run should
SC, Telecom
protection of signalling traffic Specification 3GPP All include
and DCSP
between operators? lifecycle of
certificates
Build
Is encryption applied for transport Run should
SC, Telecom
protection between network Specification 3GPP All include
and DCSP
functions? lifecycle of
certificates
Build
Is encryption applied for the
Run should
protection of the confidentiality of SC, Telecom
Specification 3GPP All include
user and signalling data between and DCSP
lifecycle of
user equipment and base stations?
certificates
64
March 2022
SO14 - Protection of security critical data
Coverage of
domains
Make sure that cryptographic key

material and secret authentication
information (including cryptographic Specification 3GPP
key material used for
SC, Telecom
authentication) are not disclosed or Specification CRYPTOTECH All All
and DCSP
tampered with.
Guideline SECASSUR
Access to private keys is strictly
controlled and monitored.
Implement policy for management

Specification 3GPP
of cryptographic keys. SC,
Specification CRYPTOTECH
Telecom All All
Implement policy for management and DCSP
Guideline SECASSUR
of user passwords.
Review and update key

Specification 3GPP
management policy. SC,
Specification CRYPTOTECH
Telecom All All
Review and update user password and DCSP
Guideline SECASSUR
management policy.
Coverage of
Coverage of
stakeholders
domains
Are there appropriate controls in
place, according to best practices, Specification eUICC
Telecom eUICC Think
for the protection of cryptographic Guideline SECASSUR
key material in UICC (or eUICC)?
Are appropriate controls in place,
3GPP33501;
according to best practices, for the
SECASSUR;
protection of cryptographic key Specification Telecom RAN All
NFVSEC
material for encryption of subscriber
SCP
permanent identifiers (SUPI)?
place, according to best practices,
3GPP33501;
for the protection of any other
SECASSUR;
cryptographic key material used to Specification Telecom All All
NFVSEC
encrypt communication between
SCP
network elements or between
different networks?

place for the protection of VNF
Specification NFVSEC Telecom All All
private keys to authenticate NF
exchanges in the 5G core network?
Where cryptographic key material is

stored on third party key servers,
are appropriate contractual
Specification NFVSEC Telecom All All
arrangements in place with the
server provider to ensure security of
this key material?
65
March 2022
D4 - OPERATIONS MANAGEMENT
SO 15 - Operational procedures

Set up operational procedures and All (needs an

SP, Telecom, All (needs an effort
assign responsibilities for the Standard ISOIEC20K effort to put
DCSP to put into context)
operation of critical systems. into context)
Implement a policy for the operation All (needs

All (needs an
of systems to make sure all critical SP, Telecom, an effort
Standard ISOIEC20K effort to put into
systems are operated and managed DCSP to put into
context)
in line with predefined procedures. context)
Review and update the All (needs

All (needs an
policy/procedures for the operation SP, Telecom, an effort
of critical systems, taking into DCSP to put into
context)
account incidents and/or changes. context)
SO 16 - Change management
Coverage of 5G
Reference to Coverage of technological and
the documents stakeholders functional
taxonomy processes
domains
Follow predefined methods or All (needs an

SP, Telecom, All (needs an effort
procedures when making changes Standard ISOIEC20K effort to put
DCSP to put into context)
to critical systems into context)

change management, to make sure
that changes of critical systems are
always done following a predefined All (needs
SP, All (needs an
way. an effort to
Standard ISOIEC20K Telecom, effort to put into
put into
DCSP context)
Document change management context)
procedures, and record for each
change the steps of the followed
procedure.
Review and update change All (needs
SP, All (needs an
management procedures regularly, an effort to
Standard ISOIEC20K Telecom, effort to put into
taking into account changes and put into
DCSP context)
past incidents. context)
66
March 2022

Are there regular assessments of

the potential impact of an intended All (needs
change prior to major system SP, Telecom, All (needs an effort an effort to
Standard ISOIEC20K
changes, especially when critical or DCSP to put into context) put into
sensitive network components are context)
about to be updated?
Is there a mechanism in place to

ensure that any major actual
change implemented, especially for All
critical or sensitive network (needs
All (needs an
components, is recorded and any SP, Telecom, an effort
irregularities encountered during the DCSP to put
context)
change process are investigated into
and, if incident reporting conditions context)
are met, reported to competent
authorities?
Are changes to a virtualised All

network environment (e.g. through (needs
All (needs an
patching of software defined SP, Telecom, an effort
network components) included in DCSP to put
context)
the change management policies into
and procedures? context)
Has the MNO given consideration

to moving to software development All
lifecycle best practices such as (needs
All (needs an
Agile, Continuous SP, Telecom, an effort
Integration/Continuous DCSP to put
context)
Development (CI/CD), and into
DevSecOps, given 5G’s shift to a context)
software based network?
67
March 2022
SO 17 - Asset management

All (needs
Identify critical assets and SP, Telecom, All (needs an effort an effort to
Standard ISOIEC20K
configurations of critical systems. DCSP to put into context) put into
context)
All (needs
Implement policy/procedures for All (needs an
SP, Telecom, an effort
asset management and Standard ISOIEC20K effort to put into
DCSP to put into
configuration control. context)
context)
Review and update the asset All (needs

All (needs an
management policy regularly, SP, Telecom, an effort
based on changes and past DCSP to put into
context)
incidents. context)

Coverage of
stakeholders
Is asset criticality assessment

aligned with the list of critical assets
Guideline RM, NFVSEC SP, Telecom All Run
identified in the Coordinated risk
assessment?
Has the MNO established relevant
information repositories/registries
containing details about deployed
RM,
technologies and components and Guideline SP, Telecom All Run
NFVSEC
are such registries appropriately
maintained (e.g. timely updates
upon changes to the network)?
Are there mechanisms envisaged in

the MNO policies/procedures for
asset management for conducting
regular assessments of their
physical assets and for
categorisation of their physical
RM,
network assets (e.g. core network Guideline SP, Telecom All Run
NFVSEC
assets, transmission hubs,
exchanges, base-stations,
interconnection and transport links)
based on a risk assessment and
according to the assets
sensitivity/criticality.
Have policies/procedures for asset
management been updated to
reflect the fact that 5G networks will
likely be virtualised, with VNFs
being instantiated and
RM,
decommissioned in an automated Guideline SP, Telecom All Run
NFVSEC
way and do such updates include
sufficient provisions to ensure good
understanding of the virtual
network, including data flows, trust
domains and the location and status
68
March 2022
of the physical hosts on which the

virtual network resides?
D5 INCIDENT MANAGEMENT
SO 18 - Incident management procedures

Make sure personnel is available

and prepared to manage and
ISOIEC27K SC, Telecom,
handle incidents. Standard All Run
ISOIEC20K DSCP
Keep a record of all major incidents.
Implement policy/procedures for ISOIEC27K SC, Telecom,

Standard All Run
managing incidents. ISOIEC20K DSCP
Investigate major incidents and

draft final incident reports, including
actions taken and
recommendations to mitigate future
occurrence of this type of incident. Standard All Run
ISOIEC20K DSCP
Evaluate incident management
policy/procedures based on past
incidents.
69
March 2022
SO 19 - Incident detection capability

Security Measure documents technological and lifecycle
Set up processes or systems for Standard ISOIEC27K SC, Telecom,

All Run
incident detection. Guideline THREATMOD DSCP

systems and procedures for
incident detection.
Standard ISOIEC27K SC, Telecom,
All Run
Implement systems and procedures Guideline THREATMOD DSCP
for registering and forwarding
incidents timely to the appropriate
people.
Review systems and processes for

incident detection regularly and
update them taking into account
changes and past incidents. Standard ISOIEC27K SC, Telecom,
All Run
Guideline THREATMOD DSCP
Implement state-of-the-art systems
and procedures for incident
detections

Security measure (5G-specific) documents technological and lifecycle
Are relevant logs related to remote

network access regularly reviewed Standard ISOIEC27K SC, Telecom,
All Run
according to predefined Guideline THREATMOD DSCP
procedures?
Are there capabilities for anomaly Standard ISOIEC27K SC, Telecom,

All Run
detection in place? Guideline THREATMOD DSCP
Is the monitoring infrastructure

implemented according to the
recommendation from Toolbox,
Standard ISOIEC27K SC, Telecom,
including whether such monitoring All Run
Guideline THREATMOD DSCP
infrastructure is established on
premises, ideally inside the country
or inside the EU?
Does the MNO have adequate
resources available to monitor, Standard ISOIEC27K SC, Telecom,
All Run
understand and analyse security- Guideline THREATMOD DSCP
related network activity?
70
March 2022
SO 20 - Incident reporting and communication
Coverage of 5G
Reference to Coverage of technological
the documents stakeholders and functional
taxonomy processes
domains
Communicate and report about on-

going or past incidents to third
parties, customers, and/or Standard All Run
BCM DSCP
government authorities, when
necessary.
Implement policy and procedures

for communicating and reporting Standard All Run
BCM DSCP
about incidents.
Evaluate past communications and

reporting about incidents.
Standard All Run
Review and update the reporting BCM DSCP
and communication plans, based
on changes or past incidents.
Coverage of 5G
Security measure (5G-specific) documents lifecycle
the documents stakeholders and functional
taxonomy processes
domains
Does the MNO comply with relevant

incident reporting provisions within Standard All Run
BCM DSCP
a given legal framework?
71
March 2022
D6 - BUSINESS CONTINUITY MANAGEMENT
SO 21- Service continuity strategy and contingency plans

Coverage of
stakeholders
All (but not put into All (but not put

Implement a service continuity
SC, Telecom, context and not into context and
strategy for the communications Standard BCM
DCSP immediately not immediately
networks and/or services provided.
Implement contingency plans for
critical systems.
All (but not
Monitor activation and execution of
All (but not put put into
contingency plans, registering
SC, Telecom, into context and context and
successful and failed recovery Standard BCM
DCSP not immediately not
times.
actionable) immediately
actionable)
Implement contingency plans for
dependent and inter-dependent
critical sectors and services.
Review and revise service All (but not
continuity strategy periodically. All (but not put put into
SC, Telecom, into context and context and
Standard BCM
Review and revise contingency DCSP not immediately not
plans, based on past incidents and actionable) immediately
changes. actionable)

Coverage of
Security measure (5G-specific) documents the technological and lifecycle
stakeholders
Are there measures in place to

ensure supply-chain resilience (e.g.
by ensuring that contingency plans All (but not put into All (but not put
consider scenarios of removal of SC, Telecom, context and not into context and
Standard BCM
critical suppliers, understanding the DCSP immediately not immediately
related impact and having actionable) actionable)
appropriate failback strategies in
place)?
Are there any special provisions

added to existing contingency plans All (but not put into All (but not put
to cover time-critical applications of SC, Telecom, context and not into context and
Standard BCM
5G services, such as URLLC as to DCSP immediately not immediately
ensure higher network availability actionable) actionable)
for such services?
Is there a map of critical

dependencies that may directly or
indirectly impact availability or
continuity of 5G network services Standard BCM
and if corresponding mitigation
measures are defined and
documented?
Is there a map of critical sectors
and services directly dependent on All (but not put into All (but not put
the continuity of network and SC, Telecom, context and not into context and
Standard BCM
service operations and if criticality DCSP immediately not immediately
of such systems is taken in actionable) actionable)
consideration in contingency plans?
72
March 2022
SO 22 - Disaster recovery capabilities
Coverage of
domains
All (but not put All (but not put

Prepare for recovery and
SC, Telecom, into context and into context and
restoration of services following Standard BCM
DCSP not immediately not immediately
disasters.

deploying disaster recovery
capabilities.
put into put into
SC,
context and context and
Implement industry standard Standard BCM Telecom,
not not
disaster recovery capabilities, or be DCSP
assured they are available from
third parties (such as national
emergency networks).
Set up state-of-the-art disaster

recovery capabilities to mitigate
natural and/major disasters.
put into put into
SC,
context and context and
Review and update disaster Standard BCM Telecom,
not not
recovery capabilities regularly, DCSP
taking into account changes, past
incidents and the results of tests
and exercises.

Coverage of
stakeholders
All (but not
Are there documented plans in All (but not put into put into
place in case of a disaster affecting SC, Telecom, context and not context and
Standard BCM
the ongoing operation of the MNO’s DCSP immediately not
network? actionable) immediately
actionable)
73
March 2022
D7 - MONITORING, AUDITING AND TESTING
SO 23 - Monitoring and logging policies

Security measure documents technological and of lifecycle
Implement monitoring and logging SP, Telecom, All (needs to be put

Guideline THREATMOD Run
of critical systems. DCSP into context)
Implement a policy for the logging

and monitoring of critical systems.
Set up tools for monitoring critical SP, Telecom, All (needs to be

systems. DCSP put into context)
Set up tools to collect and store

logs of critical systems.
Set up tools for the automated

collection and analysis of
monitoring data and logs.
SP, Telecom, All (needs to be
Review and update logging and DCSP put into context)
monitoring policy/procedures, taking
into account changes and past
incidents.

Are there adequate monitoring

capabilities in place in line with
recommendations from the Toolbox
technical measures TM05, to
ensure clear visibility and to
implement effective network
SP, Telecom, All (needs to be put
monitoring of at least the critical or Guideline THREATMOD Run
DCSP into context)
sensitive network components or
functions, to detect anomalies and
to identify and avoid threats
including but not limited to threats
to 5G core coming from
compromised end-user devices?
Does the monitoring and logging

policy also include monitoring of SP, Telecom, All (needs to be put
VPN and remote access to the 5G DCSP into context)
network from remote locations?
Is there monitoring in place for

roaming and interconnections (e.g.
message monitoring and filtering
capabilities to identify and block
malformed, prohibited and
unauthorised packets, to confirm SP, Telecom, All (needs to be put
that interfaces are only accessible DCSP into context)
to the correct external applications
and/or networks and to enable audit
logging and delivery of data to
SIEM for analysis for relevant threat
vectors)?
74
March 2022
SO 24 - Exercise contingency plans

Coverage of
stakeholders
Exercise and test backup and

contingency plans to make sure
systems and processes work and Standard BCM
personnel is prepared for large
failures and contingencies.
Implement a programme for

exercising backup and contingency
plans regularly, using realistic
scenarios covering a range of All (but not
different scenarios over time. All (but not put into put into
SC, Telecom, context and not context and
Standard BCM
Make sure that the issues and DCSP immediately not
lessons learnt from exercises are actionable) immediately
addressed by the responsible actionable)
people and that the relevant
processes and systems are
updated accordingly.
Review and update the exercise

plans, taking into account changes,
All (but not
past incidents and contingencies
All (but not put into put into
which were not covered by the
SC, Telecom, context and not context and
exercise programme. Standard BCM
DCSP immediately not
actionable) immediately
Involve suppliers and other third
actionable)
parties in exercises, for example,
business partners and customers.
75
March 2022
SO 25 - Network and information systems testing
Coverage of
5G
the documents stakeholders and
taxonomy processes
functional
domains
Test networks and information
systems before using them or SC, Telecom,
Standard DEVSECOPS All BUILD
connecting them to existing DCSP
systems.
testing network and information
SC,
systems.
Standard DEVSECOPS Telecom, All BUILD
DCSP
Implement tools for automated
testing.
Review and update the
DEVSECOPS SC,
policy/procedures for testing, taking BUILD,
Standard ISOIEC27K Telecom, All
into account changes and past RUN
DCSP
incidents.

Security measure (5G-specific) documents the lifecycle
stakeholders 5G domains
Are all patches, especially those to
critical or sensitive network
SC, Telecom,
components or functions, subjected Standard VULN All RUN
DCSP
to security testing in a controlled
environment prior to deployment?
76
March 2022
SO 26 - Security assessments
taxonomy processes
Ensure critical systems undergo

security scans and security testing DEVSECOPS
SC, Telecom,
regularly, particularly when new Standard ISOIEC27K All BUILD, RUN
DCSP
systems are introduced and VULN
following changes.
Implement policy/procedures for DEVSECOPS SC,

BUILD,
security assessments and security Standard ISOIEC27K Telecom, All
RUN
testing. VULN DCSP

policy/procedures for security
assessments and security testing.
DEVSECOPS
SC,
ISOIEC27K BUILD,
Review and update Standard Telecom, All
VULN RUN
policy/procedures for security DCSP
SUPPL
assessments and security testing,
taking into account changes and
past incidents.
Security measure (5G-specific) documents lifecycle
the documents Stakeholders 5G domains
taxonomy processes
Are security tests, vulnerability
assessments/scans and penetration
tests done on deployment and DEVSECOPS
subsequently, on a periodic basis, ISOIEC27K SC, Telecom,
Standard All BUILD, RUN
for newly deployed network VULN DCSP
components, in particular for SUPPL
products supplied by suppliers
considered to be high-risk?
77
March 2022
SO 27 - Compliance monitoring
Coverage of
5G
Coverage of technological
stakeholders and
functional
domains
All (needs
Monitor compliance to standards and ISOIEC27K SC, Telecom,
Standard effort to be put Run
legal requirements. BCM DCSP
into context)
All (needs
SC,
Implement policy/procedures for ISOIEC27K effort to be
Standard Telecom, Run
compliance monitoring and auditing. BCM put into
DCSP
context)
Evaluate the policy/procedures for

compliance and auditing.
All (needs
SC,
ISOIEC27K effort to be
Review and update the Standard Telecom, Run
BCM put into
policy/procedures for compliance and DCSP
context)
auditing, taking into account changes
and past incidents.

Security measure (5G-specific) documents the lifecycle
stakeholders 5G domains
Is monitoring of compliance with relevant

5G standards (e.g. 3GPP, ETSI NFV2) 3GPP
Guideline Telecom All Run
included in the compliance monitoring ETSINFV
policies and procedures?
78
March 2022
D8 - THREAT AWARENESS
SO 28 - Threat intelligence
taxonomy processes
SC, Telecom,
Perform regular threat monitoring. Guideline THREATMOD All Run
DCSP
SC,
Implement a threat intelligence
Guideline THREATMOD Telecom, All Run
programme.
DCSP
Review and update the threat

intelligence programme.
SC,
Guideline THREATMOD Telecom, All Run
Threat intelligence programme
DCSP
makes use of state-of-the-art threat
intelligence systems.
Applicable Coverage Coverage of

Security measure (5G-specific) documents of 5G lifecycle
taxonomy domains processes
Does the threat monitoring and/or
threat intelligence programme
SC, Telecom,
include a variety of threats of Guideline THREATMOD All Run
DCSP
particular significance for 5G
networks?
Are relevant and current sources
and publications and/or relevant SC, Telecom,
Guideline THREATMOD All Run
CTI tools and platforms consulted DCSP
or used systematically?
79
March 2022
SO 29 - Informing users about threats
taxonomy processes
Inform end-users of communication

networks and services about
particular and significant security None None None None None
threats to a network or service that
may affect them.

regular update of end-users about
None None None None None
security threats to network or
service that may affect them.
Review and update the

policy/procedures for regular
update of end-users about security None None None None None
threats to the network or service
that may affect them.
Coverage of
Coverage of
stakeholders
domains
Are there mechanisms in place to
inform users about potentially
vulnerable end user devices, None None None None None
including IoT devices and of related
risks?
Has guidance been provided to

consumers and enterprises on
signalling threats in legacy network
environments (associated with SS7,
GTP and Diameter signalling
protocols) such as location tracking,
Guideline SECASSUR Telecom None Run
interception of data, call, e-mail and
SMS messages, financial fraud and
theft or digital identity theft and
highlighting the risk of using SMS
as a multi-factor authentication
mechanism?
80
TP-06-22-113-EN-N
ABOUT ENIS A
The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common
level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the
European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT
products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU
bodies and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building
and awareness raising, the Agency works together with its key stakeholders to strengthen trust in the connected
economy, to boost resilience of the Union’s infrastructure and, ultimately, to keep Europe’s society and citizens
digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu.
ISBN 978-92-9204-568-5
DOI 10.2824/700472

ENISA - 5G Standards

Uploaded by

Copyright:

Available Formats

ENISA - 5G Standards

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ENISA - 5G Standards

Uploaded by

Copyright:

Available Formats

5G

Erika Magonara, Sławomir Górniak – ENISA

ENISA maintains its intellectual property rights in relation to this publication.

ISBN 978-92-9204-568-5 DOI 10.2824/700472

1.1 DOCUMENT PURPOSE AND OBJECTIVES 8

1.2 OVERVIEW AND STRUCTURE OF THE STUDY 8

1.3 TARGET AUDIENCE AND PREREQUISITES 9

2. SCOPE, DEFINITIONS, AND CONVENTIONS 10

2.1 THE 5G ECOSYSTEM 10

2.1.1 5G technological and functional domains 10

2.2 TAXONOMY OF DOCUMENTS CONSIDERED 16

3. POSITIONING AND ASSESSMENT OF REFERENCE DOCUMENTS

3.1 METHODOLOGY FOR THE ASSESSMENT OF COVERAGE 18

3.2 CONSOLIDATED RESULTS 18

4. IDENTIFICATION OF GAPS IN STANDARDISATION 21

4.1 METHODOLOGY FOR THE IDENTIFICATION OF GAPS IN THE EXISTING LITERATURE 21

4.2 ASSESSMENT OF COVERAGE AND IDENTIFICATION OF GAPS IN STANDARDISATION 21

4.3 OVERVIEW OF GAPS BY SECURITY DOMAIN 27

4.4 OBSERVATIONS ON THE GAPS IN STANDARDISATION 29

4.5 ADDITIONAL LEARNINGS AND OBSERVATIONS 29

5.1 ADOPT A PROGRESSIVE APPROACH TO 5G STANDARDISATION 31

5.2 HAVE A BROADER VIEW ON THE CREATION OF NEW REFERENCES 31

5.3.1 ENISA’s methodology for sectoral cybersecurity assessment 32

5.4 FINAL OBSERVATIONS 32

A.1 DOCUMENT TYPOLOGIES DEFINED BY THE EU REGULATION 37

A.2 DOCUMENT TYPOLOGIES DEFINED BY ISO 37

A.3 REFERENCING THE 5G TECHNICAL AND FUNCTIONAL DOMAINS 39

A.4 REFERENCING THE STAKEHOLDERS 39

A.5 REFERENCING THE EXISTING LITERATURE 42

A.6 DETAILED MAPPING 50

D1 - GOVERNANCE AND RISK MANAGEMENT 51

SO 1 - Information security policy 51

D2 - HUMAN RESOURCES SECURITY 55

D3 - SECURITY OF SYSTEMS AND FACILITIES 58

SO 9 - Physical and environmental security 58

SO 18 - Incident management procedures 69

D6 - BUSINESS CONTINUITY MANAGEMENT 72

SO 21 - Service continuity strategy and contingency plans 72

SO 22 - Disaster recovery capabilities 73

D7 - MONITORING, AUDITING AND TESTING 74

SO 23 - Monitoring and logging policies 74

This report focuses on standardisation from a technical and organisational perspective.

Accordingly, this report:

• Collects standards, specifications and guidelines 1 relevant to the cybersecurity of the 5G

business continuity management and incident management) present major gaps in

Still, this report recommends the adoption of a progressive approach to 5G standardisation,

1.1 DOCUMENT PURPOSE AND OBJECTIVES

• to provide an overview of standards, specifications and guidelines 2 relevant to the

The document focuses on standardisation from a technical and organisational perspective.

1.2 OVERVIEW AND STRUCTURE OF THE STUDY

After having defined the ‘5G Ecosystem’, the document:

• formulates recommendations on standardisation in the area of 5G cybersecurity (Section 5

1.3 TARGET AUDIENCE AND PREREQUISITES

• ENISA, Guideline on Security Measures under the EECC, 2020,

An overview of the standardisation organisations active in 5G is contained in ENISA report

2. SCOPE, DEFINITIONS, AND

2.1 THE 5G ECOSYSTEM

Figure 1: The dimensions of the 5G ecosystem

Building blocks of the 5G Ecosystem Definitions

Essential functions of 5G networks and the related supporting