The Framework Programme for Research & Innovation ...

July 2019 1 WP Leader: RISE

The Framework Programme for Research & Innovation Innovation actions (IA)

Project Title:

A Novel Adaptive Cybersecurity Framework for the Internet-of-Vehicles

nIoVe

Grant Agreement No: 833742 [H2020-SU-ICT-01-2018] Dynamic countering of cyber-attacks

Deliverable

D2.2 Report of Stakeholder Requirements, Needs and Interests

Deliverable No. D2.2

Workpackage No.

WP2 Workpackage Title and task type

IoV Cybersecurity Challenges & Solution Architecture (R)

Task No. T2.2 Task Title Task 2.2: Stakeholder Requirements, Needs & Interests

Lead beneficiary RISE

Dissemination level PU

Nature of Deliverable R

Delivery date 31 July 2019

Status Final

File Name: WP_Activities_WP2_Deliverables_D2.2_7_Report_of_Stake-holder_Requirements_Needs_and_Interests-v1.0

Project start date, duration 01 May 2019, 36 Months

This project has received funding from the European Union’s Horizon 2020 Research and innovation programme

under Grant Agreement n°833742


Authors List

Leading Author (Editor)

Surname Initials Beneficiary Name

Contact email

Aslam, M AM RISE [email protected]

Co-authors (in alphabetic order)

# Surname Initials Beneficiary Name

Contact email

1 Anastasia Botsi AB ICTLC [email protected]

2 Aslanidis, P PA KENOTOM [email protected]

3 Kate Francis KF ICTLC [email protected]

4 Lauinger, J LJ TUM [email protected]

5 Luca Bolognini LB ICTLC [email protected]

6 Paolo Balboni PB ICTLC [email protected]

7 Vito Pavese VP ICTLC [email protected]

Reviewers List

List of Reviewers (in alphabetic order)

# Surname Initials Beneficiary Name Contact email

1 Votis, K VK CERTH [email protected]

2 Raza, Shahid RS RISE [email protected]

3

4

5


Document history

Version Date Status Modifications made by

0.1 05/07/2019 Initial version and document structure for D2.2 (Report of Stakeholder Requirements, Needs & Interests)

RISE

0.2 19/07/2019 Added subsections in Introduction, Methodol-ogy, and Data Security requirements

RISE, TUM, KENOTOM

0.3 26/07/2019 Added Sources of Requirements;

Added Data security requirements;

Added SIEM requirements;

Added Secure Network Authentication and Communication requirements;

Added Incident Response and Recovery Re-quirements;

RISE, TUM, KENOTOM

0.4 30/07/2019 Completed Introduction and Methodology sec-tions;

Added Legal and Regulatory requirements;

RISE, ICTLC

1.0 31/07/2019 Revised the structure of the report, added Conclusion; and Finalized the Draft

RISE, TUM, KENOTOM


List of definitions & abbreviations

Abbreviation Definition

IoV Internet of Vehicles

CAVs Connected Autonomous Vehicles

IoT Internet of Things

SIEM Security Information Event Management

PoW Proof of Work

GDPR General Data Protection Regulation

AI Artificial Intelligence

ML Machine Learning

SM Smart Contract


Executive Summary

Task 2.2 (T2.2) of Work Package 2 (WP2) aims to identify and state the requirements, needs and interests of the Internet of Vehicles (IoV) ecosystem stakeholders. This is done by getting real user feedbacks that consider, most importantly, the aspects of functionality, usability, reliability and deploy ability of the solution proposed by the nIoVe project. The nIoVe solution requirements are elicited by using a defined methodology which starts by identifying stake-holders and engaging them in stating the nIoVe requirements by adopting a holistic approach that consider multiple sources of input. These sources of nIoVe requirements include user needs, expectations from the system, business objectives, shortcomings of the technology, gaps in the existing state-of-the-art (SOTA), advances proposed in the nIoVe framework and legal and regulatory obligations.

The requirements identified by each stakeholder (mostly involving consortium members) are summarized and provide input to other WPs in their design, implementation, verification and validation. It is quite possible that more requirements will arise during the actual implemen-tation of the later WPs which will be incorporated, if needed, in the revised version of this report.


Table of Contents List of definitions & abbreviations............................................................................................. 4 Executive Summary ................................................................................................................... 5 List of Figures ............................................................................................................................. 7 List of Tables .............................................................................................................................. 8 1 Introduction ....................................................................................................................... 9

1.1 Purpose, Context and Scope of this Deliverable ......................................................... 9 1.2 Background ................................................................................................................. 9 1.3 Relation to other activities in the project ................................................................. 10 1.4 Structure of the report .............................................................................................. 11

2 Methodology .................................................................................................................... 12 2.1 Identify stakeholders ................................................................................................ 12

2.1.1 Vehicle manufacturers ........................................................................................ 12 2.1.2 Designers of post-market devices for CAVs ........................................................ 12 2.1.3 Smart-city infrastructure administrators ............................................................. 13 2.1.4 Public transportation authorities ........................................................................ 13 2.1.5 Passengers and pedestrians ................................................................................ 13

2.2 Sources of Stakeholder Requirements ...................................................................... 14 2.3 Collecting Stakeholders Needs and Requirements ................................................... 15

3 nIoVe System Architecture Requirements ....................................................................... 16 3.1 In-Vehicle Data Collector .......................................................................................... 17 3.2 Data Collection Toolkit .............................................................................................. 19 3.3 Co-simulation Tool .................................................................................................... 20 3.4 Secure Network Authentication & Communication Requirements.......................... 22 3.5 Incident Response and Recovery Requirements ...................................................... 27

4 Legal and Regulatory Requirements ................................................................................ 30 5 Deployment Requirements .............................................................................................. 34 6 Conclusions ...................................................................................................................... 35 7 Bibliography ..................................................................................................................... 36


List of Figures Figure 1 – nIoVe Task 2.1 in relation to other activities of the project ................................... 10 Figure 2 - nIoVe Requirements Collection Mehtodology ........................................................ 12 Figure 3 - nIoVe System Architecture ...................................................................................... 17 Figure 4 - Sources of Elicited Requirements ............................................................................ 35


List of Tables Table 1 – Sources of Stakeholder Requirements (viewpoints) ................................................ 15 Table 2 – Requirements for In-vehicle Data Collector ............................................................ 19 Table 3 – V2X Data Collection Toolkit Requirements .............................................................. 20 Table 4 – Co-simulation Tool Requirements ........................................................................... 22 Table 5 - Secure Network Authentication and Communication Requirements ...................... 27 Table 6 - Incident Response and Recovery Requirements ...................................................... 29 Table 7 – End User Requirements ........................................................................................... 33 Table 8 - Deployment Requirements ....................................................................................... 34 Table 9 - Summary of Elicited nIoVe Requirements ................................................................ 35


1 Introduction 1.1 Purpose, Context and Scope of this Deliverable This task focuses on the specification of the users’ needs and expectations given the existing technologies for cyber-security in CAVs. The main role of this task is to collect information about user’s point of view and in cooperation with other partners to infer the preliminary nIoVe functionalities. The main users will be the vehicle manufacturers, designers of post mar-ket devices for CAVs, smart-city infrastructure administrators, public transportation authori-ties, passengers and pedestrians. Considering the nature of the nIoVe project targeting oper-ation on multiple users, the definition of the users’ requirements should be assessed from multiple viewpoints. Specifically, within this task, an extensive analysis for the current tech-nologies utilized from the manufacturers of IoV technologies for the protection of sensitive personal data from cyber-attacks will be conducted aiming to analyze the requirements of this side. Moreover, the current status from the perspective of protection of such sensitive data considering the citizens that utilize the CAV and IoV infrastructures will be performed. This includes further analysis about the already detected and well-known events, the identification of the resources of the leaks and intrusions as well as the recording of personal opinions and guidance from domain experts. In this task, an analysis about the potential technologies on which the nIoVe set of tools will be focused will be also determined. To complete the user requirements analysis from a multidimensional perspective, members of the consortium that research the security for CAVs will identify the current vulnerabilities of the envisioned IoV ecosystem, the short-term trend of the attackers and will highlight the components on which the nIoVe should be steered. The outcome of this procedure will outline the framework within which the functionalities will be developed indicating the necessary technical requirements and specifications in the next activity (T2.3).

1.2 Background Today, vehicles are gradually transformed into complex digital platforms that shape the Inter-net of Vehicles (IoV) [1],[2], and interact (on real-time basis) with: the transport infrastructure, transport authorities, service providers/third parties, personal devices and other modern ICT components (e.g. IoT devices) that operate in their proximity. In addition, Connected Auton-omous Vehicle (CAV) technologies are getting closer to maturity with several demonstrations worldwide; CAVs are capable to sense their environment and navigate with limited or even no human control. Such advances along with vehicle electrification promise enormous potential benefits for the European citizens and societies like increased comfort and convenience for passengers, improved road safety, reduced costs, reduction of traffic and parking-related problems, etc. However, the abovementioned benefits and opportunities bring in new cyber-risks and opportunities for cyber-threat actors. New and unexplored attack surfaces are cre-ated through these complex & interconnected ICT infrastructures that are exposed to a con-tinuously and fast evolving cyber-threat environment. A shared communications network and control infrastructure, relying on internal and/or ex-ternal vehicle systems, increases the exposure of potential vulnerabilities and the likelihood of cyber-attacks. Specifically, the heterogeneous network architecture of IoV ecosystem in-cludes many types of vehicular communications, for instance includes Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I) of mobile networks, Vehicle-to-Network (V2N) and Ve-hicle-to-Pedestrian (V2P). Each vehicular communication of IoV is enabled using a different Wireless Access Technologies (WAT). The WAT includes IEEE WAVE for V2V and V2N, Wi-Fi and 4G/LTE for V2I and CarPlay/NCF for V2P [3]. The communication architecture not only includes vehicles and Road Side Units (RSUs), but also other communication devices such as smartphones, sensors, cameras, etc.


The use of high-tech on-board sensors, detection and response systems on their surroundings, including LIDAR, GPS, odometry, drive-by-wire control systems, and computer vision, are all examples of possible attack vectors for hackers trying to exploit this emerging technology. The ability of CAVs to store and communicate personal data may conflict with data privacy laws, creating ambiguity regarding the ownership, storage, and transmission of data collected [4]. Additionally, CAVs face major cybersecurity risks with respect to communication networks and the (software) execution environment. Unauthorized access to these networks can have dire consequences, such as undermining a vehicle’s safety and utilizing personal data for malicious intent8. The successful operation of CAVs and their impact on society depend significantly on addressing the risks concerning the privacy and security associated with them. Therefore, keeping cybersecurity risks for CAVs is of crucial importance. The interfaces of CAVs present an opportunity for exploiting vulnerabilities if adequate cybersecurity mechanisms are not implemented, while attackers may compromise the user’s personal data, threaten the vehi-cle’s systems or endanger passengers. The nIoVe cybersecurity solution aims to address the aforementioned cyberthreat landscape by developing and demonstrating secure V2X communication, data privacy mechanisms, Blockchain-enabled trust management and identification platform, SIEM platform for the IoVs, threat analysis and situational awareness platform, and a multi-layered response and recovery toolkit. These multiple modules in the nIoVe framework are designed to address an exhaustive set of stakeholders’ requirements collected and presented in this report.

1.3 Relation to other activities in the project This task will identify and document the needs and requirements of the stakeholders which will form the basis of other work packages of the project (see Figure 1). The requirements identified in this task will be used to design and implement the technologies and solutions developed in the nIoVe project during other WPs. These set of requirements will also be used to verify and validate the solution as an artifact of nIoVe concept. The methodology used to identify user requirements uses the current knowledgebase gath-ered through various sources like needs, expectations, SOTA gaps, current technology gaps, etc. However, the advances provided by the nIoVe project in later WPs will have fair chances of identifying new requirements of various types like end-user needs, new technology needs, etc. This fact will require us to revise the requirements draft which will be done in a revised requirements specification at the end of the project.

Figure 1 – nIoVe Task 2.1 in relation to other activities of the project


1.4 Structure of the report The rest of the report is structured as follows. Section 22 gives an overview of the methodol-ogy that we adopt to elicit nIoVe requirements. The requirements are collected and presented for the nIoVe architecture in Section 3. The legal and regulatory requirements are identified in Section 4. The report presents the deployment specific requirements in Section 56; and finally we conclude the report with a summary of overall elicited requirements in Section 6.


2 Methodology This section describes the methodology that we adopt to identify and document nIoVe re-quirements. Multiple approaches, ways and guidelines are recommended in the literature to elicit system requirements [5],[6],[7],[8]; we adapt these recommendations to follow a meth-odology that best suits the demands of this project. The methodology used in this task is rep-resented in Figure 2; and each step of the followed methodology is described in the following subsections.

Figure 2 - nIoVe Requirements Collection Mehtodology

2.1 Identify stakeholders In the first step of requirement elicitation, we identify stakeholders of the IoV ecosystem. The nIoVe consortium includes almost each category of the potential stakeholders which greatly helped in identifying the real and prioritized IoV requirements. These stakeholders then, using agile approach, analyze and finalize their set of requirements which will be presented in the later sections. The identified stakeholders of nIoVe are briefly described in the following sub-sections.

2.1.1 Vehicle manufacturers The vehicle manufactures - from IoV and CAVs perspective – design and develop innovative, smart and sustainable mobility solutions, including driverless and automated vehicles used for the first and the last mile transportation. These CAVs are usually equipped with components such as lidar, video camera, radar, odometers, GNSS base, inertial measurement unit (IMUs), and embedded electronics, making it possible to assess the operation state of the vehicle and detect its environment.

2.1.2 Designers of post-market devices for CAVs The designers of post-market devices - from IoV and CAVs perspective – design and develop

devices for CAVs such as GPS, radar, odometers, GNSS base, lidar, video camera, inertial meas-

urement unit (IMUs), and embedded electronics like engine control units (ECUs) in order to

extract, receive or send, save and analyze useful data from the inner and outer environment


of a vehicle. Additionally, apart from the initial development of a product they are responsible

for the testing, assurance and maintenance of the launched devices, regular SW updates, and

also, research and development of the new technologies to keep up with the latest trends and

needs.

2.1.3 Smart-city infrastructure administrators Smart city projects help the city management teams to remotely and automatedly perform city administration instead of paying field inspections; smart city transportation is a sub-sector in the city administration. The smart city transportation needs a connected infrastructure which is administered by the city authorities. These authorities are a major stakeholder in the IoV domain who collect live data from the connected (autonomous) vehicles and provide them useful information like traffic conditions, diversions, etc.

2.1.4 Public transportation authorities A smart transportation system with IoVs and CAVs, also includes intelligent public transport systems; hence the public transportation authorities are also important stakeholders as the users of the CAVs in the transportation solutions. Public transport authorities can achieve sig-nificant benefits of intelligent schedules and fleet management.

