D5.1 Requirements Analysis of Demonstration Cases Phase1 · CyberSec4Europe D5.1 – Requirements Analysis of Demonstration Cases Phase 1 ii Abstract: This document presents deliverable

i

Proposal No. 830929 Project start: February 1, 2019 Call H2020-SU-ICT-03-2018 Project duration: 42 months

D5.1 Requirements Analysis of Demonstration Cases

Phase1

Document Identification Due date 31st May 2019 Submission date 31st May 2019 Revision 1.0 Final

Related WP WP5 Dissemination Level

PU

Lead Participant

NEC Lead Author Alessandro Sforzin (NEC)

Contributing Beneficiaries

ABI-Lab, AIT, ATOS, BBVA, CTI, CYBER, DAWEX, DTU, DUT, ENG, ISGS, i-BP, NEC, SIE, SINTEF, TDL, UCY, UMA, UMU, UPRC, UPS-IRIT

Related Deliverables

D4.1

Ref. Ares(2019)3588865 - 04/06/2019

CyberSec4Europe D5.1 – Requirements Analysis of Demonstration Cases Phase 1

ii

Abstract: This document presents deliverable “D5.1 – Requirements Analysis of Demonstration Cases Phase 1”. For all demonstration cases, it describes a set of identified use-cases together with their functional and non-functional requirements. Security and privacy requirements are treated separately from the above categories to highlight the importance of addressing the cybersecurity issues pinned down in the selected sectors. Additionally, the document serves as starting point for WP3 – “Blueprint Design and Common Research” to plan the technological advances that will allow CyberSec4Europe to address the identified cybersecurity challenges, and for WP4 – “Research and Development Roadmap” to plan the research roadmap of the project. This document is issued within the CyberSec4Europe project. This project has received funding from the European Union's Horizon 2020 Programme under grant agreement no. 830929. This document and its content are the property of the CyberSec4Europe Consortium. All rights relevant to this document are determined by the applicable laws. Access to this document does not grant any right or license on the document or its contents. This document or its contents are not to be used or treated in any manner inconsistent with the rights or interests of the CyberSec4Europe Consortium and are not to be disclosed externally without prior written consent from the CyberSec4Europe Partners. Each CyberSec4Europe Partner may use this document in conformity with the CyberSec4Europe Consortium Grant Agreement provisions and the Consortium Agreement. The information in this document is provided as is, and no warranty is given or implied that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability.

iii

Executive Summary CyberSec4Europe’s objective is to lead the European cybersecurity research and innovation efforts with technology advancements catering to the complex reality of the single market, as well as the security of European citizens and society as a whole. To this end, the project’s consortium includes a well balanced combination of industrial participants and research centers that will collaboratively identify and analyze cybersecurity industrial challenges in selected sectors, and will cooperate to develop appropriate solutions to address those challenges. This document presents a comprehensive set of use-cases and their requirements, covering the seven representative CyberSec4Europe demonstration cases. A thorough analysis of the demonstration cases produced a rich set of functional and non-functional (including security and privacy) requirements that will guide research, technology development, and design in WP3, as well as the definition of the research roadmap in WP4. The document introduces not only those requirements that are essential to ensure the use-cases correct and efficient operations, but also those that may not be met concomitantly, even though they would contribute to the research and innovation results that the project wants to achieve. This document additionally highlights security and privacy requirements for each demonstration case in order to put special emphasis to those cybersecurity issues that the project needs to address in the selected sectors. Since the project is in its initial phase, the use cases and related requirements are represented at a high-level stage. Consequently, this document further focuses on providing a coherent narrative encompassing them. A more detailed specification will be delivered in subsequent iterations of this document.

iv

Document information Contributors Name Partner Marco Crabu ABI-Lab Antonio Marrone ABI-Lab Marco Rotoloni ABI-Lab Teresa Spada ABI-Lab Mario Trinchera ABI-Lab Stephan Krenn AIT Rodrigo Díaz ATOS Juan Carlos Perez Baun ATOS Salvador Perez Franco ATOS Iñaki Aramburu Carmona BBVA Vasia Liagkou CTI Liina Kamm CYBER Peeter Laud CYBER Jeremy Decis DAWEX Alberto Lluch DTU Jolien Ubacht DUT Roberto di Bernardo ENG Giorgio Cusmà Lorenzo ISGS Médéric Collas i-BP Victor Poyet i-BP Alessandro Sforzin NEC Jorge Cuellar SIE Karin Bernsmed SINTEF Per Håkon Meland SINTEF Aida Omerovic SINTEF David Goodman TDL Elias Athanasopoulos UCY Cristina Alcaraz UMA Rodrigo Roman UMA Antonio Skarmeta UMU Elma Kalogeraki UPRC Panayiotis Kotzanikolaou UPRC Spyros Papastergiou UPRC Abdelmalek Benzekri UPS-IRIT Romain Laborde UPS-IRIT

Reviewers Name Partner Marco Crabu ABI-Lab Evangelos Markatos FORTH Welderufael Tesfay GUF


v

History

0.1 2019-02-27 NEC Initial Outline 0.2 2019-03-15 NEC Executive

Summary 0.3 2019-04-01 NEC Introduction 0.4 2019-05-10 NEC Conclusions 0.5 2019-05-08 ABI-Lab, AIT, ATOS, BBVA,

CTI, CYBER, DAWEX, DTU, ISGS, i-BP, NEC, TDL, UMU, UCY, UPRC, UPS-IRIT

Contributions to sections 3, 5, 6, 8

0.6 2019-05-09 CYBER, SIE, SINTEF, NEC, UCY, UMA, UPRC

Contributions to sections 2, 4, 7

0.7 2019-05-10 ENG, NEC, UMU Contributions to section 9

0.8 2019-05-10 NEC Quality check 1.0 2019-05-10 NEC First

complete version

1.1 2019-24-05 ABI-Lab, AIT, BBVA, NEC, ATOS, CTI, CYBER, DAWEX, DTU, DUT, ENG, ISGS, i-BP, NEC, SIE, SINTEF, TDL, UCY, UMA, UMU, UPRC, UPS-IRIT

Addressed comments of PC review.

1.2 2019-30-05 ABI-Lab, ATOS, CYBER, DAWEX, DTU, ENG, i-BP, NEC, SIE, SINTEF, TDL, TUD, UCY, UMA, UMU, UPRC, UPS-IRIT

Addressed comments of internal reviewers

1.3 2019-31-05 NEC Quality check. Ready for submission.

vi

List of Contents 1 Introduction...................................................................................................................................... 1

1.1 Structure of the Document ........................................................................................................ 1

2 Summary of the Demonstration Cases .............................................................................................. 3

2.1 Open Banking ........................................................................................................................... 3

2.2 Supply Chain Security Assurance ............................................................................................. 3

2.3 Privacy-Preserving Identity Management .................................................................................. 3

2.4 Incident Reporting .................................................................................................................... 4

2.5 Maritime Transport ................................................................................................................... 4

2.6 Medical Data Exchange ............................................................................................................ 4

2.7 Smart Cities .............................................................................................................................. 4

3 Open Banking .................................................................................................................................. 6

3.1 Goals ........................................................................................................................................ 7

Open Banking API Architecture .......................................................................................... 7

Privacy Preserving Verifiable Credentials............................................................................ 7

Open Banking Sensitive Data Sharing Network for Europe (OBSIDIAN) ............................ 8

3.2 Stakeholders ............................................................................................................................. 9

3.3 Actors ..................................................................................................................................... 10

Primary ............................................................................................................................. 10

Secondary ......................................................................................................................... 11

Use Cases Numbers........................................................................................................... 11

3.4 Functional Requirements ........................................................................................................ 11

Overview of Functionalities .............................................................................................. 11

Use Cases List ................................................................................................................... 13

OB-UC1 – Cross-Border Settlements between Financial Institutions ................................. 13

OB-UC2 – Illegal Access to the System ............................................................................ 14

OB-UC3 – Unauthorized Information Change ................................................................... 15

OB-UC4 – Unauthorized Escalation of Privilege ............................................................... 15

OB-UC5 – Open Banking Sensitive Data Sharing Network for Europe (OBSIDIAN) ........ 16

OB-UC6 – Establishing Quality User Experiences ............................................................. 16

OB-UC7 – Network Access to Data and Money Laundering Information........................... 17

OB-UC8 – Sharing Terrorist Financing Information in the Network .............................. 17

OB-UC9 – Privacy Preserving Verifiable Credentials .................................................... 17

3.5 Security and Privacy Requirements ......................................................................................... 19


vii

3.6 Non-Functional Requirements................................................................................................. 23

Look and Feel Requirements ............................................................................................. 23

Usability Requirements ..................................................................................................... 24

Operational Requirements ................................................................................................. 24

Maintainability and Portability Requirements .................................................................... 25

Social and Political Requirements ..................................................................................... 25

Legal and Regulatory Requirements .................................................................................. 25

3.7 Mandated Constraints ............................................................................................................. 26

3.8 Relevant Facts and Assumptions ............................................................................................. 26

Facts ................................................................................................................................. 26

Assumptions ..................................................................................................................... 26

3.9 Related WP3 and WP4 Tasks .................................................................................................. 26

4 Supply Chain Security Assurance ................................................................................................... 28

4.1 Goals ...................................................................................................................................... 28

4.2 Stakeholders ........................................................................................................................... 28

4.3 Actors ..................................................................................................................................... 29

Primary ............................................................................................................................. 29

Secondary ......................................................................................................................... 29



Overview of functionalities ............................................................................................... 30

Use Cases List ................................................................................................................... 30

SCH-UC1 – Supply Chain for Retail ................................................................................. 30

SCH-UC2 – Compliance and Accountability in distributed Manufacturing ........................ 32











viii


Facts ................................................................................................................................. 38

Assumptions ..................................................................................................................... 38


5 Privacy-Preserving Identity Management ....................................................................................... 40

5.1 Goals ...................................................................................................................................... 40

Demonstrator-specific background .................................................................................... 41

5.2 Stakeholders ........................................................................................................................... 41

5.3 Actors ..................................................................................................................................... 41

Primary ............................................................................................................................. 42

Secondary ......................................................................................................................... 43




Use Cases List ................................................................................................................... 46

IDM-UC1 – Registration ................................................................................................... 46

IDM-UC2 - Issuance ......................................................................................................... 46

IDM-UC3 - Presentation ................................................................................................... 46

IDM-UC4 - Revocation ..................................................................................................... 47

IDM-UC5 - Inspection ...................................................................................................... 47

IDM-UC6 – Certificate renewal ........................................................................................ 47

IDM-UC7 – De-registration .............................................................................................. 47











Facts ................................................................................................................................. 54


ix

Assumptions ..................................................................................................................... 54


6 Incident Reporting .......................................................................................................................... 55

6.1 Goals ...................................................................................................................................... 55

6.2 Stakeholders ........................................................................................................................... 55

6.3 Actors ..................................................................................................................................... 56

Primary ............................................................................................................................. 56

Secondary ......................................................................................................................... 57




Use Cases List ................................................................................................................... 64

IR-UC1 – Data Collection, Enrichment and Classification ................................................. 64

IR-UC2 - Managerial Judgement ....................................................................................... 65

IR-UC3 - Data conversion and reporting preparation. ........................................................ 66











Facts ................................................................................................................................. 71

Assumptions ..................................................................................................................... 71


7 Maritime Transport ........................................................................................................................ 72

7.1 Goals ...................................................................................................................................... 72

Identification of Critical Maritime Transport Services ....................................................... 72

7.2 Stakeholders ........................................................................................................................... 73

7.3 Actors ..................................................................................................................................... 76


x

Primary ............................................................................................................................. 76

Secondary ......................................................................................................................... 76




Use Cases List ................................................................................................................... 78

MT-UC1 – Threat Modeling and Risk Analysis for Maritime Transport Services............... 79

MT-UC2 - Maritime System Software Hardening .............................................................. 79

MT-UC3 – Trusted and Secure Maritime Communications................................................ 80

MT- UC4 – Trust Infrastructure for Secure Maritime Communication ............................... 81











Facts ................................................................................................................................. 90

Assumptions ..................................................................................................................... 90


8 Medical Data Exchange .................................................................................................................. 92

8.1 Goals ...................................................................................................................................... 92

8.2 Stakeholders ........................................................................................................................... 92

8.3 Actors ..................................................................................................................................... 93

Primary ............................................................................................................................. 94

Secondary ......................................................................................................................... 94




Use Cases List ................................................................................................................... 96


xi

MD-UC1 - Sharing Sensitive Health Data through an API ................................................. 97

MD-UC2 - Sharing Sensitive Health Data through Files .................................................... 98

MD-UC3 – Enhancing the security of on-boarding and accessing the Dawex platform ...... 99


8.6 Non-Functional Requirements............................................................................................... 100

Look and Feel Requirements ........................................................................................... 101

Usability Requirements ................................................................................................... 101

Operational Requirements ............................................................................................... 101

Maintainability and Portability Requirements .................................................................. 102

Social, Economical and Political Requirements ............................................................... 102

Legal and Regulatory Requirements ................................................................................ 102

8.7 Mandated Constraints ........................................................................................................... 103

8.8 Relevant Facts and Assumptions ........................................................................................... 103

Facts ............................................................................................................................... 103

Assumptions ................................................................................................................... 103

8.9 Related WP3 and WP4 Tasks ................................................................................................ 103

9 Smart Cities ................................................................................................................................. 104

9.1 Goals .................................................................................................................................... 104

9.2 Stakeholders ......................................................................................................................... 105

9.3 Actors ................................................................................................................................... 105

Primary ........................................................................................................................... 105

Secondary ....................................................................................................................... 105

Use Cases Numbers......................................................................................................... 106

9.4 Functional Requirements ...................................................................................................... 106

Overview of functionalities ............................................................................................. 106

Use Cases List ................................................................................................................. 111

UC1 – Register Data Consumer and Manage Services ..................................................... 113

SMC-UC2 - Discover and Consume City Data ................................................................ 115

SMC-UC3 - Personal Data Sharing ................................................................................. 116

SMC-UC4 - Sensor Data sharing and operationalization .................................................. 117

SMC-UC5 - Assess exposure to social engineering threats simulating a targeted attack on LPA 118

UC6 - Assess cyber risks for LPA, evaluating exploitable vulnerabilities and their consequences (both from qualitative and quantitative approach) ................................................... 120


xii

UC7 - Cyber security needs and solution elicitation and selection .................................... 121

9.5 Security and Privacy Requirements ....................................................................................... 122

9.6 Non-Functional Requirements............................................................................................... 126

Look and Feel Requirements ........................................................................................... 126

Usability Requirements ................................................................................................... 126

Operational Requirements ............................................................................................... 127

Maintainability and Portability Requirements .................................................................. 128

Social and Political Requirements ................................................................................... 128

Legal and Regulatory Requirements ................................................................................ 129

9.7 Mandated Constraints ........................................................................................................... 129

9.8 Relevant Facts and Assumption ............................................................................................ 129

Facts ............................................................................................................................... 129

Assumptions ................................................................................................................... 129

9.9 Related WP3 and WP4 Tasks ................................................................................................ 129

10 Conclusions .............................................................................................................................. 131

11 Bibliography ............................................................................................................................ 132


xiii

List of Figures

Figure 1: Open Banking - The Open Banking API architecture ............................................................... 12 Figure 2: Open Banking - Simplified view of an interbank settlement scenario ....................................... 14 Figure 3: Open Banking - Workflow of an illegal access to the system ................................................... 15 Figure 4: Open Banking - Workflow of an unauthorized information change .......................................... 15 Figure 5: Open Banking - Workflow of an unauthorized escalation of privileges .................................... 16 Figure 6: Open Banking – Opening a bank account with verifiable credentials ....................................... 19 Figure 7: Open Banking - The goal of verifiable credentials ................................................................... 19 Figure 8: Supply Chain Security Assurance - Simplified view of a supply chain workflow ..................... 31 Figure 9: Supply Chain Security Assurance - Simplified view of a compliance audit trail and accountability .............................................................................................................................................................. 33 Figure 10: Privacy-Preserving Identity Management - Demonstrator actors overview ............................. 43 Figure 11: Privacy-Preserving Identity Management - High-level overview of use cases......................... 45 Figure 12: Incident Reporting – Event Management Workflow .............................................................. 58 Figure 13: Incident Reporting - Functional Workflow ............................................................................ 59 Figure 14: Incident Reporting - Critical events classification methodology ............................................. 60 Figure 15: Incident Reporting - UC1 Data Collection, Enrichment, and Classification ............................ 65 Figure 16: Incident Reporting - UC2 Managerial Judgement .................................................................. 66 Figure 17: Incident Reporting - UC3 Data Conversion and Reporting ..................................................... 66 Figure 18: Maritime Transport - Maritime transport environment and the security services demonstrated in T5.5 ....................................................................................................................................................... 78 Figure 19: Maritime Transport - Threat modeling and risk analysis for maritime transport services ........ 79 Figure 20: Maritime Transport - Maritime system software hardening .................................................... 80 Figure 21: Maritime Transport - Trusted and secure maritime communications ...................................... 81 Figure 22: Maritime Transport - Trust infrastructure for secure maritime communication. The diagram shows the issuing of cryptographic credentials and enrolment of new actors ........................................... 83 Figure 23: Maritime Transport - Security and privacy requirements ........................................................ 86 Figure 24: Medical Data Exchange - Generic Use Case .......................................................................... 96 Figure 25: Medical Data Exchange - Generic Use Case .......................................................................... 96 Figure 26: Medical Data Exchange - UC1 Overview .............................................................................. 98 Figure 27: Medical Data Exchange - UC2 Overview .............................................................................. 98 Figure 28: Medical Data Exchange - UC3 Overview .............................................................................. 99 Figure 29: Smart Cities - Urban data platform ...................................................................................... 107 Figure 30: Smart Cities - Data usage dontrol dashboard for personal data ............................................. 108 Figure 31: Smart Cities - Decentralized sensor data infrastructure ........................................................ 108 Figure 32: Smart Cities - Social driven vulnerability and risk assessment processes .............................. 110 Figure 33: Smart Cities - Process of cybersecurity solution elicitation .................................................. 111 Figure 34: Smart Cities - SMC-UC1 use case diagram .......................................................................... 114 Figure 35: Smart Cities - SMC-UC2 use case diagram .......................................................................... 116 Figure 36: Smart Cities - SMC-UC3 use case diagram .......................................................................... 117 Figure 37: Smart Cities - SMC-UC4 use case diagram .......................................................................... 118 Figure 38: Smart Cities - SMC-UC5 use case diagram .......................................................................... 120 Figure 39: Smart Cities - SMC-UC6 use case diagram .......................................................................... 121


xiv

Figure 40: Smart Cities - SMC-UC7 use case diagram .......................................................................... 122


xv

List of Tables Table 1: Open Banking - Mapping of actors to use cases ........................................................................ 11 Table 2: Open Banking - Security and privacy requirements ................................................................... 23 Table 3: Open Banking - Look and feel requirements ............................................................................. 24 Table 4: Open Banking - Usability requirements .................................................................................... 24 Table 5: Open Banking - Operational requirements ................................................................................ 25 Table 6: Open Banking - Legal and Regulatory requirements ................................................................. 26 Table 7: Open Banking - Relationship with WP3 and WP4 tasks ............................................................ 27 Table 8: Supply Chain Security Assurance - Mapping of actors to use cases ........................................... 30 Table 9: Supply Chain Security Assurance - Security and Privacy requirements ..................................... 36 Table 10: Supply Chain Security Assurance - Look and Feel requirements ............................................. 36 Table 11: Supply Chain Security Assurance - Usability requirements ..................................................... 36 Table 12: Supply Chain Security Assurance - Operational requirements ................................................. 37 Table 13: Supply Chain Security Assurance - Legal and Regulatory requirements .................................. 38 Table 14: Supply Chan Security Assurance - Relationship with WP3 and WP4 tasks .............................. 39 Table 15: Privacy-Preserving Identity Management - mapping of actors to use cases .............................. 44 Table 16: Privacy-Preserving Identity Management - Security and privacy requirements ........................ 50 Table 17: Privacy-Preserving Identity Management - Usability requirements.......................................... 52 Table 18: Privacy-Preserving Identity Management - Operational requirements...................................... 52 Table 19: Privacy-Preserving Identity Management - Maintainabilty and portability requirements .......... 52 Table 20: Privacy-Preserving Identity Management - Legal and regulatory requirements ........................ 53 Table 21: Privacy-Preserving Identity Management - Relationship with WP3 and WP4 tasks ................. 54 Table 22: Incident Reporting - Mapping of actors to use cases ................................................................ 57 Table 23: Incident Reporting - Functional requirements ......................................................................... 63 Table 24: Incident Reporting - Security and Privacy requirements .......................................................... 67 Table 25: Incident Reporting - Look and feel requirements ..................................................................... 67 Table 26: Incident Reporting - Usability requirements ............................................................................ 68 Table 27: Incident Reporting - Operational requirements ........................................................................ 68 Table 28: Incident Reporting - Maintainability and portability requirements ........................................... 69 Table 29: Incident Reporting - Legal and Regulatory requirements ......................................................... 71 Table 30: Incident Reporting - Relationship with WP3 and WP4 tasks ................................................... 71 Table 31: Maritime Transport - A non-exhaustive list of critical maritime transport services ................... 73 Table 32: Maritime Transport - Mapping of actors to use cases............................................................... 77 Table 33: Maritime Transport – Usability requirements .......................................................................... 87 Table 34: Maritime Transport - Operational requirements ...................................................................... 88 Table 35: Maritime Transport - Maintainability and portability requirements .......................................... 88 Table 36: Maritime Transport - Social and political requirements ........................................................... 88 Table 37: Maritime Transport - Legal and regulatory requirements ......................................................... 89 Table 38: Maritime Transport - Relationship with WP3 and WP4 tasks .................................................. 91 Table 39: Medical Data Exchange - Mapping of actors to use cases ........................................................ 95 Table 40: Medical Data Exchange - Security and Privacy requirements ................................................ 100 Table 41: Medical Data Exchange - Look and Feel requirements .......................................................... 101 Table 42: Medical Data Exchange - Operational requirements .............................................................. 101 Table 43: Medical Data Exchange - Maintainability and portability requirements ................................. 102


xvi

Table 44: Medical Data Exchange - Social and political requirements .................................................. 102 Table 45: Medical Data Exchange - Legal and regualtory requirements ................................................ 102 Table 46: Medical Data Exchange - Relationship with WP3 and WP4 tasks.......................................... 103 Table 47: Smart Cities - Mapping of actors to use cases ....................................................................... 106 Table 48: Smart Cities - Functional Requirements ................................................................................ 113 Table 49: Smart Cities – SMC-UC1 subordinate use cases ................................................................... 114 Table 50: Smart Cities – SMC-UC2 subordinate use cases ................................................................... 116 Table 51: Smart Cities – SMC-UC5 subordinate use cases ................................................................... 119 Table 52: Smart Cities - SMC-UC6 subordinate use cases .................................................................... 121 Table 53: Smart Cities - Security and privacy requirements .................................................................. 126 Table 54: Smart Cities - Look and feel requirements ............................................................................ 126 Table 55: Smart Cities - Usability requirements.................................................................................... 127 Table 56: Smart Cities - Operational requirements................................................................................ 127 Table 57: Smart Cities: Maintainability and portability requirements .................................................... 128 Table 58: Smart Cities - Social and political requirements .................................................................... 128 Table 59: Smart Cities - Legal and regulatory requirements .................................................................. 129 Table 60: Smart Cities - Relationship with WP3 and WP4 tasks ........................................................... 130


xvii

List of Acronyms ABC AGID AIS

Attribute-Based Credential Agenzia per l’Italia Digitale Automatic Identification System

AISP AOS

Account Information Service Provider Advanced Object detection System

API Application Programming Interface ASPSP BIT CAD CEO CIO CISO CCN

Account Service Payment Service Provider Business Information and Tracking Codice Amministrazione Digitale Chief Executive Officer Chief Information Officer Chief Information Security Officer Common Communication Network

CMS CSS DP EBA EBC ECDIS ECHR EDI EDPB eIDAS EMCS EPC EU FFS FI FIM GDPR GDM GOS GSS GUI ICT IdP IdM IMT IR IRT IT JIT LOD LoLo LPA

Content Management System Container Status System Dynamic Positioning system European Banking Authority European Central Bank Electronic Chart Display and Information Systems European Convention on Human Rights Electronic Data Interchange European Data Protection Board electronic IDentification Authentication and trust Services Excise Movement and Control System European Payments Council European Union Freight Forwarder System Financial Institution Federated Identity Management General Data Protection Regulation Global Data Marketplace Gate Operating System Gas Supply System Graphical User Interface Information and Communications Technology Identity Provider Identity Management Incident Management Team Incident Reporting Incident Reporting Team Information Technology Just-In-Time system Linked Open Data Lift-on-Lift-off vessels Local Public Administration


xviii

MITM NCA NIS NVR OAuth OBSIDIAN OES OSS PA PET PISP PSD2 PSP REST RFID RTS RTU SAML SC SCADA SDVA SIS SP SPARQL SSDLC SSM TOS UC VIS VTMS VTS WMS WP W3C

Man in the Middle National Competent Authorities Network and Information Security Network Video Recorder Open Authorization Open Banking Sensitive Data Sharing Network for Europe Operator Essential Service Onboard Safety Systems Public Administration Privacy Enhancing Technologies Payment Initiation Service Provider Payment Services Directive 2 Payment Service Provider Representational State Transfer Radio Frequency Identification Regulatory Technical Standards Remote Terminal Unit Security Assertion Markup Language 2.0 Smart Card Supervisory Control and Data Acquisition Social Driven Vulnerability Assessment Ship Information System Service Provider Recursive acronym for SPARQL Protocol and RDF Query Language Secure Software Development Life Cycle Single Supervisory Mechanism Terminal Operating System Use Case Visitor Information Service Vessel Traffic Management System Vessel Traffic Service Warehouse Management System Work Package Wold Wide Web Consortium


1

1 Introduction CyberSec4Europe is a project that wants to lead the European Union cybersecurity research and innovation efforts. The project comprises research centers and industries providing research excellence and industrial expertise. Their collaboration will not only help in identifying and analyse relevant cybersecurity challenges in today’s European society, but also study and propose adequate solutions addressing those challenges. The project has identified seven key research and innovation demonstration cases covering a wide spectrum of prominent research areas in both the public and private sectors. These demonstration cases constitute the core of the project and they will be mapped to technological and research challenges that a coordinated effort between research and industry partners will address. It is expected that the results of this cooperation will be adopted as technological components that the demonstration cases will integrate in their lifecycle. The project’s methodology to achieve these ambitious goals is to structure its lifetime in two cycles of research and development:

• The first iteration will provide an initial definition of the research challenges and roadmaps that will drive the second iteration of the project.

• The second iteration will then further refine the research goals of the project to exhaustively address the identified challenges while also making them relevant beyond the scope of the project.

The purpose of this document is to gather an initial set, as comprehensive as possible, of requirements related to the seven domains defining the demonstration cases. These requirements will play a key role in identifying the technological and research roadmaps of the project. For each demonstration case, the document first presents a number of use-cases identified by analyzing each domain in collaboration with the industry participants. Based on the description of those use-cases, the document outlines a list of functional and non-functional requirements describing the conditions that ensure the system’s correct operations. Additionally, this document serves as an overview of the demonstration cases to WP3 and WP4 so that they can design the technological components and outline the research roadmap of the project.

1.1 Structure of the Document

The document is structured as follows1: • Section 2 gives a summary of all the demonstration cases. • Section 3 presents the use-cases, together with their functional and non-functional requirements,

identified in the context of CyberSec4Europe’s Open Banking demonstration case. • Section 4 presents the use-cases, together with their functional and non-functional requirements,

identified in the context of CyberSec4Europe’s Supply Chain Security Assurance demonstration case.

• Section 5 presents the use-cases, together with their functional and non-functional requirements, identified in the context of CyberSec4Europe’s Privacy-preserving Identity Management demonstration case.

• Section 6 presents the use-cases, together with their functional and non-functional requirements, identified in the context of CyberSec4Europe’s Incident Reporting demonstration case.

• Section 7 presents the use-cases, together with their functional and non-functional requirements, identified in the context of CyberSec4Europe’s Maritime Transport demonstration case.

