Scroll to discover
See a Demo
Skip to content

IEC/ANSI 62443 Example 5 - Embedded Device Requirements

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:

  1. Select the required SL Trustzone: IEC/ ANSI 62443-sl1
  2. Select and place the required IEC/ ANSI 62443 4-2 EDR component in the SL-1 Trustzone
  3. 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:

Threat Model Output:

At SL-1, 4 applicable Threats have been identified that correspond to an embedded device, these are as follows:

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.    

)