Telematics Wire November Magazine 2020

november 2020 | `250

Telematics Wire Technology Driven | Futuristic Vehicle

Cybersecurity for Future Automotive

BUILD, CONNECT AND SCALE your automotive IoT solution like never before

eSIM integrated IoT connectivity modules from Cavli Wireless

C1RS

C1RM

NB-IoT

NB-IoT

2G

CAT 1

C100AM

C10AM-G

CAT 4

GPS

3G

2G

Regions: APAC, EU, MEA

C42QM 2G

LTE CAT-M

Regions: APAC, EU, MEA

Regions: APAC, EU, MEA

Available on

C10AM 2G

Regions: APAC, EU, MEA

Regions: APAC, EU, MEA

CAT 1

Powered by

NB-IoT

2G

Regions: Global

Applications Smart Parking

Remote asset monitoring Vehicle Tracking

On-board diagnostics Autonomous driving

Technology for the connected tomorrow for more information contact sales@cavliwireless.com

Fleet management Logistics and Inventory tracking

www.cavliwireless.com www.cavlihubble.io

Leaders in

high performance automotive grade modules for the Internet of Vehicles and C-V2X

For more information contact us on

www.quectel.com

Contents Volume : 01 issue : 06

Automotive Cybersecurity Special 06

12

Solutions for Establishing a Secure Automotive Software Development Process Dennis Kengo Oka, Synopsys

30

New UN Automotive Regulations Target Cybersecurity, Software Updates Gilad Bandel, Arilou Automotive Cybersecurity

24

Protecting Connected Vehicles through Open Innovation Eldad Raziel, (Renault-NissanMitsubishi) Innovation Lab Tel-Aviv

Securing a Connected Car Mushabbar Hussain, KPIT Technologies (UK) Automotive Cybersecurity – NOT for tomorrow; we need to ACT NOW Vishal Bajpai, SecureThings

ANALYTICS

38

IoTs, Wireless Data, OTA updates - Ensuring the Security of the Connected Car Michela Menting, ABI Research

40

Standardization and Cyber regulations in mobility Praveen Sasidharan, Bharghavi Rajagopal, Deloitte India

82 NEWS 28

Idps: A Perfect Combination of Machine Learning and Big Data for Protecting Vehicles Marco Donadio, GMV

Nikhil Kumar Country Head, India HERE Technologies

CEO & Editor Maneesh Prasad maneesh.prasad@telematicswire.net Deputy CEO Anuj Sinha M: +91 87440 88838 anuj.sinha@telematicswire.net

GM- Corporate Communication Yashi Mittal M: +91 98103 40678 mgr_corpcomm@telematicswire.net

43 New UN Automotive Regulations Target Cybersecurity, Software Updates Alex Oyler, SBD Automotive

HERE’s ‘think global, act local’ strategy seeks to help make India atmanirbhar

Director Lt. Col. M C Verma (Retd.)

34

19

Automotive Cyber & Privacy Liability – Risks & Mitigation Arjun Bhaskaran, Gamasec

86 Map Maker’s View

DGM- Corporate Sales Poonam Mahajan M: +91 9810341272 mgr_corpsales@telematicswire.net Editorial Team Member Richa Tyagi Dipti Singh Web Developer Neha Nagar Designer Bishwajeet Kumar Singh Publication Address Telematics Wire Pvt. Ltd. D-98 2nd Floor, Noida Sec-63 Uttar Pradesh-201301 Email: info@telematicswire.net Printed and Published by Maneesh Prasad on behalf of Telematics Wire Pvt. Ltd. Telematics Wire Pvt. Ltd. D-98, 2nd Floor, Noida Sec-63 Uttar Pradesh-201301 Email: info@telematicswire.net Disclaimer Telematics Wire Pvt. Ltd. does not necessarily subscribe to the views expressed in thepublication. All views expressed in this issue are those of the contributors.

Please Note: No material may be reproduced in whole or part without permission of Telematics Wire Pvt. Ltd. Copyright 2020, Telematics Wire Pvt. Ltd. All rights reserved.

4 | Telematics Wire | November 2020

Epilogue

Epilogue

L

ast 6-7 months have been exhilarating for the team members of Telematics Wire; and also well-spent months, where we learned a lot about the automotive telematics ecosystem. When we re-launched our monthly publication, we estimated it to be 8-10 articles with a similar number of advertisements to support it. When we launched our publication our reach was sober, though incremental over the previous quarters in terms of readership and reach.

Where we are today, it’s far more than we planned out in terms of our reach estimates. Perhaps we were naive in estimating the number of companies and engineers working on improving the future automotive. What we see now is amazingly expansive horizon, where holding the two ends in single view looks nearly impossible. Incredible are the numbers which we are visualising for the magazine in the coming year.

What is expected from trade publication working in the automotive telematics+ segment like ourselves? Yes, we would be happy to hear more from you as we move ahead into the year 2021.

Anuj Sinha Deputy CEO anuj.sinha@ telematicswire.net +91 87440 88838

We had several inputs on articles, papers, news coverage, market update‌and more. We are also appreciative of the suggestions on thematic issues where we cover sub-segments like ADAS, Autonomous Vehicle, Cybersecurity, Vehicle Telematics etc. Not to forget some very encouraging feedback on the quality of articles covered.

That the industry is the best teacher, has been so true for us. But, we need these suggestions on a continued basis, as we know that Telematics Wire publication has a long way to go and it will be needing your inputs/suggestions in this journey.

Anuj Sinha Deputy CEO Telematics Wire

November 2020 | Telematics Wire | 5

Lead Article

Solutions for Establishing a Secure Automotive Software Development Process Dennis Kengo Oka Synopsys

Trends, and cybersecurity standards and regulations The automotive industry is seeing several major trends driving advancements for the next-generation vehicles.

These trends are commonly referred to as CASE: connected, autonomous, shared and services, and electrification.

It is important to recognize that for the automotive industry to allow the development and deployment of connected and autonomous vehicles, including electric vehicles, which provide greater user experience by enabling access to various mobility-sharing and additional services, cybersecurity is paramount. These future vehicles need to be cybersecurity-protected against malicious attackers who may target remote interfaces and vulnerabilities in automotive systems. Moreover, to achieve these advancements, there is a fundamental shift from mechanical and electrical solutions to softwarebased solutions providing the required vehicle functionality. Thus, future vehicles will contain more advanced and complex systems based on large software codebases. More software typically inherently has higher risk of more vulnerabilities and therefore automotive organizations need to emphasize the establishment of a secure software development process.

Furthermore, cybersecurity has been gaining a stronger focus in past years with the development and introduction of various standards and regulations.

A draft standard of the ISO/SAE DIS 6 | Telematics Wire | November 2020

21434 “Road vehicle – cybersecurity engineering” [1] was released in February this year. The standard has received several comments and is currently being updated and the final version is expected to be released in the first half of 2021. This standard presents various requirements and recommendations for automotive organizations on several topics including overall cybersecurity management, project-dependent cybersecurity management, continuous cybersecurity activities, risk assessment methods, concept, product development, and post-development phases. Additionally, in June this year, two new UN regulations on Cybersecurity and Software Updates were adopted by UNECE’s World Forum for Harmonization of Vehicle Regulations (WP.29) [2]. These regulations focus on a framework and processes for automotive organizations to be able to among other identify and manage security risks in vehicle design, ensure risk assessments are kept current, monitor and respond to cyber-attacks, and assess if cybersecurity measures remain effective in light of new threats and vulnerabilities. The two UN regulations emphasize mainly on the need for organizations to establish a CSMS (cybersecurity management system) and SUMS (software update management system).

It is also worth noting that the OpenChain Working group has been working on a new ISO standard focusing on requirements for an open-source

license compliance program to allow for building trust between organizations exchanging software solutions comprised of open-source software[3].

As mentioned above, with larger software codebases, including increased usage of open-source software (OSS) components in automotive systems, it becomes imperative to manage OSS in the automotive supply chain.

Although the OpenChain ISO standard focuses on license compliance, it is equally important to achieve software component transparency in the supply chain. Software component transparency is actively promoted by the National Telecommunications and Information Administration (NTIA) of the United States Department of Commerce [4].

Activities promoted by NTIA include defining and using SBOM (software bill-of-materials), how to identify and name components, how to share SBOMs between parties, and how to automate SBOM production. The main purpose of these activities is to enable a process to allow involved parties in the supply chain to be aware of especially included OSS components and associated known vulnerabilities to be able to address any potential security concerns.

With an understanding of these trends, standards and regulations, this article further explores common challenges that lead to vulnerabilities in automotive systems and highlights automated solutions to help automotive organizations establish a secure software development process.

Pressure to meet product deadlines Lack of understanding/training on secure coding practices

60% 55%

Accidental coding errors

Lack of quality assurance and testing procedures

Coding

50%

The use of insecure/outdated open-source software

40%

Product development tools have inherent bugs

26%

Open-source software

23%

Malicious code injection

19%

Incorrect permissions

Testing

39%

Lack of internal policies or rules that clarify security requirements

Back end systems

Solutions to establish a secure software development process

71%

15% © 2020 Synopsys, Inc.

Synopsys Confidential Information

1

Figure 1: Answer to the question: “What are the primary factors that lead to vulnerabilities in automotive software/technology/components?” [5]

Cybersecurity challenges in the automotive software development lifecycle A report based on a survey called “Securing the Modern Vehicle: A Study of Automotive Industry Cybersecurity Practices” was released in February 2019. This report was commissioned by SAE International and Synopsys, and the survey was conducted independently by the Ponemon institute [5]. The report contains results based on a survey of security experts in the automotive industry involved in the development of automotive systems. One example from this report is highlighted in Figure 1. The figure shows the answer to the question: “What are the primary factors that lead to vulnerabilities in automotive software/technology/ components?”

Besides the top factor “Pressure to meet product deadlines”, the top three factors are related to coding, testing, and open-source software. Regarding coding, factors include “Lack of understanding/training on secure coding practices” and “Accidental coding errors”. Regarding testing, the factor is related to “Lack of quality assurance and testing procedures”.

Finally, regarding OSS, the related factor is “The use of insecure/outdated open source software components”.

Thus, it is clear that while there are substantial benefits with more vehicle

Application security faces most security risks

Application layer

It is worth noting that while ISO/SAE DIS 21434 and UNECE WP.29 provide a more holistic view of cybersecurity including describing multiple cybersecurity activities on both organizational and project levels, this article focuses especially on cybersecurity solutions for the software development lifecycle. More specifically, the focus is on applicable solutions to address the top three factors from the above-mentioned automotive survey report namely: coding, testing, and OSS. In the following, corresponding application security testing solutions that

Network security receives highest spending

Network layer

Human layer Security risk Synopsys Confidential Information

Data layer

Figure 2: Security spending is disproportionate to security risk [7,8].

functionality controlled by software, it also introduces more risks for software vulnerabilities in the application layer due to coding errors, lack of testing, and the use of vulnerable OSS components.

These results from the automotive survey show similarities to the IT and enterprise industries where according to SAP, 84% of cyber attacks happen on the application layer, which makes it the most targeted attack surface for attackers [6]. However, as shown in Figure 2, security spending is disproportionate: while application security faces the most security risks, network security receives the highest spending. This information could serve as a guide for the automotive industry that there needs to be an increased focus on application security testing solutions.

Physical layer

Host layer

Spending © 2020 Synopsys, Inc.

automotive organizations can deploy during the software development lifecycle to help identify and fix vulnerabilities earlier are presented. Since automotive organizations often have limited security resources, the focus is on automated solutions rather than manual activities.

Figure 3 gives an overview of how these application security testing solutions are mapped to the three challenges.

Regarding coding, requirement [RQ10-12] in ISO/SAE DIS 21434 [1] states that verification activities shall be performed and that static code analysis can be used as a verification activity for software to search the source code for patterns matching known faults, common weaknesses and vulnerabilities. Static code analysis tools, e.g., Coverity [9], allow for analyzing the source code without November 2020 | Telematics Wire | 7

2

Pressure to meet product deadlines

71%

Lack of understanding/training on secure coding practices

60% 55%

Accidental coding errors

Lack of quality assurance and testing procedures

50%

The use of insecure/outdated opensource software

40%

Product development tools have inherent bugs

39%

Lack of internal policies or rules that clarify security requirements

26% 23%

Malicious code injection

19%

Incorrect permissions Back end systems

Testing

Open-source software

15%

Coding Static code analysis Vulnerability scanning Fuzz testing Software composition analysis © 2020 Synopsys, Inc.

3

Figure 3: Application security testing solutions mapped to the top three challenges.

executing the software which also means that manual activities to define any test cases can be avoided. These tools can help find buffer overflows, resource leaks, memory corruption and other issues in the software code. Moreover, requirements [RQ-10-20] and [RQ-1021] in ISO/SAE DIS 21434 [1] state that coding guidelines shall be used when cybersecurity is not sufficiently addressed by the programming language itself, and that the software shall be verified for compliance with the coding guidelines. Static code analysis tools can be used by automotive organizations to verify compliance to such coding guidelines, e.g., MISRA C/C++, AUTOSAR C++, and CERT C/C++. Moreover, it is important to recognize that a static code analysis tool by itself is not as useful as having the tool work in an automated fashion for the relevant projects as part of the CI (continuous integration) pipeline in the software development process.

Thus, automotive organizations need to consider approaches for rolling out tool usage to large relevant development teams, including ensuring scalability and performance. Additionally, it may be necessary to prepare enablement material for developers, including specific “how to” guides for safety or security-related projects, including compliance with certain coding guidelines. Last, to ensure efficiency 8 | Telematics Wire | November 2020

and effectiveness of the tools, it is necessary for automotive organizations to consider how to integrate the static analysis tools with other tools in the software development lifecycle to achieve automation, including source code management systems, automation servers, build systems, and bug tracking systems.

Regarding testing, recommendation [RC-10-03] in ISO/SAE DIS 21434 [1] states that component testing should be performed to search for unidentified vulnerabilities. In addition, requirement [RQ-10-18] in ISO/SAE DIS 21434 [1] states that weaknesses and vulnerabilities identified in [RC10-03] shall be managed by the automotive organization in a defined vulnerability management process.

There are numerous test approaches that can be applied to search for unidentified vulnerabilities including vulnerability scanning, fuzz testing, and penetration testing. Vulnerability scanning uses knowledge of known vulnerabilities or attack patterns to identify vulnerabilities on the target system. While vulnerability scanning tools typically use a database of known vulnerabilities or attack patterns, fuzz testing as a technique goes further to identifying unknown vulnerabilities by generating malformed input that is then provided to the target system. Fuzz testing tools, e.g., Defensics [10], can be used to identify unknown vulnerabilities

in various protocol implementations on automotive systems including CAN, CAN-FD, Automotive Ethernet, WiFi, Bluetooth etc. as well as upper layer protocols such as ISO-TP, UDS, DoIP, gPTP, IP, TCP, HFP, A2DP etc. While vulnerability scanning and fuzz testing can generally be performed using automated tools during the software development process, penetration testing typically involves manual activities performed in several steps including planning, discovery, attack, and reporting. During a penetration test, although some automated tools can be used, a human tester mimics a “real” attacker to try to break certain security goals of the target system [11]. Moreover, it is important to note that automotive organizations should consider approaches for applying automated test tools such as vulnerability scanning and fuzz testing tools in an automated fashion as part of the CI pipeline in the software development process. This includes determining which tools to use, when and what to test, what test environments are required and how often testing should occur.

Furthermore, it is necessary to consider how to integrate with other tools in the software development lifecycle, such as automotive test tools and automation servers. It is also important for automotive organizations to consider establishing dedicated cybersecurity test labs to enable automated security testing.

Regarding OSS, requirement [RQ06-16] in ISO/SAE DIS 21434 [1] states that when integrating an off-the-shelf component, e.g., an OSS component, cybersecurity-relevant information such as known vulnerabilities shall be gathered and analyzed. One overarching goal for automotive organizations is to achieve software transparency in the automotive software supply chain. Software composition analysis can be used to help achieve this goal. Software composition analysis tools, e.g., Black Duck [12] can scan the target software in the form of source code or binary to identify included OSS components and corresponding versions. This information is useful to help automotive organizations to avoid

the usage of outdated OSS components.

Additionally, these tools can be used to automatically generate SBOMs in an agreed format, e.g., SPDX (Software Package Data Exchange) that can be shared together with the software along the supply chain. More importantly, from a security perspective, software composition analysis tools can also map known vulnerabilities to the identified OSS components using vulnerability databases such as NVD (national vulnerability database). Furthermore, requirement [RQ-07-01] in ISO/SAE DIS 21434 [1] states that internal and external sources shall be monitored for collection of cybersecurity information.

As an external source, software composition analysis tools can provide alerts and additional information on newly identified vulnerabilities in OSS components as input to the continuous cybersecurity monitoring activity at automotive organizations. Finally, not specifically related to security, but equally important from a license compliance point of view is that these tools can also identify the relevant associated license types to help automotive organizations ensure that they are compliant with the license terms. Moreover, it is imperative that automotive organizations consider approaches to ensure that the software composition analysis tool is applied in an automated fashion for relevant projects as part of the software development process. For example, this includes establishing an overall process for OSS management that defines when and what to scan, applying OSS policies including criteria for acceptable OSS usage, and defining an approval process for using new OSS components. In addition, automotive organizations should consider how to integrate software composition tools with other tools in the software development lifecycle, such as source code management systems, automation servers, build systems, and bug tracking systems.

Summary With the continued advancements of CASE, introduction of new cybersecurity standards and regulations, cybersecurity is becoming a major

focus area for the automotive industry.

Especially regarding automotive software development, the three main challenges are related to coding, testing and OSS. To address these challenges automotive organizations can deploy automated application security testing solutions such as static code analysis tools, vulnerability scanning tools, fuzz testing tools, and software composition analysis tools. As mentioned, while it is important to use appropriate application security testing tools in the software development lifecycle, it is equally important for automotive organizations to establish the necessary processes to enable effective use of the tools.

Especially, this requires considerations for integration with other tools and systems, defining processes for when and what to test, and finally running the tools in an automated fashion in a CI pipeline.

References [1] ISO/SAE, “ISO/SAE DIS 21434 Road vehicles — Cybersecurity engineering”, https://www.iso.org/ standard/70918.html [2] UNECE, “UN Regulations on Cybersecurity and Software Updates to pave the way for mass roll out of “connected vehicles”, https://www.unece. org/info/media/presscurrent-press-h/ transport/2020/un-regulations-oncybersecurity-and-software-updates-topave-the-way-for-mass-roll-out-ofconnected-vehicles/doc.html [3] ISO/IEC, “ISO/IEC DIS 5230 Information technology — OpenChain Specification”, https://www.iso.org/ standard/81039.html

[4] NTIA, “NTIA Software Component Transparency”, https://www.ntia.doc. gov/SoftwareTransparency [5] Ponemon Institute, “Securing the Modern Vehicle: A Study of Automotive Industry Cybersecurity Practices”, 2019, https://w w w.sy nopsys.com/autosecurity [6] Forbes, ” Most Cyber Attacks Occur From This Common Vulnerability”, h t t p s : / / w w w. f o r b e s . c o m / s i t e s / sap/2015/03/10/most-cyberattack s-occur-from-this-commonvulnerability/#1ef450857454 [7] Digital Guardian, “Infographic: Is Security Spending Proportional to the Data Breach Problem?”, https:// digitalguardian.com/blog/infographicsecurity-spending-proportional-databreach-problem [8] Ponemon Institute, “How to Make Application Security a Strategically Managed Discipline”, 2016 [9] Synopsys, “Coverity Static Application Security Testing”, https:// www.synopsys.com/software-integrity/ security-testing/static-analysis-sast.html [10] Synopsys, “ Defensics Fuzz Testing”, https://www.synopsys.com/softwareintegrity/security-testing/fuzz-testing. html [11] Stephanie Bayer, Thomas Enderle, Dennis Kengo Oka, Marko Wolf, “Security Crash Test – Practical Security Evaluations of Automotive Onboard IT Component”, Automotive Safety & Security, 2015 [12] Synopsys, “ Black Duck Software Composition Analysis”, https://www. sy nopsys.com/soft ware-integrity/ security-testing/software-compositionanalysis.html . o

Author Dennis Kengo Oka Principal Automotive Security Strategist Synopsys Dr. Dennis Kengo Oka has been involved in automotive security since 2006. In the past, he worked for Volvo Car Corporation in Sweden on automotive security for connected cars, and for the Bosch group where he co-launched the automotive security practice (ESCRYPT) in Japan. As a Principal Automotive Security Strategist at Synopsys, he focuses on security solutions for the automotive software development lifecycle and supply chain.

November 2020 | Telematics Wire | 9

Technical Insight

Automotive Security: Deterministic protection of connected vehicles Eli Mordechai Karamba Security

M

any car OEMs have realized that they must manufacture and sell connected cars in order to stay competitive. GM was one of the industry’s pioneers, selling connected cars equipped with the OnStar TCU in 1997. Dataonly telematics was introduced in 2003 and were gradually adapted to by global OEMs. Nowadays even the late adapters (without mentioning names) offer builtin connectivity in their vehicles.

However, connectivity comes with a price. To date, all connected technology products are trailed by hacking attempts, for financial or terrorist motivations.

In March of this year, Tencent Keen Security Lab published a security blog post on how they gained full control over a new generation of in-vehicle infotainment units and TCUs, sent malicious CAN commands to different electronic control units (ECUs) and caused the car to perform unexpected physical – and sometimes safety-critical – actions. This accompanied similar attacks on Tesla, BMW, and other OEMs’ cars. All in all, a recent study by MarketsAndMarkets has revealed that the global automotive cybersecurity market size is projected to grow from USD 1.9 billion in 2020 to USD 4.0 billion by 2025, at a CAGR of 16.5%. In addition to risks to human life, the industry is confronted with direct financial losses, legal liability, and harmed reputation.

Automotive systems are complex, and are designed for the long term The average passenger car life expectancy is between 10 and 12 years. Even if the way cars operate remains the

same, cybercriminals are constantly changing their attack strategies. Even if manufacturers or customers quickly identify an exploited vulnerability, closing the vulnerability on all devices often takes too long, leaving attackers plenty of time to spread their malice. Traditional security solutions, as known from IT, cannot be transferred to the vehicles’ ECUs as-is, in any case. Conventional IT systems rely heavily on daily anti-virus and malware signature updates in order to fend off attacks. Such frequent updates are not possible with vehicles. Even with overthe-air updates, the typical frequency of software updates is expected to be once or twice per quarter, leaving hackers wide time windows in which to exploit reported vulnerabilities.

The pressure on manufacturers is increasing In addition to the threat of damage to their reputation in the event of a known vulnerability, Tier-1 suppliers and OEMs of connected cars are increasingly exposed to pressure from the public and from regulatory authorities. More and more regulations are being enacted worldwide to force manufacturers to secure connected devices such as automotive ECUs. Examples are the UN ECE WP. 29, ISO standard 21434 and NHTSA Cybersecurity Guidelines. Those regulations put the security burden on manufacturers, whose R&D organizations require the adoption of cybersecurity methods, such as implementing secured design and security validations, which are foreign to those organizations, disrupt

Author Eli Mordechai Director of Innovation, Karamba Security Eli has been leading the innovation at Karamba Security since 2017. He is also the chairman of the Israeli Mirror Committee of the SAE/ISO 21434 automotive cybersecurity standard. Before Karamba Security, Eli served in various technology leading positions at HP Software, HP Labs, and Mercury Interactive. Eli has more than 30 years of experience in the technology world.

10 | Telematics Wire | November 2020

finely tuned processes, and will introduce time-to-market delays.

Deterministic Security: Embedded Seamlessly to R&D When choosing a security solution, companies should therefore make sure that the work of their software developers does not become even more difficult. Companies can benefit from the unique feature of embedded systems: their deterministic nature. ECUs, FPGAs and other embedded controllers are designed to execute only certain commands, and they must not be changed by the end user. Taking advantage of the connected ECUs’ immutable nature, embedded security solutions can form a deterministic security approach.

Deterministic cybersecurity solutions harden the ECU against unauthorized changes, and rely on the concept of Control Flow Integrity (CFI): The trustworthiness of function calls and function returns can be automatically checked against a “known good state“ of the ECU software’s function-calling graph. If a deviation from the graph is detected, it is deterministically prevented and reported. In this way, the ECU is selfprotected, and the system detects and blocks the change (i.e., the attack attempt) without relying on malware updates and before the ECU is hacked and the vehicle is infiltrated by adversaries.

Such a deterministic approach is not new; Tech giants, such as Google for example, have implemented it on its Android mobile OS (which is another type of immutable software). The deterministic nature of CFI enables protecting safetycritical ECUs, such as gateways (ASIL-B level) and ADAS (ASIL-D level). TCUs are currently the main connectivity path to the car and, as such, they represent a prime target for cyber criminals. Protecting TCUs against cyberattacks, and hardening them deterministically, is paramount – with the goal of ensuring consumers’ safety as well as their data privacy. o

November 2020 | Telematics Wire | 11

Lead Story

Telematics Control Unit Cybersecurity: A Battle on Two Fronts Gilad Bandel Arilou Automotive Cybersecurity

T

he Telematics Control Unit (TCU) is now the frontline of the automotive cybersecurity battle. New use cases, driven by ubiquitous connectivity, will see it play a larger role in modern vehicles. As cybersecurity attack vectors emerge, the automotive industry will need to think fast if it is to keep ahead of the threat. Gilad Bandel, VP of Product and Marketing at Israeli firm Arilou Automotive Cybersecurity explains more.

The telematics control unit is in a similar situation in terms of cyber-threats and possible attack vectors, because the TCU serves as a gateway between the external world and the IVN. Vulnerable on two fronts, it can be attacked via both the external cellular network and the invehicle network. A full transition to the use of automotive Ethernet, using IP (internet protocol), increases the risk of a remote attack being launched against an electronic control unit (ECU).

Fighting on Two Fronts

A Mobile Enemy

On March 21st, 1801, the 28th (North Gloucestershire) regiment of the British Army fought a fierce battle outside of Alexandria, Egypt. During this battle, French cavalry broke through the British lines, formed up behind the regiment, and began to charge both sides of the line simultaneously. Still heavily engaged to their front, the order came; “Rear rank, 28th! Right about face!”, and then, in two ranks back-to-back, the regiment successfully defended itself.

Remote attacks are regarded as the most severe threat to the vehicle since they can be performed from anywhere and leave very few traces: • External cellular: Most current, high probability cases feature a cellular modem integrated within the TCU. This interface is used by Original Equipment Manufacturers (OEMs), or fleet owners, to interact with the vehicle (via the cellular network) for functions such as telemetry – using diagnostics protocols

The 28th Regiment prepare to face off against two fronts

12 | Telematics Wire | November 2020

– or the upload of new firmware to ECUs using Firmware Over-the-Air (FOTA). We can split threat analysis for this interface as follows: o Incoming traffic from the cellular network: This traffic originates from the cloud and reaches the TCU via cellular. It poses the most severe threat since it is the preferred attack vector into the vehicle. A malicious actor can reach the IVN and easily launch an attack on the vehicle via a compromised TCU – targeting other ECUs or the TCU itself.

Note that even if communication channels are secured, and the peer is authenticated using cryptography, this still does not rule out compromised cloud servers being used to attack an individual vehicle or an entire fleet.

In some cases, adding end-to-end encryption can even harm the greater cause as it denies inspection mechanisms access to network traffic. This risk is similar to that of vehicle-to-everything (V2X) traffic reaching an on-board unit (OBU), which share similarities with TCUs in terms of communication and threats. o Outgoing traffic to the cellular network: Traffic originating from the TCU, sent to the cloud over the cellular network. In this attack scenario, the attacker uses the vehicle to send rogue data with the purpose of harming the cloud. The same authentication and cryptographic considerations

mentioned above apply, however, this is not the most likely scenario. In some cases, the vehicle owner could be the actual attacker, or an innocent bystander unknowingly aiding in the attack, making the attack much simpler and significantly more dangerous.

In the Trenches As physical attacks are also possible, the basic assumption is that the enemy is among us and able to inject traffic into the IVN. • IVN: The interface for vehicle ECUs, the backbone of the internal network. In the most probable cases, attacks originating from outside the vehicle would target the IVN in an attempt to gain access to specific ECUs, but other scenarios are possible as well. In cases where the TCU has no cellular modem, the central gateway is used to interface with the cellular network, so in this case this is yet another type of outgoing traffic. The threat analysis for this interface is divided as following: o Incoming traffic from the IVN: There are three cases depending on the target: • The target of the attack is the TCU itself, with the intention of influencing TCU functionality by causing it to malfunction and provide erroneous information. This is a high probability scenario. Traffic can originate from any ECU, and in cases where the cellular modem is located in the central gateway, it can also originate from the cloud, making this a dangerous scenario.

• This type of attack can also be used as a step in the kill chain, with the actual target not necessarily related to the TCU. This is a medium-probability scenario due to its complexity, but if successful it could have severe impact.

• Using the TCU as a relay to jump from one network to another e.g. from the CAN-bus to the cellular network, or even back to the CAN-bus. This is an unlikely scenario. o Outgoing traffic to the IVN: Once traffic leaves the TCU

Figure 1: An attack via CAN-bus/SAE J1939 on a TCU with cellular connectivity

for the IVN it can reach other ECUs and cause harm.

Relevant cases are: • Destination is another ECU (Figure 1): The result of such attack scenarios depends on the victim ECU, its protection mechanism, and any other security on the path between TCU and ECU. This includes mechanisms such as network segregation (assuming the TCU is located in the connected low-security network zone, while safety critical ECUs are on a separated high-security network).

Figure 2: An attack via Automotive Ethernet on a TCU with cellular connectivity

• Central gateway equipped with cellular modem while the TCU is not: Traffic here is equivalent to the outgoing cellular traffic mentioned above, except that it first travels over the IVN to the central gateway, which then conveys it to the cellular network.

Figure 3: An attack via Automotive Ethernet on a Gateway with cellular connectivity

November 2020 | Telematics Wire | 13

• In cases where the TCU and the central gateway are combined as a Telematics Gateway Unit (TGU): We consider these as if they were two separate devices. Variations can include the TCU cellular modem being used by the gateway and other ECUs, or the central gateway modem being used by the TCU and other ECUs. In either case, this monolithic design maintains the same functionality and concept as the individual. Note that in this case, the risk is much higher since this device often has additional interfaces such as Bluetooth, Wi-Fi, GPS/GNSS (Global Positioning System/Global Navigation Satellite System) or USB. An attacker can jump from one network to another more easily since they are all packed in one place.

Figure 4: An attack via Automotive Ethernet on a TGU with cellular connectivity

Communication Protocols As above descriptions are generic, we should examine them in relation to the various protocols used.

• Cellular-Side o The physical and data link layers are cellular (3G/4G, and soon 5G) and have a high chance of residing in the central gateway. Using a public Access Point Name (APN) poses a considerable risk since the vehicle is accessible to anyone on the public internet, therefore private APNs are employed. This contrasts with in-vehicle infotainment systems (IVIs) that must have a public APN for internet access. As such, the IVI has some riskier characteristics compared to the TCU. o The network layer is standard IP. o The higher layers include standard IP protocols such as IPsec or HTTPS for VPN creation, IT protocols such as Syslog, automotive standard and proprietary protocols for telemetry, diagnostics, FOTA, and so forth.

• IVN o CAN-bus: This is a legacy bus (with new versions such as CAN-FD and CAN-XL) which all ECUs share and can 14 | Telematics Wire | November 2020

communicate over freely. Gateways are used to mediate and segregate buses. The protocol does not have any inherent source identification or designated, specific, target ECU, as it uses a form of multicast addressing of the message type relevant to interested ECUs. CANbus has some extended capabilities such as Transport Protocol (TP), and authentication methods such as SecOC (Secured Onboard Communication). Riding protocols are the standard Unified Diagnostics Service (UDS). However, the implementations are OEM and model specific (but obscurity is not security). In general, the CAN-bus was well conceived, but in a time before there was any awareness of cybersecurity risk, and as such it has no real security. o SAE J1939: This protocol shares the CAN-bus infrastructure but has higher layer protocols and features such as extended addressing, source and destination identification, extended TP, dynamic addressing and more. This protocol is common among heavy-duty vehicles such as trucks, buses and agriculture machines.

In terms of security it is not much different than the CANbus, but since it is far more standardized, many vehicles share the same message IDs and even the same ECUs. In principle this increases the threat risk since widespread common implementation implies opportunity for multiple attacks once a breach has been found. o Automotive Ethernet: An emerging technology that shares many characteristics with Information Technology (IT) and Operational Technology (OT) – except the physical layer. On top of Ethernet are some specific protocols such as Audio Video Bridging (AVB) and Audio Video Transport Protocol (AVTP). In addition, Ethernet standard TCP/IP is used with common IT protocols such as Address Resolution Protocol (ARP). It also makes use of more important automotive protocols such as Scalable service-Oriented middlewarE over IP (SOME/IP), Diagnostics over IP (DoIP), and others. Given that the protocol stack is new to the automotive industry, but also extremely mature from an IT/OT perspective, it is prone to vulnerabilities from recent adoption in addition to its well documented history of hacks, exploits, and scripts.

As such it poses a major risk. Ethernet should be regarded an excellent opportunity for the automotive industry to evolve, but also for hackers to attack. o Other protocols such as Local Interconnect Network (LIN), FlexRay, Media Oriented System Transport (MOST), and others, are not regarded as a major cyber area due to their location/position or specific/limited functionality.

Embedded Positions The TCU is just another embedded device, as such all the risks relevant to any embedded device are relevant here as well. Since this is a connected device that serves as a gateway for interfacing with a vehicle’s secure ECUs, the risks are much higher: • Compromised boot sequence: In this attack the loaded flash image might be old and unsecured or have malware embedded.

• Tampered storage: Modified software modules or data can be loaded and cause undesirable effects • Firmware update from rogue source: Includes code that will cause malfunction of the TCU, allowing the ability to take remote control.

• Taking advantage of vulnerabilities and exposures such as a Buffer Over Flow (BOF) or an open port: Cause TCU misbehavior.

Defensive Maneuvers There are numerous reasons to secure TCUs: • The TCU is one of the most common ECUs used as a means to attack a vehicle. Furthermore, if the IVN is CAN-bus then the attacker needs to switch protocols from the IP used over cellular to that of the CAN-bus. Even worse, in Automotive Ethernet, the IP is used end-to-end, facilitating direct traversal from the hacker’s computer to the victim ECU. Responsible professionals acknowledge this fact and act to protect and secure these devices.

• Worldwide regulation such as the UNECE (United Nations Economic Commission for Europe) WP.29 (Working Party - World Forum for Harmonization of Vehicle Regulations) and its equivalents in non-participating countries, list a set of risks and required mitigations to secure a vehicle.

These lists must be adhered to in order to receive the legal certification necessary to enable the sale of the vehicle.

• Top management want to prevent deaths, damage to property, and the loss of reputation they could experience in cases where the TCU is found to be used as a means to cause harm to a vehicle.

A Suitable Arsenal The following list examines relevant means to secure the TCU. Each case must be implemented following a designated process such as Threat Analysis and Risk Assessment (TARA), resulting in a list of prioritized risk minimization/mitigation methods.

Tier-1 suppliers and OEMs need to work together to create an optimized plan for cost-effective security for the TCU and associated vehicle models. In any case, there is no silver bullet that solves all problems, therefore a multi-layer, defense-in-depth approach is required.

• Secure by design: From day zero a security plan and a Cyber Security Management System (CSMS) needs to be put in place, with a goal of managing and reducing cyber risk.

Standards such as ISO/SAE 21434 should be followed. For example, network architecture with an Application Area Network (AAN) segregated by sensitivity level (connected, body, media, safety critical, etc.), usage of cryptographic means, trust chain, key distribution mechanisms, Ethernet Virtual Local Area Network (VLANs), IP Virtual Private Networks (VPNs) and similar.

• Development process: Should be designed with security in mind and employ the Secure Software Development Life Cycle (SSDLC), comply to standards such as ISO 26262 Automotive Safety Integrity Level (ASIL), Motor Industry Software Reliability Association (MISRA-C), etc.

• Endpoint Detection and Response (EDR): Include a set of tools that secure the TCU internally such as:

o Secure boot: Ensuring only a verified and authorized image is loaded at boot time. o Secure module loading: Ensure the persistent storage or volatile memory are secure and were not tampered with, thus only verified and authorized versions of each module and file are loaded and used by the software.

In case a mismatch is found, the module or file will be denied, or loading and other measures can be taken, such as TCU reboot, restoring older verified versions, reporting the event, and other relevant actions. o Host Intrusion Detection System (HIDS): Will monitor the behavior of the software of the TCU (CPU usage, memory usage, running processes, data coherence, plausibility, sanity, etc.) to ensure the proper functionality of TCU firmware and report any detected misbehavior.

• Network Intrusion Detection System/Intrusion Prevention System (NIDS/NIPS): Also known as IDS/ IPS, performs traffic inspection employing techniques such as Deep Frame Inspection (DFI), Deep Packet Inspection (DPI), Deep Content Inspection (DCI), and Stateful Packet Inspection (SPI) for anomaly detection, signature-based detection and other methods. Note that anomaly detection is well suited for the static, predictive, and deterministic nature of the in-vehicle network, and has an extremely low false positive ratio and immunity to zeroday attacks. From the other side, signature-based detection can detect complex attack scenarios but is, unfortunately, prone to more false positives alarms. A set of rules is applied on the analyzed traffic to detect anomalies and other indications of a cyber-attack, examples include: o Message format: consistency and compliance to standards o Field value range: For example, speed range within the vehicle physical boundaries (i.e. 0-250 Km/h is valid, but 1,000 Km/h is not). o Change rate of values: Such as accelerating from 20 Km/h to 23 Km/h in one second is possible but 10 Km/h to 150Km/s is one second is not possible. o Periodic messages: i.e. a message that has a 20ms frequency cannot appear after only 7ms. o Vehicle context: For example, a vehicle which is switched off and in parking mode cannot have torque on the engine. o Authentication failure: Such as the key does not match the expected value. o Media Access Control (MAC): Usage of a previously unknown MAC address, known MAC address originating from an unexpected physical port, unexpected MAC address/IP address combination. o Excessive message rate: Indicating a Denial Of Service (DOS) signature attack.

Decisive Tactics It is crucial to emphasis that while all the other measures are important, the IDS/IPS is the only dedicated, devoted, independent and objective component in the vehicle concerned exclusively with cybersecurity protection.

The IDS performs the function of detection and reporting (only) of events, normally to a Security Information and Event Management (SIEM) system at the Security Operation Center November 2020 | Telematics Wire | 15

(SOC) where a Cyber Emergency Response Team (CERT) will perform forensic analysis and generate a response. An IPS, in addition to reporting, will stop the attack by taking intrusive actions – such as dropping offending frames or disabling offending components.

Inspecting the Cellular Interface: • If the TCU is equipped with a cellular modem the IDS/IPS needs to reside on the TCU to enable it to inspect incoming cellular traffic for data that is regarded as a major threat.

• It can also monitor outgoing cellular traffic but, as already mentioned, this is less of a priority since this attack scenario is less probable.

Inspecting the IVN: Incoming traffic to the TCU needs to be inspected in case the attack target is the TCU. • For CAN-bus and SAE J1939 (Figure 5) o If only detection is needed, then the IDS can reside on the central gateway. o If prevention is needed the IPS need to be on the TCU itself since it can be attacked from any neighboring ECU. • For Ethernet (Figure 6) it can be either on the TCU or on the central gateway with the same considerations as above.

This becomes critical since the same IP is used all the way from the attacker to the ECU without any need to switch protocols along the way.

Figure 5: Arilou Sentinel detects an attack via CAN-bus/SAE J1939 on a TCU with cellular connectivity

Figure 7: Arilou Sentinel detects an attack via Automotive Ethernet on a TCU with cellular connectivity

Figure 6: Arilou Sentinel detects an attack via Automotive Ethernet on a TGU with cellular connectivity

16 | Telematics Wire | November 2020

Figure 8: Arilou Sentinel detects an attack via Automotive Ethernet on a Gateway with cellular connectivity

ADVANCED DRIVER ASSISTANCE SYSTEM A smart move towards Zero Road Accidents

Forward Collision Warning (FCW)

Advanced Driver Monitoring Closed-eyes Detection

Yawning Detection

Smoking Detection

Calling Detection

Headway Monitoring Warning (HMW)

Lane Departure Warning (LDW)

ANS IT INDIA PVT. LTD.

+91 70463 54345 operations@ansitindia.com www.ansitindia.com

November 2020 | Telematics Wire | 17

The outgoing traffic from the TCU to the IVN needs to be inspected in any case: • CAN-bus or SAE J1939 o In cases where only detection is needed, this can be done in the TCU or in the central gateway. o If prevention is required, traffic needs to be inspected in the TCU as the bus topology will propagate the message to all ECUs on the bus without the possibility to further influence the traffic. o One can claim that if the network is properly segregated then the TCU will be part of the less secured connected bus and the central secured gateway will be able to protect the safety critical bus from messages originating from the connected bus.

• For Ethernet that employs a star topology (Figure 7) the IDS/IPS function can be placed either on the TCU or on

the central gateway. Placing it on the central gateway might have several benefits since this would be a common IDS/ IPS for the entire network and specific rules relevant for the TCU port will be applied to it.

• TCUs that are not equipped with a cellular modem (Figure 8) use the central gateway for cellular communications, therefore there is a need for the outgoing traffic to be inspected. This can be done on the central gateway with the same considerations as above.

Debrief Since the TCU is a connected device with interfaces both to the outside of the vehicle and to the IVN it is prone to cyber-attacks, and it should be well protected. Protection solutions include a variety of procedural and technological means as detailed in the article. The following table summarizes the various cases and considerations:

Interface

Protocol

Direction

Cellular Modem

Detection/ Prevention

Implementation

Importance

Cellular

IP/cellular

Incoming

Yes

Both

TCU

Very High

Cellular

IP/cellular

Outgoing

Yes

Both

TCU

Low

Cellular

IP/cellular

Incoming

No

Both

TCU/GW

Critical

Cellular

IP/cellular

Outgoing

No

Both

TCU/GW

Low

In-Vehicle

CAN-bus or J1939

Incoming

Both

Detection

TCU/GW

High

In-Vehicle

CAN-bus or J1939

Outgoing

Both

Detection

TCU/GW

Very High

In-Vehicle

CAN-bus or J1939

Incoming

Both

Prevention

TCU

High

In-Vehicle

CAN-bus or J1939

Outgoing

Both

Prevention

TCU

Very High

In-Vehicle

Ethernet

Incoming

Yes

Both

TCU/GW

High

In-Vehicle

Ethernet

Outgoing

Yes

Both

TCU/GW

Very High

In-Vehicle

Ethernet

Incoming

No

Both

TCU/GW

Critical

In-Vehicle

Ethernet

Outgoing

No

Both

TCU/GW

Very High

Table 1 - Summary of cases and considerations

Author Gilad Bandel VP Product and Marketing Arilou Automotive Cybersecurity Gilad drives Arilou’s automotive cybersecurity product management and marketing. His focus is on delivering unique, innovative, and novel functionality. Creating ultramodern solutions for in-vehicle cybersecurity protection.

Gilad is an accomplished executive with over 30 years of experience in the cybersecurity and networking industries. Having covered markets in Europe, America and the APAC region, Gilad is a renowned expert in conceptualizing and developing go-tomarket strategies.

18 | Telematics Wire | November 2020

Tier-1s and OEMs need to implement proper security measures if they are to protect the vehicle and the TCU from dangerous attacks. Arilou offers a variety of automotive cybersecurity products including: • Arilou Sentinel-CAN IDS/IPS for CAN-bus • Arilou Sentinel-TRK IDS/IPS for SAE J1939 • Arilou Sentinel-ETH IDS/IPS for automotive Ethernet • Arilou Sentinel-CEL IDS/IPS for cellular interface This is in addition to other products that provide a protection solution which answers the challenge of securing TCUs, gateways and the IVN in general.

Protected by patents US9881165, US9965636, US10002258, US10534922, EP2832070, US10140450, IL256106 and more pending. o

Industry Insight

New UN Automotive Regulations Target Cybersecurity, Software Updates Alex Oyler SBD Automotive

I

n 2020, the United Nations Economic Commission for Europe released the final version of its vehicle regulations for cybersecurity and software updates. These regulations mark a new era for automakers: in addition to the existing type approval process, in almost all countries, automakers will need to prove that they have a secure, robust process and infrastructure for managing the remote delivery of software updates.

More broadly, automakers will also need

recommendations to automakers and suppliers in the space.

Cybersecurity While physical security has been a core topic for automakers for decades, cybersecurity did not truly enter the day-to-day lexicon until 2015 after the very public hacking of a Jeep Grand Cherokee platform by a pair of hackers in the United States. By proving that remote attack vectors can be exploited to

standardized security frameworks for the sharing of information and uniform verification of vehicle cybersecurity.

The Auto-ISAC, a non-profit focused on sharing security threat and vulnerability amongst industry stakeholders, launched its intelligence sharing platform shortly after in 2016.

In addition, SAE began development of its own cybersecurity guidelines, published in 2016 as J3061, built in part on some of the successful standards

Overview of new UNECE regulations and associated ISO/SAE standards

to prove that they have a comprehensive cybersecurity architecture and robust security lifecycle process. These regulations have major impacts to automakers and their suppliers, and some countries such as Japan are set to enforce these regulations within the next year.

Herein, we introduce the more important concepts in the new type approval process for both cybersecurity and software updates and provide specific

affect the driving behavior of the vehicle, and thus the safety of its occupants, this moment forced automakers to reckon with the idea that they are going to have to invest in cybersecurity infrastructure if they want to compete in the connected, autonomous, and shared mobility ecosystem.

Another effect from this incident was the renewed focus by industry alliances and regulatory agencies on building

established in ISO 26262, the standard for functional safety in road vehicles.

Based on J3061, ISO, in partnership in SAE International, began development of its own cybersecurity standard, ISO/SAE 21434.

This ISO standard forms the basis of the new regulation from the UNECE on vehicle cybersecurity. UNECE WP.29 Cyber Security establishes a framework wherein type approval authorities can

November 2020 | Telematics Wire | 19

Key components of ISO/SAE 21434 for automotive manufacturers

judge whether an OEM has credibly designed and tested the cybersecurity of a vehicle platform. The standard is not yet published in its final form, but drafts offer a preview of what OEMs will need to do in order to meet UNECE type approval guidelines, such as proving a structured cybersecurity development lifecycle from concept to operations, with supporting activities such as risk assessment and on-going monitoring of the system for cybersecurity threats and vulnerabilities.

With this framework, OEMs can achieve the two core requirements within UNECE type approval guidelines for cybersecurity compliance: the provision of a Cyber Security Management System (CSMS) and type approval for individual vehicle models. A CSMS is an OEM’s endto-end cybersecurity ecosystem, which includes both the business processes supporting cybersecurity management as well as the technologies and tools implemented by the OEM to design, develop, test, and monitor its cybersecurity disposition. An automaker is required to have its CSMS audited at least once every three years by an independent technical evaluation authority.

When a vehicle is submitted for type approval, the automaker includes a certificate of compliance issued for the CSMS, and in addition to verification of the authenticity of the certificate, the OEM must provide a variety of supplemental documents to prove that it has performed appropriate due diligence

in the cybersecurity lifecycle of the vehicle model itself.

Some of the items that must be provided in the type approval file include an inventory of all cyber-critical elements, a detailed risk assessment of the vehicle, an inventory of mitigations and countermeasures, details of its cybersecurity testing procedure, and proof of its operational monitoring once the vehicle is on the road.

For many OEMs, this represents only a codification and minor iteration of its current cybersecurity profile as they have already invested in their cybersecurity lifecycles. For example, many have already integrated state-ofthe-art security technologies, intrusion detection and prevention systems, modern cryptographic methods thanks to optimized hardware, and established security operations centers (SOCs) for

the management of its global passenger vehicle fleets.

For some, however, this represents a major new required expenditure in organizational change, platform development, lifecycle development, and operational capabilities. These OEMs must adapt quickly or face the risk that their vehicles may not be approved for sale in a majority of global automotive markets.

Software Updates While the concept of remote software updates to vehicles is not new, the proliferation of the technology across essentially all automakers, alongside the aggressive use of the technology by disruptors such as Tesla have created a need to regulate their use, in particular to ensure the continuing certification of safety-critical systems. This premise is the basis of WP.29 Software Updates.

A timeline of software updates in the automotive industry

20 | Telematics Wire | November 2020

High-level abstraction of a Software Update Management System (SBD Automotive)

WP.29 Software Updates consists of two major tenets that automakers must comply with: a secure Software Update Management System, or SUMS; and a process for modified type approval resulting from software updates which affect any function in the vehicle which is part of the regular type approval process. The SUMS is independently certified by a technical service, and any new model type approval must include a Certificate of Compliance (CoC) for the SUMS used by the vehicle. Automakers are obliged to self-regulate the modified type approval process. Furthermore, the SUMS must be re-certified at least every three years.

The Software Update Management System is the end-to-end solution which delivers, manages, and secures software updates between the automaker and its vehicles. Some of these functions include the transfer of software updates to the vehicle, the security solution used to protect software update delivery and execution, the safe and secure installation process for software updates, and

reporting of operational data related to the installation of software updates in the field.

The SUMS is to be certified by a technical service which evaluates documentation provided by the automaker to prove that it adheres to the requirements set forth in in the regulation.

Some of the items to be evaluated by the technical service include: • A process for identifying updates which affect the vehicle’s other type approved systems • Security for delivering updates to vehicles • A process for notifying users of relevant updates and associated notes • Safe execution of updates during driving or while parked • Clear documentation of update dependencies and rollback technical process If the OEM’s SUMS meets the requirements as evaluated by the technical service, the service will issue the Certificate of Compliance (CoC).

The OEM can then submit this certificate

with any vehicle model for type approval which uses the defined SUMS. Once the vehicle is in production, it is possible that the automaker releases a software update which changes the behavior of another type approved system. This case is one of the core targets of the regulation: the very mandate of the type approval process is broken if automakers are allowed to arbitrarily change the behavior of evaluated systems after launch with a software update.

Therefore, WP.29 further introduces a modified type approval process requirement to automakers. In short, automakers must implement an internal process for evaluating if any given software update changes the behavior of a type approved system. If so, then the update must go through an additional modified type approval process before release.

The real impact of this requirement to automakers is two-fold: first, a new compliance function will need to be added to manage software updates throughout the automaker’s vehicle portfolio. This compliance function will be tasked with evaluating if any given update impacts type approved systems in a target market.

This leads to the second real impact: planned software updates may result in a longer development cycle to release new features and services to production than is currently possible without regulation.

The process, in addition to additional touchpoints with various regulatory bodies, will add bureaucratic overhead to the release process in the name of safety.

In particular, this could affect automakers such as Tesla who already heavily rely on software updates to maintain their competitive advantage.

The other major concept which automakers must now design for is the concept of RXSWIN¸ or Regulation X Software Identification Number. This is a new version number which encapsulates the entire vehicle’s software version.

This can be thought of like an operating system version number: Windows 10 is a collection of software components, each with their own software version. For automakers, the RXSWIN for a specific vehicle is its “Windows version”, and

November 2020 | Telematics Wire | 21

Example of how RXSWIN versioning works

automakers only increment this number when a type approved system is modified.

While this software version does not need to be stored on the vehicle itself, automakers must keep a record of which vehicle is on which RXSWIN to comply with the regulation. The purpose is to create a simple reference point which both automakers and regulatory agencies use to assist in the management of recalls as well as identify vehicles which are not properly receiving updates.

How the industry can prepare for new regulations Automakers and their suppliers alike will need to invest in new organizations, technologies, and capabilities in order to meet the new regulations for cybersecurity and software updates.

For automakers, cross-organizational changes will need to be made to ensure the appropriate business processes are enforced in the product development

Author Alex Oyler Head of Car IT, SBD Automotive Alex is responsible for SBD’s information technology consulting practice. He works with SBD’s clients on a variety of strategic technology initiatives, ranging from technology management consulting to connected vehicle architecture, development, and cybersecurity.

Alex’s publications at SBD include syndicated research on over-the-air software updates, infotainment software and ecosystems, and software-defined cars. Prior to joining SBD, Alex was a solution architect for a major connected vehicle software-as-a-service provider and mobile network operator in North America. Alex is currently based in Nagoya, Japan.

22 | Telematics Wire | November 2020

lifecycle. For suppliers, new tools and security mechanisms will need to be implemented to demonstrate all the requirements for cybersecurity controls and the SUMS. While there will be growing pains for all stakeholders involved – including the regulatory agencies in charge of enforcing the rules – the outcome should be more secure cars that allow for continuous innovation and improvement without sacrificing driver safety and privacy.

SBD Automotive has been deeply involved in the study, survey, benchmarking, planning, and development of over-the-air software update capabilities for automakers for over five years. In addition, our company’s heritage is security: the company began in 1996, focusing on the design and development of physical security systems, which has evolved into a world-class cybersecurity design and testing organization helping automakers meet and exceed emerging threats and regulatory challenges. o

November 2020 | Telematics Wire | 23

Technical Insight

Protecting Connected Vehicles through Open Innovation Eldad Raziel Alliance (Renault-Nissan-Mitsubishi) Innovation Lab Tel-Aviv

T

he connected car revolution has greatly accelerated in the past year and is expected to boost by end of 2023, with some 100 million vehicles on the road.

As OEMs are adapting massive digitalization and connectivity the vehicle architecture has become far more complex and consequently, the attack surface has significantly expanded.

Protecting against cyber threats has become mandatory to ensure the safety of cars, drivers and passengers, as well as to enable the adaption of new automotive technologies. This is a one of the focus areas of the Alliance Innovation Lab in Tel Aviv.

Connected Cars – The Core of the New Smart Mobility A Connected Vehicle is basically connected to a network, that enables services such as: Vehicle tracking, Vehicle Diagnostic and Predictive Maintenance, Data-driven services like adapted insurances to the drivers’ behavior, online services or offers and incentives to the passengers through the infotainment unit, fleets management tools, and all sorts of data monetization possibilities from cars. In the future, at its highest level of connectivity, applications in the car could include a virtual companion or even chauffeur based on cognitive AI, with a high degree of personalized riding experience for all passengers in the car. Connectivity and communication between the car and its environment (V2X), is also an important enabler for autonomous driving.

This connectivity is supplied through 24 | Telematics Wire | November 2020

the TCU (Telematic Unit) or In-Vehicle Applications. The TCU “listens” to the bus in order to extract relevant data out of it, mainly data that had been configured before. As the TCU is an embedded part in the on-board architecture it has the capability to transfer the information from the vehicle outside (to the Cloud) and from outside to the vehicle.

Vehicles can be connected using Aftermarket tools (OBD-II, GPS Tracker for Fleet Management, etc.) or Original set-up from the vehicle OEM (Software or Hardware).

The components used in connected vehicles are: TCU, Infotainment Unit, Driver Assistant Unit, and V2X, while the connected vehicle interfaces (Entrypoints) would be Bluetooth, Wi-fi, Cellular network, GPS, OBD-II, 1/2 dindash, Sensors (such as TPSM), Lidar and Camera, Keyless entry.

Remote Attacks vs Physical Attacks The connected vehicle exposed the OEMs to a wider scope of new entry points for the attacker to manipulate. Remote attacks seem to have higher stake than the physical attacks, since in a physical attack the attacker would need a physical access, which reduces the risk.

We already saw remote manipulations (For example: Jeep Cherokee) that can cause a real impact on the vehicle, driver, etc.

CAN bus protocol – Secure or Unsecure?

CAN bus is based on a broadcast protocol divided into 2 wires – CAN-H and CAN-L, where information can be transmitted and received from ECUs connected to the network.

In the CAN network we can find ECUs,

TCUs and Gateway. The CAN network is divided into subnetworks that are connected to the Gateway.

Since the CAN bus protocol is based on message broadcast system it involves some issues related to security. Therefore, some of the OEM’s shift to other protocols such as Ethernet, but still, most of the OEM’s use CAN bus or a combination of protocols.

An example of the security issues within the CAN bus protocol: • There is no authentication mechanism – DDOS , Tampering and poisoning attacks are more than welcome • Lack of encryption – Every ECU connected to the same bus can sniff the entire messages running on the same bus.

• Lack in MSD (Message Source Detection) – it is not possible to know if an ECU sends or receives any message How to mitigate the lack of security in the CAN bus protocol?

• Encryption • Firewall • Message Authentication • Message Source Detection • Intrusion detection/Prevention Systems o Host-based / Gateway • Deterministic • Heuristic • HSM There are still some limitations to mitigate the risk due to latency, behavior, computing power, false positive ,cost and you need to take into account that only by protecting the CAN bus you are not protecting the full scope of connected vehicles.

in future cars and services offered by the Alliance member companies. As part of our open innovation approach, the Lab collaborates with the local innovation ecosystem through joint prototyping efforts (POC). To date it has led more than 20 collaborative projects with Israeli start-ups, some of them are in Cybersecurity, being one of Israel’s strongest tech domains.

These collaborations roll out as the automotive industry prepares for the new UN Regulations set to come out in January 2021, which require car manufacturers to secure connected cars from cyberattacks. (Ref: https://www.unece. org/info/media/presscurrent-press-h/ transport/2020/un-regulations-oncybersecurity-and-software-updates-topave-the-way-for-mass-roll-out-of-

connected-vehicles/doc.html) .

In light of all the above, managing software security is no longer an optional activity for car manufacturers but a mandatory transformation to a future with fully automated, self-assessed, selfhealing software This means that OEM’s, as well as Tier1’s and other suppliers will now need to enforce the following steps in order to mitigate the risk from the supply-Chain through the Value-Chain: 1. Cyber Security Risk Management 2. Security by Design 3. Detection & Response 4. Secure Updates To address the new regulation the OEM’s are adding some layers to enrich their capabilities: 1. In-Vehicle Security solutions

Cybersecurity – a mandatory transformation The Alliance Innovation Lab Tel Aviv aims to advance the state-of-the-art mobility, with a main focus on vision sensors, data & AI, and Cybersecurity. The latter is seen as an enabler for the integration of any other new technologies. Through collaborations with innovative Israeli startups, our mission is to identify and test technologies that could be implemented

Credit: Upstream

November 2020 | Telematics Wire | 25

2. Cloud solutions – for E2E visibility & detection on the connected Apps to the connected Vehicle 3.

ASOC – Automotive Security Operation Center 4. Validation and Risk management solutions

The first vehicle-level automated risk assessment solution Cybellum Israeli startup is a leader in Automotive Cybersecurity Risk Assessment. Our team at Renault Nissan Mitsubishi Innovation Lab collaborates

Credit: Upstream

Credit: Upstream

Credit: Upstream

26 | Telematics Wire | November 2020

with Cybellum to offer innovative vulnerability detection for vehicles’ software, developing the first vehicle-level automated risk assessment solution.

This strategic cooperation is the first in the world to focus on vehicle-level risk assessment Cybellum solution enables automotive OEMs and suppliers to identify and remediate security risks at scale, throughout the entire vehicle life cycle.

Their agentless solution scans embedded software components without needing access to their source code, exposing all cyber vulnerabilities. Manufacturers can then take immediate actions and eliminate any cyber risk in the development and production process, before any harm is done, while continuously monitor for emerging threats impacting vehicles on the road.

Following a successful POC of Cybellum’s solution, done by the Innovation Lab, we cooperate to build innovative cybersecurity technologies to be implemented in the automotive market.

Today, most of the risk assessment in the automotive industry is conducted manually or using tools on a single component level. This methodology cannot scale and only provides partial information. An entire vehicle is a very complex system composed of over a hundred connected components, with a complex interconnection.

Our cooperation focuses on vehiclelevel risk assessment, taking into account the architecture of the vehicle model and the automated assessment of a vehicle’s complex mesh of software and hardware.

Together we aim to bring to the market the first solution that can calculate the risk of a vulnerability in the full vehicle context, help the Alliance brands to manage the risk accurately, save time and be competitively prepared for upcoming regulations.

Cybellum automotive risk analysis solutions automatically detect a wide range of vulnerabilities in in-vehicle ECUs and other automotive software. Using upcoming developments from the new cooperation, Alliance companies will be able to use the Cybellum solution suite to gain full, ongoing visibility to their

Credit: Upstream

Credit: Upstream

cybersecurity exposure at the vehicle level and get the necessary guidance on risk remediation.

A successful collaboration with Upstream Security to mitigate connectivity risks Upstream helps corporations mitigate connectivity risks and ensure the safety and security of smart mobility solutions protecting connected and autonomous vehicles, SAE levels 0-5, from remote cyber attacks generated over the public internet or private mobile APN, as well as from fleet-wide attacks targeting multiple vehicles at the same time. Their team has developed a comprehensive protection of the mobility service infrastructure, connected vehicles and the people inside them.

Over the past year, Alliance Innovation Lab Tel Aviv worked together with Upstream Security to design a cybersecurity solution for connected cars within the Renault- Nissan-Mitsubishi Alliance.

As part of the effort, market research,

technological evaluations, and business evaluations took place. The rigorous and in-depth joint PoC subsequently found that Upstream’s solutions seamlessly fit the Alliance’s cybersecurity and business needs.

The Alliance Innovation Lab and Upstream collaborative journey started after a scouting process where we found Upstream Security to offer the most mature end-to-end cybersecurity solution covering telematic servers,

mobile applications, and the car itself.

The Lab approached Upstream with a long list of requirements for a solution that would improve our cybersecurity posture. Among the features that were requested were: no in-vehicle installation and therefore quick deployment and no impact on vehicle production cycles, a product with a proven track record that was already tested, verified, and in production, and finally a solution that would match the business needs and challenges of the Alliance members.

The year-long three-part confirmation process included a solution landscape evaluation, a technical evaluation and PoC using the Lab’s cybersecurity research team and the Lab vehicles, and lastly, a business evaluation, where the business and the commercial potential of Upstream’s solution was evaluated in accordance with the Alliance members’ needs.

After an in-depth discussion, Upstream was found to be worthy of more than just a successful POC, and Alliance Ventures, the Alliance corporate venture capital fund invested into Upstream, leading its $30M series B of financing.

As the automotive world moves toward electric, connected, and autonomous vehicles, it leads to good opportunities, but also to risks. The industry are looking for cyber protection for cars and services, not only in the car, but also at the communication and cloud level. After seeing the success of the collaborative efforts, both the Alliance Innovation Lab and Upstream Security are committed to continue joining forces to make the future of smart mobility safer and more secure. o

Author Eldad Raziel Head of Cyber Security Alliance (Renault-Nissan-Mitsubishi) Innovation Lab Tel-Aviv, Israel As part of his role, he manages the Lab’s relationship with Israeli startups in the field of automotive cybersecurity, including scouting and evaluating companies through feasibility tests and prototyping efforts (POC).

Raziel brings 15 years of experience in cyber positions starting in in Rafael, Unitask, National Bank and other financial and technological entities. He is a graduate of MAMRAM, the IDF Computer Center and Information Systems.

November 2020 | Telematics Wire | 27

Perspective

IDPS: A PERFECT COMBINATION OF MACHINE LEARNING AND BIG DATA FOR PROTECTING VEHICLES Marco Donadio GMV

A

s our cars become increasingly interconnected, mobility takes on a new meaning, offering new opportunities.

The integration of new communications technologies in vehicles has generated an enormous variety of data from various communications sources.

A combination of Big Data and the headway being made in artificial intelligence (AI) is enabling us to handle data of all types from different sources, while also greatly simplifying real-time analysis.

AI and Big Data convergence is therefore playing a vital role in all industries, the automotive included.

GMV’s automotive business includes the development of new in-vehicle technology, including cybersecurity, an issue to which everyone has become much more sensitive in recent years.

For years now we at GMV have been studying new security protection techniques for internal and external vehicle communications.

Combining our Machine Learning and Big Data expertise, GMV has developed an Intrusion Detection and Prevention System (IDPS) based on algorithms that are trained up using machine learning techniques to make the detection of intrusions and anomalies (malicious attacks) much more effective and precise.

The general architecture of our IDPS is made up by several components: • A telematic control unit (TCU) that collects the car’s data (CAN, Ethernet, USB data etc…) and performs a first and basic filter before sending the Author Marco Donadio Automotive Business Development and Trade Marketing Director GMV

28 | Telematics Wire | November 2020

data on to a server. Within the TCU, therefore, simple rules would be applied, with a very low processing load, and hence easily integrated into any of the vehicle’s electronic units.

• The complementary part of the IDPS is an external server that receives the abovementioned filtered data and then uses smart algorithms to detect and classify anomalies/intrusions, flagging up alerts as need be. The cloud processing system means the in-vehicle processing load can be trimmed back; this in turn means much more complex intrusion detection methods can be used for any instances involving deep learning.

Our detection-algorithm design can be broken down into two main phases: training and anomaly detection.

In the offline training phase data packages are processed (CAN data packages, Ethernet packages, USB data) to extract a characteristic trait representing the network’s statistical behavior.

The labeling of each training package depends greatly on the machine-learning algorithms to be used. A simple example would be supervised learning: each training package has its binary label, i.e., a normal package or an abnormal or malicious package.

From the training data the algorithm learns how to allocate the output label to suit a new value, i.e., to predict the output value.

When unsupervised algorithms are being used, there is no labeled training data to go on. The algorithm therefore creates a series of data structures that can be cataloged in terms of resemblance and correlations, thus determining complex patterns and processes that will serve for identifying and classifying any anomalous behavior that might turn out to constitute an intrusion incident.

Our inhouse solution combines several machine-learning algorithms to be able to fine tune the intrusion detection procedure.

The efficiency and precision of the proposed model is assessed and validated

by using real cases and data. From our own experience we have learned that the use of machine learning algorithms ensures rapid (down to milliseconds) anomaly-detection convergence, with a high rate of success and efficiency.

To complement intrusion detection there is the possibility of applying prevention methodologies; this is precisely why the complete solution is called an Intrusion Detection and Prevention System (IDPS).

The way prevention is phased into the system differs greatly according to the IDPS’s purpose and how it might affect vehicle and driver safety and security.

Normally, prevention tasks are broken down into active and passive actions.

Passive actions consist of a suspectedintrusion notification. Once the IDPS detects an intrusion, the user is sent a telematic notification, and the warning, which contains all the intrusion details, is then recorded in an internal database.

Active actions involve a series of measures to protect the vehicle or mitigate the threat it is exposed to. Depending on the criticality of the attack, this might be in real time and might have a big effect on the infected system.

We at GMV are convinced that the action to be taken in response to any suspected intrusion is crucial because it might impinge on vehicle safety: take the example of a simple blockage of the braking system’s CAN message, which might turn out to have fatal consequences.

For this reason we are now busily working away on the best security solution without ever losing sight of the safety aspects.

To be able to fine tune these models it is important to be able to work with a complete and bang up-to-date database for algorithm training and enhancing. Collaboration with OEMs and first-tier suppliers is very important too, in pursuit of these goals, to ensure they are offered the solution best suited to their needs. We therefore always work closely with them in the development of solutions of this type.. o

Lead Article

AUTOMOTIVE CYBER & PRIVACY LIABILITY – RISKS & MITIGATION Arjun Bhaskaran Gamasec

T

he Connected and Autonomous Vehicles (CAVs) revolution is ushering in significant benefits in convenience, safety, information, communication, and entertainment options for consumers. It also has the potential to eliminate virtually all accidents; drastically reduce traffic congestion; and providing an economical and environmentally friendly mode of transportation. But to deliver these

Source: TUV SUD (2018)3

30 | Telematics Wire | November 2020

benefits, a variety of technologies are becoming embedded into CAVs and they work on over 100 million of lines of code – manifold times more than aircrafts – with over 30,000 component parts and 30-100 electronic control units (ECUs).1 These numbers are set to explode in the coming decades.2 The explosion in software and data intensity in CAVs, make them a potential target for hacking and therefore CAVs need to be continuously secured, patched,

and updated. It is estimated that there are at least 15 key issues that can be hacked in most connected cars.4 The fast-paced changes in automotive, electronic technologies, have shortened automotive development and production cycles.5 But, while the adoption rate of new technologies has increased exponentially, cybersecurity measures are not able to keep pace with these rapid developments and are causing a sharp increase in the cyber risk.6 Further, the number of attack vectors in connected cars and the automotive industry is significant leaving many cybersecurity gaps open and unresolved, endangering customer safety along with higher risk of financial and reputational harm for businesses.7 The consequences of cyberattacks on connected automobiles, will be devastating for all stakeholders – car owners, OEMs, service providers, the public, government, and society.8 To meet the need for enforcement of automotive cybersecurity, the European Union (EU), Japan and other major markets have adopted UN-ECE-WP.29, a set of cybersecurity regulations that defines principles to address key cyber threats and vulnerabilities identified in order to assure vehicle safety in case of cyber-attacks. UN-ECE-WP.29 is being implemented through ISO/SAE 21434, “Road vehicles — Cybersecurity engineering”, a set of guidelines for ensuring automotive cybersecurity.

Under this, Automotive OEMs and suppliers are required to continually detect and react to security issues during the entire lifespan of the vehicle.

CAVs will be under live monitoring and analysis from Vehicle Security Operation Centers (V-SOCs), where vehicle data

is continuously transmitted back to a V-SOC for analysis and monitoring whether an attack is taking place, and for remedial action to be taken swiftly.

Driving functions fail Loss of brake control Loss of engine control Loss of steering control Data theft Infrastructure data Personal data Vehicle data

V-SOCs - Data Privacy Issues V-SOC will have access to data on cybersecurity systems, as well as vehicular data that is needed for enabling repairs, to ensure and promote security both in vehicles and on the road, identify and predict performance and maintenance.

However, privacy laws like the California Consumer Privacy Act (CCPA) define

personal information as the “information that identifies, relates to, describes, is capable of being associated with, or could reasonably be linked, directly or indirectly, Vehicle systems fail Dysfunctional door locks Inoperative lights Disrupted passenger safety systems Faulty diagnostics Vehicle theft Track vehicle’s GPS coordinates Manipulated navigation Telematics Takeover control Vehicle sold/held to ransom

located and how it responds in certain weather conditions or at certain speeds; 3. maintenance information, including when the vehicle has been serviced and when the next service may be required 4. any malfunction reports.

5. On-board diagnostics systems or the telematics systems — in other words, information that is collected via the communication or infotainment systems and/or via driver inputs, such as the location of the driver’s home or office.

6. Biometric information, or whether the driver is drunk or is too tired to operate the vehicle While, this data can be used by manufacturers and service providers to ensure vehicle operation and efficient repairs and services, but it involves the privacy of the vehicle owners or driver. To comply with CCPA, “Car manufacturers and service providers should conduct an inventory of what data they collect and use…., where the data is sent and for what purpose. …To the extent that the data collected by a car is classified as personal information, there are a number of rights that must be granted…., including: Notice, Access, Opt-out or -in, Deletion, Equal services and prices Collison Liability questions Driver injuries or deaths Pedestrian injuries or deaths Commercial loss Brand damage Reduced buyer confidence Revenue loss

with a consumer or household.” Majority of the data that is collected by a vehicle, fall under this definition: 1.

Information about a vehicle’s functionality, such as mileage, fuel consumption, oil levels, engine status, temperature or speed; 2. information about the vehicle’s performance, operation and environment, such as where it is

regardless of choices made.”9 Under the CCPA, consumers have broad rights to personal information collected about them, including information collected by vehicle manufacturers, dealers and service providers. The consumer the right to know what data is held about them, and the CCPA requires carmakers to ensure that there are systems in place to ensure the consumer is given that right.

November 2020 | Telematics Wire | 31

Source: TUV SUD (2018)

Product Liability and Cyber / Privacy Liability Automotive Cybersecurity in CAVs gives rise to several issues relating to product liability10 and cyber / privacy breach liability 1. In case of incidents with a certified product, there are important questions relating to 2. the liability of manufacturers, distributors, conformity assessment bodies, and consumers.

3. Liabilities regarding the convergence between product safety and security 4. are consumers responsible for the damage of an incident if they did not update their IoT device regularly?

5. At what point can a manufacturer of an IoT device stop providing important security updates? Given the crucial role of secure and regularly updated software for a device’s functioning?

6. Liability relating to responsibilities for informing users of IoT devices about known vulnerabilities and disclosing security breaches.

Mitigation of Cyber and Privacy Risks in IoT Cybersecurity and privacy risks for IoT devices, can be addressed through three high-level risk mitigation goals, as recommended by NIST 11.

1. Protect device security. Prevent a device from being used to conduct attacks, including participating in distributed denial of service (DDoS) 32 | Telematics Wire | November 2020

attacks against other organizations, and eavesdropping on network traffic or compromising other devices on the same network segment. a. Asset Management: Maintain a current, accurate inventory of all IoT devices and their relevant characteristics throughout the devices’ lifecycles in order to use that information for cybersecurity and privacy risk management purposes. b. Vulnerability Management: Identify and eliminate known vulnerabilities in IoT device software and firmware in order to reduce the likelihood and ease of exploitation and compromise. c. Access Management: Prevent unauthorized and improper physical and logical access to, usage of, and administration of IoT devices by people, processes, and other computing devices.

d.

Device Security Incident Detection: Monitor and analyze IoT device activity for signs of incidents involving device security.

2. Protect data security. Protect the confidentiality, integrity, and/or availability of data (including PII) collected by, stored on, processed by, or transmitted to or from the IoT device. a. Data Protection: Prevent access to and tampering with data at rest or in transit that might expose sensitive information or allow manipulation or disruption of IoT device operations. b. Data Security Incident Detection: Monitor and analyze IoT device activity for signs of incidents involving data security.

3. Protect individuals’ privacy. Protect individuals’ privacy impacted by PII processing beyond risks managed

through device and data security protection. a. Information Flow Management: Maintain a current, accurate mapping of the information lifecycle of PII, including the type of data action, the elements of PII being processed by the data action, the party doing the processing, and any additional relevant contextual factors about the processing to use for privacy risk management purposes. b.

PII Processing Permissions Management: Maintain permissions for PII processing to prevent unpermitted PII processing. c. Informed Decision Making: Enable individuals to understand the effects of PII processing and interactions with the device, participate in decision-making about the PII processing or interactions, and resolve problems. d. Disassociated Data Management: Identify authorized PII processing and determine how PII may be minimized or disassociated from individuals and IoT devices. e.

Privacy Breach Detection: Monitor and analyze IoT device activity for signs of breaches involving individuals’ privacy.

Further, mitigation of Cyber Security and Data Protection risks can be obtained from Cyber Insurance policies that offer cover for cyber or privacy breaches.12

Third Party V-SOCs – Potential Solution The likely enactment of the Personal Data Protection law in India, will extend the CCPA type privacy regime. To meet the requirements of privacy law, the solution could be through a tweaking the V-SOCs from Manufacture Operated to Independent 3rd Party V-SOCs that can be modelled on the National Securities Depository (NSDL) and Central Securities Depository (CDSL), in stock markets. This model will ensure that all the privacy related principles of CCPA, PDP, GDPR will be implemented effectively and simultaneously, critical vehicle and driver data can be shared (with the explicit consent of the data

principal) with insurance companies and law enforcement authorities, for monitoring and measurement of vehicle and driver risk profiles. Risk-adjusted fixation of vehicle insurance and accident insurance premiums will go a long way in incentivizing positive driver behavior and practices, while penalizing adverse patterns.

Road Safety The United Nations Sustainable Development Goals (SDG) stipulates the following goals.

1. SDG 3.6 By 2020 halve the number of global deaths and injuries from road traffic accidents 2. SDG 11.2 By 2030 provide access to safe, affordable, accessible and sustainable transport systems for all, improving road safety, notably by expanding public transport, with special attention to the needs of those in vulnerable situations, women, children, persons with disabilities and older person.

In India, the combination of CAVs and 3rd Party V-SOCs will assist in achieving the SDG goals, by a judicious mix of incentives / disincentives for safe driving behavior, through risk-adjusted motor insurance premium. We can look forward to a minimum of 10% savings in Motor Insurance premiums, which stands at Rs.69208 Crores for FY2019-20, through reduced accidents, injuries, and deaths.13 As Sanjay Gupta, Vice President & India Country Manager – NXP Semiconductors recommends, “it is important that all stakeholders fulfill their roles: government agencies, industry players as well as car owners.

Requesting information about the security capabilities of our cars should become routine, in the same way as we learn about safety, driving parameters and convenience features today. Providers

must support this goal with the most advanced technology, so we can all be safe and secure while moving towards the future of mobility.”14

References “Who is responsible for securing the connected car?”, NTT Security, 2019 2 TUV SUD (2018), “Potential Cyber Security Threats Of Autonomous And Connected Vehicles: Consequences And Safety Solutions” 3 TUV SUD (2018) 4 McCafe, Automotive Security - Best Practices, 2016 5 Chad Morley. (n.d.). Jabil. “Automotive Industry Life Cycle – Shorter Timelines.” https://www.jabil.com/blog/automotiveindustry-trends-point-to-shorter-productdevelopment-cycles.html.

6 Johannes Deichmann et al. McKinsey & Company. (2019) “The race for cybersecurity: Protecting the connected car in the era of new regulation.”

7 TUV SUD (2018) 8 TUV SUD (2018) 9 Eva Pulliam & Sarah Bruno, “CCPA’s potential impact in the automotive space”, IAPP, Oct 2019 10 “Securing the Internet of Things Together”, Indo-German Working Group on Quality Infrastructure, GIZ, January 2020 11 NIST, “Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks- NISTIR 8228”, June 2019 12 Automotive IQ, May 2018, “8 Tips to Prevent Autonomous Vehicle Cyber Breach Liability”.

13 “Cyber Governance in Motor Insurance in India”, Working Paper, Japan-India Development Forum, April 2020.

14 “Unauthorised vehicle access, loss of personal info: Connected cars need better cybersecurity”, Financial Express, Express Drives Desk, Jul 28, 2020 o 1

Author Arjun Bhaskaran Country Manager – India & Middle East Gamasec Arjun Bhaskaran, is Country Manager – India & Middle East for Gamasec an Israel based Cybersecurity company that is pioneering new models in Cyber & Privacy Liability Insurance for Enterprise and SMB markets in OECD countries. He has been CTO, CISO of several companies in the Insurance sector. He was part of a 5 member team that established Axis Bank project from conception to go-live.

He can be reached at arjun@gamasec.com

November 2020 | Telematics Wire | 33

Technical Insight

SECURING A CONNECTED CAR Mushabbar Hussain KPIT Technologies (UK)

ABSTRACT The influx of digital transformation and advancements in technology have enabled the automakers to develop cars that are cleaner, safer, smarter and more energy-efficient. This revolution is being driven by the convergence of connectivity, electrification and demanding customer needs. Today’s cars employ a series of intelligent technologies such as Blind spot detection, Adaptive headlights, Lane keep assist, Collision warning, Adaptive cruise control, Reversing camera, Hill assist, Crash-imminent braking. Further with everyone wanting to stay connected all the time, car designers are making cars in line with this growing trend. This makes the modern-day automobiles more sophisticated, extremely complicated and highly connected systems. While the Connected autonomous technologies are expected to make the cars more safer, more energy efficient, and more intelligent systems the highly connected nature of these cars make them extremely vulnerable to cyber-attacks. By gaining access to the car, hackers can compromise safety critical functions endangering life of the passengers seated in the car.

The objective of this article is to discuss about the potential cybersecurity threats in modern vehicles, their impact and the possible counter measures to safeguard the vehicle against potential attacks

navigation systems etc. Now as cars became more and more interactive, they get connected to the Internet, with each other (V2V), and with the infrastructure (V2X) they become more vulnerable than ever to attackers and hackers. Thus, a modern car architecture provides a broad internal attack surface with each component having at least implicit access to every other component on the bus. A compromised infotainment system can offer an effective vector for attacking safety critical ECU’s connected to the In-vehicle network. Once a hacker gains access to the in-vehicle network of the car, they could control everything; from controlling the acceleration, to applying or releasing brakes, locking or unlocking the doors. Therefore, security attacks are not just limited to theft or disclosure of information, but also affect safety of the passengers seated inside the car Recent studies and Experiments conducted by Independent research organizations from EUROPE/US (Stephen Checkoway et. al] have demonstrated that once a hacker gain access to the in-vehicle network of the car, could control everything; from controlling the acceleration, to applying and releasing brakes, locking/ unlocking the doors. These experiments demonstrate the importance of security in automotive systems.

INTRODUCTION

Security Attacks Overview

Unlike the classic cars, the modern vehicles are software-intensive, more complex, and highly connected systems.

They can have about 70-100 embedded microcontrollers onboard running millions of lines of code within them.

These ECU’s control almost every function of the car including safety-critical vehicle applications such as braking, engine control, steering, airbag functions,

The Security attacks can be broadly classified into Active attacks and Passive attacks. The figure below provides an overview of attacks an automotive system can be subjected to

34 | Telematics Wire | November 2020

How A Connected Car Can Be Hacked?

A modern automotive can be hacked either by physical access or by remote

access of the In-Vehicle-Network. Direct physical access to the car internal network is possible via OBD port, Debug ports or Digital multimedia ports. Remote access to car is possible via a broad range of attack vectors such as CD/DVD players, Short-range wireless access – Bluetooth, RFID(remote Keyless entry, vehicle immobilizers, Tire Pressure Monitoring System), Dedicated ShortRange Communications and Longrange wireless access – WiFi, Cellular Technologies(LTE, GSM, CDMA) Connected vehicles use a combination of wireless technologies such as Radar, Lidar, GPS and other advanced sensors for its operation. These cars are expected to have a permanent connection to the Internet and to the cloud for fetching various kinds of information such as road speed limit, current traffic situation, weather conditions, traffic light status etc. They can also communicate with other smart devices, other cars and roadside infrastructures for collecting real-time data to make certain decisions.

Attacker can intercept and manipulate the messages or send forged messages to the ECU causing them to mal function.

Therefore, it is important to understand the various threats a connected car can be subjected to and necessitate the use of robust security measures using modern day crypto techniques to protect the sensitive data from unauthorized access and manipulation Here are some of the potential attack vectors in a Connected car: Telematics Control Unit: Telematics units on a vehicle are the connecting point to the outside world.

They support a variety of wireless technologies such as Wi-Fi, Bluetooth, and Cellular Technologies such as LTE, GSM, CDMA. These technologies

WIRELESS CONNECTIVITY 5G, LTE, 2G, 3G, Bluetooth, Wi-FI SAFETY AND DRIVER AIDS RADAR, GNSS, e Call, ERA-GLONASS,TPMS,RKE, NG-eCall IN-VEHICLE NETWORKS Antennas, Connectors, RF Cables, Ethernet, Optical Fibre INTELLIGENT TRANSPORT SYSTEMS V2X, DSRC, 802. I I p ELECTROMAGNETIC INTERFERENCE OTA, EMC, EMI, Interference Hunting

November 2020 | Telematics Wire | 35

allow the vehicles to communicate with the Cloud, with the Telematics Service providers, OEM Backends. A hacker can use networking hacking techniques such as port scanning, circumventing firewalls to get unauthorized access to the vehicles via these interfaces. A hacker after compromising the servers at a telematics call center could issue engine disable commands to all cars Infotainment System: In-Vehicle Infotainment systems support a wide variety of user Apps. The user Apps provide a variety of services that include access to social media, internet browsing capabilities etc. These internet enabled Infotainment systems serve as a gateway to the car’s internal network enabling hackers to gain control of the critical car functions Unprotected External Interfaces and Debug Ports Modern day automobiles can have a number of external interfaces (wired and wireless) and a number of debug ports such as JTAG, XCP which can allow easy access to ECU resources if not protected.

Hackers gaining access to these ports can corrupt rewriteable flash memory and inject malicious firmware causing the ECU to malfunction

Fig 1: Potential Attack Surface in a Connected Car

Wireless Key Entry Breaking anti-theft systems such as Central locking, Immobilizers, passive keyless entry to gain access to the car Over the Air Firmware Upgrades Downloading malicious applications into the ECU could result in erroneous behavior. Malware in an ECU can even download incorrect navigation maps to mislead the driver. This could be one a lucrative business for cyber-criminals.

In ransomware attacks, a computer is disabled by the hacker until the victim pays a ransom fee to unlock it. A ransomware infection of a car or commercial truck would be extremely disruptive and costly to both individuals and businesses. Therefore, victims would be more inclined to pay – potentially paying more than they would for a PC or phone.

Insecure communication channels Lack of mechanisms to check integrity of messages can result in Execution of unauthorized c o m m a n d s , Eavesdropping and sending spoofed messages to the monitoring ECU, Illegal Odometer Tuning

36 | Telematics Wire | November 2020

Insider Attacks An insider threat is a security risk that originates from within the organization. Anyone who has access to the organization’s confidential data is a potential insider threat. It could be an employee, contractor having access to user credentials and sells those secrets to outsiders for making profit. e-Call Center Attack A hacker with access to Telematic call center servers could issue engine disable commands to all the cars Poor Security Policies, Procedures, Practices Weak Firewall rules, usage of hard coded Keys and passwords, weak keys and passwords, usage of same Keys on all vehicles, lack of access control methods, weak network policy of trusting everyone and every device

Securing a Connected Vehicle The security system inside autonomous connected vehicle shall ensure that technology in the connected Car works 100% of the time without compromising the safety-critical functions. To achieve this a multi-layered, distributed security architecture with a defense-in-depth strategy is needed. The figure below shows a four Layer Security architecture.

Here each layer provides a layer of security contributing to overall defense of the system In order to secure the Connected vehicles from cyber-attacks, the

automotive system shall implement appropriate security controls based on software and hardware cryptography. The security system must ensure that data is protected during its transit, while it is stored, and while it is accessed. There must be mechanism in place to ensure both unauthorized and unintended modifications do not go undetected. Any remote access shall have multi-factor authentication implemented to reduces the risk of identity theft and unauthorized disclosures. All the above can be achieved through a combination of hardware & software features, physical controls, encryption mechanisms, operating procedures, and various combinations of these.

Here are some Security measures to secure vehicle network:

• Recovery after Compromise • Employ security controls at ECU’s and Backend servers to restrict access

Conclusion: A compromised car not only endangers safety of humans but also involves many other consequences both to the owner and to the Car makers. A successful Cyberattack can result in financial losses to the OEM due to forensic investigation costs, loss of sensitive data, impact to business, legal costs, compensation to customers, vehicle recall cost. Fortunately, there are

Internet facing networks, Firewalls, IDPS, Security incident and logging and detection. Implement Security techniques such as Software Signing and Authentication, Secure diagnostics, Secure Communication, Debug port protection.

The modern cryptographic algorithms, when implemented correctly, are highlyresistant to Cyberattacks, however their only weak point is their keys. Therefore, employing robust Key management strategy is very crucial to protect the system from compromise. Last but not

Off Board Network Security • V2X Security • Secure external interfaces • Remote Diagnostics • Target Authentication • Secure Software Updates Over the Air(SOTA) In-Vehicle Network Security • Secure Boot • Secure Flashing • Secure Access • Secure Storage • Secure Onboard Communication(SecOC) • Secure Diagnostics • Key Management • Auditing and Logging • Hardware based Crypto(HSM/SHE) • Machine Security & Tamper protection Automotive Security Standardization • AUTOSAR, EVITA, HIS, NHTSA, C2CCC Cybersecurity Best Procedures and Practices: • Threat Assessment & Risk Management • Threat Modeling • Security by Design • Security Hardening (Secure Coding Practices, MISRA and Cert-C compliance) • Penetration & Fuzz Testing

Fig 2: Secure Platform

many steps that car manufacturers can take to secure the Connected vehicles.

These include deploying Network Security mechanisms - separating the safety critical networks from the

the least, follow industry standards & practices such as NIST/FIPS, EVITA, SHE, ENISA, SAE J3061, IEEE 1609.22016 while developing Security solutions rather than going with proprietary solutions. o

Author Mushabbar Hussain Solution Architect | Cybersecurity KPIT Technologies (UK) Software professional with over 18+ years of experience in embedded product development. Main focus area being Automotive Cybersecurity. Have extensive global exposure across multiple industries such as Automotive, HVAC and Security domain.

November 2020 | Telematics Wire | 37

Industry Insight

IoTs, Wireless Data, OTA updates - Ensuring the Security of the Connected Car Michela Menting ABI Research

T

he automotive industry is becoming increasingly reliant on computing, connectivity, and software to provide functionality and differentiators. This growth has brought cybersecurity to the fore of vehicle design. The key automotive trends that will transform how cybersecurity is applied include: • Vehicle autonomy, which will see the introduction of domain controllers to control advanced ADAS functions and eventually of domain architectures. In addition, robotaxis, where no driver is present in the vehicle and the vehicle is entirely controlled by software, will simultaneously increase the probability of cyberattacks as well as the potential implication of any cyberattacks.

• Vehicle Over-The-Air (OTA) updates will see the secure internal vehicle infrastructure opened up to the outside world. Although vehicle OTA will provide a means to patch faulty software or potential vulnerabilities, the OTA process will need to be provided in a secure manner. With different types of ECUs in a vehicle and challenging CAN constraints, among other issues, vehicle OTA will require new frameworks and hardware security so that it can be implemented in a safe and secure manner.

• The increasing number of devices and applications being connected to the infotainment unit, combined with the incorporation of new connectivity methods such as V2X, will mean that new security measures will be needed to validate connections and separate third-party applications and devices from accessing the core secure vehicle network.

The current approach towards automotive cybersecurity is to prevent access into the vehicle via key remote 38 | Telematics Wire | November 2020

access points: the infotainment unit, the telematics unit, and the OBD-II port.

Current cybersecurity measures used invehicle, namely hardware-based firewalls, application sandboxing, and Secure Hardware Extension (SHE)-specified processors, will not be enough to secure future vehicles. In particular, they do not provide enough consideration for the protection of data that will circulate internally, as well as to and from the vehicle. This is where communication security becomes important.

In many ways, it is the infotainment head unit that has become central to the vehicle experience, and where data plays a crucial role. Over the coming years, more and more valuable data will be present on the vehicle as well as being uploaded to the cloud for additional services. This data will be broad and varied, including real-time location, personal information, and other contextual data related to infotainment experiences. Above all, this data will be valuable and lucrative for OEMs, application developers and service providers.

Cybersecurity as such will need to safeguard not only the protection of personally identifiable information, but also data related to physical processes that may be monitored or actioned remotely. As such, security measures will need to be applied for data at rest (whether in the vehicle or in the backend), but also in motion and especially at the connection level.

The threat actors that may target connected cars are not just of the cybercriminal persuasion. Vehicles are increasingly being connected to thirdparty devices and applications. This includes connection to third-party devices such as handsets and OBDII dongles as well as third-party cloud services to share data between device/service and the vehicle via the head unit. It is those third

parties that also carry a responsibility for safety and security with regards to the data communicated to and from the vehicle. Certainly, there is the further risk of unscrupulous third-party providers that are simply focused on monetization to the detriment of data protection.

This poses an issue in terms of privacy protections for individuals, but can be a functional safety hazard when considering communications between vehicles, road-side units and other connected infrastructure (V2X).

V2X is set to allow vehicles to communicate with other vehicles as well as the surrounding infrastructure. Possible V2X applications are numerous and include, among others: • Autonomous Vehicle Applications: Utilizing V2X as a key sensor for being able to detect other vehicles and stationary objects that are at distance or in a position (i.e., around a corner) that means they cannot be detected by the sensor suite.

• Smart City Applications: Utilizing V2V and V2I to optimize traffic flow, reduce congestion, optimize parking, and charging infrastructure.

• Other Applications: Relaying important information such as road conditions and nearby accidents to drivers and relevant parties such as emergency services.

The potential impact of interference with V2X communications could be significant. As such, automotive stakeholders need to ensure security mechanisms are in place to minimize risks. These can include increased security in the head unit, which is the focal point for all third-party devices and applications connecting to the vehicle.

OTA capabilities render it even more vulnerable and so monitoring during the device’s lifecycle is critical. OEMs should consider the possibility of separating

third-party applications and devices from the core vehicle network.

In addition, new V2X communication domains will need to be secured. The V2X domain will be responsible for connections to other vehicles and infrastructure. Sharing information in the most secure manner between numerous vehicles and infrastructure will require the use of cryptographic keys, and therefore integrated hardware security modules.

Beyond that, there is no doubt that OTA updates will enable OEMs to create and swiftly deploy security patches. OTA in itself is not a protective measure however, but an impact mitigation technique. As a security tool, OTA updates can not only serve to patch vulnerabilities, but also to update intrusion detection and prevention systems.

Although OTA provides a method of mitigating the impact of a potential cyberattack, simultaneously it opens up access to the deeper vehicle network, i.e., secondary ECUs to the outside environment.

Providing suitable security is perhaps the current biggest barrier to widespread adoption of OTA processes. From a cybersecurity point of view, the biggest challenge is that each ECU is different.

Although almost every ECU in a vehicle is capable of being updated, the security and length of time required to update an ECU varies greatly. ECUs have different CPU bandwidth, storage capacities, memory types and sizes, and cryptographic key storage capabilities, meaning that one update method may not applicable to every ECU. Ideally, each secondary ECU would be capable of secure key storage, but in reality this will not be the case. Most keys will likely be stored in SHE implementations or even in the software itself due to the cost of having to provide secure hardware to more than 100 ECUs in the vehicle.

Secure software OTA frameworks specifically designed for the automotive industry such as the Uptane framework will instead be used to provide the security required. Such a framework does not require the use of secure key hardware storage on the secondary ECUs but can still provide a high level of security.

Initially based on the secure framework TUF (The Update Framework, originally introduced in 2010), Uptane is an opensource software update system designed

to provide secure software updates for ground vehicles. It is considered the de facto standard for secure software updates for automotive. The Uptane Alliance was formally instituted to standardize the design. As a result, the Uptane Standard for Design and Implementation Volume 1.0 was released by the IEEE/ISTO Federation in July 2019 (IEEE-ISTO 6100.1.0.0). Currently, the Alliance has teamed up with the Linux Foundation Joint Development Foundation to continue running the project.

It is through these sorts of frameworks that standards and best practices can be developed to provide harmonized approaches to securing processes like OTA updates, but also to protect the data being communicated. Industry advances and cooperation is dynamic in the space.

These include (but are not limited to): • The UNECE Recommendation on Software Update Processes is an initiative of the UNECE set on providing a secure and standardized manner for OTA updates to take place, while still keeping involved parties certified for that exact process.

The recommendation was approved and published in June 2020.

• ISO/SAE DIS 21434 Road vehicles — Cybersecurity engineering is a standard that defines a cybersecurity management and risk-oriented approach to robustly define cybersecurity requirements for E/E systems, hardware and software components, and a life cycle management procedure, including cybersecurity monitoring and the handling of vulnerabilities after the vehicle has been deployed. The standard includes a section on updates and provides information on how to define the basic cybersecurity requirements and attributes of updates, as well as how to securely apply them.

• SAE J3061 Cybersecurity Guidebook for Cyber-Physical Vehicle Systems is a best practice by U.S.-based SAE International, a global standards development organization and professional association of engineers and technical experts in the aerospace, automotive, and commercial-vehicle industries. The guidebook was developed by the SAE’s Vehicle

Cybersecurity Systems Engineering Committee, which is responsible for developing and maintaining recommended practices and information reports in the area of vehicle electrical systems’ security.

J3061 specifically provides the guiding principles for implementing a complete cybersecurity process for incident response and end of life (among others).

This includes maintaining cybersecurity across operational and the servicing phases, such as repair and normal maintenance activities (i.e., connecting to the on-board diagnostics port, telematics system updates, vehicle/ cloud computing interfaces, etc.).

• The Auto-ISAC stems from Presidential Decision Directive 63 (PDD-63) in 1998 on the creation of public-private sector partnerships for the protection of the U.S. critical infrastructure. In 2016, Auto-ISAC published a series of best practices (seven in total, plus an executive summary), which included incident response; collaboration and engagement with appropriate third parties; Threat detection, monitoring, and analysis; and Security development life cycle.

Other relevant standards and guides that deal with data security include NHTSA Cybersecurity Best Practices for Modern Vehicles, IPA Approaches for Vehicle Information Security, PAS 1885:2018 The fundamental principles of automotive cyber security, ENISA Cyber Security and Resilience of Smart Cars.

Critically, the future of the connected vehicle relies very much on the ability to provide security throughout the vehicle’s lifecycle. This means that OTA will play a key role going forward in providing such security. And it is important to remember that the OTA functionality must itself be protected. Data and communication integrity can only be realized through effective end-to-end secure processes. o Author Michela Menting Research Director ABI Research

November 2020 | Telematics Wire | 39

Industry Insight

Standardization and Cyber regulations in mobility Praveen Sasidharan & Bharghavi Rajagopal Deloitte India

T

he automotive ecosystem, which has been constantly evolving and seen to have undergone multiple innovations, is going through yet another transformation in the areas of autonomous vehicle and connectivity.

This transformation is enabled by a combination of multiple technologies - communication, networking, data and vehicle, which have culminated to bring about interesting changes from being human-driven, electromechanical vehicles to autonomous or driverless cars. The transformation though is not limited to only the automotive sector and rather spreads across the entire spectrum from fuel, plants manufacturing the products to dealers and to the whole supply chain itself.

Technology is at the heart of the transformational journey inclusive of a combination of software, communication, networking, artificial intelligence, data and vehicle technology. At the other end, there is also a shift from the traditional ecosystem catering to an area wise connectivity, to a global ecosystem with increased interactions.

Another important aspect is safety, which has been the primary driver for regulations so far in the auto industry. Industry standards, methodologies and quality testing were put in place to structure this aspect where stakeholders from OEMs to Auto component manufacturers were expected to adhere with. Transformation in the auto industry has expanded this realm for standardization for safety rather than limiting to traditional hardware and electronic components, quality management and safety testing. Similar to our experience across IT, Cloud and Mobile sectors, the automotive industry is also the focus area now for both academic researchers and bad actors.

Safety = Hardware Quality + Security + Privacy Safety in the context of the automotive sector needs no further emphasis. Automotive safety has traditionally referred to the physical safety aspects such as traffic collisions. However, with cars now coming equipped with 100s of ECUs and millions of lines of code to control from AC to infotainment to brakes and interacting with other vehicles or Road Side Unit (RSU) and to like tollgates etc. safety has been redefined from the traditional outlook to encompass security and privacy.

The need for security and privacy has been well demonstrated by numerous research and real-life incidents. One such classic example is the hack of Jeep Cherokee by two security researchers.

The hackers were able to control a Jeep on the highway remotely - from their home. They were able to control the climate control system, radio, windshield wipers, display and also kill the engine wirelessly. All this was possible because of the remote access enabled into the Jeep. While the vulnerability which enabled 40 | Telematics Wire | November 2020

the above hack to take place has been fixed, many open security vulnerabilities are lying in the underlying connected ecosystem.(1) Data privacy is another aspect that is of utmost importance considering the amount of data in a connected car, which is related to the person who owns the car or uses the car. Today, connected cars generate 25GB of data per hour. (2) All this data is stored in databases or cloud of OEM’s, cloud providers, component manufacturers and service providers.

Any collaboration, be it within an industry or across, requires standardization to enable the involved players to speak the same language and achieve common goals. The ecosystem described earlier, demands collaborative partnerships cutting across the different technologies and various industries must amplify the need for standardization and calls for regulations in various aspects.

To that effect, some of the questions that the regulators are trying to answer are: 1) What could be the cybersecurity requirements when a car communicates with a Road Side Unit (RSU)?

2) What are the aspects that need to be considered when it comes to the use of current telecom technologies and future 5G technology?

3) How will Over the Air (OTA) updates be managed in a secure manner?

4) How detection and response to security incidents will be handled?

5) How will the end to end integrity of components in the connected car be handled?

6) What framework, standard or methodologies should the auto components manufacturer, service providers and OEM have to adhere to ensure inter-operability and compliance?

7) Who owns the data?

8) Who determines what is private and its various facets?

Automotive regulators are attempting to provide answers to such questions through regulations to bring in standardization.

So far, each country has taken an approach that is suitable for their geography and local requirements when it comes to Automotive security.

For instance in the United States, ‘Federal Motor Vehicle Safety Standards’ is an essential requirement that the automotive manufacturers need to adhere. Canada, on similar lines, follows a regulation called the ‘Canada Motor Safety standards’.

In India, the Motor vehicles Act, 1988 and the Central Motor vehicle rules, 1989 are the two principal regulations for the automotive sector. The AIS certification was established in India along with the CMVR in 1989. These standards are based on the UNECE standards mentioned earlier. (4) One of the regulations, which was released by AIS committee,

EXCEPTIONALLY ROBUST

TOTALLY RELIABLE IP69k

EXTREMELY PRECISE 99.5%

OMNICOMM LLS 5 LEGENDARY SENSOR'S SUCCESSOR

For every business that operates a fleet of vehicles – whether trucks, locomotives or ships – where having a handle on fuel costs is critical.

For every industry that faces unexpected fuel shortages, causing expensive and even life- threatening power interruptions: hospitals, construction sites, manufacturing facilities, bank branches and data centers.

www.omnicomm-world.com sales@omnicomm-world.com

Unlike common capacitive sensors that contain a single measuring tube, OMNICOMM LLS 5 sensors contain two tubes that memorize ‘empty’ and ‘full’ values. The primary tube measures the parameters of the current fuel, while the reference tube stores information about the initial calibration fuel.

The sensor analyzes the difference between the properties of the current and the reference fuel and auto-adjusts proportionally, compensating for any measurement error. Unique FuelScan® technology guarantees unprecedented accuracy of 99.5% in all conditions.

November 2020 | Telematics Wire | 41

was on “Intelligent Transportation Systems (ITS) - Requirements for Public Transport Vehicle Operation” or AIS 140 as it is popularly known. AIS 140 mandates that the public transport vehicle be fitted with Vehicle Location Tracking, Camera Surveillance System and Emergency Request Button. It also mandates that the security and privacy for the ITS are maintained per applicable laws/guidelines of various government authorities.

The society of Indian Automobile manufacturers has also drawn a roadmap for automobile safety standards(3). The roadmap was presented to the Government in January 2002, which received inprinciple approval of the Ministry of Road Transport & Highways.

Based on the consultation, a roadmap has been finalized by the Ministry, and work has commenced on drafting standards and notifications.

Another regulation that has a global reach are the rules developed by ‘World Forum for harmonization of vehicle Regulations’ developed by UNECE. There are 62 participating countries in this forum. Overtime, we can expect an increase in the number of automotive regulations. The call for standardization across the automotive industry is inevitable. The existing regulations will see an inclusion of cybersecurity and privacy aspects similar to UNECE WP.29, which covers cybersecurity holistically.

AuthorS Bharghavi Rajagopal Deputy Manager Deloitte India

Praveen Sasidharan Partner Deloitte India

It is necessary that regulations include various aspects of the vehicle – from pre-production to production to post-production.

As mentioned earlier, the auto industry cannot be restricted to a particular region anymore and a holistic approach needs to apply.

India, which is becoming the hub for global OEMs will benefit by the adoption of global standards. For the Auto OEMs and Auto Component manufacturers in India, rather than waiting for the Indian specific law to happen, it is better to start preparing for compliance to some of the industry best practices and standards like UNECE. Drawing parallel with the IT industry, it took some time for standardizations and agreements for this industry to arrive. We expect to foresee the same churn happening in the space of the auto sector as well.

The good news is, the change is already seen to happen, and it is evolving. The best practices from the IT sector will be quickly adapted in the auto sector, leading to quicker standardization and so an evolved auto sector is to be seen for a newly emerged India.

References https://www.wired.com/2015/07/hackers-remotely-kill-jeephighway/ 2 https://www.tuxera.com/blog/autonomous-cars-300-tb-ofdata-per-year/ (3) <http://www.siam.in/technical-regulation. aspx?mpgid=31&pgidtrail=34> (4) https://www.altran.com/as-content/uploads/ sites/5/2018/01/cybersecurity-in-automotive_position-paper. pdf https://morth.nic.in/sites/default/files/Finalized_Draft_ AIS_140_regarding_Intelligent_Transportation_Systems_.pdf 1

Telematics Wire

Editorial Calendar

Technology Driven | Futuristic Vehicle

MARCH 2021 ISSUE

Connected Vehicle

JANUARY 2021 ISSUE

DECEMBER 2020 ISSUE

Electric Vehicle

Autonomous Vehicle

FEBRUARY 2021 ISSUE

APRIL 2021 ISSUE

Automotive Data

(Storage, Analytics & Monetization)

ADAS

42 | Telematics Wire | November 2020

september 2021 ISSUE

MAY 2021 ISSUE

Emerging Technologies

JUNE 2021 ISSUE

CV2021 Special

JUly 2021 ISSUE

smart & shared mobility

august 2021 ISSUE

insurance telematics

simulation & testing

october 2021 ISSUE

chips & modules + Auto Electronics

Lead Overview

Automotive Cybersecurity – NOT for tomorrow; we need to ACT NOW The current state of Vehicle Cybersecurity in India.

(Reach out to discuss and define protection strategy for your vehicle) Vishal Bajpai SecureThings

I

n 2015, Jeep Cherokee was remotely hacked by two security researchers that created a storm on cyber threat to the vehicles. This triggered a series of events leading to the establishment of ground rules for higher cybersecurity in Automobiles. Since then cybersecurity has gained enough impetus and is now on the critical radar for most concerned stakeholders. Automotive eco-system is going through a major transformation, which we now address as CASE (Connected, Autonomous, Shared Services & Electrification). All these changes are contributing to increasing cyber-attack surfaces in a vehicle. A California based consumer-advocacy group is putting it in starker terms, warning a mass cyberattack against such vehicles could lead to huge casualties. It is projected that by 2024 there could be a $24 billion loss due to cyber-attacks on automotive.

This is a wake-up call for the industry In this automotive transformation era, we see that the vehicles & supply chains are getting more software-centric & technology driven.

A modern vehicle comes with 100 million lines of code that is only going to increase with new technology advancements. The threat to the vehicle eco-system is not limited to a vehicle, entire ecosystem is getting connected. New internet-driven business models are emerging like Ride Share, vehicle ownership is moving towards the leasing model. As the vehicle is being shared, stronger cybersecurity is extremely important. Upcoming Autonomous vehicles plan to use Cloud as an additional computing layer. We’re advancing towards Electric Vehicles & connected infrastructure

like e-Tolls. This entire transformation relies completely on connectivity.

Along with Connectivity, vehicle control is also moving to the machine. The Intelligence is moving from Human to Vehicle, where Autonomous or Connected Vehicles can make human decisions. A vehicle is like multiple computers on wheel where different segments are getting connected that includes – Healthcare services, a growing In-vehicle Marketplace, and connected home appliances via IoT.

Projections show that by the year 2022, 100% of vehicles manufactured will be connected Connectivity is of different kind, a connected vehicle that communicates with external services through different network interfaces as well as within vehicle components & sensors, an Autonomous vehicle that interacts with the environment around them to gather intelligence & electric vehicle that communicate with external interfaces like Charging Station.

We are moving towards an era, where everything will be inter-connected.

Great for society BUT A Cyber Criminal’s delight –it opens so many entry points to enter a vehicle

So what are these threats?

These threats are very real and very dangerous, as you might be completely unaware of an enemy who is keeping an eye on your every move, waiting for an opportunity to attack. Even if a vehicle does not have Connectivity by default, it is still vulnerable as any cybercriminal in the form of a malicious insider or service technician

can enable Connectivity in your vehicle. An attack can be as simple as Vehicle Theft or Ransomware attack to as serious as taking a remote control of the vehicle that can result into human life. Of course, not so much focused on an individual vehicle, but when we talk about shared mobility as well as Over-the-Air (OTA) Update, a mass attack is very much possible. It can directly be related to national security, which is a much bigger concern.

Cyber Threat can impact $1.5 trillion of automotive industry Alarmed? Well, all these are very compelling reasons for us to critically look into the security aspects. Automotive sector in India considered as the backbone of the Indian manufacturing industry that is contributing to 7.5% of GDP. Transportation is a critical infrastructure for any Country. If a major cyber-attack takes place, it can cripple not only the economy but also make it difficult to contain as we do not have an optimized security protocol in place for immediate response. Due to infrastructure setup, in India, we may face a higher threat to human loss. It is critical to safeguard this industry and community from any mass attack.

I will elaborate more of these threats from the perspective of four important mass-attack segments as well as their damage potential.

Mass attack use-cases 1. Connected Vehicle Subsystem: Connectivity puts the vehicles at risk to get attacked remotely - there are multiple connected interfaces available in a vehicle, like Cellular, Wi-Fi, Bluetooth, GPS, RF, voice-command-based systems,

November 2020 | Telematics Wire | 43

etc. These can give an entry point to the cybercriminals to take control of the vehicle while being away at a remote location. Vehicle architecture is such, if cybercriminals can get into the vehicle, they can take complete control of the vehicle. Almost all controls are driven by software communication. A threat can also present itself when cybercriminals implant malware within the vehicle component and put it in dormant state and which can be triggered at any time.

Over-the-Air (OTA) updates can make it a mass threat. After implanting malware, a cybercriminal can trigger the attack on a fleet of vehicles with just a single SMS. That is why, while OTA is very critical for operational efficiency, an equally competent Security measure is required for its success, else it can become a serious issue to CISOs & CEOs. A vehicle is full of electronics, and Hardware Backdoor Entry is another threat that can trigger a mass attack.

2. Two-wheelers & Ride Share: While all the â&#x20AC;&#x2DC;connectivity relatedâ&#x20AC;&#x2122; attacks apply to two-wheelers as well, a big threat to the millions of bikes on the road is via vehicle Electronics. A cybercriminal can hack and convert a regular bike into a remotely controlled one, within minutes.

A cybercriminal can get these 10 min anytime when your bike is parked outside.

The scary part is that the attack can be as dangerous that could result in a human life.

Considering this threat, the Rideshare bikes are at a high risk as it can be easily 44 | Telematics Wire | November 2020

accessed by criminal groups and leave them triggered like a mobile bomb.

Rideshare companies need to give serious thought to embedding layered security within their system.

High the number, Higher the risk- In India, there are almost 34 million vehicles on road, and nearly 22 million vehicles are manufactured every year. Most of these are extremely vulnerable.

3. Mobility: Mobility is primarily driven by the data, generated/captured by the vehicle. Imagine if the data that comes to your Mobility platform is malicious, and the kind of chaos it can create.

Here I would like to take an example of AIS 140 regulation, which was a great step to being able to provide immediate assistance in case a passenger is in a distressing situation. However, consider that a cybercriminal uses a GPS jammer/ spoofer on the vehicle, which costs even less than INR 1000. In such a scenario, the backend system will not have a correct vehicle location. In case of a panic message, all the control agencies may go to a different location, thereby completely fooling the Vehicle Tracking & Geo-fencing system.

Manufacturers use a lot of vehicle data for their research and development of future vehicles. Insurance companies to access driving behavior for insurance products. These can all go haywire, in case of untrusted or malicious data being sent and result in huge monetary losses.

4. Lastly, Electric Vehicles & Charging Infra: EVs are being promoted

in a big way as an initiative towards clean energy. Secure charging infrastructure is a MUST for a successful EV policy. It is possible to attack unsecured EVs through vehicle sensors or charging stations.

Cybercriminals can bypass the BMS to initiate Overcharging or Overheating which would cause the vehicle to catch fire.

Charging stealing can be a monetary loss to the individuals or the business.

This could result in Big Business Loss as well as Brand Image Jeep Cherokee attack costed the company more than 600 million USD, to recall 1.4 million vehicles and fix the issue. Not to mention, how much brand image loss this could have caused. With connected system and subscription based services, Cybercriminals can hack a backend server to impact vehicle warranty & registration violations. In a recent survey taken by Total Dealer Compliance, 84% of consumers said they would not buy a car from a dealership after a data breach.

Another global survey finds that 85% of consumers have big concern on cyber attacks in the connected cars.

Vehicle Cyber Threat has become a CEO issue.

So what is the Right Protection Strategy for Automotive Ecosystem?

Cyber Security CAN NOT be an

afterthought, it must be part of every phase of the system development cycle including hardware requirement and design, system requirements, software design, validation, testing, etc. True protection means end-to-end protection along with an effective strategy to identify and minimize the risk in case of an attack, faster response time as well as information sharing with others to safeguard from similar attacks to minimize the loss.

A vehicle must have multi-layers of protection: • Protection from attacks through external interfaces (e.g. Remote Attacks, OBD II, UBI dongles, etc.)

• Host Security for any runtime attacks on the system (e.g. Buffer overflow attack) • Protection from In-Vehicle Network Attacks (e.g. Detection & Prevention from the single malicious message, sensor-based attacks, etc.)

High Need for Automotive Cybersecurity Regulations in India Regulations are essential for smooth functioning of any system. They strengthen the market, protect the rights and the safety of the citizen. Considering the danger posed by Cyber threats to Automotive, every major country has put a regulation or define a standard.

UNECE (United Nations body) has passed a regulation WP.29 to ensure the security of connected vehicles. 56 countries are a signee to this decree.

There are many more: • UK: “Principles of Vehicle Cyber Security for Connected and Automated Vehicles” mandates the use of cybersecurity for connected vehicles and autonomous vehicles.

• European GDPR stipulates protection of privacy and personal data including location, identity, etc. for which automobile cybersecurity is a necessity.

• ACEA’s framework makes cybersecurity a necessity for all member OEMs (which includes 16 of the world’s largest automobile manufacturers).

• USA: The onus of security of connected vehicles, autonomous vehicles, and mobility providers is on OEMs and component manufacturers according to the regulations such as - US Senate Bipartisan Principles for Automotive Cybersecurity.

India must have a regulation on automotive cybersecurity. We should agree to WP.29. The 2019 amendment to the Motor Vehicle Act empowers the government to enforce a recall of all vehicles which endanger the driver or other road users. Failure to comply can result in a penalty of up to INR 100 Cr or imprisonment up to 1 year, or both. It is not clear if this can cover cybersecurity, if not, India Motor Vehicle Act must include this for the rights and safety of the citizen.

General Liability policies do not cover cyber risks.

Cyber Insurance is another big topic.

Cyber Insurance policies currently available are highly customized for clients in a new and quickly growing market. The Insurance Regulatory and Development Authority of India has set up a panel to explore possibility of a basic standard product structure to provide insurance cover for individuals and establishments to manage their cyber risks.

A Reality Check We have to accept that there are many vulnerabilities exist in the automotive segment. Today the automotive industry is highly driven by software and connectivity and as we naturally keep pace with the evolving technologies, these vulnerabilities are going to grow. A deeper understanding of the attack chain and the right protection mechanism is the only key to solve the problem at hand.

While thinking about adversaries, we must consider all channels, whether it is physical access, remote attacks to the vehicle, malicious insider, rogue service technician, or others. This way of thinking will help in building the right threat model and the right protection strategy. We also need to acknowledge that an attack on one vehicle is not constrained to that particular make or brand but it can be applied across all brands, as the same supplier might be providing the devices to multiple manufacturers. Vehicles and attacks on IT systems are different. You can shut down the machines/servers but you cannot control stopping all the vehicles.

The reality is that we live in an era of cyber-crime. Automotive cyber threat is a serious issue that we cannot take lightly and must address ASAP. We must think about our 1.3 billion fellow countrymen, and how every day, every individual comes closer to such cyber risks. It is required for the safety of them, for their monetary loss. We cannot afford to be reactive, as it can be catastrophic. We MUST ACT NOW. o Author Vishal Bajpai Co-founder and CEO SecureThings Vishal Bajpai, Cofounder and CEO of SecureThings, is a visionary leader, motivator, technology expert and product strategist for the emerging markets. His mission is to create awareness and safeguard society from cyber threats, especially in the automotive eco-system.

Vishal is passionate about autonomous & connected vehicles cyber security in emerging markets, evangelizing and building innovative solutions to solve real problems for customers.

November 2020 | Telematics Wire | 45

Way Forward

Cybersecurity Framework for Cyber Physical Vehicle Systems Pamela Gupta OutSecure

informed about security basics and recent trends in security and privacy. Individuals who develop systems should attend at least one security training class each year.

Security training can help ensure system is created with security and privacy in mind and can also help development teams stay current on security issues.

Basic Concepts

T

here is immense complexity in creating an effective Vehicle Cyber Security approach. It requires a hybrid approach that combines safety and security that includes programs, people, processes, and technologies. An approach for securing Cyber Physical Systems.

Through the entire vehicle lifecycle: Design, Build, Operate, Service and Decommission Additionally, it should include capabilities to dynamically monitor and address risks that may arise in the future.

The vehicle and its entire ecosystem is required to remain protected from full range of security threats.

To add further complexity, the highly connected functionality makes vehicles today, Internet of Things, which have points of risk that can be introduced at many levels.

OutSecure has developed a framework that addresses these challenges.

• This article describes a cybersecurity process framework and guidance to help Organizations Identify and Assess cybersecurity threats • and Design cybersecurity into cyber48 | Telematics Wire | November 2020

physical vehicle systems throughout the entire development lifecycle process.

It is a Risk based & holistic approach to cybersecurity for CPS.

Security Integrated System Development & Deployment (SISDD) Approach: Cybersecurity should be built into the design rather than added on at the end of development.

Theobjective:Buildasystemthatsupports and enforces the necessary authentication, authorization, confidentiality, data integrity, accountability, availability, and nonrepudiation requirements, even when the system is under attack.

Building Cybersecurity into the design requires an appropriate lifecycle process from the concept phase through production, operation, service, and decommissioning.

This document provides a complete lifecycle process framework that may be tailored to a specific requirement.

• Secure design, including the following topics: • Attack surface reduction • Defense in depth • Principle of least privilege • Secure defaults • Threat modeling, including the following topics: • Overview of threat modeling • Design to a threat model • Coding to a threat model • Testing to a threat model • Secure coding SEI CERT C Coding Standard for the C programming language, developed by the CERT Coordination Center to improve the safety, reliability, and security of software systems.

• Buffer overruns • Integer arithmetic errors • Cross-site scripting • SQL injection • Weak cryptography • Managed code issues (C, C++, Misra, Python) • Security testing, including the following topics: • Security testing versus functional testing • Risk assessment • Test methodologies • Test automation

SISDD Training Phase:

Privacy, including the following topics:

All members of system development teams should receive appropriate training to stay

• Types of privacy data • Privacy design best practices

• Risk analysis • Privacy development best practices • Privacy testing best practices

Advanced Concepts The preceding training concepts establish an adequate knowledge baseline for technical personnel. As time and resources permit, it is recommended that you explore other advanced concepts. Examples include (but are not limited to): • Security design and architecture.

• User interface design.

• Security concerns in detail.

• Security response processes.

• Implementing custom threat mitigations.

Security Requirements • All engineers, developers, testers, and program managers must complete at least one security training class each year. Individuals who have not taken a class in the basics of security design, development, and testing must do so.

SISDD Requirements Phase The Risk Assessment section that follows is exclusive to designing a security & safety requirements plan for the CPS system development. It includes identifying: 1. Overall System functionality 2. Components and assets in the components 3. Interfaces between components 4. Threat modeling of each component’s assets and interfaces.

Note: Some of the components may be complete System of Systems “SoS. They require ‘risk model’ analysis that considers both the impact to each system objective individually and the SoS

objective as a whole

Security Requirements • System Security portfolio • The portfolio system can track information, such as contacts, dependencies, deployment considerations, milestones, testing information and history, locations of relevant documents, and tasks and security controls used during the system life cycle. Ideally, the portfolio would feature support, such as automated notification if the system is not in compliance with required (and, as appropriate—optional) controls.

• System risk assessment • System risk level is determined based on a questionnaire filled out by the system team. This determines the SDL- tasks the system owner must complete and is used to determine if the system is in scope for a security and privacy assessment.

The output of this phase dictates the

degree of oversight from a security SME. Questions in the assessment are weighted together into an overall “score,” while questions may dictate a review regardless of the overall “score.” This approach ensures consistency and reputability combined with flexibility. Experience has shown that a “one-size-fits-all” approach is not effective.

SISDD Design Phase The Design phase is crucial to ensure that the system is “secure by design” and compliant with security and privacy policies and standards. As with the standard SDL, threat modeling is crucial to accomplishing this, although the SDLdistinguishes itself by taking a more assetcentric approach to creating the threat model. Threat modeling evaluates the threats and vulnerabilities that exist in the project’s environment or that result from interaction with other systems.

You cannot consider the Design phase complete unless you have a threat model or

November 2020 | Telematics Wire | 49

design features of your system before you start the development phase. This allows you to identify and fix potential vulnerabilities before they can be exploited and before the fix requires a substantial reengineering effort.

Essentially this results in a reduced attack surface exposed by systems, thus increasing the security of the user and the system.

Important design areas to be reviewed during this task are the OWASP top ten for IoT and IEEE: Avoiding the top 10 security flaws

SISDD Build Phase

models that include such considerations.

Threat models are critical components of the Design phase and reference a project’s functional and design specifications to describe vulnerabilities and mitigations.

The threat actor(s) gain access to the assets via attack vectors and vulnerabilities present in the technology components that house or provide direct access to the targeted components. Security controls are applied to the technology components with the intent to counter or mitigate the vulnerabilities and/or attack vectors used by the threat actors, thereby protecting the assets.

We suggest using Microsoft SDL Threat Modeling Tool to select, implement, evaluate and determine gaps in security controls at the application, system, infrastructure and enterprise levels. It also enables the developers to – • Communicate about the security design of their systems • Analyze those designs for potential security issues using a proven methodology • Suggest and manage mitigations for security issues Microsoft Threat Modeling Tool 2016 comes with a base set of threat definitions using STRIDE categories – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. In addition there is an option to add threats related to specific domains.

50 | Telematics Wire | November 2020

Design Reviews Conduct design reviews of high-risk systems by a security SME to ensure that the design conforms to security/privacy standards and policies. The advantages of this include: • An architecture and design review helps you validate the security-related

The Build & Implementation Review includes the analysis activities and results that affect the implementations at the hardware and software levels.

This would be followed by the verification and validation review to help ensure that the system was designed and developed according to the requirements and that the Cybersecurity Controls are appropriate and work as intended; These reviews may be conducted by an team of technical experts that should ideally be independent of the feature development. To maintain consistency

and completeness across the feature development, it is recommended that this same 3-4 person team participates in all of the reviews throughout the system development. The results of each review may be a pass, or a conditional pass (rework required).

A gate review should be completed successfully prior to exiting the gate and moving on to the next phase.

Technical “gate” review concept is to be used - review is considered a gate to the next phase and is performed at the end of the development phase being completed,

SISDD Security, Safety Testing & Integration Phase This phase performs a validation and testing on the facets relevant: • Functional • Business • Human • Trustworthiness • Data • Timing • Boundaries • Composition • Lifecycle

Hardware Level Vulnerability Testing and Penetration Testing Cybersecurity vulnerability testing and/ or penetration testing helps to determine whether the hardware has been secured against a creative intelligent threat, such as a skilled human attacker. Testing helps determine the amount of residual risk that remains after Cybersecurity controls have been applied. It may not be possible to eliminate all risk; some risk may need to be accepted. The test results and residual risk are documented, and an individual with the authority to accept the residual risk will determine whether the risk is acceptable or whether additional Cybersecurity design work and controls are needed to lower the risk to an acceptable level. The documentation package for this stage may also include a plan of action for addressing the residual risk. For example, a particular risk could be acceptable if a policy and procedures were created that made owners/operators or maintenance personnel aware of the potential risk and provided instructions for avoiding it.

Hardware level vulnerability testing should seek to verify that

known vulnerabilities and potential vulnerabilities have been mitigated. The test methodology would check against a list of known hardware vulnerabilities and their recommended mitigations to ensure the corresponding Cybersecurity controls have been implemented and are working properly. Hardware level penetration testing should simulate the actions of an attacker or attackers attempting to circumvent Cybersecurity Controls and gain control over the system. Penetration testing can be carried out by a range of simulated attackers having novice to expert skillsets and attacks can simulate attackers having increased knowledge of the target system with each attack or having increasingly advanced attack tools, until an attack is successful, which helps define the system’s threshold of resistance to attack.

Hardware vulnerability testing and penetration testing may begin as soon as a working prototype is available, and the testing should be repeated at key points during the development lifecycle.

Vulnerability and penetration testing can be performed by personnel on an internal Cybersecurity test team as a baseline evaluation, but a qualified, independent entity should ultimately be engaged for this testing to identify issues that an internal team may miss.

REFERENCES 1. ISO 26262 Part 8 First Edition, “Supporting Processes, Road Vehicles – Functional Safety”, 11-15-2011.

2. Barbara J. Czerny. “System Security and System Safety Engineering: Differences and Similarities and a System Security Engineering Process Based on the ISO 26262 Process Framework”, SAE Technical Paper 2013-01-1419, SAE World Congress and Exhibition, 2013.

3. B. Potter. ‘Microsoft SDL Threat Modelling Tool’. In: Network Security 2009.1 (2009), pp. 15–18. ISSN: 1353-4858.

4. Iván Arce, Kathleen Clark-Fisher, Neil Daswani, Jim DelGrosso, Danny Dhillon, Christoph Kern, Tadayoshi Kohno, Carl Landwehr, Gary McGraw, Brook Schoenfield, Margo Seltzer, Diomidis Spinellis, Izar Tarandach, and Jacob West. “Avoiding the Top 10 Software Security Design Flaws”, IEEE Computer Society, 2014.

5. OWASP Internet of Things Project.

6. ISO (International Organization for Standardization). “ISO/IEC 27001: - Information technology – Security techniques - Information security management systems - Requirements”.

International Organization for Standardization. 27 January 2015.

7. ISO (International Organization for Standardization). “ISO/IEC 27002: Information Technology – Security Techniques. Code of Practice for Information Security Controls” 2008.12.

ISO (International Organization for Standardization). “ISO/IEC 27001: - Information technology – Security techniques - Information security management systems - Requirements”.

International Organization for standardization. 27 January 2015.

8. SURFACE VEHICLE RECOMMENDED PRACTICE Issued 2016-01 Cybersecurity Guidebook for CyberPhysical Vehicle Systems Author Pamela Gupta President OutSecure

November 2020 | Telematics Wire | 51

Perspective

Today’s posture of cybersecurity in the automotive industry Aditya Nepalia Tata Consultancy Services

I

n past 10 years automobile industry has completely revolutionised by providing us amazing vehicles. With increased connectivity, improved comfort, road safety and connivence that includes hundreds of electrical components. Definitely that has made our lives more easy but makes it more complex and vulnerable to attacks. Right now if we look at the auto industry we are sure that they are going to increase the connectivity and functionality that will definitely increase the vulnerabilities and automotive cybersecurity risk.

Let’s dig little bit down into some technicality related to connected cars.

A car uses different bus protocols that is responsible for the transfer of the packets through the network of the vehicle. The behaviour of the vehicle is controlled by plenty of sensors and several networks that are communicating on these bus systems and sending messages. These network has two kinds of bus lines.

High-speed bus lines that are responsible for braking and RPM management. Low speed bus lines responsible for the A/C control and door locking.

Today’s modern vehicles contains plenty of embedded systems and CAN is a simplified protocol used in the automobile industry during manufacturing. By using the CAN protocol the electronic control units (ECUs) communicates to each other. CAN can be easily located in the vehicle cables, the CAN wires run through the vehicle

and connect between the ECUs and other sensors. CAN nodes are connected on two wires, CAN High CANH and CAN Low CANL that are twisted pair cable terminated with 120Ω resistance to prevent the signal reflection.

The CAN communication protocol ISO-11898:2003 explains how information is communicated across devices within a network and also complies with the layers defined in the Open Systems Interconnection (OSI) model.

The physical layer of the model defines the interaction happening between the devices that are connected physically. Also this layers is responsible for the bit encoding and decoding, bit timing, synchronisation processes. Data Link Layer is responsible for the interaction of data with the protocol in terms of checking, message receiving and sending.

Last is the application layer that is responsible for the application of CAN device.

The CAN architecture has three components. First we have the microcontroller unit(MCU) which is the host controller responsible for sending and receiving data. Second we have the CAN controller which is responsible for error detection and handling, reception and transmission. Third we have the CAN transceiver which is responsible for converting the CAN controller serial data into bus compatible level before sending on CAN Bus and vice versa.

Author Aditya Nepalia IT Analyst- Cyber Security Tata Consultancy Services Aditya Nepalia has 9 years of IT Security experience in various fields including threat intelligence, incident response, vulnerability management and cyber threat analysis. Currently working in TCS under Cyber Security Managed Services project for network and web security. Always enthusiastic for learning new trends in cyber security and a formula 1 fanatic.

52 | Telematics Wire | November 2020

This CAN bus connection can be easily exploited by the attacker by fixing a malicious device which can track the movement of the vehicle, enabling remote connectivity and send packets directly to the CAN bus.

A cyberattack on a vehicle not only affects the car driver’s data privacy but also puts his physical safety on risk along with car’s operation. At a high level attacker could shut down, re-route GPS signal, unlock, steal, track or remotely take over a vehicle.

Further the attacker could exploit the cellular connection in a vehicle to access the internal network remotely from anywhere and then track vehicles movement. The probability of the attack increases with the use of Bluetooth and Wi-Fi in vehicle. The attacker can execute code or exploit a flaw in the Bluetooth stack or jam the Bluetooth device itself. By attacking the WiFi connection the attacker can change the WiFi password, access the vehicle network from a large distance or install malicious code in the infotainment unit.

All the above problems can be effectively solved by using encryption, authentication and protecting the communication at different levels. All the unauthorised connections to the vehicles should be blocked, SSL/TLS certificates should be used during communication between the devices on the vehicle that can provide encryption and secured communication. On the customer side there can be few important steps that can be followed to safeguard your vehicle from attacker. That includes creating complex and unique passwords that comes with default passwords or the GPS apps, enabling GPS when ever needed and keeping vehicle’s software updated along with latest patches to get protection from known threats.

So with more and more innovations and developments in the automotive industry efforts have to be made from both the manufacture and consumer side for a better and protective world. o

Lead Article

Cybersecurity in Vehicle Product Development Cycle Eduardo Maia KPIT Technologies

T

he wave of innovation in automotive industry is bringing more safety, smarter driving assistance and even more connectivity, launching the vehicle in the IoT (Internet of Things) Era, where the vehicle is the new ‘thing’, a connected thing even more efficient than ever before, but also, introducing more cyber risks as inexorable consequence.

We´ve seen a couple of initiatives in automotive industry to reach higher security and cybersecurity levels in its products in order to cover all this driving automation and connectivity in a secure way. This kind of industry is renowned by its inertia to move forward to big changes, but fortunately, with a good market competition, the companies must speed this change up in its traditional processes. or at least, try to do it, otherwise they will be left behind the scenes, since safety and security is crucial for its brands images.

One big step of OEMS and Tiers1´s to it, was the creation of AUTO ISAC community in 2014, where all associated partners can share and analyze intelligence about cybersecurity risks to the vehicle, and collectively bring values and capabilities in cybersecurity across the industry.

The resulting of this effort and others around the globe was the launching of standards and guidelines in the area, one great example was SAE J3061, published in 2016. This standard comprises fundamentally in a framework for a lifecycle process to incorporate cyber security into automotive cyber-physical systems, highlighting the importance of cyber security throughout product development cycle, from Concept and

Design to product´s end of life. It´s possible to say as ISO26262 means for critical safety systems as J3061 means for automotive cyber physical protection, they are complementary to meet safety and security into vehicle development systems.

There are 3 (three) major phases of guiding principles; Concept and Design, Development and Validation, Incident Response and Product ´s end of life.

In this article, some steps of some of the stages will be presented with some practical examples, in this way, the reader could materialize some concepts as well as realize the complexity to adopt practices in overall development phases.

One of the basics steps from the first phase starts from security assessment, the main idea of this task is to determine the assets to be protected, identifying physical and trust boundaries of the system, considering: authenticity, integrity, confidentiality and so on, as well as determine the security level of possible threats of each asset considering attack probability and severity.

This evaluation process in concept phase is called TARA (Threat Analysis and Risk assessment), the resulting of this process is

the potential threats and assets rated with its associated risks.

Usually the frameworks and guidelines like J3061, provides suggestions for methods and techniques for TARA, is possible to highlight OCTAVE, ETSI and E-safety Vehicle Intrusion Protected Applications EVITA. Besides its recommendations in some standards, exists other approaches which may be used, each method have its own probability and severity classes, as well as risk matrix to support TARA rating.

After the assessment, the idea is to keep tracking the assets into Concept and Design, analogous for traditional functional requirements in traditional V-Cycle, the requirements are the main output, but with security as a goal. For each system and assets mapped in previous phase, is possible to set protection goals and specific requirements to cover and minimize possible systems flaws, which could compromise the assets and for consequences compromises the vehicle or even the car driver in somehow. This process starts with what we called as

Image 1- Security Development Cycle

November 2020 | Telematics Wire | 53

Asset

Attack scenario Modifying the Infotainment firmware in Infotainment ECU Software Integrity Exploit known OS vulnerabilities Remote Control Functions

Threat

Effect

Probability

Severity

Risks

Tampering

Take control of system ECU operations

7 (1+2+2+2)

4

Medium

Trojan or rootkit installation

Take control of system ECU operations/Acess data

9 (2+1+3+3)

4

High

Man-in-the-middle

Password eavesdropping for remote connection

Hijack established connection

8 (1+1+3+3)

2

Medium

Brute Force

Password revealing

Normal Operation disturbance

9 (2+1+3+3)

4

High

Table 1 – Automotive TARA example

• Asset: Vehicle Network • Goal: Ensure network availability Requirements that may be used as countermeasures: • Isolate and separate the vehicle networks: In order to avoid the vehicle network compromising due and infotainment ECU hacking for example, secure gateways with firewalls may be used, allowing only authorized messages ID from Ethernet from telematics domain being gated to Vehicle Safety CAN network, also it could allow only authorized critical diagnostic services with authentication and so on.

• Apply IDS (Intrusion Detection System) on Vehicle network: In modern vehicle architectures with

Image 2 – Simplified logical structure of SHE

Security by Design, it means the product and systems is designed considering security from its birth.

Follow some examples of security Goals and system requirements: • Asset: ECU Software • Goal: Ensure a secure software Requirements that may be used as countermeasures: • Secure boot for the OS (Operation system): ECU (Electronic Control unit) hardware shall be based security with a secure environment like SHE – Secure Hardware extension on chip, in this case, is required a boot in a specific ECU which can assure in a secure environment, shifting the control of cryptographic keys from a software mechanism to a hardware one, therefore, providing hardware protection of these keys.

54 | Telematics Wire | November 2020

Image 3: Vehicle network protection

Image 4 – Trusted communication

central gateways for example, may be possible to install IDS systems on it, in order to monitoring Vehicle CAN network behavior and detect possible anomalies and CAN network compromising due an ECU affected by malicious code. The current Market IDS vehicle systems used AI (artificial intelligence) / Machine Learning algorithms to detect it.

• Asset: Remote Software updating (SOTA) • Goal: Ensure authenticity with right partner Requirements that may be used as countermeasures: • Use certificates, asymmetric encryption (private/public key) and challenges protocols for Software updating partner authentication.

Since Concept and Design phase has been finished and product/system requirements completed, it´s time for security implementation itself, Finally, is possible to say it’s time for development and coding the product, the main goal is avoid design and code errors in implementation.

For Software development, some approaches may be used in order to minimize the risk of non-secure implementation, usually is possible to find general recommendations in specific security standards like CERT C, and for Hardware security, SAE J3101 can be a good source for consulting.

Follow some recommendations examples following standards and guidelines: • Recommendation of hardened OS with secure partitioning, avoiding embedded Linux for example due its complexity, rapid change and security gaps like NULL function pointer,

which can make easier for malicious code injection.

• The usage of rigorous static code analysis: tools such as Polyspace, Coverity and Klocwork covers many security checks in order to avoid common programming mistakes like memory access outbound areas, noninitialized variables, buffers overflows, zero division etc.

• Deployment of a secure boot strategy verifying with core root of trust ex: pre burned cryptographic Keys.

Despite of all this kind of recommendations, the most important thing is the engagement of development team on those practices, as well as a good and specialized training and certifications, to be succeed on this task, the people is the key factor.

After product released by development team, it’s time for product validation, the idea in this phase is to abuse in applying different tools for cyber security testing and hardening, in this step is really necessary to have a “red team” specialized in testing which didn´t participate in product development.

The most usual test tools used are: • Static code analyzer: Tool used to analyze source code before a program is run, usually checking coding rules, security standards, code metrics, and find bugs related to it, some examples of errors covered by this kind of tool are buffer overflows, division by zero, out of bound arrays index, noninitializer punters and so on.

• Dynamic Code Analyzer: Relies on studying how the code behaves during execution, being able to find security issues caused by the code’s interaction with other system components, to be successful on dynamic analyzes is necessary to

cover all system inputs testing for errors stimulation, for this reason dynamic testing is so far more complex compared with static one.

• Network Traffic Analyzer: It is used for network troubleshooting, analysis, software and communications protocol development, with this tool is possible to act as a sniffer in automotive Wi-Fi system for example and discover uncovered functionalities and backdoors.

• Exploit tester: Testing tools which exploits system flaws with a large database of it, for example some Linux distribution have known flaws in some specific port, so if this port is opened on Infotainment system for example, it can be exploited and allow root access.

• Fuzz Tester: Is a dynamic test which consists in High volumes of random or malformed data in a system, for automotive, it can be used to stress CAN network data and observe the resulting.

There are a lot of more security test tools to be used in validation, like encryption crackers and vulnerability scanners, but again, the point is to have a strong security validation team able to be trained and updated with most recent market tools.

The final step of Development and Validation is the system security certification, the OEMs used to hire external companies to perform penetration tests on their systems and vehicles, in this way is assured a security testing with a different mindset, closer to a real hacker mind. The hiring form of this job can be done in three approaches: Black, Grey or White Box approach.

• Black Box: This approach is the

November 2020 | Telematics Wire | 55

Technical Article closest to an real external attack, as no information from the client is needed by the test analyst therefore, all and any type of information for performing a Black Box test is acquired through specific hacking techniques on the target’s available features and services. ex: Infotainment bench test given to supplier or even the entire vehicle and nothing more.

• White Box: All systems that are included in the scope of the intrusion test, and other access information to them, are provided so that, extensive and more comprehensive tests can be carried out, OEM usually delivery the source code files to Pentest supplier in this approach.

• Grey Box: This approach is a mix between the black and white, some system information is given to the test analyst in additional to the component itself, like internal technical specifications, software image files and so on.

There is no best penetrating test scope, the most suitable can vary for each project, due its timing and complexity, in OEMs the components (ECUs) and systems testing can have a different approach from entire Vehicle testing, but there is no rule for it.

After this audition/certification, the product can be launched to the market, from this point the automaker has to monitor its products on the roads, this phase is the Incident and product end of life, for this task, a SOC (Security operation center) with an incident response team may be establish, if their vehicles are equipped with intrusion detection systems for example, it may be integrated with it, assuring rapid incident responses and analysis.

Other program that some OEMs have been used after vehicles launches, is the adoption of Bug Bounty programs, where the public in general can be rewarded by finding vehicles security vulnerabilities, of course with a confidentiality agreement, in this way, the companies can actuate in advance for possible future exploitation. Tesla, GM and FCA has used this approach in last few years.

Security needs to be an integrated part of product life cycle, from its birth to death, assure security throughout all product lifecycle is a very complex and hard way, but extremely necessary to protect companies’ images and its receipts against hacking.

Is no doubt that is very hard for this companies to achieve this state of security engineering, but somehow, they should get used to it, laws regulating cybersecurity in automotive industry have emerged in recent times, certainly it is a path with no return. o

Author Eduardo Maia Automotive Software Engineer KPIT Technologies Electro electronic engineer with Embedded Systems specialization, 10 years of experience based on automotive and semiconductor industry, Head of Cybersecurity strategy in LATAM market for 2 years in OEM, working with secure software development process and methods, security systems and product development. Currently working as an automotive software development lead.

56 | Telematics Wire | November 2020

Foundations for Automotive Cyber Security: A brief guide Jagannath Tiwari Marelli India Pvt. Ltd.

It’s a fast moving world, isn’t it?

And vehicles in today’s world are faster. With the Speed one more thing that is increasing is the technological aspects of today’s automotive industry. It looks Day by day vehicle are becoming more user friendly but from and Automotive engineer point view it’s becoming more and more complex.

Connectivity is becoming an important aspect of new era mobility. In the world of Internet of things and Big-Data connection to the external world is prominent. But with more exchange of data to the external world system become more vulnerable.

The connected cars are equipped with a number of new technologies and features that are not possible without an Internet connection. For example, drivers now have the possibility to receive service information and traffic reports through the vehicle’s dedicated cellular connection. They also have the possibility to connect their smart-phone to the vehicle (Bluetooth, Wi-Fi) and use its Internet connection to enable some of the new features of the vehicle’s entertainment center. Through this center they can browse the web, access social networks, stream on-line content, etc.

Many other services exist depending on the vehicle type and manufacturer.

According to the Business Insider report, there will be 380 million connected cars on the road by the year 2021.

Even though the connection to the outside world enables many new services, it also exposes the car and its software to a potential remote attack. There has already been a number of successful cyber-attacks on connected vehicles such as the attacks on Jeep Cherokee, Tesla S model, Nissan electric car and Chevrolet Corvette. As the production of these vehicles increases, so will the importance of securing them.

How an Attacker Gets in.

It is important to understand about the attack surfaces (Figure 2) which are exposed and can be used for the attacked. In modern vehicle you will easily find Server connections, Mobile Apps, Cellular network connection, Keyless entry, OBD port, Infotainment system, Wi-Fi Connectivity, Bluetooth, etc. for providing the accessibility to the external world data or means to change the information to the external world and

manufacturer, business owner, etc.).

Owners want to protect assets, anything that has some value in the product or service (data, code, reputation, etc.).

Than we have threat agents, a person (malicious hacker, government, etc.) that can manifest a threat, anything that is capable of acting against an asset in a manner that can result in harm. To manifest a threat, the threat agents will explore vulnerabilities (weakness in the system) via an attack vector, a method or pathway used by the threat agent to access or penetrate the target system.

Security as a process throughout Product life cycle: ISO 21434 overview Figure 1

any of these can act as the attack surface for a hacker.

Let’s take an example of Vehicle Cluster (Figure 3). We will analyze Instrument Panel Cluster (IPC) in the below given item to understand what can be the possible attack surfaces, how they can be attacked by some hacker and what can be possible effects of these attack.

The system is simplified and abstracted in order to illustrate activities.

Note: The example and its work products are provided for illustrative purposes only and are not intended to imply any particular approach for practical use.

So to understand the complete picture of attack surfaces focusing just on IPC can be a wrong approach. We need to look at complete system which provide the open door for the attacker and a possible vulnerability. Above figure provide a high level model of the IPC interacting with Infotainment system and Gateway ECU. Below in the table there are some possible attack surfaces and how they can be used for attacks are detailed. IPC do not have any direct interface with the external world but still it could be possible to compromise the features of IPC through vulnerability in the externally communicating ECUs like Infotainment or Gateway ECU. IVI and Gateway can have Wi-Fi, Bluetooth, GPS connection, LTE, Multimedia Playback, USB ports etc., all these can act as the

attack surfaces if not properly managed.

Analyzing what attacks are possible from these attack surfaces some are listed below (Table 1).

Now after the above analysis of the attack surface and the methods let’s understand that what can be the possible functional effects of them in Table 2.

These can be possibilities how an attack can be performed by a hacker.

MITRE ATT&CK® is a globallyaccessible knowledge base of adversary tactics and techniques based on realworld observations. Which can be accessed and used to understand what kind of attacks are possible on a specific attack surface.

Security Concept: (Figure 4) Security is all about risk mitigation.

We have owners, those who benefit from a product or service (user,

It’s a common misconception that cyber security is all about technology (hardware and software). Technology is obviously a massive part of cyber security, but alone it is not enough to protect from modern cyber threats.

Processes are key to the implementation of an effective cyber Security strategy.

Processes are crucial in defining how the Organization’s activities, roles and documentation are used to mitigate the risks. Processes need to adapt with quickly changing cyber threats (Figure 5).

ISO 21434 helps us defining Cyber security policies and Process, manage cybersecurity Risk and Foster Cybersecurity culture.

It supersedes and expands on the same basic framework developed by SAE J3061™: Cybersecurity Guidebook for Cyber-Physical Vehicle Systems.

ISO 21434 addresses the cyber security within the Vehicles and enables to keep up with the changing technology and

Figure 2

November 2020 | Telematics Wire | 57

IVI (In vehicle Infotenment)

CAN 1

CAN 2

Gateway

IPC

Figure 3

security management as well for project related cyber security amendment.

Continuous Cyber Security Activities (Clause 7): defines the cyber security activities need to be performed during all the phases of the product lifecycle.

This includes Cyber Security monitoring, Cyber Security event

Â

Attack surface

Possible Attacks

Methods(example)

Attack Class

1

Short-range wireless communication: -> Wi-Fi or Bluetooth

->Packet sniffing -> Jamming -> MITM -> Protocol-related exploits

-> A port scan Can show vulnerabilities on the port Deniel of Service, such as service listening without valid credentals. infromation Disclosure,

2

Long-range wireless communication: -> cellular radio (3G/4G/5G).

-> GPS

-> GPS Tracking Apps -> GPS spoofing

-> Default user account password found in GPS tracker reverse apps (ProTrack and iTrack) by reverse engineering. engineering, -> GPS spoofing by A low-cost portable GPS spoofing spoofer

3

Multimedia Playback: -> CD-ROM/DVD-ROM, local multimedia file storedin USB sticks/SD card.

-> Audio over bluetooth.

-> Apple Carplay/Google Android Auto.

-> UPnP(universal Plug and Play)

Specially prepared media files can be used to tamper media engine services, Bluetooth and wi-fi stacks.

Use Trojon CD to Hack car: Social by adding extra code to a digital music file, Engineering, reasearchers were able to turn a song burned to CD Tampering into a trojon horse

4

USB Port

Media playback via USB, Frmware/Software updates via USB, Run shell script or install and install unauthorized software via USB

Maliciously crafted USB device,

Social Engneering

Table 1

attack methods. Its help building a common understanding throughout the supply chain by providing Vocabulary, Objectives, requirement and guidelines.

Letâ&#x20AC;&#x2122;s briefly see different clauses of the ISO and their major takeaways.

Attck Surface effect Short-range wireless communication: Wi-Fi or Bluetooth

Management of Cyber Security (Clause 5 and 6): These clause realizes the requirements and recommendations related to the implementation of the organizational cyber security policies, rules and processes for overall cyber

Attack Class

assessment, Vulnerability analysis, Vulnerability Management.

Risk Assessment methods (Clause 8): Defines the methods for determining the cyber security risk. All Risk Scenarios should be assessed against

Functional Effect 1: Display worng data for incomming calls

Deniel of Service, infromation Disclosure,

2: Display call allert without actual call allert 3: Sending messages with high frequency 4: grenerating BusOFF condition 5: get Confidential user infromation

Long-range wireless communication: cellular radio (3G/4G/5G). GPS Multimedia Playback: -> CD-ROM/DVD-ROM, local multimedia file storedin USB sticks/SD card.

-> Audio over bluetooth.

-> Apple Carplay/Google Android Auto.

-> UPnP(universal Plug and Play)

Compromises to the internal CAN network

reverse engineering, spoofing

1: Sending wrong turn by turn indication to cluster 2: Alter route to destination or even destination 3:Change navigation infromation such as time or distance 1: Show Slangs on screen

Social Engineering, Tampering

2: Alter the functional behavioursuch as playtime, wrong song or change in AM/FM frequecy.

Table 2

58 | Telematics Wire | November 2020

1: data Integrity 2: data Authenticity 3: error generation 4: periodicity(buffer overflow) 5: Availablity 6: Confidentiality

properties can lead to damage to an itemâ&#x20AC;&#x2122;s stakeholder. Risk Assessment Methods of ISO 21434 can be followed to understand the methodology of identifying the asset of the item and do Threat and risk assessment (TARA).

For TARA it is important to have details of Item, Item-Boundary, function and Architectural design.

In Clause 8 the risk assessment methods defined make use of the following generic modules that can be called systematically, and from any point in the lifecycle: â&#x20AC;˘ Asset Identification: Identification of damage scenarios and assets of an item or component.

One way can be to first identify the components and their functionality of the item. Define all the assets

Figure 4

SFOP: Safety, Financial, Operational, and Privacy. Impact Ratings for Each Impact Category is defined in terms of Severe, Major, Moderate, Negligible.

Allows for the following approaches for Risk Assessment: Attack Potentialbased, Attack Vector-based, CVSS2 Concept Phase (Clause 9): This clause defines the item which is required to perform the subsequent activities. It also provides cyber security risk determination and defines cyber security goals.

Product Development (Clause 10): This clause corresponds to the left leg of the V model defining the specification of cyber security and architectural design and the right leg is about integration and verification activities.

Cyber security Validation (Clause 11): Describes cyber security validation of an item at the vehicle level.

Production (Clause 12): Provide requirements for security aspect of fabrication, Assembly and/or calibration of an item or component.

Operation and maintenance (Clause 13): Describes activities need to be performed after the production which includes incident response and updates to an item or component.

Decommissioning (Clause 14): Describes considerations that relates to decommissioning of an item or component.

Distributed Activities (Clause 15): Supplier management requirements.

Following the V model for development, the figure 6 shows the mapping of the

Figure 5

nominal V development workflow and ISO 21434 workflow for product development and the corresponding phases.

Designing a secure Automotive Product: Performing Threat Assessment and Risk Analysis (TARA) The main aspect of designing a secure product can be to identify the assets which need to be protected. ISO 21434 define the asset as: Something for which the compromise of its cybersecurity

and mention the cyber security property that asset possesses in terms of Confidentiality, Integrity and availability. Than due to compromise of that asset what damage can be done thus it can be understood that whether that asset need to be considered for threat and Risk analysis. ISO 21434 ANNEX G provides an example of how to identify an asset (Figure 7).

On the identified assets the Threat Analysis and Risk Assessment is done from which the cyber security goals are

November 2020 | Telematics Wire | 59

Figure 6

Component/ Message

Function

Asset

Cyber Security Property C I

Damage Scenario No.

Damage Scenario

A

Figure 7

Damage Scenario No

Source: ISO-21434

Damage Scenario No.

Threat Scenario

Threat Scenario No.

Figure 8

Source: ISO-21434

ISO 21434 ANNEX G illustrates an example of deriving the threat scenario from the Damage scenario (Figure 8).

• Impact Rating: Estimation of the magnitude of damage or physical harm associated with a damage scenario.

It is very important to understand the impact to your system if the threat is exercised. By analyzing the damage scenario through the brain storming itself it can be identified that what impact will the threat will have. ISO 21434 define the basic impact categories As: Safety, Privacy, Operational, and Financial (SPOF). Though these are core impact categories but depending on the stakeholder these categories can be extended Loss of Image, Loss of intellectual property etc. Also the impact rating need to mentioned with

identified and thus the cyber security requirements are defined.

• Threat Scenario Identification: The identification of threat scenarios to the cybersecurity properties of the assets under analysis.

There can be various methods to the Threat modeling such as STRIDE. ISO 21434 do not provide any specific method but calls for the Security Engineer decision for selecting the methods. By having an understanding of the damage scenario by brain storming also the threat caused by that damage can be analyzed. It is also important to understand that one damage scenario can result into multiple threat scenarios. A better threat analysis can also include the details of the threat agent, methods, tools, entry point etc. should also be documented for better risk assessment.

Component/ Message

Identified Asset for Safety

Function/ Message

Asset

Figure 9

60 | Telematics Wire | November 2020

Damage Scenario No.

Damage Scenario

the category which are defined in terms of: Sever, Major, Moderate, Negligible.

ISO 21434 ANNEX G illustrates an example of identifying the impact, impact category and impact level derived from the damage scenario (Figure 9).

• Attack Path Analysis: Identification and linking of potential attack paths to one or more threat scenarios It is important to identify the attack path as it leads us to possible vulnerability that an attack surface has.

There can be two methodology to do the attack path analysis 1: Top Down Approach: Attack paths are identified base on the experience with known vulnerabilities of the similar system.

There are various approached such as attack trees, attack graph, STRIDE etc...

2: Bottom Up Approach: It is also called inductive approach. Here analysis of

Impact Category

Impact Level

Impact Source: ISO-21434

Threat Scenario No

Damage Scenario

Attack Path No.

Attack Path

Figure 10

the known vulnerabilities are done to identify the attack path. One thing is very confusing at this stage is that how it is possible to know all the vulnerabilities and attack paths? There are various data bases available such as National Vulnerability Database (NVD from NIST) and MITRE@ATTACK tool which can be concerned.

ISO 21434 ANNEX G illustrates an example of attack path analysis by attack tree analysis (Figure 10 and Figure G.5).

• Attack Feasibility Rating: The rating

2: CVSS bases approach: includes attack vector, attack complexity, privileges required and user interaction.

3: Attack vector based approach: At the initial stages of the product development attack vector based approach can be used as there is insufficient information available to identify attack path.

• Risk Determination: The determination of the risk value of a threat scenario.

Depending on the analysis of the Attack feasibility and Impact rating the matrix is

Source: ISO-21434

of the feasibility of attack paths based on the ease of exploitation.

After analyzing the attack path understanding its feasibility is important. To understand this we do the attack feasibility rating. ISO 21434 defines three method to analyze the attack feasibility rating: 1: Attack Potential based approach: As the core factor includes elapsed time, Expertise, knowledge of item, window of opportunity and equipment.

defined to find the level of risk. Risk can be mentioned in the terms of values from 1 to 5 where 1 represents the lower risk level and the 5 represent the highest level. ANNEX J of ISO 21434 provides some sample risk matrix for examples (Figure 11):

Security Defense in depth Security implementation can be considered to consist of layers namely: Hardware Security, Hardware based services, and software security services.

Hardware security forms the base for HW security services and SW security services as it act as security enabler and enforcer. Over the Hardware security runs the Hardware security services and Software security services makes the used of the Hardware security services running over secure hardware in from of firewall, Intrusion detection system, whitelists/blacklists, anomaly detection, secure over-the-air updates, and upgrade capabilities.

Hardware security: A Trust Anchor is a hardware framework upon which the other elements in the Cybersecurity Strategy rely. In order to secure sensitive material in ways that software cannot modify or manipulate, hardware-protected security anchors are used to establish protected storage behind a hardware barrier. There are many types of HTA such as Trusted Platform Module (TPM), Hardware Security Module (HSM), Smart cards/SIM chips, etc.

[ESC-HSM. Some of the major services that HTA include are: • Key Protection: Any private or secret key used for cryptographic transactions on the ECU shall be stored in a manner to prevent unauthorized disclosure and never be transmitted by any means. Any Public Key shall be protected against modification or substitution • Memory Protection: Reduces code vulnerabilities by embedding pointerchecking functionality into hardware to prevent buffer overflow conditions that may be exploited by malicious code.

• Cryptographic Accelerators: Offloads encryption workloads to optimized hardware, improving cryptographic performance and making it easier to broadly incorporate symmetric or public key encryption into applications and communications processes.

• Secure code execution environment: Uses cryptographic techniques to create a unique identifier for each approved component, enabling an accurate comparison of the elements of a startup environment against a

Figure 11

November 2020 | Telematics Wire | 61

known good source and arresting the launch of code that does not match.

• Secure boot and software attestation functions: Detects tampering with boot loaders and critical operating system files by checking their digital signatures and product keys. Invalid files are blocked from running before they can attack or infect the system, giving an ECU its trust foundation when operating.

• Device identity directly on the device: Enables manufacturers to know the unique identity of every device, enabling secure identification and preventing unapproved devices from accessing the manufacturer’s network or systems. Technologies such as Intel EPID (Enhanced Privacy ID), which may be built into processors from Intel and others, also protects anonymity by allowing devices to be verified as part of a group instead of by their unique identity.

Additionally Random number generations, Monotonic Counters, JTAG authentication or lockout features etc. can also be there.

Software security Secure Software can be defined as software developed or engineered in such a way that its operations and functionalities continue as normal even when subjected to malicious attacks. A software system or application offers some sort of services and makes use of varying types of resources.

Any one of these components are a potential target of malicious intruders.

Securing a software is like securing a device or a gadget that serves you. The level of risk will determine the ease with which it can be vulnerable to attacks. There are many ECUs with different capabilities in a vehicle. It is difficult or impossible to add hardware security capabilities to some of them, so cooperating processors and software-based

security are also needed. Architectural techniques and software technologies that can defend the vehicle include: • Input Data Validation: Data validation is the process of ensuring that input data is accurate and complies with the requirement of the input field. All data originating from outside the software, whether from clients’ or other interface applications, must always be treated as questionable.

• Data Protection and Privacy: Software must not only enforce access control but in addition, encryption as well. Encryption provides better data security and privacy. Data is vulnerable in any state and should be encrypted both in transit and at rest.

• Secure boot: Works with the hardware to ensure that the loaded software components are valid to provide a root of trust for the rest of the system.

• Partitioned operating systems: A commonly used software and hardware combination that isolates different processes or functions, such as externally facing functions from those that drive the vehicle, reducing the complexity of consolidating multiple systems onto a single ECU. Techniques, including virtualization and software containers, make it possible to update or replace individual functions without affecting overall operation, or mirror functions for redundancy and fast fail-over.

• Authentication: Authentication by a physical key for unlocking doors and starting the engine is no longer sufficient and is being augmented by software, as cars offer personalized services across multiple functions and profiles. Electronic keys, passwords, and biometrics need to be managed and authorized to access personal information, such as identity, telemetry, locations, and financial

Author Jagannath Tiwari Assistant Manager, Marelli India Pvt. Ltd. Jagannath is Vehicle Function Software Construction (Network, Diagnostics, Bootloader) Team Lead and Cyber Security SME (Subject Matter Expert) with almost 9 Years of experience in development of Vehicle ECUs over AUTOSAR and Non- AUTOSAR platforms. Working over the various latest technology such as Automotive Secure Gateway he has done Safe Network communication implementation over Ethernet, W-Fi, CAN-FD as well as complete product security analysis and secure Software development.

62 | Telematics Wire | November 2020

transactions. Similarly, the various ECUs in a vehicle need to authenticate communication to prevent an attacker from faking messages or commands.

• Enforcement of approved and appropriate behavior: It is very common for cyberattacks to try to jump from one system to another or send messages from a compromised component to an uncompromised one.

Preventing this network activity is a key to detecting and correcting accidental or malicious threats. These functions can also prevent multicar attacks on an entire series of cars or snowball effects from cascading error propagation.

Network security With in-vehicle networks carrying a mix of operational and personally identifiable information such as location, navigation history, call history, microphone recording.

Protecting messages and data over the communication bus is critical for operational security, privacy, and consumer trust.

Common protocols, such as controller area network (CAN), local interconnect network (LIN), media-oriented systems transport (MOST), FlexRay, automotive Ethernet, Bluetooth, Wi-Fi, and mobile 5G and newly proposed protocols, like dedicated shortrange communications (DSRC) amplify the threat, as they increase attack vectors.

Replacing unsecured legacy protocols with common protocols makes it possible to leverage good security techniques that have been developed in the computer industry.

Hardware-assisted technologies that help to secure networks without significantly impeding performance, latency, or real-time response include: ■ Message and device authentication: Verifies that communications are coming from an approved source and protects authentications from being spoofed or recorded and replayed.

■ Enforcement of predictably holistic behavior of all systems: Restricts network communications to predefined normal behavior and constrains abnormal types or volumes of messages so that they do not impair the vehicle’s functions.

■ Access controls: Explicitly permit communications and messages only between pre-approved systems and sensors, block unapproved and inappropriate messages, and alert security systems about any invalid attempts. o

track | analyze | optimize

Decrease Fuel Theft by up to

Reduce Fuel Cost up to

90%

15%

call Us Anytime

Email Us

+91 9989094607

callcommcba@gmail.com

Lead Article

THREAT INTELLIGENT, SMART CYBER SECURITY FOR CONNECTED VEHICLES SENTHIL KUMAR MAHADEVAN (MSK) Wipro Technologies

T

oday’s Smart Connected World is evolving with AI (Artificial Intelligence), RPA (Robotic Process Automation), IoET (Internet-ofEverything), Edge Computing and Next Generation 5G Core technology, constituting a network of embedded devices that incorporate sensors, actuators and communication functions.

In this journey, vehicles are no way exempt from the ‘things’ that are getting ‘connected’. In fact, the pioneering ‘thing’ which caught up the idea and emergence of being ‘connected’ are vehicles.

Already the current IT environments, highly-charged with its performance and potentials, and are characterized by the hacker-powered cyber-attacks for any personal or financial gain, and nationsponsored warfare for data breach across global infrastructure or networks or applications. In such a scenario, securing the automated, autonomous, automotive vehicles connecting IT, ICT, OT and IoT environments with add-on cloud and edge computers is extremely and seemingly challenging. For this, the scope of MBSS (Minimum Baseline Security Standards) is to be expanded at a larger scale and the hyper-aware cyber security foundation is to be built strongly at the base.

We will see how the security is becoming smarter, imperatively getting built into the fabric of the entire infrastructure, network and applications of the connected transportation system as an enabler with smart measures against the intelligently foreseen threats to proactively prevent any security 64 | Telematics Wire | November 2020

incidents, instead of reactively correct them later, which will cause lives and can topple the mere purpose of these initiatives.

For this, let me take you back to the industrial revolution which kick-started its 1.0 with ‘Mechanisation’ in 1784, driven by water & steam in, that progressed with its 2.0 with ‘Electrification’ in 1870, coupled with electronics & mechanical, which paved way for designing assembly line by Henry Ford in 1913. When the first PLC (Programmable Logic Controller) was invented as a part of Industry 3.0 with ‘Automation’ in 1969, the manufacturing processes ruggedized and secured with the help of information technology integrated and embedded with a system having dedicated function within a larger mechanical or electrical system. While the earlier 3 industry generations are more-or-less evenly spaced, Industry 4.0

with ‘Cyber Physical System’ involving (RPA) Robotic Process Automation is evolving much quicker than the rest, with Automated Connected Vehicles as one of the outcomes in the Supply Chain. Though this is going to bring in features to the table (in fact to the road), this is going to equally challenge us with inherent security threat for which a smart cyber security with enough threat intelligence built-in is inevitable to sail smoothly with this generation.

For instance, more than 4 decades ago, when the 2nd generation car was first produced in 1977, General Motors Oldsmobile Toronado incorporated the embedded software that had an ECU aka. ECM or PCM (Electronic Powertrain Control Module or Unit) to manage the spark timings, which were earlier managed mechanically. The use of breaker points in the mechanical units

Atmospheric chamber

Advanceleg Diaphragm

Direction of rotation

Vacuum chamber

Poles

Spring Vacuum advance body Throttle

Distributor body Reluctor Pickup coil

Intake maifold

3 7 15 16

Vacuum port

are subject to wear and tear, oxidation and burning at the contact surfaces from the constant sparking impacts vehicle’s effectiveness and engine efficiency.

EI (Electronic Ignition) in ECUs solves all these problems and help reducing fuel consumption as well.

Thereon, ECUs of vehicles control the behaviour of its devices, communicating through the in-vehicle network. The Parallel enhancements of ECUs” with RSUs (Road Side Units) help to communicate vehicles with other vehicles and to VANets (Vehicular Ad-hoc Networks), with personal devices through WPANs (Wireless Personal Area Networks), and with service centre systems through cellular

networks. A connected vehicle, that uses an external network, in addition to the in-vehicle network, need smart mobility applications to use information generated by vehicles, e.g., cooperative adaptive cruise control. However, connecting all these networks together increases the count and complexity of threats to vehicles. Therefore developing ‘threat-intelligent’ solution as smart cyber security to these smart connected vehicles is mandatory to ensure security and to protect privacy of not only the occupants of the vehicles but transients off the vehicles.

The security & privacy challenges could be multi-dimensional in the case of connected vehicles, which

include but not limited to, one or all of the following: Loss of life: Takeover driver controls, to collide on other vehicles, pedestrians, shops or anything.

Loss of data: Infrastructure, vehicle or personal data loss.

Loss of reputation: Brand image, buyer confidence and resulting revenue loss and increased damage claims.

Financial issues: Loss of vehicle or the valuables in the vehicle by tracking through its GPS coordinates.

Functional issues: Loss of break control, steering control and/or engine control.

Systemic issues: Faulty diagnostics, disrupted infotainment system, manipulated navigation, telematics, dysfunctional/inoperative doors, lights, windows, and other occupant safety systems.

Security cannot be an afterthought but a thought from the start, especially in this connected ecosystem. Connected vehicles are revolutionizing the safety of driver, occupants, and traffic by connecting with the environment around them. Mobility moves manufacturers and their customers into a world of constant presence and real-time communication of big data and analytics. For building trustful relationships between them, ensuring security has become all the more vital for driver-less / self-driving / autonomous vehicles. For this valuable asset of ‘Customer-Trust Business’, the ‘Zero-Trust Security’ model is inevitable measure, as one serious incident exploiting the ‘digital trust’ is all it takes to destroy that ‘customers trust’ earned over years. So how can the automotive industry deliver on the promise of secure connections in the new era of connected vehicles for road safety apart from traffic efficiency, and energy savings?

Let us now see, how we are getting ready for a safe journey with the connected and autonomous vehicles. Here, the triple-A, namely, Authentication, Authorization and Accounting, has to first get their ambit expanded to accommodate the dynamic mobile and cloud platforms. Certificatebased mutual authentication of encrypted data in all the fundamental states, DAR,

November 2020 | Telematics Wire | 65

Crime

Hacker1

Hacker2

Hacker3

Hacker4

Risks

Attacks to exploit Personally Identifiable Information (PII)

Updates with malicious Firmware/Software

Attacks to exploys secret keys and credentials

Remote attack for data breach and for wrongful doings

Controls

Strong Cryptography, Device Credentialing, Encryption of DAR, DIM Message Auth., Hardware-based protection Code Signing with Rights- and DIU, Code Signing, & incl. HSM to-Repair Strong Auth.

Innovative ADAS

DIM, and DIU (namely Data at Rest, Data in Motion, and Data in Use) have to be ensured to prevent malicious content from reaching the vehicles. The SIEM (Security Information and Event Management) integration with anomaly detection systems is to be put in place to detect suspicious communication patterns and protects the vehicles from any hacking attempts and data breaches in the system.

Implementation of appropriate security measures, fail-safes and constant vigilance of the same have to be built into the connected systems to ensure the CIAPAR (Confidentiality, Integrity, Availability, Privacy, Accountability and Resiliency/ Redundancy) throughout. As automotive IoT continues to gain momentum, the features of ADAS (Advanced Driver Assistance Systems) help reduce collisions and accidents on the road. These benefits grow exponentially when the smart vehicles and the AD (Autonomous Driving) vehicles are connected among themselves, so that they can share information V2X (Vehicle-to-Everything); V2X includes V2V, V2I, V2N, V2D, V2G, V2P (Vehicle-to-Vehicle, -Infrastructure, -Network, -Device, -Grid and -Pedestrian respectively) can help make the roads even safer than at present.

The U.S. NHTSA (The National Highway Traffic Safety Administration), with its mission as “Save lives, prevent injuries, reduce vehicle-related crashes” estimates a minimum of 13% reduction in traffic accidents if a V2V system were implemented, resulting in 439,000 fewer crashes per year.

“Towards Zero” is the vision of the Victorian state to bring the road deaths 66 | Telematics Wire | November 2020

down to zero. The ‘threat-aware’ smart Cyber Security measures integrated with connected vehicles for utmost safety of V2X with human-centric design, can help to reach this vision soon.

Cellular technology also has a role to play in this vision; human error is far more likely to cause accidents than overtly dangerous driving, which is why the development of viable European strategy on Cooperative Intelligent Transport Systems (C-ITS) by CAR 2 CAR Communication Consortium is an area being explored in the V2X space.

On the other hand, connected vehicle innovation and driverless technology are advancing quickly – but the real benefits of connected automated transportation can only be unlocked with the right network and infrastructure support.

Border-less services and boundaryless networks are inevitable for V2X connectivity. Vehicles, especially Passenger Cars are not just transport vehicles anymore. They are becoming smarter and smarter day-by-day with innovative, scalable, secured, high-quality digital capabilities and add-ons including a full suite of telematics, infotainment systems, electronic instrument panel cluster, smart cockpits, sound systems, connectivity to smartphones, navigations, fleet management, traffic report, weathervane and childcare assistant.

For the SDC (Software Defined Cars), the software/firmware are delivered OTT (Over-The-Top) and seamlessly updated OTA (Over-The-Air). Therefore, rapid data sharing and management enhanced by the increased speed, high bandwidth, low-latency, device processing & data offload, and trusted computing & storage are crucial to many of these innovations for real-time communication between vehicles

and the connected ecosystem. Therefore, decoupling software from hardware, and moving complexity to the cloud platforms increase the flexibility of new service rollout as and when available and simplify the management of connected vehicle systems are the smart cyber security measures for the safer traffic ecosystem, making the vehicles more intelligent to communicate via the distributed cloud with other vehicles, service providers, traffic authorities and regulators.

Automotive OEM (original equipment manufacturers) and their suppliers rely on building effective data protection and security strategies.

Today’s technology enables the root of trust needed to advance connected vehicle security and scale to meet the industry’s evolving demands.

To understand the above in detail, I would like to split the Cyber Security challenges and respective mitigation controls in an order:

CONNECTED VEHICLE CHALLENGES Compromised Telemetry Transmissions The telemetry data used for maintenance tracking or the consumer devices plugged into the on-board diagnostics (OBD II) port are the weak points for a compromise.

Cyber Attacks through Connected Devices More features call for regular connectivity to support vehicle infotainment systems, service monitoring, and online support, which opens up new potential threat vectors, exposing the whole system for advanced attackers to exploit.

Unauthorised software and firmware updates Any modern connected devices and vehicles require software or firmware updates, delivered over-the-air or at a service centre. The code updates sent to connected components have potential tampering and resulting malware threat, unintended errors or violations of rules if they are unauthorized ones.

Cheap, spurious and counterfeit aftermarket components Unauthorized and insecure aftermarket components added to the vehicle – either deliberately or unknowingly – including gadgets/widgets plugged into the vehicle’s On-board Diagnostics (OBD) II port pose a huge threat to the functionality and security of the vehicle resulting in heavy risk to the occupants and public as well.

SMART CYBERSECURITY SOLUTIONS Protected Data-in-transit Encrypting telemetry and other data transmitted to/from the vehicle to support vehicle maintenance tracking or a V2V infrastructure ecosystem, provides protection against data theft and other compromises. Mutual authentication of connected components to be enabled to trust the data thus transmitted.

DLP (Data Loss Protection), Driver/ Vehicle Safety and protection of sensitive fleet operation data of transport/cargo vehicles are ensured by securing the transmission of telemetry data and other information broadcast to/from the vehicle.

Connected Device Authentication Manufacturers give a unique identification to each of the connected components

and devices using HSMs (Hardware Security Modules) and supporting security software for authenticating them individually, with a root of trust along with the foundation for an effective PKI (Public Key Infrastructure).

Strong Code Signing The software/firmware code must be signed using a strong code signing methodology, including HSMs. Establishing cryptographically-based digital identities for connected vehicle components and securing code updates against tampering help to protect against malware and code tampering, thus safeguarding against unwanted sophisticated attacks, unauthorized modifications to vehicle performance and reputational damage.

Connected & Autonomous Transportation bundled not only featured on the functionality but also on the security at different dimensions through innovative ADAS with Cyclist Detection Auto Brake, Road Work Alert, Lifesaving Emergency Vehicle Alert, Digital Geofencing, Park Assist Pilot and Lane-keeping Aid, to aid controlling vehicles entry, speed, fuel use, line of sight, detours and so on.

With growing smart cities, the transportation is getting transformed with millions of connected vehicles in the supply chain and resulting explosion in the data volumes. Improve response times at an optimum bandwidth for upstream of the edge for better security calls for next generation smart 5G networks with • proper network slicing, zoning, microsegmentation, etc. at the network layers; • traffic routing, distributed anchoring, multi-session breakout, etc. at the transport layers;

• mobile edge paradigm for distributed compute close to consumption points with data caching, synchronization, messaging capabilities, etc. at the data layers; • AR/VR (Augmented/Virtual Reality) for performing and processing at the presentation layers; • ML (Machine Learning), caching, predicting the vehicle position at a future point at the application layers; • consistent and harmonized central management of the network topology and resources including the compute and storage in the on premise or on cloud distributed infrastructure at the orchestration layer.

For connectivity-fuelled uninterrupted disruption of the automotive industry, multi-access mobile edge computing is crucial part of the 5G platform and facilitates the first-mover advantage for communication services providers to provide secured channels. 5G facilitates edge computing service to provide RTEE (Runtime Execution Environment) for VNF (Virtual Network Functions) and non-telecommunication workloads as well. Advancements in 5G connectivity with high-speed, and ultra-reliable-lowlatency enables real-time communication between vehicles and the connected ecosystem including the edge.

As an evolution to today’s networks, next generation 5G mobile networks are expected to handle mission-critical communications of big data volume, connect multiple devices, reduce latency significantly and bring new levels of reliability, privacy, security alongside regulatory compliance, thereby, can support safer driving and enhanced V2E connects.

Improved data jurisdiction and regulatory compliance is achieved by processing the generated data near the point of consumption to reduce or eliminate cross-border transfer of data/ information. For this edge platforms helps with a shorter control loop, and smaller span of control to provide guaranteed QoS (Quality of Service).

Autonomy and survivability with threatintelligent computer resources are resilient to failures in a static data centre or a dynamic transport network, with intelligent security tools/applications and artificially intelligent HSM - at the edge. This enables fleet orchestration of

November 2020 | Telematics Wire | 67

connected automated fleets with high connectivity needs.

There are hi-tech automotive majors joining hands and forming associations and consortiums to put the ‘securityfirst’ mindset into perspective for defining & harmonizing broader use cases, for orchestrating the technical & implementation strategies, for standardising certification & regulatory approval processes and for leading the innovation & integration of cutting-edge technology solutions with ‘security by design’ and ‘security by default’ principles. Easy-to-understand and Usefulto-deploy security controls are placed on workloads, effective DevSecOps security framework are constructed around the up-and-coming server-less constructs like Kubernetes and Docker containers to the DevOps Agile development models, without any additional intricacies of wireless or mobile transport networks. These are adding up to smart cyber security.

Further, the advent of all-electric road freight transportation has huge environmental benefits with potential to reduce CO2 emissions by 90% and elimination of harmful NOx emission and ultrafine soot particles completely.

Autonomous Electric Transportation (AET) solution using 5G technology enables more secure and sustainable future of transportation.

By 2023, 5G will make up around one-fifth of all mobile data traffic, where 26% of the use-cases will depend on the capabilities of edge computing which is largely fragmented and swiftly evolving.

And by 2030, up to USD 700 billion of the 5G-enabled, B2B value could be addressed by TSPs. According to TIM, in the year 2025, there will be an estimated 100 million connected cars.

To leverage these opportunities, connected vehicles to be smart and secure as well with threat-intelligent Cyber Security in two-fold: a) smartly secured from persona point of view involving the ultimate user, app developer, app vendor, TSP (Telecommunication Service Provider), CSP (Cloud Service Provider), content manager, platform provider, infrastructure designer, SI (System Integrator), EISA (Enterprise Information Security Architect), IoT device creator and so on, and b) smartly secured from attributes point of view including trust, authentication, authorization, accounting, monitoring, verification, validation, privacy, integrity, and the like.

The key success factors being considered with 5G communications by the service provides include avoiding failures of past initiatives by building out secure platforms and easy-to-consume APIs (Application Programming Interfaces), avoiding too much of dalliances with APIs by considering proper alliances and due diligence, avoiding isolated technology silos in business by building a holistic core to edge continuum, avoiding overenthusiasm in automation strategies by following and adopting the success stories of the proven CSPs. For instance, Amazon’s AWS Greengrass, which allows appropriate synchronization, real-time replication and dynamic orchestration of its IaaS, PaaS, SaaS, FaaS and CaaS (Infrastructure, Platform, Software, Function and Containers) with the hybrid apps to run across AWS cloud, AWS IoT, AWS Greengrass devices, and AWS Lambda instances. Similar is the

Author Senthil Kumar Mahadevan (MSK) CSO & EISA, Hi-tech Automotive & Electronics, USA CSA – for Manufacturing & Consumer BUs of CRS Security Evangelist, Wipro Technologies MSK is the Chief Security Architect with over 29 years of rich IT & Cyber Security experience. MSK held various senior leadership positions including DGMIT and Group CISO. As a CSA, he is presently responsible for designing cyber security architecture framework for various IT transformation projects covering cyber security evaluation and risk management for ADAS (Advanced Driver Assistant Systems) & Driver-less AD (Autonomous Driving).

68 | Telematics Wire | November 2020

case with Microsoft’s Azure IoT Edge and Google’s GCP & Flutter.

The threat intelligence of smart security reduces over-enthusiasm in provisioning of communication services and in building of edge strategy and cloud/data lake infrastructure.

While the threat-intelligent smart security help addressing the cyber threats of connected vehicles well, there are compliance considerations such as allowing lawful interception, access restrictions, identifying the data location & localization, etc, pending to be addressed. For drafting necessary compliance standards and guidelines, the security maturity is vital which would be possible only after a good and more take-off and take-aways. In any field, the regulations and standards generally follow the innovation. The initiatives in edge computing and automation, such as, IEEE’s OpenFog, AT&T, Intel seeded Project Akraino, Linux’s EdgeX, CNCF (Cloud Native Computing Foundation), ONAP (Open Network Automation Platform) and AECC (Automotive Edge Computing Consortium) are gaining momentum in their infancy stage itself. The mix-and-match of curated and non-curated applications based on the approach – walled garden or open platform respectively – otherwise to land somewhere in the middle, hosted with a multitude of applications based on the hybrid approach, is another criterion for security of the entire automated ecosystem.

Exposure and upskilling of resources in infrastructure or device / application development, troubleshooting and maintenance are other challenge to security of the smart vehicles. While ignorance and imprecision of Code Developer and Support Engineers are untenable, their education and crossskilling are keys to swiftly turnaround to end users’ queries and complaints through ready-to-apply toolkits & libraries and easy-to-find documentation & playbooks on the complete telematics of the entire ecosystem.

I am optimistic to see a better and quicker progress in these areas for improvement, for the smart connected vehicles to be sufficiently secured ones as well. o

Perspective

Overcoming Marine Fuel Usability with fleet management solution Tushar Bhagat Uffizio India

T

he global marine fuel optimization market is one of the fastest-growing which is owing to the increase in the marine sector by providing an accurate amount of fuel oil consumption for a particular vessel. The marine industry works on various factors such as different government rules and regulations to curb the carbon emission at the seal level which in turn reduces fuel usage and improves operational efficiency.

As we all know the fact: Fuel theft is everywhere!!.

As compared to the transportation industry the detection of fuel theft in the shipping industry has more challenges and difficulties.

The daily consumption of fuel in shipping is immense and it becomes very difficult to track the actual fuel level and consumption as the ships/ barges keep moving in the ocean.

CHALLENGE : Hardware part Installation A bulk carrier consists of 3 to 4 fuel tanks which are further divided as a primary tank and secondary tank. In which the primary tank of the ship is connected with the main engines of the vessel and the secondary tank from where the fuel is transferred when there is a decrease in the fuel level of tank 1. Regarding that, they consist of generators and boilers and the overall fuel consumption depends on the work of each of these units.

Now the challenging task for installing hardware and fuel sensors is that the tank size of this vessel is way larger than that of normal fleet tanks. The capacity of these tanks varies from 15000 liters to 20000 liters or more. Now when the vessel is moving into the ocean during its voyage it faces numerous atmospheric pressures and challenges which apply multiple

forces both inside and outside the ship.

Now installing a fuel sensor rod in vessel tanks should be done in such a way that it could handle all the pressure and won’t get broken during the whole journey. The complex wiring of these sensors and hardware devices through the engines and system requires years of engineering expertise and knowledge.

CHALLENGE : Software part Execution

Reading: As we know there are multiple tanks in a vessel.

Each one consists of a different capacity of fuel. Now when the fuel is transferred from one tank to another the fuel level of each tank changes continuously. So to get the exact amount of fuel drain and refilled in the various tanks becomes a tedious task for any software.

So, basically, the software algorithm should be powerful enough to differentiate between, fluctuations in fuel level, fuel transfer from 1 tank to the other and actual fuel thefts.

SOLUTION • Fuel Theft issue was solved thus it helped in reduction of 30% cost in fuel.

• Fuel consumption reports & data for every single trip can be easily obtained.

• Provide an accurate amount of fuel consumed at any particular vessel speed or engine rpm.

• Constant change in the Fluctuation level was optimized.

• Continuously monitoring helped in evaluating how much total fuel each engine or generator can consume. o

Fluctuation: Due to the constant moving of the ship fluctuation of fuel is one of the major issues. To solve this problem a highly configured and Author powerful software is required whose algorithm should be able to detect minor changes in the fluctuation level of the fuel.

Tushar Bhagat Director Uffizio India Software Pvt Ltd

November 2020 | Telematics Wire | 69

Domain Overview

Automotive Cybersecurity: The Growing Need and Challenges Midhun Roby A R Nexteer Automotive, USA

I

n recent years, there has been a significant increase in consumers’ interest in vehicle safety. The connected car revolution will create new possibilities for consumers’ interest in data security. Along with safety, protecting consumers’ data is more important to maintain trust; a failure in safety or data security will destroy the consumers’ confidence in the manufacturer.

70 | Telematics Wire | November 2020

Just like how a weak ECU inside the car can compromise the entire vehicle security and safety, a less secured vehicle on the road can create a potential threat to other vehicles, pedestrians, and surrounding infrastructure. Now Vehicles are getting more equipped with artificial intelligence to reduce human operations. Connected and autonomous vehicles (CAVs) with 5G connectivity will take us to the next level of driving

experience - advanced driver assistance, autonomous driving, and external connectivity like vehicles communicate with other vehicles, pedestrians and surrounding infrastructure are some of them. In modern cars, the external connectivity is mainly handled by the gateway module, telematics, Bluetooth/ WiFi radios, and V2X module, more security measures are needed for these modules. The wireless and the advanced RF communication used in these modules will create more opportunities for hackers, cybercriminals to steal personal data, or manipulate vehicle functionality. On the other side, academic researchers and competitors can explore the vulnerabilities and challenge the manufacturer’s reputation.

Also, we should consider the possibilities of terrorist activities with less secured cars.

Modern vehicles support Over The Air software updates and will get numerous connection requests from their surroundings. If the car doesn’t have proper cybersecurity, such connections can steal your private data (e.g., contact list, credit card details, your medical report, bank balance, your conversations)

or it can intervene with the safety (e.g., changing/tuning car performance, disabling the breaks or locking the steering while driving). We might not be aware of the extent to which these threats can impact us. In addition to autonomous features, the vehicles will offer many advanced features to the user and also to the government officials. For example, the vehicle might have contactless bill payment, which means you don’t have to use credit cards in gas/electric stations, toll booths, and drive-thru stores; instead, you just have to save your card information in the car. Another example is, A police vehicle or a traffic signal that can read your car’s diagnostic data or access live driving records (e.g., driving behavior, overspeed, and other traffic violations) without stopping you. Any unauthorized connections can adversely impact the safety or steal personal data which can directly or indirectly affect you – like, • Indirect Impact: Stealing driving behavior can increase your insurance premium.

• Indirect Impact: Cybercriminals can sell your stolen health report on the darknet/black market for cash, which contains many personal data (e.g., govt. IDs, date of birth, place of birth); these can be used to hack your bank/ email account.

• Direct Impact: Spoofing the GPS signal can have an impact on safety, a cybercriminal can take control of your autonomous vehicle causing personal injury, property destruction, and severe traffic congestion.

The widespread use of smartphones and smart gadgets brings a basic awareness of data security to the public, but it doesn’t create any critical threats to your safety. Back to cars, both safety and data security are critical; a hacker can threaten your life by hacking the car or use stolen personal data to commit fraud.

The connectivity with the external world provides an excellent opportunity for hackers to challenge your safety and the data.

“Cybercriminals’’ can outpace the existing cybersecurity experts”.

All the current security measures will weaken as the technology improves.

a top target for cyberattacks, automotive manufacturers have started investing in security research and development to secure vehicles network from unauthorized access. However, the challenges are incredibly high with OEMs and the Tier-n suppliers. The lack of cybersecurity processes and standards was one of the major concerns for the last few years.

ISO/SAE 21434 ‘Road vehicles – Cybersecurity engineering’ is expected to be released by the mid of 2021, that will supersede SAE J3061 and help to fill the gap in cybersecurity process and culture. ISO/SAE 21434 will provide a

structured process and requirements to ensure cybersecurity across the life cycle of the vehicle. It specifies requirements for cybersecurity risk management, security concept, development, production, operation and maintenance of road vehicles. It will also help with the cybersecurity process for postdevelopment, the incident response and decommissioning. OEMs and Tier 1 will need to follow this new standard, just like ISO 26262.

The connectivity with the external world provides an excellent opportunity for hackers to challenge your safety and the data. Identifying the future threats is always the top challenge; the effectiveness of security depends on the experience and knowledge of the members who identify, analyze the risks, define security goals, and design security features to mitigate the risks. Considering the unknown threats that can happen in the future, multiple security layers are recommended.

“Cybercriminals’ can outpace the existing cybersecurity experts”. The current cybersecurity workforce shortage and the cybersecurity skill gap continues to widen; this is one of the major challenge. Many universities have already started cybersecurity in their academic programs and focus on a broad array of security-related research areas. The ability to prevent cyber-attacks depends on the availability of highly skilled cybersecurity workforce; therefore, it is essential to include cybersecurity in our

The Current Challenges Cybersecurity in the auto industry is not a new topic, but it was not a major consideration until the Jeep hack in 2015. Considering that the Connected and Autonomous vehicles will become November 2020 | Telematics Wire | 71

education system to meet the emerging demands.

The OEMs, Tier n suppliers, need to follow the rules and processes to manage cybersecurity and maintain continuous improvement. Here, another challenge is with distributed activities. The items and components developed in a distributed activity, the security design concepts, requirements, and secrets might need to be shared between the suppliers; this requires proper Non-Disclosure Agreements (NDA) and Cybersecurity Interface Agreements (CIA) between the parties. Maintaining secrecy will become each party’s responsibility; suppliers will need to provide proper training and awareness to their employees.

Vulnerability analysis is the next challenge. Until the connectivity is enabled, hackers cannot exploit vulnerabilities without physical access.

The connectivity fills the gap, and hackers around the world can exploit the vulnerabilities and access the cars remotely. Cars are complex machines, we are at the beginning of an evolution where modern cars contain around 80 ECUs, a few 100 million lines of codes.

It is not easy to find out the bugs and vulnerabilities; in such cases, one of the best possible method is performing code/design reviews and vulnerability scans. Also, suppliers need to follow Secure coding practices (e.g., CERT C/ C++, MISRA C:2012) to minimize the vulnerabilities and effectively reduce cyber-attacks’ surface. Carmakers put a lot of interest in this, any callbacks will cause considerable loss to them. There are vulnerability information-sharing systems in the cybersecurity field, like CVE (Common Vulnerabilities and Exposures), which is not of much use

to the automotive industry; it is more for the IT sector. The CWE (Common Weakness Enumeration) is one step ahead and provides both software and hardware weakness to support building secure software. Another one is the NVD (National Vulnerability database) maintained by NIST. There are few databases focused on the automotive sector like Automotive-CVE and AutoISAC, where new vulnerabilities and threats are collected and exchanged.

All the current security measures will weaken as the technology improves; this becomes another challenge to the OEMs. The current security measures are good until someone hacks it. Most of the time, the OEM defines detailed basic security features like security access, secure programming, secure diagnostics, secure modes, secure communication, and relies more on symmetric, asymmetric, or hybrid cryptographic algorithms.

Suppliers will have a great deal on other security features like secure boot, debug/ unused port lockout, development services, input filtering, boundary checks, firewall, IDS/IPS, etc. Both OEMs and Suppliers are responsible for choosing robust cryptographic algorithms, passwords, nonce, etc. Using already/soon deprecated cryptographic algorithms and weak passwords increase vulnerability to break the security measures and compromise whatever data has been protected. If there is any kind of breach in the crypto algorithms used, it will end up as huge loss for OEMs. Hardware Security Module: The Software-only solutions cannot effectively handle all cyberattacks. The hardwarebased security systems are effective against new threats, it can safeguard and manage secret keys, secret data, and perform

Author Midhun Roby A R Cybersecurity Systems Engineer Nexteer Automotive, USA Midhun Roby has over 10 years of experience in the Automotive industry with 6 years of automotive cybersecurity expertise. He deals with Security Analysis, Concepts, Designs, Implementation and Process. Midhun did his bachelor’s and master’s in Electronics. He also has a Master of Technology degree in Digital Electronics.

72 | Telematics Wire | November 2020

cryptographic operations. Hardware security modules are embedded in the microcontroller with dedicated CPU, hardware based symmetric/asymmetric cryptographic accelerators and TRNG. A wide range of hardware security systems are available in the market, following different standards and brand names (e.g., HIS-SHE/SHE+, Evita-Full/MediumHSM/Light, TPM, CSE, ICU).

Cybersecurity testing is the next challenge. Apart from normal functional and interface testing, cybersecurity targeted vulnerability scanning, fuzz, and Penetration testing has to be performed on all ECUs. Cybersecurity testing should discover the overflows, segmentation, and heap errors that will have cybersecurity implications. Penetration testing will become a must for all Safety critical ECUs to find vulnerabilities present in the system, which leads to unauthorized control, gaining privileged access, exposing privileged data, or malfunctioning the system. It is also best to practice this for all ECUs which has security implemented in it, instead of just safety critical ECUs. Remember, any weak ECU inside the car can challenge another ECU or the entire system.

Enabling Cybersecurity can prevent the suppliers’ re-work capability, leading to an increase in scrapped EUCs during production. A need for proper rework process is required to reduce the scrap cost; Suppliers will not have access to their development services on production parts, as they are being deleted or locked through multi-factor authentication. The incident response process and lack of standards are other challenges. OEMs and suppliers need rules and processes for the incident response; there will be a significant rise in security-related incidents compared to other incidents that the automotive industry is facing today.

Besides vehicles, the supply chain will also need to consider Cybersecurity for their IT infrastructure where the secrets are handled. For example, hacking the passwords, root keys, crypto algorithms that are stored inside the web servers or the database can be used to hack the connected vehicles. The supply chain will need to prepare now for Cybersecurity to prevent future loss. o

ZUPPA

Â&#x2026; Â&#x201A;Â&#x201A;

Â&#x2020;

Â&#x2021; Â&#x2C6;Â&#x2021; Â&#x201A; Â&#x2030; Â Â&#x160; Â&#x2030; Â&#x20AC; Â&#x192; Â&#x20AC; Â&#x160; Â&#x2030; Â&#x2039; Â Â&#x2021; Â&#x152; Â&#x17D; Â&#x2030;

Â&#x2021; Â&#x2030; Â&#x17D; Â&#x2021; Â&#x2030; Â&#x2030; Â&#x2021; / Â&#x201E;

 Â? Â?Â?Â? Â? Â? ­ Â?Â&#x20AC; Â&#x201A;Â&#x192; Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E;Â&#x201E; Contact Website: https://zuppa.io Phone : +91 44 42054910

Email: askme@zuppa.io Mobile: +91 9380577074

Lead Article

Automotive Network Cybersecurity through Artificial Intelligence Jayendran G Tata Elxsi

N

etwork Connectivity has enabled automobiles to add a significant amount of features and functionality to the vehicle. Security of the data and communication is a significant attendant risk. In addition to the traditional security techniques, Artificial Intelligence and Machine Learning (AI/ML) could be useful in adding cybersecurity features to a connected car.

Different Types of Automotive Networks A typical vehicle has multiple networks.

1. Controller Area Network (CAN) is a bus protocol that enables the communication between in-vehicle sub-systems.

The information exchanged between these subsystems can be used to communicate with, configure, and control various

Figure 1: Intelligent Connected Vehicle

74 | Telematics Wire | November 2020

car parts. In some cases, FlexRay or Ethernet might also be used for invehicle networks.

2. The Telematics Network includes those information-intensive components that enable various applications by combining Telecommunications and Informatics.

These include Remote Vehicle maintenance, Fleet management, emergency assistance, Location-based services, advanced driver assistance systems, etc. This is part of the Connected Car network where the automobile is connected to one or more servers, typically over a cellular wireless network.

3. Vehicle-to-vehicle and Vehicle-toInfrastructure networks, referred to by the umbrella term Vehicleto-everything (V2X networks), are peer-to-peer networks that enable

enhanced collision avoidance, vehicle safety, traffic efficiency, etc. Again, this would be over an external network to the outside world as, for example, a wireless network.

All of these networks are interconnected, and data continuously flows from one to the other.

Security Challenges and Threats: In 2015, Charlie Miller and Chris Valasek demonstrated that it was possible to remotely hack into a running Jeep Cherokee from several hundreds of miles away and take control of its operation.

They were able to disable the transmission and abruptly engage the brake. Earlier this year (2020), hackers could gain control of an autonomously driven Tesla car and accelerate it significantly.

These are just examples of cyberattacks that threaten a vehicleâ&#x20AC;&#x2122;s security and passengers and othersâ&#x20AC;&#x2122; safety. There are many ways in which these attacks happen. Malware, short for malicious software, has gained unauthorized access to a car network and has been installed in one or more of its sub-systems. With multiple remote applications connecting to the car and communicating to various sub-systems, there is always room for malware installed within the vehicle. This malware may then continuously operate within the vehicle network, either providing confidential information to a third party or denote a potentially dangerous set of actions that might threaten the safety of the vehicle and its passengers. A denial-of-service attack

would systematically use up a vehicle network’s resources, typically by sudden flooding with traffic, thus denying network access to legitimate vehicle subsystems. Identity exploits would help malicious users gain unauthorized access to various parts of the vehicle network.

The increasing complexity of vehicles and the progressive use of more and more software to control or enhance the functionality of sub-systems within a vehicle increases the attack surface, which is the number of different vehicle points that are vulnerable to a cyberattack.

A significant challenge is the so-called “zero-day attack,” which is an attack that exploits a vulnerability that may not have been identified earlier. The pattern of such an attack would not be known, and no defense would have been planned for it. A conventional software solution is impossible for a zero-day attack since no detail about the attack is known a priori.

Only an AI/ML solution is possible, which can learn the normal patterns of data and detect anomalies in the network data. The anomaly detected could be a malicious activity or a rare type of activity which need not necessarily be malicious. The alerts from the AI-based anomaly detection model serve as way of shortlisting network data to be further inspected by Security Experts. It would otherwise be impossible for Security Experts to analyse the entire volume of data collected from an automobile network without a mechanism to shortlist potential malicious activities.

Data that can be analyzed: A large amount of network traffic flows through the CAN, Telematics, and V2X networks. This network data would still follow a particular pattern of behavior.

The information being exchanged within these network messages, the types of commands given to the car remotely, the remote servers being accessed, the kind of information from the car requested for monitoring purposes, etc. can be captured and analyzed. Also, logs are maintained at multiple locations, containing information regarding the various transactions between the communicating entities, the state of different sub-systems

of the vehicle at other points in time, the manner of driving, etc. The different applications that the vehicle uses would maintain their log, both within the vehicle and at a server. These logs can serve as a significant information source for analyzing the vehicle’s behavior at any point in time.

Network traffic data from all the vehicle networks and Sub-system and Application logs would serve as input to AI modules.

How AI/ML would work: AI-based malicious activity detection models can be a hybrid composed of supervised classification models to detect known malwares or their minor variants and anomaly detection models to detect any anomalous activity which could be potentially malicious. Anomaly detection models have the potential to detect zero day attacks unlike signature-based traditional tools or supervised classification models.

Training a supervised classification model requires labelled training data to be available. That is, we need to have a significant amount of normal network data samples and many samples of each type of malware to train a supervised classification model. Anomaly detection models on the other hand can be trained using normal data that gets captured from the network without any labelling.

The AI/ML framework for Automotive Network security would have to be such that the AI models are present within the car and remote application servers.

Automotive controllers that are present in-vehicle have semiconductor support for AI/ML and data analytics. Some of the analytics can be done in-vehicle and the remaining in a remote server.

In-vehicle analytics would be done on CAN network traffic within the vehicle and log data collected. The effectiveness can be enhanced if the AI module maintains an extensive profile and detailed knowledge about each vehicular sub-system’s working and performs independent and separate analytics on each one of them. This detailed, granular analytics level would enable even a slight deviation from the normal to be accurately detected.

When a vehicle communicates with a remote server, extensive data and logs are collected on the server. AI based anomaly detection models can learn normal patterns of behaviour of various components within the vehicle by training on the data collected on the server. Any pattern deviating from the normal patterns could be potentially malicious and can be detected by the anomaly detection model.

The AI models can also to be customised for particular drivers and their style of driving. This would enable the models to detect even the slightest deviation from the normal and identify potential problems.

Summary In the end, security in an automobile is a safety question for passengers and other vehicles and pedestrians. Human lives are at stake and vulnerable to malicious intruders. The absolute power of Artificial Intelligence and Machine Learning needs to be brought to Automotive Network Cybersecurity. It is mandatory to do so as AI/ML is the only way to combat the myriad and diverse threats that make an automotive network vulnerable and help strengthen and protect them against attack. o

Author Jayendran G General Manager, Next Generation Business Unit Tata Elxsi Jayendran has worked on Communications technologies for over 25 years. He has led teams that have built several products in the areas of Routers and Wireless Communications and has worked with Networking & Communications OEMs and Service Providers across the world. He heads the Cybersecurity practice at Tata Elxsi.

November 2020 | Telematics Wire | 75

Shared Mobility

Why do you need to center ‘the choice of hardware (IoT device)’ on user and operator experience in your Shared Mobility service?

Venkatesh Gopal movmi Shared Transportation services

H

ow critical is technology’s role in a successful shared mobility (car/bike/moped share) operation? As an operator, should one invest in a reliable hardware (IoT device) and focus on operations? Seems obvious when we put it that way. Here are a few handy tips on what you should consider to help you select or validate if what you have is operationsready.

The World Economic Forum defines ‘Shared Economy’ as the focus on the allocation of underutilized assets, monetized or not, within a community or group of users in ways that improve efficiency, sustainability and the overall community. Shared mobility is a considerable slice of this pie and has seen success in many modes (cars, bikes, mopeds, and vans/micro-transit). Technology has been at the epicenter of creating and sustaining the sharing economy.

The ins and outs of Telematics (hardware) in Shared Mobility In any shared mobility operation, you typically need an IoT device (telematics) which communicates between the vehicle and the cloud to perform basic tasks such as granting access to the vehicle, determining the real-time position, relaying fleet management data from the vehicle to an external interface. The second piece is the software (backend) to analyze data, support user (end consumer or member) 76 | Telematics Wire | November 2020

experience and manage the operations.

The last piece is the mobile application which is used to support user experience.

Here we look at the telematics piece.

Use it wisely and your IoT device (hardware) choice could prove highly competitive in every way. The basics for the shared mobility telematics are connectivity, battery-life and vehicle compatibility. Connectivity here could be seen as the amount of vehicle information the device can tap into. Goes without saying that the more variety of data and higher the frequency of collection, the higher the power demand (and we go back to the previous point). Data points such as GPS location, vehicle mileage, fuel/charge level, engine status, vehicle immobilization and vehicle access (unlocking/locking doors) are very common across most of the hardware providers and this immediately allows the vehicle to transform into an interactive technology piece or IoTenabled. Depending on the integration levels, operators are able to enable/disable read/write access to the vehicle which slightly bumps the control over vehicles to the next level.

Secondly, we look at battery life. This depends on the power rating. The IoT device is the power rating which, in most devices, creates major operational difficulties especially when the vehicle utilization is lower. Even when the vehicle is parked for a long period, the operations team still needs location info and vehicle status in order

to enhance user experience and backend processes. This results in the IoT device draining the auxiliary battery (12V). End result, the vehicle goes offline when needed and/or fails to start. As much as this ‘alwayson-real-time’ view might sound desirable to users and operators alike, the latter need to work with the hardware provider to customize (if possible) this feature and find a balance between operational must-haves and battery life.

Lastly, the device’s compatibility with vehicle type/model. While choosing the IoT device you will need to have an idea of the vehicle model, depending on which some advanced technical features could be tapped into. A device already tested with electric vehicles is better for an EV sharing model. Certain commercial vehicles need additional ports that need to be connected to the device and finally, the mobility mode viz. car, scooter, moped, bike.

Financially, the decision of choosing the right IoT device is critical since this is a long term one (considered CAPEX). With the right features enabled the hardware will enhance the user experience through the software platform then tapping into all the data points (output) and analyzing in a way to ease critical business decisionmaking. Speaking of business, the IoT device choice could be attributed to the experience of the two stakeholders, viz.

Users and Operators.

Everything boils down to a better UX (User Experience) Leveraging vehicle telematics not just to solve user issues but also to enhance user experience is the key to any shared mobility operations. The user or member journey (case in point, station-based car sharing) basically deals from booking a vehicle to completion of trip and payment. While most of the processes are reliant on a smooth software (a mobile APP) interface, the foundation proves to be the telematics device.

Wayfinding. This aspect goes both ways i.e. for virtual & actual. The problem here is that a vehicle not available at the location shown or the system not able to exactly locate the vehicle. While choosing or customizing the telematics device, pulling location information and doing it precisely is vital. Depending on the device’s communication frequency, the user may have to wait too long to let the system detect the location. This hampers user experience and as we know it results in lower utilization. Another aspect, as mentioned above, is the location precision. The capability doesn’t have to be pinpointed, but enough to let users in the visible range of the vehicle. That said, by virtue of regular use this suffices and creates an expectation of the vehicle being available around a zone at a given time.

Unlocking. The one reason why the user is a part of your service, to get in and drive. Depending on the vehicle (in this case, a car) telematics functionalities could be a little spotty when it comes to writing

Shared Economy brings focus on underutilized assets, within a community or group of users in ways that improve efficiency, sustainability and the overall community

commands on the vehicle system. User authentication process will have an effect in this process, but once completed, the response of the vehicle is detrimental to the user experience. Depending on the whole process it could take the user as much as 10 minutes to get into the vehicle.

Testing the device functionality for this aspect is one of the decision factors for IoT hardware selection.

Ghost cars. Sounds unusual, but is more commonly found than expected. This issue is critical as it might pop-up even after testing during the operations. Simply put, this problem is about cars not physically at (or anywhere near) the location shown on the user interface map (mobile APP). This depends on two factors; one of them is

software-based where navigation service is not well integrated with the rest of the APP and the other is based on the IoT hardware capability. Telematics as any other electronic device have their downtime and might not function or respond to the communication request from the server.

The vehicle, if a user walks up to it and unlocks it, will respond, but the location might not have been updated on the map.

While this is a user experience problem, it will reflect at the operator side (backend) as well.

Ending trip. The last part of user experience that deals with the vehicle and hence the telematics is locking the vehicle when the user ends the trip. As for the functionality, it could work exactly as ‘unlocking’, but user behaviour practically changes once they reach their destination.

Users could be needed to confirm ‘end trip’ once they reach the destination and take all their belongings out and the vehicle would lock itself, end the trip and charge the user.

This is not the ideal journey as seen across shared mobility services. Operators ensure making accessing and using a vehicle so unintrusive that users expect a superior experience going forward. One of the better practices that such operators enable is as the user reaches the destination, ends the trip while in the vehicle, takes their belongings and walks away. The device detects proximity of the mobile device (therefore the user) and locks itself before making itself available for a new trip. Having said that, the operators need to factor in the IoT device functioning on proximity as a safety precaution too, as users may

November 2020 | Telematics Wire | 77

walk away and miss locking the vehicle or even ending the trip. This expectation also depends on the precedence set by global car sharing operators, but as a good practice managing this will not just ease but enhance user experience.

A perfect fit: The telematics device that also delivers ‘best-in-class’ OX (Operator Experience) Everything that is vital for users, is just 100X critical for the operators (100, let’s say the no of users or vehicles).

Tracking vehicle locations (and other vehicle-specific parameters that the telematics typically relay back) allows the member support team (backend) to not just know the physical locations which are typically used for rebalancing and vehicle maintenance procedures, but also to exactly troubleshoot user issues.

Remotely unlocking and locking are ways to resolve user issues (might we add of the highest importance) and such issues, when detected by the device, must be relayed back as an alert to the backend which allows remote troubleshooting.

‘Pinging’ vehicles at request is helpful and the first go-to method for the operators to resolve on-trip user issues. Besides the user issues, telematics need to be leveraged for enabling better business models too.

Insurance. Selecting an IoT device could help reduce risk and hence save premiums while insuring the fleet/ business. Starting with critical aspects, any unauthorized access or activity to the vehicle must be alerted to the operator team as soon as they are detected. Security measures such as deactivating the vehicle

Connected cars form the bedrock of shared mobility operations and provide the foundation for CASE

immobilizer when ‘not rented’ ensures any unauthorized attempt of vehicle theft.

Enabling live GPS tracking on demand is recommended and therefore needs to be within the device’s capabilities to help authorities track the stolen vehicle.

Tracking driving patterns also holds key importance in the insurance checklist.

Depending on the target demographics and driving record checks once the user is approved, having a record of erratic/ unsafe driving patterns helps reduce the risk.

Fleet management. Not as critical, but certainly a factor to consider regarding upkeep of the vehicles, preventive/ scheduled maintenance. IoT devices are capable of sending preventive maintenance alerts depending on vehicle odometer info which ensures risk free operations and helps strengthen from an insurance standpoint too. Goes without saying that communicating/ alerting the operations backend about vehicle faults as they occur helps the

Author Venkatesh Gopal Business Development Manager movmi Shared Transportation Services Venkatesh Gopal is the Business Development Manager at movmi Shared Transportation Services. As a shared mobility expert, he helps model, launch and analyze businesses operations. A mechanical engineer with an MBA, Venkatesh’s experience in customer management allows him leverage while developing strategies. A sustainability ambassador, he is an executive committee member at Vancouver Electric Vehicle Association (VEVA) and has also participated in promoting active-transportation policies.

78 | Telematics Wire | November 2020

field support team plan their operations and depending on the criticality of the fault lets them intervene immediately or schedule taking the vehicle off the grid for maintenance at the end of the day.

Such features not only enable operators to plan better but also impact user experience. An important aspect which must be included in fleet management is tracking vehicles proactively for being parked in ‘red-zones’. These are areas typically in the city-center where the municipality/local authority has strict tow-away laws for unauthorized vehicles.

While for a smaller fleet operators could manage this almost manually to an extent, but for a larger fleet size operation the device’s location update which can then be layered over earmarked zones on the map could help trigger alerts for the field support/rebalancing team to take appropriate actions.

In Summary Connected cars form the bedrock of shared mobility operations and provide the foundation for CASE (Connected Autonomous Shared and Electric).

External telematics devices enable transforming any vehicle into an IoTenabled device and shared mobility is one of the major applications in this field.

From a financial standpoint, hardware is an investment and not merely an expense and works out best if planned for a longer term (as compared to the software). Interchangeability of these devices (compatible with a wide range of vehicles) is important so that the choice of hardware and operational requirements could be managed seamlessly.

Creating a superior user experience while leveraging telematics to help run operations more efficiently are the two most important considerations when it comes to shared mobility services.

Depending on the target demographics, business applications, feasibility, regulations and strategy the tech choice, in most cases, provides a competitive edge to businesses. After all, the role of mobility services has always been inclined to being purpose-driven and the more seamlessly woven into our day-today lives, the wider its acceptance and thereby higher returns. o

Some of the Automotive Cybersecurity Companies Akimbo Technologies

Mathematic.ai

Argus Cyber Security

MathEmbedded Consulting

Arilou Technologies

Mocana

Arxan Technologies, Inc

OnBoard Security â&#x20AC;&#x201D; O

C2A Security

OutSecure

Centri

RazorSecure

Cyper

RunSafe Security

Cymotive

SafeRide Technologie

Dellfer

Safritel Canada

Enigmatos

secunet Security Networks

ETAS

SecureThings

Flexxon

Symantec

Gamasec

Tokai Rika Co Ltd

GuardKnox

TowerSec

Infineon Technologies

Trillium

Innoventis

Trustonic

Karamba Security

Upstream Security

LynuxWorks

Vector Informatik

Perspective

The Automotive Cybersecurity Industry and Its Unique Challenges Kamel Ghali White Motion

O

ver the last decade, automobiles have seen an unprecedented level of growth in their connectivity and autonomy capabilities. Traditional vehicle electronic networks and systems that were once housed in iron cages on wheels are now exposed to the outside world through inclusion of Bluetooth, Wi-Fi, and 4G cellular connectivity. This reality has propelled the automotive industry into a new era where vehicles can have their control arrested from their drivers and placed into the hands of a malicious hacker intent on causing damage.

This damage can take the form of personal information compromise, automotive ransomware locking a vehicle down until its owner has paid a hefty sum in bitcoin, cyberterrorism, or targeted assassinations made to look like tragic accidents. The reality is that vehicles are now – and will increasingly become – targets for hackers and cyber criminals all around the world. The full extent to which a vehicle hack can affect a car’s operation was shown in 2015 when two hackers famously took remote control of a Jeep Cherokee from hundreds of kilometers away – without ever physically touching the vehicle. Since their exploits brought automotive cybersecurity into the spotlight, public awareness of the issue and increased attention from the security industry have led to more research showing the sorry state of cybersecurity in the transportation industry. New vulnerabilities are constantly disclosed, highlighting how unprepared vehicles with advanced connectivity and autonomy features are for withstanding the cyber landscape.

The Global Response To protect the next generation of vehicles, the world has seen a rise in legislation and industry standards tasked with mandating 80 | Telematics Wire | November 2020

the inclusion of vehicle cybersecurity tests and management systems in vehicle safety approval processes. Key examples of such regulations include the ISO/SAE DIS 21434 (Road Vehicles – Cybersecurity Engineering) industry standard and the recently ratified United Nations ECE WP 29 (Automotive Cybersecurity Regulation).

The standards set in place have propelled automotive OEMs and suppliers to begin prioritizing cybersecurity testing for new vehicles and vehicle subsystems. Under UN ECE WP 29, vehicles that have not been granted cybersecurity approval cannot be sold in countries choosing to implement the regulation. This includes major automotive markets such as Japan, the United Kingdom, Russia, Australia, and most of the EU. While the regulation is not directly aimed at suppliers – placing the majority of the burden on the OEMs – it remains true that OEMs now prefer to do business with suppliers that prioritize the implementing of security in their products. Suppliers will soon find themselves ostracized by the greater industry if they fail to meet the

cybersecurity sophistication demands set in place by industry and new legislation.

Rapidly Expanding Market, Insufficient Talent Resources Despite the rising urgency for security in vehicles, the talent pool is, unfortunately, very lacking. Endemic of an industry rising to such importance – essentially overnight – the number of qualified, experienced automotive cybersecurity professionals is too low to ensure that every supplier or OEM has a well-equipped security team. Universities and other institutions of higher learning are not yet equipped with curriculum to reliably produce enough qualified professionals. In an ideal world, cyber criminals would resist targeting vehicles with cyber-attacks until the vehicles are sufficiently prepared to handle and react to their assaults, but the real world is no such place – the industry needs to act now, and society will suffer if the precautions taken are not adequate.

Due to the potentially destructive consequences of a vehicle cyber-attack, automotive cybersecurity can, and should,

be a concern for all – not just industry and governments. To prevent the advanced connected vehicles of tomorrow from becoming deadly missiles in the hands of a hacker, all members of the automotive ecosystem should take the necessary steps to ensuring their readiness for the future of vehicular cyber-crime.

Ever-Evolving Threat Landscape Traditionally, cybersecurity has been a field that demands constant vigilance. New threats and vulnerabilities emerge nearly daily, and the security systems that protect the world’s networks and infrastructure require constant upkeep to remain effective. The same principle applies to automotive security while also introducing new challenges – automobiles have not traditionally been connected to the internet and have thus had to be recalled or brought into a shop to update their software. This is becoming less true as Over-the-Air (OTA) updates make their way into the design of modern vehicles but managing said OTA updates in a secure fashion is its own unique challenge. Updates need to be tested before deployment and signature checks need to be performed before installation on the vehicle to ensure no rogue software makes its way onto the in-vehicle components. These technical demands have led to the birth of the Automotive Security Operations Center (A-SoC) – a specialized platform for monitoring the cyber-health of a fleet

of vehicles and securely administering software updates and patches when needed. An example of such is the Joint Anti Vehicle Striking System (JAVSS) developed by White Motion – a stateof-the-art A-SoC platform that leverages vehicle connectivity and a robust public key infrastructure to securely monitor and protect vehicles from cyber-attacks.

Vehicle network anomalies are detected an embedded intrusion detection system and uploaded to the JAVSS backend, allowing for remote fleet cybersecurity management, OTA administration, and in-depth incident analysis. Flexible solutions such as the ones JAVSS provides will become increasingly necessary for ensuring the continued safety and security of the next generation of vehicles.

Summary The rise of connected and autonomous vehicles promises many benefits to both

society and the environment, but the risks of approaching such an interconnected future unprepared are tremendous.

Automakers and the suppliers they work with need to give cybersecurity preparedness the priority it deserves. Due to the real-world threat vehicle hacking poses to the lives and livelihoods of a vehicle’s passengers, a reactive approach to security is inappropriate – there is no time to waste. In the face of this uncertain future, firms like White Motion are helping the automotive industry prepare itself through developing dedicated cybersecurity products, training customers to bolster human resources, and sharing knowledge and expertise with the industry as a whole. A secure, connected future demands continuous effort from industry , academia, and government. Without the cooperation of every party involved, such a future will forever remain an unobtainable dream. o

Author Kamel Ghali Automotive Cybersecurity Technology Architect White Motion Kamel Ghali is an Automotive Cybersecurity Architect at White Motion – subsidiary of the global supplier Marelli. Kamel has excelled in the automotive security industry for over 3 years as an expert car hacker, trainer, and contributor to industry-focused communities worldwide including the SAE and ASRG. At White Motion, Kamel heads the vehicle security research team, assessing vehicle systems and training customers in state-of-the-art car- hacking techniques.

November 2020 | Telematics Wire | 81

Products & Services

Ouster announces solid-state digital lidar sensor Ouster announced a new solid-state lidar sensor based on its digital lidar architecture. The new ES2 sensor will be the first true solid-state, high-resolution, long-range digital lidar sensor. With a $600 expected price for automotive production programs with SOP 2024 and a 200+ meter range, Ouster’s new sensor offers a low-cost option for Advanced Driver Assistance Systems (ADAS) and industrial automation.

Hitachi Automotive Systems has new automated parking brake Hitachi Automotive Systems, Ltd. is introducing a new heavy-duty automated parking brake (APB HD) especially designed for pickup trucks, vans, SUVs, and light commercial vehicles.

Developed by the company’s Brake Business Unit in Europe, the new brake system already has gone into production in North America and Europe. Several Hitachi Automotive Systems customers have introduced the new brake system on new vehicles in September in Europe and October in North America. The brake system will go into production in the AsiaPacific region in 2021.

Hesai unveils PandarXT, 32-Channel Mid-Range LiDAR with LiDAR ASICs Hesai has released a new 32-channel mid-range LiDAR. Based on a new system architecture integrating Hesai’s LiDAR ASICs, PandarXT is a cost-effective solution designed for multiple applications, including low-to-medium-speed autonomous driving.

PandarXT features a minimum range of zero and outputs a valid point cloud even when an object directly touches the sensor’s enclosure.

It also has millimeter-level ranging accuracy and superb precision.

Furthermore, its improved reflectivity accuracy and greater dynamic range enable accurate and consistent detection of retroreflectors, low-reflectivity targets, and object boundaries with sudden changes in reflectivity. Consistent with every LiDAR in Hesai’s Pandar series, PandarXT has undergone and passed stringent reliability testing to ensure robustness and reliability in any operational environment.

82 | Telematics Wire | November 2020

Continental invests in AEye, a LiDAR technology company Continental made a minority investment in LiDAR company AEye, Inc. a LiDAR sensors startup.

AEye LiDAR offers maximum leverage for passenger and commercial vehicle applications because it combines a high dynamic spatial resolution with a long-range detection. The first series production is currently scheduled for the end of 2024. By partnering with AEye, Continental complements its existing shortrange 3D Flash LiDAR technology, which goes into series production later this year, supporting automated driving program.

Products & Services

Fyusion announces automated vehicle inspections solution Fyusion Inspect is an automated damage analysis and condition reporting tool built on ALIS AI platform. It produces accurate and consistent vehicle condition reports based on 3D images, which can be captured by most smartphones via a simple, guided process. Fyusion Inspect simplifies the inspections process, enables more consistent and objective reporting, and reduces the financial burden of using on-site professional vehicle inspectors.

Airbiquity launches OTAmatic Vehicle Configurator Airbiquity® launched its OTAmatic® Vehicle Configurator, a tool for defining and managing connected vehicle software. The OTAmatic Vehicle Configurator gives automakers insight into the precise hardware and software configurations within a vehicle, manage known combinations of electronic control units (ECUs) and software versions in vehicles, and meet emerging government compliance requirements for type certified vehicle systems. The OTAmatic Vehicle Configurator gives automakers the facility to deal with these issues and better control the software configurations in their vehicles.

Green Hills Software expands leadership in automotive cybersecurity Green Hills Software, announced it has adopted the two new international security standards and regulations for automotive cybersecurity – ISO/SAE 21434 and UNECE WP.29 – for the INTEGRITY® realtime operating system (RTOS) and associated products and services.

Livox brings two new solutions for long-range and short-range detection

Livox Tech announced two new product solutions, the Mid-70 for blind-spot free short-range detection and Avia for improved long-range detection.

Mid-70 offers a wider industry-leading FOV of 70.4° in both the horizontal and vertical directions, while the blind spot range in the vicinity is only 5cm. After being installed onto a vehicle, the Mid-70 can offer zero blind spot to the perception system.

Avia Lidar solution only weighs 498g, with the measuring range increased to 450m. The Avia can switch between the repetitive and non-repetitive scanning patterns with an increased FOV of 70°. Featuring triplereturn, the Avia is able to capture significantly more details, making it the ideal choice for critical power line inspection, forestry, mobile topographic surveying, and mapping, as well as assisting with the planning for future smart cities.

Escort BLE and GalileoSky 7x Integration GPS/GLONASS 7x trackers manufactured by GalileoSky are now compatible with wireless Escort TD-BLE sensors as well as other Bluetooth devices of the same line-up.

GalileoSky can offer functionalities like- simple installation, flexible configuration, and easy connectivity with many different external devices, including the bluetooth.

From now on all devices from the new line up (GalileoSky 7x, GalileoSky 7x 3G, GalileoSky 7x Plus, GalileoSky 7x C) can work with both the wired fuel level sensors (TD-100, TD-150, TD-500, TD-600) and wireless one (TD-BLE). The data on fuel consumption, collected by Escort sensors and transmitted to the GalileoSky trackers, can be processed and stored at Wialon, for example, or any other monitoring platforms that support communications protocols GalileoSky or EGTS.

November 2020 | Telematics Wire | 83

leadership view

Kamyar Moinzadeh

President and CEO, Airbiquity

When did Airbiquity start working on OTAmatic and what motivated its development?

We debuted OTAmatic®, an industry leading, multi-ECU overthe-air (OTA) solution that securely orchestrates and automates software update and data management campaigns, in 2017. After 15+ years of experience working in the automotive telematics space, and knowing software would be increasingly embedded into connected vehicles to power new features and services, we saw a future automaker priority for updating software and managing data collection remotely. It was clear to us that OTA capabilities would be crucial to efficiently manage software and data across the entire lifecycle of connected vehicles, improve consumer driving experiences, and continue the evolution of advanced driver assistance systems (ADAS), vehicle to everything (V2X) communications, and autonomous driving features. This led us to work closely with automakers to understand their emerging OTA requirements and build the OTAmatic product to meet them.

Since 2017 automakers have universally come to understand the importance of having an OTA platform to service and support their product offerings. Typically, automakers are deploying OTA software update management capabilities first, followed by OTA data management capabilities. We designed and built OTAmatic to provide both software update and data management capabilities from the start so our customers can use one system to accomplish both tasks.

OTAmatic has been well received and thoroughly vetted by multiple leading automakers. We don’t talk about customer programs that are in development, but we have made many announcements that illustrate OTAmatic market momentum.

In 2019 Airbiquity received a strategic investment from Toyota Motor Corporation, DENSO Corporation, and Toyota Tsusho Corporation and formed a partnership with YESWAY to bring the product to Chinese automakers. And for multiple years we’ve been working with other leading companies including NXP, STMicroelectronics, Renesas, Arity, SafeRide, Teraki, and Wind River to pre-integrate technology to enhance OTAmatic and speed customer evaluation and deployment.

The automotive industry is in transition and services like OTAmatic could be the default software update tool. Do you see cybersecurity threats disrupting it?

In our ever-connected world, cybersecurity is more important than ever. In order to mitigate cybersecurity threats associated with OTA systems, automakers must ensure that their technology suppliers have a robust security framework built into their offerings. Airbiquity understands how important security is not only to automakers but also consumers. Automotive software recalls, software hacking and intrusions, and data privacy breaches can be detrimental to both brand and customer loyalty—not to mention scary for drivers. That’s why OTAmatic uses heavily vetted and widely adopted standards-based security technologies throughout. OTAmatic also features Uptane which 84 | Telematics Wire | November 2020

is a comprehensive security framework specifically designed for automotive electronics. We believe Uptane is the current gold standard for automotive OTA security mitigation.

How does OTAmatic benefit automakers and consumers?

OTAmatic provides many benefits to automakers and consumers: • Update defective or down-level vehicle software remotely eliminating the need for consumers to take the time, expense, and inconvenience of going to dealerships for software related services • Lessen the time and expense requirements for automakers to complete software related vehicle recalls • Lessen the time and expense requirements for automakers to address software related cybersecurity issues • Introduce new vehicle features and performance enhancements—both for free and paid—after a vehicle has been manufactured and purchased. What consumer wouldn’t be delighted to know a recent software update improved the fuel economy or enhanced the safety features of their second most expensive purchase after real estate?

• Dynamically collect operational data from vehicles that can be analyzed to power proactive service recommendations to protect consumer vehicle investments and offer highly personalized and relevant transportation services to enhance consumer driving experiences How does Airbiquity see the current COVID-19 pandemic and the resulting slowdown in the automotive industry?

Like many other industries COVID-19 initially dealt a blow to the automotive industry and created a very difficult business environment in terms of automotive sales. But we’re starting to see automotive sales rebound as we move towards 2021.

We’re also seeing automakers maintain prior investment levels in developing new technologies like electric vehicle platforms, autonomous driving capabilities, and the prioritization of OTA systems because they are so crucial to the operation, maintenance, and security of connected vehicles and monetization of data centric consumer services.

Do you foresee new technology adoption by the automotive industry or its introduction in the market going on low burner?

Every industry today is driven by technology advancements and the automotive industry is no exception. While our industry is notorious for moving carefully and slowly—production cycles take multiple years—automakers know they need to incorporate the latest and greatest technology to stay competitive. Leading automakers are continuing to push forward with electrification, autonomous, and new mobility service development – all of which are highly dependent on vehicle software and data. OTA systems are critical to the success of these initiatives and are therefore being prioritized. o

0.05° ATTITUDE

0.02° HEADING

1 cm

POSITION

The Smallest RTK GNSS/ INS for Robust Real-Time Navigation

NEW ELLIPSE-D

Ellipse-D RTK Dual Antenna

»

Quad constellations and Dual-frequency

»

Fusion with Pulse or CAN OBDII Odometer

»

Fast Initialization

Ellipse-N RTK Single Antenna

Visit our website: www.sbg-systems.com

OEM RTK Best-in-class SWaP-C

Map Maker’s View

HERE’s ‘think global, act local’ strategy seeks to help make India ‘atmanirbhar’ In an exclusive interaction with Telematics Wire about the importance of location intelligence in a post COVID era, Nikhil Kumar, Country Head, India, HERE Technologies spoke about how India drives a considerable portion of the company’s R&D capabilities, with smart governance solution innovations rolled out from India for a global audience.

Can you tell us about HERE Technologies initiatives in automotive industry?

HERE is at the centre stage of the automotive industry with its pioneering work in creating digital representation of the physical world through our maps. This is not limited to digitalizing what you see on ground, but also providing a set of services to extend its applicability in different use cases.

From a content company, HERE is becoming a platform company. It is expanding from automotive to other sectors like transportation & logistics, tech-media, telecom, retail and more.

What is the current scale of HERE’s operation in India?

In India we have about 4000 people of the global HERE workforce. They are highly skilled professionals. They are part of the team creating automation into this entire platform centric approach. Leveraging their local presence and extending that capability into the India market has been of advantage for the local operations.

Nikhil Kumar

Country Head, India HERE Technologies 86 | Telematics Wire | November 2020

What are HERE’s products and services being offered in India?

We all know that the government is talking about “act local and think global”. In this context, HERE is more Indian than any other company. At the centrestage of our operations whether it is in engineering or global content; the operations team is seated in India. Now that is one aspect which is operational capability existing in India and trying to extend what we build in India to the global market.

On the business side, we are working on enhancement of reach and extension of geospatial technologies into decision making by governments, businesses and communities, which is more about location based decision making. Out of these, those which make a lot of sense to us and so far what we have done is, we have put this notion of accelerate, retain and unlock.

We ‘retain’ our automotive focus where we already have good presence. We have added feather into our cap, with Hyundai Venue vehicles, in which we are providing live search and traffic data. Put together, Maruti and Hyundai represent about 65 to 70% of cars manufactured yearly in India.

Next is the ‘unlock’ part which we are following in the public sector. We have given smart navigation and mapping platform to state governments, allowing them to not only to use the content that we offer, but also use location services like geocoding, routing, and geofencing all within their own server, by bringing their own private layers of data from different departments, whether it is Fire Department, Enforcement Agencies, Hospitals, Education on top of it and extending location based services.

Any specific tools or apps for transport and logistics?

In transportation and logistics we have various use cases for commercial vehicle, yard & warehouse management etc.

We are providing apps and customized application services to help business in planning, routing, dispatch and more. In this space, we have a set of web based APIs and also native iOS, Android based SDKs. We work with local solution providers and system integrators in logistics space, except for some cases like with some of the state transportation where we work directly.

You launched HERE WeGo Deliver during the pandemic to help businesses. Tell us more.

HERE WeGo Deliver was useful during the pandemic. During the early phase of COVID-19, small businesses were struggling to move to online transactions.

The challenge was how to carry out the last mile delivery. Our platform made it easy for enterprises. One just needs to put a ‘.csv’ file of drop locations, which could be multiple locations and considering various parameters, it works out a delivery route plan.

HERE WeGo there are two things, one

is for B2B and other is for consumer space.

Now we have extended that HERE WeGo Deliver for small and medium enterprises.

We have done a lot of visibility for HERE WeGo Deliver, on how it benefits the businesses because our SME businesses are our prime focus. But in order to enhance the brand quotient for HERE WeGo, we also needed to enrich our India content.

During the last year and half, we have put a lot of effort in the way we are capturing and writing our content. Our ability to acquire those probes data which actually goes into building your traffic, was limited in India.

This required a lot of investment, which over the last 18 months we have made. And we have moved from 500 million probe points in a month, to 1500 million, three times enhancement. You will also see visibility campaign around HERE WeGo and we definitely believe that increasingly people will know and use HERE WeGo in the coming weeks and months.

Can you share something about HERE Marketplace and its response in India?

Marketplace is a collaborative big data analytics platform. Because of its native construct being very API driven and agnostic to sources and type, it allows companies and developers to integrate the location context into the application and services for various industry segments. It can integrate different types of data from sensors, wearables, physical infrastructure, IoT devices, all kinds of data sources, coming in different formats, as it is agnostic to types and sources.

Hence it allows the holistic aggregation of all the sources at one platform which become very collaborative and also allows depending upon how we want to use it.

In India, we are working with different business organizations and large business group houses. They have different businesses within their group companies, and they would like to use the power of different sources of the data they collect. Put into a pipeline where everything becomes normalized to be run on the business logic to be used and extended for different services like- geocoding, routing and geofencing.

On the other side, the same set of data they can monetize. This monetization is more a concept like a typical marketplace, where somebody whom you do not know as to whether he is going for prospecting or using your data. So it is indeed a platform

which is not in itself complete, but it becomes complete in association with other sources of data and eventually becomes a very attractive proposition for a buyer. That notion we are bringing in the market, that it is a very massive platform oriented offering that we are providing, and we have started extending in Indian market. We are still in a planning stage because we are trying to bring that with some large case of success story and then extend into the normal customers and businesses.

Will HERE use data from sensors in automotives?

All the data sources which are either mounted on the vehicle or as a wearable; are providing different types of location based context. We are actually working with partners in acquiring data from sources including vehicle sensors and anonymizing it, as this is very important in terms of data privacy. Thereafter delinking the private attribute from the geolocation content and then using it for different use cases. It’s already happening here for not only India but we are collecting terabytes of data globally, which is coming from the sources which you are referring to and then we use artificial intelligence and machine learning to unearth the geospatial context and intelligence inside it.

Do you see HERE catering to the needs of autonomous vehicles in future?

Not only in autonomous, but high definition content it is going to be very useful in the way we are managing our Smart City infrastructure. Transportation, logistics, navigation and many other areas will see its usage. We have already started working and creating applications around these.

Do you see synergy between the Smart Cities, ITS and Smart Vehicle which will all be connected?

It’s an industry challenge. We need to have the option of being connected. Next, what kind of connectivity or protocol should that be there. 3rd is being able to manage all the sources of data and its users, by providing the information back and forth. It may call for Smart City to be a little more agile in its construct. Some of the cities have already started doing it, and I am hopeful that the majority of the Smart Cities initiatives will get adapted to this notion which is agile, and platform driven. o

November 2020 | Telematics Wire | 87

TW Story

There is no quick money, if someone has made it, it’s an aberration

V

adiraj Katti’s childhood in Dharwad, Karnataka, was full of dreaming and nurturing desire to do something. His father was a professor and his extended family members consisted mostly of academicians and teachers. As a middle class family in the 1970s, which had expenses budgeted, it was difficult to have all desires fulfilled. But limited means fuelled his curiosity, making 88 | Telematics Wire | November 2020

him observe the elderlies in terms of what he would be doing or not doing.

When in 7th grade in school, he was distributing newspapers early in the morning, for earning Rs 20 a month, without informing anyone at home. The urge to earn own money made him borrow friend’s cycle and distribute newspapers.

The ideas of doing something, evolved over time, with changing surroundings,

as he grew and moved from school to college. During his 12th grade he took a contract work for canal along with his friend, who had a contractor’s licence.

During his college days in Bijapur, he opened a garment shop in Bijapur with a partner, who runs it even today.

The entrepreneurship journey has not been easy for Vadiraj, as the family which was into academics and teaching could not relate

to it and would often persuade him to think traditionally.

In 1990 he joined multinational bank as sales executive. By the time he quit his job in 1996, he was handling the entire southern region of this bank.

Soon after he was on his own, with business in Pagers in 1997, a growing business during those days. Soon the business of Pagers was being replaced by mobile phones and so did his business portfolio. He was having South India distribution for Samsung, Motorola and others. He was instrumental in bringing two mobile phones to India. He set up an entire ecosystem for them in India. But, mobile phone distribution, had little scope for innovation and was more of trading, and started losing interest. His family was not yet supportive of his business ideas, insisting on reasonable success. Perhaps this pushed him to experiment with something new, exciting and innovative.

Technology from early days had fascinated Vadiraj. Sometime during 200708, he came across Kiran, who was with Siemens working in the field of vehicle telematics. Kiran had spent a good 7-8 years working on the entire product development life cycle, while also being part of a product called vehicle data recorder. Over the next few months they continued sharing their ideas and exploring something exciting. In the fag end of year 2008, they decided to launch a company in partnership in the field of vehicle telematics and iTriangle came into existence in early 2009.

Though, not many were encouraging about vehicle telematics during those days, Vadiraj and Kiran were convinced with the growth opportunities in this segment.

Vadiraj and his team started with a quick survey to map the issues faced by the users of vehicle tracking devices. Though many in the transport sector were convinced about the benefits of vehicle tracking, the service and support offered during those days, was keeping them away from making upfront investment in tracking devices. It was quite common amongst the telematics service providers or TSP players in the aftermarket segment to import devices from China and other countries and write their own software application to provide vehicle tracking solutions. Many times these applications were not stable and created apprehension in the transport industry, making them stay

away from making capital expenses in vehicle tracking systems. Sensing a need for a stable application and reliable support system, Vadiraj and his team started moving towards developing vehicle telematics platform, which will include hardware, firmware and software along with setting up infrastructure for support and maintenance.

The initial years of his venture were more about development and design of vehicle telematics solutions. In the second quarter of 2013, he started deploying solutions.

Amongst the first few projects, the one from the Ministry of Defence vindicated his belief in developing the platform, rather being a hardware vendor. Data security was a nagging issue for MoD and their R & D work for the last 3-4 years paid off in overcoming financial qualification required to bid for the project. In the initial years he preferred to be in the B2C space also, more to have first hand feedback from customers and end users. iTrinagle acquired about four thousand vehicles in B2C over the next couple of years. Using the understanding of user needs and stable solution, he started offering services in a modular fashion to other TSPs in India.

Amongst the learning acquired, in Vadiraj’s words- “One important thing that we learnt is whatever we do, we need to create prosperity and wealth in the business. Responsibility of making the business successful rests with the entrepreneurs.

Lastly, you need to keep harnessing talents that come across your way.”

Failures or little successes in his earlier ventures, did leave him enriched with experience and learning. Important beingSuccess should be shared and failure is to be owned by the entrepreneur. He was methodical in his approach to analyse failure up to the directions and guidelines set by the entrepreneurs. Value of money and need to be profitable has been of prime importance to him. In early days Kiran, being a techie had insisted on technology or idea which could make the difference, but this notion changed with time and today have realised that, while ideas are good to begin with, money is important to make it happen, particularly in

a capital intensive industry.

Like many entrepreneurs who start with desire to do everything, it was with Vadiraj even with his iTriangle initiative. He wanted to do many things, or in other words did not want to miss out any opportunity. This made his resource spread thin, with his team working on multiple projects from varied domains. After spending about a year in this mode, he realised that the quality of service is taking a beating. His customers are not happy. Realising the need to be focussed, soon he changed the business approach in 2016. Though at a cost, but an important lesson was learnt. Today, Vadiraj is not only planned, but reasonable in his approach to product development, when allowing 18 to 24 months time frame to develop a product.

Looking back at the journey of nearly 12 years, Vadiraj seems pleased by his own success. He never thought that he would be having four hundred thousand devices in the Indian telematics ecosystem through his partners.

As of today, iTriangle is not a funded company. Entire investment has come from directors. The existing board of iTriangle consists of family and friends, those who have invested in trust. The other portion of investment has come through bank debt.

Vadiraj was cautious about going to market for funding. He was apprehensive that a funding partner may push the company away from the path of innovation. Though the VC funding option was there since 2014, he preferred to build the company from selffunding, its own profit and bank debt. This is where he thinks startups fail due to (1) lack of patience, (2) lack of planning and (3) looking forward to making some money by achieving some valuation. He is of firm view that one should go after creating value for the end user, this will result in valuations for startup. According to him, there is no quick money, if someone has made it, it’s an aberration.

For Vadiraj, who has been trying to be on his own since early childhood, he appears quite satisfied with the way things have spanned out for him. If there is one area where he would like to contribute going further, its education. He has a desire to do something which can help reach quality education far and wide in India. o Vadiraj Katti, Kiran A R and Anup Naik are the people who drive the business at iTriangle.

November 2020 | Telematics Wire | 89

Join us at

APACâ&#x20AC;&#x2122;s Biggest Connected & Autonomous Vehicle Conference & Exhibition

6th Edition

presents

2021 1, 2, 3 June Radisson Blu, Bengaluru India

ANALYTICS 1100+ participants

80+

Exhibitions

20+

countries

60+

speakers

500+ visitors

10+

Sessions & Expert Panel

10+ Vehicle Display

10+

Keynotes

20+ Countries

(India, USA, Canada, South Korea, Japan, Australia, UK, Spain, France, Singapore, Russia, Israel, Germany, Brazil, Israel, Italy, Switzerland, Thailand, United Arab Emirates, Sweden, Mexico, Sri Lanka, South Africa, Netherlands, Nepal)

For more details, please contact

Anuj Sinha | )+91-87440 88838 | * anuj.sinha@telematicswire.net

Visited

Visited

Checkpoint

Checkpoint

JOB DISPATCH

Utilise your fleet with efficient work planning

Job dispatch helps you to easily plan, allocate & monitor work your vehicles. You just need to create a job, set a schedule for type, add checkpoints and allocate the job to the vehicles. And you are all set.

â&#x20AC;&#x153;

â&#x20AC;?

BENEFITS Increased Productivity

Reduced Cost

Maximized fleet utilization

Easily plan & allocate trips for your fleet.

Manage jobs for multiple vehicles which helps you to reduce your business cost.

Make sure none of your vehicles remain idle with fleet utilization status.

info@uffizio.in www.uffizio.com

ZED-F9P

Multi-band receiver delivers centimeter-level accuracy in seconds Highlights Multi-band receiver delivers centimeter-level accuracy in seconds • • • • •

Concurrent reception of GPS, GLONASS, Galileo and BeiDou Multi-band RTK with fast convergence times and reliable performance High update rate for highly dynamic applications Centimeter accuracy in a small and energy efficient module Easy integration of RTK for fast time-to-market

Easy integration of RTK Integrated RTK •

• •

Multi-band in module

No third party SW integration on host required No resources (RAM, MIPS) required on host No license fee or NRE for the host SW

• •

Integrated HPG multiband RF chain with guaranteed performance Little design effort, no design risk

Navigation applications are demanding higher accuracy to increase productivity • • • • •

With high availability In all environments At sensible cost level Easy to integrate Globally deployable

Centimeter-level accuracy

Fast TTFF

Global Coverage

Dead reckoning

Multi-constellation and multi-band

u-blox Singapore Pte. Ltd.

• • • • • •

Quick to market No technology risk Low engineering cost Low capital investment Future proof Reduced supplier base

Commercial UAV

Ground robotics navigation

Heavy machine navigation

Lane-level navigation

Industrial navigation and tracking

DBS House-26, Cunningham Road, Bangalore - 560052 Ph. No. - +91-80405092, Mob. No.: +91-9945329985 | E-mail: info_in@u-blox.com