European OEMs and TIERSX are subject of compliance with the ISO21434:2021 and ISO24089:2023 (only in the case of OEMs), in particular if the target market is any of the 68 countries of the UNECE Agreement of 1958. Considering the implications of implementing the requirements of the ISO 1434, we will see that in case of mature organizations it may not be that challenging of implementation if a pragmatic approach is considered.
The ISO21434 standard
The ISO21434 is the international standard from ISO for designing secure products, handling the cybersecurity related risks and performing threat monitoring activities when the product is on active operation. ISO24089 deals with the software update process, which links not only product cybersecurity, but also IT security (usually covered by an ISMS as per ISO27001 or TISAX), and ISO26262:2018 – functional safety (functional safety risks derived of the update of the modules software shall be considered).
Why automotive cybersecurity is now regulated?
In practice, cybersecurity related initiatives for the automotive domain have been around since at least the EVITA project, which was kicked off back in 2008. It all exploded in 2015, with the publication in media of the results of a multiple years of research project led by Charlie Miller and Chris Valasek, who conducted several vulnerability assessments on the most popular US vehicles, and discovered and exploited a replicable security vulnerability on a 2015 Jeep Cherokee fully remote – this was indeed the critical factor.
If left unchecked, the vulnerability would allow any would-be attacker to remotely access any one of the 1.4 million affected vehicles and gain physical control, including steering and braking. Since then, and considering that nearly every newly sold vehicle has some level of connectivity, allowing remote connections, the implications on public road users safety is notoriously concerned. UNR 155 forced all newly vehicles beyond July 2024 to consider cybersecurity from design, and not just as an add-on, requesting OEMs on performing monitoring (usually through VSOCs) of the field fleet and distributing patches if critical vulnerabilities were found.
Standards, methods and practices
The ISO21434 is just a set of state-of-the-art “whats” on how to design (development, integration, testing) secure products. It does not provide – except examples and notes – prescriptive description on the how.
The automotive community then took a look on what was being learnt and applied on IT environments since the 60’s. Methods and processes were to some extent relatively easy to extrapolate, while a complete set of new tools were required. Some others were just adapted to the particularities of embedded development – example, while OWASP is mainly targeting web-based applications, CERT-C is recommended for embedded systems secure coding, alongside MISRA. Testing methods were also relatively easy to convert into automotive needs, while still there is a hype on the real needs from a TIER1 and OEM perspective.
Secure Software Development Lifecycle (SSDLC)
A SSDLC – Secure Software Development Lifecycle is recommended for automotive secure applications. In essence it is a SEC-DEVOPS – a collaborative approach that integrates security practices into the software development and delivery lifecycle.
The keyword here is integrated – the more you don’t diverge, the better. If your organization has a seamless, and integrated product development process for safety and cybersecurity relevant, you will find the synergies (and in some cases the overlappings).
Compliance challenges
As a customer, if we ask our supplier ASPICE, ISO26262, and ISO21434 compliance, it would probably be a mess on the final result. But it shouldn’t be the case, as safety has been around since almost 15 years (from the very first publication of ISO26262 in 2011), cybersecurity (if well understood) since 4 years and ASPICE, with all its iterations and extensions, since many years.
So all these have been around for a while, then, why is hard to get all of them properly implemented at organizations and most importantly, at product level? Usually because it is overestimated – and particularly, cybersecurity.
Cybersecurity in practice
What cybersecurity tells you to do is just identify the potential product cybersecurity risks, due to threats, weaknesses or vulnerabilities, define risk mitigations measures which are not contradicting functional safety goals (also known as CS goals linked to one or more CS control), refine the needed technical specification, and get it implemented.
Once, test it – several methods can be applied, the most suitable one needs to be agreed with your customer – and that’s it. Once you’re done, maintain a small team (few hours or big teams, depending on your size) to monitor (this can be as simple as receiving emails from your SW or HW suppliers and manage them) potential threats, and in case a vulnerability with high scoring (there is a discussion on whether CVSS is good enough to determine whether high scoring CVSS shall be solved …) analyze it and if possible deliver a software solution.
Why if it seems so simple, in some cases it becomes a hurdle? Usually the problem comes from how the organization is indeed designed – usually the safety folks don’t talk to the security team, and nobody talks with the software team.
Our recommendation
Our recommendation: cybersecurity is not a one-man-one-day stuff, it is a journey which needs to be planned (the same as when you go in summer with your family on vacations), staffed, and progressively achieved. In the meantime, be open and transparent, handle the organizational risks on not being yet prepared and agree short or mid-term solutions, which helps you to drive in the same direction – maturity increment.
This is not solved with expensive tools or complex processes and methods which claim to be all-in-one packaged solution. This will just not work.
Conclusion
A risk driven approach shall be taken when deploying cybersecurity at organizational level. It helps you to handle everything that you don’t have yet, and drives you to where you would like to be in a 5-years improvement plan. Don’t get it wrong, the target is not to have the CSMS – Cybersecurity Management System that your customer is asking, the objective is to design a safe and secure product – and it takes time.
Plan it, define the targets, and more important, people leading the plan shall be skilled enough to determine what’s needed and what’s not – be pragmatic, be Kentian.