2.1.5 Passengers and pedestrians Passengers and pedestrians are among the main sources of the personal data that can be in-volved in processing activities and as such their role in the CAV environment must be consid-ered with respect to compliance with data protection provisions in addition to the necessity to have appropriate organizational and technical security measures in place. The ethical decision-making potential of CAVs presents an important consideration for pas-sengers and pedestrians [9]. CAVs are inherently capable of making decisions [10], also while facing uncertainty, that can affect both passengers and pedestrians. Safety plays a key role for both drivers and passengers who can be severely injured or killed if, for example, a sensor or positioning system fails to function correctly [11] and privacy is key in terms of what data is collected and the potential for surveillance, which together with security, is paramount for users. Trust plays a vital role in the success of autonomous vehicles and represents a primary need for users that encompasses both moral and technical concerns. Trust in the CAV environment is specifically linked to the perceived level of safety and the confidence of the user or passen-ger in the autonomous vehicle. Beyond the technical cybersecurity requirements of the CAV, the non-functional requirements of look and feel of safety, cybersecurity, and privacy [12] can be considered requirements for a larger social acceptance of such technologies. Incidents which include the remote attack of Jeeps, vulnerabilities in Volkswagens’ remote-less key sys-tems and the hacking of BMW’s ConnectedDrive systems [13] are concrete examples where the security of vehicle systems were compromised and negatively impacted consumer trust insofar as they had clear consequences on the safety and privacy of users/owners. Directly related to trust is the concept of transparency, as enshrined in Article 12 and Recital 58 of the GDPR [14] where the controller is obliged to provide information in an easily acces-sible and easy to understand manner. This legislative requirement represents the possibility for the other stakeholders to increase the trustworthiness of their product, insofar as an in-formed user will have more faith and a greater sense of security with respect to the CAV when they are able to understand how the machine works.


2.2 Sources of Stakeholder Requirements After identifying the stakeholders of nIoVe, they will be engaged in gathering requirements from their perspective. This means that each stakeholder will explore various viewpoints like her needs, objectives, expectations, technology constraints, gaps in the current state-of-the-art, and various legal and regulatory compliance requirements. These viewpoints or the sources of stakeholder requirements are listed in Table 1. The stakeholders, while gathering their requirements, may consider only a subset of these sources that they find relevant in their context. Once all requirements of different types (from different viewpoint) are gathered, they are prioritized to select only the requirements that match with the concept and scope of the nIoVe project.

S.Nr Source Type Description

1 Needs Identifying the needs of the stakeholders help in gathering nIoVe requirements. Due to different types of stakeholders (like end users, service providers, government, vendors, etc.), types of their needs can also vary and contradict significantly. For example, the end user needs a convenient system without complexities whereas the service providers have to offer multiple services for their business growth which can get complex.

2 Objectives Then nIoVe architecture aims to fulfill different ob-jectives of each stakeholder, such as, business growth, usability, security, privacy, safety, etc. These objectives, within the scope of nIoVe project, require a set of functionalities that help in identifying the re-quirements.

3 Technology Constraints The stakeholders like the CAVs manufactures, or af-termarket equipment vendors can identify con-straints or shortcomings of the existing technologies. These constraints are translated into the nIoVe re-quirements which aims at advancing the existing technologies.

4 State-of-the-art (SOTA) Gaps The literature review identifies gaps which can be plugged by researching new techniques to fulfill stakeholder needs and requirements. These gaps need to be filled which creates the requirements de-manding new research solutions. nIoVe identifies such requirements and will research new solutions in later WPs.

5 Expectations Th expectations are the required functionalities of the system which are necessary to meet the objec-tives. Identifying expectations help in gathering the system requirements.

6 Laws and Regulations Due to the involvement of multiple stakeholders as proposed in the nIoVe architecture, the interests of


these stakeholders, mainly the end-users, is pro-tected through various laws and regulations. These laws and regulations thus mandate various proce-dures and protections which define these regulatory requirements.

Table 1 – Sources of Stakeholder Requirements (viewpoints)

2.3 Collecting Stakeholders Needs and Requirements There are many ways of collecting stakeholder needs and requirements. The nIoVe project partners, who also represent the stakeholders, will use a variety of practices to collect nIoVe requirements. These practices include stakeholder workshops, internal brainstorming ses-sions, interviews with the stakeholders, and surveys, etc. The exhaustive set of requirements collected through these practices are then prioritized to elicit only selected requirements which will be included in this report and will make the basis for the functionalities provided by the nIoVe solution.


3 nIoVe System Architecture Requirements The advanced nIoVe cybersecurity framework aims to develop a concrete security and privacy solutions in connected-autonomous vehicles and IoV ecosystems. The nIoVe system architec-ture, shown in Figure 3, will consist of: (a) the core nIoVe toolkit (i.e. a Threat Intelligence Monitoring Platform driven by Machine Learning technologies, a multi-layered and coordi-nated response toolkit, a recovery toolkit, a trust management and accountability reinforce-ment platform, a threat intelligence repository); and (b) a reference architecture along with a set of secure-by-design guidelines and methodologies for OEMs. The bottom layer of the architecture consists of the Internet-of-Vehicles Infrastructure, namely the CAVs and their networks, as well as possible virtualized honeypots operated on vehicles. In the second layer (Secure Communication Layer), the Vehicle Data Collectors (VDC) are dedicated to sensing components build-in the connected and autonomous vehicles, while all other data collectors (Intelligent Transport Data & Network Traffic Collectors) coming from the smart-city infrastructure (cameras, meters for traffic, etc.) will be used to formulate a se-cured data transfer channel to serve the higher layers of the architecture. Last but not least, the Blockchain component (Blockchain-enabled Trust Management & Identification Platform) will provide a semi-private (consortium-based) Blockchain based on Etherium in order to pro-vide trust management services like device authentication, user authorization (mainly for ad-mins), data exchange verification, secure software updates and maintenance. The middle core of the architecture is a SIEM Platform for IoV, which includes three sub-mod-ules. The first is the ML-Driven Threat Analysis & Situational Awareness which will pre-process all collected data, will detect anomalies, perform risk assessment and provide visual analytics services to platform users. The second is the Multi-layer Response Toolkit which will take ac-tion whenever an attack is on progress or in regular maintenance processes and finally the third component is the Recovery Toolkit, used to estimate the damage made and to recover data, device and the overall system. Finally, users make the topmost layer of the architecture, who are the CAVs and their manu-facturers, Industry Cooperation Teams (ICT) and Computer Security Incident Response Teams (CSIRTs), IT administrators, and citizens (passengers & pedestrians). We focus on identifying nIoVe requirements to develop this architecture which is done by collecting requirements for each of its components in the following subsections.


Figure 3 - nIoVe System Architecture

3.1 In-Vehicle Data Collector The in-vehicle data collector is dedicated to collect data from in-vehicle sensors and to report vehicle information to a centralized data processing point (e.g. a server) or directly to other vehicles. The available vehicle operation data may include but not limited to: GPS position, speed, acceleration, fuel consumption data, engine running mode, sensor’s condition, cam-eras, etc. Any additional sensors and after-market equipment should be mounted in a way so the wire insulation is not broken or there is not any interference with the rest of the vehicle’s electronic systems. The in-vehicle data collector will also take advantage of valuable sensor data which are coming from user’s smartphones and use them for confirmation purposes in case of cyberattack and for back-up solution in case of malfunction as part of the response. Simultaneously, it could provide some vehicular data to smartphones and tablets for analysis and visualization, so the


communication will be two-way. In addition, data will be available to the sophisticated equip-ment installed in autonomous vehicle of NAVYA for accidents detection, traffic monitoring, attacks and violations detection, etc. The functionality is limited to the area of a single CAV, while external communication with the nIoVe is handled by the V2X data collection toolkit. In the table below the functional requirements that lead us to develop In-Vehicle Data collec-tor (represented by Requirement ID - RDV) are listed:

Req. ID Requirement Title Type Description

RDV-1

In-vehicle sensors Need The In-Vehicle Data Collector should be able to connect to any sensor which exists in or on vehicle (GNSS Antenna, Camera stereovi-sion, Odometer, Radar, Sonars, GPS, Accel-erometers, etc.).

