IEC/ANSI 62443 Example 5 - Embedded Device Requirements

Jul 14, 2022

Example xml: https://github.com/iriusrisk/IriusRisk/tree/master/Examples

Scope:

The main focus of this exercise is to identify and evaluate an embedded device’s threats, weaknesses and controls directly related to it; subsequent systems or services that are inter-connected are excluded.

62443 4-2 contains specific guidance for various component types, this guidance is related to Embedded Device Requirements (EDR).

Example Scenario:

Embedded devices are implemented in many daily purposes or specialized systems. Some examples of systems that contain Embedded devices are as follows:

Medical Devices
Smart Devices (Mobiles, Tablets, Fitness Trackers, Watches etc.)
Heating Systems
Domestic Appliances (TV’s, Dishwashers etc.)
Automotive Systems

Embedded devices are generally multi-purpose multi-feature micro-processors embedded in a complete functional system. These devices may be connected to the internet or entirely isolated from online services. Even though some of the devices are entirely ‘offline’, access points may still be readily accessible which may make them susceptible to attack.

Embedded devices consist of multiple peripherals, interfaces and functions, e.g. wifi, bluetooth, ports, protocols and sensors etc., all of which should be secured and regularly updated with its latest firmware as and when essentially required in case of vulnerability identification.

Weaknesses corresponding to some of the device peripherals could lead to an attack not just on the subject device but a system wide directed distributed attack if communications or end points are not secured between them.

Requirement:

Threat model an embedded device to identify expected threats, weaknesses and define recommended controls for mitigation. The embedded device is designated for installation to a SL-1 (security level as defined in the 62443 standards and selected as per subject case requirements), this is considered as the least restrictive Trust Zone. SL-1 protects against causal or coincidental access by unauthenticated entities.

Method:

Select the required SL Trustzone: IEC/ ANSI 62443-sl1
Select and place the required IEC/ ANSI 62443 4-2 EDR component in the SL-1 Trustzone
Update threat model, once the threat model has been updated, the threats and countermeasures will be automatically generated by the internal IriusRisk rules engine. Then move to the threats & countermeasures tabs to review the applicable threats/controls for the subject device.

Basic Architecture:

No.	Threat	Inherent Risk
1	An adversary can execute remote code	High
2	An adversary can execute malicious code by compromising the host server, performing DNS spoofing, or modifying the code in transit	High
3	An adversary bypasses the secure-boot process and executes their own untrusted, malicious boot code	High
4	An adversary sends a phishing mail with a trojan as email attachment	High

Subject Weakness and Vulnerability Overview:

Fundamental component weaknesses corresponding to the identified threats include, but are not limited to:

CWE-94: Improper Control of Generation of Code ('Code Injection').
CWE-494: Download of Code Without Integrity Check.
CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code
CWE-507: Trojan Horse

Preventative Control Measures Overview:

4 controls have been defined and would be required to comply with SL-1 as per 4-2 Embedded Device Requirements. The controls corresponding to threats are as follows:

Threat name	Inh. risk	State	Control name	Status	Res. risk	Proj. risk
Use case: SL1 - Common - 4-2 - EDR2.4
An adversary can execute remote code	High	Expose	Enforce Security Policy for the usage of mobile code technologies	Recommended	High	High
Use case: SL1 - Common - 4-2 - EDR3.10
An adversary can execute malicious code by compromising the host server, performing DNS spoofing, or modifying the code in transit	High	Expose	The embedded device shall support the ability to be updated and upgraded	Recommended	High	High
Use case: SL1 - Common - 4-2 - EDR3.14
An adversary bypasses the secure-boot process and executes their own untrusted, malicious boot code	High	Expose	Embedded devices shall verify the integrity of the firmware, software, and configuration data needed for the component's boot and runtime processes prior to use	Recommended	High	High
Use case: SL1 - Common - 4-2 - EDR3.2
An adversary sends a phishing mail with a trojan as email attachment	High	Expose	The embedded device shall provide the capability to protect from installation and execution of unauthorized software	Recommended	High	High

‍

In IriusRisk, these countermeasures are aligned to IEC/ANSI 62443 4-2 EDR and include the detailed description of how they should be implemented as well as the implementation status. This example pays special attention to the requirements of remote/malicious code execution, secure boot processes and malicious email attachments protection. This supports the embedded device user, developer or engineer with the implementation of each individual security control down to a component or product level.

Summary:

This example shows how IriusRisk can be used to quickly and easily determine what the specific countermeasures for an embedded device should be; and the importance of taking it into consideration during the design, threat model or risk assessment phases.

‍