INF.11 General Vehicle

Description

Introduction

Institutions use a wide variety of vehicles for short and long distances in many situations. In the context of this building block, vehicles are motorized means of transport that generally move on land, air, sea, and waterways and have a vehicle cabin or equivalent. Examples include cars, trucks, aircraft, and ships. In the following text, only the generic term “vehicle” is used unless a specific type of vehicle is meant.

Almost all modern vehicles have integrated IT components, such as infotainment systems or internal analysis systems, which must be viewed holistically within the framework of information security. In addition, official tasks are frequently carried out not only in the rooms and buildings of an institution, but also within vehicles that may be at changing locations and in different environments. A vehicle is therefore also an independent mobile working environment that must be adequately secured by the institution.

Objective

This building block describes specific threats to be taken into account when institutions deploy vehicles with IT components or when vehicles are used generally as IT workplaces. Building on this, the building block specifies the requirements that vehicle users and operators must meet in order to ensure optimal vehicle operation from an information security perspective.

Scope and Modeling

The building block INF.11 General Vehicle is in principle to be applied once to every land, air, and water vehicle deployed by the institution.

The building block is addressed to users and operators of vehicles. Autonomously driving or remotely controlled vehicles, rail vehicles, and spacecraft are excluded from this building block.

The type, equipment, deployment location, and field of activity of vehicles can differ from one institution to another. The building block INF.11 General Vehicle only addresses typical vehicle deployment scenarios, so that special purposes — such as rescue missions by rescue helicopters or combat missions by military vehicles — must be additionally considered on an individual basis.

Therefore, no conclusive discussion is provided of subsequently installed, mission-specific IT systems or vehicle-specific specialist applications such as those typical in emergency vehicles or command vehicles. The equipment and associated specialist applications of these vehicles are to be dealt with individually and additionally.

Furthermore, vehicle-internal networks via communication buses such as CAN, LIN, or FlexRay, also known as IVN (In-Vehicle Network), are not addressed, since these are generally not modified by users.

To secure IT components carried along and subsequently installed, all relevant building blocks must be separately considered — such as SYS.3.1 Laptops, SYS.3.2 General Smartphones and Tablets, NET.3.3 VPN, and the building block layers NET.4 Telecommunications and NET.2 Wireless Networks.

Furthermore, before the vehicle is disposed of or decommissioned, the building block CON.6 Deletion and Disposal must be applied so that no sensitive information remains in the vehicle.

This building block addresses all infrastructural aspects, so that INF.9 Mobile Workplace does not additionally need to be modeled.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block INF.11 General Vehicle.

Missing or Inadequate Regulations for Vehicles

If it is not regulated, or only inadequately regulated, what information may be transmitted and processed via the networks made available to users by vehicles — such as WLAN or Bluetooth — and what protective measures must be taken, confidential information can be disclosed. If it is not sufficiently regulated how these are to be secured and used, sensitive information such as personal data could be disclosed.

If vehicles are stolen or integrated IT components fail and there are no regulations and defined procedures for these situations, this can have grave consequences. There is a risk that sensitive information will remain in the vehicle and unauthorized third parties will gain access to it.

If vehicles or the IT components installed therein are improperly commissioned, this can lead to extensive threats to information security. Relevant settings, such as automatic synchronization of phone books, could be incorrectly configured, or functional tests on aircraft could be skipped or carried out improperly. This in turn can cause the aircraft’s systems to not function as intended during operation and, in the worst case, lead to a total loss of the aircraft.

Similarly, the function of integrated IT components and the entire vehicle can be jeopardized if the vehicle is improperly shut down or temporarily taken out of service. Emergency vehicles are one example. If these are switched off for an extended period, there is a risk of the vehicle battery completely discharging due to the extensive equipment. As a result, the vehicle may fail to start and data could be lost in the integrated IT components.

Lack of Security Awareness and Carelessness When Handling the Vehicle

A lack of security awareness and carelessness when handling vehicles and their components represent a serious threat. If employees, for example, are not adequately trained on how to handle vehicles and IT components and are not aware of possible risks, vehicles and the IT components installed therein could be used incorrectly or carelessly. For example, IT systems on ship bridges are used by different persons. If significant settings are changed by one user without informing the other users, malfunctions could occur that other users cannot trace.

A further risk can arise from vehicles being locked unreliably. This could allow unauthorized third parties to easily enter the vehicle cabin and view or steal all IT components and information present.

