IoT Security By Design

After years of anticipation and steady uptake, the Internet of Things (IoT) seems poised to cross over into mainstream business use. The percentage of businesses utilizing IoT technologies has risen from 13% in 2014 to approximately 25% today. Global projections indicate that the number of IoT-connected devices is expected to reach 43 billion by 2030, nearly tripling from the figures in 2018. One notable example of widespread adoption of IoT devices is the automotive industry.

Modern vehicles are becoming increasingly connected and can be viewed as complex electronic devices. An average vehicle design now includes more than 150 electronic control units (ECUs) that manage various functions, including not just infotainment and communications, but also powertrain, safety and driving systems. Supporting these functions leads to a rise in the volume and complexity of these electronics, accompanied by a significant increase in software. This trend is driving the development of the Software-Defined Vehicle (SDV), effectively transforming the modern vehicle into an Internet of Things (IoT) device on wheels.

IoT security

The need for security in these devices is now critical to their success and a required part of the overall IoT infrastructure. The IoT Security Foundation has developed a comprehensive assurance framework that provides clear guidance on the security requirements for IoT, based on the specific application and the overall goal of enhancing security (see Table 1).

Table 1: Cyber Security Assurance table. (IoT Security Foundation)

Automotive IoT security

A defense in depth solution is essential for creating safe and secure integrated circuits (ICs) for automotive applications. At Siemens, the concept of defense in depth is embedded in the core of all the company’s products and solutions (see figure 1). One notable area where this is implemented is within the Tessent product family, which utilizes both secure test technology and embedded analytics monitors. These tools provide hardware-based solutions that address various aspects of the security challenge.

Fig. 1: Siemens’ defense in depth.

As we continue to strive towards autonomy within modern vehicles, we measure progress towards being fully autonomous against the six levels of autonomy defined by the Society of Automotive Engineers (SAE). This definition has been widely adopted across the industry, and emerging vehicle technology is measured against this scale (see figure 2).

Fig. 2: SAE automation levels.

As shown in figure 2, the closer we move towards level 5 and become completely autonomous, the more driving tasks and control we relinquish to the ADAS technology within the vehicle. Thus, we expect these electronic systems to:

1. contain high-quality, defect-free components and remain defect free for many years,
2. be able to operate in a functionally safe manner,
3. operate as per the intended function, and
4. be secure and guard against cybersecurity attacks.

Several standards have emerged in recent years to ensure that all vehicle systems meet at least a minimum level of compliance with various requirements. Figure 3 illustrates the different types of faults addressed by each standard. In the context of the ISO 26262 standard, the focus is on hardware defects that either exist during manufacture or develop during the vehicle’s lifecycle. In contrast, the ISO 21448 standard emphasizes the device’s functionality within the system, ensuring it operates correctly according to its intended purpose. This standard is more concerned with operational accuracy. Then we have ISO 21434, a comprehensive standard that provides guidance on cybersecurity risk management in the automotive industry.

Fig. 3: Automotive standards.

• ISO 26262 – Is an international standard for functional safety in the automotive industry. The standard applies to electrical and electronic systems consisting of hardware and software components in vehicles. ISO 26262 defines requirements to be met by the safety relevant function of the system as well as by processes, methods and tools which are used within the development process. The ISO 26262 standard ensures that sufficient levels of safety are being met and maintained throughout the vehicle lifecycle.
• ISO 21448 – SOTIF (Safety Of The Intended Functionality) standard is designed to be applied to the situational awareness function of ADAS applications taking data flowing in from sensor networks.
• ISO 21434 – Specifies engineering requirements for cybersecurity risk management regarding concept, product development, production, operation, maintenance and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces.

Hardware-based security solutions

As detailed in a Siemens technical paper entitled “High-Quality test and embedded analytic solutions for secure applications,” a wide range of hardware technologies can be deployed to assist in the protection against cybersecurity threats. These technologies are varied but essentially fit a standard set of requirements. Figure 4 shows the basic components of a security by design solution.

Fig. 4: Components of a security by design solution

