SYS.4.3 Embedded Systems

A person MUST be appointed to be in charge of embedded systems in order for them to operate smoothly. All users and administrators MUST be informed of any codes of conduct and reporting channels in the event of failures, malfunctions, or suspected security incidents.

Embedded systems MUST be configured securely. These configurations SHOULD be documented. Regulations SHOULD be defined for testing integrity and functionality.

It MUST be ensured that only required interfaces can be accessed. Only the required services MAY be activated. Access to application interfaces MUST be protected by means of secure authentication.

Security breaches MUST be logged (see OPS.1.1.5 Logging). If electronic logging is not feasible or only possible to a very limited extent, alternative organisational rules SHOULD be created and implemented.

Before an embedded system is procured, a requirements list MUST be drawn up that can be used to evaluate the systems or components available on the market. The requirements list SHOULD include the following security-relevant aspects at minimum:

• aspects of material security
• requirements for hardware security properties
• requirements for software security properties
• support for a Trusted Platform Module (TPM) through the operating system
• security aspects of the development environment
• organisational security aspects

It SHOULD be ensured that embedded systems are adequately protected from harmful environmental influences according to their intended use and location. The requirements for this SHOULD be analysed right from the planning phase. It SHOULD also be ensured that the precautions taken to protect individual components from dust and contamination are compatible with the requirements of the overarching system at hand.

Possible debugging options SHOULD be removed from embedded systems as completely as possible. If on-chip debugging is used, it MUST be ensured that debugging functions cannot be used or activated by unauthorised persons.

It SHOULD also be ensured that no input interfaces for test signals or measuring points for connecting analysers can be activated or used by unauthorised persons. All hardware debugging interfaces SHOULD also be disabled.

If embedded systems are developed in-house, security aspects SHOULD be taken into account when taking decisions on hardware and software design. Security aspects SHOULD also be taken into account when deciding to implement a particular hardware technology.

The operating system used and the configuration of an embedded system SHOULD be suitable for its intended operation. The operating system SHOULD thus have sufficient security mechanisms for the task at hand. The required services and functions SHOULD be activated. The operating system SHOULD support the use of a Trusted Platform Module (TPM).

If an additional microcontroller is used for cryptographic calculations, its communication with the system microcontroller SHOULD be adequately secured. The required trust anchors SHOULD be realised for the embedded system in question. A chain of trust SHOULD also be implemented.

Embedded systems SHOULD have rollback capabilities.

Prior to the disposal of embedded systems, all their data SHOULD be securely deleted. Their deletion (or destruction) SHOULD be documented.

Effective controls SHOULD be carried out in the logistics chain to ensure the following:

• embedded systems do not include any manipulated, falsified, or replaced components.
• embedded systems meet the respective specifications and no hidden functions have been implemented during manufacture.
• confidential information on embedded systems cannot be accessed by unauthorised persons

The companies involved SHOULD be demonstrably qualified.

The operating system in use SHOULD be evaluated at an adequate level according to a recognised standard.

The boot process of an embedded system SHOULD be secured by the boot loader based on its ability to check the integrity of the operating system and only load it when it is classified as correct. By the same token, the operating system SHOULD also check the integrity of the boot loader.

A multi-stage boot concept SHOULD be used that can check the individual steps in a cryptographically secure manner. Secure hardware trust anchors SHOULD also be used. ARM Secure Boot SHOULD be used in ARM-based embedded systems. Secure Boot SHOULD be used with a Unified Extensible Firmware Interface (UEFI).

Memory protection mechanisms SHOULD be considered right from the design of embedded systems. The type of storage protection and the number and size of the protected areas SHOULD be appropriate for this purpose.

A tamper protection concept SHOULD be developed for embedded systems. Adequate mechanisms SHOULD be established to detect, record, and prevent tampering. Adequate guidelines SHOULD also be established on how to respond to tampering.

All the assemblies of an embedded system with higher availability and integrity requirements SHOULD be equipped with integrated self-testing equipment (built-in self-test, BIST). Tests SHOULD check the integrity of the system when it is turned on and at adequate intervals during its operation. Where possible, the self-test functions SHOULD also check assemblies' security functions and properties.

The integrity of the memory and I/O components SHOULD be checked regularly within the framework of the BIST. Existing BIST functions SHOULD be supplemented by the functions required if possible.

To make embedded systems resistant to side-channel attacks, appropriate precautions SHOULD be taken against non-invasive and (semi-) invasive side-channel attacks.