• Section 8 presents the use-cases, together with their functional and non-functional requirements, identified in the context of CyberSec4Europe’s Medical Data Exchange demonstration case.

1 The structure of this document has been inspired by a template by Professor J. Alberto Espinosa of the Kogod School of Business, American University, which can be found at his website here.


2

• Section 9 presents the use-cases, together with their functional and non-functional requirements, identified in the context of CyberSec4Europe Smart Cities demonstration case.

• Section 10 concludes the document.


3

2 Summary of the Demonstration Cases In this section, we provide a brief summary of all CyberSec4Europe demonstration cases. The goal is to give an overview of what cybersecurity challenges the remainder of the document covers.

2.1 Open Banking

This demonstration case will allow users to carry out financial transactions, including cross-border, using the new services available under PSD2 securely and with confidence from their mobile devices. Such services include being able to make payments to merchants by giving them access to one of their bank accounts and allowing the merchant to process a payment through an intermediary service with access to their bank account. In an open banking environment, users should also be able to terminate their relationship with the merchant, so they no longer have access to their bank account and work with a third party to transfer all their account information to another financial institution. The overall result of this demonstration case will be to address, when users are seeking to obtain account information, the risks and vulnerabilities emerging from social engineering and malware attacks, provide protection for bank administration security policies as well as overcome weaknesses in the design and/or implementation of APIs in use and to prevent fraud and data loss in relation to the access and request of payment by third parties in an open banking environment.

2.2 Supply Chain Security Assurance

The demonstration case will allow involved stakeholders to secure the supply chain and trace the movement of components and goods during all stages of the supply chain. They want to guarantee quality and integrity of the parts and products. The resulting system should be non-repudiable, detect manipulations and errors in the supply chain and resolve conflicts quickly, and preferably, avoid errors and prevent counterfeiting in the supply chain. In the case of low quality or counterfeit components that lead to problems with the final product, participants should identify and resolve the issue or conflict quickly. Players will only have to reveal the data that is needed to ensure the integrity and the security of the supply chain, keeping all other information private and internal. The overall result of this demonstration case will be to provide a blueprint for supply chain solutions for multiple sectors. One specific application will be for an energy use case involving transformers for power distribution, where the supply chain for the transformers will be critical to ensure proper operation of transformers as crucial components in power networks.

2.3 Privacy-Preserving Identity Management

This demonstration case will enable an identity infrastructure to fulfil the need for strong privacy-preserving authentication with a distributed and scalable platform for privacy-preserving self-sovereign identity management. The platform will allow users to collect and manage attributes and claims from identity service providers, authenticate to service providers, provide consent for and control the personal data usage in a seamless and privacy-preserving fashion.

The demonstration case will also showcase an example of the secure and trustworthy exchange of higher education certificates between organisations, such as educational institutes, universities, state agencies, private sector organisations, as well as with individuals. It will allow higher education graduates to share documents and prove their expertise during a preselection stage. The verification of the education credentials will keep graduates’ information private until needed later, such as for recruitment. Graduates


4

will be able to prove their competencies as well as other qualifications, hiding information not relevant to the situation, which is an example of applying the data minimisation principle as required by the GDPR.

This demonstration case will also provide transversal support to the other demonstration cases and empower end users and organisations to control their privacy and increase the trust in Internet services.

2.4 Incident Reporting

This demonstration case will develop a platform that enables organisations or their entities to report incidents according to the different procedures and methods specified by applicable regulatory bodies, such as PSD2 and the ECB Cyber Incident Reporting Framework. The platform will specifically support cybersecurity information data sharing in a bidirectional way, allowing for a centralised or a decentralised approach, i.e. a peer-to-peer approach.

The resulting prototype will cover trustworthy information sharing including secure and efficient protocols for information exchange, big data analysis of cybersecurity information and quantitative risk assessment, the application of machine learning and AI to prevent attacks and threats, but also to assist in decision support and improve reaction to incidents, secure and privacy-preserving efficient information storage possibly using distributed, blockchain based mechanisms as well as usable interfaces for the design and operation of cybersecurity procedures.

2.5 Maritime Transport

This demonstration case identifies the current cybersecurity challenges of the maritime sector and will design and develop a threat management system capable of continuously managing cybersecurity threats against Internet connected critical cyber infrastructures in the maritime sector. Security services will cover the whole ecosystem of maritime sector critical cyber infrastructures, including both those residing at the port side and the ship side.

The demonstration case will develop advanced threat models for the maritime environment, able to capture and assess new threats that may involve the whole maritime sector ecosystem and to assist the relevant stakeholders, such as ship operators and port operators, to be in line with the related regulations and best practices. It will also help port and ship operators to manage their security risks more effectively and to increase the resilience of critical maritime infrastructures, ultimately offering advanced security to maritime transport “users” such as citizens and manufacturers who use maritime transport services.

2.6 Medical Data Exchange

This demonstration case will integrate and validate in a realistic environment the research outcomes on the cybersecurity and sensitive and personal data protection for medical data sharing, enhancing the multilateral trust among stakeholders generating and consuming data in the medical business sector through theDAWEX data marketplace platform, improving its trustworthiness and creating new business opportunities as a result.

It will allow the secure and trustworthy exchange of sensitive data between several kinds of players with different aims and claims, regarding the security, data protection and trust issues: companies, public organizations and citizens, aligned with applicable legislation and the strategic policy framework (the GDPR, NIS Directive, blueprint for rapid emergency response, ENISA recommendations on security and privacy etc.).

2.7 Smart Cities


5

This demonstration case will connect the cyber security challenges of smart cities through the OASC organisation, whose objective is to “create an open smart city market based on the needs of cities and communities”. It will deploy prototypes addressing cybersecurity challenges mainly related to privacy management in data exchanges among city stakeholders that will be elaborated with OASC during the first phase of the project.

The demonstration case will include a dedicated environment enabling ideas, needs, best practices and lesson learned exchange among cities and cities’ stakeholders to ease the identification, uptake, collaboration and deplo-ment of cybersecurity services for smart cities, including novel business models to pool resources and decrease the individual cost supported by each city. This environment then will also act as a trusted marketplace for cybersecurity services, using a "pooling" delivery model of services and resources. This aspect of the demonstration case will address the novel governance model of the CyberSec4Europe competence network. The demonstration case will also include a ‘lifelong training’ mechanism and environment to decrease the impact of social engineering attacks.


6

3 Open Banking In this section, we describe the requirements for the CyberSec4Europe demonstration case entitled Financial Transactions. We first provide a high-level overview of the demonstration case and its goals, followed by a description of the actors involved. We then provide more detailed functional requirements featuring use cases, followed by a description of non-functional requirements. Finally, we report relevant constraints and assumption to be considered while implementing this demonstration case. This demonstration case investigates four different scenarios:

• Privacy Preserving Verifiable Credentials • An Open Banking Sensitive Data Sharing Network • An Open Banking API Architecture • Improving Financial Settlements

Each one of these addresses security concerns that have arisen as a result of the highly disruptive digital transformation in banking and financial services, from both the coming into force of new regulations as well as the introduction of new technologies. It could be said that Open Banking is just about data, and all that matters is how you use it. Ironically, while the GDPR is intended to protect citizens’ data, PSD2 is designed to remove the barriers to accessing bank information and the treasure trove of sensitive financial data contained therein. Not surprisingly then, our four use cases all reflect in one way or the other the concerns arising from the emerging landscape of financial services about protecting access to and the potential loss of sensitive financial data.

(A) Privacy Preserving Verifiable Credentials

This section describes the requirements for the set of use cases associated with verifiable claims. The Payment Services Directive 2 (PSD2) introduces two new payment services provided by new actors.

• Payment Initiation Service Providers (PISPs) will initiate online payments to third parties on behalf of the payers. These entities, which do not necessarily have a relationship with the payers’ banks and are called Account Service Payment Service Providers (ASPSPs), shall access to the online account of the payers.

• Account Information Service Providers (AISPs) are able to give users a consolidated view of all their payment accounts even if they are managed by multiple ASPSPs.

Customers are entitled to a high level of security in mobile banking. However, these new actors raise new security issues. For example, a bank customer may give a PISP full access to their online bank accounts to initiate payments. If so, the provider would also have access to all the bank information associated with the user. Since no formal relationship with the ASPSP is required, it makes the protection of customers complicated for the banks. In addition, in this example AISPs would have access to all incoming and outgoing payments in order to provide a consolidated view of the customer’s bank accounts. As a consequence, AISPs will gain access to sensitive information data such as rent and salary or insurance and health insurance payments. The task of the banks to protect the privacy of their customers becomes much more complicated in such a situation. Finally, it would be extremely difficult for users to understand what is happening to their data, where it is being saved and what their rights are. Nor is it clear in the case of any data loss, whom the responsibility would lie with.

(B) Open Banking Sensitive Data Sharing Network for Europe (OBSIDIAN)

This section describes the requirements for the set of use cases associated with developing an Open Banking Sensitive Data Sharing Network for Europe for the CyberSec4Europe demonstration case Financial Transactions. We first provide an overview of the demonstration case’s context. We then describe it in details by providing its requirements and illustrating them with concrete use cases. We finally list the challenges and issues to take into account to succeed in demonstration use case’s implementation.


7

Banks are facing several types of risks, which are growing with banking’s digital transformation. These may include data breaches, banking fraud, money laundering and other illegal activities such as terrorist financing. Today financial fraud is globalized. As bank strategies are focused on digitalizing critical processes like opening a bank account or adding a transfer beneficiary to a bank account, it is becoming very easy for a hacker to realise several fraudulent transactions from his living room within a short time and without fully revealing his physical identity. Moreover, criminals and their illegal activites can affect several banks without having to change his mode of operation, given that today banks do not share any information on effective frauds and associated data. Finally, with new technologies like Instant Payment which provide bank users with real time money transfer services, it will be even more difficult to fight against fraud, as a bank will not have any delay time to make a recall in the case of a fraudulent transaction. Similarly, the lack of information sharing between banks (starting with institutional IBANs) makes it very difficult to fight against fraud because there are many false positives. In an open economy, we must also share sensitive data related to the fight against money laundering or terrorist financing in order to be more effective in our detection systems and protect the European market. Sharing proven data and information about occurrences and non-occurrences of these risks between banking actors is an opportunity to globally improve cooperative detection models and resilience facing fraudulent activities, by reducing false positives / negatives. The CyberSec4Europe partner network could be the right place to demonstrate how info-sharing such security- enhancing practices would work and make it possible to engage a decision process at the right (i.e., European) level. To achieve the expected outcome of the set of use cases associated with OBSIDIAN, we have created the conditions to increase collaboration across the following areas:

• business specification: which data / information to share and for which purpose; • technical specification: how (technical protocol, needed infrastructure) to share with the right level

of security / privacy; • legal/political validation: validating sharing compliance with the latest regulations such as the

GDPR to engage policy decision makers by making them aware of the overall implications.

3.1 Goals

Open Banking API Architecture

The following section describes the essential components for an adequate governance of the exposed services and the functional characteristics that could support the evolution towards Open Banking for open financial services. In particular, a shared map of the macro-components and functionalities for the Open API was developed, starting from the study of different sources in the literature, from the analysis of case studies and market models and from the collection of ideas in the various moments of interactions that took place in the meetings of the working table. The map is designed as a model to support API exposure with a view to openness. It represents a useful starting point for moving towards future scenarios, but clearly it must be understood as a necessary but not sufficient condition for Open Banking, since the technological, infrastructural and architectural adaptation must in any case be accompanied by a broader rethinking of the organizational aspects, governance paradigms and business logic support models.

Privacy Preserving Verifiable Credentials

The goals of this use case are to: (1) Identify / authenticate with a high assurance level the bank customer to their PISPs and AISPs (2) Manage the delegated access privileges a customer gives to their PISPs and AISPs


8

(3) Make customers aware of the usage of their data, delegated rights, etc. Registration and authentication processes on websites have been significantly simplified by federated identity management systems, which encourage single sign-on. An identity provider (IdP) centralises all the identity attributes of each of its users and provides them with a single authentication process they can use to identify and authenticate to any service on the Internet that is federated with the IdP. Based on web-based standard protocols (e.g., SAML, OpenID Connect), this process replaces the tedious task of manually declaring an identity by registering at each service provider (SP), with an automatic exchange of identity information between the IdP and the SP. Identity federation also simplifies user authentication in a password environment, since the user only authenticates to the IdP, thereby reducing the number of credentials to remember. In the world of Open Banking, the PSPs (i.e., the banks), the ASPSP, the AISP and the PISPs can play the IdP role. They can build a circle of trust and operate a federated identity management (FIM) system. However, today’s FIM systems have a significant structural weakness: namely, putting the IdP at the centre of the identity ecosystem.

• First, the trust model requires (1) the IdP to trust the SP to preserve the privacy of the user’s identity information that it is asserting, and (2) the SP to trust that the IdP is the authoritative source of (all of) the user’s identity information. Both of these trust requirements are unreasonable. No single IdP is the authoritative source of all a user’s identity information. For example, a user may hold several accounts in several banks, and users may want to present their identity information to SPs that IdPs do not fully trust.

• Secondly, the IdPs are the centre of the identity eco-system, and issue short-lived identity assertions or tokens on demand to trusted SPs. Consequently, they know which SPs the user is visiting and when, which allows them to track the user. In addition, besides violating the user’s privacy, it also introduces a severe security vulnerability as a recent Facebook hack highlighted. This allowed the attackers to access all the user’s accounts at all the SP websites that trusted Facebook as the user’s IdP. Since PSPs, like Facebook, share and store a huge amount of information about lots of users, such attacks have a big impact.

Verifiable credentials are the electronic equivalent of the physical credentials we have today such as plastic cards, passports, tickets, qualifications etc. Verifiable credentials are cryptographically protected and are stored in end users’ devices such as mobile phones, laptops etc allowing users to carry them around with zero portability effort. Like plastic cards, verifiable credentials can be presented to whomsoever the user chooses, without asking the permission of anyone – unlike a user’s identity attributes in federated identity management systems, which are only released with the permission of the IdP. Verifiable credentials are not a new concept, but are just becoming standardised by the W3C, so this is an opportune time to demonstrate their potential in terms of enhancing an end user’s privacy, security, trust and usability of the Internet – and financial systems in particular.

Open Banking Sensitive Data Sharing Network for Europe (OBSIDIAN)

We propose to experiment with the establishment of a trusted network to provide banks with a channel for sharing and exchanging critical information on effective fraud, institutional IBANs, money laundering and terrorist financing data using the latest open online banking services. First, by making such information sharing possible, banks could improve their ability to detect and react in real time to fraud cases. For example, if a bank which had detected a transfer fraud was able to share with other banks the information about the IBAN implied in the transfer, these banks could take this information into account in time to prevent the fraudster from using this IBAN to realize other fraudulent transactions.


9

The PSD2 Regulatory Technical Standards (RTS) to be implemented in September 2019 will not effectively combat a wide range of fraud types as it focuses solely on the payer. For example, fraud such as real time phishing, social engineering, technician fraud, supplier fraud scams (customers buy objects that do not exist), manipulated agency, cheque fraud, all of which we face on a daily basis, will not be reduced by this regulation. On the other hand, another consequence of the lack of information sharing activities between banks is the rising leadership in the EU of non-European ICT providers in the field of risk scoring, thus leveraging globalised fraud information centralisation. Several of these ICT providers2 can increase the risk management services aiming at scoring transactions in a bank information system to detect fraudulent ones. But:

• few if any of them offer services featuring all fraud typologies (transfer fraud, cash machine fraud, check fraud, payment fraud etc);

• their solutions are based on blackbox architectures to protect their competitive advantage.

There is also a sovereignty issue, given that this lack of cooperation is an opportunity for these providers: • to become leaders in the field of centralisation and correlation of fraud information by contracting

one-to-one with each bank; • to increase their leadership by fueling their product roadmaps with a sharp knowledge of globalised

fraud use cases, and then becoming essential actors by developing evident addiction to their services.

Finally, several organizations aiming at developing cooperation between financial actors already exist3 but the data they share is not effective fraud data (for example, an IBAN signature used to realise a fraudulent transfer). These organizations are focused more on delivering, for example, cyber threat intelligence services and less on sharing effective fraud information.

3.2 Stakeholders

Open Banking API Architecture European banks and third service providers will have an economic interest in the architecture network. In particular, banks are able to easily connect other APIs in the market in order to extend their service offerings by introducing native FinTech solutions in a secure plug-and-play manner. Through embracing the Open Banking API economy, banks are able to further enhance and transform current offerings, increasing their appeal to existing and prospective customers alike. However, Open Banking APIs can also create a threat for banks, as they enable FinTech firms to tap into a bank’s financial data. For example, a FinTech startup may decide to use a bank’s “Customer Data API” in order to build a mobile application where customers budget their finances, manage their debt, and get real-time investment and financial advice through chat. The majority of traditional banks do not offer such debt and real-time finance management services. This means that by opening up their APIs, the bank has enabled the FinTech startup to fulfill this existing gap and drive a wedge between the bank and the customer.

Privacy Preserving Verifiable Credentials The bank customers (the payers and the payees) as well as the trust intermediaries such as the banks and the PSPs (AISPs, ASPSPs, PISPs).

Open Banking Sensitive Data Sharing Network for Europe (OBSIDIAN)

2 IBM, threatmetrix, Ping identity, … 3 https://www.first.org/, https://ec.europa.eu/anti-fraud/


10

European banks will have an economic interest in such a trust network as it would mitigate their fraud losses and improve trust and loyalty of their customers by better protecting them from attempted frauds. Extended use cases of such a trust network could include not only black list but also white list information sharing, that could be used to improve user experience with less friction linked to security procedures. The trust between members of this network could be created by leveraging existing certification authority ecosystems. These kinds of actors would have a business motivation to participate and in addition:

• those in charge of regulation writing and privacy concerns would be involved to create the legal framework (like the European Data Protection Board).

• Europol, as well as Interpol and LEAs (Law Enforcement Agencies), will also have an important interest in being able to use data related to money laundering, terrorist and criminal financing activities.

Such a network for exchanging data on risks such as the fight against money laundering and the fight against terrorist financing would be much more appropriate to the current challenges, considering that these risks do not stop at the borders of Member States.

3.3 Actors

In this section we provide a list of actors with brief descriptions. Actors are all the entities that interact with the overall Financial Transactions ecosystem. They can be of two types:

(i) Primary actors, which are actors that have goals which this demonstration case needs to fulfill; and

(ii) Secondary actors, which don't have specific goals associated with this demonstration case but are needed for the execution of its use cases.

Primary

The actors involved in these use cases are: • Commercial/Corporate / Retail Banks: these banks transact with customers, play a direct part in

settlements and are regulated by a national central bank. This category includes: o Settlement banks which are the last banks to receive and report the settlement of a

transaction between two entities. o Internet banks — also known as virtual banks, online banks, or web banks — lack any

physical branch locations and exist only on the Internet. o Account Service Payment Service Providers (ASPSP) when referred to as a bank by

PSD2. • Service Providers: PSD2 introduced two new payment services provided by new actors.

o Payment Initiation Service Providers (PISPs) initiate online payments to third parties on behalf of the payers. These entities, which do not have necessarily a relationship with the payers’ banks (ASPSPs), may access the online account of the payers.

o The Account Information Service Providers (AISP) allow users to get a consolidated view on all their payment accounts even if they are managed by multiple ASPSPs.

• European Payment Council (EPC): the decision-making and coordination body of the European banking industry in relation to payments, consisting of banks and their associations, with responsibility for the development of the Single Euro Payment Area (SEPA).

• European financial governance bodies: for example, the European Banking Authority (EBA) • Europol: the law enforcement agency of the EU that handles criminal intelligence and combats

serious international organized crime and terrorism through cooperation between competent authorities of EU Member States.


11

• Regulatory and privacy bodies: for example, the European Data Protection Board (EDPB), as well as the Data Protection Authorities (DPAs), the agencies responsible for overseeing the GDPR within each Member State.

Secondary

• Consultancy agencies: audits and certifies the supply chain process in settlement transactions. • Government agencies: governmental entity that interacts with the flow of money entering/leaving

a country (e.g., treasury, customs office, etc.). • ICT and equipment providers: providing others with tools to carry out their operations (e.g., IT

companies) and some of the needed technologies to implement the targeted fraud network. • Open Banking pure players: these include Fintech companies. • End users: these include bank customers or open banking service users. • Fraudsters, hackers, mischief makers, malicious users, bored teenagers: the list is endless.

Use Cases Numbers

ACTORS OB-UC1

OB-UC2

OB-UC3

OB-UC4

OB-UC5

OB-UC6

OB-UC7

OB-UC8

OB-UC9

Banks X X X X X X X X X

Service providers

X X X X

EPC X X X X

Europol X X X X

Governance bodies

X X X X

Regulatory bodies

X X X X

Table 1: Open Banking - Mapping of actors to use cases

3.4 Functional Requirements

In this section we provide a brief description of the functionalities of this demonstration case, along with a list of use cases implementing them.

Overview of Functionalities

The Open API Architecture

The architecture identifies five basic areas within the defined macro-components for the Open API, which represent the main elements that contribute to the dynamics of exposure and governance of the Open Banking stakeholders.

• API Security: Components useful for ensuring the necessary security features for interaction with the Open Banking Architecture (OBA) including Identity Provider.

• API Platform: Components with responsibility for orchestration, policy enforcement, monitoring and aid to the government including the API Gateway, API Manager and the API Portal


12

• Knowledge Base: Collection, organization and distribution of knowledge through the API Catalogue and Documentation Management

• Baseline: Components constituting the reference point on which the implementation of the Open Bank is based

• Ecosystem: Open banking implies the use of external services, data and features developed by parties outside the bank.

OBSIDIAN

The proposed network will focus on four core functionalities: 1. Banks experiencing potential fraud attempts will request confirmation of the right decision to

take (i.e., monitoring / rejecting / validating the transactions) from the proposed network. The requests provide the core transaction data (IBAN et al) in a format which guarantees privacy and security network requirements.

2. Banks must confirm transactions for which the quality of the user experience (real time, trust) is critical. In order to succeed in providing such a user experience, banks should request the proposed network to gain the needed quality.

3. In its daily fight against money laundering, banks’ security experts should cooperate with the network expert ecosystem in order to provide their fraud fight models with extended qualified data to improve global detection skills.

4. In their ongoing fight against the financing of terrorism and criminal activities, open banking actors will use the proposed network to share their cases analysis in order to create the conditions to build some global detection patterns and improve their response times when facing new incidents.

Figure 1: Open Banking - The Open Banking API architecture


13

Use Cases List

• OB-UC1 - Cross-border settlements between financial institutions: A system handling settlement between financial institutions. It leverages the blockchain to carry out its operations.

• OB-UC2 - Illegal access to the system: A hacker / malicious user tries to gain illegal access to the system.

• OB-UC3 - Unauthorized information change: A hacker / malicious user tries to tamper with the data.

• OB-UC4 - Unauthorized escalation of privilege: A hacker / malicious user tries to gain unauthorized access to information.

• OB-UC5 - Posting fraud information to the network: The preparation, reporting and scoring of fraud information as well as facing such an attempted fraud and dealing with false positives.

• OB-UC6 - Establishing user experience trust levels: The preparation and reporting of effective information on institutional IBANs (white list IBAN) for publication and defining access authorization to the information.

• OB-UC7 - Network access to data and money laundering information: The preparation and reporting of money laundering information and defining access authorization to that data.

• OB-UC8 - Sharing terrorist financing information in the network: The preparation and reporting of information related to terrorist financing and defining who and under what circumstances access to that data is authorized.

• OB-UC9 - Privacy Preserving Verifiable Credentials: The recognition of customers’ entitlement to a high level of security in mobile banking that is compliant with the requirements of the GDPR.

OB-UC1 – Cross-Border Settlements between Financial Institutions

This use case aims to investigate efficient ways to shorten the time for the settlement of interbank payments, global payments, and securities. In recent years, blockchain technologies have gained momentum, placing themselves at the forefront of technology innovation in many fields, such as crypto-currencies and supply-chain management. However, financial institutions still hold some doubts regarding the feasibility of using the blockchain for a number of reasons. Namely:

• Privacy: the blockchain relies on the availability of transactions and their order of execution to all the system’s participants. However, organizations are not willing to share their data with potential competitors, and then to restrict data sharing as much as possible.

• Scalability: existing blockchains transaction processing speed is vastly inferior to the transaction processing requirements of modern financial systems. (e.g., VISA's ~50.000 per second). There is the need for a solution that allows the blockchain to scale to without sacrificing its throughput.

• Lack of Governance: the blockchain is a decentralized system that removes the need of a trusted third-party overseeing its operations. However, organizations still want to assert a certain degree of control over their systems and networks to enforce business logics and policies.

This use case proposes a blockchain architecture capable of solving the aforementioned issues.

Use Case Diagram


14

Figure 2 depicts a scenario that is greatly simplified for the purpose of clarity: that is, the number of entities involved and their interactions are limited. The blockchain architecture:

• Enables banks in different administrative regions to securely and timely exchange transactions • Keeps track of all transactions in the system • Allows for the deployment of smart contracts to validate and settle transactions, and enforce specific

financial policies. • Runs a consensus protocol between business partners to reach consensus over the legitimacy of

transactions and the consistency of each participant’s transactions history.

OB-UC2 – Illegal Access to the System

The use case aims to find ways to prevent a hacker or a malicious user from targeting the Identity Provider, API Manager or the API Portal of the Open API architecture using the interfaces and communication channels with a view to gaining illegal access to the system by spoofing is identity or using MITM attacks.

Use Case Diagram

SharedLedger

Blockchain Network

Figure 2: Open Banking - Simplified view of an interbank settlement scenario


15

Figure 3: Open Banking - Workflow of an illegal access to the system

OB-UC3 – Unauthorized Information Change

The use case aims to find ways to prevent a hacker or a malicious user from targeting the API Gateway or the API Manager of the Open API architecture using data stored in transit with the intention of making unauthorized changes to the data which would then have its integrity compromised.

Use Case Diagram

Figure 4: Open Banking - Workflow of an unauthorized information change

OB-UC4 – Unauthorized Escalation of Privilege

The use case aims to find ways to prevent a hacker or a malicious user from targeting the API Gateway, the API Manager or the API Portal of the Open API architecture using the authorisation system or the


16

development environment with the goal of making unauthorized access to functions and information with potentially privileged access to restricted resources.

Use Case Diagram

Figure 5: Open Banking - Workflow of an unauthorized escalation of privileges

OB-UC5 – Open Banking Sensitive Data Sharing Network for Europe (OBSIDIAN)

There are six stages to this use case: (1) Preparing effective fraud information in order to post it to the network describes a set of tasks

to be completed by a network member in order to convert the data about a fraud she has experienced in her context in a format sharable with other members of the network (anonymization, certification).

(2) Reporting fraud information in the network is the process used by a member of the network to report to the network the data computed at the first stage.

(3) Scoring a transaction with information provided by the network is the process used by a member of the network to request the network to score the data (IBAN et al) used in a transaction.

(4) Facing a fraud confirmed by information provided by the network describes the actions performed by a network member when he detects an effective fraud which is confirmed by information provided by the network. These actions include updating network information based on the new fraud case.

(5) Dealing with a false positive provided by the network describes the actions performed by a network member when he experiences a false positive when scoring a given transaction with information provided by the proposed network.

(6) Defining precise rules for data and fraud network access describes exactly and in what context an entity is authorized to access the proposed network. It also defines the technical authorization system put in place to restrict access. Finally, it defines which interlocutors within the entity are authorized to access the data.

OB-UC6 – Establishing Quality User Experiences

There are three stages to this use case: (1) Preparing effective information on institutional IBANs (white list IBAN) for publication on the

network describes a set of tasks performed by a network member to convert data on institutional IBANs known to it into a format that can be shared with other network members


17

(anonymization, certification, etc.) in order to help partners reduce the number of false positives they detect in the fight against fraud.

(2) Reporting institutional IBANs information in the network is the process used by a network member to report to the network the data computed in UC10.

(3) Defining exact rules for data and institutional IBAN network access describes precisely and in what context an entity is authorized to access the network. It also defines the technical authorization system put in place to restrict access. Finally, it defines which interlocutors within the entity are authorized to access the data.

OB-UC7 – Network Access to Data and Money Laundering Information

There are three stages to this use case: (1) Preparing effective information on money laundering for publication on the network describes

a set of tasks performed by a network member to convert the money laundering data it detects into a format to be shared with other network members (anonymization, certification, etc.).

(2) Reporting money laundering information in the network is the process used by a network member to report to the network the data computed in (1)

(3) Defining precise rules for data and money laundering network access describes exactly and contextually an entity is authorized to access the network. It also defines the technical authorization system put in place to restrict access. Finally, it defines which interlocutors within the entity are authorized to access the data.

OB-UC8 – Sharing Terrorist Financing Information in the Network

There are three stages to this use case: (1) Preparing effective information on terrorist financing for publication on the network: this use

case describes the different tasks performed by a network member to convert the terrorist financing data it detects into a format shared with other network members (anonymization, certification, etc.).

(2) Reporting terrorist financing information in the network: this use case describes the process used by a network member to report to the network the data computed in UC14.

(3) Defining exact rules for data and terrorist financing network access case describes precisely and contextually an entity is authorised to access the network. It also defines the technical authorization system put in place to restrict access. Finally, it defines which interlocutors within the entity are authorized to access the data.

OB-UC9 – Privacy Preserving Verifiable Credentials

This use case recognises customers’ entitlement to a high level of security in mobile banking that is compliant with the requirements of the GDPR. The intention is to use verifiable credentials protect users’ data and privacy down to the attribute level. Current approaches using FIMs fail to provide that level of protection and security and the use case will take the following approaches to demonstrate the importance of being able to use verifiable credentials.

(1) Users are in control of the use of their verifiable credentials, whereas the FIM IdPs are in control of the users' identities i.e. users can present verifiable credentials to whichever verifier will accept them, whenever they wish, whereas FIM users can only present their identity attributes to SPs that the IdP is willing to trust. IdPs are usually not willing or able to release all the user attributes that SPs require for fine-grained authorization.

(2) Since no single FIM IdP is the authoritative source of all a user’s identity attributes, this necessitates the pulling of user identity attributes from other attribute authorities. In order to solve this 'attribute aggregation' problem, the assignment of a persistent globally unique identifier to each user is proposed by many. But this has privacy implications for the user, as it provides a correlating handle


18

that can be used to track the user everywhere. Verifiable credentials allow a user to present multiple credentials from multiple issuers as required by the verifier, without the need for a globally unique identifier.

(3) Verifiable credentials provide "least privileges" because the user only reveals to the SP those identity attributes that are necessary for the required service at the time of access, whereas with FIM systems, all the user's identity attributes are presented at login time, before the actual service has been chosen.

(4) Verifiable credentials are more privacy protecting. FIM IdPs know which SPs the user is visiting and when, which allows IdPs to track users in violation of their privacy. Verifiable credentials stop the issuer from tracking users’ movements. Furthermore, verifiable credentials provide "selective disclosure" so that the user only needs to reveal part of a verifiable credential e.g., only the date of birth from a driving licence.

(5) Verifiable credentials are more secure. FIM systems facilitate phishing attacks, whereby an untrustworthy SP redirects the user to a masquerading IdP, which then steals the user’s authentication credentials. Verifiable credential ecosystems are not open to phishing attacks because there is no redirection, and there are no usernames and passwords to be phished. The recent Facebook hack highlights another security weakness with FIMs. If an IdP is compromised, it allows the attacker to login to every trusted SP where the user has an account. Finally, because most FIM IdPs issue bearer assertions or tokens, they can be stolen and used by an attacker. VCs on the other hand use cryptographically secured credentials that attackers cannot use.

(6) Verifiable credentials make verifiers (SPs) compliance with GDPR [8] easier as follows: • Clause 6(1)(a) – the data subject has given consent by sending his/her verifiable credentials; • Clause 7(1) – the verifier can demonstrate consent because the set of verifiable credentials is signed

by the user; • Clause 6(1)(b) – the verifier requests only those verifiable credentials that are necessary for

performing the contracted service with the data subject; • Clause 5(1)(c) – the requested verifiable credentials are adequate, relevant and limited to what is

necessary in relation to the purposes for which they are processed ("data minimization"); • Clause 5(1)(d) – the verifiable credentials are accurate and up to date; • Clause 5(1) (f) – verifiable credentials are cryptographically protected and can be processed in a

manner that ensures appropriate security of the personal data; • Clause 11 – the verifier does not require the identification of the data subject (but only the attributes

necessary for the service).

Use Case Diagram


19

Figure 6: Open Banking – Opening a bank account with verifiable credentials

3.5 Security and Privacy Requirements

ID REQUIREMENT DESCRIPTION USE CASES PRIORITY MANDATORY

OB-SP01 Authentication

Actors must be authenticated and have a verifiable identity in the system

OB-UC1 High Yes

Figure 7: Open Banking - The goal of verifiable credentials


20


OB-SP02 Identity management

A PKI infrastructure must be in place to provide every actor with unforgeable key-pairs

OB-UC1 High Yes

OB-SP03

Message authentication

Actors must use their digital signature to sign all transactions

OB-UC1 High Yes

OB-SP04 End-to-end security

Communications go through secure TLS channels to provide a safe medium within the system

OB-UC1 High Yes

OB-SP05 Anonymity

Anonymization techniques prevent the leakage of actors’ sensitive information

OB-UC1 High Yes

OB-SP06

Privacy-preserving analytics

Actors can leverage privacy-preserving data analytics to extract information that allows them to optimize their business strategies

OB-UC1 Low No

OB-SP07 OAuth

To provide controls to ensure that unauthorised user cannot access the system.

OB-UC2 OB-UC3 OB-UC4

High Yes

OB-SP08

Authentication using shared keys -

authentication using public key

cryptography

To provide controls to ensure that unauthorised user cannot access to the system.


High Yes

OB-SP09 SAML 2.0

To provide controls to ensure that unauthorised flows cannot occur


High Yes

OB-SP10 Federated identity

To provide controls to ensure that unauthorised flows cannot occur


High Yes


21


OB-SP11

Non-bypassable login function

To avoid changes of login page (e.g. fake forms) to exfiltrate data


High Yes

OB-SP12 Encryption To avoid clear storage of

sensitive data.


High Yes

OB-SP13

Key-based authorization

To provide controls to ensure that unauthorised flows cannot occur.


High Yes

OB-SP14

Access rules & permissions

The system shall be designed and implemented so that the security features cannot be bypassed.


High Yes

OB-SP15 Access control

The system shall be designed and implemented so that the security features cannot be bypassed.


High Yes

OB-SP16 Encryption

To provide controls to prevent confidentiality compromises.


High Yes

OB-SP17 Log protection

To provide controls to prevent unauthorized actions from being hidden.


Medium No

OB-SP18 S-SDLC

The CMS shall provide measures such that only authorised changes are made to the configuration items

OB- OB-UC2

OB-UC3 OB-UC4

High Yes

OB-SP19

Security policy configuration

The CMS shall provide measures such that only authorised changes are made to the configuration items


High Yes

OB-SP20

Key lifecycle management

To provide controls to ensure that unauthorised users cannot access the system


High Yes


22


OB-SP21


To reduce the likelihood that accidental or unauthorised modifications will occur. i.e., the system shall be designed and implemented so that the security features cannot be bypassed.


High Yes

OB-SP22


For all designed policies, the model shall provide a formal proof that the system cannot reach a non-secure state.


High Yes

OB-SP23 Data protection rules

The security functions shall be designed and implemented so that it is able to protect itself from untrusted active entities.


High Yes

OB-SP24 Hashing

To provide controls to prevent integrity compromises.


High Yes

OB-SP25 Log protection

To provide controls to prevent unauthorized actions from being hidden.


Low No

OB-SP26 Least privileges

Verifiable credentials provide least privileges, integrity protection, high availability, high security, and prevent phishing attacks.

OB-UC9 High Yes

OB-SP27 Selective disclosure

Verifiable credentials provide selective disclosure and stop an IdP from tracking a user and also help stakeholders conform to GDPR.

OB-UC9 High Yes


23


OB-SP28 Trust model

Verifiable credentials employ a simple trust model in which verifiers unilaterally decide who they will trust to issue verifiable claims. Issuers do not need to trust verifiers and are not required to know who the verifiers are.

OB-UC9 High Yes

Table 2: Open Banking - Security and privacy requirements

3.6 Non-Functional Requirements

Look and Feel Requirements

ID REQUIREMENT DESCRIPTION USE

CASES PRIORITY MANDATORY

OB-LF01 Client Interface

Client interface allows actors to easily interact with the blockchain to manage their respective organization’s operations

OB-UC1 Medium Yes

OB-LF02

Encryption for data storage

To avoid storage of sensitive data in the clear.

OB-UC2, OB-UC4 Medium Yes

OB-LF03

Access rules & permissions for

unauthorized access

The system should be designed and implemented so that the security features cannot be bypassed.

OB-UC2, OB-UC4 High Yes

OB-LF04

Access control for unauthorized access



OB-LF05

Data protection rules for confidentiality

compromise

The security functions should be designed and implemented so that the system is able to protect itself from untrusted active entities access.



24

Table 3: Open Banking - Look and feel requirements

Usability Requirements


OB-U01 Error Reporting

The system reports errors and security breaches timely and automatically.

OB-UC1 High Yes

OB-U02

Open banking usability

The proposed network will be expected to support open banking usability characteristics, including real time and high availability requirements.


OB-U03

Verifiable credentials

Verifiable credentials remove the need for users to have countless user names and passwords, to carry physical credentials around with them, and to enter identity attributes and credit card details manually into websites.

OB-UC9 High Yes

Table 4: Open Banking - Usability requirements

Operational Requirements

ID REQUIREMENT DESCRIPTION USE CASES

PRIORITY MANDATORY

OB-OP01 Throughput

The system must be able to process tens of thousands of transactions per second.

OB-UC1 High Yes

OB-OP02

Byzantine Fault Tolerance

The system must be resilient to byzantine faults. It should continue its operations even if multiple banks are offline because of hardware failures or malicious attacks.

OB-UC1 High Yes

OB-OP03 Scalability

The system must be able to scale to a significant number of nodes to allow several banks in a single country, or in a regional alliance

OB-UC1 High Yes


25


PRIORITY MANDATORY

(APAC), to join the same network.

Table 5: Open Banking - Operational requirements

Maintainability and Portability Requirements

No maintainability and portability requirements have been identified at this point.

Social and Political Requirements

No social and political requirements have been identified at this point.

Legal and Regulatory Requirements


OB-LR01 GDPR compliance

The system must handle data in full compliance with the GDPR.

OB-UC1 High Yes

OB-LR02 Fraud protection

The system must provide protection against financial fraud.

OB-UC1 High Yes

OB-LR03

Encryption for data storage

To avoid storage of sensitive data in the clear.


OB-LR04

Access rules & permissions for

unauthorized access



OB-LR05

Access control for unauthorized access



OB-LR06

Data protection rules for confidentiality

compromise

The security functions should be designed and implemented so that it is able to protect itself from untrusted active entities.



26


OB-LR07 Data sharing

Some European countries (Austria, Switzerland, France) must respect the bank secrecy principle. Data sharing will have to use a format compatible with national legislations.



The EDPB will have to be engaged in the build phase in order to validate data sharing.

OB-UC5, OB-UC8 Medium Yes


Verifiable credentials make verifiers’ GDPR compliance easier regarding clauses 5(1)(c)(d)(f), 6(1)(a)(b), 7(1) and 11.

OB-UC9 High Yes

Table 6: Open Banking - Legal and Regulatory requirements

3.7 Mandated Constraints

No mandated constraints have been identified at this point.

3.8 Relevant Facts and Assumptions

Facts

No relevant facts affecting the system have been identified at this point.

Assumptions

No assumptions about the system have been identified at this point.

3.9 Related WP3 and WP4 Tasks

WP3 defines all common research related to the development of technologies that are leveraged in the demonstration use cases. Here are some tasks of WP3 that provide techniques that are useful for the maritime demonstrator.

• T3.2: Research and integration on cybersecurity enablers and underlying technologies. This task is the most relevant to task 5.1 as one of the common baseline technologies to be investigated are the ones related to identity management and authentication solutions over multiple non-federated providers solutions (Verifiable Credentials) as well as distributed access control using blockchain (Settlements).


27

• T3.5: Adaptive security. This task investigates the development of flexible security solutions that can quickly adapt security controls in response to security changes such as new attacks or changes in security requirements which could be relevant in each of the four use cases.

• T3.6: Usable security. This task is also concerned about mechanism to support users` privacy mechanism and as such enabling effective and usable security controls of user attributes, which could resonate with the Verifiable Credentials use case.

• T3.7: Regulatory sources for citizen-friendly goals. The purpose of this task is to design best practices for innovative and GDPR compliant user experience and to investigate the compliance for identity technologies interoperability, as well as the legitimacy of technologies used and processing of personal data in cross-border and cross-sector. This could be pertinent to all four use cases.

• T3.8 Conformity, Validation and Certification. This task analyses technologies, system designs and implementations to determine whether the combination of cybersecurity technologies in use achieve the desired security goals, allowing to compare different systems. The task will design a security framework capable of formally defining cyber-physical attack incidents, detecting an intrusion at different levels (physical or cyber), provide a resiliency policy and generate a forensics analysis – all of which could resonate with all four use cases.

• T3.9 Continuous Scouting. This task seeks to identify game-changing innovative approaches that are an essential component of innovative Open Banking applications.

• T3.10 Impact on Society. This task intends to advance a novel security awareness conceptual model with continuous enhancements is very relevant to the significant changes in Open Banking that are impactful on all citizens – inasmuch as all citizens are highly susceptible to any changes in the changes to the processing of financial transactions.

WP4 is the bridge between WP3 and WP5, and although there is one task that specifically correlates with Task 5.1, there are synergies in other areas when addressing long term roadmap issues. Task 5.1 will contribute to the following WP4 activities:

• T4.1: Vertical stakeholders’ engagement and consultation. This task is the general roadmap design and applies to all of the tasks in WP5

• T4.4: Roadmap for industrial challenge 5.1. This task is the one that is directly related to the output from task 5.1

• T4.5: Roadmap for industrial challenge 5.2. This task addresses the roadmap challenges for the management of supply chains, which is a key aspect of the Settlements use case

• T4.6: Roadmap for industrial challenge 5.3. This task which is focused on privacy-preserving identity management has a direct correlation with the Verifiable Credentials use case

• T4.7: Roadmap for industrial challenge 5.4. This task involves the challenges associated with incident reporting, particularly in the finance community, which resonates with the OBSIDIAN use case

WORK PACKAGE T1 T2 T3 T4 T5 T6 T7 T8 T9 T10

WP3 ü ü ü ü ü ü ü ü

WP4 ü ü ü ü ü

Table 7: Open Banking - Relationship with WP3 and WP4 tasks


28

4 Supply Chain Security Assurance In this section, we describe the requirements for the CyberSec4Europe demonstration case titled Supply Chain Security Assurance. This chapter is organized as follows: we first provide a high-level overview of the demonstration case and its goals, followed by a description of the actors involved. We then provide more detailed functional requirements using use cases, followed by a description of non-functional requirements. Finally, we report relevant constraints and assumption to be considered while implementing this demonstration case.

4.1 Goals

The demonstration case reflects the need to secure a crucial ongoing transformation in the manufacturing industries: the integration of information technologies (IT) with the existing operational technologies (OT) [Che17, Lop17, Lu17]. The purpose of this digitalization of the value chain is the optimization of processes in terms of production costs, delivery services, and quality assurance under the customized interaction of new stakeholders such as customers or end consumers [Che17,Lu17]. Under this commitment to digitize and interact with diverse entities, new security challenges arise [Tup18], for example: the secure interconnection of IT-OT networks [Alc19], the influence of the new technologies in the operation processes, and the tracking, auditing and accountability of all processes and entities involved in the value chain. The value chains present different criticality levels according to the product, [Lop17]: “It is not the same to protect […] the construction of a bicycle, as [to secure the production of] a plane or a train”. Attacks against the supply chain can be very devastating, as the whole integrity of the manufactured product is at risk. Without proper security, this type of attacks are deemed to increase in number and impact over the next years.

4.2 Stakeholders

The main stakeholders in this demonstration are: • The manufacturer of a good, which wants to optimize his processes, reduce costs, have a better

overview of the exact state of the supply chain in order to act on time to any problem that could appear. A very similar role is played by the Engineering, Procurement, and Construction contractor (EPC), which coordinates the construction of a system.

• The end consumer (or owner) of the produced good, for instance the operator of a critical infrastructure or an airline that buys an airplane. Since he will be responsible for the quality of the manufactured good, he is interested in verifying the quality of the good he is buying. In case of any problem due to the poor quality or late delivery of the ordered goods he will suffer costly delays in his business.

• The suppliers, which deliver parts, components, or raw materials for the production. He is interested that his parts are available on time for production and that the main manufacturer or the product owner accepts his as a reliable partner.

• The Supervisory Agency (Authority) must understand the root cause of incidents (say accidents in a plant, in a train or airplane or in a hospital) or of complaints about the poor quality of a lot of goods. This agency has the authority to judge on accountability and liability issues, including the compliance of production with required standards and to take measures against a non-compliant entity.


29

• The notified body is a governmental entity that monitors the construction of the product and is notified about the single compliance-relevant steps during the process.

4.3 Actors

In this section we provide a list of actors with brief descriptions. Actors are all the entities that interact with the Supply Chain ecosystem. They can be of two types: (i) Primary actors, which are actors that have goals which this demonstration case needs to fulfill; and (ii) Secondary actors, which don't have specific goals associated with this demonstration case, but are needed for the execution of its use cases.

Primary

Actors who, at some point along the supply chain, have an ownership stake of the good: • End Consumer: owner of the final good with own criteria to customize and improve production

processes. In the case of industrial products he/she is often also the main responsible for the quality of the final product.

• Store: makes goods available to end consumers. • Warehouse: buys goods from manufacturers in bulk and distributes them to retailers. • Engineering, Procurement, and Construction (EPC) contractor: entity responsible for all the

activities from design, procurement, construction, commissioning and handover of the project or good to the end consumer or owner.

• Manufacturer: manufactures goods. • Supplier: supplies raw materials and components to manufacturers. • Supervisory Agency (Authority): gathers information about incidents or complaints and decides

on accountability and liability issues, evaluating the compliance of production steps and audit trail.

Secondary

Actors who do not own the goods, but play a role in the supply chain process: • Logistics services provider: moves goods between primary actors (e.g., UPS, DHL, etc.) • Consultancy agency: audits and certifies the supply chain process. • Financial institution: processes payments. • Government agency: governmental entity that interacts with the flow of goods entering/leaving

the country (e.g., customs office, food safety agencies, drug agencies, etc.) • Notified Body (NoBo): governmental entity that is being notified on each main step in the design

and or production and (in our simplified UCs) accepts the design and construction of the product. • Equipment provider: provides other actors with tools to carry out their operations. • Indirect material supplier: supply goods that support the supply chain but are not associated with

the goods produced by a given supply chain.


30

Use Cases Numbers

ACTOR UC1 UC2 End Consumer X X

Store X Warehouse X

Manufacturer X X EPC X

Supplier X X NoBo X

Supervisory Agency X Table 8: Supply Chain Security Assurance - Mapping of actors to use cases


In this section we provide a brief description of this demonstration case functionalities, along with a list of use cases implementing them.

Overview of functionalities

The integration of IT technologies and OT offers a new possibility of optimizing the supply chain in order to handle market changes in a timely manner, reduce delays, ensure to deliver just-in-time production, predict and understand problems. To obtain these improvements it is necessary to monitor process status, the performance across the production plants, transportation systems, warehouses, and to track the parts and products along the whole production and supply. Besides a faster and cheaper production, the new technologies and processes offer the possibility to verify the quality of the parts and products and the ability to demonstrate the compliance of parts and products to authorized parties. Providers and manufacturers run tests on parts, components, products, and the resulting audit protocol is signed for instance by a smart object embedded in the part and the testing equipment. The genuineness and integrity of products, as well as the compliance with manufacturing standards is demonstrated, certification authorities can access information to verify and certify products. In case of a problem or a dispute about a problem with a product, a judge should be able to resolve the dispute and identify the root cause and the entity responsible of the problem. This is particularly interesting because some of the information is kept confidential for the normal use case.

Use Cases List

• SCH-UC1 - Supply Chain for Retail: this use-case describes a supply chain system for retail. The supply chain’s flows leverage a distributed ledger to carry out their operations.

• SCH-UC2 - Compliance and Accountability in Distributed Manufacturing: this use case describes a supply chain system for industrial products and expands the previous UC with questions regarding the compliance of manufacturing and accountability issues.

SCH-UC1 – Supply Chain for Retail

Supply-chains are very complex systems moving products or services from suppliers to customers. Nowadays, their complexity has reached the point where organizations can hardly keep track of what is going on at the lower levels of their supply-chains. There is much that a distributed ledger can do for the supply chain ecosystem:

• Trust: a distributed ledger technology (DTL) removes the need for a trusted central organization operating and maintaining the system. It allows various players that do not necessarily trust each


31

other, such as shipping companies, logistics and transport operators, insurers, and stores to collaborate within one common platform in order to scale-up their respective businesses.

• Digitization: a distributed ledger can help by digitizing the sales processes, facilitating payments in close to real time, and the development of legal contracts between participants. The latter can be easily done via smart contracts, that is, Turing complete programs that can be uploaded to the distributed ledger. The digitization process drastically reduces the chance of human errors and eventually will ensure that every member has an identical view of who did what and when, thus removing database inconsistencies.

• Securing information: a distributed ledger offers a secure and highly resilient information sharing platform that is resilient to cyber-attacks by tolerating Byzantine faults in the system. Transfer of information is done via signed transactions. Since owners' signatures are unforgeable, nobody can challenge the legitimacy of any transfer. Additionally, all information is hashed before storage, making it impossible for anyone to alter it without being immediately detected.

• Counterfeiting: Goods can be associated with unique identifiers which, combined with the stored history of transactions, is a very powerful weapon against counterfeiting. The distributed ledger will store the unique products identifiers and history of transfer between suppliers. In order to further ensure the genuinity of products, certification authorities can join the distributed ledger to certify products. The distributed ledger will then store the product information and additional data to verify authenticity.

Use Case Diagram

• Figure 8: Supply Chain Security Assurance - Simplified view of a supply chain workflow

Figure 8 show a simple supply-chain scenario featuring: • Two suppliers supplying a single raw material • One manufacturer producing a single type of good. • One warehouse handling stores orders and distributing goods to them as needed. Warehouses can

be shared by different manufacturers. • Two stores in different geographical location to achieve maximum coverage.

The depicted scenario is greatly simplified for the purpose of clarity, that is, the number of entities involved and their interactions is limited.

��

��

��

��

��


32

SCH-UC2 – Compliance and Accountability in distributed Manufacturing

A large industrial manufacturing enterprise with many suppliers or a consortium of several producers must be able to track and monitor not only the location, movements, and availability but also the quality and compliance of parts and products, and the conditions of transport or storage. Manufacturing compliance comprises the set of technical, legal and corporate requirements, manufacturers must fulfil in order to create and market goods in accordance with regulations and industrial practices. Compliance responsibilities of manufacturers and suppliers are growing due to the establishment of regulatory rules, directives, and supervisory bodies in different industry sectors, along with the emergence of international standards to address the global nature of manufacturing. The risk of non-compliance has become a pressing concern in recent years, particularly for manufacturers with operations in multiple countries and jurisdictions. Compliance mechanisms and controls include audits, system validations, audit trails, electronic signatures, and documentation of development, manufacturing and testing. Such procedures must result in verifiable certifications which can be used to demonstrate compliance to a regulation such as, for example, the Machinery Directive 2006/42/EC [EU16]. Companies should increase controls over suppliers and be able to track risks and incidents down to their originating point. For this reason, suppliers are required to (1) collect design, manufacturing, and test data, (2) share them to authorities and to their customers to prove compliance. Many of these controls and modes to verify the compliance of the regulatory frameworks are also contemplated by guidelines, recommendations and standards such as “Cybersecurity Framework” [NIS18], “Best Practices in Cyber Supply Chain Risk Management” [NIS-C] and “Cybersecurity Framework Manufacturing Profile (NISTIR 8183)” [NIS17]. This latter clearly establishes the need to: “define, implement, and enforce policy and regulations” (PR.IP-5) and “conduct detection activities in accordance with applicable federal and state laws, industry regulations and standards, policies, and other applicable requirements” (DE.DP-2).

Use Case Diagram


33

Figure 9: Supply Chain Security Assurance - Simplified view of a compliance audit trail and accountability

Figure 9 shows a simple compliance audit trail scenario featuring: • One owner that orders a product from an EPC contractor. • One supplier supplying components and providing evidence of tests for quality and compliance. • One EPC / manufacturer producing an industrial good for critical infrastructure or constructing a

plant. • One supervisory agency gathering information about an incident and clearing accountability and

liability issues.



SCH-SP01 Authentication

Actors must be authenticated and have a verifiable identity in the system

SCH-UC1, SCH-UC2 High Yes


34


SCH-SP02

Identity Management

A PKI infrastructure must be in place to provide every actor with unforgeable key-pairs

SCH-UC1, SCH-UC2

High Yes

SCH-SP03

Message Authentication

Actors must use their digital signature to sign all transactions

SCH-UC1, SCH-UC2

High Yes

SCH-SP04

End-to-End Security

Communications over secure channels to provide a safe medium within the supply chain

SCH-UC1, SCH-UC2

High Yes

SCH-SP05 Integrity

the value chain data must present an integral format throughout its entire life cycle, without corrupting the real meaning of the transactions, actions or behaviors carried out within its own value chain.


SCH-SP06

Confidentiality

the protection of access to sensitive data from unauthorized entities and the safeguard of the privacy of individuals involved in the production and supply process

SCH-UC1, SCH-UC2

High Yes

SCH-SP07

Authorization and Access Control

The supply-chain information system should provide different levels of access and visibility. The manufacturer does not want that sensor information pertaining to the provenance or current conditions of the goods leaks to competitors and therefore wants to assure



35


the confidentiality of this data.

SCH-SP08 Anonymity

Anonymization techniques allow actors to carry out their supply-chain operations without unveiling their identity


SCH-SP09

Privacy-Preserving Analytics

Actors can leverage privacy-preserving data analytics to extract information that allows them to optimize their business strategies

SCH-UC1 Low No

SCH-SP10 Non-repudiation

Digital evidence (provided for instance by digital signatures), keep record of relevant activities of the diverse entities within the system. Through these mechanisms it is possible to establish responsibility measures and control the actions taken in the entire system. This requirement is a precondition for accountability, but it is often in competition or tension to confidentiality and privacy.

SCH-UC2 High Yes

SCH-SP11

Accountability

The actions taken within the entire value chain can be traced to verify the compliance of policies and regulatory frameworks.

The lawful disclosure of the identities of parties suspected of not acting according to the rules or claiming false information

SCH-UC2 High Yes


36


should be provided to authorized entities

Table 9: Supply Chain Security Assurance - Security and Privacy requirements





SCH-LF01

Client Interface

Client interface allows actors to easily interact with the distributed ledger to manage their respective organization’s operations

SCH-UC1, SCH-UC2

Medium Yes

SCH-LF02

Technological uncoupling

The blockchain technology should not interfere in the control and operational requirements. Namely, any IT technological coupling should not affect the underlying infrastructures and its monitoring 24/7.

SCH-UC1 High Yes

Table 10: Supply Chain Security Assurance - Look and Feel requirements



SCH-U01 Error Reporting

The system reports errors and security breaches timely and automatically


SCH-U02

Secure configurability

The system allows all partners to manage and configure the underlying platforms and their policies in a secure, usable, and consistent way.

SCH-UC1 Medium Yes

Table 11: Supply Chain Security Assurance - Usability requirements


37



PRIORITY MANDATORY

SCH-OP01 Throughput

The system must be able to process tens of thousands of transactions per second


SCH-OP02

Byzantine Fault Tolerance

The system must be resilient to byzantine faults


SCH-OP03 Scalability

The system must be able to scale to a significant number of nodes to handle the significant size of today’s supply chains


SCH-OP04

Operational Performance

The system must be updated without major impact in the supply chain operations. This requirement is related to LF02.

SCH-UC1 High Yes

SCH-OP05 Auditing

The system must provide logging and monitoring of its operations, so as to support audit and accountability procedures.


Table 12: Supply Chain Security Assurance - Operational requirements


No maintainability and portability requirements have been identified at this point.


No social and political requirements have been identified at this point.




SCH-LR01

GDPR Compliance

The system must handle data in full compliance with the European General Data Protection Regulation (GDPR). Namely, it will only work on, and store, metadata needed to ensure correct operations. At no point in time the system will store users’ data, thus preventing the



38



disclosure or identification of a user’s identity.

SCH-LR02

Counterfeiting Protection

The system must provide protection against counterfeiting


SCH-LR03 Fraud Protection

The system must provide protection against financial fraud


SCH-LR04 Transparency

The provision of information to environmental agencies, United Nation Programmes, local authorities, certification organizations, NGOs or to the general public related to matters that concern the society as a whole: sustainability, environmental fingerprint, labour conditions, compliance with fair trade or organic standards, etc.

SCH-UC2 High Yes

Table 13: Supply Chain Security Assurance - Legal and Regulatory requirements




Facts


Assumptions



The security of the supply chain, as to be developed in Task 5.2, is related to several transversal security technologies and research aspects in security and privacy. Specifically, the relation to the tasks in WP3 is as follows:

• Task 3.1: this task addresses the project lifecycle; it will formulate the realistic progress of the project, impact potential, define the feedback for the project activities and communicate and


39

organise the progress behind the building blocks of the CyberSec4Europe ecosystem. This Task will probably will not provide any particular technical building blocks for Task 5.2, but will help in organizing and structuring the work.

• Task 3.2: this a very relevant task for Task 5.2, providing several of the the common baseline technologies to be used for securing the supply chain. Specifically, these are: (a) blockchain, (b) identity management, (c) PET (particularly for Anonymity, Privacy-Preserving Analytics, and GDPR compliance), (d) authentication solutions over multiple providers, (f) IoT Privacy Preserving Middleware Platform, (g) decentralized evidence-based authorization and distributed access control using blockchain, and (h) privacy- and integrity-preserving storage and processing of critical data with long-term protection requirements.

• Task 3.3: SDL - Software Development Lifecycle. This task identifying research challenges, requirements and approaches in all stages of the lifecycle of software. Among these, the mechanisms to enhance trust in pervasive infrastructures and technologies such as the IoT, cloud and fog, edge will be important in Supply Chain Security.

• Task 3.8 studies the topics conformity, validation and certification, which will be relevant for the Use Case SCH-UC2 - Compliance and Accountability in distributed Manufacturing. Here it will be necessary to analyse the system design to determine whether the proposed architecture do achieve the desired security goals and eventually prove the security of the whole system.

In relation to WP4, Task 5.2 will interact with: • Task 4.1, which collects requirements from demonstrator Task 5.2 and receives feedback from this

task for the roadmap. • Task 4.3, the general roadmap design. • Task 4.5, the task that is directly related to the results and evaluations of Task 5.2.


WP3 ü ü WP4 ü ü

Table 14: Supply Chan Security Assurance - Relationship with WP3 and WP4 tasks


40

5 Privacy-Preserving Identity Management In this section, we describe the requirements for the CyberSec4Europe demonstration case titled Privacy-preserving Identity Management. We first provide a high-level overview of the demonstration case and its goals, followed by a description of the actors involved. We then provide more detailed functional requirements using use cases, followed by a description of non-functional requirements. Finally, we report relevant constraints and assumption to be considered while implementing this demonstration case.

5.1 Goals

In an increasingly digital and inter-connected world, identity management systems offer a convenient and user-friendly way for handling different authentication and authorization domains. Over the last two decades, privacy-preserving identity management systems have gained significant attention by the academic community. More recently, this has been encompassed by increasing privacy awareness of the general public following major data breaches, as well as national and European data protection laws such as the General Data Protection Regulation (GDPR). In a nutshell, a privacy-preserving IdM system works as follows. A user can obtain a credential on a variety of personal attributes (e.g., name or birth of date) from an issuer, which may be a public authority, an educational institution, an online service provider, etc. Then, at a later point in time, the user can present such a credential to a relying party (aka service provider) to convince the relying party that she indeed satisfies some policy (e.g., that she is old enough to consume a certain service, or that she has a certain nationality). On the one hand, the presentation process needs to be performed in a way that gives the relying party high authenticity and integrity guarantees, i.e., it needs to be guaranteed that the user cannot “fake” a presentation without actually satisfying the policy. On the other hand, the user shall receive high privacy guarantees, meaning that no sensitive information than what the user is explicitly consenting to reveal (e.g., her birth date but not her name) is revealed to any party involved in the process. The objective in general it is to provide and eID ecosystem offering the citizen/users an efficient and convenient way to manage identities, including the possibility to anchor the trust on a secure and high level of assurance infrastructure that will be used for supporting different levels of privacy preserving and anonymization capabilities. Note that this is in contrast to many other IdM solutions – e.g., offered by major cloud providers from different sectors such as search engines, social networks, or online retailers – where the provider of the IdM system has full access to the user’s attributes and learns detailed behavior patterns about the user. Furthermore, relying parties often do not get end-to-end authenticity guarantees as the IdM provider vouches for the correctness of the attributes, but no formal link to the original issuer can be given. The goal of this demonstrator is to develop a highly efficient, scalable, and user-friendly IdM system giving formal security and privacy guarantees to all parties, thereby pushing forward the state-of-the-art in privacy-preserving cryptography. The core technologies shall be flexible enough to be deployed in many application domains, such as eHealth (e.g., where a user can reveal different parts of a treatment report to her insurance company, employer, or family doctor), eGovernment (e.g., thereby achieving paper de-materialization by replacing paper-based documents by electronic counterparts without having to give up on security), or others, including, but not limited to, smart cities, eCommerce, or physical access control to restricted areas. Additionally, and beyond privacy-preserving operations based on modern cryptography, the demonstrator will include state-of-the-art countermeasures for realizing security defenses. In particular, the demonstrator will include hardening techniques for ensuring that possible vulnerabilities will not pose the users’ data into risk. Specifically, we plan to leverage credential-hardening techniques for preventing attackers to abuse the system, on behalf of existing users, in the unfortunate event of a data breach involving the exfiltration of user credentials.


41

Within CyberSec4Europe, these core features and functionalities will be showcased in the educational sector, where, e.g., graduates are able to prove that they hold certain degrees, or defeated job applicants may file anonymous complaints in case of premature evaluations of a hiring committee. In the remainder of this section, we will aim for a compromise between generality and specificity. To do so, we will describe certain aspects of the use case agnostic of the precise demonstrator domain to ensure that our results are sufficiently generic to also be used in other application domains. Tough, on the other hand, we will give clarifying details on how these generic observations apply to our specific domain.

Demonstrator-specific background

In Greece there was an incidence of corruption where some people bought phony degrees from companies that sell “degrees” on the Internet without requiring the buyer to do anything more than pay a fee. CTI will lose its credibility if it hires an unqualified person as a researcher who may expose CTI and colleagues to potential damage. The CTI has to check out the academic degrees and insure the integrity of the hiring process. Nowadays CTI’s personnel is responsible for checking out the credibility of the submitted documents of a participant in a job or research position. To avoid hiring researchers with bogus submitted documents CTI personnel need to do a number of things spending a lot of time. The following actions performed to people that want to be hired. After the assessment committee recommend a specific participant for a job position the specific CTI’s personnel has to verify the authenticity of the participant’s submitted degrees and documents. This procedure must be done for all newly hired people. This verification is accomplished by viewing the original submitted documents, examining the stamps and signs on them and searching the credibility of the educational institutions. The goal of this demonstrator is to overcome these administrative hurdles by introducing electronic certificates for attended courses or obtained degrees, which can easily be presented to institutions like CTI. This should happen in a way that gives the future employer provable guarantees that the certificate was issued by a legitimate institution (e.g., another university). Once such a system has been set up, it can be leveraged to support many other desirable features as well. For instance, applicants may receive a credential upon application for a job offer, which they can later use to anonymously file an objection of the hiring committee’s decision if they feel discriminated in the application process. Or students could use their electronic certificates for passed exams to apply for stipends without having to reveal the precise courses taken, but only revealing the grades and associated ECTS points The precise scenarios have not yet been fully decided, but will only be chosen after the core components of the system have been designed, to avoid a design and architecture which is too specific for the chosen functionalities but not generic enough to also support other features and application domains.

5.2 Stakeholders

The ambition of this demonstrator is to give a way to graduates of education to digitally authenticate and share awards enhancing the multi-lateral trust. Demonstrator will provide a trustworthy and privacy preserving way to high education institutions to issue and verify education official documents and awards that contain private graduates’ information. Privacy Preserving, User Empowering, Identity Management concerns the verification of the education credentials and of the participants for a job position. The context is to allow secure and trustworthy exchange of higher education degrees, certifications and awards between several kinds of players with different aims and claims, regarding the security, data protection and trust issues: education organizations, companies and citizens. Demonstrator will allow higher education graduates an easy, verifiable means for them to share their awards and accomplishments as well as to promote their expertise.

5.3 Actors


42

In any identity management system, there exist a number of mandatory actors as well as some optional ones, depending on the specific features of the specific system and the environment within which it is deployed. The mandatory actors are users, issuers, and service providers (also known as relying parties or verifiers). Further additional actor roles may include revocation authorities, inspectors, or also IdM platform providers. In this section we provide a list of actors with brief descriptions. Actors are all the entities that interact with the Privacy-preserving Identity Management ecosystem. They can be of two types: (i) Primary actors, which are actors that have goals which this demonstration case needs to fulfill; and (ii) Secondary actors, which don’t have specific goals associated with this demonstration case, but are needed for the execution of its use cases. We differentiate between active and passive actors. Active actors initiate a process by an action or wish for action. Passive actors react upon a request of an active actor, but don’t initiate a chain of actions themselves. Users and inspector are seen as active actors. Users, generally, wish to login to a service provider and, thus, they must obtain, beforehand, appropriate credentials that satisfy the service provider’s policies. For users to be able to get credentials, an issuer has to take some actions in advance: to define, verify credentials, as well as provide the user with an account to retrieve the credentials. For simplicity, we consider this setting up of user accounts as a process initiated by the user, wishing to login to a service provider. Thus we view only the user and the inspector as actors that may initiate a process.

Primary

The following primary actors have immediate goals associated with privacy-preserving identity management systems: • Users wish to obtain credentials on their attributes from issuers, and later present (parts of) these

attributes to service providers in a privacy-preserving manner. Specifically, in our demonstrator domain, graduates receive certificates on degrees or passed courses, and can later selectively reveal this information, e.g., when applying for a job position, to local authorities, etc.

• Service providers/ Verifier want to receive provably authentic information about a user to grant her access to a specific service. They also need to be able to define a (minimum) policy a user must fulfill in order to be granted access. In the context of our use case, education organizations need be able to obtain verifiable claims on awards of applicants in order to accept them for a job position.

• Issuers certify a user’s attributes upon her request after checking whether these attributes indeed belong to the user. In the context of our use case, education organizations may, e.g., certify that a user possesses a certain degree, passed certain courses, or applied for a certain job position.

• Inspectors are able to revoke the anonymity of a certain presentation and unveil the identity of the user. We model inspectors as active actors as their actions are not triggered by another actor in the system. However, in reality, inspectors may typically become active, e.g., after a court order, i.e., after being triggered by an external entity. The need for an inspector is still being analyzed in the context of our demonstrator case.

• Revocation authorities provide publicly accessible revocation information such as white lists or black lists that may be used by service providers to decide whether or not to a accept a presentation based on a certain credential. Depending on the application scenario, revocation may be triggered by the issuer, a service provider, or the user herself. In our demonstrator case, the revocation authority and issuer will most likely coincide.

• IdM platform providers are hosting and maintaining the central infrastructure needed for an identity management system. Depending on the concrete instantiation of the system, their sole responsibility may be to provide certain system parameters, but they may also act as a relay/proxy for messages


43

being exchanged between the different actors, or even take over substantial parts of the computation to achieve a light-weight solution on the user’s side. The concrete underlying cryptographic technology has not yet been finally decided for our demonstration case and may also be influenced by ongoing research activities, e.g., in other work packages of the project.

Secondary

In the context of privacy-preserving identity management, several other actors need to participate despite not having direct goals associated with the specific application scenario. The secondary actors identified so far will be mainly be applications or platforms into which the different roles of a privacy-preserving identity management platform are embedded, but which in addition offer a broader range of functionalities in order to provide the precise semantics of the demonstrator scenario. In particular, they include the following systems:

• A Degree Verification System that performs access control by presenting a policy to the graduates. Only authorized users are given access to the Degree Verification System. Potential users of this application is the CTI personnel. The Degree Certification system provides a web service to education institutions where they their personnel can upload degrees and professional certifications. These degrees and certifications are then made available to the graduates.

• CTI’s Job Application Portal is web base information portal. Through this portal, the job participants and researchers will get information about the pilot system and functionality as well as information about its usage. Moreover, this portal also contains the necessary links to the components of the system (Educational Certification System, Degree Verification System) that the participants should access.

• The Educational Certification System lets graduates prove that they possess a certain degree or similar

• The User's Home Application provides the user with an interface that enables her to browse the credentials that she possesses and create verification tokens if she wants to share a legible document or degree.

Figure 10: Privacy-Preserving Identity Management - Demonstrator actors overview


44

Use Cases Numbers

ACTORS IDM-UC1

IDM-UC2

IDM-UC3

IDM-UC4

IDM-UC5

IDM-UC6

IDM-UC7

User X X X (X) X X

Issuer X (X) X Service Provider X (X)

Inspector X

Revocation Authority (X) X

IdM Platform Provider X (X) X Table 15: Privacy-Preserving Identity Management - mapping of actors to use cases


In this section we provide a brief description of this demonstration case functionalities, along with a list of use cases implementing them. We provide the corresponding use case forms in Appendix B. Note that we here focus on the demonstrator case only, and not on generic IdM systems, as there functional requirements already follow directly from the descriptions above.

• CTI will be responsible for the scheduling and realization of the Documents Certification scenario. • CTI will be responsible for the communication framework with graduates and the Department of

Computer Engineering and Informatics at University of Patras. • Department’s Registration Office employees have to provide a document containing a list of

participating graduates together with department related data. • Department’s Registration Office employees have to provide graduate with a document which when

signed guarantees their consent to participate in the demonstrator. • Department’s Registration Office employees will distribute to graduates a sealed envelop that

contains secure hardware device (smart card) for storing his personal information and a PIN for using it.

• Department’s Registration Office employees will distribute smart card reader to each graduate. • Department’s Registration Office employees will distribute a one time password in order the graduate

to be able to access the Educational Certification System for the first time. • CTI will contribute to the deployment and operation of the CTI’s. The systems required for the

demonstrator will be placed at CTI premises.


We suppose that the Set up phase has been finished and all the systems have been initiated and the graduates of Computer Engineering and Informatics Department have in their possession a smart card with a user secret. The scenario describes the procedures required so that the graduates can obtain credentials that certify that they have a legible property e.g., i) that they took the 1st or 2nd or 3rd degree from the department or that they passed a course. In order to handle smart card loss and retrieve the data stored in graduates’ smart cards, we define the next use case scenario that backups and restores graduates' information. The last and basic use case scenario considers the degree verification within the University of Patras.

Obtaining an Educational Credential An Academic officer is authorized to upload degrees or grades or academic documents like the decision of the PhD committee for a student to start writing her PhD thesis e.t.c in the database of the Educational


45

Certification System. Graduates thought Educational Certification System could get a receipt that they took the 1st or 2nd or 3rd degree from the department. When a graduate wants to obtain a valid educational credential, she browses to the CTI’s Job Application Portal and follows the provided instructions. Educational Certification System authenticates the graduate via the one time password (OTP, see setup phase) and initiates an issuance protocol that stores a valid graduate Privacy-ABC on her smart card. Graduate will get a valid educational credential in her smart card by logging in Educational Certification System via ABC technology. The educational credential stored in her smartcard contains attributes related with educational credits.

Data Backup and Restore This scenario is used in order to handle the loss of a smart card containing graduate’s information. This scenario allows a graduate to back up her information and to restore backed up data on her (new) smartcard. If a graduate has backup smart card content on her PC, she will be able to restore backed up data from her PC on her (new) SC though User Agent application. In order to restore the data, the User Agent application prompts graduate to enter her PIN. Note that the PIN for backup and restore can be selected by the user, thus may be different from the PIN for unlocking the SC. Graduate should connect her smart card reader to her PC before starting user agent application.

Degree Verification A group of graduates of Computer Engineer and Informatics that want to be hired can prove that they have a legible degree. We assume that the set up phase has been finished and all the graduates that will participate at the degree verification have at their possession a valid educational credential. This Degree Verification scenario is used for the realization of the verification of the submitted educational certifications for a job position. Each graduate should have an ABC4Trust SC reader and have installed the ABC user agent on her computer in order to start the degree verification procedure. Graduates are able to participate anonymously in a degree verification by logging in to the Educational Certification System via ABC technology. Whenever a graduate wants to submit his application to a CTI’s job position she can access the CTI’s Job Application Portal though her computer and the smart card reader. Then the CTI’s Job Application Portal will redirect him to the Educational Certification System where only users satisfying certain policies will be able to access. Graduates thought Educational Certification System could get an anonymous proof that they have a legible property that they took the 1st or 2nd or 3rd degree from the department or that they are msc or phd graduates.

Figure 11: Privacy-Preserving Identity Management - High-level overview of use cases


46

Use Cases List

In the following we specify the following use cases that are inherent to any privacy-preserving identity management sytem. • IDM-UC1 – Registration: allows a user to join a privacy-preserving IdM system • IDM-UC2 – Issuance: enables a user to receive a credential on her attributes • IDM-UC3 – Presentation: lets a user present parts of her attributes to a relying party • IDM-UC4 – Revocation: lets a user, relying party, or issuer invalidate a credential • IDM-UC5 – Inspection: allows a judge to de-anonymize a presentation • IDM-UC6 – Certificate renewal: lets a user request a new credential in replacement of an already

existing one • IDM-UC7 – De-registration: enables the user to leave the IdM system

IDM-UC1 – Registration

This use case describes all steps and interactions needed for a user to join a privacy-preserving identity management system. For reasons of identity assurance, and depending on the concrete instantiation and use case, this use case may involve offline (physical) processes like visiting an authority’s office, or online steps leveraging existing systems like governmentally-issued eIDs. In the course of the registration, the necessary (master) key material for a user is generated and made accessible to the user, e.g., in software, bound to a hardware token such as a smart card, or through a authority-hosted hardware security module (HSM). Specifically, for our demonstrator case, this use case contains all steps needed for a graduate to register to our demonstrator and to Degree Certification System. The Degree Certification system has stored the uploaded degrees and professional certifications. The graduate is following the instructions of the CTI’s Job Application Portal in order to be considered as a registered user.

IDM-UC2 - Issuance

To obtain a certificate on personal data, a user engages in an issuance session with a certificate issuer, which might be, e.g., a public authority, a university, or a service provider. In such an interaction, the user typically authenticates herself towards the issuer, and the two parties negotiate the specific attributes to be certified for the user (e.g., age, birth date, place of residence, nationality, expiration date, academic degrees, etc.). At the end of the interaction, the user receives a digital certificate (aka credential) attesting these attributes. Specifically within the domain of the degree certification use case, this step is needed for a graduate to receive a credential from the Degree Certification System. The attributes attest that she possesses a legible title. The graduate access the Degree Certification System thought CTI’s portal in order to request from it to certify that she has a legible academic degree/title/certificate.

IDM-UC3 - Presentation

A user can prove possession of a credential certifying certain personal attributes to a service provider (aka relying party) by engaging in a presentation protocol. In this protocol, the two parties agree on which attributes the user needs to reveal, e.g., based on a policy of the service provider. At the end of the interaction the service provider receives these attributes with high authenticity guarantees, while the user is guaranteed that no other information was revealed to the service provider. Specifically, within our demonstration case, this use case is performed when a student needs to generate a verifiable proof that she possesses a certain title or attended specific courses, e.g., to the job application portal or a local authority.


47

IDM-UC4 - Revocation

A user's credential may be invalidated or revoked for many different reasons, e.g., because of abuse or after a name change. Depending on the precise scenario, this process may be triggered by the different actors in the system. Firstly, the user may herself request the revocation of a credential at the issuer, e.g., if she suspects that her secret data was somehow leaked. Secondly, the issuer may revoke a certificate, e.g., because of abuse. Thirdly and finally, the service provider may decide the locally revoke a certain certificate, e.g., again because of abuse. As a result, the user will no longer be able to perform a presentation with the invalidated credential, either globally in the system or with this specific service provider. Within our demonstration domain, this use case will in particular be needed when attributes (e.g., names) change, or when unauthorized parties gained access to a user’s secret credential.

IDM-UC5 - Inspection

This use case allows a dedicated party, often referred to as “judge”, to revoke the anonymity of a specific presentation process, e.g., because of abuse.

IDM-UC6 – Certificate renewal

In this use case, a user can renew a credential that she already received earlier. This procedure may be triggered for different reasons, e.g., because the expiration date of a certificate has expired, or attributes such as name have changed. Also, the user may request a re-issuance of a credential that was previously revoked for some reason. The involved process is closely related to issuance (cf. UC2), yet might be more lightweight and require less strict attribute assurance. Also, depending on the concrete type of credential, the use case may trigger revocation of the underlying original credential (cf. UC4) in order to avoid that a user has multiple credentials on the same data.

IDM-UC7 – De-registration

This use case allows a user to completely de-register from the system. In this case, all certificates belonging to this user will be invalidated, and the user’s personal information will be deleted to the extent possible by legal regulations.



IDM-SP01 Data privacy

The hardware tokens used for store the degree information should comply with relevant standards, cryptography requirements, authentication protocols and protection profiles (if available) and must correctly implement them.

IDM-UC1, IDM-UC2 Medium No


48


IDM-SP02 Authenticity

The service provider/relying party in a presentation shall receive formally provable guarantees that the revealed attributes have not been altered by the user.

IDM-UC3 High Yes

IDM-SP03 Authentication

All components of CS4E must use authentication protocols to mutually authenticate. Each communication between the components, between any hardware token (SC), the Degree Verification System and between the verification service consumer shall only take place after a successful mutual authentication.

All High Yes

IDM-SP04

Authenticity of key material

In a real-world application scenario, it must be guaranteed that a key indeed belongs, e.g., to a certain issuer, in order to protect against adversaries issuing credentials under non-certified keys.

IDM-UC2, IDM-UC3, IDM-UC6

High Yes

IDM-SP05

Controlled linkability

Besides the users’ data itself, also metadata about the user such as usage or access patterns can be sensitive information. Any privacy-preserving identity management solution should therefore give users the option to decide which activities should be linkable to each other, and which activities should be provable unlinkable to each other.

IDM-UC3 Medium No


49


IDM-SP06

Selective and minimum disclosure

In order to maximize the level of privacy as well as for legal compliance purposes, users should have full control over which parts of their sensitive data they are willing to reveal to whom.

Furthermore, it is desirable that users can check whether certain relying parties are actually eligible to request certain pieces of information, similar to what was done in previous projects.

IDM-UC3 Medium Yes

IDM-SP07 Anonymity

The user’s identity must not be leaked to any other party in the system, neither through the presentation itself nor through metadata, expect if the user explicitly consented to reveal his identity.

IDM-UC3 High Yes

IDM-SP08

Anonymity revocation

While high privacy guarantees are essential, perfect anonymity might not always be desirable in order to avoid abuse. Therefore, depending on the specific scenario, a dedicated third party may be necessary that is able to revoke the anonymity of a user, e.g., upon judicial order.

However, it is necessary that the existence of this option is clearly communicated to the user, and also that this party is clearly specified.

IDM-UC5 Low No


50


IDM-SP09

Certificate invalidation

In order to prevent abuse through a user or in case of a data leak, it may be required to invalidate a credential, triggered by the user, the issuer, and/or a relying party. In this case, the revocation information (e.g., blacklists) should not leak the identities of the owners of the revoked credentials.

IDM-UC4 Low No

IDM-SP10

Identity and attribute

assurance

Depending on the concrete deployment scenario, high assurance guarantees regarding the identities of the credential owners, as well as the certified attributes, are required.

IDM-UC2, IDM-UC6 Medium No

IDM-SP11 Confidentiality

User credentials, for instance upon a data breach, should be hardened against cracking attempts.

All Medium No

Table 16: Privacy-Preserving Identity Management - Security and privacy requirements



No look and feel requirements have been identified at this point.


51



IDM-U01 Efficiency

In order to increase usability and future market penetration, all developed solutions must be highly efficient. In particular, the time needed for the cryptographic operations and necessary communication when receiving or presenting a credential should not exceed 1000ms, even when stored on a commodity smart card.

Furthermore, all user data must be presented in a sufficiently compact form to fit on such devices.

All, in particular IDM-UC3

High Yes

IDM-U02 Invisibility

While high privacy and security guarantees are appreciated by end users, broad adoption of security and privacy technologies requires a high level of invisibility towards the end user. For instance, canonical or well-known usage patterns should be affected as little as possible, as little additional steps as necessary should be introduced, not non-commodity hardware should be required, or the responsiveness and efficiency of the overall system should not be negatively impacted by the new solutions.


High Yes


52


IDM-U03 Transparency

All privacy guarantees but also the remaining privacy risks shall be communicated to the user in a highly transparent way, e.g., regarding metadata privacy but also regarding the existence of a third party that may revoke anonymity.

This is necessary to enable users to take informed decisions about their private data.

All, in particular

UC3 High Yes

Table 17: Privacy-Preserving Identity Management - Usability requirements



IDM-OP01 Scalability

Solutions provided and their integration on existing system should take into account privacy and security compliance, perceived ease-of-use, scalability and performance aspects


High Yes

Table 18: Privacy-Preserving Identity Management - Operational requirements



IDM-MP01 Compatibility

All developed solutions should aim for high compatibility with existing de-facto and industry standards for authentication and authorization (e.g., OAuth2).


Medium No

Table 19: Privacy-Preserving Identity Management - Maintainabilty and portability requirements


No social or political requirements have been identified at this point.


53



IDM-LR01

General Data Protection Regulation

Newer European Commission law/regulation about data privacy must be respected.

All High Yes

IDM-LR02 ePrivacy regulation

The ePrivacy Regulation (ePR) should be respected. The Regulation of the European Parliament and of the Council concerning the respect for private life and the protection of personal data in electronic communications and repealing Directive 2002/58/EC. In particular, Privacy is guaranteed for communications, while metadata have a high privacy component and must be anonymised or deleted if users did not give their consent unless the data is needed for billing.

All Medium No

IDM-LR03 eIDAS

CS4E stakeholders should comply with the security requirements defined in eIDAS regulation.

The Degree Verification System shall apply the Article 19: Security requirements applicable to trust service providers.

All Medium Yes

IDM-LR04

Entity assurance frameworks

For legal compliance and compatibility with other frameworks, entity assurance frameworks such as ISO/IEC 29115 should be followed.

All Medium No

Table 20: Privacy-Preserving Identity Management - Legal and regulatory requirements



54



Facts


Assumptions



Task 5.3 cover a transversal technology that can be related to several areas and research aspects in security and privacy and as such it has relation to different tasks in WP3:

• T3.1: as part pf the common framework definition it is needed to define the enablers/asset that will be investigated in each task as correspond to task 3.2 .

• T3.2: this is the most relevant task associated to task 5.3 as one of the common baseline technologies to be investigated are the one related to privacy preserving identity management solutions and it interrelation with blockchain.

• T3.4: in this task some of the research will focus on privacy-respecting big-data analytics, and more important privacy data mechanism for data sharing in the context of security intelligence.

• T3.6: usable security it is also concerned about mechanism to support users` privacy mechanism and as such enabling effective and usable security controls of user attributes.

• T3.7: this task will evaluate how to deploy privacy by design and privacy by default requirements for solutions compliant with regulation like GDPR and in that sense some of the results could be applicable in task 5.3

• T3.9: As part of the scouting aspects new solutions and advanced on privacy preserving and ABC mechanism can be fed to the task 5.3

In relation to WP4: • Task 5.3 will provide contributions and solutions to different aspects: • T4.3: it is the general roadmap design • T4.4: the e-commerce and regulatory vertical s concerned with GDPR and user in control of the

data provision will be related to the results task 5.3 can provide. • T4.6: it is the one directly related to task 5.3 results and evaluations • T4.9: in the medical data exchange there is s directly specification of need of privacy preserving

identity and attributed based solution to manage personal medical data.


WP3 ü ü ü ü ü ü

WP4 ü ü ü ü

Table 21: Privacy-Preserving Identity Management - Relationship with WP3 and WP4 tasks


55

6 Incident Reporting In this section, we describe the requirements for the CyberSec4Europe demonstration case titled Incident Reporting. We first provide a high-level overview of the demonstration case and its goals, followed by a description of the actors involved. We then provide more detailed functional requirements using use cases, followed by a description of non-functional requirements. Finally, we report relevant constraints and assumption to be considered while implementing this demonstration case.

6.1 Goals

Cyber Security is of paramount importance to protect the whole EU Digital Single Market and this is mirrored in the EU legislative evolution addressing Cyber Security. It is worth mentioning among the NIS Directive, the GDPR, the PSD2 along with other financial sector regulatory requirements that the Financial industry is one of the main critical sectors. The importance of Cyber Security in the financial sector should be addressed starting with research and development, keeping in mind the need to implement and leverage tools helpful to mitigate and tackle cyber threats, and improving cyber resilience.

The Digital Single Market landscape and his transformation into a highly interconnect environment have for example led regulators to identify critical sectors and the need to draw the attention to their systemic relevance. The analysis of all the actors involved in a scenario of a large cyber-attack demonstrate that not only cyber-risk does go beyond national borders, but also beyond sectorial boundaries, leading to potentially dramatic systemic risks. It is utmost appropriate to undertake a holistic view, pushing for a collaborative approach towards enhanced cyber resilience.

Bearing in mind the objective of increasing the readiness and awareness in Cyber Security, the current EU legal framework already incorporates the need to comply with Mandatory Incident Reporting to different Supervisory Authorities respecting the relevant impact assessment criteria and thresholds, timing, data set, communication means as defined by each authority both at EU and national level. All these different criteria and patterns cause fragmentation into the overall incident reporting process and are to be managed along the critical path of managing the incident itself.

These mandatory reporting requirements are particularly strong in the financial market. For instance, when a cyber incident impacts a multinational Financial Group, there is also the additional need for each entity impacted to eventually report to the National Competent Authority, and for the Parent Company Headquarter to gather all the information in a standardised way from each legal entity, in order to assess the overall impact at Group level.

The goal of this demonstration case is to develop a platform that enables financial institutions to fulfil the mandatory incident reporting requirements according to the different procedures/methods specified by applicable regulatory bodies (e.g. PSD2, ECB Cyber Incident Reporting Framework.) The created platform will address this common need for standardised and coordinated cyber-security communication cooperation, could also pave the way towards a public and private cooperation to reach the common goal of an enhanced cyber resilience across Europe and beyond the EU borders.

6.2 Stakeholders

This section is devoted to the identification of the main stakeholders that are the entities that will affected by, or who have an interest (economic, technical, political, legal, etc.) in the Incident Reporting demonstration case. We consider two main categories of stakeholders:


56

• Financial Institutions: FIs are the entities who are forced by different regulations/frameworks to report to different Supervisory Authorities on Cyber Incidents applying different procedures and templates. It is worthy to highlight that under different regulations a single FI, could represents several subjects, at the same time, each with specific requirements: o Target 2 Participants (ECB Target2): A distinction is made between critical participants

and non-critical participants depending on the market share in terms of value and/or the type of transactions processed.

o Significant Institutions (ECB SSM): The ECB classify a bank as Significant or Not Significant based upon the criteria of Size, Economic Importance, Cross-Border Activities and Direct Public Financial Assistance

o Payment Services Providers (PSD2): Banks and financial institutions operating as Payment Service Providers (PSPs).

o Operator Essential Service (NIS): Banks and financial institutions are considered as OES because they (a) provide a service which is essential for the maintenance of critical societal and/or economic activities; (b) the provision of that service depends on network and information systems; and (c) an incident would have significant disruptive effects on the provision of that service.

o Personal Data Processor/Controller (GDPR): Banks and financial institutions operate both as Processor, which processes personal data on behalf of the controller, and Controller which determines the purposes and means of the processing of personal data.

o Trust Service Providers (eIDAS): Banks and financial institutions can operate with their trust services either as a Qualified or as a Non-qualified trust service provider.

• EU/National Supervisory Authorities: they are the entities responsible for introducing the different reporting requirements and receiving the corresponding reports. Each regulation/framework imposes a concrete and corresponding authority: o NIS Directive: National NIS Authority o GDPR: National Data Protection Authority o eIDAS Regulation: National Certification Authority o PSD2: NCA/ECB/EBA o ECB/SSM: ECB/Joint Supervisory Team o Target2: National Central Bank/ TARGET2

6.3 Actors

In this section we provide a list of actors with brief descriptions. Actors are all the entities that interact with the Incident Reporting ecosystem. They can be of two types: (i) Primary actors, which are actors that have goals which this demonstration case needs to fulfil; and (ii) Secondary actors, which don’t have specific goals associated with this demonstration case, but are needed for the execution of its use cases. Special attention has been paid to the identification of the actors in the management process from an internal FI perspective.

Primary

The envisaged primary actors of this demonstrator are:

• Incident Management Team (IMT): This is the main actor of the Incident Reporting demonstration use case and correspond to operator/s of the internal organizational unit affected by the potentially dangerous event. They are in charge of carrying out a more detailed analysis in order to determine the necessity of the opening of an incident in the application or if it is an


57

issue that can be solved internally. In case of incident, the Asset Owner / Incident Management Team is responsible for the opening of the incident and for the collection of the main information related to the incident itself. There are two subtypes, the Bank IMT and the International Subsidiary IMT.

• Incident Classification Team (ICT): This actor is the internal organizational unit responsible for classifying all the incidents opened by the Incident Management Teams. This includes the identification of the type of incident, the perimeter extension, the estimation of the economic impact. The result of the classification determines if the incident can be managed by the unit until its closure or if an escalation process is needed because the incident is classified as an emergency or as a crisis.

• Incident Reporting Team (IRT): This actor has to continuously monitor the evolution of the incident and needs to carry out the intermediate reporting processes to competent authorities until the closure of the incident, according to relevant regulation timeline.

• Controller: This actor is responsible for performing the managerial judgement about the incident classification done by the Incident Reporting demonstrator and give the authorization to proceed with the reporting. The Controller is also the one who authorizes the actual reporting and oversees the whole incident reporting process.

• Administrator: This actor oversees the customization of the Incident Reporting Demonstrator to adapt it to the particular needs of a FI or a given market. The Administrator is the demonstrator supervisor from the IT perspective.

Secondary

The envisaged secondary actors are the following ones: • EU/National Supervisory Authorities: This actor is in charge of receiving and processing the

incident reports submitted by the demonstrator. • EU/National Competent Authorities: This actor is in charge of receiving and processing the

incident reports submitted by the demonstrator.

Use Cases Numbers

Actors IR-UC1 IR-UC2 IR-UC3

Incident Management Team X

Incident Classification Team X

Incident Reporting Team X Controller X X

Administrator X X X EU/National Supervisory Auth. X

Table 22: Incident Reporting - Mapping of actors to use cases




58


The main functionalities of this Incident Reporting demonstration case shall enable the financial institutions to leverage such smart engine during the mandatory incident reporting including the coverage of the incident management process Figure 12 and Figure 13 provide different views about the functional workflows expected in this Incident Reporting Demonstration case.

Figure 12: Incident Reporting – Event Management Workflow

BankIncident

Management Team (IMT)

1…n

EVENT REGISTER DB

DATAFEED INTO

DB

EVENT DETECTION

InternationalSubsidiary

IMT1…n

2

MANDATORY INCIDENT REPORTING

Data Collection & Enrichment

Event Classification

Event Taxonomy

Data Conversion for Reporting & Info-sharing

Managerial Judgement

Event Manager Workflow

NETWORK

LAYER

DATA IN INPUT

DATA IN INPUT

DATA IN INPUT

Internal & International

Subsidiary1…n

INFRAGROUP INFO-SHARINGI

NPUT

DATASET

EU Supervisory Authority

1…n

SUPERVISORY AUTHORITIES

ADVOCACY

National Competent

Authority 1…n


59

Figure 13: Incident Reporting - Functional Workflow

The Incident Reporting workflow begins with the data collection followed by the data enrichment and event classification. These three steps aiming to define and quantify the incident have a direct correspondence with UC1 covered in section 6.4.3. The minimum set of information to be collected at first when a Security Incident is detected is identified to assess the need for Incident Reporting depending on different regulatory frameworks considered. The first collection of data could be categorized in three different types of information:

1. General Information; 2. Incident Taxonomy: identifying the causes that generated the incident; 3. Specific information to assess the need for Mandatory Incident Reporting.

Figure 14 depicts the methodology that should be used at this stage for the classification of critical events.

UC

DETECTION & TRIAGE

DATA COLLECTION

DATA ENRICHMENT

EVENT CLASSIFICATION

IncidentManagement

Team 1

Incidentmanagement

team 2

Incidentmanagement

team 3

Incidentmanagement

team 4

Incidentmanagement

team N

Smart GUI

Smart GUI

Information Security Office

INCIDENT IMPACT

SEVERITY (Suggested)

NEED FOR EXTERNAL

REPORTING (Suggested)

THROUGH

MAN

AGER

IAL J

UDG

EMEN

T –Co

nfirm

clas

sific

atio

n?

DATA CONVERSION

TO

FROM

Smart GUI

IncidentManagement

Teams

&

Appropriate

template

Appropriate

template

Appropriate

templateAppropriate format and template

MANDATORY INCIDENT

REPORTING PEC / PGP / …

Continuous Data enrichment for subsequent notification and incident severity monitoring

EVENT REGISTER DB – Incident Management Tracking along the event lifecycle

UC1 UC2 UC3


60

Figure 14: Incident Reporting - Critical events classification methodology

Once the event has been classified, the next step in the workflow is the managerial judgement done by the controller. This step is represented by UC2 covered in section 6.4.4. When the controller authorizes the reporting, the Incident Reporting Demonstrator will prepare and deliver the incident reports considering the formats and process specified for the targeted Supervisory Authorities. This step is represented by UC3 covered in section 6.4.5. As a consequence of the workflows described above, we envisage that the Incident Reporting demonstration use case should include the following high-level functional requirements:


IR-F01 4-eyes principle

Mandatory Incident Reporting shouldn’t be automatic, it should still be manual to prevent accidental reporting – 4eye principle

IR-UC1, IR-UC2, IR-UC3

High Yes

IR-F02 Data Collection

It must collect all the information collecting all the information required related to the cyber incident through different questionnaires.

IR-UC1 High Yes

IR-F03 Templates configuration

It will allow to upload/download/configure templates that will be sent to the incident report team with the fields fulfilled. The user will indicate the regulatory framework and all the variables to insert in the template according to the templates specified in the regulation.

IR-UC1 High Yes

IR-F04 Event Classification

It must provide support during the Security Event Classification. The IR-UC1 High Yes

EVENT TAXONOMY

Identification of the type of critical event (taxonomy), defined according to the cause that generates the event.

IMPACT PERIMETER

Identification of the impact perimeter in order to contextualise the event and

support the Impact Assessment (e.g. geographic extension, commercial

channels, processes, services, assets, IT components affected)

IMPACT ASSESSMENT & EVENT SEVERITY

Quantification of the potential or real impact, by mean of specific drivers,

thresholds and application of rules and policies internally adopted by Intesa Sanpaolo to determine the overall

severity of the critical event.

INCIDENT REPORTINGThe methodology, during the impact assessment, enables to identify the

need for Incident Reporting under the different regulations and FMIs

procedures applicable, and to collect all the information required for the

notification.

1 2

4 3


61


classification methodology to be included will take into account the criteria and thresholds defined by the European regulators along with the set of information necessary to report the incident, using the appropriate procedures and templates defined by the Competent Authority (National or European).

IR-F05 Event Severity Suggestion

It must suggest the Severity of a Security Event, in order to activate the most appropriate action plan for managing and responding to the Incident or Threat.

IR-UC1 High Yes

IR-F06 Mandatory IR Identification

It must identify the need for Mandatory Incident Reporting, considering the reporting requirements and related assessment methodologies w.r.t. each Competent Authorities.

IR-UC1 High Yes

IR-F07 Processes Suggestion

It must suggest to the FI operator about the Mandatory Incident Reporting processes to be followed.

IR-UC1 High Yes

IR-F08 Managerial Judgement

It must request the authorization of the FI operator (Controller) to proceed with the reporting.

IR-UC2 High Yes

IR-F09 Report Template

It must produce the appropriate template and communication, in the appropriate format to be sent to the Competent Authority.

IR-UC3 High Yes

IR-F10 Communications

It must provide communications from the Legal Entity of a multinational Group, or the specific office detecting the incident, to the headquarter Information Security Office.

IR-UC3 High Yes


62


IR-F11 Notify regulator

Incident is forwarded to the applicable competent authority. The demonstrator should be able to determine or advice upon which reporting duties apply.

IR-UC3 High Yes

IR-F12 Incident Tracking

It must support the tracking for the whole Security Event lifecycle within a Financial Institution Security Event DataBase.


High Yes

IR-F13 Workflow Enforcement

It must enforce a workflow to be used for reporting purposes.


High Yes

IR-F14 Workflows customization

It must improve the Incident Reporting Workflows, customized directly by system administrator, for enhancing the efficiency and effectiveness of the Reporting processes even in light of the integration of new coming regulation.


High Yes

IR-F15 Export

It will allow exports from the graphic user interface of thresholds, criteria or incidents to different formats (pdf, xls, txt, etc.).


Low Yes

IR-F16 Authority Administration

The demonstrator should allow the administration per template of the applicable internal and external competent authorities.

IR-UC3 High Yes

IR-F17 Statistics of the system

The application should contain a report module that allows access to the information on the number of incidents that occurred in a given time.


Low No

IR-F18 Configuration of variables

The application should have a section where the variables that are going to be present in the creation of the incidents can be configured. In this section the possible values of each field will be catalogued and will allow the addition of new values to the catalogue.


Low No


63


IR-F19 Logs

The application must have log files that will be saved in their systems. The logs must contain all traceability of the application itself (errors, status, etc.), as well as the actions that each user has made when using the application.


High Yes

IR-F20 Help

The application will have a help button that will show the specific help for each screen you are in order to help the user to understand and perform the actions available in it.


Low No

IR-F21 Help function Possible introduction of a regulatory wiki as part of a help function.


Medium No

IR-F22 Knowledge Base

The application should have a section where the users could find the direct link of main Mandatory Incident Reporting Regulations/Guidelines/Directives.


Low No

IR-F23

Users Management Administrator

Reviews

The application should allow to administrator the management of the entire user account lifecycle in terms of creating, modifying, deleting, assigning right permissions, searching and so on in order to identify the right reviews (User and Account Access, Role Definition, Task in charge etc.)


High Yes

IR-F24 Rules & Alert

The application should allow to create and process several rules able to identify and notify specific conditions that it is needed to monitor for the improvement of the user activities on the application


Medium No

IR-F25 Third-party integration

The application should have a REST API to allow the integration with third-party technologies


Medium Yes

Table 23: Incident Reporting - Functional requirements


64

Use Cases List

Based on the functional workflow described in previous section, we have identified the following high-level use cases:

• IR-UC1 – Data Collection, Enrichment and Classification • IR-UC2 – Managerial Judgement • IR-UC3 – Data conversion and reporting preparation

IR-UC1 – Data Collection, Enrichment and Classification

UC1 starts with the data collection phase where the ITM will input all the information related to the incident through a smart GUI based on questionnaires. All the information required in the “Data Collection” phase should be gathered by the Incident Management Team that can either receive a notification from an impacted or involved business office/function or could detect directly an incident occurrence. If there is a clear evidence that the incident is entailing a possible mandatory incident reporting requirement (e.g. personal data breaches, incident impacting T2, Payment service, … ), or if the impacts of the occurred incident seem to be significant, the Incident Management Team should send to the Incident Classification Team all the information gathered in order to assess the incident severity and to report the incident to the competent authority, as appropriate.

Once the incident has been registered, the next step is enrichment of information about the incident to have a better knowledge about the scope and potential impact. This enrichment will be done also by using the GUI and taking into consideration the information received by the Supervisory Authorities (if any).

After that, the Incident Classification Team validates the information provided and continue with the categorization, classification and identification of the cause that generated the incident with the final objective of reporting to the FI the impact and severity. As a result of this process, it will be decided if the incident must be reported or not and to whom. Each regulatory requirement is linked to specific needs also w.r.t. customers protection, thus upon an incident the impact assessment must be undertaken against each and every EU and national regulations to verify the applicability of IR regulatory requirements. The first move towards the harmonisation of IR is to create the most exhaustive IR data set, considering all the possible requirements, and define a common taxonomy. The Taxonomy is applicable to both Cyber and Operational critical events. The impact assessment process is on the critical path of Incident Management and requires a clear coordinated procedure; it is necessary to smooth the process to create and efficient and effective Incident Reporting introducing new tools such as a Common Application.

Use Case Diagram


65

Figure 15: Incident Reporting - UC1 Data Collection, Enrichment, and Classification

IR-UC2 - Managerial Judgement

UC2 covers the authorization process in which the Controller will perform the managerial judgement about the incident classification. The Controller, based on the experience gained, the specificities of the incident and further considerations made, may still assign the overall level of severity through a Managerial Judgement, confirming, increasing or lowering the Incident Severity level, and confirming or not the need for Incident Reporting suggested by the application. Based on the assigned Severity judgement, the most appropriate action plan to be implemented to handle and respond to the incident will be determined.

Use Case Diagram


66

Figure 16: Incident Reporting - UC2 Managerial Judgement

IR-UC3 - Data conversion and reporting preparation.

On the basis of the information collected and the Incident Reporting evaluation output performed in UC2, the Incident Reporting demonstrator should include all the needed information into the appropriate template/communication to be sent to the Competent Authority. First the data is converted to the formats and templates requested by the Competent Authorities affected by the incident and after that, when the Controller authorizes it, the actual reporting is performed.

Use Case Diagram

Figure 17: Incident Reporting - UC3 Data Conversion and Reporting



67


IR-SP01 Authentication and Profiling

Strong authentication mechanisms must be included and check of rights granted with the credentials to access to the platform.


High Yes

IR-SP02 Confidentiality Granting access to information on a need to know base and matching authorisation profiles.


High Yes

IR-SP03 Availability Warranty that information needed is made available.


High Yes

IR-SP04 User Administration

The demonstrator must have a section of roles and users that will allow configuration with the sufficient granularity to be able to ensure limiting or granting permissions to each user based on their functions.


High Yes

IR-SP05 Accountability

Logging, timestamping and tracking mechanisms must be incorporated at all phases of the Incident Reporting process.


High Yes

Table 24: Incident Reporting - Security and Privacy requirements




IR-LF01 GUI

The Incident Reporting demonstration case must include a GUI that will allow the interaction with the operator.


High Yes

IR-LF02 Multi-Language

The GUI must support different languages and provide an easy way to incorporate new ones.


Medium No

Table 25: Incident Reporting - Look and feel requirements


68



IR-U01 User-friendly

The GUI must be user-friendly, offering a better user experience, improving the response times and facilitating the navigation between several functionalities.


High Yes

IR-U02 Questionnaires

The GUI must request to the operator all the required information about the incident, including the impact assessment, through different questionnaires.

IR-UC1 High Yes

IR-U03 Self-adaptative questionnaires

The questionnaires presented to the operator must be self-adaptive, customized depending on the information already provided about the incident.

IR-UC1 High Yes

Table 26: Incident Reporting - Usability requirements




IR-OP01

“In house” Deployment

The Incident Report demonstrator must be an “in house” standalone application deployed on the FI premises.


High Yes

IR-OP02 Multi-Currency

The user will be able to select the currency applicable for creating the incidents.

IR-UC1 Medium No

IR-OP03 Multi-Time zone

The Incident Report demonstration case must support multiple time zones.


Medium No

IR-OP04

Multiple Business Calendars

The demonstrator should be able to consider different business calendars.


Low No

Table 27: Incident Reporting - Operational requirements


69



IR-MP01

Customizable Regulations

It is possible to envisage a future extension of the Incident Reporting Demonstration case beyond the financial sector. Consequently, the demonstrator should include mechanisms for incorporating additional regulations that may have effect in different sectors.


Medium Yes

IR-MP02 Flexibility

Flexibility and modularity shall ensure that the application is able to evolve and cope with regulatory evolution over the time and geographies.


Medium Yes

Table 28: Incident Reporting - Maintainability and portability requirements


No social or political requirements have been identified at this point.



IR-LR01 NIS Directive

NIS Directive, to be adopted by each Member State at latest by May 2018, introduces additional incident reporting requirements for Operators of Essential Services the latter shall be identified by each Member State by November 2018. Within the directive are only defined the general criteria to be taken into account and the minimum set of information to be provided. Specific procedures should be defined at national level.


High Yes

IR-LR02 GDPR

EU privacy regulation entered into force in May 2018, introducing the obligation to report Personal Data Breach resulting in a Risk to Right and Freedom of individuals, to the National Competent Authority. The Regulation and the related Guidelines do not introduce specific


High Yes


70


thresholds to assess the need for reporting personal data breach, but provide some general criteria in order to assess the Risk to the Right and Freedom and the minimum set of information to be reported. Each Member State should define the operational procedure for reporting to the National Competent Authority, along with the templates for reporting.

IR-LR03 eIDAS Regulation

The regulation has introduced since July 2016 the obligations to report security incident for Trust Service Providers. The assessment criteria and the set of information to be provided are defined into the ENISA Guidance on Incident reporting for eIDAS. The National Competent Authority in each MS has adopted the requirement defined in the regulation, eventually defining a template for communication.


High Yes

IR-LR04

ECB Cyber Incident

Reporting Framework

The ECB framework entered into force in July 2017 and foresees specific thresholds to assess the need for reporting a cyber incident to the ECB. Templates and operational procedure for reporting are defined.


High Yes

IR-LR05 Payment Service Directive 2

The Directive entered into force in January 2018, and foresees the reporting of Security incident (cyber and operational) for Payment Service Providers, under certain specific conditions, to the National Competent Authority. Due to MS delays in implementing the directive, the EC has extended the period for adoption of the Incident reporting requirement till the end of the first quarter 2018. Templates and procedures have been defined by EBA into the Guidelines on Incident reporting under PSD2, and should be adopted by the National Competent Authority.


High Yes


71


IR-LR06 Operational Guide for

Target2 user

inancial Institutions participating in Target2 system have to comply with the operational procedures as defined by the ECB. Critical participants have to comply with the requirement to report Incident causing an interruption of the Target2 system. Templates and procedures are defined into the Operational Guide, and adopted by the Responsible National Central Bank.


High Yes

Table 29: Incident Reporting - Legal and Regulatory requirements




Facts


Assumptions




WP3 ü ü ü ü ü

WP4 ü ü ü ü

Table 30: Incident Reporting - Relationship with WP3 and WP4 tasks


72

7 Maritime Transport In this section, we describe the requirements for the CyberSec4Europe demonstration case titled ‘Maritime Transport’. We first provide a high-level overview of the demonstration case and its goals, followed by a description of the actors involved. We then provide more detailed functional requirements using use cases, followed by a description of non-functional requirements. Finally, we report relevant constraints and assumption to be considered while implementing this demonstration case.

7.1 Goals

The Maritime Transport demonstrator is a representative example of a collaborative and complex process that involves domestic and international transportation, communications and information technology, warehouse management, order and inventory control, materials handling and import/export facilitation, among others. The maritime transport services include various interactions and tasks among the various entities engaged (stakeholders and actors) having different goals and requirements. In particular it includes a number of interactions and tasks that involve several physical (docking of the ship, stevedoring, loading, unloading, storage, transportation, inspection, etc) and cyber (pre-arrival notifications, customs clearance documentation management, ISPS declaration, etc) operations, interconnections and assets. Obviously, the maritime ecosystem is characterized by significant (inter) dependencies among the involved actors thus we need to treat internal, external and diffused cyberthreats for the entire maritime ecosystem. In this context, the aim of this demonstration case is to contribute to the effective protection of the maritime transport that arises from the interconnections and interdependencies of a set of maritime entities, such as port authorities, ministries, maritime companies, ship industry, customs agencies, maritime/ insurance companies other transport CIIs (e.g. airports) and other CIIs (e.g. transport networks, energy networks, telco networks). Therefore, there is an emerging need for new innovative approach that facilitates the identification, analysis, assessment and mitigation of the organization-wise and interdependent cyber threats, vulnerabilities and risks. Within the scope of the maritime transport demo case is to identify and to implement targeted security services that will ensure high levels of security for various critical maritime transport services, covering: the threat and risk management; the trust and key management services; the security of the communications in respect to the trust and key management services; and the software hardening of critical systems.

Identification of Critical Maritime Transport Services

The transport sector has been identified as a critical sector for the European Union, since the proper operation of transport services and infrastructures is crucial for the wellbeing of people and citizens, the economy and the society in general. Maritime transport is an important subsector; although the criticality level of Maritime Transport services may differ in the member states, in general maritime services may provide vital operations to people transport (e.g. for commuting, leisure or healthcare related reasons) and goods transport, including fuel, food, consumer goods and in general, the support of the supply chain. In order to identify and analyze the relevant security challenges, the Maritime Transport demonstrator will base its pilot operations by exploring the security challenges involved in a number of critical maritime transport services (see Table 31):


73

People Transfer

Passengers Transport

Service

It includes all the relevant operations and formalities required for the passengers’ maritime transportation.

Cruise Service It provides sea crossings for tourist travel (i.e. tourist travel as utility).

Goods Transfer

Tanker Transport

Service

It includes the transport of coal tar, carbon black feedstock, creosote oil, fuel oil and other petroleum/black products

LNG (Liquefied Natural Gas)

Transport Service

A special instance of fuel transport service. It involves the transport of liquefied natural gas from the liquefaction plant (production/extraction) to the supply station. Once natural gas has been liquefied it can easily be shipped by tanker to receiving LNG terminals. On arrival at the terminal, the LNG is “regasified” (turned back into a gaseous state), before being injected into the natural gas transmission system (by trucks or pipelines).

Vehicles’ Transport

Service

A massively complex transport service with numerous players, including shippers, transport operators that involve the shipment and receipt of various types of vehicles and equipment such as trucks, vans, truck trailers and threshing machines.

Dry Bulk Cargo Transport

Service

It includes the transport of large quantities of goods without packaging or packing where the means of transport itself acts as a container. In particular, dry bulk commodity cargo is is anything (usually raw material) that is shipped in large, unpackaged parcels like coal, iron ore, gravel and grain.

General Cargo & Container Transport

Service

The goods are transported in containers or packages (TEU containers, sacks, boxes, barrels, bales, crates, bundles, coils and pallets, etc.).

Table 31: Maritime Transport - A non-exhaustive list of critical maritime transport services

Although those services do not represent an exhaustive list, they can be considered as representative examples of critical services to security and economics, taking into consideration suggestions from the maritime stakeholders and knowledge gained from past European projects and initiatives of the participants involved in this case, dealing with maritime operations (e.g. SUPPORT, CYSM, S-PORT, MEDUSA, MITIGATE and SAURON).

7.2 Stakeholders

The Maritime Transport ecosystem is complex environment with numerous players, including shippers and transport operators. Port authorities (which are public or private-public organizations) and port operators (private organizations) along with terminal operators are the main identified stakeholders. The key entities stakeholders involved in this environment are the following: • Cargo owners: Cargo owners are any entity upstream or downstream the maritime transport services

who owns the cargo to be transported, both to be exported or imported.


74

• Government-related stakeholders: the following government related stakeholders are identified: ○ Shareholders: Many port authorities have a total or partial state ownership and/or having

private/public shareholders in their managing board. ○ Customs: It is an authority or agency in a country responsible for collecting tariffs and for

controlling the flow of goods. ○ Health and biosecurity inspection: They represent agencies or authorities appointed by a

country government (Health, Food and Environmental Depts or Ministries) usually working closely to customs agencies for controlling items that could contain harmful substances capable of causing and propagating diseases or pathologies or even affect the local environment and checking for the compliance with national laws and environmental issues.

○ PSC Inspections: Appointed by a national authority, usually under the control of the Harbour Master, they are in charge of inspecting vessels in order to ensure the accomplishment of national/international regulation in vessel traffic and safety.

○ State security and protection forces (police, civil protection, army, etc.): They are committed to the detection and prevention of illegal traffic, illicit acts and other crimes and to the prevention and response to accidents and crisis.

• Shipping lines: A shipping line is a business that transports cargo aboard ships. The business may either be ship owners or not own ships and act as charterers.

• Marine services providers: ○ Linesmen (mooring services): They are professionals dedicated to ships mooring from the

shore side. ○ Pilotage: It is a port service that directs the movement of a ship through port waters by visual

or electronic observations of recognizable landmarks to provide safe vessel mooring or unmooring.

○ Towage: It is another port service consisting of manoeuvring vessels by pushing or towing them in a crowded or complex harbour or a narrow canal, or those that cannot move by themselves, such as barges, disabled ships, log rafts, or oil platforms.

○ Bunkering: It refers to the storage and supply of fuel oil to maritime vessels. ○ Maintenance Services:It includes a wide set of services for ships such as repairs, supplies

(water, electricity, provisioning, etc.). ○ Slipways: It is a service for moving ships/boats to/from the water by the use of ramps. in

shipyards when a ship is under construction or under repair.

• Stevedores: They represent firms or individuals engaged in the loading or unloading of a vessel handling the port equipment (ship-to-shore cranes, yard tractors, forklifts, etc.), in addition to various other dockside duties and responsibilities.

• Logistics providers: ○ Cargo agents: A cargo agent has three primary responsibilities: provide quotations to potential

clients, complete shipping and customs documentation, and arrange for parcel transportation. ○ Local Agent: He has the primary responsibility to complete shipping and logistics

documentation, clearance procedures and arrange for vehicle/cargo transportation. ○ Freight forwarder: A freight forwarder, also known as a non-vessel operating common carrier

(NVOCC), is a person or company that organizes shipments for individuals or corporations to provide goods from the manufacturer or producer to a market, customer or final point of distribution.

○ Haulier: An entity responsible for the main transport of goods. ○ Charterer: Chartering is an activity within the shipping industry. A charterer may own cargo

and employ a shipbroker to find a ship to deliver the cargo for a certain price, called freight rate or may be a party without a cargo who takes a vessel on charter for a specified period from the owner and then trades the ship to carry cargoes at a profit above the hire rate.


75

○ Transport manager: A transport manager is a company or a person responsible for the execution, direction, and coordination of all transportation matters within a company or organization.

○ Ship-owners: A ship-owner is the owner of a merchant vessel (commercial ship). ○ 3PL/4PL Contractors: 3PL and 4PL stand for “third party” and “fourth party” logistics. A

3PL is a firm that provides service to its customers of outsourced (or "third party") logistics services for part, or all of their supply chain management functions. A fourth party logistics provider has no own transport assets or warehouse capacity. It has an evocative and integration function within a supply chain, to increase its efficiency.

• Trade facilitators: They represent associations of carriers, cargo managers, shipping companies, traders, etc.; aimed at providing to the logistics community a wide range of services such as consultancy, documentary management, training, information, fee reductions, etc.

• Transaction facilitators: ○ Shipping agent / Cargo broker: They are the designated persons or agencies responsible for

handling shipments and cargo at ports and harbors worldwide on behalf of shipping companies. In some parts of the world, these agents are referred to as port agents or cargo brokers.

○ Consignees: They are parties (usually buyers) named by the consignor (usually a seller) in transportation documents as the parties to whose order of consignment will be delivered at the port of destination.

○ Shipbrokers: Ship broking is a financial service, which forms part of the global shipping industry. Shipbrokers are specialists intermediaries/negotiators (i.e. brokers) between ship owners and charterers who use ships to transport cargo, or between buyers and sellers of ships.

○ Customs brokers: It is a profession that involves the "clearing" of goods through customs barriers for importers and exporters (usually businesses).

○ IT Providers: They represent companies or agencies contracted by or belonging to a Port Management Company or Port Authority entrusted to provide IT solutions for the management of port operations, documents, services, etc.

○ Financial Holdings (Banks): Port Authorities require to be in close relation with banks and financing entities to charge fees for their services, manage economical transactions among different parties and for their staff or make huge investments for technology, physical infrastructures, etc.

○ Insurance companies: The provision of critical services in critical infrastructures such as ports is not exempt of risks of any type. Therefore, Port Authorities count on appropriate insurances, to face accidents, thefts and even attacks or cyber-attacks.

○ Marine Underwriter: A Marine Underwriter is a financial actor, usually contracted by the Insurance Company, who provides insurance coverage both for the vessel and the freight that are transported evaluating the risks of insuring and setting premium pricing for the Insurance Company.

○ Authorized Economic Operator (AEO): An entity that complies with supply chain security standards (e.g. from World Customs Organization WCO)

• Infrastructure providers: ○ Services contractors: Ports, depending on their nature, count on many types of services

contractors such as mooring, pilotage towage, management of ship-generated waste/garbage. ○ Maintenance: Ports are structures with many facilities and installations which require

appropriate maintenance including electrical lines, data lines, IT and infrastructure, etc. ○ Installation: It includes the provision of any type of installation within the port area, such as

gas, electricity, water, safety and security, telecommunication, etc. ○ Land-side infrastructure contractors: Providers of cranes, tractors, vehicles, in container and

bulk terminals, etc.


76

○ Marine infrastructure contractors: Providers of auxiliary boats, tugs, bunkering platforms, etc.

○ Security contractors: Private security companies providing staff, vehicles, scanners, etc. for the port area security.

7.3 Actors

In this section we provide a list of actors that are actively involved in the use cases described in the sections that follow.

Primary

● Port Facility Security Officer (PFSO): A person responsible for the security of the port facility. ● Ship Security Officers (SSO): A person responsible for the security of the ship. ● Port Authority: A port is a maritime commercial facility where vessels can dock to load and

discharge passengers and cargo. ● Vessels: A vessel, ship or boat that can transport passengers and cargo across the water. Here, all

vessels are assumed to be equipped with digital communication systems, such as WiFi, 3G/4G/5G, VDES, SATCOM, etc.

● Vessel Traffic Service (VTS): shore-side systems (typically the coastal administration) which range from the provision of simple information messages to ships, such as position of other traffic or meterological hazard warnings, to extensive management of traffic within a port or waterway4

● PKI service provider: A Public Key Infrastructure (PKI) service provider is an entity that offers services related to the set up, operation and and management of public key cryptography.

● Supervisory Control and Data Acquisition (SCADA)/EMS Operators: Operators of SCADA/EMS systems related with the port and vessel operations.

● ICT Administrators: People responsible for the administration of ICT systems involved in the maritime sector.

● Cybersecurity experts: These may involve internal Port Authority cybersecurity experts, or external experts collaborating with a Port Authority.

Secondary

We also provide a list of secondary actors, involving both people and maritime specific systems, that according to the specific environment, might be related to the use cases.

● Advanced Object Detection System (AOS) ● Automatic Identification System (AIS) ● Business Information and Tracking (BIT) ● Car Carriers ● Common Communication Network (CCN) ● Container Status System (CSS) ● Cranes (Gantry, Cargo etc.) ● Dynamic positioning system (DP) ● Electronic Chart Display and Information Systems (ECDIS) ● Excise Movement and Control System (EMCS) ● Freight Forwarder System ● Gate Operating System (GOS) ● IT Consultants and experts

4 http://www.imo.org/en/OurWork/Safety/Navigation/Pages/VesselTrafficServices.aspx


77

● Lift-on-Lift-off vessels (LoLo) ● Onboard Safety Systems ● Port Community System (PCS) ● Port Management Information System (PMIS) ● Programmable Logic Controllers (PLC) ● Radio Communication System ● Radio Frequency Identification (RFID) tags ● Remote Terminal Units (RTUs) ● Roll–on/Roll–off vessels (RoRo) ● Sensors (e.g. Navigational Sensors) ● Ship Information System (SIS) ● Telecommunication operator ● Terminal Operating System (TOS) ● Vessel Traffic Management System (VTMS) ● Visitor Information Service ● Warehouse management system

Use Cases Numbers

For the above identified stakeholders and actors, the following table shows the use cases’ numbers that each actor is associated with.

Use Cases Stakeholders Involved Actors Involved

MT-UC1

Port Authorities, Ship-owner, Cruise Operators, Public Administrations, Customs Authorities, Importer, Industry, Insurance Company

Port Facility Security Officer (PFSO), Ship Security Officers (SSO), ICT administrators, SCADA/EMS Operators, Cyber Security experts

MT-UC2 Port Authorities, Ship-owner System Administrator, Security Analyst

MT-UC3

Port Authorities, Ship-owner, Cruise Operators, Public Administrations (ministries, Customs Authorities)

VTS, Vessel, Port

MT-UC4

The International Maritime Organization (IMO), Flag States, Port Authorities, Ship-owners, Cruise Operators, Public Administrations (ministries, Customs Authorities)

Vessel Traffic Services (VTS), Vessels, Ports, Public Key Infrastructure (PKI) service providers

Table 32: Maritime Transport - Mapping of actors to use cases



To secure this complex, dynamic and continuously evolving ecosystem, there is a need to manage security threats and risks, to harden the security of the systems involved, and to secure the communications between the various maritime systems through the design and development of a targeted trust infrastructure that may support the underlying services of authentication, authorization, data confidentiality and integrity and service availability. Figure 18 presents an overview of the security services that will be examined in this demonstrator.


78

Figure 18: Maritime Transport - Maritime transport environment and the security services demonstrated in T5.5

Future maritime communication will cover a diverse set of interactions, including information exchanges between ships, ships and organisations (such as ports, Vessel Traffic Services, and Shipping Operation centre), and ships and services (such as e-Navigation and Medical Aid Providers). The maritime transport demo will focus on identifying cybersecurity threats for the maritime environment, both at the ship side and the port side and will demonstrate the design and development of novel and targeted security services for identification, assessment and mitigation of such threats. In particular, the scope of this demo includes: • Design threat modeling and risk assessment services for the identification and analysis of cyber and

combined cyber-physical threats, both at the ship and the port side. • Analyze security vulnerabilities of ship navigation and communication systems for ship-to-ship and

ship-to-port communication to harden the security of their software components and to increase their resilience against related cyberattacks.

• Design and validate PKI for maritime communication to provide resilience against novel targeted threats.

• Use TM & RA tools to assess PKI tradeoffs (design choices, costs, security level, etc).

Use Cases List

The following use case have been identified and are analyzed below: ● MT-UC1 - Threat modeling and risk analysis for maritime transport services: this UC

describes the functionalities related with the threat modeling and risk assessment services. ● MT-UC2 - Maritime system software hardening: it describes the process of software hardening

for critical maritime systems. ● MT-UC3 - Secure maritime communications : it describes various maritime communications that

require security services such as confidentiality, integrity and authentication. ● MT-UC4 - Trust infrastructure for secure maritime communication: it describe the

functionalities related with the design of a trust infrastructure, required to support system and communication security for the maritime sector.


79

MT-UC1 – Threat Modeling and Risk Analysis for Maritime Transport Services

The interconnectivity of modern vessels and port infrastructures creates new opportunities for the maritime transport sector, but at the same time substantially increases their attack surface. Examples of relevant cyber security threats involve, remote hacking against port and vessel ICT systems, interception and manipulation of ship-to-ship and port-to-ship communication systems (e.g. AIS, ECDIS) and nearby attacks against IoT technologies, (e.g. ship navigational sensors or RFID tags used in port supply chain management). At the sane time, the list of the relevant threat agents is very dynamic and it covers a wide range of adversaries with different capabilities, access level and motivation, such as state adversaries, cyber terrorists or economic adversaries. This use case will focus on the design and development of a targeted and dynamic threat modeling and risk assessment service for the critical maritime transport services. The service will be capable of identifying and assessing novel threats such as cascading threats, or threats that may be triggered by the underlying connectivity and dependencies of the critical maritime systems. A threat modeling and risk assessment service should enable the involved actors to collaboratively and securely exchange threat and risk related information, to define the scope of the assessment, to model their continuously evolving threat landscape, to assess their relevant cybersecurity threat, vulnerability, impact and risk, and to take informed decisions related with risk mitigation.

Use Case Diagram

Figure 19: Maritime Transport - Threat modeling and risk analysis for maritime transport services

MT-UC2 - Maritime System Software Hardening

Modern vessels include various software controlled and connected systems that are critical for proper vessel operation. The vessel crew accesses internet at ports or via satellite internet as a connected part, bringing risk to vessel software systems. Software implementing these tasks can be written in safe or unsafe systems. When programs are developed in safe systems, they still execute using unsafe systems. These unsafe


80

systems contain machine code that runs with no runtime support and therefore it is vulnerable to memory errors and corruption. With software hardening, exploitation by corrupting memory becomes harder. Even if code contains bugs, then hardening can make these bugs non-exploitable. Hardening can be applied to source code (when software can be recompiled) or directly to binaries. Protecting native code is critical, since, for example, any cryptographic operation can be bypassed if the program realizing the cryptographic algorithms can be compromised. Moreover, hardening can be applied to the underlying OS, running in vessels or the port infrastructure, by sys admins, and to any application that includes unsafe components. In the latter case, hardening is applied by security analysts either by LLVM instrumentation, when source is available, or binary instrumentation.

Use Case Diagram

Figure 20: Maritime Transport - Maritime system software hardening

MT-UC3 – Trusted and Secure Maritime Communications

Various type of information is exchanged in this use case. Namely: ● VDES frequencies (to be used for VTS information services) ● AIS information: Maritime Mobile Service Identity (MMSI), time, ship position, speed, rate of turn,

length, course etc. ● Vessel voyage information: Route plans and mandatory ship reports ● Maritime Single Window reporting information: Ship certificates, single window reports

(notifications, declarations, certifications, requests and service orders), log books, passengers’ lists and crew lists.

● Port to vessel information: Weather reports, passenger or cargo manifestos, etc


81

The information is exchanged/transmitted between different maritime stakeholders and actors using all kinds of systems. Authenticity, integrity, availability, in some cases confidentiality, non-repudiation, resilience and privacy of the communication must be assured.

● VTS to Vessels broadcasting: o General VTS to vessels communication. In general, the communications should be visible

to all vessels nearby. o Transmission of VDES bulletin board. A bulletin board will announce available channels

and modulations through a regularly transmitted broadcast message from the VDES base stations and satellites.

o Transmission of DGPS corrections. o Transmission of reports and manifestos. VTS transmits weather reports and passenger or

cargo manifestos to the vessels. ● Vessel to Vessel communication:

o General vessel to vessel communication. In general, the communications should be visible to all vessels nearby.

o AIS broadcasting: Every vessel broadcasts to all nearby vessels information from the Automatic Identification System (AIS), which is used (among other things) to avoid collisions at sea.

● Vessel to VTS: o Transmission of vessel voyage information: Vessels transmit their route plans and

mandatory SRS (Ship Reporting System) reports to VTS ● Vessel to Port:

o Maritime Single Window reporting: The Maritime Single Window environment is an initiative to digitalise and harmonise ship reporting to EU countries. Digital reports are sent from the vessel to the Port through a National Single Window (NSW).

Use Case Diagram

Figure 21: Maritime Transport - Trusted and secure maritime communications

MT- UC4 – Trust Infrastructure for Secure Maritime Communication

The information exchanged in this use case will belong to one or more of the following four categories:


82

● Message payloads ● Certificate Signing Request (CSR), which is used to issue certificates to new actors in the PKI. ● Certificate, which provides the binding between an actor and the actor's cryptographic key. ● Certificate Revocation List (CRL), which is used to revoke the certificate(s) from one or more actors

in the PKI. The information will be exchanged between different maritime actors at sea and on shore, using any of the existing or future communication systems (WiFi, VDES, SATCOM, etc). Setting up and operating a trust infrastructure will enable these actors to authenticate themselves and securely exchange information. This use case demonstrates establishment of a Public Key Infrastructure (PKI) service, as a means to facilitate:

● Enrolment of new actors in the circle of trust. ● Issuing of cryptographic credentials that will allow the actors to communicate securely. ● Checking the status of the cryptographic credentials. ● Exclusion of misbehaving or "expired" actors from the circle of trust.

Use Case Diagram


83

Figure 22: Maritime Transport - Trust infrastructure for secure maritime communication. The diagram shows the issuing of

cryptographic credentials and enrolment of new actors



MT-SP01

Entity Authentication

There must be a reliable authentication mechanism to uniquely identify the persons accessing the maritime information systems (e.g. the NSW).

MT-UC1, MT-UC2, MT-UC3, MT-UC4

High Yes

uc Primary Use Cases

Issuing cryptographic credentials and enrolment of new actors

Vessel Traffic Service (VTS)

Retrieve certificate

Generate CSR

Sign CSR

PKI service provider

Vessel

Generate key pair

Port

Publish certificate


84


MT-SP02 Authorization

Critical information, such as security information (e.g. threat and risk assessment information) or maritime related critical information should only be available to authorized entities.


High Yes

MT-SP03 Access Control

Access control should be implemented for vessel software systems. (e.g. limiting access to only certain systems for each user).


High Yes

MT-SP04

Network Segregation

Segregation of networks between critical vessel software systems and common use systems. (e.g. between crew internet access and ship control systems).


Low Yes

MT-SP05

Data source/origin authentication

It must be possible to validate authenticity of the originator as well as of the destination of the transmitted data (e.g. VTS information, vessel voyage information, bulletin board data, AIS data).

MT-UC3, MT-UC4 High Yes

MT-SP06

Mutual Authentication

It should be possible to establish a mutual authentication between two parties.


MT-SP07 PKI enrolment

It must be possible to authenticate new actors that want to enroll into the PKI service.

MT-UC4 High Yes

MT-SP08 Revocation It must be possible to revoke users

and to exclude actors. MT-UC4 High Yes

MT-SP09

Data/Communication Confidentiality

It must be possible to ensure confidentiality of the communications and of stored or processed critical information.


High Yes


85


MT-SP10

Critical system integrity

Integrity protection for all command and control systems and other critical systems (e.g. critical sensors).

MT-UC2 High Yes

MT-SP11

Software update integrity

Integrity protection for the software, such that only updates from trusted sources get applied.

MT-UC2 High Yes

MT-SP12

Communication Integrity

There must be integrity protection of the information exchanged (e.g. VTS information, vessel voyage information, bulletin board data, AIS data), so that the maritime stakeholders/actors (vessels, VTS etc.) can verify the content.

MT-UC3 High Yes

MT-SP13 Log integrity

The maritime information systems (e.g. NSW) shall give the possibility to verify the history, location, or application of the information by means of documented recorded identification: user identification, timestamp, action performed.


Medium Yes

MT-SP14 Certificate integrity

It must be possible to verify the integrity of the active and revoked certificates (CRL).

MT-UC4 High Yes

MT-SP15

Critical system availability

The availability of critical maritime systems must be assured.


High Yes

MT-SP16

Transmission availability

The vessel must be able to transmit data (e.g. AIS information) without significant delays according to the required timing intervals (depending on speed).

MT-UC3 MT-UC4 High Yes

MT-SP17 Non-repudiation

There must be mechanisms to ensure the non-repudiation and traceability of actions performed by all persons generating, modifying or accessing the maritime information systems and data, such



86


as the National Single Window (NSW5).

MT-SP19 Privacy

The processing or transmission of privacy-sensitive data must be compliant with protection of data regulation, i.e. General Data Protection Regulation (GDPR), Directive (EU) 2016/680, Data quality principles Regulation (EU) 2016/679, ENISA Privacy and Data Protection by Design).