RDV-2

After-market equipment Technology Constraint

Additional sensors and after-market equip-ment should be connected to In-Vehicle Data Collector by using Crocodile connect-ors. By that way wire insulation is achieved and none interference with the rest of vehi-cle’s electronic systems occurs.

RDV-3

Vehicle operation data Need The In-Vehicle Data Collector should be able to read and collect vehicle operation data (GPS position, speed, acceleration, fuel con-sumption, engine running mode, sensor’s condition, cameras, etc.) from existing in-vehicle sensors or new ones that will be con-nected afterwards.

RDV-4

Collection mode Objective The In-Vehicle Data Collector should collect vehicle operation data of sensors by a pre-defined mode (polling in predetermined time period, interrupts, etc.).

RDV-5

Report data Need The In-Vehicle Data Collector should be able to report vehicle information to other parts of the nIoVe (server, vehicles, citizens etc.)

RDV-6

External communication Objective External sensing and communications with other parts of the nIoVe must be handled only by the V2X data collection toolkit.

RDV-7

Vehicle passengers Need The In-Vehicle Data Collector should be able to establish a secure, authenticated and dis-tinct connection with mobile devices (smartphones, tablets, etc.) of passengers.

RDV-8

Vehicle passenger’s data Need The In-Vehicle Data Collector should be able to use available data from passenger’s mo-bile devices via Wi-Fi connection or V2X functionality for cross-confirmation pur-poses and back-up solution.

RDV-9

Report data to passenger Need The In-Vehicle Data Collector should be able to provide some of the collected vehicular data to passenger’s mobile devices via Wi-Fi connection or V2X functionality order to be analyzed and visualized.


RDV-10

Vehicle of NAVYA Objective Sophisticated equipment installed in auton-omous vehicles of NAVYA should be able to connect and communicate with In-Vehicle Data Collector in order to manipulate avail-able vehicular data.

Table 2 – Requirements for In-vehicle Data Collector

3.2 Data Collection Toolkit V2X data collection toolkit is based on the in-vehicle data collector and contains vehicular in-formation like position and speed, as well as status information such as alerts and warnings. Collected data are reported to other vehicles (V2V) or the infrastructure (V2I). Communication between CAVs and other architectural components of the nIoVe is two-way, so V2X data col-lection toolkit can also receive information from external to the CAV sensing components such as traffic cameras, microwave sensors and Bluetooth scanners for IoT. Integrity of the V2X messages is preserved by digital signature using ECDSA. Optionally the content can also be encrypted, and the cryptography is based on a public-key infrastructure that is managed by a central service provider. On receiving data from any component of nIoVe first the signature is verified, then the communicated data are compared and finally the data are propagated to surrounding V2X systems. In the table below the functional requirements that lead us to develop Interoperable V2X Data Collection Toolkit (represented by Requirement ID - RDT) are listed:


RDT-1 Data Collector Need V2X Data Collection Toolkit should be con-nected with the in-vehicle data collector.

RDT-2 Toolkit Information Need V2X Data Collection Toolkit should be able to contain odometry data (information about position and speed of the vehicle). In addition, should be able to contain status in-formation such as alerts and warnings.

RDT-3 External components of nI-oVe

Need V2X Data Collection Toolkit should be able to establish communication between other architectural components of the nIoVe such as other vehicles (V2V) or the infrastructure (V2I).

RDT-4 Communication type Need V2X Data Collection Toolkit and other archi-tectural components of the nIoVe should es-tablish a two-way communication.

RDT-5 Send data Need V2X Data Collection Toolkit should be able to send all collected data to external compo-nents of nIoVe.

RDT-6 Receive data Need V2X Data Collection Toolkit should be able to receive any available information coming from external to the CAV components (for example traffic cameras, microwave sen-sors, Bluetooth scanners for IoT).

RDT-7 Manipulate external data Need V2X Data Collection Toolkit should be able to use information about traffic conditions, the number, type and speed of vehicles


passing around, etc. which are coming from external to the CAV components.

RDT-8 Digital signature Objective V2X messages must be digitally signed using ECDSA. By that way integrity of V2X mes-sages is preserved.

ΚΕΝ-9 Data encryption Objective The content of V2X messages could be op-tionally encrypted in order to guarantee confidentiality and privacy.

RDT-10 Cryptography Objective V2X Data Collection Toolkit cryptography should be based on a public-key infrastruc-ture that is managed by a central service provider.

RDT-11 Allowance reception Objective V2X Data Collection Toolkit must first verify the signature when receiving data from other architectural components of the nI-oVe (vehicles or infrastructure)

RDT-12 Compare data Need V2X Data Collection Toolkit should be able to compare vehicle’s data with received data (from other architectural components of the nIoVe).

RDT-13 Post actions Need V2X Data Collection Toolkit should be able to assess potential risks (e.g. accidents) and initiate countermeasures (e.g. automatic brake maneuver, alarms).

Table 3 – V2X Data Collection Toolkit Requirements

3.3 Co-simulation Tool The Co-simulation tool for IoV vulnerability assessment will simulate existing and future com-plex infrastructures and cyberattacks in order to test quick responses to security incidents. The outcome from Risk Assessment Engine will be consumed by the tool to create evidence of the performance of various proposed solutions and furthermore detected Cyber-attacks coming from Big Data Monitoring and Cyber-attacks Detection will be used to perform pur-pose-built simulations into alternative IoV ecosystem settings. There would be a scoring algo-rithm for automated scoring of simulations and an additional manual scoring system, available at domain expert’s discretion. Domain experts and administrators will study outcomes and simulation reports through the visual analytics suite. There would be a cybersecurity training framework for the overall sim-ulation functionality where the core simulation elements will be represented as Objects (nodes, communications paths, software elements, devices like sensors and gateways, arti-facts/credentials/messages, human participants, processes & constraints) and a Scenario Def-inition Language (SDL) will describe interactions inside the simulation models. Metadata (like ObjectID, ObjectType, OS, IP addresses, ARP tables, listening ports, accounts) and virtually all available information will form the models to be used in a simulated scenario. Various Per-spectives (Attacker Perspective, Defender Perspective, Service Provider Perspective) will be provided by the Co-simulation tool. The models used by the Co-simulation tools will be ab-stractions of existing elements to allow easy mitigation in cross-platform settings. The tool will be compliant with the interoperability standards of the IEEE High-Level Architec-ture (HLA). Simulation Management Workstations (SMW) will provide the tool for authorized


personnel and parts of the simulation results will be shared through the Threat Intelligence Repository & Services for the IoV. In the table below the functional requirements that lead us to develop Co-Simulation tool (represented by Requirement ID - RCS) are listed:


RCS-1 Main focus Need The Co-simulation tool should be able to simulate existing and future complex infra-structures and cyberattacks.

RCS-2 Result characteristic Need The Co-simulation tool should be able to test quick responses to security incidents.

RCS-3 Risk Assessment Need The Co-simulation tool should be able to im-port and use any relevant information and data coming from Risk Assessment Engine.

RCS-4 Big Data Need The Co-simulation tool should be able to im-port and use any relevant information and data coming from Big Data Monitoring and Cyber-attacks Detection.

RCS-5 Simulation combination Need The Co-simulation tool should be able to manipulate all imported data in order to create evidence of the performance of vari-ous proposed solutions, to perform pur-pose-built simulations into alternative IoV ecosystem and study the results.

RCS-6 Scoring algorithm Need Simulations of the Co-simulation tool should use a scoring algorithm for automated scor-ing after the usage of Fault & Vulnerability injections to modify the known Attack Sur-face.

RCS-7 Reporting Objective Outcomes and simulation reports should be presented through the Visual analytics suite and Co-simulation tool should be able to ex-port information to this suite.

