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
July 2019 2 WP Leader: RISE
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
July 2019 3 WP Leader: RISE
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
July 2019 4 WP Leader: RISE
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
July 2019 5 WP Leader: RISE
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.
July 2019 6 WP Leader: RISE
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
July 2019 7 WP Leader: RISE
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
July 2019 8 WP Leader: RISE
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
July 2019 9 WP Leader: RISE
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.
July 2019 10 WP Leader: RISE
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
July 2019 11 WP Leader: RISE
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.
July 2019 12 WP Leader: RISE
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
July 2019 13 WP Leader: RISE
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.
July 2019 14 WP Leader: RISE
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
July 2019 15 WP Leader: RISE
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.
July 2019 16 WP Leader: RISE
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.
July 2019 17 WP Leader: RISE
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
July 2019 18 WP Leader: RISE
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.
July 2019 19 WP Leader: RISE
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:
Req. ID Requirement Title Type Description
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
July 2019 20 WP Leader: RISE
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
July 2019 21 WP Leader: RISE
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:
Req. ID Requirement Title Type Description
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.
July 2019 22 WP Leader: RISE
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
July 2019 23 WP Leader: RISE
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.
July 2019 24 WP Leader: RISE
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:
Req. ID Requirement Title Type Description
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
July 2019 25 WP Leader: RISE
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
July 2019 26 WP Leader: RISE
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
July 2019 27 WP Leader: RISE
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.
July 2019 28 WP Leader: RISE
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].
Req. ID Requirement Title Type Description
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
July 2019 29 WP Leader: RISE
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
July 2019 30 WP Leader: RISE
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
July 2019 31 WP Leader: RISE
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):
Req. ID Requirement Title Type Description
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
July 2019 32 WP Leader: RISE
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
July 2019 33 WP Leader: RISE
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
July 2019 34 WP Leader: RISE
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.
Req. ID Requirement Title Type Description
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
July 2019 35 WP Leader: RISE
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
July 2019 36 WP Leader: RISE
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.
July 2019 37 WP Leader: RISE
[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
Top Related