High Yes

MT-SP20

Critical system resilience

All critical maritime systems should follow the resilience-by-design principle.


Medium Yes

MT-SP21 Robustness

The maritime stakeholders and actors (vessel and VTS etc.) must be able to detect malicious activity or states of operation that initiate need for fallback modes.

MT-UC2, MT-UC3, MT-UC4

High Yes

MT-SP22

Resilience in connectivity loss

The PKI must be operational without online access for longer periods of time (weeks).

MT-UC4 High Yes

MT-SP23

Backward compatibility

The vessel must be able to receive and interpret older versions of the maritime information systems such as Automatic Identification Systems (AIS).


Figure 23: Maritime Transport - Security and privacy requirements



No look and feel requirements have been identified at this point.

5 https://ec.europa.eu/transport/sites/transport/files/modes/maritime/doc/2015-06-11-nswguidelines-final.pdf


87



MT-U01

User friendliness/ non-security experts

Entities that are not familiar with cybersecurity (non-experts) should be able to provide security-related inputs.

MT-UC1 MT-UC4 Medium No

MT-U02

User friendliness/ SW update

There must be ease of applying frequent software security updates to most vessels.

MT-UC2 High Yes

Table 33: Maritime Transport – Usability requirements



MT-OP01 Collaborative use

There should be a collaborative approach that assists the maritime stakeholder in analyzing and assessing the security processes and possible threats associated with the ICT systems.

