Keeping-Up With the Joneses’ Cybersecurity

When Jesus was asked “Teacher, which is the greatest Commandment in the Law?” He essentially decided to introduce an 11th Commandment: “You shall love your neighbor as yourself.”

I cannot help but think of that statement every time someone asks me: “Steve, which of the Top 10 Cybersecurity Risks is the greatest?”

Therein, I’m going to introduce an 11th risk: “Not Keeping-up with the Joneses’ Cybersecurity”.

This previously unmentioned risk requires a bit of background about the changing standards, legal precedents and then the various aspects of the overall risk.

The Change in Functional Safety

The propagation of software-enabled systems in automotive has led to the steady iteration of standards to ensure continued Functional Safety (FuSa). The de facto standard, ISO 26262, is an adaptation of the International Electromechanical Commission (IEC) 61508 functional safety standard, and now specifically defines functional safety for automotive equipment to address possible hazards caused by the malfunctioning of electrical and/or software-enabled systems.

ISO 26262 offers design recommendations – from conceptual development to product decommissioning – and assigns processes for engineers to quasi-dictate acceptable risk to a system.

In the midst of defining risk classes, called ASILs (Automotive Safety Integrity Levels), it specifies requirements, validation and verification measures to ensure a sufficient and acceptable level of safety. Automakers mandate an ASIL level for a system, component, etc., and the supplier has the burden of improving its processes to meet the standard, frequently with the help of unbiased third parties (consultants) to decrease risk.

Among the iterations is a 2018-19 change that includes a new key requirement dictating operative communication channels between functional safety and other related disciplines. Cybersecurity and its influence upon functional safety considerations is squarely in the crosshairs with a new Annex showing example interfaces between functional safety and cybersecurity.

While OEMs and FuSa practitioners apply the standard as a guidance “chinning bar,” lawyers also consider ISO 26262 to be the technical reference for legal arbitration. Therein, lies the second item worth understanding as background info: the legal burden of precedents.

The Burden of “State-of-the-Art Technology”

Something I did not fully understand until starting this article – which makes me as much the student as the teacher – is that depending upon the continent, engineers and/or companies have a legally enforced burden per precedents in rulings to provide functional safety designs that include “state-of-the-art” technology that is economically practical. All those phrases are VERY loaded ones, so we will hold off on defining taxonomy, other than providing these three automotive, liability cases:

1971 NORTH AMERICA Garst v. General Motors: The first two paragraphs of this ruling set precedence in law that 1) the manufacturer must show reasonable care in the design of its products including alternatives known at the time, and that they are not required to design products “… so that they are foolproof or incapable of producing injury.”

2009 EUROPE Plaintiff v. BMW: A ruling for BMW is overturned in the Federal Court of Justice (a.k.a. Court of Appeals) that BMW did not provide a sufficiently safe vehicle since false triggering of the side airbags occurred when heavy blows (a.k.a. potholes) against the underbody were interpreted like a crash pulse. BMW knew a more complex, expensive, state-of-the-art design and chose not to implement it.

2012 NORTH AMERICA Aguirre v. Mitsubishi Motors North America: Lizabeth and Jorge Aguirre successfully sued Mitsubishi because the safety performance of their 2003 Eclipse did not, ironically, eclipse that of the Chevy and Dodge sister vehicles built on the same platform. The plaintiffs’ lawyers demonstrated that only the design of the Eclipse did poorly because of a design defect that could only be remediated by the inclusion of side-impact airbags, but Mitsubishi alone made the airbags optional to save cost.

In North America, it appears the burden is to show the vehicle is not just less safe, but essentially defective without the economically viable, “state-of-the-art” technology, and the corporation protects the individual from said liability. According to German law, both engineers and car producers are generally liable for injury to a person caused by the gross negligent malfunction of a component or system and state-of-the-art technology must also be applied. As noted by Hans-Viggo von Hulsen in “Design Liability and State of the Art: The United States and Europe at a Crossroads”:

“The design of any product evolves within the scientific, technological, and socio-economic environment existing at the time of the product’s conception. Particularly in the case of complex products, the period of conception extends over several years. An example is the approximately 5-year conception period for the design of an automobile. [This is] followed by a production period during which the product may be manufactured for perhaps five to 10 years before replacement by a redesigned or new model.”

In these cases, if the malfunction could not have been prevented by adhering to the technical standard (e.g. ISO 26262), the liability is set aside, however the new cybersecurity Annex paired with legal precedent opens Pandora’s Box on what state-of-the-art cybersecurity technologies provide sufficient safety.

