Skip to content

Introduction to ITS Cybersecurity

Welcome to the International Standards Organization (ISO) Guide Intelligent Transportation Systems (ITS) Cybersecurity. This website catalogues ITS-specific threats, standards and regulations, stakeholder responsibilities, and building blocks for engineering cybersecurity risk mitigations. If you are new to the concept of ITS cybersecurity, please first read our Beginners Guide.

You may also view the site glossary here.

An ITS consists of myriad devices, services and systems. The components that make up an ITS may be installed in fixed locations, or may be "on-the-move". Mobile ITS components may enter and leave policy domains frequently, resulting in the need for a dynamic trust model whereby trust is not provisioned between components a priori, but instead dynamically. The complexity of an ITS is well suited by the term "System of Systems (SoS)". The figure below illustrates some of the complexities associated with an ITS SoS.

ITS Environment

Within an ITS SoS, components such as Road Side Units (RSU), environmental sensors, and vehicle On Board Units (OBU), may be managed by different organizations. Each organization is responsible for maintaining their own cybersecurity policies and procedures. For example, an Original Equipment Manufacturer (OEM) may be responsible for distributing software updates to its brand of vehicles, a Fleet Manager may be responsible for monitoring the cybersecurity posture of its entire fleet, and a Municipal Infrastructure Owner Operator (IOO) may be responsible for managing the cybersecurity of all of it's domains' traffic signal controllers.

Given the quantity of stakeholders associated with designing, deploying and operating an ITS or the components that make up an ITS, there is a need for well-defined standards that collectively enable integrity, authenticity, availability and when needed confidentiality of data stored or transmitted. These standards define concepts such as secure message types, identity certificate formats, methods to anonymize data, authorization approaches, cross-trust mechanisms, and much more.

This website provides details on these topics, beginning with an inventory of patterns that can be used as building blocks for a trusted ITS architecture.

Start Here: Introduction to ITS Cybersecurity – A Beginner's Guide

Begin with this introductory guide to understand the basics of ITS Cybersecurity.

ITS Cybersecurity

1. Security Regulations, Frameworks, Standards and Guidance Documents

Organizations that develop or operate an ITS or ITS components must often demonstrate that they meet a minimum set of cybersecurity requirements. There are standards and frameworks available that define those minimum requirements. For example, an OEM that develops a connected vehicle may adhere to ISO/SAE 21434, while an IOO that operates an ITS may adhere to ISO/IEC 27001 or even National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) if based in North America. European organizations may also be required to adhere to regulations such as the EU Cyber Resilience Act or UNECE WP.19 R155. There are also technical standards that define how for example secure messaging should be developed and integrated into an ITS. These standards are defined by organizations such as the Society of Automotive Engineers (SAE), the Institute of Electrical and Electronics Engineers (IEEE) and others.

2. Performing an ITS Threat Analysis

Any organization that develops or operates an ITS or ITS components must understand their unique risk profile. A Threat, Vulnerability and Risk Assessment (TVRA) can be conducted to identify threats, quantify likelihood and impact (should the threat be realized), and assess risk.

In Europe, ETSI TR 102 893, provides a structured approach for assessing Cooperative-ITS (C-ITS) risk. European organizations that operate an ITS should also expect to conduct and maintain operational risk assessments in alignment with ISO/IEC 27005. In North America, the NIST Cybersecurity Framework and NIST SP800-30 provide a foundation for performing a comprehensive risk assessment. North American organizations may also find the ITS Cybersecurity Profile useful for understanding the threats that an ITS faces. The ITS Cybersecurity Profile is used in conjunction with multiple ITS Cybersecurity Control documents that each detail ways to mitigate risks to specific ITS product types: Dynamic Message Signs, Closed-Circuit Television cameras, RSUs and Advanced Traffic Controllers (ATC).

There are many different approaches for conducting a threat and risk assessment, but in general the process chosen should include documenting ITS system assets, communication data flows and trust boundaries and then assigning threats to each of these logical structures. From there, an estimate of the likelihood and impact of each specific threat to the ITS can be calculated, providing a way to prioritize the risks in a quantifiable and defendable manner. This allows cybersecurity executives within an ITS organization to prioritize the most appropriate cybersecurity processes, procedures and technologies, given the risk profile and operational context of the system.

3. ITS Cyber Security Patterns

Technology patterns provide a blueprint that describes how to design a capability in a repeatable manner. The ITS cybersecurity patterns in this section can be used by cybersecurity architects and engineers to efficiently implement specific security features and capabilities within an ITS. Patterns are categorized based on whether they apply to the management layer, application layer, device layer, network /transport layer, or to the secure development or deployment of an ITS. By referencing these patterns, implementers can identify the protections most relevant to their systems, ensure alignment with applicable trust models, and select implementation approaches that provide strong, scalable, and auditable mitigation of cybersecurity risk.