MT-UC1 High Yes

MT-OP02 Dependency-aware

There should be new algorithms and techniques for capturing, analyzing and modelling the multi-order dependencies within the maritime supply chains.

MT-UC1 Medium Yes

MT-OP03 Adaptiveness

There should be new techniques for predicting and representing combined attacks/threats paths and patterns and measuring their effectiveness and applicability.

MT-UC1 Medium Yes

MT-OP04 Scalability

The PKI must be able to scale (with respect to number of certificates) for a number of users which is relevant for maritime sector.

MT-UC4 High Yes

MT-OP05

Domain-oriented PKI service

The PKI solution must be suitable for the maritime communication infrastructure in the sense that its bandwidth often is severely limited.

MT-UC4 High Yes


88


MT-OP06

Language-independent PKI

service

The PKI must be language-independent in order to be applicable in an international environment, regardless of country of origin of the participating actors.

MT-UC4 High Yes

Table 34: Maritime Transport - Operational requirements



MT-MP01 Adaptability

The PKI should be possible to operate by an internationally recognised trusted third party, such as IMO.

MT-UC4 High Yes

MT-MP02

Compliance with current infrastructures

The PKI should be applicable on top of any vessel communication systems (WiFi, VDES, SATCOM, etc).

MT-UC4 High Yes