Furthermore, poorly trained employees could respond inappropriately to disruptions and worsen the situation through an incorrect reaction. If, for example, the institution’s responsible department is not contacted when a disruption occurs in a vehicle’s integrated IT systems, but instead the user attempts to resolve the disruption themselves, unforeseeable consequences could result. For example, relevant settings for security or data protection could be changed.

Unregulated Data Transmission to Third Parties and Insecure Communication Interfaces

Many modern vehicles are equipped not only with the wireless communication interfaces directly relevant or visible to users, such as Bluetooth or WLAN. Many internal systems of the vehicle communicate directly with the manufacturer’s IT systems via integrated cellular interfaces, and this exchange of information generally cannot be influenced by users. This refers not only to legally required and user-transparent systems such as eCall, but in particular also to those that are not directly visible to the user. For example, many vehicle manufacturers transmit data to collect detailed information about the vehicle’s location, mileage, or the behavior of drivers. This could result in extensive personal data being collected about vehicle users without their knowledge or explicit consent to such data collection and processing.

A further threat arises from insecure communication interfaces in vehicles. Sensitive data could be read out through inadequate protective mechanisms. For example, if the infotainment system permits Bluetooth pairing without security mechanisms, unauthorized third parties could pair their smartphone with it unnoticed and synchronize phone books.

Improper Modifications to the Vehicle

While conventional cars are very rarely modified by the vehicle operator, vehicles for specialized purposes very frequently need to be subsequently adapted by the operators or specialized companies. Emergency vehicles or subsequently modernized or repurposed ships are one example. If in such cases a vehicle is improperly modified — for example by routing additional cables inappropriately — this can lead to significant damage up to total loss of the vehicle.

Other modifications can also impair the operational capability of vehicles. If, for example, the infotainment system is manipulated to activate new or locked functions, updates from the manufacturer may no longer be installed and associated potential security vulnerabilities may no longer be closed.

Manipulation, Unauthorized Access, and Theft of Vehicles

Information left openly in vehicles can frequently be viewed from outside if there is no or only inadequate privacy screening. This can arouse interest and lead to attacks.

Vehicles are frequently parked in publicly accessible car parks or moored at boat berths that are not protected by central security measures of the institution, such as security services or locked garages. They are therefore in principle exposed to an increased risk of being entered by unauthorized persons. Insecure locking systems can be a vulnerability here. For example, so-called keyless locking systems in vehicles can under certain circumstances be easily bypassed by relay attacks.

IT systems, accessories, information, and software can thus more easily be manipulated, destroyed, or stolen when stored unattended in vehicles rather than in the institution’s premises. If IT systems, accessories, information, or software are manipulated or destroyed, employees in vehicles are often only able to work to a limited extent. The affected IT systems could even be manipulated in such a way that, for example, data processed on them is forwarded to unauthorized third parties via malware. Furthermore, destroyed IT components may need to be replaced, requiring both financial and personnel resources.

Hazards in Connection with Maintenance, Repair, and Updates

If vehicles and the IT components used are not or only insufficiently maintained and serviced, or their functionality is not regularly checked, they may be fully or only partially operational when needed.

A major challenge here is that updates for IT systems integrated in vehicles are not necessarily available on the regular maintenance cycles of the vehicles. As a result, updates could, for example, only be installed irregularly and with delay.

In institution-owned workshops, vehicles and the installed IT components generally cannot be fully maintained or repaired, which is why vehicles are frequently handed over to third-party companies. In the premises of the third-party company, the vehicles are usually unobserved and third parties can comprehensively access the vehicle and the IT components used. This creates an increased risk of IT components being misused or sensitive information being stolen.

Hazards During Decommissioning

When vehicles are decommissioned, they can be sold with all installed IT components or with some of them. This can allow external persons to access the IT components and thereby draw conclusions about internal information or personal data — such as stored telephone numbers. Furthermore, institution-owned components such as SIM cards or cryptographic modules can remain in the vehicles. The subsequent owners would thus inadvertently gain access to these and could, for example, read information from these components (such as telephone numbers from the SIM card) and use them unlawfully.

Impermissible Temperature and Humidity in Vehicles

Every device has a temperature range within which it functions properly. If the ambient temperature exceeds or falls below the limits of this range, devices and IT components can fail and operations can be disrupted. The same applies to humidity. Vehicles present different conditions that can lead to exactly such situations. For example, the interior of vehicles parked in the sun can reach up to 70 degrees and thus exceed the usual temperature range of, for example, lithium-ion batteries.

Requirements

The following are the specific requirements of the building block INF.11 General Vehicle. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They should be filled where meaningful and appropriate.