RCS-8 Specialists Objective Outcomes and simulation reports of Co-sim-ulation tool should focus mainly to domain experts and administrators.

RCS-9 Manual scoring Need Domain experts should be able to select manual scoring system apart from the auto-mated one when executing simulations in Co-simulation tool.

RCS-10 Elements Need The core simulation elements of the Co-sim-ulation tool will be represented as Objects (nodes, communications paths, software el-ements, sensors and gateways, arti-facts/credentials/messages, human partici-pants, processes and constraints)

RCS-11 Framework Need All elements of Co-simulation tool (known as Objects) will be used in a cybersecurity training framework.


RCS-12 Scripting language Objective Simulation models (combination of Objects in the framework of Co-simulation tool) should describe their interactions using a Scenario Definition Language (SDL).

RCS-13 Metadata Need Simulation models should be formed by Metadata (like ObjectID, ObjectType, OS, IP addresses, ARP tables, listening ports, ac-count) and all available information and will be used in a simulated scenario.

RCS-14 Perspectives Need The Co-simulation tool should be able to provide various Perspectives such as At-tacker Perspective, Defender Perspective, Service Provided Perspective).

RCS-15 Mitigation Technology Constraint

Models of the Co-simulation tool should be abstractions of existing elements to allow easy mitigation in cross-platform settings.

RCS-16 IEEE standards Laws and Regulation

The Co-simulation tool should be compliant with the interoperability standards of the IEEE High-Level Architecture (HLA).

RCS-17 Execution Need The Co-simulation tool should be available only on Simulation Management Work-stations (SMW) for authorized personnel.

RCS-18 Repository Objective The Co-simulation tool should be able to es-tablish a connection with Threat Intelligence Repository and share parts of the simulation results there.

Table 4 – Co-simulation Tool Requirements

3.4 Secure Network Authentication & Communication Requirements The trust management and identification platform of the secure communication layer of the nIoVe framework connects infrastructure components in a horizontal, secure, scalable, in-teroperable, real-time responsive, and decentralized approach. The underlying blockchain based technology leverages several different components and concepts which in turn depend on their own requirements. Since the nIoVe project has the objective to deliver a multi-layered cybersecurity solution, it makes sense to differentiate and categorize blockchain technology and concept requirements. Analysis of blockchain design and architecture enables to specify mappings and connections between blockchain architecture and nIoVe framework require-ments. Before introducing the first view on trust management and identification platform re-quirements, it is helpful to name functional requirements of the blockchain-based trust man-agement and identification platform which implements secure network authentication and communication. Functional requirements of the trust and identification platform are to provide device regis-tration, user authentication and identification, authorization, auditing and logging verification, and network traffic encryption across the network and services. Here, services that implement the requirements should comply with general nIoVe service features such as fault tolerance, isolation capabilities, redundancy competence, and automated maintenance, updates, patches, configuration, discovery, and deployment. The trust management and identification platform must ensure the stated functionalities between different services of nIoVe architec-tural layers. As the blockchain-based network connects multiple communication endpoints


within the nIoVe architecture, components and services of different nIoVe architecture layers specify different requirements on trusted management and identification functionalities. Therefore, it is necessary to first inspect nIoVe architecture communication devices, types, paths, and interactions. The objective to satisfy different functional requirements of the trust management and iden-tification platform, the trust management and identification platform requires a Software-De-fined Perimeter (SDP) compatible architecture. Utilization of the SDP architecture model ena-bles adjustable, on-demand and dynamically provisioned controlling and management of trust management and identification functionality between network components. The SDP model uses the SDP controller and authentication mechanisms to grant a client access to critical net-work assets and components [6]. Blockchain components could embody more critical network components for instance. Authentication and authorization determination happens prior to network access of the client. The architectural model specifies flexible role-based, privilege-based, policy-based, or access-control based authentication methods. The approach moreo-ver allows to establish a robust key management framework which leverages public key cer-tificates, symmetric keys, hash functions and revocation lists before a client connects to an internal SDP gateway that provides access to internal blockchain components. This communi-cation security establishment through the trusted management and identification platform functionalities and services is one of the main objectives of the nIoVe framework. For system wide communication security, trust management and identification processes depend on val-ues stored in the distributed ledger. From a stakeholder perspective, there are CAV manufacturers, passengers, OEMs, and others which participate in the nIoVe framework. Requirements of stakeholders on device registra-tion, authentication, authorization, auditing, logging, and network traffic encryption derive from law and regulations such as the EU General Data Protection Regulation (GDPR) which protects personal data [15]. This regulation formulates privacy guidelines within the infra-structure. Privacy requirements on identification management requires privacy preserving networking approaches, cryptography techniques, as well as zero knowledge proofs for trans-action verification within the distributed ledger block generation process. Zero knowledge proofs enforce correctness on transaction verification even if validated infor-mation is encrypted [16]. In other words, a zero-knowledge proof is a protocol by which one party can prove to another party that they know certain information without revealing the underlying data. The requirement for such a measure allows to store validated and privacy preserving encrypted information for authentication and identity management within a public ledger. The nIoVe framework utilizes cloud, vehicle, and infrastructure communication between pas-senger, enterprise, and cloud networks. A resulting requirement for the trust management and identification platform requires an interplay of public private and consortium based block-chain solutions. A consortium based blockchain is partially permissioned as well as private. The difference is that a set of predetermined nodes have the responsibility for consensus and block validation [17]. This means that multiple blockchain networks can form such a consor-tium blockchain. Blockchain based distributed IoV networks utilize multiple blockchain net-works which justifies the requirement for blockchain network interplay [18]. Another point from stakeholder view is comfort in authentication and identification processes. Here network segmentation through SDP could adjust authentication methods based on network compo-nent safety criticality level.


Another major stakeholder requirement on trust and identification functionality specifies flex-ible smart contracts for trust management and identification service implementation. The va-riety of different services for different application scenarios of for example authentication ser-vices justifies this requirement. Additionally, smart contracts and blockchain services need to satisfy immutability, traceability, auditability and accountability properties for ensuring a trustworthy cooperation between OEMs, tier suppliers, and passengers that demand contin-uous information sharing. The next technological view on the trust management and identification platform with its ser-vices that connect different nIoVe layers and services introduces another group of require-ments. Since blockchain technology analysis allows to classify different technology layers [19],[20], it is possible to group requirements based on blockchain technology layers. From the technological view, the blockchain infrastructure layer requires an open distributed ledger implementation, determination of geographical distribution of network nodes, storage, virtu-alization and containerization as well as tokenization strategies, trusted environments, and hardware for specific consensus algorithm requirements such as PoW. The next blockchain technology network layer requires solutions and definitions for connection types, propagation mechanisms, and network separation, segregation, and isolation capabilities. The following protocol layer requires consortium-based, permissioned, private, and public consensus proto-cols. Moreover, consensus algorithms are required. For enabling flexible, modular, sandboxed smart contract implementations the protocol layer leverages Ethereum Virtual Machines (EVMs) [21]. The protocol layer also handles chain forking. Coming to the service layer of the blockchain technology, smart contracts, digital identities, state channels, multi signatures, dig-ital assets, oracles, governance, wallets, and off-chain computation represent service layer components which allow blockchain based networks to implement a large variety of services. Services from service layer are important as they can be used to implement device registration and identity managements services. The last application layer requires distributed and decen-tralized apps, business logic, user interfaces, and programming languages and completes the blockchain technology stack. The following table lists and groups requirements of the trust management and identification platform which ensures system wide secure authentication and communication:


Functional (general) Requirements

RF-1 Device registration Objective Method to record and afterwards verify de-vices

RF-2 User authentication Objective Assure identity of the authenticating client

RF-3 User identification Objective Detect unique properties among clients

RF-4 Authorization Objective Specify access rights/privileges to resources

