Do you need to improve your automotive product development, to increase efficiency, or to comply with ASPICE and Functional Safety?
You are at the right place.
Connected Car Safety And Security: The Future, Complex Interchange Between Them
Mixing together safety and security for the connected car seems as natural as merging peanut butter and chocolate: both individual items thriving decades independently before the combination, but now together they can create a better product. For automotive, safety was birthed in the seminal court case of Macpherson vs. Buick Motor Company (1916) where the court first started using phrases like “foreseeable use of the product“, “liability and “negligence“ in the same ruling. And although transportation cybersecurity arguably first materialized within the MIT Railroad Club of 1948, automotive experienced its first hack in 2002 when powertrain calibrations were being reprogrammed. Nearly twenty years of co-existence.
The thought that safety and security go together easily rolls off the tongue, but the complex exchange of ongoing information requires expertise and cooperation that must be understood and built going forward.
But the connected car has now forced together the combination of safety and security. As stated best in 2019 by Dimitrios Serpaos, a professor at The University of Patras and Senior Member of IEEE, “Specifically, we argue that safety requires system security and dependability.“ And just like the 1972 Reese‘s commerical for peanut butter and chocolate, mixing together two seemingly independent ingredients can initially seem irregular from each party’s perspective. Yet that’s the reality. The need. And the superior end product after that consternation.
So to demonstrate the interdependence and the complexity of the merge, we shall walk chronologically backwards the product lifecycle from grave-to-cradle with two experts in each arena and look at the overlap at three critical touchpoints: post-sale operations, pre-sale validation and pre-development design.
Computer servers in dark corners of the world shall be tracking vehicles in the future
to look for cyber criminals and to update software patches. Part of the complexity
between the two specialties shall be how to manage the operational portion.
Interchange #3: Post-Sale Operations
Easily the newest to automotive is the ongoing detection and response aspects. Starting next year, The United Nations Economic Commission for Europe (UNECE) regulations will disallow vehicle sales in large swaths of the world sans certifications that require, in part, an ongoing relationship with the vehicle. Monitor. Detect. Protect. Update.
Although both of the standards for Functional Safety and Cybersecurity discuss the need for an exchange of information to support these operations, they do not – and cannot – exactly specify how and when to do intermingle since every project has different complexities. “After the start of production, [Functional Safety] goes into a mode of ‘field observation‘, states Sebastian Schröder, a Senior Consultant for Kugler Maag Cie. “As there is a failure, there’s a determination of whether or not it’s a design failure. This effort, though, is much smaller than the ongoing detection, protecting and updating for cybersecurity.“
Markus Steinmetz, another Senior Consultant at Kugler Maag Cie, brings the perspective of Cybersecurity. “To extend his point, in Functional Safety there’s only effort when the customer informs you the system isn’t working properly anymore. But for Cybersecurity, maybe the customer does not even know there’s an issue. Exploitation of vulnerabilities might scale much faster than system failures. This requires the manufacturer to be much, much more active in monitoring.“
So Cybersecurity Operations Centers (SOCs) around the globe will be seeking anomolies in the network and basing forensic activities around a perponderance of the evidence, which will spark action from an Incident Response Team likely in the form of a software update. That new software likely requires a Functional Safety review, but when to gather the gang isn’t perfectly perscribed. “From my experience,“ states Steinmetz, “this requires an expert to facilitate when to bring the parties together. There is always pushback since the soft requirement for alignment requires convincing the engineers with other, urgent tasks that the two topics are interrelated.“
Pre-production inspection and verification might be the most obvious touchpoint for some, but the reasons behind such coordination might not be as intuitive
Interchange #2: Pre-Production Validation
An interesting set of touchpoints that might not be obvious to the average bystander would be the middle step of validating that the two activities didn’t head down conflicting paths of risk remediation. “You could have contradicting requirements such as ‘unlocking the doors‘,“ explains Schröder. “Unlocked doors might be a safe state from the perspective of the Functional Safety Engineer, but it might be a damage scenario from the Cybersecurity viewpoint or perspective.“
“There’s a strong need to align,“ adds Steinmetz. “There is a design concept for both domains, which consists of requirements and a solution. The proposals for the solutions must be aligned once again to make sure those contradictions are either resolved or have full visibility.“
This might mean adjusting the Technical Safety Concept or the Cybersecurity Concept, but fixing those conflicting requirements before it becomes a launch defect or field vulnerability is money well spent.
Interchange #1: Upfront Design
For fans of psychological thrillers, the climatic reveal of this saga is not so surprising: the foundational fulcrum between functional and dysfunctional is rooted in the infancy of the project. Address problems early and the child avoids being a trainwreck of an adult, although in this thriller it’s fraternal twins instead.
“Functional safety puts the focus inside the product to a dedicated spot that demonstrates a behavior that’s not intended. A failure.“ says Steinmetz. “Cybersecurity does not start inside the product, but outside the product with a human: the attacker.“
And so much like Julie Andrews and The Sound of Music, they start at the very beginning. “The first step for Functional Safety and Cybersecurity is a close-to-complete system description. What is our system doing on a vehicle-level because this is the information I need before I assess ‘risk‘?“ says Schröder. “Both areas should start as soon as they know what they need to build.“
Once that foundation has been built via robust systems engineering, the teams should begin interacting for the determination of risk. “Both domains have a big work product defined – the one is the HARA (Hazard Analysis and Risk Assessment) and the TARA (Threat Analysis and Risk Assessment) — and there shall be alignment,“ says Steinmetz. “It’s not one artifact here and there; it’s about discussions.“ The frequency of those alignment discussions, though, cannot be a one-size-fits-all since the complexity of the project and its associated timing dictates the need for regular interaction.
So at a high-level the project becomes identify risks, design against those, confirm we’re on the page and stay aligned into perpetuity (of the product’s lifetime).
But, as we well know by now, combining peanut butter and chocolate isn’t that easy.
Do you need to improve your automotive product development, to increase efficiency, or to comply with ASPICE and Functional Safety? You are at the right place.CONTACT US