MT-MP03

Cryptographic extensibility

The PKI should enable migration to future cryptographic algorithms without excessive costs or efforts.

MT-UC4 High Yes

Table 35: Maritime Transport - Maintainability and portability requirements



MT-SPL01

Political Compliance

Compliance with the NATO Alliance Maritime Strategy.


Medium No

Table 36: Maritime Transport - Social and political requirements


89



MT-LR01

Compliance with security standards

Compliance with existing security standards (such as ISO27001, 27005, ISPS, ISO2800, ISO28001) associated with the protection of the maritime supply chain, mandated by law and regulation for the protection of critical infrastructures (NIS Directive, Directive 2002/21/EC, Directive (EU) 2016/1148).


High Yes

MT-LR02

Maritime security compliance

Compliance with the international maritime security law and regulation (such as the SOLAS Convention, the ISPS Code).


High Yes

MT-LR03 EU CIP compliance

Compliance with regulations on EU Critical Infrastructure (Council Directive 2008/114/EC of 8 December 2008, SEC(2008)2701: the Critical Infrastructure Warning Information Network (CIWIN).


High Yes

Table 37: Maritime Transport - Legal and regulatory requirements


This section gives an overview on relevant national and international standards that specify a number of rules, obligations and requirements which should be taken into consideration. ● Information security Standards

○ ISO / IEC 27001 - "Information security management systems - Requirements" is the normative document to which an organization that wishes to be certified must refer.

○ ISO / IEC 27002 - "Information technology - Security techniques - Code of practice for information security management” provides guidance not prescriptive to protect the information assets of a company

○ ISO / IEC 27003 - "Information technology - Security techniques - Information security management system implementation guidance provides guidelines to define a project for the implementation of a management system of information security in accordance with ISO 27001

○ ISO / IEC 27004 - "Information technology - Security techniques - Information security management - Measurement" provides the procedures and examples of construction for defining and measuring the effectiveness of the Management System for Information Security adopted by the organization and related controls of Annex A.

○ ISO / IEC 27005 - "Information technology - Security techniques - Information security risk management" provides guidance on how and steps to be taken for a correct assessment of the business risk, particularly the risk inherent in information security. This standard, in the 2011 version, has been aligned with ISO / IEC 31000 "Risk management - Principles and guidelines".


90

○ The ISO 28000:2007 “Specification for security management systems for the supply chain”, defines the requirements for the implementation of safety management along the supply chain.

● Maritime Security Standards ○ International Ships and Port Facilities Security Code (ISPS) ○ International Safety Management Code ○ EC Regulation No 725/2004 on enhancing ship and port facility security ○ EC Directive 2005/65 on enhancing port security ○ MSC 96-4-1 - The Guidelines on cybersecurity on board ships ○ IMO-PKI guidance_Rev 2015 ○ MSC 96-4-2 - Guidelines for Cyber risk Management ○ MSC 96-4-5 - Measures aimed at improving cybersecurity on ships ○ IEC: 2016 MARITIME NAVIGATION AND RADIOCOMMUNICATION EQUIPMENT AND

SYSTEMS - Cyber Risk Management Guideline


Facts


Assumptions

An assumption related with UC2 is that software components are implemented in unsafe programming systems (e.g., C/C++ binaries).


Several partners involved in the demonstrator presented in this task are also actively involved in tasks of WP3 and WP4. In this part we provide a short discussion of how work presented in this demonstrator is related to tasks of WP3 and WP4. In particular, WP3 defines all common research. related to development of technologies that are leveraged in the various demonstrators of WP5. Here are some tasks of WP3 that provide techniques that are useful for the maritime demonstrator.

● T3.2: Research and Integration on Cybersecurity Enablers and underlying Technologies (partners involved: CYBER, UPRC, UCY). This task defines the technology behind several security and privacy enablers. Among these enablers, several apply on the maritime demonstrator and, specifically, these are (a) identity-management and authentication over multiple non-federated providers, (b) trusted execution on IoT devices, and (c) integrity-preserving storage for processing of critical data with long-term protection requirements. The maritime demonstrator leverages technologies from all these domains. For instance, identity management over multiple non-federated providers is critical, since several different components, of different origin, are involved in the demonstrator. Additionally, the demonstrator includes several IoT devices, and, finally, communication with the vessel may involve the exchange of critical information.

● T3.3: SDL – Software Development Lifecycle (partners involved: CYBER, SINTEF, UCY). This task explores the development lifecycle of software, from the early stages up to deployment, from a security and privacy point of view. The task focuses on secure-by-design and proactive methodologies for software development. In the maritime demonstrator, contrary to other domains and demonstrators, software can be considered legacy (hard to rewrite from scratch using new secure-by-design techniques). Nevertheless, in the maritime demonstrator, we explore the ability of unsafe software to defend against attacks by using software-hardening techniques.


91

● T3.5: Adaptive Security ((partners involved: UPRC): Task 3.5 is related with research in risk assessment and threat modelling. In the maritime transport demo, open research challenges involve the study and modelling of cascading threats, as well as of risk methods that emphasize on the system survivability and the resilience of systems under attack.

● T3.8: Conformity, Validation and Certification (partners involved: CYBER (lead)). This task analyses technologies, system designs and implementations to determine whether the combination of cybersecurity technologies in use achieve the desired security goals, allowing to compare different systems. The task will design a security framework capable of formally defining cyber-physical attack incidents, detecting an intrusion at different levels (physical or cyber), provide a resiliency policy and generate a forensics analysis.

Furthermore, WP4 aims at creating a common roadmap that represents the joint effort of all the various demonstrators of the project. To this aspect, T4.1 engages all vertical stakeholders (end users and industrial participants) so as to collect their requirements. With this, T4.1 establishes a feedback loop with the requirements of the maritime demonstrator. Moreover, all research challenges related to T5.8 are documented in the roadmap for maritime transport, which is documented in T4.8.

WORK PACKAGE T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 WP3 ü ü ü ü WP4 ü ü

Table 38: Maritime Transport - Relationship with WP3 and WP4 tasks


92

8 Medical Data Exchange In this section is described the requirements for the CyberSec4Europe demonstration case titled Medical Data Exchange. Firstly, a high-level overview of the demonstration case and its goals is provided, followed by a description of the actors involved. Then is provided a more detailed functional requirements using use cases, followed by a description of non-functional requirements. Finally, relevant constraints and assumption to be considered while implementing this demonstration case are reported.

8.1 Goals

The main objectives of the Medical Data Exchange demonstrator are: • Integrate and validate the research outcomes on the cyber-security and sensitive and personal data

protection for medical data sharing in a realistic environment (DAWEX Data Exchange platform) by:

a) Enhancing the multi-lateral trust among stakeholders generating and consuming data in the medical business sector;

b) Improving data marketplace platform trustworthiness; c) Generating new business opportunities.