RF-5 Auditing verification Objective Examination of management controls of in-frastructure

RF-6 Logging verification Objective Verify automatically recorded system /soft-ware/communication events

RF-7 Network traffic encryption Objective Encryption/Decryption of network commu-nication data

nIoVe framework/infrastructure requirements


RI-1 Communication types Need Passive / active communication within and between nIoVe framework components

RI-2 Communication ser-vices/devices

Need List all communication devices, interfaces, and endpoints

RI-3 Communication interac-tions

Need List all interaction requirements of compo-nents that interact with trust management service

RI-4 Software-Defined Perime-ter (SDP) compatible archi-tecture

SOTA gap The SDP model uses a SDP controller and au-thentication mechanisms to grant a client access to critical network assets and compo-nents located behind a SDP gateway

RI-5 Robust key management framework

Need Management of cryptographic keys (gener-ation, exchange, storage, use, destruction, replacement), protocol design, key servers, user procedures

RI-6 Interoperability Need Conform characteristic of communication interfaces

Stakeholder requirements

RS-1 Data privacy Expectation

Policy of data collection and dissemination

RS-2 Stakeholder privacy Expectation

Protect personally identifiable information

RS-3 Zero knowledge proof SOTA Gap Transaction validation without revealing un-derlying data

RS-4 Public blockchain Expectation Publicly open platform for various clients can join, transact, and mine

RS-5 Private blockchain Expectation Private sharing and data exchange among participants with controlled mining of se-lected individuals

RS-6 Consortium-based block-chain

Expectation Partially private blockchain where no single organization is responsible for creating con-sensus but a set of predetermined nodes

RS-7 Continuous information sharing

Expectation Permanent access to shared information

RS-8 Flexible smart contracts Need Modular, sandboxed, integrated smart con-tracts designed for stakeholder needs

Technological requirements

Infrastructure layer

RT-1 Open distributed ledgers Need Consensus of replicated, shared, and syn-chronized digital data geographically spread across multiple components

RT-2 Geographical distribution of networks and nodes

Need Geographical deployment planning

RT-3 Storage Need Blockchain based storage techniques


RT-4 Virtualization/ containeri-zation

Need Isolated software packages which bundle li-

braries and configurations and communi-

cate through well-defined channels

RT-5 Hardware for specific con-sensus algorithm require-ments

Need Hardware designed to execute PoW compu-

ting tasks.

RT-6 Tokenization Need Reference identifiers for secure data substi-tution. Requires token management system

Network layer

RT-7 Connection types Need Peer-to-Peer, Software Defined Network-ing, etc

RT-8 Propagation mechanisms Need Information movement within networks

RT-9 Network segregation/iso-lation, Trusted execution environments

Need Capability to hide/ separate network parts using for example SDP.

TEE is an isolated area or server away from the main network that allows data being stored on the network safely

Protocol layer

RT-10 Consortium-based, pri-vate, public consensus process

Need Public, permissioned individuals (private), permissioned groups (consortium) partici-pation in consensus process

RT-11 Consensus algorithm Need Consensus algorithm requires agreement among multiple processes (or agents) for a single data value. (PBFT, PoW, PoS)

RT-12 Privileges /permissions Need Protocol layer permission handling

RT-13 Forking/side chains Expectation Blockchain forking required for chain adap-tation in cases of mining conflicts. Allow to-kens or other assets to go from the mother blockchain to a separate blockchain and then back

RT-14 Ethereum virtual ma-chines

Need Decentralized virtual machine stored in blockchain with the ability to execute scripts

Service layer

RT-15 Smart contracts Need Computer protocol intended to digitally fa-

cilitate, verify, or enforce the negotiation or

performance of a contract

RT-16 Digital identities Need Information on an entity used by computer

systems to represent an external agent (per-

son for example)

RT-17 State channels Need Channels for private available participants with limited existence. Clients on the chan-nel must sign transactions with private key for ensuring authorization

RT-18 Multi signatures Need This signature provides secure sign. Possible to decide how many signatures required be-fore providing access


RT-19 Digital assets Need Images, multimedia, textual contracts count as digital assets

RT-20 Oracles Expectation Find out information about the real-world situation and carry information to the smart contracts

RT-21 Governance Need Decentralized autonomous organization manages information and system assets

RT-22 Wallets Expectation Programs that store public and private keys of a user and interact with other blockchain networks. Enables monitoring on your digi-tal assets

RT-23 Off-chain computation Expectation Computing is done outside the blockchain application stack

Application layer

RT-24 Distributed/decentralized apps

Expectation Computer application that runs on a distrib-uted computing system

RT-25 Business logic Expectation Program that encodes real-world business rules which determine data creation, stor-age, editing

RT-26 User interfaces Need Software for human machine interaction for effective operation and control

RT-27 Programming languages Expectation Formal languages to express a set of instruc-tions that produce various kinds of output

Table 5 - Secure Network Authentication and Communication Requirements

3.5 Incident Response and Recovery Requirements The main objective of the incident response and recovery toolkits is attack prevention. The following functional requirements compose the multi-layered response and recovery toolkits. Functional requirements of the response toolkit are the existence of a response manager with the ability to respond with passive and active responses. The nIoVe framework expects the response manager to implement critical asset importance estimation, response planning, and response deployment. Decisions of response manager services depend on the threat analysis and situational awareness service of the nIoVe framework Security Information and Event Management (SIEM) layer. Therefore, components of the threat analysis and situational awareness platform described in section 7.1 count as source requirements for the response toolkit. Active and passive responses execute the planned incident response of the response manager. Additionally, the response manager can leverage functionality of the recovery toolkit for attack prevention or system isolation. From a stakeholder viewpoint, attack incident notifications and response handling should not overload user interfaces of passengers with all response actions but rather inform about pas-senger relevant responses and recovery measures. User interfaces of secure control cockpits, network administrators, CAV manufacturers, as well as industry teams should receive all no-tifications about response planning and recovery measures. The nIoVe framework expects the recovery toolkit to consist of a damage assessment, data recovery, device recovery and system recovery modules. The recovery toolkit entirely de-pends on the requirements of the multi-layered response toolkit.


The following table lists requirements for the nIoVe multi-layered response toolkit and the recovery toolkit. Additionally, it lists general requirements for response toolkits [22] and re-covery toolkits [23].


Functional Requirements

RF-1 Response Manager Objective Component that is responsible for directing the response

RF-2 Critical asset importance estimator

Need Estimates the importance of the infected critical asset or the vehicle under attack

RF-3 Response planning SOTA Gap Response planning depends on attack anal-ysis and reacts dynamically on different at-tack types

RF-4 Response deployment Need Determine the installation location of the response toolkit (vehicle, smart city, gate-way, etc)

RF-5 Passive response Expectation Attacking entity stays unaware of response

RF-6 Alerts & notifications Need Notification Signal towards stakeholder endpoints

RF-7 Digital forensics genera-tion & analysis

Need Investigation and maintenance of material prior or past the attack that can be used in a lawsuit against the attacker

RF-8 Active Response Expectation Attacking entity is aware of response

RF-9 Updates & patches Need Update software components

RF-10 Asset isolation/ safe mode Need Isolates software components from system

RF-11 Recovery toolkit Objective Recovery management

RF-12 Damage assessment mod-ule

SOTA Gap Performs damage assessment and depends on system monitoring information. Cooper-ates with risk assessment engine.

RF-13 Data recovery Need Retrieves inaccessible, lost, corrupted, dam-

aged, formatted data if data is not accessi-

ble in regular way

RF-14 Device recovery Need Automated or manual recovery applies in device recovery processes

RF-15 System recovery Need Revert system states for returning to regular system behavior

General Intrusion Response and Recovery Requirements

RG-1 Attack prevention Objective Goal to prevent the attack or system failure

