Secure Code Review
Secure Code Review
A secure embedded design and development lifecycle must be used for the development of hardware, firmware and mobile computing devices. The following aspects are of particular relevance beyond the aspects of typical secure development guidelines:
- Secure coding guidelines must be specific for hardware-related development and languages.
- Consider adding extra variable integrity validity checks on critical values to prevent “bricking” of systems should a value be improperly changed.
- Rely on stable software components. Updates are often costlier than in traditional IT systems.
- Rely on software components with long support times.
- Trust boundaries must be reviewed: While typical trust/threat analysis often considers the local system trustworthy, this is not the case when assessing hardware-related threats. For example, firmware update mechanisms process data provided within the same system, however, the code processing a signed firmware upgrade bundle may be the only code processing data from other system components at all, making it an exposed interface.
- Implement segregation of duties, least privileges, and different trust zones for different system services/functionality. Atmia.com link below describes the typical limits of embedded/hardware-related platforms, however, modern platforms offer sufficient resources to implement trust areas.
- Only unmodified tools and components must be used for the development. This applies to both software and hardware and must be verified throughout the whole supply and development chain.
- Available platform security mechanisms (such as DEP, ASLR and logical access restrictions) must be used and correctly enabled/set, at least/the latest during the release process for the system.
- Access to memory regions should be restricted according to the system needs, e.g. using technologies like memory protection units or IOMMUs (implemented e.g. by Intel’s VT-d or AMD’s Vi).
For firmware/software developer:
For firmware/software developer:
- Platform security mechanisms should be integrated, made available, and clearly documented to developers using the platform. A security best practices guide for the platform should be published.
For hardware/platform developer:
For hardware/platform developer:
C and C++ are the main languages when it comes to hardware-related development. However, those languages are also more prone to result in software vulnerabilities (mainly in the memory corruption area). Languages like Go and Rust also provide the option to create compiled executable code but also introduce type-safety, garbage collection, and other security-relevant characteristics. The use of such a language
(or at least alternative programming paradigms as described in (Memory Safety Without Garbage Collection for Embedded Applications) should be evaluated for hardware-related programming to prevent certain types of vulnerabilities in the first place.
(or at least alternative programming paradigms as described in (Memory Safety Without Garbage Collection for Embedded Applications) should be evaluated for hardware-related programming to prevent certain types of vulnerabilities in the first place.
Language Security:
Language Security:
Further Reading:
Further Reading:
