Establishing the security requirements for a GNSS-based Train Localisation On-Board Unit (TLOBU)

Project scope and expected challenges

The purpose of the CLUG project is to establish the feasibility of novel certifiable localisation architectures and concepts using GNSS (Global Navigation Satellite System) in the railway environment. To this end, two on-board continuous and safe GNSS-based  localisation unit) proof of concepts are designed and tested. If their architectures essentially focus on meeting the stringent railway safety requirements, security is also expected to gain in importance in the coming years for the railway sector.

Such a security concern has already started at European Union level with the Network and Information System (NIS) Directive (July 2016). If this Directive focuses on Railway networks supporting the train signaling and control, it is expected that, in a near future, cybersecurity standards will emerge in relation with on-board electrical and electronic Railway systems as it has already happened in the Industrial Automation and Control Systems (IEC 62443) or the electrical and electronic (E/E) systems in road vehicles (ISO/SAE 21434).

The security analysis carried out in the frame of CLUG aims at anticipating the emergence of Railway cybersecurity standards and laying the foundations for the development of a secure and certifiable Train Localisation On Board Unit (TLOBU).

Identifying threats and vulnerabilities as an initial step:

Following an overview of the TLOBU architecture as well as a TLOBU threats and vulnerabilities identification, six top level threats have been studied for the CLUG TLOBU:

• T.1: TLOBU counterfeiting;
• T.2: TLOBU input services spoofing;
• T.3: Corrupted sensor measurements;
• T.4: Digital map database corruption;
• T.5: TLOBU output tampering;
• T.6: TLOBU denial of services.

The TLOBU risk assessment for these top-level threats has demonstrated that the spoofing and Denial of Service (DoS) threats are the most intolerable risks for the TLOBU. In addition, the counterfeiting as well as the TLOBU sensor corruption threats have been identified as undesirable risks that must also be mitigated by appropriate security measures.

Figure 1: Risk matrix representation of the top level TLOBU threats

Establishing TLOBU railway systems security requirements:

The security requirements established by the CLUG security report could contribute to the drafting of a Protection Profile specifying the security requirements for the designing of an operational security certified railway GNSS TLOBU.

Security requirements have been elaborated in order to mitigate or control the risk levels associated to the identified TLOBU threats. These security requirements take place at various layers of the TLOBU such that if one security protection fails, another can step up immediately (defence in depth concept). A total of six TLOBU layers have been considered during the elaboration of the security requirements:

• Standard, awareness and procedures (layer 1): refers to the standards to be applied when designing a secure TLOBU, the security awareness to be provided to the TLOBU users and administrators as well as the procedures to be elaborated in case of TLOBU security incident.
• TLOBU physical protection (layer 2): refers to the physical access controls as well as the stakeholders screening to be implemented for the physical protection of the TLOBU and its sensors.
• TLOBU perimeter (layer 3): refers to the sensors (IMU, odometer, balise reader) and services (GNSS, SBAS, TLOBU database updates) providing data as inputs to the TLOBU as well as the TLOBU data provided by the TLOBU output interface to the train systems.
• TLOBU hardware (layer 4): refers to the countermeasures required against identified TLOBU hardware threats.
• TLOBU software (layer 5): refers to the countermeasures required against identified TLOBU software threats.
• TLOBU memory (layer 6): refers to the protections required for the data stored within the TLOBU memory such as the digital map database.

Each of the identified security requirements has been associated to various security levels objectives (as defined in the IEC 62443 standard) for the TLOBU product to be developed in the future:

• SL1 – Initial: Few TLOBU security measures are in place or are not documented. The TLOBU provides good assurance level against casual or coincidental violations (threats identified as being certain).
• SL2 – Managed: intermediate security measures are in place and provide assurance against laymen with standard equipment and limited time to perform the attack (relates to likely and possible threats). The TLOBU is documented but the stakeholders do not always follow the best practices when interacting with the TLOBU.
• SL3 – Defined (practiced): good security measures are in place and provide assurance against proficient attackers with specialised equipment and weeks to perform the attack (unlikely threats). The TLOBU is documented and well used by the stakeholders.
• SL4 – Improving: strong security measures are in place and the TLOBU is documented and well used by the stakeholders. The TLOBU security programme is updated on a regular basis in order to improve governance and technical solutions. The security measures provide assurance against complex and remote threats.

Applying security requirements at each of the identified TLOBU defence layer should allow to reduce and control the risks associated to the identified threats at least at a tolerable level. However, even if the risk is considered as tolerable, the identified risks shall be monitored actively by the TLOBU stakeholders so that the countermeasures and protection means are always adapted to the TLOBU threats that are always evolving.

All these measures have been identified in our study but not implemented in the current prototype. Therefore, this identified work will be performed as complementary development in the future.