ECU Cyber Security: SELinux and Host Protection Power Duo

ECUs are the intelligence hub of a vehicle, responsible for controlling media and entertainment, external communication, and other functions. With the emergence of software-defined vehicles (SDVs), ECUs are now interconnected, communicating with each other and external networks. While this increased connectivity enables enhanced functionality and convenience, it also expands the attack surface with respect to software vulnerabilities and other cyber threats.

ECUs that run on Linux (and some that run on Android) come with a free open source layer of protection known as SELinux (Security-Enhanced Linux). While SELinux is an effective general-purpose tool for software developers, it doesn’t check all the boxes from an automotive cyber security standpoint. Accordingly, many OEMs are deploying intrusion detection and prevention systems (IDPS) to protect their in-vehicle networks and components and to comply with emerging automotive cyber security regulations and standards (e.g., ISO 21434, UNR 155 and Chinese GB/T).

In this post, we’ll review why OEMs and Tier 1 suppliers need more than SELinux to protect connected ECUs from sophisticated cyber threats.

SELinux in Automotive: Strengths and Challenges

SELinux is a Linux kernel security module that provides a mechanism for managing and enforcing access control security policies set by the system administrator for users, programs, and services. As such, applications within any SELinux-enabled environment are protected from attempts to access system resources beyond their designated boundaries. This safeguard ensures the consistent and secure behavior of applications.

SELinux plays a pivotal role in managing and securing automotive ECUs that run on Linux. It offers granular control over system processes, enhancing the security of mission-critical vehicle systems. This functionality is crucial for both OEMs and Tier 1 suppliers looking to protect vehicle ECUs from increasingly sophisticated cyber threats. 

Despite its strengths, the implementation of SELinux in the automotive sector encounters several industry-specific challenges:

• Maximizing security without compromising functionality – When implementing cyber security, there’s a constant need to balance between minimizing the attack surface (i.e., limiting the system) and allowing the capabilities needed for normal system functionality. In other words, you want to harden the system against abnormal behavior, but you also need to keep it open enough to enable routine operations. This requires the flexibility to limit capabilities for one process, while allowing the same capabilities for another. This is difficult to achieve using SELInux.
• The need for real-time response capabilities – Hardening protection layers like SELinux are an excellent starting point, but they are static and not built to respond to rapidly evolving attack techniques. In contrast, an agnostic flexible solution (e.g., combining SELinux with EDR (Endpoint Detection and Response) or Automotive IDPS) can provide comprehensive, in-depth protection in a dynamic manner without requiring constant maintenance.
• Logging of security events – This is a standard feature in SELinux. The hard part is handling the logs once they are created. This includes collecting and storing the events, filtering them and sending them to a backend management system for analysis. This might sound simple from an IT perspective, but the truth is that most OEMs cannot support this functionality today. Moreover, these logging activities are explicitly required for compliance with UNR 155 and GB/T. 
• Open source – Open source software is great for developers, but it can be a double-edged sword from a security standpoint. Since the code is readily available and anyone can see how it’s implemented, persistent hackers can eventually find a way to bypass it. Since SELinux can be used for various purposes and is not required for every application, it is removable by design and could be disabled by sophisticated malware.
• Maintainability – Another drawback of open source is that you need to maintain it over time. Each time you upgrade your own application you need to check its compatibility with SELinux – and vice versa. For example, you need to be aware of bug fixes and upgrades in SELinux, and then adapt and update your code to support those updates. In contrast to proprietary software, open source offers no support and no upgrades. If, for instance, a new requirement is added to a regulation, software vendors serving the automotive industry would address it immediately. Using open source, you would have to rely on internet forums for assistance or use your own resources to meet the requirements. 

One Layer of Security Is Not Enough

By way of analogy, if you’re trying to protect a famous art museum, you’re going to do more than just lock the front gate. You’re probably also going to install cameras, motion sensors and other devices to protect against unauthorized entry. It’s too risky to rely on a single layer of security, because that leaves you with a single point of failure – which is unacceptable for art museums and for automotive.

One of the basic tenets of cyber security is that a single layer of protection is not enough to address all the relevant attack vectors, exploits and scenarios. SELinux, in particular, can be easily bypassed or disabled, as demonstrated many times by our research department. This is another important reason why SELinux shouldn’t be relied upon as a single layer of protection.  

Meeting Automotive Cyber Security Requirements

The need for multiple layers of security is especially true for today’s ECUs, which are comprised of software and other components from multiple vendors. This diverse, tiered ecosystem can create integration issues and unforeseen security vulnerabilities. Accordingly, OEMs require holistic security solutions that provide a comprehensive security picture, rather than specific hardening on a trial and error basis. 

SELinux policies are primarily designed around the standard Linux usage paradigm, which does not always align with automotive-specific needs. It is based often on a trial and error approach and lacks features and shortcuts that are specific to automotive applications, making it difficult to define the scenarios and use cases required to secure a vehicle (e.g., protect kernel parameters).

HostProtection (IDPS): Bridging the Gaps in ECU Cyber Security

Reflecting this multi-layered approach, many OEMs have chosen to deploy Host IDPS Protection solutions as an additional layer of ECU security on top of SELinux. Host Protection is designed to address the unique needs of automotive security, complementing the existing SELinux functionality. Based on simple, easily configurable rules, Host  Protection fills certain security gaps that SELinux might not address or struggle to control, such as strict execution controls. 

Together with SELinux, Host  Protection provides OEMs with a secure, automotive-grade system solution by offering the following additional layers of security:

1. Protection – Host IDPS Protection enhances ECU protection by ensuring the integrity and authenticity of all executables and special files. Each executable running in the system should be identical to the certificate signed by the OEM. If any change or modification to the file is detected, the file is blocked. In addition, Host Protection allows users to create rules that cover multiple automotive specific scenarios and prevent their exploitation.
2. Detection – Going back to our example, the protection layer locks the gate, and the detection layer corresponds to the cameras and sensors around and inside the museum. Host Protection systems typically include bundles of sensors on the ECUs that can sense abnormal behaviors of the system. This also includes a dedicated sensor to monitor SELinux itself to make sure that it has not been removed or tampered with, and monitor system measurements, CPU utilization, etc. to facilitate further investigation.
3. Logging –  This layer consists of collecting and managing all the SELinux logs and all other security events in the system, and sending them as SEvs (Security Events) to the IdsM (Intrusion Detection System Manager) or other configured sink for aggregation and filtering. . These operational functions, mandated by UNR 155 and GB/T, complement the basic logging functionality in SELinux.

As mentioned earlier, each of these layers is essential for OEMs looking to protect their vehicles and ECUs from cyber attacks, as well as facilitating compliance with cyber security requirements for type approval.

Bottom Line

While SELinux provides excellent value for developers, there is still a need to complement SELinux with additional layers of automotive-grade security in order to protect Linux-based ECUs and meet regulatory requirements.

The combination of SELinux and Host IDPS Protection represents a powerful synergy in automotive cyber security. SELinux provides a robust foundation, while Host Protection offers the agility and specificity required to address the unique challenges of the automotive industry. This dual approach ensures that vehicles are not only equipped to handle current cyber security threats but are also prepared for the evolving challenges of the future.