4. Interoperability Strategies

ITS interoperability focuses on the ability for vehicles, ITS devices and ITS services to be able to communicate with each other in a trusted manner. For example, an vehicle OBU from OEM A must be able to transmit a Basic Safety Message (BSM) and have that message be received and successfully processed by a vehicle OBU from OEM B, as well as by an RSU a different manufacturer, etc. This requires that interoperability be designed into ITS Standards that detail message fields and values, and that those message types be adopted by all participants within the ITS ecosystem.

Trust adds another layer of interoperability complexity. It is not sufficient for vehicles from OEM A to receive and process messages from OEM B and vice versa. OEM A's vehicles must be able to trust that the messages coming from vehicles produced by OEM B are authentic and integrity protected. This requires the use of a trusted third party, known as a Public Key Infrastructure (PKI). A PKI provider adheres to specific polices and procedures to ensure that any person, system or device that is issued a certificate, meets a minimum set of assurances and has sufficiently proven its identity. In the example above, vehicles from both OEM A and OEM B may be issued certificates by the same PKI, meaning that all vehicles operate within a single trust domain.

There are multiple PKI providers that server ITS's across the globe. This requires that there also be interoperability strategies put into place between the PKI providers themselves, to ensure that the trust associated with certificates issued by PKI Provider 1 is equivalent to the trust associated with certificates issued by PKI Provider n. One way to accomplish this is to ensure that the polices that each PKI provider operates by, are harmonized. Another method to accomplish this, is to engineer technical solutions. For example, in North America, IEEE 1609.2.2 (DRAFT) provides a mechanism whereby PKI Provider 1 establish conditional trust with PKI Provider 2, for example by allowing trust for BSMs but not for messages that request priority services.

5. Device and Application Security Policy Recommendations

ITS components operate in a range of contexts and environments. Oftentimes, devices are left unattended on the roadside. This may leave devices vulnerable to attacks that are made easier when the attacker has physical access. ITS vendors should provide their customers with the tools and information needed to securely configure and effectively lock down those devices. This section provides detailed configuration setting recommendations across a variety of categories, for example password management, user authentication, logging and encryption settings. The recommendations are based on established ITS guidance and can be applied across field devices, backend systems, and supporting applications to strengthen resilience and support consistent policy enforcement.

6. ITS Stakeholder Groups and Their Cybersecurity Focus Areas

Roles and responsibilities for the cybersecurity and resilience of ITS's are divided across stakeholder categories.

  • Standards Development Organizations (SDOs): SDOs author the standards that enable the various components within an ITS to operate safely and effectively. Types of standards applicable to ITS include information models, application profiles, interfaces, functional safety, human factors, and many more. SDOs should work to ensure that cybersecurity and resilience are considered when developing any standard. Cyber security specific standards also exist, which detail how to invoke various security services, including secure messaging, privilege management, trust management, misbehavior detection and more.
  • Cybersecurity Oversight and Policy Authorities: Executive-level stakeholders play an important role in establishing governance frameworks, ensuring that an ITS complies with applicable laws and regulations, and quantifying and prioritizing risk-based decisions.
  • Infrastructure Owner Operators (IOOs); IOOs are responsible for deploying, configuring, and maintaining ITS equipment. To accomplish this, an IOO should define and enforce lifecycle procedures for the onboarding, monitoring, management, and decommissioning of any electronic equipment that operates within an ITS. IOOs also must have processes in place for post-market operation of ITS equipment, for example processes for certificate enrolment, security configuration management, audit collection and storage, and incident management.
  • Original Equipment Manufacturers (OEMs). The OEM role has evolved recently to encompass more responsibilities. OEMs may now offer services that include telematics, software update, and data management. OEMs are responsible for manufacturing secure vehicles (e.g,. in accordance with ISO/SAE 21434) and deploying trusted services.
  • ITS Manufacturers and Application Developers: ITS vendors should design and deliver ITS devices using a secure development methodology that protects the supply chain, development environment, and results in products that meet minimum baseline cybersecurity requirements. This could include for example, secure boot, tamper detection, and certificate validation. ITS vendors are responsible for obtaining test and certification for devices that will be provisioned PKI certificates, to demonstrate that devices are secured according to any given PKI providers' enrollment requirements.
  • Certificate Management Authorities: Certificate management authorities design, develop and operate PKI systems, such as CCMS and SCMS. They are responsible for ensuring that these systems comply with published certificate policy and practices, and that they successfully pass audits on a routine basis.

7. ITS Misuse Cases

ITS misuse cases illustrate how attackers could chain multiple threats together to compromise transportation systems. Each case provides a short scenario, identifies which assets are affected, and highlights the relevant threats and mitigations. Misuse cases are designed to illustrate how incidents may unfold in practice so that stakeholders can better understand how to calculate risk and choose the optimal cybersecurity patterns for risk mitigation.