These objectives are aligned with the following project objectives outlined in WP5 and WP3: • [Obj. 5.2] To identify use cases as demonstration cases with a high impact that sufficiently supports

or if possible enhances the intentions of EU regulations and directives, such as GDPR, eIDAS and PSD2.

• [Obj. 3.2] Innovative research in the main topic fields of cybersecurity providing and supplying of European products and solutions adapted to different sectors' needs, as well as with a sufficient level of trust among market players.

The challenges this demonstrator will address in the health domain context when sharing sensitive data are described as follow:

• Security and data protection aspects to ensure trust between parties. The data exchange marketplaces have to ensure trust between all parties involved in the data ecosystem, by guaranteeing their identities, and providing them legal functionalities as well as protecting citizen’s rights;

• Guarantee the right data management from different sources (smart wearables, hospitals, laboratories, insurance companies, pharmaceutical companies, etc.). The marketplace must assure that all data are properly protected by using privacy preserving techniques;

• Compliance with EU laws and regulations. Both EU companies and non-EU companies must be compliant to GDPR;

• Improve the identity and access management. Increasing security when both data providers and data consumers access the marketplace.

8.2 Stakeholders

In the context of the health domain and, particularly, when sharing data is performed, several stakeholders are involved. We see them as stakeholders within the health data ecosystem, each with their own roles, objectives and responsibilities. Two main categories of stakeholders can be distinguished:

• General health domain stakeholders • Specific health data sharing stakeholders


93

General health domain stakeholders are playing a basic role in the heath domain: • Policymakers: Are those participants such as health authorities, legal and regulatory bodies, which

are in charge of creating laws and regulations related to (personal) data protection and monitoring regulatory compliance when data sharing is performed. Their objective is providing the legal context to protect data subject rights.

• Data Subjects: The subject who owns both its personal data and its sensitive health data, and it consents to share the latter with third parties for unselfish goals or for a rewarding benefit. Examples are patients or persons that wear devices acting as data sources which generate the corresponding health data (e.g., wearables).

Specific health data sharing stakeholders are involved in the process of sharing sensitive health data of the data subjects:

• Data providers: Stakeholders who gather both personal data and sensitive health data from data subjects through different data sources:

o Participants in Health EU projects; o Hospitals; o Pharmaceutical companies; o Health tech companies; o In some cases, the data subject itself can act as a data provider.

• Data aggregators: These stakeholders are enabled to aggregate health data and perform some kind of data analytics. Data aggregators offer protected data to data consumers through the data exchange marketplace. The retrieved and provided data must not harm the data subject’s privacy. Towards this end, different privacy-preserving techniques, such as anonymization or pseudonymization, could be employed. Additionally, sensitive health data must be properly protected by using a crypto scheme, with the aim of avoiding leaks of these data subject’s sensitive data. According to it, some examples of data aggregators are the following:

o Health tech companies; o Municipalities; o Health data hubs o Health consortiums; o Health EU projects.

• Data consumers: Comprise a wide number of participants which use the protected data provided via the data exchange marketplace for their studies, while the data subject’s privacy is still preserved:

o Public and private research organizations; o Health authorities; o Hospitals; o Pharmaceutical companies; o Health EU projects

• Data Exchange Marketplaces providers: the marketplace owner is in charge of connecting the data providers with the data consumers for sharing sensitive health data, assuring at any moment the data subject’s privacy across the marketplace. Services for compliance with current regulations and for assuring the data subject’s rights are also provided. Additionally, the data consumers are able to upload and share processed data to marketplace.

8.3 Actors

In this section we provide a list of actors with brief descriptions. Actors are all the entities that interact with the Medical Data Exchange marketplace. They can be of two types: (i) Primary actors, which are actors that


94

have goals which this demonstration case needs to fulfil; and (ii) Secondary actors, which do not have specific goals associated with this demonstration case but are needed for the execution of its use cases.

Primary

Actors who provides the data to be shared and also those who consume such data have a main role in the envisaged use cases:

• Health tech companies: they provide data subject’s health data, aggregates health data from users’ wearables;

• Pharmaceutical companies: they can provide medical data and also act as consumers; • Hospitals: they provide sensitive health data from patients; • Research organizations and laboratories: they consume data for research purposes; • French Health data hub: gathering anonymized data from private players and consumes data for

study purposes; • Municipalities: that gather data collected from different public institutions; • French health consortium: is a private initative made up by several companies and supported by

the French government, gathering both private and public institutions. • MyHealthMyData EU project6: they provide synthetic data and also consumes aggregated data.

Secondary

Actors who do not participate during the data sharing but they are needed to fulfil this process. Health data exchange marketplace and privacy preserving tools system that will be applied are necessary for completing the described use case scenarios.

• Wearable provider: provides devices for retrieving health data subject’s data; • Infrastructure providers: provides infrastructure for connecting data providers with data

consumers and monetize the data exchange for all the stakeholders involved.

Use Cases Numbers

Table 39 associates the actors involved for each use case introduced in section Error! Reference source not found. in the Medical Data Exchange demonstrator.

ACTORS MD-UC1 MD-UC2 MD-UC3

Hospitals X X X

Pharmaceutical companies X X X

Health tech companies X X X

Data subject X X X

Municipalities X X X

French consortium X X X

6 http://www.myhealthmydata.eu/


95

ACTORS MD-UC1 MD-UC2 MD-UC3

Dawex GDM EU project X X X

Public and private research organizations X X X

Health authorities X X X

Pharmaceutical companies X X X

Insurance companies X X X

French Health data hub X X X

Wearable provider X X

Health data exchange marketplace provider X X X

Table 39: Medical Data Exchange - Mapping of actors to use cases


In this section we provide a brief description of these demonstration case functionalities, along with a list of use cases implementing them.


With the goal of allowing the exchange of sensitive medical and health data through the Dawex data exchange marketplace, different challenges related to security and privacy of such data need to be addressed. Particularly, health data must be protected in order to avoid leaks of sensitive information and ensure data integrity between the stakeholders. Furthermore, and according to the EU laws and regulations (e.g., GDPR), data subjects’ privacy must be guaranteed, assuring a correct management of their data. Additionally, identity management at the exchange marketplace need to be improved, with the aim of properly validating the stakeholders’ identities. According to it, we propose a generic use case, which is shown in Figure 24


96

Figure 24: Medical Data Exchange - Generic Use Case

Figure 25: Medical Data Exchange - Generic Use Case

This generic use case allows the exchange of sensitive health data through the Dawex data exchange marketplace between different stakeholders, also addressing the security and privacy challenges previously pointed out. Specifically, we integrate the most relevant and innovative tools and methods in cybersecurity in order to ensure confidentiality and integrity of shared health data (e.g., by using functional encryption, homomorphic encryption or multi party computation), as well as to preserve privacy of involved subjects sharing such health data (e.g., by employing data anonymization or pseudonymization techniques). Similarly, we also propose the use of strong authentication mechanisms and emerging decentralized technologies (e.g., eIDAS or Blockchain) to improve the stakeholders’ identity management at the data exchange marketplace. Regarding the stakeholders, we consider pharmaceutical companies, hospitals and health tech companies on the data provider side, among others. On the data consumer side, laboratories and Dawex GDM EU project7 are involved. Furthermore, data are mapped into a common data model using standard biomedical terminologies at the metadata level, so that their scope, volume and relevant characteristics can be easily viewed and evaluated by data consumers (i.e., data buyers) through the Dawex exchange marketplace. To facilitate this process, data visualisation tools will be integrated, thereby facilitating user experience.

Use Cases List

Based on the indicated generic use case, the envisaged UCs for the Medical Data Exchange are the following • MD-UC1 - Sharing Sensitive Health Data through an API: Protected sensitive health data are

shared by using an API that is made available through the data exchange marketplace;

7 https://cordis.europa.eu/project/rcn/218537/factsheet/en


97

• MD-UC2 - Sharing Sensitive Health Data through Files: Protected sensitive health data are shared by using files that are stored and made available through the data exchange marketplace;

• MD-UC3 – Enhancing the security of on-boarding and accessing the Dawex exchange marketplace: Security for on-boarding and accessing process to the data exchange marketplace is enhanced through strong authentication by using the eIDAS network and blockchain technology.

MD-UC1 - Sharing Sensitive Health Data through an API

In this use case (see Figure 26), the data provider, gathers both personal data and sensitive health data from a specific data source, such as a user’s wearable (step 1). Note that this provider must have previously acquired consent of the corresponding data owner in order to manage such data. Specifically, we consider data providers as legal persons (e.g., health tech companies, municipalities, French Heath Hub consortium) uploading health data as a report or medical tests. It should be pointed out that these data providers are able to aggregate health data coming from different sources and perform certain data analytics with them, so that they also play the data aggregator role. Therefore, they must also be in charge of preserving data subjects’ privacy, as well as properly protecting shared health data. Moreover, with the aim of monetizing the stored health data, the data provider makes them available to interested buyers by providing related metadata on the data exchange marketplace catalogue (step 2). Then, a data consumer (e.g., a medical laboratory) that is enabled to browse the catalogue (step 3) looks for an appropriate set of data in which it is interested. In this sense, information about how to treat the data will be provided (depending on the kind of crypto techniques applied during browse data protection process). To make this browsing easier, data visualization tools (provided by Dawex) will be used, thus improving the user experience, as already mentioned. Subsequently, the data consumer contacts the data provider to agree the terms and conditions about the management of the further requested data. It should be pointed out that this step is made through specific contract services that the Dawex marketplace supplies. Then, the data consumer requests health data to the data provider (step 4), which uses a data protection service (step 5) enabled to preserve data subject’s privacy by using data anonymization or pseudonymization techniques. Additionally, this service also allows to encrypt the requested health data by employing an encryption schema, such as functional encryption, homomorphic encryption and so on. Note that the data protection service may be provided by the marketplace or by a third party in different ways:

• As a jar file to be integrated in the data provider system; • As a standalone REST service to be deployed on the data provider environment; • As a marketplace service itself.

Finally, the data consumer retrieves the protected data through the marketplace(step 6) and then, it tries to decrypt the encrypted health data. At this point, if the decryption process is successful, and the consumer recovers the heath data, such actor could perform analytics over these just obtained data (step 7). Otherwise, it only be able to perform analysis with encrypted data (e.g., by using homomorphic encryption). It should be noted that, while the data consumer is able to carry out certain analysis with received health data for the original purpose, data subjects’ privacy is preserved in any moment. Moreover, it should be clarified that data protection on data sources (e.g., on user wearables) when they act as data providers is out of scope of this demonstrator. Then, the data provider should oversee:

• Obtaining consent of the data subject who is the owner of the shared health data in order to properly manage such data;

• Preserving data subject’s privacy on the data provider system; • Complying with the data owner rights.

Use Case Diagram


98

Figure 26: Medical Data Exchange - UC1 Overview

MD-UC2 - Sharing Sensitive Health Data through Files

This use case (see Figure 27Figure 27)differs from the previous one, when health data are included and shared through files, which are in turn stored in the data exchange marketplace. Therefore, many of the interactions are similar. For this specific reason,those that are different, have been described. Specifically, when the provider receives data from a source (step 1), the former launches the data protection service over the received data before of generating a file and include them on it, so that unauthorized accesses to the health data are avoided and data subject’s privacy is preserved (step 2). Note that, as previously stated, the data protection service may be provided in different ways. Once this file containing protected health data is generated, the data provider uploads it on the data exchange marketplace to be shared, also including a set of related metadata. Then, when the data consumer set the agreement with the data provider, the former requests the file. It should be pointed out that, unlike in the previous use case, this request is performed to the marketplace (not to the data provider) since it is in charge of storing and providing files containing protecting health data to interested consumers (steps 5 and 6).Finally, the data consumer tries to decrypt the health data from the just received file and, if it succeeds, the consumer will be able to perform analytics over such data (step 7), while data subject’s privacy is still preserved thanks to the previous data protection service.

Use Case Diagram



99

MD-UC3 – Enhancing the security of on-boarding and accessing the Dawex platform

The different stakeholders trying to use the Dawex marketplace need to be registered in advance. For onboarding purposes, based on the country eIDAS node availability for private sector, the Dawex data exchange platform will integrate a connection to eIDAS network for using an electronic identity issued by an EU country developing an eID scheme, under the eIDAS notification process. Currently, eIDAS network is able to authenticate natural person and is envisaged legal person would also be authenticated during the project development. This enables to improve the current online onboarding protocol on the Dawex platform, in terms or trustworthiness and assurance, thus easing both the enrolment and access processes to the platform users. This way, the user’s identity is validated by a trusted party, such as an Identity Provider from an EU country, which is issuing the eID (e.g., eID card). Once the user is registered on the Dawex platform, its identity can be derived to SSI blockchain. Specifically, after the user’s authentication, the platform service generates a verifiable credential, which can be stored on the user’s portable SSI Wallet (e.g., in a mobile phone). By registering this credential in a blockchain ledger, the user is permanently able to provide those certifications, without depending on the availability of the initial IdP for later verifications (Figure 28Figure 28).

Use Case Diagram




MD-SP01

Preserving data subjects’ privacy

When personal and sensitive data are shared, data providers must to preserve the data subjects’ privacy (e.g., by using anonymization and privacy-preserving techniques)

MD-UC1 MD-UC2 High Yes


100


MD-SP02

Secure exchanges of sensitive health

data

Communications between data providers and data consumers through the platform to exchange health data must be protected by security associations, in order to avoid leaks of sensitive information


MD-SP03

Ensuring the confidentiality and

integrity of sensitive health

data

Data subject’s health data must be protected at any time by using an encryption scheme that allows to ensure both their confidentiality and integrity


MD-SP04

Accessing to the data exchange marketplace

The enrolment and the access processes to the data exchange marketplace should provide a strong authentication mechanism to ensure only those legitimate stakeholders are allowed to perform such processes

MD-UC1 MD-UC2 MD-UC3

Medium Yes

MD-SP05 Sharing contracts

The marketplace must provide sharing contracts between data providers and data consumers


MD-SP06

Data access tracking

Mechanisms for tracking data access must be provided by the marketplace (e.g., by using blockchain technology).

MD-UC3 High Yes

MD-SP07

Decentralized verification

Decentralized identity verification should be provided by the marketplace

MD-UC3 Medium No

Table 40: Medical Data Exchange - Security and Privacy requirements


The following non-functional requirements are detected to be applied to this demonstrator.


101



MD-LF01 Metadata schema

A schema for metadata must be defined and provided by Dawex marketplace. The schema must use a well-known standard (such as XSD).


MD-LF02 Metadata format

Metadata must be provided to the Dawex marketplace either using the marketplace interface configuration or using a supported format type such as csv, xml, json or shapefile


Table 41: Medical Data Exchange - Look and Feel requirements


No usability requirements have been identified at this point.



MD-OP01

List of legal conditions

All the legal conditions for the exchange of sensitive health data must be provided by the marketplace


MD-OP02

Specifications for the integration of

the eIDAS

eIDAS authentication should be integrated for authentication purposes for accessing the marketplace

MD-UC3 Medium No

MD-OP03

Specifications and perimeter of the SSI blockchain

Definition and limit the perimeter for the use of the SSI blockchain regarding the Dawex roadmap must be provided

MD-UC3 High Yes

MD-OP04 Taxonomy

Definition of the taxonomy related to medical data must be provided


Table 42: Medical Data Exchange - Operational requirements


102



MD-MP01 Maintainability

Marketplace should consider the final user feedback for updating the platform.


Medium No

Table 43: Medical Data Exchange - Maintainability and portability requirements

Social, Economical and Political Requirements


MD-SPL01

Data subjects’ data protection

Data subjects’ personal data must be protected at any moment avoiding third parties can learn from the data


MD-SPL02 Data analytics

Data providers must be able to provide data from multiple sources in an adequate form to data consumers for analytics.


MD-SPL03

Monetize shared data

The data exchange marketplace should allow shared data monetization. The data owner can be remunerated when its health data are used.


Medium No

Table 44: Medical Data Exchange - Social and political requirements



MD-LR01

GDPR fulfilment about privacy and

data protection

The data subjects’ privacy must be preserved at any time. Towards this end, data providers and data consumers must fulfil the GDPR regulation and accomplish the data subjects’ rights.


MD-LR02 Sharing contracts

The marketplace must provide sharing smart contracts between data providers and data consumers


Table 45: Medical Data Exchange - Legal and regualtory requirements


103




Facts


Assumptions



The Medical Data Exchange demonstrator (Task 5.6) has a close link and dependencies with following WP3 and WP4 tasks:

• Task 3.2: This task identifies the horizontal cross sectoral security and privacy enablers, like blockchain, identity management, PET and the advance over state of art, providing privacy preserving enablers, that will be used in T5.6 demonstrator.

• Task 3.7: This task will be focus on best practices for innovative and GDPR compliant user experience, and also on the investigation of the compliance for identity technologies interoperability (e.g. eIDAS, GDPR, ePrivacy). These technologies play a main role in T5.6 demonstrator as personal and sensitive data subject’s data are shared.

• Task 4.1: This task collects requirements from demonstrator T5.6 and receives feedback from this task for the roadmap.

• Task 4.3: This task provides the steps to follow by task 4.9 related to this demonstrator, for providing a roadmap.

• Task 4.9: This task creates a roadmap for task 5.6 (Medical Data Exchange) based on the methodology explained in Task 4.3.


WP3 ü ü

WP4 ü ü ü

Table 46: Medical Data Exchange - Relationship with WP3 and WP4 tasks


104

9 Smart Cities In this section, we describe the requirements for the CyberSec4Europe demonstration case titled “Smart Cities”. We first provide a high-level overview of the demonstration case and its goals, followed by a description of the actors involved. We then provide more detailed functional requirements using use cases, followed by a description of non-functional requirements. Of course, a specific section will focus on cyber security requirements. Finally, we report relevant constraints and assumption to be considered while implementing this demonstration case.

9.1 Goals

Smart City demonstration case will focus on two main goals: • Setup and put in operation a consent-based infrastructure to support sensor and other urban data

platform and infrastructure for personal data exchange and reuse in public services, in compliance with GDPR.

• Setup an Open Innovation cycle that will drive city stakeholders from cyber security risks and needs assessment to the identification of the related solutions (i.e. cyber security services): setup cyber-security risk assessment tools and social engineering penetration testing tools.

SmartCity demonstration case will be based on the fact that Local Public Administration (LPA) could adopt a set of tools to protect themselves from cyber-risks, in privacy and security, especially in order to detect and prevent such attacks over two main level: at individual level (e.g. citizens, civil servants), and organizational level (e.g. PAs, third parties).

Starting from a process of needs assessment, an Open Innovation environment will involve city stakeholders to identify potential solutions/best practices and setup a marketplace of cybersecurity services to be used by Municipalities, in particular in personal data sharing scenarios among different services and 3rd party actors with different processing purposes in compliance with the GDPR.

Needs assessment will be applied at individual and organizational level with a set of tools: • At individual level:

o A Social Driven Vulnerability Assessment, that may simulate one of the most dangerous attack strategy (called Social Engineering) performed by attackers against people (both employee and citizens) in order to convincing them to reveal personal and sensitive information8.

o An assessment tool for people, about phishing emails, whose goals is to assess their capability to identify phishing emails9.

o Moreover, we aim at introducing an entire training platform that may facilitate Organizations (not only LPAs) to manage and assign specific training plans to people (both citizens and employees), in order to improve cyber-threats awareness and knowledge how to defend themselves from an “on-going threat reality”.

• At organizational level: a Risk Assessment Tool (RATING) whose aim is to help Risk managers, CEO and LPAs to have a full detailed report based on discovered vulnerabilities and estimated economic impacts. The carried-out goal is not only to give a predictive analysis of the possible attacks and impacts that an organization may suffer, but also to give a detailed plan of mitigations action (both soft and hard) to implement in order to minimize risks.

8 see https://www.dogana-project.eu/ 9 see for example TO4SEE (assessmenT tOol for Social Engineering Exposure)


105

Smart City demonstrator will be implemented starting from the specific requirements from Genoa, Murcia and Porto stakeholders in order to put in operation the above processes around personal data exchange among citizen, PA and other city stakeholders.

9.2 Stakeholders

This section is devoted to the identification of the main stakeholders that are the entities that will affected by, or who have an interest (economic, technical, political, legal, etc.) in the Smart Cities demonstration case. We consider two main categories of stakeholders:

• Local Public Administration: It includes all public entities involved (administrative, public employee, civil servants and other staff..) in smart cities processes and public service provision.

• Service Suppliers: Public and/or private organizations which provide any type of smart cities services generally processing data (personal or not).

• Platform Provider: Entities working with the providers of city data and services, and managing the content, defining policies and regulations of the platform.

9.3 Actors

In this section a list of actors with brief descriptions is provided. Actors are all the entities that interact with one or more use cases identified for Smart Cities demonstration case. They can be of two types: (i) Primary actors, which are actors that have goals which this demonstration case needs to fulfil; and (ii) Secondary actors, which don’t have specific goals associated with this demonstration case, but are needed for the execution of its use cases.

Primary

Actors who participate during the data sharing or cyber security assessment and solution elicitation and have a main role in the envisaged use cases:

• Citizens: operates as data subjects or end users of personalized data sharing services provided by Smart Cities service providers.

• Service Providers: They provided Smart Cities personalized services base on data sharing data. According to the type of services they are Data Consumer or Data Providers and hence operate both as Data Processor and Controller according to the definition provided by GDPR Regulation.

• City Data Publisher: Publishes open and proprietary data into the platform. Manages and maintain resources in the platform accordingly to terms and conditions

• CISO – CIO – CEO: Chief Information Security Officer; Chief Information Officer; Chief Executive Officer; are the main actors of the SMC-UC5, SMC-UC6 and SMC- UC7, whose aim is to support to identify and evaluate cyber-vulnerabilities and related risks and identify the solution to adopt.

Secondary

Actors who do not participate during the data sharing or cyber security assessment and solution elicitation but they are needed to fulfil these processes.

• DPO – Data Protection Officer: In use cases processes DPO can access to comprehensive records of all data processing activities conducted by the company, including the purposes of all processing activities, which must be made public on request DPO could participate to interfacing with data subjects to inform them about how their data is being used, their right to have their personal data erased, and what measures the company has put in place to protect their personal information.


106

• Employees: For SMC-UC5 and SMC-UC6, to assess vulnerabilities, the solutions should evaluate even human-related vulnerabilities, such as human behaviours of the employee and citizens.

• Pen-tester: Is a technical person, who will be delegated by Managers or CISO to conduct a SDVA. • Risk Manager: in case of well-structured organizations, Risk Management is often related to a

specific profile whose aim is to identify, prioritize and evaluate risks followed by economic consequences

Use Cases Numbers

Actor SMC-UC1

SMC-UC2

SMC-UC3

SMC-UC4

SMC-UC5

SMC-UC6

SMC-UC7

Employees X X X X X X X Citizens X X X X Service

Providers X X X X

City Data Publisher X X X X

CISO – CIO – CEO X X X

DPO X X X X X Risk Manager X X X

Pen-tester X X Table 47: Smart Cities - Mapping of actors to use cases




SmartCity Demonstration case has to support the following main functionalities.

Urban Data Platform functionalities

The urban platform provides city data in both human and machine (e.g. sensors, actuators, systems) readable and understandable formats to support interoperability among data sources and data consumers. The urban platform enables users to consume and publish data in a secure and privacy protected manner. User’s experience is enhanced by the provision of value-added services. To this end services provide the functions for updating, maintaining and accessing services as well as tracking their usage by users in a lawful manner, assuring security and privacy. Below the list of main functionalities:

• The platform (p/f) must provide open API so that new services exploiting the Data can be built • The p/f must be able to accommodate multiple data sources and origins. • Data shall be annotated in the form of LOD. • A SPARQL endpoint must be made available in order to search and retrieve data. • It must be possible to federate multiple instances of the p/f without compromising security. • Data annotation must include quality properties (availability, accuracy,…).


107

• It must be decided at run-time where (cloud level, edge) analytics are executed and then deploy functionalities accordingly.

• Platform must support Personal Data Sharing in which personal data is accessed and used by third party companies to provide services to the city.

Figure 29: Smart Cities - Urban data platform

Empower the citizens to their data

Demonstration case has to support Urban Data platform for a "user centred" personal data management: • The p/f must provide mechanism for enforcing privacy and data protection. • End-users must be able to decide their own access policies as far as their personal data is concerned

(using MyData concepts.) • End-users must be able to visualize easily who has access to their data. • The access policies must be context dependent, allowing to bypass restrictions in case of natural

disaster, or emergency for instance. • Right to be forgotten must be guaranteed (ability to erase unwarranted or wrong data) when legally

possible. • The p/f shall not make the raw data available without prior pre-processing.


108

Figure 30: Smart Cities - Data usage dontrol dashboard for personal data

Operationalization of a decentralized sensor data infrastructure

Demonstration case has to support the operationalization of a sensor data infrastructure for allowing multiple stallholders to interoperate without a centralized ownership, while enforcing privacy and security required by GDPR:

• To provide a decentralized identity management. • To support different stakeholders with different levels of access to the data. • Break-the-glass built-in mechanism for accessing sensitive data while recording evince of the

operation, e.g., law enforcement requesting raw video footage, without digital masks, as a crime scene evince.

• Ensuring data confidentiality to be enforced at the computational level in order to minimize data leakage.

• Ensuring secure communications between the sensors and the backend.

Figure 31: Smart Cities - Decentralized sensor data infrastructure

Protect Smart Cities assets from cyber risks


109

To protect Smart Cities from cyber-risks, the suggested demonstration case provides two assessments for different aims:

1. A social driven vulnerability assessment: the aim is to allow CISO to conduct a social engineering campaign in order to assess employee’ reaction on such specific kind of attacks (Phishing for example) and report discovered vulnerabilities, both human and technology based.

2. A risk assessment: The aim is to support LPA to assess evidence-based risk profiles for smart cities in order to identify major cybersecurity risks for their services and managed assets. LPA managers will be also supported by the solution to make decisions related to cyber-security investments on hard and soft mitigations in order to minimize exploitable vulnerabilities.

Below the list of major functionalities for the Social Driven Vulnerability Assessment (1): • To define the pen-test approach (if black box or white box) • Gather information on LPA’s digital shadow, likewise public information available on internet,

their web technologies and employee contacts email addresses. • To prepare a sample (better call hook for the attack) for the social engineering attack. • To launch and monitor the social engineering attack of the campaign. • To report targets ‘reactiveness and, in case of successful attack, to report all the information about

technological vulnerabilities discovered and their severity.

Below the list of major functionalities for the Risk Assessment (2): • Understanding Smart City cyber posture, in terms of major interested threat agents, their

motivations and their skills used to attack the LPAs • Evaluate LPA cyber vulnerabilities thought a Cyber Maturity Model. • Identify vulnerable assets and their relationships in case of attacks. • Estimation of the consequences from a Qualitative and/or Quantitative analysis. • Discover cyber-risks and their possibility to be mitigated.


110

Figure 32: Smart Cities - Social driven vulnerability and risk assessment processes

Cyber security solution elicitation and market place

Demonstration case has to support City stakeholders in the elicitation adoption of cyber security solutions and best practices to assure security and privacy in city services used by citizen. To this end demonstration case has to support the following functionalities:

• To suggest or report cyber security needs and issues (e.g. to the Municipalities). • Launch challenges in order to find possible solutions to solve those needs. • Propose, by following a collaborative approach, new ideas as possible solutions. • Evaluate and select the best ideas in order to be refined and implemented in a collaborative way,

