Specifications iVRI Architecture, iVRI Security
Datum besluit SC 13-10-2016
D3047-3 / Version 1.1
D3047-3 / Version 1.1
Disclaimer (NL):
Bij het gebruik en toepassen van de Landelijke iVRI standaarden is en blijft de gebruiker, te weten de wegbeheerder respectievelijk opdrachtnemer van de wegbeheerder, zelf aansprakelijk voor de mogelijke risicos die ontstaan of kunnen ontstaan uit het aanbieden of laten aanbieden van (combinaties van) diensten en producten die conform deze standaarden werken in de eigen organisatie of elders in de keten waarvoor de wegbeheerder verantwoordelijk is. Dit geldt in het bijzonder ten aanzien van het verzamelen, opslaan en delen van gegevens en meer specifiek indien daar waar al dan niet direct of indirect herleidbare persoonsgegevens worden verwerkt op grond van de AVG. Gebruikers zijn zelf verantwoordelijk om bij het gebruik van de standaarden telkens na te gaan of gebruik van standaarden, dan wel de combinatie van data vanuit de standaarden in de basis voldoet aan de wet- en regelgeving, in het bijzonder de AVG. Het gebruik conform de standaarden kan het risico op aansprakelijkheid van de wegbeheerder verkleinen, maar niet altijd wegnemen of geheel uitsluiten. Dit is mede afhankelijk van de wijze waarop de wegbeheerder zelf in haar eigen organisatie of bij gebruik van opdrachtnemers in de keten de data verwerkt en gebruikt. Het is dan ook een dringend advies zowel voorafgaand aan de implementatie en ingebruikname door de gebruiker van de standaarden als periodiek een risico-analyse (zoals Data Protection Impact Assessment (DPIA)) en controle van de keten op het gebruik van de standaarden en bijkomende individuele risico s bij de wegbeheerder en haar opdrachtnemers uit te laten voeren. Het doel van dergelijke analyses en controles is dat mogelijke risico s die onbedoeld kunnen optreden op voorhand gedentificeerd kunnen worden, zodat de wegbeheerder zelf de nodige beheersmaatregelen kan treffen om (alsnog) aan de wettelijke voorschriften te kunnen voldoen. CROW en de opstellers van de standaarden hebben deze documenten met de grootst mogelijke zorg en met aandacht opgesteld, maar kunnen geen aansprakelijkheid aanvaarden voor een mogelijke overtreding van wet- en regelgeving door de wegbeheerder respectievelijk opdrachtnemer van de wegbeheerder, door te verwijzen naar de standaarden als oorzaak van een mogelijke overtreding van de AVG of andere wettelijke voorschriften. CROW en de opstellers van de standaarden wijzen derhalve een aansprakelijkheid door gebruikers ten aanzien van het gebruik van de standaarden Landelijke iVRI standaarden van de hand.
Disclaimer (EN):
When using and applying the Landelijke iVRI standaarden the end user, being the road authority or its principal, remains solely responsible for the possible risks that emerge or can emerge from the provision of services and products that operate by these standards, either within the own organisation or elsewhere in the chain of the road authoritys responsibility. This especially applies to the activities where data is gathered, stored and shared, and more specifically in cases where, be it directly or by inference, private data of individuals are processed, based on the GDPR and/or its national implementation. The user of these standards are themselves responsible for ascertaining that either the use of these standards, or the combination of data that is processed from applying these standards, are legal, especially in terms of the GDPR and/or its national implementation. The use of these standards can reduce the risks for liability of road users, but they can not eliminate these risks; the beforementioned risks of violating privacy legislation are mainly dependent on the way in wicht the road authority uses and processes the data within the own organisation and in relation to contractors within the chain of responsibility. It is urgently advised that, not alone when preparing a project, but also when implementing and operating a service or product, the road authority performs a periodic risk analysis (like a Data Protection Impact Assessment (DPIA)) and a check on the whole chain of information in terms of compliance to standards and additional individual risks on behalf of the road authority and its contractors. The purpose of these analyses and checks is to identify the possible risks beforehand, in order to take preventive and controlling measures, so that the road authority (eventually) is compliant to the legal framework that is applicable. CROW and the authors of these standards have created this document with the utmost care, but will not accept liability for a possible violation of any legislation by the road authority or its contractors by referring to these standards as the root cause of a possible violation of the GDPR, its national implementation or any other legal prescription. CROW and the authors of the Landelijke iVRI standaarden therefore explicitly waive all responsibility for the use of these standards.
Voorwoord
In mei 2016 is opdracht verstrekt door het Ministerie van Infrastructuur en Milieu via het Beter Benutten Vervolg (BBV) programma aan vijf VRA leveranciers om de in fase 1 opgeleverde iVRI architectuur, te bouwen en te testen in samenwerking met applicatiebouwers.
Dit document vormt Deliverable 1d van de afgesproken leverdelen in de opdrachtverstrekking en beschrijft de security requirements voor de ITS applicatie, de TLC en de RIS.
Dit document is tot stand gekomen door samenwerking van de vijf leveranciers in de werkgroep bestaande uit:
| Koos van Vliet | |
| Edwin Henning | |
| Eddy Verhoeven Hans Looijen | |
| Jaap Zee | |
| Wim Nouwens Michel Huisman |
NB. De rest van dit document is geschreven in het Engels om internationale uitwisseling te ondersteunen.
The rest of this deliverable has been written in English to facilitate international exchange.
Publication level: Public
Version filename: iVRI2_deliverable_1d IRS security v1.1.docx
Contents
1 – Introduction
1.1 – System overview
1.2 – Document overview
1.2.1 – Purpose
1.2.2 – Document structure
1.3 – Advise for the reader
1.1 – System overview
1.2 – Document overview
1.2.1 – Purpose
1.2.2 – Document structure
1.3 – Advise for the reader
2 – References
2.1 – Normative
2.2 – Informative
2.1 – Normative
2.2 – Informative
3 – Acronyms, abbreviations and concepts
4 – Security context
4.1 – Cyber security Best practices
4.2 – Private network
4.3 – Devices on the private network
4.4 – Temporary devices on the private network
4.5 – Data exchange with devices outside the private network
4.6 – Security matrix
4.7 – Authentication
4.8 – Cryptography
4.9 – Certificates
4.1 – Cyber security Best practices
4.2 – Private network
4.3 – Devices on the private network
4.4 – Temporary devices on the private network
4.5 – Data exchange with devices outside the private network
4.6 – Security matrix
4.7 – Authentication
4.8 – Cryptography
4.9 – Certificates
5 – Requirements
5.1 – Introduction
5.1.1 – Requirement notation format
5.2 – General requirements
5.3 – Traffic Light Controller (TLC)
5.4 – Roadside ITS station (RIS)
5.5 – ITS application
5.1 – Introduction
5.1.1 – Requirement notation format
5.2 – General requirements
5.3 – Traffic Light Controller (TLC)
5.4 – Roadside ITS station (RIS)
5.5 – ITS application
Appendix 1. Requirements overview
1 Introduction
This document describes the security requirements of the iTLC. In this chapter, a brief system overview will be given. See [Ref 3] for a detailed architecture description.
1.1 System overview
The iTLC architecture defines several interfaces of the iTLC. Figure1 shows these interfaces.
[ link ]
Figure1 System overview
1.2 Document overview
Purpose
This document provides specifications of the security requirements of the iTLC architecture.
Document structure
Chapter 2 contains references to normative and informative documents.
Chapter 3 explains acronyms and used definitions and concepts.
Chapter 4 outlines the security context.
Chapter 5 contains formal security requirements.
Chapter 3 explains acronyms and used definitions and concepts.
Chapter 4 outlines the security context.
Chapter 5 contains formal security requirements.
1.3 Advise for the reader
It is advised that the reader has taken knowledge of the iTLC Architecture as described in [Ref 3].
It is advised that the reader has a general understanding of cybersecurity also known as computer security1).
2 References
2.1 Normative
ID Reference
ETSI EN 302895, V1.1.1
CEN ISO/TS 18750:2015
Beter Benutten Vervolg, project iVRI , Deliverable F, iTLC Architecture , v1 .2
SAE-J2735, Dedicated Short Range Communications (DSRC) Message Set Dictionary, SAE International - 2015-09
ISO/TS 19321:2015
ETSI EN 302 637-2 V1.3.2 (2014-11)
ETSI EN 302 637-3 V1.2.2 (2014-11)
RFC7525 2) , May 2015
2.2 Informative
ID Reference
ETSI EN 302 665, V1.1.1
ETSI TS 102 894-2, V1.2.1
Rapportage onderzoek juridische inbedding Spookfiles A58 3) , December 2014
WaterISAC 4) , 10 Basic Cybersecurity Measures, June 2015.
Beter Benutten Vervolg , project iVRI Deliverable H2: iVRI Security & Safety matrix, version 1.2
3 Acronyms, abbreviations and concepts
Acronyms and abbreviations
| CEN | European Committee for Standardization |
| C-ITS | Cooperative ITS functionality for exchange of data between in-vehicle and or road side devices making use of either cellular or short range wireless communication |
| ETSI | European Telecommunications Standards Institute |
| FAT | Factory Acceptance Test |
| IDD | Interface Design Description |
| IRS | Interface Requirements Specification |
| ISO | International Organization for Standardization |
| iTLC (Dutch iVRI) | Intelligent TLC performing traffic light controller and C-ITS functions and providing access to these functions for ITS applications |
| ITS | Intelligent Transport Systems |
| ITS Station | Functional entity specified by the ITS station reference architecture (see ETSI EN 302 665, V1.1.1) |
| IVERA | Management protocol for traffic light controllers in the Netherlands |
| IVERA-APP | Management protocol for ITS applications. |
| IVERA-TLC | Management protocol supported by the RLC Facilities. |
| LAN | Local Area Network |
| PKI | Public Key Infrastructure |
| PoE | Power over Ethernet |
| RIS | See R-ITS-S |
| RIS-FI | R-ITS-S Facilities Interface |
| R-ITS-S | Roadside ITS Station, responsible for C-ITS functionality within a geographical area. |
| SAT | Site Acceptance Test |
| TLC | Traffic Light Controller; controls the signal of one or more intersections |
| TLC-FI | Traffic Light Controller Facilities Interface |
| TLS | Transport Layer Security |
| VLOG | Traffic Data log |
| VPN | Virtual Private Network |
| WAN | Wide Area Network |
Concepts
| ITS Control Application | A Traffic Control Application which uses TLC- and/or RIS-interfaces |
| ITS Application | An application which supports one or more ITS use-cases. Range of possible ITS Applications include an ITS Control Application |
| RIS Facilities | Component providing RIS Facilities to users (internal and/or external). Includes amongst others:
|
| TLC Facilities | Component providing facilities of a TLC to users (internal and/or external). Includes amongst others:
|
4 Security context
The aim of iTLC is an open eco-system, standardized interfaces and clearly defined behaviour, allowing ITS applications to reside inside a roadside cabinet or in the cloud. To facilitate this open eco-system security has to be integral to the design ( security by design).
This chapter outlines the security context of the iTLC and outlines the assumptions for the network in which the iTLC components are located.
4.1 Cyber security Best practices
Listed below are best practices regarding cyber security to reduce exploitable weaknesses and attacks on control networks. Please refer to the original article [Ref 12] for more information.
- Maintain an accurate inventory of control system devices and eliminate any exposure of this equipment to external networks;
- Implement network segmentation and apply Firewalls;
- Use secure remote access methods;
- Establish role-based access controls and implement system logging;
- Use only strong passwords, change default passwords, and consider other access controls;
- Maintain awareness of vulnerabilities and implement necessary patches and updates;
- Develop and enforce policies on mobile devices;
- Implement an employee Cybersecurity training program;
- Involve executives in Cybersecurity;
- Implement measures for detecting compromises and develop a Cybersecurity incident response plan.
4.2 Private network
The security requirements in this document are based on a system setup where the components of the iTLC architecture are located on a private network used for monitoring and controlling devices (IRS_SEC_GEN_001). The private network could spread across a city or an entire province and can be used to control and monitor a wide variety of objects (i.e. the network is not restricted to iTLC s only).
The assumption is made that the network is designed and maintained by a network administrator in accordance with the best practices outlined above, recognizing that a network administrator may have its own cybersecurity policy and best practices.
The network architecture and security measures for this (private) network are out of scope for this specification.
[ link ]
Figure 2 Private network overview
The figure shows several examples of connecting iTLC components to the private network:
- The ITS application is hosted in the network and the TLC and RIS are located in the roadside cabinet [1].
- All components are located inside the roadside cabinet [2]. Access to the iTLC components from the network can be restricted by an optional firewall integrated in the roadside cabinet.
- The RIS or another device (connected to the LAN) is located outside the roadside cabinet [3]
- A RIS using its own roadside cabinet [not shown].
4.3 Devices on the private network
The list below outlines the typical methods for connecting devices to the private network:
- Connect a device to the LAN inside a roadside cabinet using an available network connector.
- Connect a device to the LAN inside a server room using an available network connector.
- Connect a device using a VPN (i.e. remote access by extending the private network across a public network or the internet).
- Connect a device to a network connector outside the roadside cabinet. For example, a Power over Ethernet connector for interfacing with a pole mounted device.
- Connect a device via a Wifi access point located inside a roadside cabinet or placed near a roadside cabinet.
Best practice: Maintain an accurate inventory of the devices on the private network.
4.4 Temporary devices on the private network
A device in this context can be a service laptop or another device used for diagnostic or maintenance. The list outlines typical methods for connecting temporary devices to the private network:
- Connect a device to the LAN inside a roadside cabinet using an available network connector.
- After opening the main cabinet door.
- After opening the police panel door.
- Connect a device to the LAN inside a server room using an available network connector.
- Connect a device using a VPN (i.e. remote access by extending the private network across a public network or the internet).
- Connect a device via a Wifi access point located inside a roadside cabinet or placed near a roadside cabinet.
Best practice: Develop and enforce policies on mobile devices.
4.5 Data exchange with devices outside the private network
Data is exchanged in a controlled manner with devices outside the private network. In a typical network there will be:
- Centre-to-Centre data exchange (for example a link to the National Data Warehouse5) Nationale Databank Weg en verkeersgegevens) using a gateway.
- Exchange of ETSI messages between the Roadside-ITS-Station and vehicles (i.e. ETSI messages via the RIS Wifi-p (IEEE802.11p) interface.).
Best practice: Eliminate any exposure of control devices to external networks.
4.6 Security matrix
In iVRI phase 1 a security and safety analysis has been conducted on this open eco-system and mitigating actions have been identified. The results are documented in [Ref 13].
Listed below are identified security threats. The mitigation actions for these threats are addressed in the requirements in this document. The threats are sorted by risk (impact * probability). The list contains all threats with a risk >= 15 and a selection of the threats with a lower risk.
| # | Threats | Impact | Probability |
| A1 | Unauthorized persons that have direct or indirect (via applications) access to the iTLC. | 5 | 5 |
| A2 | Authentication information becomes public due to irresponsible behavior of people. | 5 | 5 |
| A3 | Cryptographic methods become outdated and are not being updated | 4 | 5 |
| A4 | Incorrect permissions | 5 | 3 |
| A5 | Unauthorized physical access to the system or network | 5 | 3 |
| A6 | ITS G5 messages not signed | 3 | 5 |
| A7 | Unworkable situation (impact on daily workflow) due to tight security measures, leads to bypasses of the security. | 5 | 3 |
| A8 | Too many and complex security measures lead to incorrect implementation of the security measures. | 5 | 3 |
| A9 | Security settings are not correctly configured/implemented, leading to lower security or even disabled security. | 5 | 3 |
| A10 | ITS application cannot access TLC facilities or the RIS facilities. | 5 | 3 |
| A11 | Theft of the security settings, to be used later for unauthorized access. | 5 | 2 |
| A12 | Security measures are not tested during development. | 3 | 3 |
| A13 | Brute force attack may disable a user account. | 3 | 2 |
4.7 Authentication
The iVRI security is based on username/password (i.e. what you know). All - standardized and manufacturer specific - network interfaces of iTLC components shall be secured with a username/password as a minimum.
Each iTLC component has a management interface, allowing the users to be managed centrally by the network administrator.
Transport Layer Security (TLS) allows the ITS client to verify the identity of the TLC facilities or RIS facilities.
Note: More enhanced authentication methods based on something you have (like a token) or even more sophisticated ( something you are ) are outside the scope of this document.
Note: In a setup without TLS the system is sensitive to a man-in-the-middle-attack as the ITS application cannot authenticate the TLC Facilities and/or the RIS Facilities.
4.8 Cryptography
Transport Layer Security (TLS) is selected as a standard security measure on TLC-FI, RIS-FI, IVERA-TLC and IVERA-APP. TLS is strongly advised on all6) VLOG3 is an output only stream without encryption . other network interfaces of the components of the iVRI architecture.
(TLS) and its predecessor, Secure Sockets Layer (SSL), both of which are frequently referred to as 'SSL', are cryptographic protocols that provide communications security over a computer network. Major web sites use TLS to secure all communications between their servers and web browsers. The primary goal of the Transport Layer Security protocol is to provide privacy and data integrity between two communicating computer applications 7) Source : .
Note: In a setup without TLS the system is sensitive eavesdropping.
4.9 Certificates
As a consequences of choosing TLS, a public key infrastructure (PKI) is necessary for a client to authenticate a server (e.g. authentication of the TLC facility by an ITS application).
The public key infrastructure (PKI) is out of the scope for this specification.
Note 8) Source: : A public key infrastructure (PKI) is a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.
5 Requirements
5.1 Introduction
This chapter contains security requirements of the iTLC-architecture as described in [Ref 3] and depicted in Figure 1.
Requirement notation format
The following format is used to define a requirement:
| Req-ID | IRS-x-y-zzz |
| Title | |
| Description | |
| Source | |
| Comment |
- Req-ID: unique identification of the requirement according to the following format: IRS-x-y-zzz , where x is an identifier for the interface, y is a textual tag and zzz is a number of the requirement.
- Title: a short description of the requirement
- Description: formal and detailed description of the requirement.
- Source: reference to a source document used as input for the requirement.
- Comment: optional clarification of the requirement.
5.2 General requirements
The following requirements are applicable to security in general.
| Req-ID | IRS_SEC_GEN_001 |
| Title | Private network ( Secure bubble) |
| Description | The iTLC components, using the socket based TLC-FI and RIS-FI interfaces, shall be on a private network, managed by a network administrator, in accordance with cybersecurity best practices. |
| Source | Threat A1 |
| Comment | The first line of defence is the access to the private network, both for systems and users. |
| Req-ID | IRS_SEC_GEN_002 |
| Title | Road side cabinet locks |
| Description | Roadside cabinets shall have locks and the keys shall be managed. |
| Source | Threat A5 |
| Comment | People that have access to a roadside cabinet also have physical access to the network and can connect devices to the network. |
| Req-ID | IRS_SEC_GEN_003 |
| Title | Alarm when roadside cabinet door is opened (optional for legacy controllers) |
| Description | When a roadside cabinet door is opened, an alarm shall be raised. The alarm shall be forwarded to the traffic management system (TMS) as an IVERA trigger event.
|
| Source | Threat A5 |
| Comment | Legacy controllers may not have door contacts on all three doors. In the Traffic Management System the IVERA trigger event could be linked to a planned action by an authorized field engineer. |
| Req-ID | IRS_SEC_GEN_004 |
| Title | Authentication |
| Description | A system or user shall authenticate itself using username and password when establishing any connection with an iTLC component (ITS application, TLC or RIS). |
| Source | Threat A1 |
| Comment | Authentication: The act of verifying the identity of an entity (subject). |
| Req-ID | IRS_SEC_GEN_005 |
| Title | Role based authorization |
| Description | A system or user shall be assigned a role, giving the system or user access to a predefined set of resources (objects) in the iTLC component. |
| Source | Threat A4, Best practice 4. |
| Comment | Authorization: The act of determining whether a requesting entity (subject) will be allowed access to a resource (object). |
| Req-ID | IRS_SEC_GEN_006 |
| Title | Auditing |
| Description | A iTLC component (ITS application, TLC Facilities or RIS Facilities) shall keep a security audit log, including at least the following events:
|
| Source | Threat A1, A4 |
| Comment | Logging access (including attempts to access) to the network interfaces of the components. |
| Req-ID | IRS_SEC_GEN_007 |
| Title | Local (wired and wireless) networks. |
| Description | Local (wired and wireless) networks that reach outside the road side cabinet shall be protected to prevent illegal access to the private network. The supplier of the local network shall perform a security analysis and provide proof that the local network meets the security requirements set by the network administrator. |
| Source | Threat A1, A5 |
| Comment | Take for example a pole mounted device with a Power over Ethernet (PoE) connection. Another example is a wifi network between devices on the street. These interfaces could be exploited to obtain access to the network. An example of a local network is depicted below. In the example the TLC uses a separate (local) network for connecting devices to the TLC. |
| Req-ID | IRS_SEC_GEN_009 |
| Title | User management |
| Description | An iTLC component (ITS application, TLC or RIS) shall have a management interface for user management.
User management shall be restricted to users with administrator rights. |
| Source | Threat A2 |
| Comment | This setup allows the user management from a central location, giving the network administrator the possibility to implement a scheme for managing users. Examples of schemes are:
It is advised to separate user management from functional or technical management. |
| Req-ID | IRS_SEC_GEN_013 |
| Title | Transport Layer Security (TLS) |
| Description | During the lifetime of equipment, the vendor should keep track of any systems not adhering to best practices as documented in RFC7525 [Ref 8]. |
| Source | Threat A3 |
| Comment | Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. Because of these attacks, those who implement and deploy TLS need updated guidance on how TLS can be used securely. |
| Req-ID | IRS_SEC_GEN_014 |
| Title | Product Development |
| Description | The security measures shall be tested prior to releasing a product or new product release for operational use. The supplier shall provide test results on request of the network administrator (i.e. the client). |
| Source | Threat A12 |
| Comment |
| Req-ID | IRS_SEC_GEN_015 |
| Title | Site Acceptance Testing |
| Description | The security measures shall be verified during a SAT. This shall be a mandatory item on the SAT checklist. |
| Source | Threat A9 |
| Comment | Default username/passwords are typically used for testing prior to the SAT. During the SAT the final usernames/passwords are configured. |
| Req-ID | IRS_SEC_GEN_016 |
| Title | Periodic security check |
| Description | The security measures shall be periodically verified in accordance with the security policy set for the private network. |
| Source | Threat A3, A9 |
| Comment | This is the responsibility of the network administrator. |
| Req-ID | IRS_SEC_GEN_017 |
| Title | Storing of security settings |
| Description | The security settings shall be securely stored in the iTLC components. More specific:
|
| Source | Threat A2, A11 |
| Comment |
| Req-ID | IRS_SEC_GEN_018 |
| Title | Strong passwords |
| Description | The iTLC components (TLC Facilities, RIS Facilities and ITS applications) shall support strong passwords with a maximum length of 32 characters. A strong password is characterised by a minimal length, use of letters, digits and punctuation and is not sensitive to dictionary attack. Punctuation characters are restricted to the punctuation characters supported by IVERA-TLC and IVERA-APP. |
| Source | |
| Comment | A static strong password is considered safer than passwords that should be modified periodically. |
5.3 Traffic Light Controller (TLC)
The following requirements are applicable to the security of the TLC.
| Req-ID | IRS_SEC_TLC_001 |
| Title | TLC-FI Authentication & Authorization |
| Description | An ITS client using TLC-FI shall be authenticated based on username and password. The ITS client shall be assigned a role (A Control, Provider or Consumer application). Access to the TLC resources shall be restricted based on the assigned role. |
| Source | Threat A1, A4 |
| Comment |
| Req-ID | IRS_SEC_TLC_003 |
| Title | TLC-FI + TLS |
| Description | The TLC facilities shall support Transport Layer Security (TLS) on the TLC-FI interface, in accordance with the best practices document in RFC7525. |
| Source | Threat A1, A5 |
| Comment | This is the mandatory security setup: Restricted access to the private network User authentication and authorization on the TLC-FI interface. The ITS application can verify the identity of the TLC based on the provided (digital) certificate. The communication between the ITS application and the TLC facilities is encrypted. |
| Req-ID | IRS_SEC_TLC_004 |
| Title | IVERA-TLC Authentication & Authorization |
| Description | A client using IVERA-TLC shall be authenticated based on username and password. The client shall be assigned a role. Access to the TLC resources (objects) shall be restricted based on the assigned role. |
| Source | Threat A1, A4, IRS_SEC_GEN_004, IRS_SEC_GEN_005 |
| Comment | The current IVERA pin code is deemed insufficient protection, especially since users and passwords are being managed using the IVERA-TLC interface. The login using a pin-code should be removed and replaced by a login using username and password, including objects to manage the users and passwords. The roles are defined in the IVERA specification. |
| Req-ID | IRS_SEC_TLC_005 |
| Title | IVERA-TLC + TLS |
| Description | The TLC facilities shall support Transport Layer Security (TLS) on the IVERA-TLC interface in accordance with the best practices documented in RFC7525. |
| Source | |
| Comment | This is the standard security setup providing the following security: Restricted access to the private network User authentication and authorization on the IVERA-TLC interface. The client can verify the identity of the TLC based on the provided (digital) certificate. The communication between the client and the TLC is encrypted. |
| Req-ID | IRS_SEC_TLC_005a |
| Title | IVERA-TLC without TLS for legacy TLC |
| Description | A legacy TLC that cannot support TLS shall support IVERA-TLC without TLS. |
| Source | |
| Comment |
| Req-ID | IRS_SEC_TLC_006 |
| Title | Other TLC interfaces |
| Description | The manufacturer of the TLC shall provide a consolidated overview of the network interfaces of the TLC and the supported protocols, allowing the security risk of the equipment to be assessed. The network administrator may request a manufacturer to disable specific network interfaces due to the security risks associated to these network interfaces. |
| Source | Threat A1 |
| Comment | The TLC can have other network interfaces like web pages, telnet, ftp, etc. Especially on legacy TLC s it may not be possible to bring all interfaces up to date with the latest security requirements. Basically the road authority together with the supplier of the legacy equipment has one of the following choices:
|
| Req-ID | IRS_SEC_TLC_007a |
| Title | User management TLC-FI |
| Description | The IVERA-TLC interface shall support the management of the TLC-FI users. |
| Source | IRS_SEC_GEN_009 |
| Comment | |
| Req-ID | IRS_SEC_TLC_007b |
| Title | User management IVERA-TLC |
| Description | The IVERA-TLC interface shall support the management of the IVERA-TLC users. |
| Source | IRS_SEC_GEN_009 |
| Comment |
| Req-ID | IRS_SEC_TLC_007c |
| Title | User management File Transfer |
| Description | The IVERA-TLC interface shall support the management of users that are allowed to transfer files (upload/download files). |
| Source | IRS_SEC_GEN_009 |
| Comment | IVERA objects: FTPUSER.I, FTPPASS, FTPLOCATION. |
| Req-ID | IRS_SEC_TLC_007d |
| Title | User management other interfaces |
| Description | The TLC shall have an interface to manage the users of other network interfaces (i.e. network interfaces for which the user management is not supported by IVERA-TLC). |
| Source | IRS_SEC_GEN_009 |
| Comment | Think about interfaces like a secure shell or an integrated web server. The preferred option is to define manufacturer specific IVERA objects (like XSSHUSER.I, etc). Another option is a web interface for managing the users. |
| Req-ID | IRS_SEC_TLC_008 |
| Title | Unique usernames |
| Description | Each entity of an ITS application shall have a unique username. The TLC facilities shall not accept a connection from an ITS application if there is already a connection with an ITS application with the same username. |
| Source | Threat A4 |
| Comment | Prevent multiple ITS applications to setup concurrent TLC-FI connections using the same username. An event in the security audit can be linked to a specific entity. |
| Req-ID | IRS_SEC_TLC_009 |
| Title | Security audit log |
| Description | The IVERA datacom events (6xxx) shall be used for the security audit logging. |
| Source | IRS_SEC_GEN_006 |
| Comment |
5.4 Roadside ITS station (RIS)
The following requirements are applicable to the security of the RIS
| Req-ID | IRS_SEC_RIS_001 |
| Title | RIS-FI Authentication & Authorization |
| Description | An ITS client using RIS-FI shall be authenticated based on username and password. The ITS client shall be assigned a role. Access to the RIS resources shall be restricted based on the assigned role. |
| Source | Threat A1, A4 |
| Comment | The roles are defined in the RIS-FI interface design description. |
| Req-ID | IRS_SEC_RIS_003 |
| Title | RIS-FI + TLS |
| Description | The RIS facilities shall support Transport Layer Security (TLS) on the RIS-FI interface, in accordance with the best practices outlined in RFC7525 [Ref 8]. |
| Source | Threat A1,A5 |
| Comment | This is the mandatory security setup providing the following security: Restricted access to the (virtual) private network User authentication and authorization on the RIS-FI interface. The ITS application can verify the identity of the RIS facilities based on the provided (digital) certificate. The communication between the ITS application and the RIS facilities is encrypted. |
| Req-ID | IRS_SEC_RIS_004 |
| Title | User management |
| Description | The RIS-MGMT interface shall support the management of users:
The RIS-MGMT interface shall be documented and available to third parties allowing the users to be managed centrally. |
| Source | |
| Comment | The RIS does not have a standardized management interface (like IVERA-TLC on the TLC). |
| Req-ID | IRS_SEC_RIS_005 |
| Title | RIS-MGMT + TLS (optional) |
| Description | The RIS shall support Transport Layer Security (TLS) on the RIS-MGMT interface, in accordance with the best practices outlined in RFC7525 [Ref 8]. |
| Source | Threat A1,A5 |
| Comment |
| Req-ID | IRS_SEC_RIS_006 |
| Title | Unique usernames |
| Description | Each entity of an ITS application shall have a unique username. The RIS facilities shall not accept a connection from an ITS application if there is already a connection with an ITS application with the same username. |
| Source | Threat A4 |
| Comment | Prevent multiple ITS applications to setup concurrent RIS-FI connections using the same username. An event in the security audit can be linked to a specific entity. |
| Req-ID | IRS_SEC_RIS_007 |
| Title | IEEE802.11p / Wifi-p |
| Description | It shall not be possible to access the private network via the Wifi-p interface of the RIS. The Wifi-p interface shall be restricted to exchanging ETSI message using the GeoNetworking protocol stack (i.e. only allow 802.11p frames with Ethertype 0x8947, according to http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml ) |
| Source | Threat A1, A5 |
| Comment | IPv6 and IPv4 shall be disabled on the Wifi-p interface of the RIS. |
5.5 ITS application
The following requirements are applicable to the security of the ITS applications.
| Req-ID | IRS_SEC_ITS_002 |
| Title | TLC-FI + TLS |
| Description | An ITS application shall support TLC-FI + TLS. |
| Source | IRS_SEC_TLC_003 |
| Comment | TLC-FI with mandatory security measures. |
| Req-ID | IRS_SEC_ITS_004 |
| Title | RIS-FI + TLS |
| Description | An ITS application shall support RIS-FI + TLS. |
| Source | IRS_SEC_RIS_002 |
| Comment | RIS-FI with mandatory security measures. |
| Req-ID | IRS_SEC_ITS_005 |
| Title | TLC-FI and RIS-FI management |
| Description | An ITS application shall provide an interface, allowing an administrator to configure the TLC-FI and/or RIS-FI connections.
|
| Source | |
| Comment | Support initial configuration and changes during the life span of the system. The interface could be a standardized interface like IVERA-APP (IRS_SEC_ITS_009a) or a manufacturer specific interface. |
| Req-ID | IRS_SEC_ITS_006 |
| Title | IVERA-APP Authentication & Authorization |
| Description | A client using IVERA-APP shall be authenticated based on username and password. The client shall be assigned a role. Access to the ITS application resources (objects) shall be restricted based on the assigned role. |
| Source | Threat A1, A4, IRS_SEC_GEN_004, IRS_SEC_GEN_005 |
| Comment | The current IVERA pin code is deemed insufficient protection, especially since users and passwords are being managed using the IVERA-APP interface. The login using a pin-code should be removed and replaced by a login using username and password, including objects to manage the users and passwords. The roles are defined in the IVERA specification. |
| Req-ID | IRS_SEC_ITS_007 |
| Title | IVERA-APP + TLS |
| Description | An ITS application shall support Transport Layer Security (TLS) on the IVERA-APP interface in accordance with the best practices documented in RFC7525. |
| Source | |
| Comment | This is the mandatory security setup providing the following security: Restricted access to the private network User authentication and authorization on the IVERA-APP interface. The client can verify the identity of the ITS application based on the provided (digital) certificate. The communication between the client and the ITS application is encrypted. |
| Req-ID | IRS_SEC_ITS_007a |
| Title | IVERA-APP without TLS in legacy TLC |
| Description | A legacy TLC that uses IVERA-APP to manage a backup application in the TLC shall use IVERA-APP without TLS, in case the TLC cannot support TLS. |
| Source | |
| Comment |
| Req-ID | IRS_SEC_ITS_008 |
| Title | Other ITS application interfaces |
| Description | The manufacturer of the ITS application shall provide a consolidated overview of the network interfaces of the ITS application and the supported protocols, allowing the security risk of the equipment to be assessed. The network administrator may request a manufacturer to disable specific network interfaces due to the security risks associated to these network interfaces. |
| Source | Threat A1 |
| Comment |
| Req-ID | IRS_SEC_ITS_009a |
| Title | User management TLC-FI and RIS-FI using IVERA-APP |
| Description | The IVERA-APP interface shall support the configuration the TLC-FI and/or RIS-FI connections.
|
| Source | IRS_SEC_ITS_005 |
| Comment |
| Req-ID | IRS_SEC_ITS_009b |
| Title | User management IVERA-APP |
| Description | The IVERA-APP interface shall support the management of the IVERA-APP users. |
| Source | IRS_SEC_GEN_009 |
| Comment |
| Req-ID | IRS_SEC_ITS_009c |
| Title | User management FTP |
| Description | The IVERA-APP interface shall support the management of users that are allowed to transfer files (upload/download). |
| Source | IRS_SEC_GEN_009 |
| Comment | IVERA objects: FTPUSER.I, FTPPASS, FTPLOCATION. |
| Req-ID | IRS_SEC_ITS_009d |
| Title | User management other interfaces |
| Description | An ITS application shall have an interface to manage the users of other network interfaces (i.e. network interfaces for which the user management is not supported by IVERA-APP). |
| Source | IRS_SEC_GEN_009 |
| Comment | Think about interfaces like a secure shell or an integrated web server. The preferred option is to define manufacturer specific IVERA objects (like XSSHUSER.I, etc). Another option is a web interface for managing the users. |
| Req-ID | IRS_SEC_ITS_010 |
| Title | Security audit log |
| Description | The IVERA datacom events (6xxx) shall be used for the security audit logging. |
| Source | IRS_SEC_GEN_006 |
| Comment |