![](https://cdn.prod.website-files.com/650d8cb4b59554163db63bab/65495e377a2f9414a42a3668_Medical%20Device.jpg)
![](https://cdn.prod.website-files.com/650d8cb4b59554163db63bab/651fcd3f8d3d382c93f5386a_Charles%20Marrow.jpg)
IEC/ANSI 62443 Example 5 - Embedded Device Requirements
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:
![](https://cdn.prod.website-files.com/650d8cb4b59554163db63bab/653a44bfcf10b8a475a56aca_IEC%2520%252062443%2520Example%25205-1.png)
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:
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.
![](https://cdn.prod.website-files.com/650038f43bd74338d2d25f41/667d4053d008f447de84064b_EU%20LOGOS.png)