So now you understand my 11th unspoken cybersecurity risk: “If you haven’t kept up with the Jones’ cybersecurity, you are facing untold product liability.”

So What’s The State-of-the-art Technology for Cybersecurity?

Great question. That answer will change the instant this article is published and likely will require an automotive OEM to demonstrate a staff researcher whose sole responsibility is constantly evaluating options throughout the conception phase. Woe to the weakest cybersecurity-link because they shall be the target of the hackers and lawyers alike.

What’s an economically-viable technology? Another great question that I approached in a previous WardsAuto article as well (see “#1: How Much is Enough?”).

The short answer: Any attempt to calculate Return on Investment (ROI) is fraught with inaccuracies and, therein, anything calculating what’s economically viable is built upon a house of cards.

So maybe the question should be, “What should we be constantly evaluating?”

I think the answer there would be unchanging and simple in concept: Prevention and Detection.

PREVENTION: This seems to be the most economically viable and the path that many OEMs have headed-down. Most have begun to add gateways in the networks with white-list filters that block CAN messages violating explicit, basic protocols. These gateways are presently separate from other modules because they were add-ins during that complex automotive lifecycle. But since they are typically built by major Tier 1s electronics companies (such as Bosch, Lear, Continental, Harman and Mobis), suppliers will likely bundle them as partitioned functionality within other modules in the long-term (also known as “Smart Gateways”). Also included in most modules will be simple protection code like Bootloaders.

What has not hit the market in automotive yet, but is state-of-the-art in the software industry, is a Control Flow Integrity (CFI), which has existed in some form since 2005.

CFI hardens the software against in-memory attacks by performing runtime integrity for function calls and function returns. When deviation from the software’s original function flow is detected, such as an exploit attempt against a hidden software vulnerability, the hacked process automatically is restarted using the process’s fail-safe mechanism.

The restart cleans up malware from memory and prevents the attack. CFI enforcement and overhead used to be complex in the early days, but now CFI enforcement is practical: it is compatible with existing software and can be done efficiently using software rewriting in commodity systems. A few weeks ago, Google announced its launch of CFI in the Pixel 3 Android devices,Google announced its launch of CFI in the Pixel 3  which may or may not translate perfectly to automotive. That said, minimally Karamba Security has a like-technology, and can be applied economically to the safety-critical modules of a vehicle, although any module that talks on the CAN network can arguably become safety-critical.

DETECTION: As mentioned in one of my previous articles, detection is still in its infancy. At the time of this publication, only a handful of OEMs have Automotive Security Operation Center (ASOCs) that include any detection of cybersecurity hacks on their edge devices, also known as cars.

Running an ASOC is expensive (24x7 personnel in multiple geographies) and the operational costs can be significant depending upon the number of false positives. The most expensive cost might be the constant calibration of the Intrusion and Detection Software (IDS) -- the watchdog of unwanted messages on the network – since new modules can be running changes with new software, messages, etc. As one Chief Information Security Officer recently told me, “No one is implementing those since the economics don’t make sense, and I’ve talked with all of my peers.”

That said, remaining in semi-blissful ignorance will become expensive, too, so the OEMs must find a solution.

My recommendation is to start with some type of CFI-to-ASOC solution. If someone tries to hack into a module, it should not only enact its prevention, but additionally communicate that protection to the Mother Ship as a data point for detection. With enough data points showing the risk’s order of magnitude, maybe a different business case can be made for more detection (and prevention).

About Steve Tengler (above)

Steve has worked within the automotive industry on the connected car for over a quarter of a century for some of the top brands in world: Ford, Nissan and OnStar. He most recently was a Line of Business Leader for cybersecurity products for an automotive Tier 1 and now is a Principal at automotive consultancy Kugler Maag.

He has nearly 40 publications to his name and 50-plus patents and can be contacted at [email protected] and www.kuglermaag.us

About Steffen Herrmann (below)

Steffen started work in the automotive industry more than a decade ago developing safety critical mechatronic steering systems. He joined Kugler Maag Cie, 7 years ago and is Managing Consultant and Director Sales.

He is a certified Automotive SPICE® Principal Assessor and certified instructor. He has performed 50+ Automotive SPICE® Assessments in the last years and successfully trained over 100 Automotive SPICE® Assessors. Steffen lives in Munich, Germany, and can be contacted at [email protected]