A state of mind to keep during the whole lifecycle of your product
The “security by design” approach requires you to take a step back and analyze the possible sources of attacks and vulnerabilities. These can emerge at each phase of your product lifecycle: for example, if you choose some specific hardware, library, or language (design), decide to use dynamic allocation for some buffer (development), overlook limit testing (validation), or fail to see that some component has a new vulnerability (maintenance).
But the rationale for building secure by design Linux systems is that if you do your risk assessment at the end of the development, for instance, then chances are that you will reconsider several choices made earlier, and that the cost of taking this into account is prohibitive. During testing you may also overlook limit cases, which may provide groups for unexpected behaviors that may be exploited by an attacker later.
To mitigate all these threats and avoid additional costs, it’s essential to consider all the risks during the design phase.
Note that the state of the art of attacks is always evolving: a product that is secure at some point may be vulnerable six months later because of a novel attack.
The security of a product is typically enforced by a combination of security mechanisms implemented in the product (e.g., velocity checks on a login or password authentication) and assumptions made about its operational environment (e.g., a robust password policy). The latter relies on proper enforcement of various security policies when the product is on the field.
Preparing for secure developments with a preliminary risk analysis
Before diving into product development, a preliminary analysis is crucial to:
– Prioritize Threats: It’s not possible to address every potential threat (or you’ll spend an enormous amount of time and budget doing so). Risk analysis helps in choosing battles wisely.
– Study Attack Paths: Evaluating all potential attack paths helps identify the right security countermeasures. Keep in mind that every countermeasure will impact both your development and operations phases.
Implementing security measures on embedded Linux systems
Keep your Linux distribution minimalist
When working with embedded Linux systems, minimizing the number of system components is key. Fewer components mean reduced attack surfaces and lower maintenance efforts. That’s why creating a tailored Linux image that meets specific security requirements is a valuable asset.
Solutions like Yocto Project and Buildroot help you create minimalist, custom Linux distributions. While these systems are not straightforward to implement, they offer substantial advantages in terms of cybersecurity, optimization, and maintenance.
The Yocto Project helps create custom embedded Linux distros. We firmly believe that it remains the optimal choice for OEMs’ embedded Linux developments, as it offers unparalleled advantages in terms of configuration, optimization, cybersecurity, documentation, and community support.
Secure Boot: ensuring software integrity
Ensuring that only your software runs on your system is critical. That’s why you should implement a secure boot system.
Secure boot relies on authentication chains starting from the hardware level (with the bootloader), passing by the operating system level, and ending at the application level.
Figure on secure boot authentication chains to build secure by design Linux-based products.
Provisioning
Another best practice is to secure your communications with external systems using provisioning. Such authentication mechanisms underpin a lot of security approaches, such as allowing IoT devices to identify themselves robustly to a cloud platform. In this scenario, the authentication would rely on device-level asymmetric key pairs, with a private key residing securely within the device and a corresponding public key available in the cloud. A challenge-response system would then verify the device’s authenticity by matching both keys.
Did you know? Ensuring the authenticity of public keys in the system often involves implementing a Public Key Infrastructure (PKI) with a certification system. This allows for scaling up when dealing with device authentication since it relaxes the need for managing large databases of device public keys and simplifies the provisioning process greatly.
Nevertheless, PKIs concentrate the security of the whole system at a single point of failure (the Certification Authority), which comes with its own security challenges and presents significant industrialization challenges in terms of provisioning certificates that attest to key authenticity before products leave the factory.
Isolation: protecting against attacks
Limiting the potential impact of an attack is another central aspect of security. Isolation is achieved through containerization; the overall system infrastructure allows applications to run in isolated containers. If an attacker compromises one container, they’ll remain isolated from the rest of the system, providing an additional layer of protection. Technologies like Docker and SystemD provide such capabilities.
While software-based isolation is common, hardware-based isolation offers even greater security. Technologies like ARM’s TrustZone create highly secure execution environments, making it exceedingly difficult for attackers to escape their sandbox and access the Trusted Execution Environment (TEE).
Did you know? Ensuring the authenticity of public keys in the system often involves implementing a Public Key Infrastructure (PKI) with a certification system. This allows for scaling up when dealing with device authentication since it relaxes the need for managing large databases of device public keys and simplifies the provisioning process greatly.
Nevertheless, PKIs concentrate the security of the whole system at a single point of failure (the Certification Authority), which comes with its own security challenges and presents significant industrialization challenges in terms of provisioning certificates that attest to key authenticity before products leave the factory.
Maintaining a secure by design Linux system in the long term
Building a robust security architecture for secure by design Linux-based products involves the integration of numerous protection and hardening mechanisms. However, maintaining security over time is equally crucial. This necessitates ongoing security audits, updates, and adaptability to emerging threats.
In conclusion, building secure by design Linux-based products is a proactive strategy that starts at the product design phase and continues through the end of their lives. By prioritizing threats, defining attack models, and implementing appropriate security measures, organizations can create resilient and secure systems. Combining secure boot, provisioning, isolation, and ongoing security practices further enhances the long-term security of embedded Linux products, ensuring that they remain resilient in the face of evolving threats.
To help you design and maintain secure by design Linux systems, we’ve condensed decades of experience into software accelerators:
– Welma, our Linux distro and DevOps platform
– Pluma, automated testing tool
– CVE Scan to monitor your Linux vulnerabilities
Feel free to test them yourself!