RG-2 Component Isolation Need Isolation of components to prevent compo-nent interaction with affected system

RG-3 Safe mode Need Allows limited number of services

RG-4 Fault tolerance (adaptive nature)

Objective System maintenance/ reliability/ robustness in cases of failures or attacks


RG-5 Real-time response SOTA Gap CAV and infrastructure should be able to re-spond to live events

RG-6 Response metrics policy Expectation Require static approach to the response metrics, and response selection is always based on some specific static metrics (Noti-fication IRS, Manual IRS, Automated IRS, Cost-Sensitive IRS, Adaptive IRS)

RG-7 Interoperability Need System interoperability to enhance real-time behavior

RG-8 Semantic coherence Need Required features allow the IPS to under-stand the intrusion notification and events with different syntaxes and semantics from different IDS

RG-9 Timing behavior Need Capability to design responses based on tim-ing properties

RG-10 Open system architecture Need Response network propagation has require-ment to reach desired components and ser-vices

RG-11 Alert parallelization SOTA Gap Parallelization of system alert propagation

RG-12 Manage/Control of False Alarm

SOTA Gap Requirement to indicate IDS confidence and accuracy

RG-13 Risk/Damage Assessment (cost-sensitive)

Need IPS should be cost-sensitive and be able to assess the risk, complexity, and cost of the response

Table 6 - Incident Response and Recovery Requirements


4 Legal and Regulatory Requirements The Article 29 Working Party (WP29) Opinion 8/2014 on the on Recent Developments on the Internet of Things (IoT), in exploring potential threats to individuals and giving recommenda-tions to stakeholders, specifically stated that individuals should be empowered by way of be-ing informed, which is the best way to protect their rights and at the same time drive innova-tion. Following this logic, passengers, but also pedestrians, should be aware of the interaction between the data being collected by the CAV and actions that they may take if they wish to exercise their rights. As the WP29 has pointed out, the protection of data subjects’ rights and interests in the IoT environment (and, by way of analogy, in the IoV environment as well) rep-resents a particular challenge in terms of managing data flows. The WP29 warns that users may find themselves under monitoring, especially when the col-lection and processing of their data is not carried out in a transparent manner. Therefore, stakeholders in the IoT field shall apply the principles of privacy by design, when developing new systems, applications, and tools. Moreover, the WP29 points out that data subjects and users must be able to exercise their rights and thus be “in control” of their personal data at all times. It follows that devices and applications shall be designed so as to inform users and non-users about the means and purpose of the collection and the processing of their data. This may be achieved, for example, by allowing users to receive notices or warnings, designed to frequently remind them that sensors are collecting data, also by allowing the application on which the IoT tool is running to periodically send a notification to the user to let him know that the device is actually recording data. Furthermore, developers shall pay attention to the types of data being processed and to the possibility of inferring sensitive personal data from them (this issue has not been tackled yet, but it shall be in a later stage of the project). The WP29 concludes by stressing that developers shall apply a data minimization principle: for example, if the purpose of the processing may be achieved using aggregated data, then developers shall not access the raw data. In 2014, the first standards for Cooperative Intelligence Transport Systems (C-ITS) were adopted and implemented, with the objective of preventing car accidents by providing warn-ing messages and successfully mitigating other road safety risks, promoting safe mobility through the adoption of wireless communication technologies that connect infrastructure and vehicles to identify risks in real time [24]. The standards provide high-level security rules for devices connected to network infrastructure and can be used by developers and manufactur-ers to guide their work. The Cyber Security for Consumer Internet of Things (2019-02) Guidelines provide developers and manufacturers with guidance on how to secure their projects, implementing technical controls and organizational protocols that can mitigate security problems of IoT and ensure GDPR compliance [25]. The ETSI TS 103 645 Guideline provisions1 include useful points of reference with respect to the nIoVe mission and should be considered in the development of the cybersecurity frame-work:

1 ETSI is a European Standards Organization, a recognized regional standards body dealing with tele-communications, broadcasting and other electronic communications networks and services that supports European regulations and legislation through the creation of Harmonised European Standards. Only standards developed by the three ESOs (CEN, CENELEC and ETSI) are recognized as European Stand-ards (ENs). For more information see https://www.etsi.org/about

https://www.etsi.org/about

https://www.etsi.org/about


1. No universal default passwords: “Following best practice on passwords and other au-thentication methods is encouraged. Device security can further be strengthened by having unique and immutable identities”;

2. Manage vulnerabilities reports: provide a public point of contact to report vulnerabil-ities to, disclose vulnerabilities in a timely manner, continuously monitor vulnerabili-ties as part of the product security lifecycle;

3. Keep software updated; 4. Securely store credentials and security-sensitive data; 5. Communicate securely; 6. Minimize exposed attack surfaces; 7. Ensure software integrity; 8. Ensure personal data is protected; 9. Make systems resilient to outages; 10. Examine system telemetry data; 11. Make it easy for customers to delete personal data; 12. Make installation and maintenance of devices easy; 13. Validate input data.

The table below lists functional requirements that shall be followed in the development of the cybersecurity Requirements framework for End-Users (represented by requirement ID - REU):


REU-1 Internal organization: Se-curity roles

Need Assign appropriate security roles and secu-rity responsibilities to designated personnel

REU-2 Personnel: Assignment and review of access and privi-lege rights

Need Establish and maintain an appropriate pro-cess for managing assignment and review of access rights and changes in personnel or changes in their roles and responsibilities

REU-3 Access rights: Access con-trol to network and sys-tems

Need Establish and maintain appropriate policies and measures for access to resources. For example, zero trust model, ID management, authentication of users, access control sys-tems, firewall and network security, etc.

REU-4 Third Party Management: Security in supplier man-agement and service agreements

Need Establish and maintain a policy with security requirements for contracts with suppliers and customers (in which data protection re-sponsibilities and obligations are imposed on the supplier)

REU-5 Physical and environmen-tal security: Physical and environmental security

Need Establish and maintain policies and measures for the physical and environmen-tal security of datacenters such as physical access controls, alarm systems, environ-mental controls and automated fire extin-guishers, etc.

REU-6 Integrity of network and systems: Network security management

Need Establish, protect, and maintain the integ-rity of its own network, systems and services by taking steps to prevent successful secu-rity incidents. The goal is the protection from viruses, code injections and other mal-ware that can alter the functionality of the


systems or integrity or accessibility of infor-mation

REU-7 Security assessments: Compliance with security policies and standards

Objective Establish and maintain appropriate proce-dures for performing security assessments of critical assets

REU-8 Security of data at rest Need Establish and maintain appropriate mecha-nisms for the protection of the data at rest, by taking into consideration the following:

Segregation of duties

Labelling of information

Handling of assets

Business requirements of access control

Management of privileged access rights

Information access restriction

Use of privileged utility programs

Access control to program source code

Separation of development, testing and op-erational environments

Protection from malware

Control of operational software

Network controls

Segregation in networks

Information transfer policies and proce-dures

Electronic messaging

Confidentiality or non-disclosure agree-ments

Securing application services on public net-works

Protecting application services transactions

REU-9 Physical media handling Need Check the removable devices and define a policy for their use and disposal, that is per-formed with respect for the applicable law and regulation. If any data is stored in such devices, they are protected during transport, to avoid corruption and/or data breach

REU-10 Cryptographic controls Objective Ensure proper and effective use of cryptog-raphy to protect the confidentiality, authen-ticity and/or integrity of information

REU-11 Security incident reporting Need Establish and maintain appropriate proce-dures for reporting and communicating about security incidents

REU-12 Data Breach reporting Laws and Regulations

Establish and maintain appropriate proce-dures for reporting and communicating about data breaches