1. Secure Boot – Hardware monitoring technology can verify that the prescribed boot sequence has executed as expected, ensuring hardware and software function as intended.
2. Attestation – Similar to secure boot, functional monitoring can generate dynamic signatures that represent either a hard or soft configuration of a specific intellectual property (IP) or IC within a system. This process verifies both the accuracy of the expected hardware and its configuration. It can provide either a single identity token or a system-wide collection of tokens. This uniquely generated system signature can be used to ensure that the appropriate software build for an Over-The-Air (OTA) update is applied correctly.
3. Secure Access – As with all systems, it is critical that communication channels in and out of the device are secure and, in many cases, configurable based on different levels of required access.
4. Asset Protection – Active functional monitoring can be a critical part of any defense in depth strategy. Based on a detailed threat analysis selection and placement of functional monitors within the device, functional monitoring provides extremely low latency threat detection and mitigation.
5. Device Lifecycle Management – It is now critical for all automotive ICs to monitor their health throughout their entire lifecycle, from manufacturing to decommissioning. Functional monitoring and sensors play a significant role in this health assessment. In some cases, active feedback can even be utilized to extend the active life of an IC by making dynamic adjustments to external factors when possible.

Cybersecurity and threat modeling

Unlike the functional safety risk landscape, which remains relatively static for a given function, the security threat landscape is highly dynamic. The type and complexity of cybersecurity attacks evolve continuously throughout the entire lifecycle of a vehicle, which can span many years. Furthermore, it’s important to note that in most vehicle development projects, the technology is often several years old when the vehicle reaches the market. Consequently, it is entirely possible for the security features and safeguards integrated into the system’s design to become outdated even before the vehicle goes into production. The security technology must also be extremely dynamic and adaptable to address future threats effectively.

The ISO/SAE 21434 specification Road Vehicle – Cybersecurity Engineering, developed by Praerit Garg and Loren Kohnfelder at Microsoft and published in August 2021, recommends using a methodology such as STRIDE, as shown in figure 5. Several ready-made solutions are available for threat modeling. However, users must invest significant effort in adopting and fully adhering to a specific solution. Some of these options are based on the STRIDE methodology and framework, while others utilize proprietary databases of threats and assets and employ structured (though not standardized) descriptive language formats.

Fig. 5: STRIDE.

The reality is that threat modeling is hard. It can serve as a valuable tool for design, helping teams think more clearly and articulate the types of issues they may encounter. However, threat modeling can become overly abstract without real-world experience regarding how systems are attacked at an engineering level. The teams involved in this process need to understand the threat environment deeply. They must be able to sensibly and objectively assess the risk associated with various scenarios. Mis-scoring a threat or risk can lead to significant consequences: if a threat is scored too high, it can inflate development costs. Conversely, if it is scored too low, it can divert funding and engineering resources away from areas that require more attention. This situation often leads to the familiar dilemma of having an “open kitchen window and a triple-locked front door.”

Other tools for threat modeling can help analyze various aspects of an attack, such as the cost to an attacker of choosing a particular approach. Attack trees are valuable for this purpose, as they can be effectively constructed modularly and combined like a jigsaw puzzle to yield meaningful insights. To create valuable attack trees, it is essential to involve team members who deeply understand the technology involved and how it is being compromised in real-world scenarios.

A crucial aspect of threat modeling is that it should not be static; it must be kept up to date to avoid becoming stale. Every team must start somewhere. The initial time invested in threat modeling will likely yield significant benefits if it is properly maintained and followed by development teams. While it is improbable that a universal threat model will exist across the industry, individual Original Equipment Manufacturers (OEMs) will likely have very similar models, as will their suppliers. Future advancements are expected to increase automation, but this discipline will still require critical thinking.

Summary

As we work towards achieving full Level 5 autonomy, the development and certification processes for automotive systems within the supply chain must evolve. We must adopt the latest tools and technologies to ensure that the systems being developed are safe and secure against current and future cyber threats. Without advanced embedded analytics technology, automotive ICs will remain opaque, making it difficult to assess the overall health of a vehicle’s systems. This lack of transparency can reduce a vehicle’s reliability and increase its vulnerability.

To learn more about Siemens’ Tessent Safety and Security solutions, please see https://www.siemens.com/tessent-safety-security.