Exactly one role should be Primarily responsible. There may also be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a specific requirement, that role is listed in square brackets after the requirement heading. The use of singular or plural does not imply anything about the number of persons filling these roles.

Basic Requirements

The following requirements MUST be met as a priority for this building block.

INF.11.A1 Planning and Procurement (B) [Specialist supervisors, Procurement office, Data Protection Officer]

Before vehicles are procured, the intended use MUST be planned. The functional requirements for the vehicles and in particular the requirements for information security as well as the data protection of the installed IT components MUST be identified. The following aspects MUST be taken into account:

• deployment scenarios of the vehicles,
• the specific deployment environment of the vehicles, and
• the entire lifecycle of the vehicles.

The vehicles MUST furthermore have appropriate locking systems, provided the vehicles cannot be secured continuously by other measures or regulations. During planning, it SHOULD be taken into account that many vehicles can transmit data to vehicle manufacturers and other third parties.

INF.11.A2 Maintenance, Inspection, and Updates (B) [Specialist supervisors, IT Operations]

Vehicles and the associated IT components MUST be maintained in accordance with the manufacturer’s requirements. It MUST be noted that the intervals for conventional maintenance and for updates to the integrated IT components may differ from one another. It MUST be clearly regulated who may install updates in which environment. “Over-the-Air” (OTA) updates MUST also be installed in a regulated manner.

Maintenance and repair work MUST be carried out by authorized and qualified personnel in a secure environment. It SHOULD already be clarified before maintenance takes place how to deal with third-party companies. If vehicles are maintained at external institutions, it SHOULD be examined whether all portable IT systems belonging to the vehicle that are not needed should be removed.

When vehicles are reintegrated into operational use, it MUST be checked using a checklist whether all complaints and deficiencies have been remedied. It MUST also be verified that the IT components present are operational.

INF.11.A3 Regulations for Vehicle Use (B) [IT Operations, Specialist supervisors, Users, Data Protection Officer]

For all activities that can affect the security of information processed in vehicles, it MUST first be regulated whether they may be carried out in the vehicles. It MUST be clearly regulated which information may be transported and processed in the process. In addition, it MUST be specified what protective measures must be taken. This MUST apply to every type of information, including conversations in vehicles. It MUST be clarified under what framework conditions employees may access what type of information from their institution.

Furthermore, it MUST be regulated to what extent infotainment systems, applications, and other services of the vehicles may be used. It MUST also be specified how interfaces are to be secured. Existing business or operational instructions MUST describe how IT carried along in vehicles may be used and stored.

Standard Requirements

Together with the basic requirements, the following requirements represent the state of the art for this building block. They SHOULD generally be met.

INF.11.A4 Creation of a Security Policy (S) [Specialist supervisors, IT Operations]

All relevant security requirements for IT within vehicles SHOULD be documented in a security policy that is binding for employees. The policy SHOULD be known to all relevant employees of the institution and form the basis for their handling of vehicles. The responsibilities for individual tasks SHOULD be clearly regulated in the policy. The security policy SHOULD be regularly reviewed and updated on an event-driven basis.

INF.11.A5 Creation of an Inventory List (S)

For each vehicle, an inventory list SHOULD be maintained covering:

• IT components permanently installed in or belonging to the vehicle (e.g., handheld radios in emergency vehicles),
• specialist applications running on the integrated IT components,
• operating instructions and operational documentation, and
• mobile devices paired with the infotainment system.

The inventory list SHOULD be regularly and event-drivenly updated. It SHOULD be checked whether all inventoried IT components belonging to the vehicle are still present. Additionally, the inventory list SHOULD be used to verify that no mobile end devices have been unlawfully paired with the infotainment system.

INF.11.A6 Establishment of Operating Instructions (S) [Specialist supervisors, Users]

For all significant situations affecting the information security of vehicles, operating instructions in the form of checklists SHOULD be available. The operating instructions SHOULD be integrated into the security policy and be available in an appropriate form as checklists while the vehicle is in use. The case of the vehicle itself being stolen SHOULD also be taken into account. The operating instructions SHOULD in particular address the following scenarios:

• failure of IT components of vehicles,
• emergency situations such as accidents,
• unauthorized entry of vehicles, and
• theft of vehicles or objects stored therein that are relevant to information security.

Responsibilities for individual tasks SHOULD be documented in the checklist. The instructions SHOULD be applied by vehicle users in the corresponding situations. How the users proceeded in these situations SHOULD be documented based on the checklist.

INF.11.A7 Proper Handling of Vehicles and Sensitive Information (S) [Specialist supervisors, Users]