REU-13 Business continuity Objective Establish and maintain contingency plans and a continuity strategy for ensuring conti-nuity of the services offered

REU-14 Disaster recovery capabili-ties

Objective Establish and maintain an appropriate disas-ter recovery capability for restoring the of-fered services in case of natural and/or ma-jor disasters

REU-15 Data subject’ rights Laws and Regulations

Provision of information notice to data sub-jects and guarantee on the exercise of data protection right (right to erasure, right to data portability, right to lodge a complaint with a supervisory authority)

Table 7 – End User Requirements


5 Deployment Requirements The question of where to deploy the nIoVe framework and its components marks a source requirement. From a stakeholder view, there is the expectation to deploy the framework in the most possible automated and cost-efficient manner. Moreover, infrastructure deploy-ment strategies need to consider infrastructure design which takes monitoring capabilities into account. Automated bootstrapping and configuration of services enables services to join a system after isolation. Component isolation requires modularity of services and serves for separated monitoring of processes. After system deployment, Continuous Integration and Continuous Delivery/Deployment (CI/CD) ensures highly automated system maintenance.


RG-1 CI/CD Expectation Combined practices of continuous integra-

tion and continuous delivery/deployment.

CI/CD produces (build, test, release) soft-

ware in short cycles with greater speed and

frequency.

RG-2 Modularity Need Software isolation capabilities

RG-3 Automated configuration Expectation Joining networks without intervening active

services

RG-4 Automated maintenance Need Automated updates and software patches

RG-5 System bootstrapping Need Automated system startup and infrastruc-ture integration

RG-6 Geographic location / in-frastructure location

Need Specify where to deploy components

Table 8 - Deployment Requirements


6 Conclusions This task involved broad participation of project consortium members which hail from differ-ent sectors associated with the Internet of Vehicle (IoV) domain. These participants, therefore also represented, different stakeholders of the IoV domain for which the nIoVe solution is being developed. This meant that the requirements we elicited during this task grasp an ho-listic standpoint addressing not only the functional requirements as needs, expectations, ob-jectives, but also addresses the needed advancements by covering state-of-the-art and state-of-the-practice gaps. Additionally, since the nIoVe solution focuses on security and privacy by design, we also covered the legal and regulatory aspects and identified related requirements which will later be considered in the design and development of the nIoVe solution.

S.Nr Source Type Number of Requirements

1 Needs 82

2 Objectives 26

3 Technology Constraints 2

4 State-of-the-art (SOTA) Gaps 7

5 Expectations 18

6 Laws and Regulations 3

Total Number of Elicited Requirements 138

Table 9 - Summary of Elicited nIoVe Requirements The requirements elicitation study done for the nIoVe project indicates that a major set of requirements stem from the stakeholder needs and objectives, as shown in Table 9 and Figure 4, which shows the novice state of available IoV solutions. The nIoVe project is therefore ex-pected to play a significant role in addressing the stakeholder needs and requirements. The requirements elicited due to technology constraints and SOTA gaps is relatively small in num-ber which indicates the maturity of technology; however, such technological advancements are yet to be exploited in the IoV domain as also represented by the expectations of the stake-holders. Finally, there are few but critically more important legal and regulatory requirements which will be addressed in the design and development of the nIoVe solution.

Figure 4 - Sources of Elicited Requirements


7 Bibliography

[1] Yan F., Shangguang W., Jinglin Li et al. (2014). An overview of internet of vehicles. China communications, 11 (10), pp. 1-15.

[2] Gerla M., Eun-Kyu L., Giovanni P., Uichin L. (2014). Internet of vehicles: From in-telligent grid to autonomous cars and vehicular clouds. In Internet of Things (WF-IoT), IEEE World Forum on, pp. 241-246.

[3] Lu N., Cheng N., Zhang N., et al. (2014). Connected vehicles: Solutions and chal-lenges. IEEE Internet of Things Journal, 1(4), 289-299.

[4] Kohler W.J., Colbert-Taylor, (2014). A. Current law and potential legal issues per-taining to automated, autonomous and connected vehicles. St. Clara Comput. High Technol. Law J.

[5] IIBA, K.B., (2009). A Guide to the Business Analysis Body of Knowledge. Interna-tional Institute of Business Analysis.

[6] Christel, Michael and Kyo C. Kang, (1992). "Issues in Requirements Elicitation". Technical Report CMU/SEI-92-TR-012. CMU / SEI. Retrieved January 14, 2012

[7] Ian Sommerville and Pete Sawyer. (1997). Requirements Engineering: A Good Prac-tice Guide (1st ed.). John Wiley & Sons, Inc., New York, NY, USA.

[8] Ian F. Alexander, Ljerka Beus-Dukic, (2009). Discovering Requirements: How to Specify Products and Services.

[9] https://www.ftc.gov/system/files/documents/public_coments/2017/11/00046-141905.pdf

[10] https://arxiv.org/pdf/1807.05720.pdf

[11] https://www.gsc-europa.eu/system/files/galileo_documents/Road-Report-on-User-Needs-and-Requirements-v1.0.pdf p. 21

[12] Halimaton Hakimi, Massila Kamalrudin, Safiah Sidek, Suriati Akmal. Trust Re-quirements Model for Developing Acceptable Autonomous Car. Journal of Electrical and Electronic Engineering. Vol. 6, No. 2, 2018, pp. 59-64. doi: 10.11648/j.jeee.20180602.14 page 60

[13] https://www.enisa.europa.eu/publications/cyber-security-and-resilience-of-smart-cars

[14] https://eugdpr.org/the-regulation/

[15] Regulation, G. D. P. (2016). Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46. Official Journal of the European Union (OJ), 59(1-88), 294

[16] Kosba, A., Miller, A., Shi, E., Wen, Z., & Papamanthou, C. (2016, May). Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. In 2016 IEEE symposium on security and privacy (SP) (pp. 839-858). IEEE.

[17] Puthal, D., Malik, N., Mohanty, S. P., Kougianos, E., & Das, G. (2018). Everything you wanted to know about the blockchain: Its promise, components, processes, and problems. IEEE Consumer Electronics Magazine, 7(4), 6-14.


[18] Jiang, T., Fang, H., & Wang, H. (2018). Blockchain-based internet of vehicles: Dis-tributed network architecture and performance analysis. IEEE Internet of Things Jour-nal.

[19] Lenz, R. (2019). Managing Distributed Ledgers: Blockchain and Beyond. Available at SSRN 3360655.

[20] Fernández-Caramés, T. M., & Fraga-Lamas, P. (2018). A Review on the Use of Blockchain for the Internet of Things. IEEE Access, 6, 32979-33001.

[21] Wohrer, M., & Zdun, U. (2018, March). Smart contracts: security patterns in the ethereum ecosystem and solidity. In 2018 International Workshop on Blockchain Ori-ented Software Engineering (IWBOSE) (pp. 2-8). IEEE.

[22] Inayat, Z., Gani, A., Anuar, N. B., Khan, M. K., & Anwar, S. (2016). Intrusion re-sponse systems: Foundations, design, and challenges. Journal of Network and Com-puter Applications, 62, 53-74.

[23] Kurra, K., Panda, B., Li, W. N., & Hu, Y. (2015, January). An Agent based approach to perform damage assessment and recovery efficiently after a cyber attack to ensure E-government database security. In 2015 48th Hawaii International Conference on Sys-tem Sciences (pp. 2272-2279). IEEE.

[24] https://www.etsi.org/newsroom/news/753-2014-02-joint-news-cen-and-etsi-deliver-first-set-of-standards-for-cooperative-intelligent-transport-systems-c-its

[25] CYBER; Cyber Security for Consumer Internet of Things. https://www.etsi.org/de-liver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf

The Framework Programme for Research & Innovation ...

Documents

Transcript of The Framework Programme for Research & Innovation ...