STANDARDS SUPPORTING CERTIFICATION
Analysis of Standards in Areas Relevant to the Potential EU Candidate Cybersecurity Certification Schemes
DECEMBER 2019
0
STANDARDS SUPPORTING CERTIFICATION December 2019
ABOUT ENISA
The mission of the European Union Agency for Cybersecurity (ENISA) is to achieve a high common level of cybersecurity across the Union, by actively supporting Member States, Union institutions, bodies, offices and agencies in improving cybersecurity. We contribute to policy development and implementation, support capacity building and preparedness, facilitate operational cooperation at Union level, enhance the trustworthiness of ICT products, services and processes by rolling out cybersecurity certification schemes, enable knowledge sharing, research, innovation and awareness building, whilst developing cross-border communities. Our goal is to strengthen trust in the connected economy, boost resilience of the Union’s infrastructure and services and keep our society cyber secure. More information about ENISA and its work can be found at www.enisa.europa.eu.
CONTACT For contacting the authors please use [email protected]. For media enquiries about this paper please use [email protected].
EDITORS Ioannis Agrafiotis, Dorin Bugneac, Slawomir Gorniak
AUTHORS Inigo Barreira, Hendrik Dettmer, Massimiliano Masi, Leire Orue Echevarria, Andreas Sfakianakis
LEGAL NOTICE Notice must be taken that this publication represents the views and interpretations of ENISA, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the Regulation (EU) No 2019/881. This publication does not necessarily represent state-of the-art and ENISA may update it from time to time.
Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication.
This publication is intended for information purposes only. It must be accessible free of charge. 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.
COPYRIGHT NOTICE © European Union Agency for Cybersecurity (ENISA), 2019 Reproduction is authorised provided the source is acknowledged.
Copyright for the image on the cover and on the internal pages: © Shutterstock 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-329-2, DOI 10.2824/40722
1
STANDARDS SUPPORTING CERTIFICATION December 2019
TABLE OF CONTENTS
1. INTRODUCTION 5
2. CYBERSECURITY ACT 6
3. INTERNET OF THINGS (IOT) 8
3.1 IOT LANDSCAPE 9 3.1.1 Eurosmart cybersecurity certification scheme for IoT 9 3.1.2 ETSI 303 645 12 3.1.3 Other relevant frameworks and suggestions 13
3.2 POTENTIAL CANDIDATE FOR A EUROPEAN IOT CYBERSECURITY CERTIFICATION SCHEME 14
4. ANALYSIS OF THE STANDARDS LANDSCAPE FOR CLOUD SERVICES 16
4.1 OVERVIEW OF LANDSCAPES 16
4.2 POTENTIAL CANDIDATE FOR AN EU CYBERSECURITY CERTIFICATION SCHEME FOR CLOUD 19
5. ANALYSIS OF THE STANDARDS LANDSCAPE FOR THREAT INTELLIGENCE-BASED FRAMEWORK 26
5.1 OVERVIEW OF THE TIBER-EU FRAMEWORK 26 5.1.1 History of Threat Intelligence-led Red Teaming Frameworks 26 5.1.2 Overview of TIBER-EU Framework 27
5.2 POTENTIAL CANDIDATE EUROPEAN CYBERSECURITY CERTIFICATION SCHEME 28 5.2.1 Gaps and opportunities for certification schemes 28 5.2.2 Security objectives of European cybersecurity certification scheme for TIBER-EU 29 5.2.3 Assurance levels of European cybersecurity certification scheme for TIBER-EU 30 5.2.4 Security requirements for the cybersecurity certification scheme for TIBER-EU 31 5.2.5 TIBER-EU certifications for individuals 34
6. ANALYSIS OF THE STANDARDS LANDSCAPE ON E- HEALTH RECORDS 36
6.1 OVERVIEW OF LANDSCAPE FOR EHR 36
6.2 POTENTIAL CANDIDATE CYBERSECURITY CERTIFICATION SCHEME FOR SHARING EHRS 38
2
STANDARDS SUPPORTING CERTIFICATION December 2019
6.2.1 Potential product/service or process that can be evolved to a cybersecurity certification scheme. 38 6.2.2 Assurance levels based on risk assessment 38 6.2.3 Potential rules/standards for the schemes 39
7. ANALYSIS OF THE STANDARDS LANDSCAPE IN RELATION TO QUALIFIED TRUST SERVICE PROVIDERS 42
7.1 OVERVIEW OF EIDAS REGULATION ON QUALIFIED TSP AND TRUST SERVICES 42 7.1.1 Initiation and supervision 43 7.1.2 TSP supervisory scheme 44
7.2 OVERVIEW OF STANDARDS’ LANDSCAPE 44 7.2.1 eIDAS Regulation requirements 44 7.2.2 ETSI certification scheme 45 7.2.3 WebTrust for CAs assurance audit 45 7.2.4 Cab Forum, CAs and browsers 45 7.2.5 ISO/IEC 27000 series 46 7.2.6 Identification of gaps in current practice to acquire a qualified status. 47
7.3 POTENTIAL CANDIDATE FOR A CYBERSECURITY CERTIFICATION SCHEME 48 7.3.1 Potential product/service or process that can be evolved to a cybersecurity certification scheme. 48 7.3.2 Identification of potential rules/standards for the schemes 48
8. CONCLUSIONS 50
REFERENCES 51
3
STANDARDS SUPPORTING CERTIFICATION December 2019
EXECUTIVE SUMMARY
In September 2017, the European Commission presented a proposal for a Regulation, dubbed the Cybersecurity Act, with a view to harmonise the current cybersecurity certification activities and policies across the Member States. ENISA has a pivotal role in this new EU cybersecurity certification framework, since it is tasked to prepare candidate schemes.
This report explores five distinct areas, which have frameworks, schemes or standards that can potentially be evolved to EU candidate cybersecurity certification schemes. These five areas are the Internet of Things (IoT), cloud infrastructure and services, threat intelligence in the financial sector, electronic health records in the healthcare and qualified trust services. This report reflects on standards currently available on these five areas of interest (i.e., Eurosmart IoT Certification scheme, SESIP, TIBER EU Framework) to identify gaps. It further proposes reasonable recommendations based on Articles 51, 52 and 54 of the CSA on how these gaps can be addressed and how the available standards could potentially be adapted to form the basis of future candidate EU cybersecurity certification schemes.
A key finding of this exercise is that for a potential EU candidate scheme to be successful, the levels of assurance should reflect the market needs. There are technical rules in standards that can provide the guiding principles for assurance levels in all five areas. Further investigation is required on how these rules will be allocated to different levels, specifically for technical metrics which are present in all three levels with variant objectives (e.g., time to perform patch management). In all five areas there are opportunities for products (smart home devices for Internet of Things area, test-beds for validating interoperability in the electronic heath records domain), processes (accreditation schemes to harmonise the process of providing a qualified status to Trust Service Providers) and services (penetration testing for the financial sector and cloud services such as Platform as a Service).
4
STANDARDS SUPPORTING CERTIFICATION December 2019
1. INTRODUCTION
In September 2017, the European Commission presented a proposal for a Regulation, dubbed the Cybersecurity Act (hereinafter CSA)1, with a view to harmonise the current cybersecurity certification activities and policies across the Member States. The CSA was published on 7th of June 20192 in the official EU journal and entered into force on the 27th of June 2019. The CSA follows on an array of legal instruments that compose the legal framework of the Digital Single Market. It further benefits from the framework on standardisation laid out by means of Regulation 1025/2012 and standardisation and provisions on conformity assessment laid out in Regulation 765/2008.
The CSA is a multi-layered Regulation that on the one hand addresses the updated ENISA mandate and on the other it lays out the EU cybersecurity certification framework. With regard to the latter, ENISA has been tasked with new competences, being to prepare candidate cybersecurity certification schemes. Furthermore, ENISA will assist the Commission in carrying out certain roles (e.g. in the European Cybersecurity Certification Group (ECCG), co-chair with the Commission the Stakeholders Cybersecurity Certification Group (SCCG)) that contribute to the overall process of designing European cybersecurity certification schemes.
This report provides an analysis of the landscape of standards in five distinct key areas, followed by recommendations on how these standards can be evolved to potential European cybersecurity certification schemes by reflecting on three articles of the CSA. The five key areas are the Internet of Things (IoT), cloud infrastructure and services, threat intelligence in the financial sector, electronic health records in the healthcare and qualified trust services. This report reflects on standards currently available in these five areas of interest (i.e., Eurosmart IoT Certification scheme3, SESIP, TIBER EU Framework4 with emphasis on identifying gaps and proposing reasonable recommendations based on Articles 51, 52 and 54 of CSA on how these standards could potentially be adapted to form the basis of future candidate cybersecurity certification schemes.
1 Regulation (EU) 2019/881 of the European Parliament and of the Council of 17 April 2019 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), PE/86/2018/REV/1. 2 See, http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52017PC0477 3 https://www.eurosmart.com/eurosmart-iot-certification-scheme/ 4 https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
5
STANDARDS SUPPORTING CERTIFICATION December 2019
2. CYBERSECURITY ACT
The EU cybersecurity certification framework defines a mechanism to establish European cybersecurity certification schemes and to attest that the ICT products, processes and services that have been evaluated in accordance with such schemes comply with specified security requirements. ENISA has a pivotal role in the design of the candidate EU cybersecurity certification schemes5. The CSA provides clear guidelines regarding how these schemes should be designed in the articles below:
Article 51 – Security objectives of European cybersecurity certification schemes Article 52 – Assurance levels of European cybersecurity certification schemes Article 54 – Elements of European cybersecurity certification schemes
Article 51 stipulates that any European cybersecurity certification scheme should be designed with strict security objectives, namely:
to protect stored, transmitted or otherwise processed data against accidental or unauthorised storage, processing, access or disclosure during the entire life cycle of the ICT product, ICT service or ICT process; to protect stored, transmitted or otherwise processed data against accidental or unauthorised destruction, loss or alteration or lack of availability during the entire life cycle of the ICT product, ICT service or ICT process; that authorised persons, programs or machines are able only to access the data, services or functions to which their access rights refer; to identify and document known dependencies and vulnerabilities; to record which data, services or functions have been accessed, used or otherwise processed, at what times and by whom; to make it possible to check which data, services or functions have been accessed, used or otherwise processed, at what times and by whom; to verify that ICT products, ICT services and ICT processes do not contain known vulnerabilities; to restore the availability and access to data, services and functions in a timely manner in the event of a physical or technical incident; that ICT products, ICT services and ICT processes are secure by default and by design; that ICT products, ICT services and ICT processes are provided with up-to-date software and hardware that do not contain publicly known vulnerabilities, and are provided with mechanisms for secure updates.
While Article 52 describes the assurance levels for a scheme and explains how these should be specified, article 54 is the cornerstone of a cybersecurity certification scheme because it describes the core elements that need to be present, namely:
the subject matter and scope of the certification scheme, including the type or categories of ICT products, ICT services and ICT processes covered; a clear description of the purpose of the scheme and of how the selected standards, evaluation methods and assurance levels correspond to the needs of the intended users of the scheme; references to the international, European or national standards applied in the evaluation or, where such standards are not available or appropriate, to technical specifications that meet the requirements set out in Annex II to Regulation (EU) No
5 Proposal for REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on ENISA, the "EU Cybersecurity Agency", and repealing Regulation (EU) 526/2013, and on Information and Communication Technology cybersecurity certification (''Cybersecurity Act''), ST 15786 2018 INIT.
6
STANDARDS SUPPORTING CERTIFICATION December 2019
1025/2012 or, if such specifications are not available, to technical specifications or other cybersecurity requirements defined in the European cybersecurity certification scheme; where applicable, one or more assurance levels; an indication of whether conformity self-assessment is permitted under the scheme; where applicable, specific or additional requirements to which conformity assessment bodies are subject in order to guarantee their technical competence to evaluate the cybersecurity requirements; the specific evaluation criteria and methods to be used, including types of evaluation, in order to demonstrate that the security objectives referred to in Article 51 are achieved; where applicable, the information which is necessary for certification and which is to be supplied or otherwise be made available to the conformity assessment bodies by an applicant; where the scheme provides for marks or labels, the conditions under which such marks or labels may be used; rules for monitoring compliance of ICT products, ICT services and ICT processes with the requirements of the European cybersecurity certificates or the EU statements of conformity, including mechanisms to demonstrate continued compliance with the specified cybersecurity requirements; where applicable, the conditions for issuing, maintaining, continuing and renewing the European cybersecurity certificates, as well as the conditions for extending or reducing the scope of certification; rules concerning the consequences for ICT products, ICT services and ICT processes that have been certified or for which an EU statement of conformity has been issued, but which do not comply with the requirements of the scheme; rules concerning how previously undetected cybersecurity vulnerabilities in ICT products, ICT services and ICT processes are to be reported and dealt with; where applicable, rules concerning the retention of records by conformity assessment bodies; the identification of national or international cybersecurity certification schemes covering the same type or categories of ICT products, ICT services and ICT processes, security requirements, evaluation criteria and methods, and assurance levels; the content and the format of the European cybersecurity certificates and the EU statements of conformity to be issued; the period of the availability of the EU statement of conformity, technical documentation, and all other relevant information to be made available by the manufacturer or provider of ICT products, ICT services or ICT processes; maximum period of validity of European cybersecurity certificates issued under the scheme; disclosure policy for European cybersecurity certificates issued, amended or withdrawn under the scheme; conditions for the mutual recognition of certification schemes with third countries; where applicable, rules concerning any peer assessment mechanism established by the scheme for the authorities or bodies issuing European cybersecurity certificates for assurance level ‘high’ pursuant to Article 56(6). Such mechanism shall be without prejudice to the peer review provided for in Article 59; format and procedures to be followed by manufacturers or providers of ICT products, ICT services or ICT processes in supplying and updating the supplementary cybersecurity information in accordance with Article 55
7
STANDARDS SUPPORTING CERTIFICATION December 2019
3. INTERNET OF THINGS (IOT)
This chapter analyses the cyber security certification landscape for IoT devices in the European Union focusing on two main standards or schemes (ETSI 303 6456 and Eurosmart IoT certification (Eurosmart, 2019)). Standards or other widely adopted technical specifications contain requirements that form the basis for any certification activity. European standards for security evaluation models, methods, techniques and tools adapted to the IoT world are needed urgently to complement existing initiatives, good practices and industry guidelines on IoT security.
ENISA defines the Internet of Things (IoT) as a cyber-physical ecosystem of interconnected sensors and actuators that enable decision making (ENISA, 2018). Information lies at the heart of IoT devices, feeding into a continuous cycle of sensing, decision-making, and actions. IoT is tightly bound to cyber-physical systems and in this respect is perceived as an enabler of Smart Infrastructures (e.g. Industry 4.0, smart grid, smart transport) by facilitating services of high quality and supporting the provision of advanced functionalities.
Given the abundance of IoT devices, the threat landscape is broad, therefore, the likelihood of an impactful attack is high. Although an attack on a small number of devices may not be problematic, an attack on a large-scale number of IoT devices that are distributed around the European Union can be utilised in larger attack-schemes. These larger attack-schemes may result in Distributed Denial of Service (DDoS) attacks or attacks on European Energy Grids (Soltan, Mittal, & Poor, 2018).
Figure 1: IoT Devices7
Given the broad range of IoT devices and their functionality, the focus of IoT device certification regarding security lies in the area of consumer IoT devices, coined as ‘Smart Home’ (ENISA, 2014). Other areas, such as Industry 4.0, automotive and medical devices, due to the sensitivity
6 Draft ETSI EN 303 64 V2, Cyber Security for Consumer Internet of Things, 2019 https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.00.00_20/en_303645v020000a.pdf 7 Figure: https://www.embedded-software-engineering.de/synopsis-schliesst-kooperation-mit-smic-und-brite-a-646277/
8
STANDARDS SUPPORTING CERTIFICATION December 2019
of the information they process or the criticality of the environment in which they are deployed, are heavily regulated.
For example, the industry 4.0 area is governed by a defined industry standard for security with the IEC 624438. The modular strategy of this standard allows the security evaluation and certification of components, systems and production environments. The medical device regulation (MDR9) includes requirements to ensure that all medical devices will integrate state- of-the-art security. Finally, the automotive industry is pioneering self-regulations systems. One example is the TISAX (ENX, 2019) standard; the regulation is driven by dominant automotive brands, which impose regulatory security requirements on their suppliers.
It is worth noting that regulation in the aforementioned areas does not focus on specific IoT certification standards. Increasing the security level of consumer IoT devices would complement regulatory security requirements for IoT devices which are utilised in these areas; the reason being that industrial applications often use off-the-shelf consumer products to solve problems in their niche area.
3.1 IOT LANDSCAPE
3.1.1 Eurosmart cybersecurity certification scheme for IoT Eurosmart is the first IoT certification scheme that was developed based on the requirements of the CSA. The first Eurosmart document describes the scope of the scheme as follows: “The scope of the Eurosmart IoT Security Certification Scheme (Eurosmart, 2019) is the “IoT Device” with a focus on the Substantial security assurance level as defined by the Cybersecurity Act. At this level of assurance, the certification intends to minimise the risks of successful attacks commonly taking advantage of poor design in IoT devices, which brings severe consequences to consumers and vendors, due to non-existent or ineffective security controls. It is indeed vital that IoT devices have security designed-in and verified-in from the outset. Since these IoT Devices at the low end of the range may have security features constrained by cost, available processing power and performance, size, type of power source, this Certification Scheme considers the trade- off between such constraints, the risks and the cost of certification.”
The Eurosmart scheme in its current version (November 2019) consists of nine documents, all with detailed descriptions. The first document provides the definition of a Security Profile. The use of Security Profiles similarly to the Security Target in a Common Criteria (CC) certification is in principle a good approach. Due to the expertise required in writing Security Profiles, costs for completing the process are substantial, especially for small vendors.
The scheme described in the remaining documents resembles common smart card certifications schemes, namely CC. An IoT certification scheme with a focus on smart-home devices should be simpler than a smart card certification scheme, especially in the basic assurance level. The reason being that unlike smart card vendors, smart-home IoT vendors create new products very frequently. The majority of the vendors focus on developing IoT with enhanced usability features, neglecting simple security and privacy-by-design principles. Eurosmart proposes a scheme with a single assurance level, substantial, omitting to provide a basic assurance level that could provide the ground for certifying low-risk products.
The Eurosmart scheme was designed with a focus on smart card products and high security requirements. The list of security requirements that pertain to the usage of a secure element (smart card) aim to mitigate attacks on the hardware level. These attacks are highly
8 IEC TS 62443-1-1:2009 industrial communication networks - Network and system security - Part 1-1: Terminology, concepts and models, https://webstore.iec.ch/publication/7029 9 Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC, https://eur-lex.europa.eu/eli/reg/2017/745/oj
9
STANDARDS SUPPORTING CERTIFICATION December 2019
sophisticated and scarcely target smart home devices. Such IoT devices are placed inside homes or offices and therefore already a relative physically secured environment can be assumed.
As the Mirai and similar attacks (Newman, 2016) demonstrated, the origin of most attack vectors for home devices is the network interface. Therefore, the security of the network interface, the mobile application environment and the cloud infrastructure that may facilitate IoT devices is far more important to consider than the security of local hardware attacks and their countermeasures like Secure Boot (Rane, 2017), TEE (Heyton, 2018). Restricted Operation Environments (ROE)10 as described in the Eurosmart scheme are only necessary for a small number of IoT devices.
According to the Eurosmart scheme, IoT ROE is “responsible of the following functionality - Secure storage/usage -Secure Boot -Access Control policy, Isolation of Applications - Resistance to physical/local attacks -Resistance to all types of side-channel leakage analysis“. Such security functionalities are meaningful for smart cards or other products, which contain secrets for financial transactions or identification services. Home devices on the other hand, contain sensors or actuators that are not targeted on a hardware level and therefore IoT ROE functionalities address a scarce number of very sophisticated attacks.
The scheme further defines the role of an IoT Security Operator/Administrator. In a smart home environment, the person that will fulfil such a role does not always possess the necessary skills. A non-expert user will most likely install by themselves the smart home devices. Users tend to assume that these devices are securely configured and that maintenance of the security controls is achieved automatically. Finally, users expect simple setup processes. Therefore, secure configurations of IoT devices should be by default initiated during the installation process without particular user intervention. The vendor must automatically apply security updates and maintain secure configurations without prompting users to act.
Figure 2: Phases in the development of IoT Devices11
10 IoT Restricted Operation Environment, chapter 3.4 in [Part-2] Eurosmart_IoTsCS-GPP_v1.0_B-RELEASE 11 Figure: Chapter 5 IoT Device Life-Cycle, [Part-2] Eurosmart_IoTsCS-GPP_v1.0_B-RELEASE
10
STANDARDS SUPPORTING CERTIFICATION December 2019
Figure 2 illustrates the different phases of an IoT device as described in the Eurosmart scheme. The first two phases (Hardware, Firmware and Software Design and Silicon/Chip Manufacturing) are deemed complex for a basic assurance level.
To briefly describe these phases, the vendor purchases ready-to-use hardware and standard software components before combining them to form a working product. The next step considers the configuration and customization of the standard software. The remaining phases focus on off-the-shelf products. Therefore, requirements for hardware, in-depth firmware or software cannot be fulfilled by vendors who opt for off-the-shelf devices. This limits the possibilities for vendors to participate in such an evaluation and to fulfill any requirement.
In a similar vein, requirements described in Chapter 1112 such as Resistance to Perturbation, HW-based immutable root of trust, Tamper Detection and Tamper Protection are extremely advanced to be understood and followed by the majority of the consumers of IoT devices.
Figure 3 provides an overview of the risk-based assessment methodology suggested by Eurosmart. It is a very thorough and complex process that applies to a wide range of manufacturers and for a variety of products. Consider the case of a smart refrigerator, where the risk assessment may be performed for a consumer, an enterprise or an industrial environment, resulting in diverse attackers for each scenario. Aiming for a certain level of security for all devices (such as ‚substantial) might be a reasonable approach. To achieve higher levels of assurance, special certifications like Common Criteria can be applied to specific devices.
Figure 3: IoT Risk-Based Assessment Methodology13
The Annex of Part 214 provides examples of attack calculations. Estimating the probabilities of attacks occurring is a challenging task. Part 315 of the scheme refers to certified Common Criteria chip-card devices, which should be used to create a secure IoT device. Parts 416, 517 and 718 describe the processes concerning a certification scheme, e.g. accreditation of labs. These parts can be the foundation for defining processes that pertain to substantial level security certification (see also potential candidate for a European Error! Reference source not f
12 [Part-2] Eurosmart_IoTsCS-GPP_v1.0_B-RELEASE 13 Figure: Chapter 12.3 Risk-Based Methodology in [Part-2] Eurosmart_IoTsCS-GPP_v1.0_B-RELEASE 14 [Part-2] Eurosmart_IoTsCS-GPP_v1.0_B-RELEASE 15 [Part-3] Eurosmart_IoTsCS-Evaluation_v1.0_B-RELEASE 16 [Part-4] Eurosmart_IoTsCS-Certification-Agreement_v1.0_B-RELEASE 17 [Part-5] Eurosmart_IoTsCS-CABs-Accreditation-Policy_v1.0_B-RELEASE 18 [Part-7] Eurosmart_E-IoT-sCS_Mark and Certificate Usage Policy_v1.0_B-RELEASE
11
STANDARDS SUPPORTING CERTIFICATION December 2019
ound.). Part 619 covers the vulnerability management and continuity assurance. Vulnerability management and continuity assurance should always be the responsibilities of the vendor.
Experience from the application of Common Criteria over the past decades has indicated that only experts can fully comprehend these complex certification schemes which use Security Profiles. Consumers of smart home devices require security principles that would be simple to follow. Eurosmart’s certification scheme, due to its complexity, is an excellent candidate for substantial and high assurance levels as defined in the Cybersecurity act. A basic level of assurance that relies on self-certification is prohibited given that the simplest analysis, as described in the Eurosmart scheme, should be verified by a certification body.
3.1.2 ETSI 303 645 The ETSI EN 303 645-v.0.1.0 standard is a new standard spearheaded by the UK Department for Digital, Culture, Media and Sport (DCMS). In the process of becoming an EN Draft, the DIN standard (27072 on IoT capable devices - Minimum requirements for Information security)20 was incorporated. ETSI EN 303 645-v.0.1.0 emphasises the security of consumer IoT devices and is developed by ETSI TC Cyber. This standard specifies high-level provisions for the security of IoT devices that are connected to network infrastructure (such as the Internet or home network) as well as their connectivity to other associated services. IoT products primarily intended to be used in manufacturing, healthcare or for other industrial applications are not in scope of this document.
The draft ETSI EN 303 645 standard specifies, to-date, around 75 detailed requirements. These requirements are categorised in the following control groups:
No universal default passwords Implement a means to manage reports of vulnerabilities Keep software updated Securely store credentials and security-sensitive data Communicate securely Minimize exposed attack surfaces Ensure software integrity Ensure the protection of personal data Make systems resilient to outages Examine system telemetry data Make it easy for consumers to delete personal data Make installation and maintenance of devices easy and Validate input data.
The requirements are elicited by examining best practices in IT security for similar products. The format of the standard starts with Provisions, which are followed by detailed descriptions and examples to clarify these descriptions. For example, in chapter 4.5 of the standard “Communicate securely“, Provision 4.5-2 stipulates that “the consumer IoT device should use reviewed or evaluated implementations to deliver network and security functionalities, particularly in the field of cryptography“. After the Provision, there is a more detailed description and an example like:
„EXAMPLE 1: Distributed software libraries within the development and test community, certified software modules, and hardware equipment crypto-service providers (such as the Secure Element and Trust Execution Environment) are all reviewed or evaluated.“.
The number of requirements accompanied by the examples allow vendors who lack experience in the cybersecurity domain to implement the appropriate requirements. To further facilitate the
19 [Part-6] Eurosmart_IoTsCS-Vulnerability Management, Maintenance & Continuous Assurance_v1.0_B-RELEASE 20 https://dx.doi.org/10.31030/3049430
12
STANDARDS SUPPORTING CERTIFICATION December 2019
application of the standard, the annex section separates requirements into mandatory, recommended and conditional.
There is no detailed description of the certification scheme because the standard focuses on the requirements that will enhance the cybersecurity maturity of IoT products. ETSI EN 303 645 was designed as a certification standard and additional work is needed to create a complete certification scheme.
The standard would map to a substantial level of assessment as defined in the Cybersecurity act. The self-assessment process would be possible for a basic security level. The requirements are described in detail, enabling vendors to implement them and validate compliance with the standard without additional assistance from experts or the need for certification bodies.
3.1.3 Other relevant frameworks and suggestions An ENISA study defined baseline security measures (policies, people/organizational measures and technical measures) by examining and grouping a range of standards. The study considered common measures that can apply horizontally across critically information infrastructures (ENISA, 2017).
The National Institute of Standards and Technology (NIST) (National Institute of Standards and Technology, 2019) identified a recommended set of security features that IoT manufacturers may voluntarily follow, named “Core Baseline for IoT Devices”. The guide contains information and reference examples for six main features. These features are:
Device Identification: Unique information to identify the IoT device. Device Configuration: Software and firmware configuration can be subject to change by authorised users only. Data protection: Protect stored and in transit data from unauthorised access or modification Logical access to interfaces: Enable logical access through local and network interfaces to authorised entities only. Software and firmware updates: enable updates to software and firmware through secure and configurable mechanisms. Cybersecurity event logging: Log cybersecurity events and provide access to these logs to authorised entities only.
The Cloud Security Alliance (CSA) published an IoT Security Controls framework to guide organisations that intend to incorporate multiple types of IoT devices and cloud services. The aim of the framework is to identify relevant security controls for a range of components, such as, simple sensors, cloud applications and services, mobile devices etc (Cloud Security Alliance, 2019).
The IoT Security Foundation [IoTSF] provided a list of technical controls in a report titled IoT Security Compliance Framework to meet the DCMS proposed Code of Practice for Security in Consumer IoT products and Associated Services (IoT Security Foundation, 2018). This report underpinned DCMS’s involvement in developing the draft ETSI EN 303 645 standard. Finally, Finland launched in 2019 a cybersecurity label to certify smart home devices. The label considers basic information security features which are based on EN 303 64521.
21 https://www.kyberturvallisuuskeskus.fi/en/news/finland-becomes-first-european-country-certify-safe-smart-devices-new- cybersecurity-label
13
STANDARDS SUPPORTING CERTIFICATION December 2019
3.2 POTENTIAL CANDIDATE FOR A EUROPEAN ERROR! REFERENCE S OURCE NOT FOUND. A potential candidate European cybersecurity certification scheme could focus on smart home IoT devices, with emphasis on security requirements that can be followed by the majority of the vendors in a market that is in its infancy regarding cybersecurity requirements. An ENISA study provides further details on smart home devices and their threat landscape (ENISA, 2014). The scheme will contain three levels of assurance. For each level, the technical rules would be based on the ETSI EN 303 645 standard and on the Eurosmart scheme. Given the detailed formatting of the Eurosmart scheme, its elements would populate technical measures in the Substantial and High level of assurance. Procedures and ideas, particularly presented in Parts 4, 5 and 7 could be the foundation for the two aforementioned levels.
The Eurosmart standard adopts ideas and evaluation mechanisms from the Common Criteria. The CC is a very useful standard for certification in the area of products with a high security level. CC requires experience and the fact that the first European cybersecurity scheme will be the transposition of SOGIS can provide the grounds to develop the skills and knowledge required in the EU. The verification of requirements described in the ETSI EN 303 645 standard is straightforward and does not require the involvement of certification bodies.
The risk assessment of mainstream IoT smart home devices shows that physical attacks are prevalent. Therefore, physical hardware protection mechanisms should be mandated only in critical sectors when a physical attack is likely. IoT products that need to withstand such physical attacks should require a high level of security and therefor a CC certification and a physical smartcard or TEE inside of the IoT device.
Figure 4: Everything is IoT22
The proposed potential candidate scheme focuses on consumer IoT devices mainly used in Smart Home environments and contains the following levels:
Basic security level certification is achieved by self-assessment based on the requirements from the ETSI EN 303 645. The device must meet all mandatory requirements. Substantial security level certification is achieved by adding defined processes in the Eurosmart scheme such as vulnerability management, policies, and mark usage. The
22 Figure: https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/iot
14
STANDARDS SUPPORTING CERTIFICATION December 2019
overall scheme setup follows the same principles that derive from other EU legislation acts, such as eIDAS. High security level certification is achieve through the Common Criteria scheme. The ETSI EN 303 645 requirements and the requirements from Eurosmart are used to create a Consumer IoT High Level Protection Profile and use the current CC infrastructure (SOG-IS23) for the certification.
The basic level of assurance pertains to simple customer IoT devices as a minimum level of security. Ideally, all IoT devices should be compliant to the technical requirements of this level through self-assessment processes. The substantial level of assurance pertains devices, which need to guarantee a certain level of security (e.g. IoT cameras, IoT devices used in public spaces). The high level of assurance is demanded when IoT devices are deployed in critical infrastructure environments or in areas where cyber attacks may cause significant harm. The aim of the scheme should be for most IoT vendors to reach a substantial security level through straightforward and non-expensive processes.
23 https://www.sogis.eu
15
STANDARDS SUPPORTING CERTIFICATION December 2019
4. ANALYSIS OF THE STANDARDS LANDSCAPE FOR CLOUD SERVICES
In response to the CSA, the Cloud Service Provider Certification Working group (hereinafter CSPCERT WG) was created to explore the possibility of developing a European wide cloud certification scheme24. The group revolves around the elaboration of security objectives that an EU-wide certification scheme shall includeꓼ existing standards, schemes and good practices, analysis of relevant conformity assessment methodologies and the results of open consultation. A suitable certification scheme is one that meets the specifications in the CSA, which are the Cloud Computing Assurance Levels, the CSA requirements and the recommendations related to the Scheme Governance.
4.1 OVERVIEW OF LANDSCAPES The market of cloud certification schemes is fragmented, with various public, private and private-public initiatives currently in place (Orue-Echevarria, Cortés, Alvarez, Sanchez, & Ayerbe, 2018). Table 1 provides and overview of the well-established cloud certification schemes:
Table 1: Overview of cloud certification schemes
Type of imitative Name Brief description
C5 is intended for professional CSPs. C5 defines which requirements, named as controls in the documentation, are to be complied with by the CSPs, as well as the minimum set of requirements that the CSPs have to meet. BSI C525 The requirements expressed in the supporting (Germany) documentation have been elicited from widespread security standards and supplemented with BSI’s own requirements. BSI is based on CSA CCM26 and ISO 2700127. Public and European Norms SecNumCloud28 above is intended for CSPs. Its controls are mostly based on ISO 2700127 and structured in similar categories. However, it contains additional requirements ANSSI that differentiate it from the existing standard and that do SecNumCloud28 not induce equivalence between the two sets of rules. (France) These supplementary requirements refer to service agreement content definition, data location French language usage, and activities to perform at the end of contract.
24 https://drive.google.com/file/d/1J2NJt-mk2iF_ewhPNnhTywpo0zOVcY8J/view 25 German Federal Office for Information Security, 2017, Compliance Controls Catalogue (C5), https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/CloudComputing/ComplianceControlsCatalogue- Cloud_Computing-C5.pdf;jsessionid=0A26465CAC7891AC14E23B835AB952BC.2_cid369?__blob=publicationFile&v=3 26 Cloud Security Alliance, CCM - Cloud Control Matrix, https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v3- 0-1/ 27 International Standards Organization, 2013, ISO/IEC 27001:2013 - Information technology -- Security techniques -- Information security management systems -- Requirements 28 ANSSI, 2018, SecNumCloud – Referentiel, https://www.ssi.gouv.fr/uploads/2014/12/secnumcloud_referentiel_v3.1_anssi.pdf
16
STANDARDS SUPPORTING CERTIFICATION December 2019
Type of Name Brief description imitative
ENS sets out the basic principles and minimum requirements as well as the protection measures to be Esquema Nacional implemented in the Administration's systems. It focuses de Seguridad29 on integral security, risk management, incident (Spain) management and continuous improvement. It also establishes three levels and details the applicability of each measure in each of the three levels.
Set of standards that define security measures for Information Service Management systems. The controls ISO 27000 family30 for generic ISMS are defined in 2700231, while the cloud- specific controls are defined in 2701732. 2701833 focuses on personally identifiable information.
Designed for CSPs. The security controls upon which organizations can get certified are the ones defined in the CSA STAR34 CSA Cloud Control Matrix35 (CCM) (Cloud Security Alliance)
Private Zeker Online is a Dutch private, independent organization, that aims to certify providers of cloud – based services, IaaS, PaaS or SaaS. This certification has two big pillars: Zeker Online36 1) legal requirements, covering all data-related aspects such as data portability, GDPR37 compliance and so on; 2) infrastructure
Trusted Cloud focuses on SMEs, both CSPs and cloud users, and covers data security aspects, quality of service, transparency, data protection and contractual issues.
Public – Private Trusted Cloud38 Trusted Cloud is the non-profit association founded after the conclusion of the German program “Trusted Cloud” (funded by the Federal Ministry of Economic Affairs and Energy (Bundesministerium für Wirtschaft und Energie, BMWi)).
In June 2019, the CSPCERT Working Group (CSPCERT) published a document (CSPCERT Working Group, 2019) with recommendations for the European Commission on the implementation of the EU-wide cloud-security certification scheme. The aim of the document is to identify gaps and similarities in the aforementioned schemes. In an effort to harmonise the market of cloud certification, CSPCERT draws from widely accepted schemes to propose suggestions for an EU certification scheme.
As part of this document and the activities performed, the group reported:
29 Government of Spain, 2019, Spain: National security scheme – ENS, https://www.ccn.cni.es/index.php/es/esquema- nacional-de-seguridad-ens 30 Internationa Standards Organization, ISO/IEC 27000:2018 - Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary. 31 International Standards Organization, 2013, ISO/IEC 27002:2013: Information technology -- Security techniques -- Code of practice for information security controls, https://www.iso.org/standard/54533.html 32 International Standards Organization, 2015, ISO/IEC 27017:2015 - Code of practice for information security controls based on ISO/IEC 27002 for cloud services. 33 International Standards Organization, 2019, ISO 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors. 34 Cloud Security Alliance, CSA STAR, https://cloudsecurityalliance.org/star/cloud-service-provider/ 35 Cloud Security Alliance, CCM - Cloud Control Matrix, https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v3-0- 1/ 36 Zeker Online, https://www.zeker-online.nl/keurmerk-zeker-online/documenten/ 37 Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (OJ L 119, 4.5.2016, p. 1): https://eur-lex.europa.eu/legal- content/EN/TXT/?uri=CELEX%3A32016R0679 . 38 Trusted Cloud, https://www.trusted-cloud.de/en
17
STANDARDS SUPPORTING CERTIFICATION December 2019
1) A gap analysis comparing several certification schemes, namely ISO 27002, ISO 27017, ISO 27018, SecNumCloud and BSI C5. The schemes that were analysed were selected because they originate from European public entities or are European Norms. 2) A set of high-level and detailed security controls extracted from the comparison of the previous certification schemes, as well as the methodology used to obtain them and how new schemes could be incorporated. This is necessary since the cloud security certification scheme should always be up to date in order to cover new requirements as the technology and risks evolve. 3) A comparison of different conformity assessment methods that are commonly used in the different certification schemes. 4) Recommendations on how the implementation of the different articles stated in the EU CSA could be addressed, accompanied by a set of justifications.
This document is complementary to the European Commission’s study SMART 2016/0029 “Certification schemes for cloud computing” (Directorate-General for Communications Networks, Content and Technology (European Commission) , Fundación TECNALIA RESEARCH & INNOVATION, 2019) which was taken as baseline for the gap analysis. That study mapped the controls of ISO 27002, ISO 27017, ENISA Cloud Control Matrix (ENISA, 2014), BSI C5, Cloud Security Alliance Cloud Control Matrix, and NIST 800-5339. That study also analysed the most adopted cloud security certification schemes in the top 50 CSPs and found that ISO 27001 is the most adopted one in spite of not being cloud specific, but rather suitable for any Information System.
The gap analysis presented in Annex 1 of the CSPCERT document builds on top of the one performed in the abovementioned study. The main findings of the comparison analysis are:
Controls related to the integrity and security of the software developed and deployed as part of the cloud service are not fully covered by several of the certification schemes (e.g. ISO 2700x). These controls entail the development and operation of the software for all the cloud services (e.g. Platform as a Service (PaaS), Software as a Service (SaaS), Infrastructure as Code), coming both from proprietary development and from the inclusion of third-party libraries. Controls related to risk, threats and vulnerability management are also frequently overseen. Only SecNumCloud has a limited number of controls to this end. However, since security is closely related to the management of risks, further controls need to be considered. Operational security, procurement management of the supply chain, asset management and access management are the main focus of cloud-specific certification schemes such as SecNumCloud and BSI C5. Penetration testing, Cloud Service Levels of Agreement (SLAs) (and the corresponding metrics and Security Quality of Service (SQOs)) are not thoroughly covered in any of the analysed certification schemes. Continuous auditing is a new aspect that shall be considered, especially in schemes requiring high levels of assurance. To this end, the trustworthiness of the audit trails of the collected evidences shall be ensured.
The second item analysed in the CSPCERT is the different conformity assessment methods (CAM) which are currently used in certification schemes. Several CAMs exist: self-assessment, evidence-based, ISO-based approach and ISAE-based approach. Their characteristics are as follows:
39 NIST, 2014, Security and Privacy Controls for Federal Information Systems and Organizations - NIST Special Publication 800-53. rev 4. doi:https://doi.org/10.6028/NIST.SP.800-53r4
18
STANDARDS SUPPORTING CERTIFICATION December 2019
Self-assessment: The cloud service provider performs an analysis of its own processes and services and compares them with a self-assessment questionnaire provided by the certification scheme. Evidence-based assessment: a CSP performs a self-assessment but provides the collected evidence to a third party that reviews the conformity of such evidence. This third party is a monitoring body appointed by the National Certification Authority. An example of this is Trusted Cloud in Germany. ISO-based: the procedure is carried out following the ISO conformity assessment methodology by ISO auditors, where it is analysed that the security controls are in place, that the evidence is collected in accordance to what has been defined and aligned to what the scheme states in its implementation measure. ISAE-based: this is based on the ISAE 340240 auditing standard. The auditors are usually financial auditors. Here, it is certified that the security measures exist and that the controls are operationally efficient.
Cloud computing has a complex supply chain, especially in the upper layers of PaaS and SaaS. Furthermore, a security breach at the Infrastructure as a Service (IaaS) level can have serious implications. To this end, CSPCERT recommends that self-assessment is not accepted as a valid CAM for cloud computing. In this respect, Table 2 illustrates the recommended CAMs for each of the assurance levels identified in the EU CSA:
Table 2: Conformity assessment methodologies vs. levels of assurance41
Level of Assurance Conformity Assessment Basic Substantial High
Evidence based conformity assessment X
Third party ISO based approach X X X
Third party ISAE based approach X X X
All previously mentioned schemes and conformity assessment methods focus on the level of security of a cloud service at a certain point in time or during a limited time interval. However, due to the criticality of cloud, a continuous monitoring of the effectiveness of the security controls measured, as well as continuous evidence collection and audit are essential. This is aligned with Articles 54 (j) and 57 (9) of the EU CSA that propose the possibility of deploying a high-assurance, evidence-based and continuous certification of European cloud service providers.
4.2 POTENTIAL CANDIDATE FOR AN EU CYBERSECURITY CERTIFICATION SCHEME FOR CLOUD A certification scheme for cloud providers should aim to certify the cloud services which are offered. This approach has been successfully implemented in two schemes, namely SecNumCloud and Esquema Nacional de Seguridad.
The European Cybersecurity Act establishes that the EU-wide certification schemes for ICT products, processes and services shall have three assurance levels: basic, substantial and high. The assurance levels are defined in the EU CSA in Article 52 and are related to the potential of
40 International Auditing and Assurance Standards Board (IAASB), Auditing international standard on assurance engagements (isae) 3402: assurance reports on controls at a service organization, http://www.ifac.org/system/files/downloads/b014-2010-iaasb-handbook-isae-3402.pdf 41 CSPCERT Milestone 3 document
19
STANDARDS SUPPORTING CERTIFICATION December 2019
the attacker and the level of risk such attacks pose to the organisation (basic, known and state of the art).
Defining an assurance level entails several dimensions inter alia, Availability, Authenticity, Integrity, Reliability, Confidentiality and Traceability. A cloud service can be affected in one or more of these dimensions during a security incident. For an organisation to decide which assurance level to follow, a possible consideration can be as follows:
Basic level: the consequences of a security incident impose limited damage in the functions of the organisation, its assets or personnel. Limited damage can be conceived as minor damages in the assets of the organisation (e.g. degradation of an asset is less than 1%), reparable damage to a person or that the capacity of the organisation to meet efficiently its duties decreases slightly. Substantial level: the consequences of a security incident that affect at least one dimension result in severe damage in the functions of the organisation, its assets or personnel. Severe damage can be conceptualised as suffering major damage in the assets for the organisation (e.g. degradation of the assets is between 1% and 50%), long-term health issues for personnel, and significant reduction in the capacity of the organisation to efficiently continue in providing services. High level: the consequences that affect some of the dimensions are extremely severe. Extremely severe can be conceived as the annulment of the organisation to provide any of its duties, irreparable loss of the assets of the organisation and grave damage to a person.
Based on the aforementioned security dimensions, the cloud services can be classified into a category. Three dimensions can be defined:
Basic level: if any of the dimensions of the cloud service is classified as Basic, and none is classified in a higher level. Substantial level: if any of the dimensions of the cloud service is classified as Substantial and none is classified in a higher level. High level: if any of the dimensions of the cloud service reaches the level High.
To this end, a risk assessment process shall be put in place. While some risks may be common to all services provided by a cloud service provider, others might be specific to that cloud service and therefore more careful consideration is needed. For instance, while IaaS, PaaS and SaaS implement security mechanisms, in the case of SaaS the multi-tenancy aspects need to be considered in the security dimensions. If the SaaS is a cloud-native application developed as a microservices-based application, then the communications among the microservices usually through REST APIs, must also be secured.
A risk assessment process is often composed of five steps (CSPCERT Working Group, 2019):
1. Establishment of a risk assessment framework 2. Identification of risks 3. Analysis of risks 4. Evaluation of risks 5. Selection of risk management options
The key elements for a risk assessment framework are:
The context of the organisation, which involves the legal and regulatory obligations of the company; The context of the service;
20
STANDARDS SUPPORTING CERTIFICATION December 2019
Risk criteria, which is the way in which risks are measured, usually based on probability and impact but with clear and defined parameters. Clear criteria will ensure that when people conduct the same the risk assessment they will produce the same result. Risk acceptance or risk tolerance or appetite that will determine the level of risk that is accepted by the organisation to perform or not any corrective action.
ISO 27000 states that an “Information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization”30. Therefore, a risk comprises the following three elements:
An Asset, which is an element that needs protection. In this case, a cloud service. A Threat, which is a danger that can hurt the asset. A Vulnerability that allows the threat to reach the asset. An Impact, which describes how an asset is affected by a threat.
A security risk assessment for a cloud service, be it IaaS, PaaS, SaaS or any other XaaS (e.g. Container as a service, database as a service) shall consider the damage that can occur towards integrity and availability of said service.
Risk is measured by probability and impact. In this context, the correlation between probability and threat and impact and vulnerability is strong, as for instance, similar threats tend to have similar impacts in the service and business continuity.
Table 3 shows a summary of different types of impact and probability factors.
Table 3: An example of factors for probability and impact
Probability Impact
Frequency of occurrence Human
Current levels of the security control (implementation measures) Financial
Possibility of occurrence after the mitigation Legal
Regulatory
Operational
Reputational
For an effective risk assessment, the following aspects need to be considered:
Risk id Affected asset (service) Risk description Effect on the Integrity of the service Effect on the Availability of the service Effect on the Confidentiality of the service Threat Vulnerability Current control(s) implementing safeguards for that risk Target values, as defined in the implementation measures Current values achieved by the cloud service Risk probability Risk impact
21
STANDARDS SUPPORTING CERTIFICATION December 2019
Risk rating: probability * impact Risk treatment: Accept, reduce, transfer, avoid Risk treatment plan New controls affected by the risk treatment Possibility of occurrence Residual risk probability Residual risk impact Residual risk treatment Risk owner
Table 4: Risk evaluation matrix
Level of Impact
Level of Probability 1 2 3 4 5
Insignificant Minor Moderate Major Catastrophic
5 Almost Certain Medium High Very High Critical Critical
4 Probable Medium High Very High Critical Critical
3 Possible Low Medium High Very High Very High
2 Improbable Low Low Medium High High
1 Rare Low Low Low Medium Medium
Taking as input Table 4, and the high-level description of the different assurance levels with respect to the risks, the assurance level can be determined as follows:
Assurance level High: services which have an overall risk rate “Very High” or “Critical” Assurance level Substantial: services which have an overall risk rate “Medium” and “High” Assurance level Basic: services that have an overall risk rate “Low”.
In principle, CSPCERT recommends that all assurance levels comprise the same set of security controls. However, the implementation measures, technical objectives and target levels should differ and be more or less stringent depending on the selected level of assurance. Moreover, the conformity assessment can also differ with respect to the sought assurance level (see Table 2). An example of this is illustrated in Figure 5.
22
STANDARDS SUPPORTING CERTIFICATION December 2019
Figure 5: Example of Combination of controls, corresponding Requirements and methodologies42
A practical example is given in Table 5. Here a list of controls is mapped to the core dimensions that are defined for every level of assurance. Then, implementation requirements for technical security measures are described for every level in order to effectively deploy the control.
Table 5: Practical example of controls and security measures per assurance level
Security Control Category Basic Substantial High measure
Availability, Confidentiality, Authentication Integrity, Reliability and Applies + ++ Control 1 Traceability
Change Confidentiality N/A Applies = Control 2 Management
Business Availability N/A N/A Applies Control 3 continuity Plan
N/A is defined as not applicable, the “=” symbol denotes that the controls is deployed identically with the lower level of assurance, and “+” and “++” indicate stringent and significantly stringent requirements, respectively, in the deployment of the controls when compared to lower levels of assurance.
For instance, focusing on the Authentication in Table 5, an example of technical security measures for Control 1 can be:
Basic level: any mechanism of authentication will be accepted such as passwords, tokens, certificates Substantial level: passwords shall be accepted only if a rigorous policy is put in place, such as rules on secure passwords, requests to frequently renew passwords. Tokens, certificates and biometrics can be accepted. High level: the access will be revoked if not used for a certain period of time. Tokens, biometry, certified products.
These security measures are summarised per level of assurance in Table 6.
42 Figure. source CSPCERT Milestone 3 document
23
STANDARDS SUPPORTING CERTIFICATION December 2019
Table 6: Implementation of security measures for accepted authentication mechanisms
Measure Basic Substantial High
Revocation of access if not used Passwords Yes Secure password policies, frequent updates after a specific period
Additional factors (e.g. Tokens Yes Yes cryptographic)
Biometrics No Yes Double factor authentication
This approach can be followed for each control and level. Differentiating aspects among levels can be:
Frequency in which the tasks need to be performed (e.g. daily, monthly, regular) Duration of a specific activity Response time and service level agreements Scope of the control
Due to the complexity of the cloud computing supply chain, as well as the criticality of the data and applications deployed on a cloud service, a security breach can have severe consequences for the cloud user and the application provider (e.g. SaaS). Therefore, self-certification shall not be accepted in the basic level of assurance. In agreement with the recommendation of CSPCERT, it is expected to establish an evidence-based conformity assessment similar to the one implemented in Germany with Trusted Cloud. There, “the CSP has to provide to the reviewer”, namely a monitoring body appointed by the National Certification Authority, “structured information about the cloud service provided and on all items of the pre-defined set of security controls. The information provided by the CSP is legally binding and should be signed off by the management of the CSP”. With all this information as input, the monitoring body prepares a report that is checked by the National Certification Authority who, if successful, issues the certificate for a Basic level of assurance.
While several security certification schemes exist, few are cloud-specific. Thus, for a potential candidate EU cybersecurity certification scheme for cloud, the basis of the scheme should form cloud-oriented schemes, such as SecNumCloud, ISO 27017, BSI C5 and ENS. This does not preclude considering other schemes such as Trusted Cloud, Zeker Online and CSA STAR. An initial equivalence classification per level of assurance is described in Table 7: Equivalence of existing cloud specific certification schemes and EU CSA assurance levels.
Table 7: Equivalence of existing cloud specific certification schemes and EU CSA assurance levels
Assurance level Cloud security certification Cloud Services
Trusted Cloud IaaS, SaaS Basic Zeker Online Infrastructure ENS low IaaS, SaaS
BSI C5 IaaS, SaaS CSA STAR IaaS, SaaS Substantial ISO 27017 IaaS ENS medium IaaS, SaaS
High SecNumCloud IaaS, SaaS
24
STANDARDS SUPPORTING CERTIFICATION December 2019
Assurance level Cloud security certification Cloud Services ENS high IaaS, SaaS
Several member states such as Germany, Spain and France, possess already the infrastructure se-up for the attestation or certification of their cloud-security certifications. Furthermore, ISO 27017 is a European Norm and therefore, the infrastructure is set-up in the different Member States. This infrastructure will be important for the transition to the EU-wide cloud-security certification scheme.
25
STANDARDS SUPPORTING CERTIFICATION December 2019
5. ANALYSIS OF THE STANDARDS LANDSCAPE FOR THREAT INTELLIGENCE- BASED FRAMEWORK
This chapter analyses and provides guidance in the area of Threat intelligence-based ethical red teaming for the core financial infrastructure. Multiple national-led initiatives for the creation of red teaming frameworks can lead to incompatible frameworks and market segmentation, which consumes resources on duplicating efforts. The TIBER-EU Framework is proposed by the European Central Bank (ECB) with the potential to enhance cyber resilience of the financial sector and harmonise the way financial institutions perform red teaming exercises.
5.1 OVERVIEW OF THE TIBER-EU FRAMEWORK
5.1.1 History of Threat Intelligence-led Red Teaming Frameworks During the past years, the cyber threat landscape has evolved and the risks for organisations have increased. Organisations have fallen victims of cyber-attacks resulting in severe impact (Greenberg, 2018) and thus the World Economic Forum (WEF) has classified the risk of cyber- attacks as one of high likelihood and high impact (Marsh & McLennan Companies, Zurich Insurance Group, 2019). The aforementioned risk raised significant concerns to governments and regulators about the operational resiliency of critical infrastructure. As a result, there has been an increased interest in operational assessments of the critical infrastructure against cyber-attacks.
The financial sector is heavily regulated and is considered by many Member States as part of the critical infrastructure. Financial institutions are prime targets and are heavily targeted by cyber-attacks that can potentially under extreme circumstances affect the stability of the banking system. One of the effective risk controls against cyber attacks is the execution of penetration testing. The current operational penetration tests against the financial sector’s infrastructure have mostly narrow focus and do not fully simulate the tactics that are used by malicious threat actors. Therefore, there is an urgent need for structured frameworks to test the cyber operational resiliency of the financial institutions (and more generically of what is regarded as critical infrastructure43).
From 2014 to 2018, three frameworks were developed for the testing of the cyber operational resiliency of the financial sector in Europe44:
In 2014, the Bank of England (BoE) released the CBEST45 framework to test the operational resiliency of the UK financial institutions.
43 https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:345:0075:0082:EN:PDF 44 In 2016, the Hong Kong Monitory Authority developed iCAST framework and in 2018 the Association of Banks in Singapore developed AASE framework. 45 https://www.crest-approved.org/schemes/cbest/index.html
26
STANDARDS SUPPORTING CERTIFICATION December 2019
In 2017, the Dutch National Bank (DNB) released TIBER-NL46 framework (Threat Intelligence Based Ethical Red Teaming) which was inspired by CBEST. In 2018, European Central Bank (ECB) released TIBER-EU47 framework which is based on TIBER-NL and is the European framework for threat intelligence-based ethical red teaming.
5.1.2 Overview of TIBER-EU Framework Within the EU, multiple initiatives for the creation of red-teaming frameworks could lead to incompatible frameworks, market segmentation as well as duplicating efforts. According to the ECB, TIBER-EU is the first EU-wide framework for threat intelligence-based ethical red teaming. In this work, ENISA’s project team selected to analyse ECB’s TIBER-EU as it has the potential to enhance the cyber resilience of the financial sector and harmonise the way financial institutions perform intelligence-led red-teaming tests. While TIBER-EU is designed for the financial sector, there are no limitations for other sectors to adopt it and use it. One of the major advantages of TIBER-EU is the fact that it enables cross-border testing so that different (sectoral/national) authorities can mutually recognise the TIBER-EU tests.
According to the TIBER-EU framework, the main participating teams and their responsibilities are:
The Blue Team: the cyber security team of the target organisation (e.g. SOC, Incident Response, CSIRT, etc.) is the subject of the test and whose prevention, detection and response capabilities are tested without their foreknowledge. The Threat Intelligence provider: the company (threat intelligence service provider) responsible for the identification of the possible threats who carries out reconnaissance on the target organisation (e.g. the financial institution). The Red Team provider: the company (red teaming service provider)) that carries out the simulated attack and attempts to compromise the infrastructure of the entity by mimicking a cyber-adversary. The White Team: a small team within the target organisation (i.e. the financial institution) who knows that a TIBER-EU test takes place and who leads and manages the test in collaboration with the TIBER cyber team. The TIBER cyber team: the team within the relevant authority (e.g. national bank authority) that is responsible for overseeing the TIBER-EU test and ensuring it meets the requirements of the TIBER-EU framework.
The TIBER-EU process has three main phases: preparation, testing and closure. The preparation phase includes the identification of the major stakeholders, the procurement of threat-intelligence and red-teaming providers, the TIBER-EU testing scope, and the TIBER-EU project plan.
The testing phase includes the tailored threat-intelligence report (as delivered by the threat intelligence provider), the red teaming scenarios (handover between threat intelligence and red teaming providers), and the execution of the test by the red teaming provider.
Finally, the closure phase comprises the test summary report (which includes input from the red team and the blue team), the remediation plan, and the attestation (confirmation that the test was conducted according to TIBER-EU framework). The TIBER-EU process can be seen in Figure 6Error! Reference source not found..
46 https://www.dnb.nl/en/news/news-and-archive/nieuws-2017/dnb365801.jsp 47 https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
27
STANDARDS SUPPORTING CERTIFICATION December 2019
Figure 6: TIBER-EU Process48
5.2 POTENTIAL CANDIDATE EUROPEAN CYBERSECURITY CERTIFICATION SCHEME
5.2.1 Gaps and opportunities for certification schemes Currently, there is limited use of certification within EU about the cybersecurity features of various ICT products, services and processes. Thus, this lack of trusted information leads to decreased trust in EU’s digital solutions49. In this section, we identify the opportunities for certification schemes related to TIBER-EU and provide some relevant security requirements as well as recommendations.
Compared to traditional penetration testing methodologies, TIBER-EU testing, at its core, consists of a threat-intelligence part and a red-teaming part. The threat intelligence part provides the detailed view of the target organisation’s attack surface and underpins the production of actionable and realistic attack scenarios. The red-teaming part mimics the tactics, techniques and procedures (TTPs) of real-life cyber adversaries within a threat landscape and delivers a realistic simulation. TIBER-EU tests the target organisation’s critical functions and underlying systems (i.e. its people, processes and technologies) and assists the target organisation in assessing its protection, detection and response capabilities.
The TIBER-EU framework includes a requirement stating that third-party vendors should conduct the threat intelligence and the red-teaming tests. Thus, external specialist service- providers that meet the appropriate requirements to deliver the service for a TIBER-EU test, conduct the testing phase (threat intelligence and red teaming parts). Moreover, the test is not recognised if the entity’s own teams execute the testing phase, given that an independent (external) testing perspective is a prerequisite for TIBER-EU engagements.
This practically means that target organisations are responsible for conducting due diligence in order to identify and carefully select the most competent threat intelligence and red-teaming providers that can deliver high quality TIBER-EU testing. However, currently both threat intelligence and red-teaming markets feature a wide variety of providers with competing claims, which generate a significant amount of hype (especially the threat intelligence one).
In order to help entities during the procurement process, the ECB has published a document50 with guidelines that lists a set of requirements for the provision of red team and threat- intelligence services. As a result, organisations willing to undergo a TIBER-EU test should dedicate resources during the procurement phase trying to identify the most suitable providers
48https://cdn2.hubspot.net/hubfs/3021880/Ebook%20PDFs/NETTITUDE%20FINANCIAL%20SERVICES%20BRIEFING_Jul y%202019.pdf 49 https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32019R0881&from=EN 50 European Central Bank, TIBER EU Framework, https://www.ecb.europa.eu/pub/pdf/other/ecb.1808tiber_eu_framework.en.pdf
28
STANDARDS SUPPORTING CERTIFICATION December 2019
that meet the TIBER-EU requirements. The fact that every financial institution has to go through this process highlights a duplication of effort that could be avoided.
ECB has already identified this gap in the TIBER-EU framework50 and highlights the current absence of EU certification and accreditation capabilities for TIBER-EU services offered by providers. ECB recommends that there should be certification and accreditation capabilities to ensure that the red teaming and threat-intelligence services consumed in TIBER-EU test meet stringent requirements to conduct high-quality tests on critical infrastructure and functions. Thus, a potential certification scheme should cover a baseline level of requirements that will ensure that the service provided by the red teaming and threat-intelligence providers is proficient. The target organisations will opt for only TIBER-EU accredited and certified services. The Cyber Security Act (CSA) could address the identified gap.
5.2.2 Security objectives of European cybersecurity certification scheme for TIBER-EU Before diving into the specifics of TIBER-EU framework and the potential for a certification scheme for the provision of the red teaming and threat intelligence services, it would be good to have a look at how CBEST, widely accepted as a mature intelligence-led red teaming framework, has implemented its respective part.
The Bank of England (BoE) has also identified that companies wanting to participate in a CBEST test have difficulty and extra responsibility in identifying and selecting the most appropriate red teaming and threat-intelligence services. This happens mostly due to the market maturity (especially the threat-intelligence market is relatively immature compared to red- teaming market), duplication of effort from each company during the procurement phase of a CBEST test as well as potential increased risk in selecting an incompetent provider to conduct the test. Thus, the BoE has collaborated with the Council for Registered Ethical Security Testers (CREST), which is an international not-for-profit accreditation and certification body that represents and supports the technical information security market51. They jointly developed new accreditation standards for CBEST for the provision of threat intelligence and red-teaming service that companies have to achieve to deliver CBEST tests.
Moreover, certifications for individuals have been created that would enable them to participate in CBEST engagements: CREST Certified Threat Intelligence Manager (CCTIM)52, CREST Registered Threat Intelligence Analyst (CRTIA)53, CREST Practitioner Threat Intelligence Analyst (CPTIA)54, CREST Certified Simulated Attack Manager (CCSAM)55 and CREST Certified Simulated Attack Specialist (CCSAS)56.
Organisations that aim to undergo a CBEST test can select red teaming and threat-intelligence providers from the list of approved CBEST providers57 that have, in turn, employees certified by CREST. Furthermore, BoE has published a “CBEST Services Assessment Guide”58 which assists organisations in assessing the competence and quality of the red teaming and threat- intelligence providers in order to select the most appropriate one.
In a similar vein, ECB’s document “TIBER-EU Framework: Services Procurement Guidelines”50 provides guidance on the procurement process of the red teaming and threat-intelligence
51 https://www.crest-approved.org/ 52 https://crest-approved.org/examination/crest-certified-threat-intelligence-manager/index.html 53 https://crest-approved.org/examination/crest-registered-threat-intelligence-analyst/index.html 54 https://crest-approved.org/examination/crest-practitioner-threat-intelligence-analyst/index.html 55 https://crest-approved.org/examination/certified-simulated-attack-manager/index.html 56 https://crest-approved.org/examination/certified-simulated-attack-specialist/index.html 57 https://www.crest-approved.org/members-2/members-supplying-cbest-services/index.html 58 Bank of England, CBEST Intelligence-Led Testing, https://www.bankofengland.co.uk/-/media/boe/files/financial- stability/financial-sector-continuity/cbest-services-assessment-guide
29
STANDARDS SUPPORTING CERTIFICATION December 2019
services. The document also includes guidelines on the possible roles of authorities regarding the accreditation and certification process of the provision of red teaming and threat-intelligence services.
The Article 51 of the CSA clearly mentions the security objectives of European cybersecurity certification schemes. In this context, a potential cybersecurity certification scheme for TIBER- EU services aligns with the security objectives mentioned within Article 51.
5.2.3 Assurance levels of European cybersecurity certification scheme for TIBER-EU According to CSA’s Article 52, “A European cybersecurity certification scheme may specify one or more of the following assurance levels for ICT products, ICT services and ICT processes: ‘basic’, ‘substantial’ or ‘high’. The assurance level shall be commensurate with the level of the risk associated with the intended use of the ICT product, ICT service or ICT process, in terms of the probability and impact of an incident.”
TIBER-EU is designed to test the cyber resilience of the critical functions of financial institutions. The TIBER-EU Scope specifies the critical functions that will be tested and engaged operationally. Moreover, the information handled by the service providers is highly sensitive and any leakage might end up being impactful. As a result, any intentional or accidental incident caused by the service providers will have high impact on the target organisation’s confidentiality, integrity and availability of service. Thus, stringent requirements are needed in order to mitigate potential adverse impact on the target organisation.
In order to assess the probability of such incidents happening, we need to take into consideration a number of factors. First, the selected service providers should meet the TIBER- EU criteria and requirements. However, there is a risk that the service provider’s threat- intelligence team is not highly competent and the collected and analysed intelligence as well as attack scenarios do not fully cover the target organisation’s critical functions. As a result, the target organisation will not fully test its critical function via the TIBER-EU test and remain vulnerable resulting in not meeting TIBER-EU objectives.
Moreover, there is the risk that without certified/accredited members of the service provider’s red team (e.g. inexperienced personnel) the test may have damaging consequences (in terms of availability, integrity and confidentiality) to the critical functions being tested. The significance of this risk is highlighted further by the fact that TIBER-EU framework itself provides a degree of flexibility to the service provider’s red team regarding the attack scenarios to be followed during the test. TIBER-EU is less prescriptive regarding the attack scenarios and allows developing alternative ways to reach the red team’s objective.
On the other hand, it is necessary to take into consideration the fact that the TIBER-EU framework includes risk management measures to reduce the probability of denial-of-service incidents, unexpected system crashes, damage to critical live production systems, or the loss, modification or disclosure of data. These measures include the appropriate risk assessment before the TIBER-EU test, baseline requirements for the service providers, contractual agreements with service providers that include clauses regarding information security risks, confidentiality and escalation procedures for the TIBER-EU test, due diligence checking before the test as well as proper risk management controls during the test. For all the above reasons explained, it is required to assess that there is medium probability of impactful security events happening during a TIBER-EU engagement.
30
STANDARDS SUPPORTING CERTIFICATION December 2019
Before discussing the assurance levels of a potential European cybersecurity certification scheme for TIBER-EU framework, it is mandatory to consider some additional factors. Red teaming and (especially) threat-intelligence markets are still maturing and it is expected to be further developed in the upcoming years (Hielkema & Kleijmeer, 2019). Moreover, there exist service providers that are small in size but experienced in red teaming and threat intelligence. This practically means that if the assurance level of the cybersecurity certification for the provision of TIBER-EU services considers only level high, then there is a risk to exclude these small companies with the “niche” expertise required for TIBER-EU tests.
Finally, TIBER-EU framework, while currently tailored for the financial sector, can as well be adopted by authorities in other sectors. In these sectors, the security requirements can be different, meaning that multiple assurance levels could potentially be applicable for the provision of TIBER-EU services.
Based on the reasons explained above, it is suggested that the potential candidate for a European cybersecurity certification scheme for the provision of TIBER-EU services should have two assurance levels, basic and high, with incremental security requirements. Providers that cannot satisfy the requirements for the provision of TIBER-EU services within EU for the high assurance level, they could conduct conformity self-assessments for certified/accredited provision services with basic assurance level (acting as a lower entry point). Thus, based on the assessed risk or other requirements from the TIBER-EU implementation by the authority, target organisations can select provision of services satisfying the security requirements of a selected assurance level.
Moreover, it is expected that in the next three years the red teaming and threat-intelligence markets will be more mature. Therefore, the TIBER-EU framework will be further adopted and EU cyber security certifications will be more prevalent within EU. In accordance with this, it is recommended to reassess the need for having basic assurance levels for the EU cybersecurity certification/accreditation scheme for the provision of TIBER-EU services. This recommendation is also aligned with CSA that provisions that certification schemes should be periodically re- evaluated.
5.2.4 Security requirements for the cybersecurity certification scheme for TIBER-EU As recommended, having two separate assurance levels requires a different set of security requirements for basic and high assurance levels. The rest of the section will provide general recommendations on the security requirements of the two assurance levels that need to be included in the certification scheme for the provision of services with less focus on which requirements should be in included in each assurance level (the security requirements, which are included in the basic level, should also be fulfilled in the high level).The below guidelines are based on prior work conducted by ECB50, BoE58 and CREST59,60.
The below security requirements, of the cybersecurity certification scheme for the provision of TIBER-EU threat intelligence services, are for the basic assurance level:
Signed mutual non-disclosure agreement (mNDA) with the accreditation and certification provider (e.g. Conformity Assessment Bodies). This agreement will address any confidentiality concerns.
Evidence that the service provider has registered presence within EU. Thus, the service provider can be member of the EU’s single market for threat intelligence service providers for TIBER-EU testing.
59 https://www.crest-approved.org/accredited-companies/how-to-join-crest/index.html 60 https://www.crest-approved.org/criteria-to-become-a-cbest-provider/index.html
31
STANDARDS SUPPORTING CERTIFICATION December 2019
Evidence of the service provider’s indemnity insurance. ECB identifies this requirement in order to cover activities that are not covered in the contract or are a result of misconduct, negligence, etc.
Evidence of the service provider’s standards compliance certificates (e.g. ISO-2700127, ISO-900161). Proof of the service provider’s Quality and Information Security processes. According to ECD, competent service providers should provide evidence that they have a robust Information Security Management System (ISMS) with the relevant security control frameworks and appropriate certification based on recognized standards (as shown in Annex1 of ECB’s document “TIBER-EU Framework: Services Procurement Guidelines”50).
Evidence of the service provider’s Complaint Handling and Conflict of Interest policies.
Provision of references from previous TIBER-EU or intelligence-led red-teaming engagements. ECB specifically mentions that at least three references from previous assignments are needed. It is recommended for the threat intelligence service provider to show sectoral expertise in delivering TIBER-EU tests (e.g. financial sector) based on the references provided. High assurance level, service providers should provide evidence of sectoral expertise in delivering TIBER-EU tests.
Provision of named individuals involved in all elements of every TIBER-EU test.
The service provider’s threat-intelligence team must have an experienced Threat- Intelligence Manager (e.g. 5-year experience) that has end-to-end responsibility for delivering the TIBER-EU test. The threat intelligence service provider must also deliver an up-to-date CV of the Threat Intelligence Manager and a number of references (e.g. 3) of previous assignments of delivering intelligence-led red taming tests. The service provider or the national authorities must conduct additional background checks on the Threat Intelligence Manager. Finally, the Threat Intelligence Manager should have the appropriate certifications (not expired) for threat intelligence (as shown in Annex1 of ECB’s document “TIBER-EU Framework: Services Procurement Guidelines”50). Basic assurance level, the service provider should have an experienced Threat Intelligence Manager with the relevant background checks (conducted by the service provider). High assurance level, the service provider should have an experienced Threat Intelligence Manager, holding valid certifications with a background check conducted by the national authorities. The appropriate certifications applicable for the Threat Intelligence Manager need to be defined by the certification scheme.
The service provider’s threat-intelligence team must have team members with sufficient experience in threat intelligence (e.g. 2-year experience each) and, ideally, intelligence-led red-teaming tests. The threat intelligence service provider must also deliver up-to-date CVs of the Threat-Intelligence team members exhibiting a team with multi-disciplinary composition and skillset. The service provider of the national authorities must conduct additional background checks on the Threat Intelligence team members. Finally, the Threat Intelligence team members should have the appropriate certifications (not expired) for threat intelligence (as shown in Annex1 of ECB’s document “TIBER-EU Framework: Services Procurement Guidelines”50). Basic assurance level, the service provider should have sufficiently experienced threat intelligence team members with the relevant background checks (conducted by the service provider). High assurance level, the service provider should have sufficiently experienced threat intelligence team members holding valid certifications with
61 ISO 9000 family, Quality management, https://www.iso.org/iso-9001-quality-management.html
32
STANDARDS SUPPORTING CERTIFICATION December 2019
a background check conducted by the national authorities. The appropriate certifications applicable for the threat intelligence team members need to be defined by the certification scheme.
The threat intelligence service provider must be able to provide the relevant proof about its threat-intelligence processes and especially comprehensive threat- intelligence collection function (breadth of sources, depth of sources, language support, timeliness of collection, types of intelligence, intelligence gathering process, threat intelligence analysis and dissemination).
Evidence that the service provider and its employees comply with robust code of ethics and professional conduct. Moreover, the threat-intelligence service provider should have a mature understanding of ethical standards in gathering and processing human and technical intelligence respecting the relevant legislative frameworks.
The below indicative security requirements of the cybersecurity certification scheme for the provision of the TIBER-EU red teaming services, are for the basic assurance level, include:
Signed mutual NDA agreement with the accreditation and certification provider (e.g. ENISA). This mNDA agreement will address the confidentiality concerns.
Evidence that the service provider has registered presence within EU. Thus, the service provider can be member of the EU’s single market for red teaming service providers for TIBER-EU testing.
Evidence of the service provider’s indemnity insurance. ECB identifies this requirement in order to cover activities that are not covered in the contract or are a result of misconduct, negligence, etc.
Evidence of the service provider’s standards compliance certificates (e.g. ISO-2700127, ISO-900161). Evidence of the service provider’s Quality and Information Security processes. According to ECD, competent service providers should provide evidence that they have a robust Information Security Management System (ISMS) with the relevant security control frameworks and appropriate certification based on recognized standards (as shown in Annex1 of ECB’s document “TIBER-EU Framework: Services Procurement Guidelines”50).
Evidence of the service provider’s Complaint Handling and Conflict of Interest policies.
Provision of references from previous TIBER-EU or intelligence led red teaming engagements. ECB specifically mentions that at least five references from previous assignments are needed. It is recommended for the red teaming service provider to show sectoral expertise in delivering TIBER-EU tests (e.g. financial sector) based on the references provided. Basic assurance level, previous participation in TIBER-EU or intelligence-led red teaming engagements. High assurance level, service providers should provide evidence of sectoral expertise in delivering TIBER-EU tests.
Provision of named individuals involved in all elements of every TIBER-EU test.
The service provider’s red team must have an experienced Red Team Test Manager (e.g. 5-year experience) that has end-to-end responsibility for delivering the TIBER-EU test. The red teaming service provider must also deliver an up-to-date CV of the Red Team Test Manager and a number of references (e.g. 3) of previous assignments of delivering intelligence-led red taming tests. The service provider or the national authorities must conduct additional background checks of the Red Team Test Manager. Finally, the Red Team Test Manager should have the appropriate
33
STANDARDS SUPPORTING CERTIFICATION December 2019
certifications (not expired) for red teaming (as shown in Annex1 of ECB’s document “TIBER-EU Framework: Services Procurement Guidelines”50). Basic assurance level, the service provider should have an experienced Red Team Test Manager with the relevant background checks (conducted by the service provider) High assurance level, the service provider should have an experienced Red Team Test Manager, holding valid certifications with a background check conducted by the national authorities. The appropriate certifications applicable for the Red Team Test Manager need to be defined by the certification scheme.
The service provider’s red team must have team members with sufficient experience in red teaming (e.g. 2-year experience each) and, ideally, intelligence led red teaming tests. The red teaming service provider must also deliver up-to-date CVs of the Red team members exhibiting a team with multi-disciplinary composition and skillset. The service provider of the national authorities must conduct additional background checks of the Red team members. Finally, the Red team members should have the appropriate certifications (not expired) for red teaming (as shown in Annex1 of ECB’s document “TIBER-EU Framework: Services Procurement Guidelines”50). Basic assurance level, the service provider should have sufficiently experienced red team members with the relevant background checks (conducted by the service provider). High assurance level, the service provider should have sufficiently experienced red team members holding valid certifications with a background check conducted by the national authorities. The appropriate certifications applicable for the red team members need to be defined by the certification scheme.
The red teaming service providers must be able to provide the relevant proof about its robust methodologies in place to conduct the most advanced and innovative forms of red team testing. Moreover, the red teaming service provider should be able to deliver proof of the quality and depth of their research and development capability.
Evidence that the service provider and its employees adhere to a formal and robust code of conduct and ethical framework.
Finally, ECB provides a detailed set of requirements and list of questions to facilitate the procurement process for red team and threat-intelligence providers for TIBER-EU testing50. A potential cybersecurity certification scheme should consider them and identify the relevant security requirements for each of the two proposed assurance levels. This process would be a joint work that should include the relevant stakeholders (e.g. ECB, market representatives, etc.) which will provide their input.
5.2.5 TIBER-EU certifications for individuals Regarding the individual certifications, we note that these certifications will not be part of the EU scheme, since CSA aims at products, services and processes. Certifications for individuals can be referenced in the scheme are prerequisites to achieve technical requirements and rules in the different levels of assurance. This work has identified the certification options below for EC:
EC should explore the current landscape of existing threat intelligence and red- teaming certifications for individuals. Once this exercise is concluded, the most relevant certifications should be mapped to the roles within the threat intelligence teams and the red teams of the service providers. ECB has already provided the most relevant certifications mapped to the roles of the service providers’ teams50. See below table for the relevant identified certifications for the Threat Intelligence Manager and the Red Team Test Manager roles of the service providers.
34
STANDARDS SUPPORTING CERTIFICATION December 2019
Table 8: Relevant certifications for TIBER-EU Threat Intelligence Manager and Red Team Test Manager50
Certification Body Qualification
CREST Certified Threat Intelligence Manager (CCTIM)
CREST Certified Simulated Attack Manager (CCSAM)
Offensive Security Offensive Security Certified Expert (OSCE)
Table 9: Relevant certifications for TIBER-EU threat intelligence and red team members24
Certification Body Qualification
CREST - Others CREST Certified Simulated Attack Specialist (CCSAS)
ISACA Cybersecurity Nexus (CSX)
Certified Information Systems Security Professional (CISSP), (ISC)2 Systems Security Certified Practitioner (SSCP)
GIAC Penetration Tester (GPEN), GIAC Web Application Penetration Tester (GWAPT), GIAC Exploit Researcher and SANS Institute - GIAC Advanced Penetration Tester (GXPN), GIAC Mobile Device Security Analyst (GMOB), GIAC Assessing and Auditing Wireless Networks (GAWN)
Offensive Security Certified Professional (OSCP), Offensive Security Wireless Professional (OSWP), Offensive Security Offensive Security Exploitation Expert (OSEE), Offensive Security Web Expert (OSWE)
eLearnSecurity Certified Professional Penetration Tester Others (eCPPT), EC-Council Certified Security Analyst (ECSA), Licensed Penetration Tester (LPT), Certified Ethical Hacker (CEH)
Another option for EC would be to sign an agreement with a third-party concerning individual cybersecurity certifications for professional development. For example, in 2016, the Hong Kong Monetary Authority (HKMA)62 introduced the Intelligence Led Cyber Attack Simulation Testing (iCAST)63 testing. Among other organisations that can certify individuals for participating in iCAST tests, a new tailored certification programme has been created which is supported by CREST64,65. It is assessed that HKMA selected CREST based on its prior experience and participation in implementing CBEST framework in UK.
62 https://www.hkma.gov.hk/eng/ 63 https://www.hkma.gov.hk/media/eng/doc/key-information/guidelines-and-circular/2016/20161221e1.pdf 64 https://www.riskinsight-wavestone.com/en/2016/08/hong-kong-cybersecurity-program-cybersecurite-banking-industry/ 65 https://itsecurity.org/hkmas-cyber-fortification-initiative-cfi-part-1-2/
35
STANDARDS SUPPORTING CERTIFICATION December 2019
6. ANALYSIS OF THE STANDARDS LANDSCAPE ON E-HEALTH RECORDS
This section introduces the current situation in sharing Electronic Healthcare Records (EHR) with respect to existing standards, architectural models, and best practices for cybersecurity.
6.1 OVERVIEW OF LANDSCAPE FOR EHR Electronic Health Records (EHR) reached a substantial maturity level in Europe. With the advent of the e-Health Digital Service Infrastructure66, member states started to share medical data cross-border to improve the European citizens’ freedom of movement. As a result, member states utilised international health-record exchanges to enhance their national e-Health infrastructure. Of notice, the Austrian ELGA67 and the Italian FSE68 are connecting regional EHRs to a central national infrastructure to facilitate future EHR sharing at European scale. These initiatives leverage interoperability as an intrinsic factor to create EHRs.
However, achieving interoperability at a large scale is a complex matter. The European commission started the European Interoperability Framework (EIF) defining the principles for interoperability in public services, spanning different viewpoints69 e.g., from Legal to Technical interoperability. Similarly, the Healthcare Information and Management Systems Society (HIMSS) classifies interoperability in Foundational, Structural, Semantical, and Organizational70.
Focusing on the implementation level, the European Interoperability Reference Architecture (EIRA) provides guidelines and specifications, following the concepts of enterprise architectures. EIRA aims to provide re-usable building blocks that can guarantee technical and economical sustainability. Notably this model is re-used in other critical sectors as well: in the Energy sector, the Smart Grid Architectural Model71 (SGAM), or by the Reference Architectural Model for Industry 4.072 (RAMI 4.0); all these efforts provide architectural models to underpin projects with strong focus on interoperability.
The healthcare sector (worldwide73) uses a similar architectural model, named “Integrating the Healthcare Enterprise” (IHE)74. IHE provides domains (such as IT Infrastructure, Patient Care Device, Eye Care, and Radiation Oncology). Each domain publishes a technical framework containing Profiles, a set of actors and transactions that fulfil requirements for specific clinical use cases. IHE profiles utilise existing standards (such as OASIS, W3C, DICOM, and HL7) as implementation guidelines to fulfil requirements for the use cases. IHE is involved in the development of standards under ISO/TC 21575.
66 https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/eHealth+DSI+Operations+Home 67 https://elga.gv.at/index.html 68 https://www.fascicolosanitario.gov.it/il-fascicolo 69 https://ec.europa.eu/isa2/eif_en 70 https://www.himss.org/library/interoperability-standards/what-is-interoperability 71 https://www.cencenelec.eu/standards/Topics/Smartgrid/Pages/Default.aspx 72 DIN SPEC 91345:2016-04 73 IHE profiles are used for the creation of IT Architectures for the exchange of Electronic Health Records. The already mentioned pan-European exchange eHealth DSI, the Nationwide Healthcare Information Network73 in USA, ELGA, the Italian FSE, etc, are examples. 74 http://www.ihe.net 75 https://www.iso.org/organization/548404.html and https://www.ihe.net/news/ihe-granted-iso-liaison-d-status/
36
STANDARDS SUPPORTING CERTIFICATION December 2019
Inter alia, IHE specifies profiles for the secure exchange of EHR. IHE’s role in specifying cybersecurity profiles is recognised76 by the Commission77,78, by the World Health Organization79 and by the Interoperability Standard Advisory80. Other emerging standards, which attract attention, are HL7 FHIR81 and Personal Connected Health82. The role of IHE is to cooperate83 with these initiatives to ensure technological sustainability in healthcare IT projects by providing (“wrapping”) profiles over a selected set of specifications.
IHE-based architectures are built by choosing those profiles that match with specific use cases. After this phase, profiles are grouped, i.e., their functionalities (namely the functionalities profiled from the underlying standard) are merged. Cybersecurity is a basic, horizontal profile grouping. This means that every architecture based on IHE profiles will have the same initial security countermeasures for the exchange in place. In particular, IHE provides the foundation for the following elements:
Time synchronisation: time synchronisation across medical actors (e.g., devices, infrastructures) is achieved by means of the Network Time Protocol (NTP); Establishment of secure communication channels by means of TLSv1.284 with modern cipher suites: communication channels are secured by means of the WS-Security profiles (XML encryption85 and digital signature of parts of the message exchanged), and the certificate used in the TLS handshake. Signature verification is also used to authenticate and identify the sending (and receiving); Secure Node via an existing Public Key Infrastructure86: A secure node is a device for which access to health data is only possible through secured IHE transactions (therefore keeping the data confidential also from the system administrators). By using the grouping mechanism and ensuring that the security profile is applied horizontally to all architectures, each profile (e.g., a medical device or an X-Ray machine) is a secure node. Each transaction is subject to a mandatory audit trail using the syslog (rfc5424) protocol87 to achieve accountability; Authentication of principals: SAML assertions88 and JSON Web Tokens89 are used as a means to carry the identity of the principal across different trust zones. An adaptation of the IHE profile using SAML and the eIDAS regulation (EU 910/2014) has been performed90 by Deloitte under the supervision of the EU commission in the context of the establishment of the cross-border patient summary exchange; Authorisation and informed patient consent: patients can declare their freely given informed consent for the handling data concerning health in paper format (and then rendered as an electronic document), or directly as XACMLv2.091 policies;
76 https://gazelle.ihe.net/files/IHE_and_Cybersecurity.pdf 77 With Commission Decision 2015/1302 and the Commission Recommendation 2019/800 of 6/2/2019 on a European Electronic Health Record Exchange Format 78 See also D5.4.3.1, Report on Standardisation Developments in eHealth, by the Joint Action to Support the eHealth Network (jasehn.eu). 79 WHO Guideline: “Recommendations on Digital Interventions for Health System Strengthening”, available at https://apps.who.int/iris/bitstream/handle/10665/311941/9789241550505-eng.pdf 80 US Department of Health and Human Services, Interoperability Standards Advisory, http://www.healthit.gov/isa/ISA_Document/Appendix_I 81 http://hl7.org/fhir 82 https://www.pchalliance.org/ 83 See, e.g., https://www.healthcareitnews.com/news/onc-partners-ihe-advance-interoperability-standards, and https://www.healthcareitnews.com/news/joint-task-force-simplify-merging-personal-health-data-ehrs-drafts-fhir-spec 84 https://tools.ietf.org/html/rfc5246 85 https://www.w3.org/TR/xmlenc-core1/ 86 This is the Audit Trail and Node Authentication (ATNA) profile from the ITI Technical Framework 87 Notably that audits are sent on best effort, thus they can be lost. Only the e-Health DSI has a specific means using ISO 13888 to establish a non-repudiation mechanism. 88 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security 89 https://tools.ietf.org/html/rfc7519 90 DG Informatics, Final Report on the use of CEF eID in the CEF eHealth DSI, 2016 91 https://www.oasis-open.org/committees/xacml/
37
STANDARDS SUPPORTING CERTIFICATION December 2019
Digital Signature: an eIDAS-aware profile for the signature of medical data is based on ETSI EN 319 132-1.
6.2 POTENTIAL CANDIDATE CYBERSECURITY CERTIFICATION SCHEME FOR SHARING EHRS
6.2.1 Potential product/service or process that can be evolved to a cybersecurity certification scheme. EHR exchange based on IHE undergoes continuous testing by holding events named connect- a-thons92. Connect-a-thon events are week-long occurrences where vendors perform interoperability and conformance testing with other vendors and software tools. Skilled personnel verify the evidence on test results. The test-bed software used, Gazelle93 is aligned with the CEN Global eBusiness Interoperability Testbed Methodologies94, therefore guaranteeing interoperability in test definitions and reuse of test assets. Public connect-a-thons (held multiple times per year in different geographical locations) are not accredited by a certification scheme: their aim is to show evidence in public tenders of the implementation of a specific set of profiles (listed in Vendor’s integration statements documents95).
The methodology is already in use for certification purposes; the eHealth Digital Service Infrastructure (eHDSI) is using private connect-a-thons between participating member states (named project-a-thons) as one of the requisites to enter in operation96. Switzerland’s Electronic Patient Record created several project-a-thons97 to test interoperability and conformance with the Swiss EHR specifications to help vendors to achieve the final Certification98, required by the Federal Act on Electronic Patient Record (EPRA)99. This certification scheme, apart from achieving interoperability, has a strong focus on the certification of cybersecurity national extensions to IHE profiles. PCHA offers an ISO/IEC 17025:2016 and 17065:2016-based certification process100 to prove conformance with their standard. Similarly, HL7 offers FHIR connect-a-thons to test interoperability with FHIR-based specifications.
Notably, based on the tools used in connect-a-thons, the EU H2020 project EURO-CAS has devised a specific Conformity Assessment Scheme (CAS). In the project’s deliverable it has been highlighted the existence of national and regional-wide conformity assessment scheme and the need to provide an EU-level framework to show the fulfilment of specific standards (initially a set of IHE profiles) performed by laboratories accredited based on ISO/IEC 17025:2018. The outcome of the analysis of the System Under Test (viz-a-viz the EHR system) is aimed at being the basis for any project-specific certification process.
6.2.2 Assurance levels based on risk assessment The EU 2016/679 treats data concerning health (thus, the basis of the EHR) as a special category. Moreover, EU 2016/1148 Annex II classifies “healthcare care settings (including hospitals and private clinics) as operators of essential services”. In its opinion paper on policies regarding the eIDAS eID101, the Joint Action to Support the eHealth Network (JASeHN.eu) suggests that exchanges of EHR should use an eIDAS “substantial” level scheme. There is,
92 https://www.ihe.net/participate/connectathon/ 93 https://gazelle.ihe.net 94 https://www.cen.eu/work/areas/ict/ebusiness/pages/ws-gitb.aspx 95 https://www.ihe.net/testing/ihe_product_registry/ 96 https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Test+Framework . Notably another pillar to show the readiness of operation is the Audit Framework, https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/Audit+Framework 97 https://www.e-health-suisse.ch/en/technik-semantik/epr-projectathon.html 98 Eidgenössisches Departement des Innern EDI, Bundesamt für Gesundheit BAG, Swiss Interoperability Conformity Assessment Scheme (SIAS), version 1.1 99 https://www.admin.ch/opc/de/classified-compilation/20111795/index.html 100 https://www.pchalliance.org/continua-certification-process 101 JASeHN, Recommendation paper on Policies Regarding eIDAS eID, adopted the 15th May 2018
38
STANDARDS SUPPORTING CERTIFICATION December 2019
however, a push from member states to adopt the “high” eIDAS “assurance” scheme. Such private data is defined in the USA as Protected Health Information (PHI) covered in the Health Insurance Portability and Accountability Act (HIPAA) Security Rule102. HIPAA establishes “national standards to protect individuals’ electronic personal information that is created, received, used, or maintained by a [covered] entity”103” effectively setting a precise security context to the processing of PHI.
Data concerning health in the form of EHR are thus assets, which cross the border of different security zones (crossing between healthcare facilities and hospitals takes place sometimes by using public internet). Such sharing of data can potentially expose the life of a patient at risk, resulting in requiring levels of assessment in the scheme to be either “substantial” or “high”. Therefore, software systems operating EHR exchange shall comply with certification schemes (according with Art. 52 of the CSA) with assurance level “substantial” or “high”. A potential difference between the two levels could be “substantial” for software, which deals only with patient demographics (e.g., name, treatment relationships), and exchange of medical documents for treatment purposes, while “high” can be used for software components that effectively exchange medical documents.
6.2.3 Potential rules/standards for the schemes Article 51 of the CSA specifies that, on of its aims is to “protect stored, transmitted of otherwise processed data against accidental or unauthorised storage, processing, access or disclosure during the entire life cycle of the ICT product, ICT service or ICT process”. The current available schemes mentioned in this section do not tackle the lifecycle of a product. Yet, they consider the lifecycle of the specification (i.e., the IHE process is coded within ISO/TR 28380 under the TC 215), which is crucial for the technological sustainability of the standard and thus of the associated certification scheme. However, they do not specify any Software Development Life Cycle (SDLC). As an example, the e-SENS project evaluated the Reference Model for Information Assurance and Security (RMIAS) in conjunction with modular architectures to build secure-by-design ICT systems SDLC-aware104.
Moreover, Article 51 prescribes to carry out a review to verify that ICT products, services and processes do not contain known vulnerabilities. Current conformity assessments do not tackle this important point yet, since they tend to prove the conformity with a given set of specifications. However, such set of specifications may not represent all the details of an implementation, thus an additional technical rule has to be included that will be based on well- established methodologies for identifying vulnerabilities (e.g., OWASP top ten105 ). For the “high” assurance level, a further constraint is proposed: the use of penetration testing. EURO- CAS has coined the concept of “test plan” that could be exploited to define the various profiles to be certified. A test plan is a set of test assertions aimed at specifying a test scenario.
OASIS Test Assertion Guidelines (TAG)106 (also used in 퐼푆퐴2 and implemented also by the Gazelle test suite) provide a methodology to express conformity rules by issuing predicates on test assets, enabling the reproducibility of a conformity assessment.
Test assertions are created upon the constraints of the specifications (e.g., those indicated using the keywords “MUST”, “MAY” from rfc2119107) indicating the prescription levels. In IHE Connect-a-thons, vendors execute mandatory tests and are encouraged to further comply with the optional tests (which, as architectural variability points, may be further enforced by projects).
102 https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/combined-regulation-text/index.html?language=es 103 https://www.hhs.gov/hipaa/for-professionals/security/index.html 104 E-SENS EIRA Architectura Evaluation v1.0, 7/4/2017, Deliverable 6.4 105 https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project 106 https://www.oasis-open.org/committees/tag/ 107 https://www.ietf.org/rfc/rfc2119.txt
39
STANDARDS SUPPORTING CERTIFICATION December 2019
Regarding the security aspects which pertain to the deployment environment (e.g., policies for user accreditation, eventual additional means to access medical data not specified by IHE profiles), these can be elicited by using a questionnaire (to test the ATNA profile) mediated by the testing platform108. Vendors declare how such procedures are implemented in their product in a free-text form, which are then evaluated by qualified personnel. This test assertion is set as a pre-requisite for all other vendors: they must demonstrate their security capabilities before proceeding in further qualification.
The use of modular architectures also allows for re-certification of specific software components, bound to the lifecycle of the specification for the given component. For example, IHE profiles have a lifecycle of a year where they could receive an update and thus a re- certification will be required. However, critical security patches usually follow the Change Proposal process, with a quicker timing109, and re-certification may not be necessary.
IHE, HL7, and DICOM provide the specifications driving the sharing of Electronic Health Records.
IHE offers a conformity assessment for software based on its specifications https://www.ihe.net/testing/conformity-assessment/ (ISO 17025) HL7 offers Personal-level certifications http://www.hl7.org/certification/ Personal Connected Health Alliance offers a conformity assessment for their specifications https://www.pchalliance.org/continua-conformity-assessment ETSI provides a set of Plug-tests for testing interoperability https://www.etsi.org/about/our-expertise
It is worth noting the work produced by an H2020 project named EURO-CAS on designing conformity assessment schemes and it is based the IHE CASC. By exploiting the concept of test plans, EURO-CAS could achieve the requirements set by the certification profiles as pointed in Article 52, by defining test plans for the substantial, and high profiles.
The OWASP top 10 project provides a list of the most critical web application security risks, and it is actively maintained and freely available. It contains security vulnerabilities found by a community of security experts. Moreover, OWASP publishes two additional resources: the “Cheat Sheet” series 110(a set of documents tackling specific security aspects for products and development paradigms e.g., SAML security, REST security, etc.) and the Application Security Verification Standard (ASVS)111, laying down the basic requirements for secure development.
For the creation of certification profiles, the same procedure for the ATNA questionnaire could be used, without adding too many requirements for specific deployment models (e.g., portals, RESTFul services) as indicated in the ASVS or in the Cheat Sheets series. However, those documents may be used by the vendor as evidence of fulfilment for an OWASP top ten security risk. Vendors can elaborate in the existing tool (i.e., Gazelle) countermeasures taken for a specific risk. Table 10 shows an example of questionnaire with answers.
Table 10: Sample Questionnaire for the Basic Certification Profile
OWASP Top 10 link Vendor’s answer
A3:2017 Sensitive Data Exposure. A: The system prevents data related to health (i.e., already Please describe how the Software classified) to be disclosed in uncontrolled zones by
108 https://gazelle.ihe.net/content/11106-atna-questionnaire 109 https://wiki.ihe.net/index.php/Category:CPs 110 https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html 111 https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
40
STANDARDS SUPPORTING CERTIFICATION December 2019
Under Test avoids disclosing of data encrypting when in rest, and using only IHE secured and related to health. encrypted transactions when in transit.
A4:2017 XML External Entities (XXE). A: The system follows the recommendations from the Please describe how the system is OWASP Cheat Sheet ‘XXE Prevention’. In particular, preventing attackers to exploit loading of external entities from XML is disallowed, and all vulnerable XML processors when the XMLs follows a specific XSD schema, stored on a uploading XML containing hostile signed file on the disk. content (e.g., within a CDA document)
The “substantial” certification profile implies testing with automated tools to produce repeatable results. Since the scope is on providing CAS for the sharing of Electronic Health Records, the focus of the test plan for the substantial profile is on securing the communication channel in respect of confidentiality, accountability, and integrity of data in transit112. It is worth noting that the granularity of access control rules, identity attributes, and strength of encryption algorithms is a peculiarity of each local EHR exchange. For this reason, IHE and HL7 leave variability points in those security profiles, which define consent enforcement and identification procedures; a certification profile should be agnostic to these variability aspects. However, a software product shall prove its capabilities towards enforcing identification, authentication, and authorization rules, as suggested in the following bullet points:
Confidentiality: ensure that the data transits only over mutually-authenticated encrypted TLS channels (e.g., following BCP 195113), that the message exchanged between the parties containing personal healthcare information bears an authentication token (i.e., either a SAML assertion or a JWT token114), and that a basic Opt-In, Opt-Out scenario can be enforced (leaving further granularity to project-specific acceptance criteria). Those steps are inspired by the current approach115; Accountability: ensure that for each message there exists audit trail (one per communicating party) containing information on “who” performed an event (authentication information), “when” the event happened (implies time synchronization testing), “what” event happened (a code specifying the event), “for which resource” (for instance, a document, a patient identifier), and “using which server”, e.g. IP address information, or certificate Distinguished Name (DN)116; Integrity: ensure that the intermediaries do not manipulate the data. Moreover, ensuring medical data provenance is crucial also to allow the patients to recognize any violation of its consent due, e.g., to a secondary use of its data related to health117. Conformance with ETSI signature standards or with IHE mXDE118 and QEDm119 profiles may fulfil the requirements.
For the “high” certification profile, an additional penetration test requirement and a source code review that will be economically feasible may be required. However, there is not yet any standard procedure available, although source code reviewers follow best practices120.
112 Notably the aspect of availability (part of the usual CIA triad) is not under this certification profile. The availability is typically defined at project level (with decision depending on the type of medical procedures, emergency accesses) and it tackled by ensuring the interoperability levels. 113 https://tools.ietf.org/html/bcp195 114 As specified by the IHE XUA and IUA profiles, User-Managed Access (see https://kantarainitiative.org/confluence/display/uma/Home) Smart on FHIR (https://docs.smarthealthit.org/), and the eIDAS regulation 115 See e.g., ATNA tests: https://gazelle.ihe.net/content/atna-tests, XUA https://gazelle.ihe.net/content/11120-assertions- xua-testing, or introduction to BPPC testing https://gazelle.ihe.net/content/16405-bppc-privacy-policy-connectathon-testing. 116 Note that this schema is compliant with rfc 3881 and DICOM appendix 3.15 http://dicom.nema.org/medical/dicom/current/output/html/part15.html 117 See Xu, S., Rogers, T., Fairweather, E., Glenn, A., Curran, J., & Curcin, V. (2018). Application of Data Provenance in Healthcare Analytics Software: Information Visualisation of User Activities. AMIA Joint Summits on Translational Science proceedings. AMIA Joint Summits on Translational Science, 2017, 263–272. 118 https://wiki.ihe.net/index.php/Mobile_Cross-Enterprise_Document_Data_Element_Extraction 119 https://wiki.ihe.net/index.php/Query_for_Existing_Data_for_Mobile 120 See, e.g., the SEI Secure Coding Guidelines for various languages https://wiki.sei.cmu.edu/confluence/display/seccode
41
STANDARDS SUPPORTING CERTIFICATION December 2019
7. ANALYSIS OF THE STANDARDS LANDSCAPE IN RELATION TO QUALIFIED TRUST SERVICE PROVIDERS
The objective of this chapter is a recommendation path for the definition of an accreditation scheme for the eIDAS regulation121, taking into account the variety of standards that apply so far to the certification of Trust Service Providers (TSPs) requiring the qualification status. For stakeholders – such as relying parties and end users – to build and maintain confidence in the security of qualified trust services (QTS), they need to have the assurance that qualified trust service providers (QTSPs) have established a set of procedures, processes and security measures to minimize the associated operational and financial threats and risks. Under eIDAS regulation, this is accomplished when accredited Conformity Assessment Bodies (CABs) conduct audits.
The eIDAS Regulation does not define technical criteria and does not impose any specific accreditation scheme against which CABs must be accredited or any specific standard that QTSPs or QTS need to follow in order to obtain a qualified status. Therefore, there is room for individual interpretation and development. Considering standards, policies and requirements, the success or acceptance of the eIDAS audit scheme depends on several factors that hinder the further recognition of the scheme:
non-existent statutory/mandatory specification of any (but especially the ETSI/CEN) standards, which were developed as a basis for the eIDAS - compliant operation of (Q)TSPs the lack of harmonization of requirements within the EU (and thus beyond) at the level of CABs accreditation and certification scheme for TSP auditing the restricted possibilities for the visibility of trust generated by the scheme
7.1 OVERVIEW OF EIDAS REGULATION ON QUALIFIED TSP AND TRUST SERVICES Regulation (EU) No 910/2014 (hereafter the eIDAS Regulation), on electronic identification and trust services for electronic transactions in the internal market, provides a regulatory environment for electronic identification of natural and legal persons and a set of electronic trust services, namely electronic signatures, seals, time stamps, registered delivery services and certificates for website authentication122.
Error! Reference source not found. illustrates all the trust services, features and indeded a udiences. To enhance the trust of small and medium-sized enterprises (SMEs) and consumers in the internal market and to promote the use of trust services and products, the eIDAS Regulation introduces the notions of QTS & QTSP. QTSs and their providers must comply with requirements and obligations that ensure high-level security of whatever qualified trust service or product is used or provided and, therefore, these are granted a higher presumption of their
121 Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC 122 Art.3.16 of the eIDAS Regulation for the definition of trust services
42
STANDARDS SUPPORTING CERTIFICATION December 2019
legal effect. Therefore, when consumers search for trust services, selecting those, which are qualified, ensures a high level of security and legal certainty of trust services.
Figure 7: eIDAS picture
7.1.1 Initiation and supervision The eIDAS Regulation foresees an active supervision scheme for the QTSP and the QTS they provide, by the national competent supervisory body (SB). SBs supervise, ex-ante and ex-post, the fulfilment of the QTSP/QTS requirements and obligations. QTSPs may only begin to provide the qualified trust service after the competent SB grants the qualified status and the QTSP/WTS is included in the national trusted list. From there, the supervision scheme covers the full life- cycle of each QTS and each QTSP, from its inception to its termination.
In practice, when TSPs without qualified status intend to start providing qualified trust services, they submit to the supervisory body a notification of their intention together with a conformity assessment report issued by an “eIDAS” accredited conformity assessment body. Before notifying the competent SB of its intention to start providing qualified trust services, the potential QTSP/QTS must successfully pass an external assessment (audit) to confirm it fulfils the eIDAS requirements. The CAB, which will conduct the audit, must be accredited specifically to carry out assessments of QTSP/QTS. The audit results in a formal conformity statement verifying - if such is the case - that the QTSP/QTS meets all the applicable requirements of the eIDAS Regulation. Based on the notified information, including the report of such an audit, the competent SB will formally confirm that the candidate QTSP/QTS meets, if that is the case, the applicable eIDAS requirements before publishing the qualified status for that QTSP/QTS in the national trusted list.
It should be noted that a TSP cannot be qualified without providing at least one qualified trust service (cfr Art.3.20 of the eIDAS Regulation). Moreover, a TSP is granted a qualified status separately for each type of qualified trust service covered by the eIDAS Regulation.
Once granted a qualified status, QTSPs and their QTSs have the obligation to successfully conclude an assessment and submit to the competent SB a conformity assessment report (CAR) biannually. CARs are issued only by accredited CABs, confirming that the QTSP and the QTSs it provides continue to fulfil the requirements laid down in the eIDAS Regulation. Competent SBs are allowed in their own discretion and at any time, to perform audits on any QTSP/QTS or to request an accredited CAB to perform an ad-hoc audit.
In order to ensure sustainability and durability of QTSs, QTSPs must always maintain an up-to- date termination plan. That plan is approved by the SB the first time a TSP acquires a qualified status and it should be regularly checked for compliance during the life of the QTSP/QTS. ENISA has published relevant reports regarding QWACs, qualified electronic signatures, seals, time stamps and eDelivery. These documents aim to raise awareness on the benefits of using
43
STANDARDS SUPPORTING CERTIFICATION December 2019
such products and underpin efforts to enhance growth of a European market for QWACs (ENISA, 2017)
7.1.2 TSP supervisory scheme National Accreditation Bodies (NABs) contribute to the quality assurance of the whole process by being responsible for accrediting CABs that perform the conformity assessment audits for the TSPs. Each NAB determines the ability of a CAB for conducting conformity assessments in accordance with (specific) accreditation criteria. To this day, there is no implementing act nor any other statement to harmonise this process.
The European Accreditation (EA) is the body recognised under Regulation (EU) No 765/2008 that organises the peer evaluation scheme among the NABs from the EU Member States and other European Countries. ETSI, in collaboration with the EA and with representatives of the interested parties, has developed a specific standard (ETSI EN 319 403123) for the accreditation of CABs. The ETSI EN 319 403 defines an accreditation scheme that requires the accreditation of CABs to be based on ISO/IEC 17065. It further supplements ISO/IEC 17065 by defining specific requirements that assess CAB’s capabilities in performing conformity assessments (certification).
It is worth mentioning that for a specific certificate type for website authentication, QWACs, browsers require access to the same CAR provided by the CAB.
7.2 OVERVIEW OF STANDARDS’ LANDSCAPE
7.2.1 eIDAS Regulation requirements The eIDAS Regulation foresees a set of requirements and obligations for QTSP/QTS in order to ensure high-level security. These obligations include:
Processing of personal data shall be carried out in accordance with Directive 95/46/EC124 and the EU GDPR regulation 2016/67937. The TSP is liable for any damage caused intentionally or negligently to natural or legal persons due to a failure to comply with the obligations under this Regulation, while the intention or negligence of a QTSP shall be presumed, unless proven otherwise by QTS. When a TSP informs customers in advance on limitations on the use of its services, and when such limitations are recognisable to third parties, then the TSP is not liable when these limitations have been exceeded. Where feasible, services must be accessible for people with disabilities. TSPs need to implement appropriate technical and organisational measures to manage the risks posed to the security of the trust services they provide. Having regard to the latest technological developments, those measures shall ensure that the level of security is commensurate to the degree of risk. Measures shall be taken to prevent and minimize the impact of security incidents and inform stakeholders of the adverse effects of any such incidents. Very strict rules regarding the obligation of notifying security & personal data breaches are imposed. Additional requirements on QTSP operations and practices: Inform SBs of any change in QTS and of their intention to cease; Have an up-to-date termination plan, agreed with the competent SB, to ensure continuity of service;
123 ETSI EN 319 403, Electronic Signatures and Infrastructures (ESI);Trust Service Provider Conformity Assessment - Requirements for conformity assessment bodies assessing Trust Service Providers, https://www.etsi.org/deliver/etsi_en/319400_319499/319403/02.01.01_20/en_319403v020101a.pdf 124 Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, https://eur-lex.europa.eu/legal- content/en/TXT/?uri=CELEX%3A31995L0046
44
STANDARDS SUPPORTING CERTIFICATION December 2019
Requirements on employed staff and subcontractors, when used; Sufficient financial resources and/or liability insurance, in accordance with national law; Consumer information on terms and conditions, including on limitations on use; Use of trustworthy systems and products ensuring the technical security and reliability of the supported processes; Use of trustworthy systems to store (personal) data in a verifiable form; Appropriate measures against forgery and theft of data; and Record and keep accessible activities related data, issued and received, even after cessation of activities. Specific requirements as laid down in the eIDAS Regulation concerning the provision of a specific type of qualified trust service.
All these requirements must be met by the QTSP/QTS before issuing the very first qualified trust service output. However, it is not indicated how these requirements can be met. There are standards to follow that are recognised as best practice by the industry that can assist in evaluating when a TSP can acquire the qualification status.
7.2.2 ETSI certification scheme
ETSI EN 319 401125 specifies general requirements for TSPs. The main documents for the evaluation of the TSPs that issue certificates are ETSI EN 319 411 part 1 for public key certificates and part 2 for the issuance of qualified certificates. When auditing against ETSI EN 319 411-1 or -2 (or any other eIDAS trust service), there exist requirements in these documents which reference ETSI EN 319 401. Therefore, checks against relevant ETSI EN 319 401 requirements are carried out when conducting an ETSI EN 319 411-1 and/or -2 audit.
ETSI EN 319 411-1 specifies applicable policy and security requirements for TSPs issuing public key certificates, including trusted website authentication certificates. It provides guidance to the TSPs on how to develop, implement, enforce and update the Certification Practise Statement (CPS) (which describes the practices and procedures used to address all the requirements identified for the applicable TSP's policy) and the Certificate Policy (CP) (which refers to the CPS to indicate how the TSP implements the policy requirements for the selected CP). ETSI EN 319 411-2 specifies policy and security requirements for the issuance, maintenance and life-cycle management of EU qualified certificates as defined in the eIDAS Regulation.
7.2.3 WebTrust for CAs assurance audit WebTrust is a well-accepted commercial audit scheme for TSPs. WebTrust assessments are performed by independent accountant firms, which are recognized by Chartered Professional Accountants (CPA) Canada126. As a rule-based assurance audit, the WebTrust scheme aims to review the implementation and operational effectiveness of controls over a period of time. The rationale behind WebTrust is that the services offered by TSPs have verifiably met a rigorous set of defined criteria. The operational assumption is that fulfilling a checklist of objectives is similar to fulfilling the obligations to security for which TSPs are responsible in their operations. Similar to the ETSI scheme, WebTrust is inherently interested in past performance. Since CPA is the only responsible accreditation body for this scheme, ambiguity on interpreting requirements differently is prohibited, therefore ensuring harmonisation across audits.
7.2.4 Cab Forum, CAs and browsers
125 ETSI EN 319 401, Electronic Signatures and Infrastructures (ESI);General Policy Requirements for Trust Service Providers, https://www.etsi.org/deliver/etsi_en/319400_319499/319401/02.02.00_20/en_319401v020200a.pdf 126 https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services
45
STANDARDS SUPPORTING CERTIFICATION December 2019
eIDAS refers to a type of trust service which is specific for the authentication of the web sites. Authentication is achieved by issuing a certificate for the SSL/TLS authentication process named Qualified Website Authentication Certificate (QWAC). The CAB Forum holds a pivotal role in the issuance of the qualified certificates for website authentication despite the fact that their actions or decisions do not relate nor take into account eIDAS provisions.
The CAB Forum127 is an unincorporated association of Certification Authorities (CAs), which are the equivalent of TSP under the eIDAS nomenclature, vendors of Internet browser software (usually known as browsers) and suppliers of other applications that use X.509 v3 digital certificates for SSL/TLS. The CAB Forum provides guidance to the CAs/TSPs on best practices for the issuance and management of the publicly trusted certificates.
The documents published by the CAB Forum cannot be considered standards. However, Standards Organizations can adopt these to design standards that CAs/TSPs have to comply with. ETSI and WebTrust, in particular, update their standards regularly by following the recommendations of the CAB Forum.
The CAB Forum produces two different documents for the issuance and management of the certificates for website authentication. The first defines the baseline requirements and the second provides a guideline named EV (Extended Validation). EV describes additional information such as what needs to be included in the subject field for a clear identification in the browser bar with a distinct and unique feature (coloured in green).
Apart from the CAB Forum documents, the browsers impose specific requirements indicated in their respective root programs. These root programs further increase the complexity of the audits performed by the CABs. CABs perform audits according to standards that do not include nor reflect requirements that browsers request for their root store programmes. The additional requirements imposed by browsers when QTSPs issue QWACs may result in greater divergence in the content of CARs that CABs produce.
7.2.5 ISO/IEC 27000 series The ISO/IEC 2700030 series represents the information security family of standards, which provides recommendations for the management of information security and covers a wide range of general network and information security concerns.
Whereas ISO/IEC 27000128 and ISO/IEC 27001129 outline foundational elements of information security management systems (ISMSs), ISO/IEC 27002130 details a CP concerning the information security controls that a TSP needs to deploy. Recommendations laid out in ISO/IEC 27006131, ISO/IEC 27007132 and ISO/IEC 27008133 comprise guidelines for auditing a management system and the security controls that a TSP possess. The trust scheme of ISO is very similar and comparable to ETSI certification framework.
While there is currently no dedicated ISO standard for PKI nor for practices and corresponding policy frameworks134, ISO is currently drafting such a standard as a new work item (ISO/IEC JTC 1/SC 27), tentatively entitled, “Information Technology – Security techniques - Public key infrastructure - Practices and policy framework” (ISO SC 27/2WG4). The new work item will make use of concepts and requirements of ISMS, as defined in ISO/IEC 27000 and ISO/IEC
127 https://cabforum.org/ 128 https://www.iso.org/standard/73906.html 129 https://www.iso.org/standard/54534.html 130 https://www.iso.org/standard/54533.html 131 https://www.iso.org/standard/62313.html 132 https://www.iso.org/standard/67398.html 133 https://www.iso.org/standard/67397.html 134 A standard does exist, however, it targets the financial sector and it is ISO 21188.
46
STANDARDS SUPPORTING CERTIFICATION December 2019
27001, respectively. It will also use the code of practice for information security controls, as defined in ISO/IEC 27002.
7.2.6 Identification of gaps in current practice to acquire a qualified status. One of the major shortcomings of the audit scheme under the eIDAS Regulation appears to be the lack of standardisation for the conformity assessment process.
All (currently) listed eIDAS-accredited CABs135 are accredited according to ISO/IEC 17065. Some CABs follow the certification scheme defined in ETSI EN 319 403, others set the scope of accreditation as per article 3.18. The majority follow all three (ISO/IEC 17065 + ETSI EN 319 403 + eIDAS art 3.18 scope of accreditation) as per guidelines issued by the The European Co- operation for Accreditation.
Despite the fact that the accreditation of all listed CABs is according to ETSI EN 319 403 (based on ISO 17065), it is not guaranteed that all SBs will interpret the final assessment criteria uniformly. This results in CABs across Member States to use variant lists of requirements when auditing a TSP. The Forum of European Supervisory Authorities for Electronic Signatures (FESA), a loose association of some European SBs and third countries, strives to coordinate SBs with limited success.
The general approach for CABs assessing the conformity of TSPs and the services they provide is presented in ETSI EN 319 403. For each step of the audit, all the general requirements for evaluating TSPs against the requirements are described in the eIDAS Regulation. However, there is currently no implementing act to enforce this standard; CABs follow the articles one by one, utilizing EN 319 403 as a supporting document. It includes the specificities of the type of trust service under assessment, various aspects of TSP activities to be covered and relevant standards (e.g. ETSI) or other potential regulatory requirements that need to be considered.
There exist CABs that may provide CARs which will not contain the minimum required information needed to assess the trust status of a TSP. A comparison of several audit reports from different European TSPs and CABs reveals a notable dissonance. The final decision regarding the qualification of the TSP and its trust services, however, is made by the correspondent SB. Each SB has its own interpretation for single requirements that may differ from one to other SB.
This may result in incongruences in the qualification of TSPs in different countries as well as their qualified trust services, leading to a heterogeneous trust service market. This divergence in the criteria for the qualified status erodes trust in the quality of QTS. The absence of a standardised CAR constitutes a challenge, but also offers an opportunity to move forward. CABs that have different interpretations of the actual scope of audits and/or the content of audit reports might be better aligned with the publication and enforcement of implementation acts for the accreditation of CABs across borders.
Finally, the CABs acquire their accreditation as a whole but they need to undergo internal processes to achieve the level of degree and knowledge required to perform the correspondent audits. These requirements can be defined internally by developing an intense training procedure, to update tools adequately, etc. It is fundamental to ensure that all CABs can provide trained and liable auditors to TSPs of similar quality.
In order to avoid inconsistent qualification of TSPs and their qualified services, it is necessary:
135 https://ec.europa.eu/futurium/en/content/list-conformity-assessment-bodies-cabs-accredited-against-requirements-eidas- regulation
47
STANDARDS SUPPORTING CERTIFICATION December 2019
to harmonize interpretations by national Supervisory Bodies on the topic of the conformity assessment criteria to be applied by all CABs to harmonize comparable / standardized application of the reconciled conformity assessment criteria by different CABs acting for the European SBs in the case of QWACs, to integrate the requirements from external bodies like the CAB Forum and browsers
7.3 POTENTIAL CANDIDATE FOR A CYBERSECURITY CERTIFICATION SCHEME The harmonisation problems derive from the lack of clearly defined criteria, despite the availability of a variety of standards that can provide such a pool of common requirements. All gaps described in the previous section can be addressed by defining a commonly accepted accreditation scheme. A possible candidate scheme can be ETSI (officially, this may not be acceptable as ETSI, despite EA’s recognition of ETSI as a scheme owner, do not run audit schemes) or the supervisory bodies through FESA.
7.3.1 Potential product/service or process that can be evolved to a cybersecurity certification scheme. The lack of a certification scheme is affecting all parties: TSPs, CABs, SBs. Currently, the same (Q)TS provided by different (Q)TSPs can be considered qualified or not depending on the SBs in the different EU member states.
Regarding QWACs, this is even more complex because there are additional parties involved, such as browsers, imposing their requirements independently of what eIDAS requires or what is defined in the accreditation scheme. Browsers have their own root program requirements and in order to be included in their trust list, commonly known as root store, TSPs have to comply with all of their rules.
Therefore, browsers have identified some issues within the current approach, which refers to the lack of harmonization of the different aspects of the process.
Hence, these are the needs in order to harmonize the market on TSPs:
CAR standardisation Standards harmonisation Auditors accreditation standardisation
Considering the criticality of the services that TSPs offer, the proposed candidate EU cybersecurity certification scheme will consist of a single high level of assurance.
7.3.2 Identification of potential rules/standards for the schemes The ETSI solution is optimal because it covers the accreditation of CABs (ISO 17065 and EN 319 403), references standards relevant to the execution of conformity assessments (EN 319 401 and 411-x, 412-x) and details how CARs should be structured. eIDAS does not refer to any standardisation bodies, as it is not the appropriate authority to mandate the accreditation scheme. It is worth mentioning that the definition and creation of the criteria and the scheme is not against the neutrality of the eIDAS regulation. On the contrary, it will facilitate all parties with tools that will streamline and harmonise the market of QTSs.
EA promoted the use of the ETSI 319 403 which incorporates ISO/IEC 17065 (“Requirements for bodies certifying products, processes and services”) for the accreditation of the CABs. ISO/IEC 17065 defines requirements for conformity assessment bodies (e.g. requirements
48
STANDARDS SUPPORTING CERTIFICATION December 2019
regarding personnel and processes). One of such requirements is to have/use a certification scheme for the products/processes/services to be certified. Either this can be a scheme maintained by the certification body itself, or it can be a public scheme maintained by some third party (e.g. a supervisory body) or just included in the eIDAS regulation.
ISO/IEC 17065 requires having or using a certification scheme. It is suggested that a potential candidate, in which this scheme can be based on, is ISO/IEC 17067136 (“Fundamentals of product certification and guidelines for product certification schemes”), which is a guideline on how to create such certification scheme. The required content, concept and objectives, the schemes, functions to have, etc. refers to ISO/IEC 17065, which is compatible.
ISO/IEC 17067 outlines how schemes for product certification can be structured and managed. It identifies common assessment techniques that are used as a basis for product certification, such as product testing, inspection and auditing. ISO/IEC 17067 provides also guidance on how to define and develop an accreditation scheme. This process should follow the technology neutral approach of the eIDAS.
This scheme is highly recommended to use different technical specifications (TS). TS of the ETSI EN 319 403 (ETSI TS 119 403-2137 and ETSI TS 119 403-3138) are fundamental in order to address the gaps identified in the quality of CARs. Their use will ensure that the content of CARs will be consistent and will address the different requirements by the competent authorities, such as the SBs or the browsers in the case of the issuance of the QWACs. Auditing for CABs will be achieved with the use of EN 411-x standards.
In conclusion, it is clear that the eIDAS regulation needs to have an accreditation scheme and therefore needs to define and develop this scheme (e.g. using ISO/IEC 17067) with a high assurance level which is built on identified criteria (e.g. ETSI standards) and set requirements on the conformity assessor (e.g. ISO/IEC 17065 + EN 319 403).
136 https://www.iso.org/standard/55087.html 137 https://www.etsi.org/deliver/etsi_ts/119400_119499/11940302/01.02.01_60/ts_11940302v010201p.pdf 138 https://www.etsi.org/deliver/etsi_ts/119400_119499/11940303/01.01.01_60/ts_11940303v010101p.pdf
49
STANDARDS SUPPORTING CERTIFICATION December 2019
8. CONCLUSIONS
This report examined five areas of interest, where standards and policies can evolve to become potential candidates for EU cybersecurity certification schemes. These five areas were Internet of Things (IoT), cloud infrastructure and services, threat intelligence in the financial sector, electronic health records in the healthcare and qualified trust services.
By providing an analysis of the standards’ landscape and identifying the gaps, this report highlighted potential products, services and processes that can be certified. For every suggested potential candidate scheme, reasonable recommendations were provided based on Articles 51, 52 and 54 of CSA.
In all five areas there were opportunities for products (smart home devices for Internet of Things area, test-beds for validating interoperability in the electronic heath records domain), processes (accreditation schemes to harmonise the process of providing a qualified status to Trust Service Providers) and services (penetration testing for the financial sector and cloud services such as Platform as a Service).
A key finding of this exercise was that for a potential EU candidate scheme to be successful, the levels of assurance should reflect the market needs. There exist technical rules in standards that can underpin guiding principles for assurance levels in all five areas. Further investigation is required on how these rules will be allocated to different levels, specifically for technical metrics which are present in all three levels with variant objectives (i.e., time to perform patch management).
50
STANDARDS SUPPORTING CERTIFICATION December 2019
REFERENCES
Cloud Security Alliance. (2019). Guide to the CSA Internet of Things (IoT) Security Controls Framework. Cloud Security Alliance. Retrieved from https://cloudsecurityalliance.org/artifacts/guide-to-the-iot-security-controls-framework/
Cloud Security Alliance. (n.d.). CCM - Cloud Control Matrix. Retrieved from https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v3-0-1/
Cloud Security Alliance. (n.d.). CSA STAR. Retrieved from https://cloudsecurityalliance.org/star/cloud-service-provider/
CSPCERT Working Group. (2019). Recommendations for the implementation of the CSP Certification scheme. Retrieved 11 30, 2019, from https://drive.google.com/file/d/1J2NJt-mk2iF_ewhPNnhTywpo0zOVcY8J/view
Directorate-General for Communications Networks, Content and Technology (European Commission) , Fundación TECNALIA RESEARCH & INNOVATION. (2019). Certification schemes for cloud computing. doi:10.2759/508460
ENISA. (2014). Cloud Certification Schemes Metaframework.
ENISA. (2014). Threat Landscape and Good Practice Guide for Smart Home and. Athens: ENISA.
ENISA. (2017). Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures. Athens: ENISA. Retrieved from https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot
ENISA. (2017). Security guidelines on the appropriate use of qualified website authentication certificates. Athens: ENISA. Retrieved from https://www.enisa.europa.eu/publications/security-guidelines-on-the-appropriate-use- of-qualified-website-authentication-certificates
ENISA. (2018). IoT Security Standards Gap analysis: Mapping of existing standards against requirements. Athens: ENISA.
ENX. (2019). enx.com. Retrieved 11 30, 2019, from https://portal.enx.com/en-US/TISAX/
Eurosmart. (2019). Eurosmart IoT Certification Scheme. Retrieved 11 30, 2019, from eurosmart.com: https://www.eurosmart.com/eurosmart-iot-certification-scheme/
Greenberg, A. (2018). The Untold Story of NotPetya, the Most Devastating Cyberattack in History. The Wired. Retrieved 11 30, 2019, from https://www.wired.com/story/notpetya- cyberattack-ukraine-russia-code-crashed-the-world/
Heyton, R. (2018). Trusted execution environments: What, how and why? Retrieved 11 30, 2019, from internetofthingsagenda.techtarget.com:
51
STANDARDS SUPPORTING CERTIFICATION December 2019
https://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/Trusted-execution- environments-What-how-and-why
Hielkema, P., & Kleijmeer, R. (2019). Lessons Learned and Evolving Practices of the TIBER Framework for Resilience Testing in the Netherlands. Carnagie Endowment For International Peace. Retrieved 11 30, 2019, from https://carnegieendowment.org/files/WP_Hielkema_Kleijmeer_TIBER1.pdf
IoT Security Foundation. (2018). Applying Technical Controls Contained in the Compliance Framework To Meet the DCMS Code of Practice. IoT Security Foundation.
ISO. (n.d.). ISO/IEC 27000:2018 - Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary.
Marsh & McLennan Companies, Zurich Insurance Group. (2019). The Global Risks Report 2019. World Economic Forum. Retrieved 11 30, 2019, from http://www3.weforum.org/docs/WEF_Global_Risks_Report_2019.pdf
National Institute of Standards and Technology. (2019). Draft NISTIR 8259: Core Cybersecurity Feature Baseline for Securable IoT Devices: A Starting Point for IoT Device Manufacturers. National Institute of Standards and Technology. Retrieved from https://doi.org/10.6028/NIST.IR.8259-draft
Newman, L. H. (2016). Retrieved 11 30, 2019, from Wired.com: https://www.wired.com/2016/10/internet-outage-ddos-dns-dyn/#
Orue-Echevarria, L., Cortés, C., Alvarez, M., Sanchez, B., & Ayerbe, A. (2018). Certification schemes for cloud computing. Luxembourg: EU Publications office. doi:10.2759/87945
Rane, A. (2017). IoT security starts with secure boot. Retrieved 11 30, 2019, from embedded- computing.com: https://www.embedded-computing.com/embedded-computing- design/iot-security-starts-with-secure-boot
Soltan, S., Mittal, P., & Poor, V. H. (2018). BlackIoT: IoT Botnet of High Wattage Devices Can Disrupt the Power Grid. 27th USENIX Security Symposium.
52
N
-
EN
-
089
-
20
- 04
- TP
ABOUT ENISA The mission of the European Union Agency for Cybersecurity (ENISA) is to achieve a high common level of cybersecurity across the Union, by actively supporting Member States, Union institutions, bodies, offices and agencies in improving cybersecurity. We contribute to policy development and implementation, support capacity building and preparedness, facilitate operational cooperation at Union level, enhance the trustworthiness of ICT products, services and processes by rolling out cybersecurity certification schemes, enable knowledge sharing, research, innovation and awareness building, whilst developing cross- border communities. Our goal is to strengthen trust in the connected economy, boost resilience of the Union’s infrastructure and services and keep our society cyber secure. More information about ENISA and its work can be found at www.enisa.europa.eu.
ISBN 978-92-9204-329-2 DOI 10.2824/40722