By Ling Cheng (Senior Product Marketing Manager)
Software containers have revolutionized deployment and integration, significantly accelerating the development of software-defined vehicles (SDVs). They offer a consistent, isolated environment for applications, enabling rapid development, testing, and scaling. With containers, automotive manufacturers (OEMs) and suppliers can streamline updates, enhance security, and ensure reliable software performance across diverse hardware platforms in SDVs.
Indeed, software containers offer many advantages, but their growing use also brings new considerations for security. As the automotive industry increasingly adopts container technology, it’s crucial to recognize the broader implications that arise in the SDV landscape. While containers enhance efficiency and flexibility, they also require attention to potential security concerns specific to this architecture.
Container attack vectors
In addition to the attack vectors encountered in existing architectures, such as unsecure networks, host application vulnerabilities, and host vulnerabilities, container technology also introduces new attack vectors. These include:
- Compromised container images: These are container images — essentially packaged application environments — that have been tampered with or contain malicious code, which could lead to security vulnerabilities when the containers are deployed.
- Container vulnerabilities: These are security weaknesses or flaws within the container runtime or configuration that could be exploited by attackers to gain unauthorized access, escalate privileges, or compromise the system.
- Container escapes: These occur when an attacker gains unauthorized access from within a container to the underlying host system, potentially allowing them to bypass container isolation and exploit the host’s resources or data.
- Poorly configured hosts: Improperly or unsecurely set up host systems could expose vulnerabilities that might be exploited by attackers to compromise the containers running on them or the hosts themselves.
Figure 1. Container attack vectors
If containers are compromised, attackers could gain escalated privileges, which they could leverage to steal personally identifiable information (PII) or even manipulate vehicle functions. As a result, many developers have recognized the importance of properly addressing the security issues of containers themselves. In some designs, additional layers of protection, such as using virtual machines (VMs), are implemented to further enhance isolation between different domains.
However, host vulnerabilities and residual debugging mechanisms can render such protections ineffective, even with the use of containers and VMs to isolate different applications or jobs. For instance, host vulnerabilities identified in a German OEM’s electric cars have demonstrated the feasibility of privilege escalation attacks, allowing manipulation of in-vehicle infotainment (IVI) systems and speed displays.
In a containerized architecture, all applications share the same hardware resources. If applications aren’t well optimized or become the target of an attack, it could end up consuming too many resources. It could lead to performance degradation or denial-of-service (DoS) conditions for critical automotive functions. For instance, it might delay critical decision-making processes in advanced driver assistance systems (ADASs) or even hinder the responsiveness of autonomous driving features.
Readiness for risks in SDVs: Securing containers today
Here are common methods to address container attack vectors:
- Lockdown of overprivileged configuration files: A container configuration file sets the parameters for building and running containers. If not properly defined, it could lead to security risks like overprivileged containers and unsecure networks. Attackers could exploit improperly defined configuration files for malicious activities, including privilege escalation and data theft. Using solutions with “config lockdown” features can help prevent unauthorized access and ensure secure configurations.
- Lockdown of applications to prevent unauthorized or malicious programs: To reduce security risks in containerized environments, approaches such as limiting privileges, ensuring image integrity, isolating networks, controlling resources, and monitoring activities are advised. Using solutions with “container application lockdown” can further prevent unauthorized or malicious program execution.
- Adaptive container escape detection: To counter container escape attempts, continuous monitoring of abnormal behavior is vital. Attackers often display unusual patterns when trying to escape containers. Recommended solutions are those that adapt to and learn from these escape behaviors, extract attack signatures, and apply expert rules to detect and prevent similar threats effectively.
Figure 2. Adaptive container escape behavior extraction and detection
Attack methods evolve constantly. Given that cars last over 10 years, it’s essential to implement comprehensive measures to handle emerging risks. Thus, relevant factors should be considered when selecting security solutions to adopt:
- Actionable threat intelligence: Does the solutions provider continuously monitor deep and dark web threat intelligence and correlate the intelligence with potentially affected vendors and components to provide actionable insights?
- Behavioral analysis capabilities: Does the solutions provider have the capabilities of experienced in-house threat researchers to analyze container application behavior and detect anomalies?
- AI capabilities: Do the solutions have AI features geared toward self-learning and adapting to new attack patterns?
- Software quality and reliability: Do the solutions meet relevant process frameworks (e.g., ASPICE) and undergo thorough testing?
VicOne’s frictionless intrusion detection or prevention system (IDS/IPS), xCarbon, not only provides container security but also supports operations within VM environments, ensuring readiness for risks in SDVs.
This article was updated on Nov. 15, 2024, at 3:00 p.m. UTC, to emphasize the potential impacts of compromised containers or virtual machines.
