SEOUL, KOREA, July 6, 2023 — Automotive cybersecurity and mobility solutions provider AUTOCRYPT announced its new “AutoCrypt Security Fuzzer for HIL” solution, jointly developed by AUTOCRYPT and RWTH Aachen University as part of their industry-academia partnership. As an add-on version of the existing AutoCrypt Security Fuzzer, the new tool enables fuzz testing in the HIL simulation environment.
Hardware-in-the-loop (HIL) simulation is a testing platform created by generating a virtual simulation of the in-vehicle architecture so that all systems and operations can be pre-validated before producing and conducting tests on the physical vehicle. Given that a modern vehicle contains over 1,000 semiconductors, being able to pre-validate the systems through a virtual simulation greatly reduces the complexity and costs of early-stage testing.
AutoCrypt Security Fuzzer for HIL is a fuzz testing solution optimized for vehicle HIL simulations, fuzzing against the virtual operations of the vehicle systems and ECUs to detect and report vulnerabilities. As the world’s first fuzzing solution for vehicle HIL simulations, it complies with vehicular cybersecurity standards ISO 21434 and UN R155, and functional safety standard ISO 26262 regarding electrical current stability.
AUTOCRYPT’s CEO, Daniel ES Kim noted that “existing HIL tests mainly verify system integrity in certain specific scenarios, but AutoCrypt Security Fuzzer for HIL detects unprecedented vulnerabilities by exploring unexpected system abuse cases.” Regarding the partnership, he added, “We are excited to partner with one of the leading European universities. With contributions by RWTH Aachen University, we are now at the automation and advancement stages of the development process.”
Along with fuzz testing, AUTOCRYPT provides a full range of vulnerability testing tools and security validation services dedicated to different stages of the automotive manufacturing process, helping OEMs exceed cybersecurity regulatory requirements and save on production costs.
For more information with regard to AutoCrypt Security Fuzzer for HIL, contact global@autocrypt.io.
SEOUL, KOREA, February 2, 2023 — A global leader in automotive cybersecurity and connected mobility technologies, AUTOCRYPT announced its certification for ASPICE Capability Level (CL) 2. One of the very first and few cybersecurity providers to achieve this certification, AUTOCRYPT was recognized for its well-established processes in securing in-vehicle systems and software.
ASPICE, or Automotive Software Process Improvement Capability Determination, is an assessment scale used to evaluate an automotive supplier’s software development and management procedures. It is a de facto standard for continuous improvements in the software supply chain, confirming all components are planned, performed, and managed systematically.
AUTOCRYPT obtained ASPICE CL2 certification for its AutoCrypt IVS-TEE software security platform, a trusted execution environment (TEE) built into application processors. Since the TEE is separated from regular operating systems, it allows applications to run in an isolated and secure environment. As one of the first to integrate TEE into the automotive ecosystem, AUTOCRYPT expects to further strengthen its international partnership network for in-vehicle software security.
“Automotive architecture is transforming rapidly. More and more application processors are built into vehicles to run advanced applications like ADAS, infotainment, and the central communication unit. This makes software security a key determinant of vehicle quality, reliability, and safety,” said Daniel ES Kim, CEO of AUTOCRYPT. “We look forward to integrating cutting-edge security technologies into the automotive supply chain to ensure a reliable and flawless software-defined experience.”
Beyond its usage in securing in-vehicle systems, AutoCrypt IVS-TEE will soon be integrated into security-critical services such as OTA, digital key, and smart EV charging. The solution is now available worldwide for OEMs and tier suppliers.
For more information regarding AUTOCRYPT’s in-vehicle systems security solutions and offerings, contact global@autocrypt.io.
As more and more software components and connected technologies make their way into vehicles, cybersecurity has rapidly become a crucial aspect of vehicle design, manufacturing, and maintenance. However, in the century-old automotive industry, cybersecurity can be an unfamiliar field of expertise. Many automotive OEMs have found it challenging to implement security by design and integrate vehicle cybersecurity into functional safety.
To promote standardized practices in vehicle cybersecurity, the National Highway Traffic Safety Administration (NHTSA) – the United States’ federal agency dedicated to transport safety – drafted a guideline in 2016 on Cybersecurity Best Practices for the Safety of Modern Vehicles. The guideline helps automotive OEMs and suppliers establish a set of procedures to minimize cybersecurity risks and effectively manage threats throughout the vehicle lifecycle.
NHTSA’s guideline is centered around the voluntary standard of ISO/SAE 21434: “Road Vehicles – Cybersecurity Engineering”, a vehicle cybersecurity standard co-published by the International Organization for Standardization (ISO) and the Society of Automotive Engineers (SAE). Although compliance with the standard isn’t enforced by law like the United Nation’s R155 and R156 set out by UNECE WP.29, most automotive OEMs across the globe refer to ISO/SAE 21434 as a guide to establishing a secure procedure for vehicle manufacturing and post-production management.
In September 2022, NHTSA published the finalized version of the Cybersecurity Best Practices guideline, five years after the initial draft was released in 2016. The updated guideline contains more detailed descriptions of implementing appropriate cybersecurity procedures with respect to an OEM’s corporate process, as well as modifications based on the feedback and comments provided by industry experts.
Most importantly, the finalized Cybersecurity Best Practices contains updates to reflect the finalized version of ISO/SAE 21434, which was still under development when the 2016 draft was released.
A Summary of Key Practices Outlined by NHTSA
NHTSA’s Cybersecurity Best Practices contains a comprehensive corporate guide from as broad as leadership priorities and employee education to as specific as technical manuals on cryptographic techniques and credentials. In this blog, we extract some of the key practices relating to the establishment of vehicle cybersecurity by design, along with some of AUTOCRYPT’s tips that can help save corporate resources during the implementation process.
The Importance of Security by Design
Speaking of cybersecurity, most people tend to think about cybersecurity systems and tools like firewalls and threat detection software. However, the scope of cybersecurity in the IoT age stretches beyond these traditional definitions. For the automotive industry in particular, cybersecurity isn’t simply about threat detection and response, but covers an end-to-end process that begins from a vehicle’s development stage all the way to its everyday usage in the consumer’s hand. Therefore, a vehicle must be designed and developed with security in mind, and an OEM must continuously monitor and manage threats throughout the entire lifecycle of the vehicle.
Below is a summary of NHTSA’s suggested practices for achieving cybersecurity by design.
1. Risk Assessment and Removal
To incorporate vehicle cybersecurity by design, risk assessment must be performed at an early stage of a vehicle’s development process. This is done by evaluating a vehicle’s potential entry points from a threat actor’s perspective, predicting their motives and intrusion methods, then listing out the risks the vehicle faces. Of course, it can be difficult to pinpoint all prospective risks at an early stage. Hence this assessment should primarily focus on identifying risks that could potentially threaten the safety of passengers and other road users.
Our Tip: Cybersecurity risk assessment should be conducted by a team of security experts that specialize in automotive systems and architecture. To fill this gap, AUTOCRYPT provides Threat Assessment and Remediation Analysis (TARA) to automotive OEMs, generating an accurate assessment of the potential risks of a vehicle model. A professionally conducted TARA enables an OEM to make early adjustments to its system design and architecture to remove safety-critical risks, creating a solid foundation to build upon.
2. Security Testing and Vulnerability Identification
At the next stage, NHTSA recommends a full evaluation of both commercial off-the-shelf (COTS) and open-source software components used in embedded vehicle systems such as ECUs. This allows the OEM to identify all known vulnerabilities in their software. After known vulnerabilities are removed and patched, fuzzing and penetration testing should be conducted to further eliminate any zero-day vulnerabilities and software development flaws. To enable security by design, automotive OEMs need to ensure that their vehicles are vulnerability-free before moving into mass production.
Our Tip: AUTOCRYPT offers a range of advanced cybersecurity testing tools and solutions for manufacturers to identify flaws and vulnerabilities within their systems. Starting from AutoCrypt® Security Analyzer, which utilizes an SBOM (Software Bill of Materials) approach to scan the source code and break down the components of open-source software by different units of analysis, enabling accurate patching with minimal modifications required. This is followed by AutoCrypt® Security Fuzzer, which feeds the tested system with randomly generated, invalid, and unexpected inputs in an attempt to trigger errors and expose its vulnerabilities. Lastly, AUTOCRYPT’s security validation experts conduct penetration testing on the targeted program to eliminate any remaining flaws and vulnerabilities.
3. Monitoring, Containment, Remediation
After all the preventative measures are implemented, an OEM needs to integrate a set of security monitoring and management systems into the vehicle architecture. The NHTSA emphasizes that automotive OEMs must maintain their capability to monitor, contain, and respond to any attacks against their vehicle fleet after they are sold to consumers, with rapid incident detection and remediation capabilities being of paramount importance. This means that when a cyberattack occurs, the OEM must be able to detect it in real-time and prevent it from causing any safety-related impacts to its vehicle fleet.
Our Tip: An effective intrusion detection and prevention system (IDPS) should be equipped on every vehicle to defend it from all types of intrusions and internal threats. AutoCrypt® IVS is an advanced firewall for in-vehicle systems, capable of detecting any signs of intrusion and contain them from spreading inside the vehicle. To make things more visible for the OEM, all this fleet information can be visually monitored and managed on AUTOCRYPT’s Vehicle Security Operations Center (vSOC).
The Growing Importance of Vehicle Cybersecurity
Legally speaking, even though NHTSA’s Cybersecurity Best Practices and the ISO/SAE 21434 standard are not enforced as of today, they are extremely helpful to OEMs that want to succeed in the market of software-defined vehicles. Putting legalities aside, since many embedded systems inside a vehicle are directly related to its physical functionality, vehicle cybersecurity and functional safety are no longer separable, with cybersecurity becoming a crucial evaluation criterion for quality. Therefore, whether it is for regulatory compliance or quality assurance, OEMs and software providers must work together with cybersecurity providers to implement security by design and pave a safe future for every road user.
To learn more about AUTOCRYPT’s in-vehicle systems (IVS) security solutions and offerings, contact global@autocrypt.io.
To stay informed and updated on the latest news about AUTOCRYPT and mobility tech, subscribe to AUTOCRYPT’s quarterly newsletter.
The automotive industry is evolving at an incredible pace, characterized by changes in vehicle architecture, automotive software, and user experience. No longer are automobiles a mere transportation tool, but consumers are now expecting their car to function as their smart mobile device on the road, capable of not just (autonomous) driving, but also personal computing tasks from music and video streaming to in-car payment and cloud-based functionalities. Today, drivers and passengers want their interactions with the car to be personalized, synchronized, and most importantly, effortless.
A smart mobile device relies heavily on software applications. Just like smartphones and tablets, the modern vehicle operates on hundreds of software applications with millions of lines of source code, powered by up to a hundred application processors in the forms of MCUs (microcontrollers) and ECUs (electronic control units)—and in some cases, a couple of centralized CPUs. Whereas conventional vehicles are largely evaluated by their hardware, software is playing an increasingly important role in defining today’s vehicles. We are in an age where two vehicles with the exact same engine and technical specs can drive and feel entirely different depending on the underlying software.
The Role of Automotive Software
In a modern vehicle, a surprising number of features that consumers take for granted are enabled by software. To consumers, the most familiar type of automotive software is the user applications installed in the head unit (i.e., dashboard and infotainment system), which make up the human-machine interface (HMI). Yet, beneath the surface, there are hundreds of software applications embedded throughout the in-vehicle system, underpinning the smart features that are seamlessly integrated into the driving experience. For instance, software is embedded in every camera to process the captured imagery and transmit the visual information to the computing unit, enabling advanced driver-assistance systems (ADAS).
Looking deeper within the vehicle, all ECUs contain pieces of embedded software that act as communication modules, allowing them to communicate with one another throughout the CAN buses, the head unit, the telematics control unit (TCU), and externally to the telecommunications network and the clouds. These communication interfaces lay the groundwork for V2X (vehicle-to-everything) communications and vehicle-infrastructure cooperated autonomous driving (VICAD). Lastly, information collected from the in-vehicle system is likely recorded and transmitted to the OEM cloud, allowing for the vehicle security operations center (vSOC) to detect anomalies and respond to any potential cybersecurity threats. All these software-enabled features run seamlessly without the need for any manual intervention.
Who Develops Automotive Software?
Unlike hardware parts, most of the software components used in automobiles are not directly developed by OEMs or Tier 1 suppliers. Instead, they come from a diverse range of software vendors and providers, including HMI providers, middleware providers, operation systems providers, telematics providers, ADAS software providers, telecommunications providers, cloud providers, security providers, and many more. Some of these software components are installed directly on top of the infotainment system, while others are embedded within the wide array of in-vehicle systems prior to the assembly phase. Oftentimes, software vendors need to work with hardware suppliers and chipmakers during the production process to ensure cross-industry interoperability. As software becomes an integral part of production, the automotive supply chain is looking less like a vertical deliver-and-assemble process but more like a horizontal network of partnerships and co-developments.
The Components of Automotive Software
A vehicle’s software environment is much more complex than that of other computing devices like smartphones and PCs. Smartphones and PCs operate on a single OS, where all software applications are developed for the specific platform. In the vehicular software environment, however, vehicles do not run on a single OS nor a proprietary platform (even though OEMs are moving in that direction—topic for another time). This means that every software component is essentially independent, only to be stitched together by the rules set out by standardized communication protocols and interfaces.
Since automotive software components are developed by individual parties, a large portion of them contain open-source code and licenses. This isn’t surprising given that more than 70% of all the world’s software source code is open source—the most popular mobile OS Android was built on the grounds of the open-source Linux kernel, while over two-thirds of all web servers in the world run on the open-source Unix OS and its variants. Of course, these popular open-source distributions are often developed and managed by large corporations, ensuring that vulnerabilities are monitored, detected, and patched immediately. But this isn’t the case for automotive software, which comes from hundreds of vendors and developers across the world. Since open-source code is widely copied and modified during the development of applications, even developers can lose track of which components or licenses were used, or whether one component could form codependency with another. This makes it much more challenging to manage software updates and ensure that patches get to the right vehicles on time.
Fortunately, there is a promising solution that makes it easy for automotive OEMs to continuously manage their in-vehicle software throughout all stages of the software development lifecycle (SDLC)—the software bill of materials.
Securely Manage Automotive Software With the Software Bill of Materials (SBOM)
To counter the security risks that arise alongside the growing popularity of open-source software (OSS), the software bill of materials (SBOM) has become a popular tool to manage OSS vulnerabilities across many industries. An SBOM, as its name suggests, is a machine-derived list that contains a detailed breakdown of all open-source ingredients—including code and licenses—found within a piece of software. In 2021, a US Executive Order on enhancing OSS security made SBOM mandatory for certain sensitive industries. A detailed guideline was later published by the National Telecommunications and Information Administration (NTIA) of the US Department of Commerce.
Like many other industries, the SBOM is the most effective way for OEMs to manage automotive software. Not only does it help establish a vulnerability-free software environment in the first place, but it also allows OEMs to keep track of vulnerabilities in their OSS and licenses during the aftermarket stage and have them patched via OTA (over-the-air) updates to all impacted vehicles.
AUTOCRYPT’s newly launched AutoCrypt® Security Analyzer (SA) is an SBOM-based software analysis and management tool that accurately detects and categorizes software components, enabling OEMs to continuously manage their automotive software during all stages of the vehicle’s lifecycle.
To learn more about AutoCrypt® Security Analyzer and AUTOCRYPT’s mobility service solutions, contact global@autocrypt.io.
To stay informed and updated on the latest news about AUTOCRYPT and mobility tech, subscribe to AUTOCRYPT’s quarterly newsletter.
Vehicular cybersecurity is now an inseparable component of automobiles. To establish an ecosystem where vehicles can safely connect with the outside world, UNECE’s WP.29 regulations on vehicular cybersecurity require automakers (OEMs) to manage cybersecurity risks at every stage of a vehicle’s lifecycle. This includes 1) pre-production design and development stage, where cybersecurity gets embedded into the supply chain; 2) production stage, where hardware and software components are integrated and tested for interoperability; and 3) post-production stage, where continuous monitoring and timely updates are required to keep the vehicle protected throughout its lifespan.
As a cybersecurity adviser on the International Transport Forum’s Corporate Partnership Board (CPB), AUTOCRYPT has been contributing its expertise in vehicular cybersecurity standardization and policymaking, making the company a specialist in cybersecurity integration and regulatory compliance. Developed to help OEMs integrate cybersecurity with functional safety, AUTOCRYPT’s in-vehicle security solution, AutoCrypt IVS, provides a robust end-to-end security package for all three stages of vehicle production, stretching beyond regulatory requirements.
In this article, we break down AUTOCRYPT’s in-vehicle security process to look at how a vehicle is secured at each stage.
1. Threat Assessment and Remediation Analysis (TARA)
The biggest difference between vehicular cybersecurity and IT cybersecurity is that a vehicle does not run on a host computer, nor a unified operating system. Instead, each vehicle has a unique electronic and electric (E/E) architecture made up of over a hundred electronic control units (ECU), interoperating through the Controller Area Network (CAN bus). This means that there cannot be an off-the-shelf cybersecurity software or tool that is readily installable across all vehicles; instead, in-vehicle security needs to be custom-designed for each vehicle model.
To develop a system and process for a particular vehicle, it is crucial to start by assessing the threats associated with the specific OEM and vehicle model through an engineering methodology called Threat Assessment and Remediation Analysis (TARA). TARA is widely used for the initial assessment of cybersecurity risks, based on a deep analysis of the vehicle’s architecture, followed by a prediction of potential vulnerabilities and entry points. After identifying the risks, security engineers will thoroughly select a pool of necessary countermeasures that can mitigate these specific risks.
During TARA, AUTOCRYPT begins by identifying critical assets within the target vehicle, then compiles a list of attack vectors that hackers could potentially use to access and intrude the system. After that, the level of risk and feasibility of each attack vector is analyzed, before arriving at a final list of threat priorities. These priorities are used to design and develop a security model, where detection engines and software modules get embedded in different parts of the vehicle.
2. Threat Modeling and Security Testing
After initial design and development of the in-vehicle security system, it is then time to conduct a series of tests by simulating real-life hacking scenarios to verify the efficacy of the security model. In this stage, three types of security testing are implemented: vulnerability scanning, fuzz testing, and penetration testing.
Vulnerability Scanning
Unlike threat assessment in TARA, vulnerability scanning requires the physical vehicle prototype with the adopted security model. Both software static testing and dynamic testing are performed. The former checks for errors in the development stage, including leaks and buffer overflows, whereas the latter executes the code to test for vulnerabilities in runtime environments by analyzing the behaviours of dynamic variables.
Fuzz Testing
Fuzz testing, or fuzzing, is a type of automated software testing technique that feeds a large pool of randomly generated invalid and unexpected inputs into the program as an attempt to make it crash or break it through. If a vulnerability a found, a fuzzer can be used to pinpoint the potential causes. Fuzzing is a quick and useful way to identify unexpected coding errors, highly effective at mitigating most automated hacking techniques.
Penetration Testing
Penetration testing is the most advanced and sophisticated test of the three. It requires security analysts and red team hackers to manually search and exploit vulnerabilities using complex hacking techniques such as password cracking and injection, then try to manipulate and exfiltrate data from the vehicle. AUTOCRYPT’s red team, led by experienced resident white hat hacker Dr. Jonghyuk Song, performs penetration testing to vehicle components and security software prior to final implementation, ensuring that no vehicle leaves the factory in a vulnerable state.
After completion of threat modeling and security testing, all errors and vulnerabilities will be corrected and reviewed. Finally, the vehicle will be ready to enter the market.
Figure 1. Three Stages of In-Vehicle Security
3. Threat Mitigation
As the vehicle gets passed down to the consumer, the role of cybersecurity does not end here. In fact, this is only the beginning of a long journey of continuous monitoring, prevention, and incident response. At this stage, the security engineering of AutoCrypt IVS works at its best to protect the ECUs by running both an intrusion detection system (IDS) and intrusion protection system (IPS) to block hacking attempts, encrypting all messages to prevent data tampering, and controlling access to all storages to ensure privacy and financial safety. It also monitors the central gateway for any abnormal behaviour throughout the vehicle’s CAN bus and between the vehicle to the external network. Such data is then collected in real-time by the OEM and reported to AutoCrypt vSOC (Vehicle Security Operations Center) for analysis.
Vehicle Security Operations Center
Similar to the SOC in IT security, vSOC brings enterprise threat intelligence to the mobility environment by monitoring the activities and conditions of all active vehicles using live data collected and shared from the OEM’s cloud. AutoCrypt vSOC provides an easy-to-navigate graphical user interface, allowing the OEM to track and analyze threats by region and prioritize updates and patches.
Figure 2. AutoCrypt vSOC GUI for an OEM customer
Vehicular Cybersecurity Made Easy With AUTOCRYPT
Most OEMs do not have the time and capacity to assess, deploy, and manage all three stages of vehicular cybersecurity in-house. Over the past decade, AUTOCRYPT has been filling this gap not only by offering AutoCrypt IVS as a product, but also by designing and developing a complete in-vehicle security solution that OEMs can rely on in the long-run.
To learn more about AUTOCRYPT’s end-to-end solutions, contact global@autocrypt.io.
To stay informed with the latest news on mobility tech and automotive cybersecurity, subscribeto AUTOCRYPT’s monthly newsletter.
Cybersecurity is one of the most complex and dynamic fields in the data-driven world, involving a constant battle between hackers and defenders. As internet connectivity reaches every corner of our lives, cybersecurity is now an essential component for automobiles. Yet, many are surprised to find out that cybersecurity in the automotive industry is entirely different from what we are used to encountering in the IT industry, and this means that there are challenges in terms of preparation and prevention. This article takes a closer look at how automotive cybersecurity differs from traditional IT security, with cybersecurity challenges unforeseen in the automotive industry.
1. Massive Scale and Density
As vehicles become increasingly digitalized and connected, many like to draw comparisons between cars and computers, referring to automobiles as “computers on wheels”. However, comparing a car to a computer is not quite fair because a car is, in fact, made up of hundreds of individual computers, which by industry terms are called electronic control units (ECU). The scale of the IT infrastructure in a vehicle resembles that of a small enterprise network, with all the computers, servers, and networking devices densely packed into this metal box. Now imagine having to manage cybersecurity risks for tens of millions of these densely packed “enterprise networks”; a single world-class OEM has between 20 to 100 million active vehicles on the road, a scale never seen in a single corporate IT environment.
Despite this seemingly impossible task, OEMs make cybersecurity scalable by incorporating it into the design and manufacturing stage. Since all vehicles of the same model contain an entirely identical IT infrastructure, they are able to pre-establish cybersecurity measures and embed them into the vehicle parts during the manufacturing stage. This brings us to the next point: type approval.
2. Regulations Requiring Cybersecurity Type Approval
In the IT industry, computer and device manufacturers are not directly responsible for the cybersecurity of their products. It is up to the users, mostly enterprises, to implement cybersecurity tools to protect their network and data. As a result, IT cybersecurity regulations tend to be enforced on enterprise users, not manufacturers. For instance, data privacy laws such as the General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) mandate enterprises to have reasonable security measures to protect the customer data they possess. It is only recently that governments have started to require more transparent reporting from hardware manufacturers due to the latest surge of supply chain attacks.
In contrast, in the automotive industry, since cybersecurity must be deployed during the manufacturing stage, OEMs are directly held accountable for failures in cybersecurity implementation. UNECE’s WP.29 working party was the first to establish a set of regulations that require vehicular cybersecurity type approval, meaning that all vehicles must be assessed and qualified prior to being put on sale. The following diagram illustrates a stage-by-stage comparison of when cybersecurity is implemented between the automotive and the IT industry.
Cybersecurity Implementation: Automotive Industry vs. IT Industry
3. System Complexity
Besides having greater scale and density, the internal system of a vehicle—referred to as the E/E (electrical and electronic) architecture—is much more complex than that of a computer. With more than 30,000 hardware components moderated by over 100 ECUs, a single vehicle operates on over 100 million lines of code. What makes things more complex is that the in-vehicle system is largely distributed without a universal operating system; as each ECU serves a unique purpose, every one of them is crucial to a car’s functionality. For instance, some ECUs are paired with sensors and actuators. Some are paired with the powertrain. The ECU that provides wireless connectivity is called the telematics control unit (TCU)—or on-board unit (OBU)—overseeing communications between the vehicle and the outside world.
Given that the ECUs are highly sophisticated minicomputers, they are often manufactured by different third-party suppliers that specialize in their own field of expertise. This means that to implement cybersecurity throughout the vehicle, OEMs need to work with both cybersecurity providers and ECU manufacturers to ensure that all needs are aligned and all components interoperable. An example of such multi-party collaboration is demonstrated when AUTOCRYPT partnered with ECU manufacturer NXP Semiconductors to embed its AutoCrypt V2X software development kit (SDK) into NXP’s OBUs. The secured chipsets are then able to be delivered to OEMs for assembly.
As vehicles become more and more sophisticated, the industry is now looking for ways to group the ECUs by their domains of service and slowly work towards a more centralized vehicle system that is easier to assemble and manage, transforming the multi-tier supply chain into a more horizontal supply line.
4. Long Lifespan
Having covered the differences in the manufacturing process, it is now time to look at how car consumers differ from electronics consumers. With increasingly efficient engines, advanced mechanics, and precise quality control systems, vehicles now last longer than ever. As a result, more and more consumers are keeping their cars for longer, with the average age of vehicles on US roads reaching a record 12.1 years in 2020. This is three times the average age of computers in the US.
This might be good news to the consumers. Yet, long-lasting cars pose a new challenge to OEMs as they need to spend more effort into managing software updates for each car model to ensure that they are free of security vulnerabilities. More active vehicles on the road also put more strain on the Vehicle Security Operation Center (vSOC), which needs to constantly monitor all vehicle systems in real-time.
5. Scattered Locations
Speaking of vehicle monitoring, we need to talk about the unique challenges that the vSOC faces as compared to the SOC of an enterprise network. The computers and servers in a company do not move, hence it is easy for the cybersecurity team to monitor suspicious activities at all times and respond to threats immediately. On the other hand, vehicles move around constantly across cities and even countries. Oftentimes, they will enter zones without internet connectivity, making it difficult for the vSOC to detect and respond to threats due to delays in data transfer.
6. Damage Severity and Recovery
Lastly, in case a cyberattack happens, an enterprise will most likely lose sensitive data and experience operation disruptions. However, a successful cyberattack against a vehicle system not only puts data at risk, but the personal safety of the passengers and all those others on the road. Patching vulnerabilities is also more complex in the automotive industry because the OEM needs to work with different Tier 1 suppliers and cybersecurity providers to ensure smooth updates.
How AUTOCRYPT Overcomes Automotive Cybersecurity Challenges
What sets AUTOCRYPT apart from other automotive cybersecurity providers is its capability to offer a complete set of end-to-end solutions that help OEMs overcome all aspects of cybersecurity challenges throughout the vehicle. From securing in-vehicle systems and V2X communications, to EV charging and fleet management, AUTOCRYPT eliminates the complexity of searching for a different provider for each problem, making it a completely personalized experience for each client.
To learn more about AUTOCRYPT’s end-to-end solutions, contact global@autocrypt.io.
To stay informed with the latest news on mobility tech and automotive cybersecurity, subscribe to AUTOCRYPT’s monthly newsletter.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!
