Why third-party suppliers need to be concerned.
Software Defined-Vehicles and their advanced technology are paving the way for the cars of the future. Estimates predict that by 2029 more than 90% of new vehicles will be SDVs. The automotive industry has embraced SDV architecture that delivers powerful tools and benefits for both safety and consumers. But as we’ve learned, these advancements are also exposing vehicles to new and dangerous cybersecurity threats and exploits. Product cybersecurity compliance initiatives such as the ISO/SAE 21434 standard, the UN R155 regulations, and the Chinese GB standard, are laying the foundations to overcome these challenges and are forcing the industry to reevaluate and improve their vehicle cybersecurity posture.
Some of the key challenges that the automotive industry needs to address are the lack of cybersecurity expert personnel, the ever-growing costs to R&D, supply-chain hierarchy revisions, compliance demands for frequent software updates, and continuous cybersecurity throughout the lifecycle.
The initial outcomes of SDV technology can already be observed in third-party supplier’s application designs, in the fact that more open-source software is developed in-house, and in the reductions in EE costs. Thanks to virtualization, separation of hardware from software is now common practice, and ECU consolidation allows significant decentralization of networks from 80-100 ECUs down to 3 main hypervisors that run multiple virtual operating systems. Since the need to secure Virtual Machines (VMs) and containers that share operating systems, high-performance computing and domain controllers have become prevalent. Container runtime systems can add security controls automatically into loaded containers, and suppliers can add built-in security into containers using an SDK.
As cars become service platforms, OEMs and third-party suppliers have started selling on-demand features, applications, and services accompanied by OTA updates for safety-critical and privacy cybersecurity. In-vehicle applications also pose a potential breach port-way. Increased open-source software applications, safety-critical applications, and in-vehicle data applications delivered by third-party suppliers should be cyber-hardened by a combination of mobile and cloud security elements.
Tier-1 Continual Security Verification
As Tier-1 applications gain a larger share of the market, in-vehicle software security risks increase. Each vehicle could potentially contain software from many various suppliers, some too small to maintain a cybersecurity culture.
The ISO/SAE 21434 and UN R155 are raising the bar and demanding to verify suppliers’ security posture and to identify cybersecurity issues in suppliers’ binaries. Safety and privacy are prioritized, by hardening safety-critical applications and protecting customer’s in-vehicle data from leakage. Additionally, as the supply-chain hierarchy shifts from a traditional pyramid model to a collaborative flattened one, manufacturers need to increase their security posture and conduct continuous management.
To meet the regulations, OEMs must adapt their development processes and demand that all software suppliers perform the required evaluations and tests to ensure homologation: CSMS, TARA and Pen-Testing of every delivered product. These requirements entail substantial resources, and demand new measures that can speed up the cybersecurity process.
The industry is eager to welcome a combination of automated platforms that can manage and perform all or most product security functions and produce the required artifacts. The goal is to easily analyze and correlate events and findings during the various product stages, from concept and design to postproduction and decommissioning.
The regulatory requirements are only going to get stricter, as illustrated for example by the Chinese GB standard. In addition to the UN R155 requirements, the GB standard demands that OEMs ensure in-vehicle anti-malware measures, verify application integrity in runtime, and additionally verify third-party application integrity. To avoid SOP delays, cybersecurity compliance must be considered, as part of current planning phases.
To avoid impact on embedded security controls, Karamba’s XGuard, automated host IDPS software, hardens the ECU against malware and in-memory attacks, thanks to binary whitelisting and software control-flow integrity (CFI). It ensures deterministic protection and continuous monitoring of the ECU. A backend engine receives high-fidelity alerts from XGuard agents in the devices, and matches them to automatically created baselines on vehicle and fleet levels. XGuard complements secure boot mechanisms with runtime firmware protection, seamless to R&D (no source code required). It has a negligible performance impact of less the 5% CPU use.
Furthermore, it is recommended to include Karamba’s VCode 3.0 platform in the OEM dev toolchain for third-party developers. This automated platform uncovers security vulnerabilities, misconfigurations, and other security issues in suppliers’ and home-grown binaries. The discovered issues are prioritized, based on the software bill of materials (SBOM), which is automatically generated.
VCode’s Vulnerability Management System (VMS) consolidates vulnerabilities from multiple data sources, such as Auto-ISAC alerts, security attacks, bug bounty, and white hat hackers’ disclosures. VCode VMS prioritizes all issues by blast-radius analysis, severity, and exposure to exploits. It covers AUTOSAR, QNX, Linux, and Android operating systems. VCode 3.0 also performs an automated Threat Analysis and Risk Assessment procedure (TARA), identifying risks in ECU and vehicle type architecture and design. It prioritizes and mitigates according to risk and likelihood of being exploited.
Karamba Security’s End-to-End Portfolio of Products and Services provides a complete cybersecurity journey that complies with regulatory requirements and connects to the CI/CD pipeline, without the need to recompile or change code or delay product release dates.