The institution SHOULD supplement the operating instructions for vehicle use with aspects of when, how, and where vehicles may be appropriately parked or docked. The primary question to be answered SHOULD be which environments adequately protect the vehicles against unauthorized access or vandalism. It SHOULD also be taken into account which information and IT systems may be stored in the vehicles. Adequate measures for access protection SHOULD be taken.

The vehicle’s cargo SHOULD be secured. It SHOULD be ensured that sensitive information cannot be viewed, overheard, or stolen from outside the vehicle by unauthorized persons. Employees SHOULD be familiarized with the basic functioning of the vehicles and the relevant IT components. Employees SHOULD also be informed of the existing security risks.

INF.11.A8 Protection Against Weather-Related Influences (S) [Users, Specialist supervisors]

Vehicles and the IT components installed therein SHOULD be adequately protected against weather-related influences. Depending on the type of vehicle, deployment location, and deployment environment, additional protective measures SHOULD be taken. For short-term extreme weather events, appropriate protective measures SHOULD be taken.

These protective measures SHOULD be documented in the vehicle operating instructions in the form of checklists.

INF.11.A9 Ensuring Supply (S) [Specialist supervisors]

Before vehicles are deployed, it SHOULD be planned how they will be supplied with fuel during deployment. Vehicles SHOULD always be adequately supplied with fuel during deployment.

INF.11.A10 Decommissioning (S) [IT Operations, Specialist supervisors]

When vehicles are decommissioned, no sensitive information SHOULD remain in the vehicles. Before vehicles are finally decommissioned, it SHOULD be checked using the inventory list whether no inventoried objects and beyond that any relevant objects have been left behind.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection representing the state of the art. The proposals SHOULD be considered when protection needs are elevated. The specific determination is made within an individual risk analysis.

INF.11.A11 Contingency Measures for Failures (H) [Specialist supervisors]

In the event that vehicles or drivers are unavailable, preparatory measures SHOULD be taken within the institution. Depending on the importance of the vehicles, replacement vehicles SHOULD be available, or alternatively a framework agreement SHOULD be concluded with a suitable external institution. Additional replacement drivers SHOULD also be available.

INF.11.A12 Anti-Theft Protection or Guarding (H) [Specialist supervisors, Employees]

An alarm system SHOULD be present. For ground vehicles, an immobilizer SHOULD additionally be present. When leaving the vehicle, the alarm system and immobilizer SHOULD be activated. Alternatively, the vehicles SHOULD be guarded.

INF.11.A13 Harmful External Interference (H) [Specialist supervisors]

Depending on the type of vehicles, appropriate measures SHOULD be taken to protect the vehicles against potential external interference in the planned deployment environment, such as disruptive radio waves.

INF.11.A14 Protection of Sensitive Information Against Unauthorized Access and Knowledge (H) [IT Operations, Specialist supervisors]

Vehicles and the associated IT components SHOULD be secured so that sensitive information cannot be read, manipulated, or deleted by unauthorized persons. The existing protective measures of the manufacturers SHOULD be reviewed and adjusted as necessary.

INF.11.A15 Physical Protection of Interfaces (H) [IT Operations, Specialist supervisors]

All physical internal and external interfaces of vehicles SHOULD be physically protected against unauthorized use and external influences.

INF.11.A16 Fire Suppression System (H) [Specialist supervisors]

Vehicles SHOULD have a fire suppression system capable of extinguishing a fire from outside and inside. Alternatively, suitable firefighting equipment SHOULD be carried.

INF.11.A17 Network Separation of the In-Vehicle Network from a Special Vehicle Network via Gateways (H)

In general, the institution SHOULD ensure that no information is exchanged without authorization and without defined boundaries between:

• the In-Vehicle Network (IVN), which in turn is connected to the networks of vehicle manufacturers, and
• the mission-specific IT components.

For this purpose, gateways with standardized protocols (e.g., in accordance with the CiA 447 standard) SHOULD be used. The gateways SHOULD be approved by the vehicle manufacturer.

Additional Information

Good to Know

The scientific article “IT-Sicherheit und Datenschutz im vernetzten Fahrzeug” (IT Security and Data Protection in the Connected Vehicle) by the Fraunhofer Institute (DOI: 10.1007/s11623-015-0434-4) provides a general overview of connected vehicles, possible applications, the required data, and the resulting threats.

The scientific article “Security Issues and Vulnerabilities in Connected Car Systems” from the IEEE conference 2015 shows which new threats arise from vehicle connectivity.