according to a definite evaluation and selection mechanism. • Provide more details (refinement) about the selected ideas. • To support the publication of new solutions/services directly in a City Marketplace or identify

already available solutions that match the selected ideas.


111

Figure 33: Smart Cities - Process of cybersecurity solution elicitation

The above main functionalities could be mapped in the following use cases.

Use Cases List

• SMC-UC1 - Register Data Consumer and manage services: User, as data publisher or consumer, can register in the platform and personalize value added services, and request approval to consume city data via GUI or APIs.

• SMC-UC2 - Discover and Consume City Data: Registered and authorized users can discover and consume city data via GUI or APIs in a lawful manner.

• SMC-UC3 – Personal Data Sharing: Personal data is accessed and used by third party companies through third party consenting process.

• SMC-UC4 - Sensor Data sharing and processing: The sensor data is produced by different stakeholders and its processing can be performed by varying entities.

• SMC-UC5 – Assess exposure to social engineering threats simulating a targeted attack on LPA.

• SMC-UC6 – Assess cyber risks for LPA, evaluating exploitable vulnerabilities and their consequences (both from qualitative and quantitative approach).

• SMC-UC7 - Cyber security needs and solution elicitation and selection: City stakeholder can identify cyber security threats/risks and related potential solutions/best practices, already available or to publish in a city market place.

The above use cases are mapped with the following functional requirements:


SMC-F01

User registration

Allow users to register to use services and consume proprietary city data and open data (optional)

SMC-UC1 Medium No

SMC-F02

Security and authorization to

access to sensitive

information

Keep sensitive information secured and accessible only to authorized users

SMC-UC1, SMC-UC2, SMC-UC3, SMC-UC4, SMC-UC5,

High Yes


112

ID REQUIREMENT DESCRIPTION USE CASES PRIORITY MANDATORY SMC-UC6, SMC-UC7

SMC-F03

Authentication mechanisms

Provide authentication mechanisms for users

SMC-UC1, SMC-UC2, SMC-UC3, SMC-UC4, SMC-UC5, SMC-UC6, SMC-UC7

High Yes

SMC-F04

Definition of structured terms and

condition of provided services

Provide service providers mechanisms to define the terms and conditions of platform services data usage

SMC-UC1, SMC-UC2, SMC-UC3, SMC-UC4

Medium Yes

SMC-F05

Data format definition

Allow users to format data in any supported data formats

SMC-UC2, SMC-UC3, SMC-UC4

Medium Yes

SMC-F06

Multi data source

management

The query request may require data to be sourced from different storage locations


Medium Yes

SMC-F07 Metadata query

Allows query requests against all metadata used to manage the repository.


Medium No

SMC-F08

Data Usage disclaimers

Provide users information about the legal aspects of the data (license, ownership)


High Yes

SMC-F09 Audit log

Keeps an audit trail of all actions. All data must be traceable at any given moment, by owner. It must be possible to identify in a human-readable report: (i) all data concerning an individual, and (ii) the identity of the owner of any piece of data stored within the system


High Yes

SMC-F10

Consent Management

User can manage personal data consents (opt-in, opt-out, withdrawal) for third party re-use


High Yes


113


SMC-F11

Personal Data management

User can re-arrange personal data and usage policies


High Yes

SMC-F12

Data event Notification

User can track personal data processing and subscribe for process events notification


High Yes

SMC-F13

Add new stakeholder

Removing or adding of new stakeholders have to conform to a majority

SMC-UC4 Medium No

SMC-F14

Manage legal and ethical campaign

CISO must conduct a legal and ethical compliant social engineering campaign on his/her LPA

SMC-UC5 High Yes

SMC-F15

Vulnerabilities listing

The risk assessment must indicate Human, IT, and Physical LPA cyber-vulnerabilities.

SMC-UC6 High Yes

SMC-F16

Idea/solution lifecycle

management

To support a co-creation approach for discovery and problems detection and idea/solution evaluation and selection process

SMC-UC7 High Yes

SMC-F17 Market place

To support the discovery and publication of new/already available service solutions following a "marketplace" approach.

SMC-UC7 Medium No

Table 48: Smart Cities - Functional Requirements

UC1 – Register Data Consumer and Manage Services

User can register in the platform and request approval to consume city data via GUI or APIs. They provide valid registration details (to be defined) and wait for platform to confirm their registration. Users must accept the terms and conditions of platform usage and define how their personal data can be used by the Platform Owner and value added-services. Users can manage and alter their registration information at any time they want to. This use case can be further divided into a number subordinate use cases that Table 49 lists.

USE CASE BASIC STIMULUS AND RESPONSES

SMC-UC1.1 - Register Consumer

1. The platform prompts the user for a username and password or register new account.

2. The user selects registration options.


114


3. The platform prompts user for data consumer registration information (e.g. username, password) and privacy policies

4. The user enters in their information. 5. Platform verifies information and creates account. • If non-valid information, platform shows error message and returns

to step 1. 6. Platform acknowledges registration has been successful. 7. End of registration.

SMC-UC1.2 - User manages services

1. Platform provides user with an interface for services management. 2. User chooses to edit or delete services. 3. If edit, user revise service information (access-control, commercial models, parameters) and deployment: If delete, user selects services to be removed / disabled 4. User confirms action. 5. Platform quickly process user’s request. 6. Platform confirms execution of request:

o If valid request, platform acknowledges request has been processed successfully.

o If non-valid request, platform returns to step 1. 7. End of services management.

SMC-UC1.3 - User tracks services usage

1. Platform provides user with an interface for services management 2. User chooses to visualise usage information of a service 3. Platform quickly process user’s request for data usage information 4. Platform provides user with statistical information about services usage and data users anonymised information 5. End of data services tracking. Table 49: Smart Cities – SMC-UC1 subordinate use cases

Use Case Diagram

Figure 34: Smart Cities - SMC-UC1 use case diagram


115

SMC-UC2 - Discover and Consume City Data Users are registered in the platform and have received approval to consume city data via GUI or APIs. Users have accepted the terms and conditions of platform usage and define how their personal data can be used by the Platform Owner, including their usage for data profiling tools for service enhancing and personalization. Users, in any time, can manage and alter their registration information at any time they want to. This use case can be further divided into a number subordinate use cases that Table 50 lists.

USE CASES BASIC STIMULUS AND RESPONSES

SMC-UC2.1 - Discover city data via data query end-points

1. Users access specialised data query end-points (e.g. SPARQL) 2. Users provides information for pre-defined parameters for search 3. Users request data search 4. Platform quickly process users request for data

• All queries are verified against access rights restrictions • If restriction applies users are redirected to log in interfaces • Users provide credentials and log on the system

5. Users are provided with query results on the end-point if access is allowed

• If access is not allowed, platform issues an error message to the user.

SMC-UC2.2 - Discover city data via GUI

1. Users search city data via GUI 2. Users inputs search parameters (e.g. key words, categories, formats, publishers) 3. Users request data search 4. Platform quickly process users request for data

• All queries are verified against access rights restrictions • If restriction applies users are redirected to log in interfaces • Users provide credentials and log on the system

5. Users are provided with query results on an interface • If access is not allowed platform issues an error message to the

user

SMC-UC2.3 - Customise City Data

1. Users request data to be formatted in a particular format supported by the platform.

2. Platform quickly process users request for data formatting. 3. Mechanism for data conversion is called and process data. 4. Users are provided with data formatted as requested.

SMC-UC2.4 - Consume City Data via GUI

1. Users / Machines select data to be downloaded. 2. Users / Machines are redirected to authentication mechanism in case of registration is needed for the particular dataset:

o If authentication is successful, users are provided with requested data streams.

3. Users are provided with requested data via APIs.

SMC-UC2.5 - Consume City Data via APIs

1. Users / Machines makes data request on the platforms API 2. Users / Machines are redirected to authentication mechanism in

case of registration is needed for the particular dataset • If authentication is successful, users are provided with

requested data streams


116

USE CASES BASIC STIMULUS AND RESPONSES

3. Users are provided with requested data via APIs Table 50: Smart Cities – SMC-UC2 subordinate use cases

Use Case Diagram


SMC-UC3 - Personal Data Sharing A municipality manages a large number of information regarding citizens and the territory. Citizens data concern:

• Identifying data • Tax information • Specific information related to the use of social and commercial services (e.g. kindergartens,

primary school, social services etc.). Territory information are related to:

• Topography and place names • Road conditions • Facilities and infrastructure • Emergency systems (e.g. fire hydrants) • Public works

The Municipality’s goal is to maintain data security and governance by sharing part of its data with third party actors (companies, other public entities etc.). Data sharing process, and in particular citizen persona data sharing has to be supported by privacy and security enhancement tools. It is important to introduce tools for a lawful data sharing processes, with the ability to grant and withdraw consent to sharing data from a service (Data Source) to be processed in another service (third party ). Consent authorizes Data Sources to provision data to Data Consumer and authorizes Data Requester to process that data. Consent has to refer to a Data Usage Policy that can be linked to consent formalization. Consent needs to be given in a clear manner so that the data controller can demostrate that a valid consent has been given. Consent record should demonstrate:

• Who consented. • When they consented.


117

• What was consented. • How was consented. • Wheather a consent withdrawn occurred. • (in case of minor) consent on his/her behalf.

Consenting is free given by data subject and it consists of five steps: 1. Data processors (as Data source and third party data consumer) have to define and describe data

processing and related policies. 2. Information about the service is presented to data subject including what information the data

consumer would like to have and for what purpose. Data subject then defines data processing rules and constraints, which must meet the third party minimum requirements for the consent to be actionable.

3. Consent Record (receipt) is stored in data subject client (dashboard or wallet). 4. Consent Record (receipt) is delivered to the involved services and any requested authorization data

(e.g. token) is delivered to the services. Citizens as data subject by means of a dashboard/wallet is enabled to manage and control “personal data” during the interactions in data sharing process. By means of that dashboard Data subject has a single point to verify which data are used, and how and for which purpose, receive notifications about data processing and perform objections or consent withdrawal as well as perform right to be forgotten and data portability rights.


SMC-UC4 - Sensor Data sharing and operationalization

Cities must leverage the multiple sources of information regarding sensor data, i.e. IoT data. In this scenario, different stakeholders can produce data, so the ownership of data is spread across these actors. The data processing must be compliant to the GDPR so the following concerns must be take care:

• Decentralized Identity management • Data tagging • Audit trail for at all stages of the operation • Break-the-glass mechanisms to ensure proper response in emergency scenarios • Confidentiality while processing data • Privacy preserving techniques for sensitive data


118

The Municipality’s goal is to maintain data security and governance while allowing multiple stakeholders to participate, private (companies) and public (law enforcement, etc) entities to participate.

Use Case Diagram


SMC-UC5 - Assess exposure to social engineering threats simulating a targeted attack on LPA

Following Privacy by design and security by design concepts, this use case has as main goal to describe the process that need to be implemented in order to allow CISO (or managers in case of LPA) to conduct an entire social driven vulnerability assessment on their employees in order to understand how much the organization is vulnerable over social engineering attacks. In details, people who will use such solution will be able to understand what are on internet the public information about their organization and using such information, they can delegate pen-testers to simulate a real phishing attack and discover both human and technological vulnerabilities. This use case can be further divided into a number subordinate use cases that Table 51 lists.


SMC-UC5.1 - SDVA set-up

1. CISO creates a new social driven vulnerabilities 2. Machine provides to CISO a SDVA key access

• Only CISO can access to sensible information 3. CISO configures the SDVA instance

• Pen-tester information • SMTP server configuration • Upload list of targets

4. Machine anonymize information SMC-UC5.2 -

Information gathering 1. Pen-tester access to SDVA instance 2. Pen-tester collects information about targets based on CISO’ requirements

• Web researches (eg. Wikileaks, pastebin, whois etc..)


119


3. Pen-tester tags collected information as sensitive or appropriate to use in order to not violate any defined policies by the CISO

4. Pen-tester/Machine creates datasets that may be used to create the hook of the attack

SMC-UC5.3 - Hook Preparation

1. Pen-tester creates the email to be used as hook • Subject and Sender • Content • Evocative images

2. Pen-tester creates fake websites as landing page • Adding scripts to collect and track targets activities

SMC-UC5.4 - Launch of the attack

1. Pen-tester selects the available hooks 2. Pen-tester configures the scope of the attack:

• Collect credentials • Website visiting

3. Pen-tester sets the time schedule of the attack 4. Once launched the attack, machine starts to collect all the information about

targets activities • Number of email sent • Number of visits in the websites • Numbers of collected credentials • Technical information collected from targets’ system

5. Pen-tester/Machine stop the attack

SMC-UC5.5 - SDVA Reports

1. Machine aggregates information about the attack 2. CISO access to statistical results

• Overall activities • Clicks vs provided credentials • General statistics based on targets sample (eg.departments age

range, etc..) 3. Based on collected technical information on targets’ system, the machine

provides information about all the common vulnerabilities discovered. 4. CISO accesses to final report and see severity scores 5. CISO is also able to download the entire report about the attack

Table 51: Smart Cities – SMC-UC5 subordinate use cases

Use Case Diagram


120


UC6 - Assess cyber risks for LPA, evaluating exploitable vulnerabilities and their consequences (both from qualitative and quantitative approach)

CISO must perform a risk assessment based on company’s vulnerabilities and, once identified the most vulnerable assets is able to estimate from both qualitative and quantitative impact analysis the related consequences in case of cyber-attacks. The general approach then is to support users to distinguish tolerable risk from non-tolerable ones and make decision on best cyber-security mitigations strategy to implement. This use case can be further divided into a number subordinate use cases that Table 52 lists.


SMC-UC6.1 - Identify LPA Cyber-Posture

1. LPA manager access to the main menu of the solution 2. LPA manager selects the “asses vulnerabilities” stage and perform the

self-assessment • Identification of Threat Agents and their motivations • Identification of Cyber-Vulnerabilities

• Human related • IT related • Physical related

3. Machine provides overall scores about likelihood to be attacked and vulnerabilities founded.

SMC-UC6.2 - Create Risk Assessment

1. LPA manager access to the stage “Risk Assessment” 2. LPA manager clicks on “create” 3. Machine creates the risk-model

SMC-UC6.3 - Asset Clustering

1. LPA accesses to the stage “asset clustering” 2. Machine provides the asset taxonomy (both tangible and intangible

categories) 3. LPA manager select which are the assets that wants to involve in the

risk assessment


121


SMC-UC6.4 - Identify consequences

1. LPA manager access to the stage “Consequences” 2. LPA manager select which kind of evaluation wants to perform

• Qualitative approach • Quantitative approach

If Qualitative: 3. Machine provides list of vulnerable assets 4. LPA manager select for each asset the rating impact scale.

If Quantitative: 3. LPA manager provides economic value for the quantification of the

losses on assets. 4. Machine calculate impacts on assets

SMC-UC6.5 - Evaluate Risks

1. LPA manager access to the risk management stage 2. Machine provide a graphical representation of the assets in a risk matrix

defining criticality of the assets and estimated impacts 3. LPA manager prioritizes risk by setting risk criteria (tolerable vs no

tolerable) 4. Machine updates the risk matrix 5. Machine provides list of possible controls actions to mitigate the risk Table 52: Smart Cities - SMC-UC6 subordinate use cases

Use Case Diagram


UC7 - Cyber security needs and solution elicitation and selection

Following a security and privacy assessment City stakeholders as authenticated user have access to functionalities to create a need, an idea or a challenge by providing the required information about it. Each stakeholder is involved in the process and is invited to cooperate with each other to identify problems and needs to be able to solve them. The co-operation environment supports participant stakeholder in the management of Cyber security needs and solutions elicitation lifecycle and related solutions selection and adoption. The main phases are:

• Discovery and Problems Detection;


122

• Idea generation; • Idea Selection; • Idea Refinement; • Solution selection.

In Discovery and Problems detection phase stakeholders involved (in particular Municipality) share information in order to have a mutual understanding about needs, problems and services. Mutual knowledge is created. In Idea generation phase the stakeholders co-define the implicit knowledge created in the previous phase and convert it in explicit and shared knowledge. The collaboration between the users is promoted in this phase, in order to co-create innovative ideas to solve the problems discovered in the previous stage. In Idea selection phase the Municipality, together with an expert team (appropriately appointed) evaluates all the proposed ideas based on a set of barrier and quantitative criteria and select a subset of ideas. The selected ideas will pass to the next phase, named Refinement. After the Refinement the stakeholders starts a process of development and collaborative design. The author and the collaborators of an idea cooperate with each other to implement the refined idea. To do this, the involved actors are also supported by a marketplace of cyber security services and best practices to be used for the solution implementation. The implemented solution it can in turn be published in the marketplace for later discovery and adoption.

Use Case Diagram



This section resumes, for completeness, all the security and privacy requirements (functional and non functional). Solutions applied to demonstration case, described in the above use cases, should conform to security-by-design principles, privacy-by-design principles and EU Legal compliance.

ID REQUIREMENT DESCRIPTION USE CASES PRIORITY MANDATORY SMC-SP01

Authentication & Authorization

Solution implements different levels of security

SMC-UC1, SMC-UC2, High Yes


123

ID REQUIREMENT DESCRIPTION USE CASES PRIORITY MANDATORY and ensures that authentication, authorisation, and accounting is implemented through the solution;

SMC-UC3, SMC-UC4, SMC-UC5, SMC-UC6, SMC-UC7

SMC-SP02

Multi channel security protocols

Solution ensures the required protection across multiple communication protocols. Security has to be at the same level for all types of connection and regardless of whether the app is connected to the device over the Internet or locally;


High Yes

SMC-SP03

Authentication integration

Solution can be integrated with existing authentication mechanisms;


Medium NO

SMC-SP04

Data Provenance tracking

Solution provides data provenance, so that it allows for auditing of data access and update on secured data;


High Yes

SMC-SP05

Security modularity and

isolation

Solution is easy to protect and isolate parts from vulnerabilities;


Medium Yes

SMC-SP06

Access monitoring

Solution allows for monitoring access and changes;


Medium Yes

SMC-SP07

Track and identification or

breaches

Solution manages log records from its own components and from the underlying devices and systems in order to be able to track any breaches and to identify patterns and prevent problems that can

SMC-UC5, SMC-UC6 High Yes


124

ID REQUIREMENT DESCRIPTION USE CASES PRIORITY MANDATORY pinpoint problems before they happened;

SMC-SP08 E2E Encryption

Solution should support end-to-end encryption (protocol and message), automatic standard-based encryption from device to the application and encrypting data in transit between platform elements;


High Yes

SMC-SP09

Key Store management

Solution should have a secure store for keys and be able to integrate with key stores.


High Yes

SMC-SP10

Privacy and Security standards

compliance

Solution must implement privacy rules as stated by the European Union, in particular the new GDPR, national law, ECHR10 (Article 8), EU Charter11 (Article 7 and 8), Public law, criminal law and civil law of the countries where use cases will be implemented (fundamental rights, communication secrecy, privacy laws;


High Yes

SMC-SP11

Data ownership and control

Solution has to be transparent about the “who, what, where, when, and why” for any data or information being collected and should allow people to keep personal data private or share for specific purposes, safeguarding data ownership and control;


High Yes

SMC-SP12

Signed Data Consent

Any personal data "processed" in use case should require signed


High Yes

10 European Convention on Human Rights - https://ec.europa.eu/digital-single-market/sites/digital-agenda/files/Convention_ENG.pdf 11 EU Charter of Fundamental Rights - http://ec.europa.eu/justice/fundamental-rights/charter/index_en.htm


125

ID REQUIREMENT DESCRIPTION USE CASES PRIORITY MANDATORY consent by the relevant parties covering its intended use;

SMC-SP13 Dynamic consent

When a new request with the data arises, the platform has to be able to request a refit for purpose to the party;


High Yes

SMC-SP14

Personal Data store

Personal data has to be stored in a protected way (e.g. encryption, hashing);


High Yes

SMC-SP15

Data Storage security readiness

level

Any systems used for the storage and processing of personal data within the project must demonstrate a good level of security readiness, which can be done by (a) inclusion of the system within the scope of an ISO 27001 certified Information Security Management System or (b) independent verification by a third-party audit.


High Yes

SMC-SP16

Data minimization

Unused or unnecessary data that is collected must be deleted as early as possible


High Yes

SMC-SP17

Data Anonimization

Whenever functions within the platform could be performed without the use of personal data or with the use of anonymized data, this should be preferred;


High Yes

SMC-SP18 Data Visibility

Whenever personal information is visible to others, this should clearly be indicated to users;


Medium Yes

SMC-SP19

No automated data analysis by

default

No automated decision should be done when processing personal data.

SMC-UC1, SMC-UC2, SMC-UC3,

Medium Yes


126

ID REQUIREMENT DESCRIPTION USE CASES PRIORITY MANDATORY SMC-UC4, SMC-UC5, SMC-UC6, SMC-UC7

SMC-SP20

Central surveillance

Demonstration case solutions should prevent the possibility of creating central surveillance on users or groups of users.


Medium Yes

SMC-SP21

Open architecture and standards

The establishment of technological practices for security and privacy should based on open architectures and standards


Medium Yes

Table 53: Smart Cities - Security and privacy requirements


The following non-functional requirements are detected to be applied to this demonstrator



Solutions must be designed to be used by Non IT people with lack of information technology knowledge.


SMC-LF01

GUI & web plugins

The demonstration case must include a GUI that will allow the interaction with the end uses in data sharing processes or in cyber security risk assessment and solution elicitation.


Medium Yes

SMC-LF02 Multi-Language

The GUI interfaces must support different languages and provide an easy way to incorporate new ones.


Medium Yes

Table 54: Smart Cities - Look and feel requirements


127


SMC-U01 Usable interfaces

Solutions should be designed to be used by Non IT people with lack of information technology knowledge.


Medium No

Table 55: Smart Cities - Usability requirements


ID REQUIREMENT DESCRIPTION USE-CASES PRIORITY MANDATORY

SMC-OP01 Scalable solution

Solutions should be able to scale in term of data capacity, user capacity and components and services to be integrated.


Medium Yes

SMC-OP02

Distribute architecture

Solutions need to run on a distributed architecture and the components should be decoupled


Medium Yes

SMC-OP03

Pluggable components

The architecture must be “pluggable” and components in the platform must be easily replaceable with minimum impact.


Medium Yes

SMC-OP04

No service interruption

Solutions should not require service interruption to perform a risk assessment

SMC-UC5, SMC-UC6 Medium Yes

SMC-OP05

Technical compatibility

Solutions should be compatible to existing hard- and software architecture of the Smart Cities


Medium Yes

Table 56: Smart Cities - Operational requirements


128




SMC-MP01

Open Infrastrucures

Open infrastructures to make possible to change service providers without proprietary data lock-ins


Medium Yes

SMC-MP02 Data portability

To grant the data owner easier ability to exercise their right to data portability


Medium Yes

SMC-MP03

Open formats for data

Data available in a machine readable open formats and accessible by means of secure and standardized APIs;


Medium Yes

SMC-MP04

Support "Once Only" Principle

Open up for reuse of data in different services and follow "once only" principle in public services

SMC-UC2, SMC-UC3 Medium Yes

Table 57: Smart Cities: Maintainability and portability requirements


SMC-SPL01

No political purposes

Solution cannot be used for political purposes.


High Yes

SMC-SPL02

System non intrusive and

invasive

Solution should not affect the life of citizens and the ways in which the services of the municipality are used by the latter.


High Yes

Table 58: Smart Cities - Social and political requirements


129



No mandated contraints have been identified at this point.

9.8 Relevant Facts and Assumption

Facts


Assumptions



Smart Cities demonstrator (Task 5.7) has a close link and dependencies with following WP3 and WP4 tasks: • Task 3.1: this task addresses the project lifecycle and how the activities, results and community

built and gathered by the project compose into an overall CyberSec4Europe ecosystem of cyber-security development

• Task 3.2: This task oversees the identification of the horizontal cross sectoral security and privacy enablers, the design of the operational technological components and the identification and research on common technologies like:

o blockchain, o identity management


SMC-LR01 AGID Compliance

Compliance with the Agenzia per l'Italia Digitale - Agency for Digital Italy [AGiD] guidelines and the CAD (Codice per l’Amministrazione Digitale) regulation.


High Yes

SMC-LR02

GDPR Compliance

Compliance with the GDPR and other linked regulations.


High Yes

Table 59: Smart Cities - Legal and regulatory requirements


130

• Task 3.3: This task aims at identifying research challenges, requirements and approaches in all stages of the lifecycle of software.

• Task 3.4: in this task some of the research will focus on privacy-respecting big-data analytics, and in that sense with potential on citizen privacy and urban platform aspects.

• Task 3.6: usable security it is also concerned about mechanism to support users` privacy mechanism and as such enabling effective and usable security controls of user attributes.

• Task 4.1: This task collects requirements from demonstrator T5.7 and receives feedback from this task for the roadmap.

• Task 4.2: This task provides legal and regulatory requirements, these need to be taken into account in T5.7, especially regarding the GDPR compliance.

• Task 4.6: Privacy Preserving Identity Management will clearly impact the solution on data sharing and data management in the urban platform.

• Task 4.10: This task provides the roadmap for the smart cities demonstrator and, of course, it is strongly related to the T5.7.


WP3 ü ü ü

WP4 ü ü ü ü

Table 60: Smart Cities - Relationship with WP3 and WP4 tasks


131

10 Conclusions This document presenteds deliverable “D5.1 – Requirements Analysis of Demonstration Cases Phase 1”. For all demonstration case it identified relevant stakeholders and actors that have direct and specific interests into, or interact with, their ecosystem. Furthermore, it described a a set of use cases and their requirements. Non-functional requirements have been organized in specific categories, namely Look and Feel, Usability, Operational, Maintainability and Portability, Social and Political, and Legal and Regulatory. This systematic categorization allows for the definition of relevant requirements, thus providing a clear view of what cybersecurity challenges CyberSec4Europe needs, and aims, to overcome. Security and privacy requirements are treated separately from the above categories to highlight the importance of addressing the cybersecurity issues pinned down in the selected sectors. Finally, the document shows the relationship of each demonstration case with the tasks of WP3 – “Blueprint Design and Common Research” and WP4 – “Research and Development Roadmap”, in order to facilitate, promote, and strengthen the collaboration between the three core work packages.


132

11 Bibliography

[Lop17] J. Lopez, C. Alcaraz, J. Rodriguez, R. Roman, and J. E. Rubio, "Protecting Industry 4.0 against Advanced Persistent Threats", European CIIP Newsletter, vol. 11, issue 26, no. 1, European CIIP Newsletter, pp. 27-29, 2017.

[Che17] Chen, B., Wan, J., Shu, L., Li, P., Mukherjee, M., and Yin, B, Smart Factory of Industry 4.0: Key Technologies, Application Case, and Challenges. IEEE Access, 6, 6505–6519, 2017. https://doi.org/10.1109/ACCESS.2017.2783682

[Lu17] Lu, Y. Industry 4.0: A survey on technologies, applications and open research issues. Journal of Industrial Information Integration, 6, 1–10, 2017. https://doi.org/10.1016/j.jii.2017.04.005

[Alc19] C. Alcaraz, "Secure Interconnection of IT-OT Networks in Industry 4.0", Critical Infrastructure Security and Resilience: Theories, Methods, Tools and Technologies, no. Advanced Sciences and Technologies for Security Applications book series (ASTSA), Springer International Publishing, pp. 201-217, 2019.

[Tup18] Tuptuk, N., & Hailes, S. Security of smart manufacturing systems. Journal of Manufacturing Systems, 47(November 2017), 93–106, 2018. https://doi.org/10.1016/j.jmsy.2018.04.007

[NIS17] NIST, Cybersecurity Framework Manufacturing Profile, NISTIR 8183, September 2017.

[NIS-C] NIST and CISCO, Best Practices in Cyber Supply Chain Risk Management, Cisco® Managing Supply Chain Risks End-to-En, U.S. Resilience Project.

[NIS18] NIST, NIST Cybersecurity Framework, NIST release Version 1.1, 2018. [EU16] European Union, Machinery Directive 2006/42/EC, https://eur-

lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:157:0024:0086:EN:PDF, 17th May 2016, last access in 2019.