IEC 62443 Example 6 - Hardware Security Requirements

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

Scope:

The main focus of this exercise is to identify and evaluate hardware security countermeasures principally related to the 2021 CWE Most Important Hardware Weaknesses. Threats and controls will be derived and manually selected as per a typical hardware component arrangement.

62443 4-2 contains specific guidance for various component types. In this exercise a 62443 EDR or NDR component could be selected and secured according to the design.

Example Scenario:

Different hardware types are used as the building blocks for computers, control systems, network devices, medical IoT/Consumer IoT/Industrial IoT devices. Hardware includes modules such as motherboards, programmable logic controllers, microchips, memory (Random Access/Read Only), storage (optical/solid state/magnetic), communications ports, maintenance ports (JTAG) etc. Generally such hardware is selected appropriately and interconnected to form a complete functional system or device. Firmware and software is installed on the hardware to control them independently and/or to allow for a unified functionality between each component, thus forming a purpose designed and built system.

Hardware is also susceptible to sophisticated attacks initiated through vulnerable code or component features. Attacks can be launched taking advantage of shared resources without proper isolation, improper access control via a test interface or firmware that does not have an option to be updated. Securing each independent system component should be considered as important as securing the software that is embedded on them.

The figure below shows the connection and data flow details of a typical JTAG architecture. JTAG ports have standard security modes, some examples are as follows:

No debug; Maximum Security
Secure Debug; High Security
Debug Enabled; Low Security

JTAG Architecture; Connections, Data Flow & registers

Requirement:

Identify hardware related controls and associate applicable CWE’s for greater visibility of weaknesses, vulnerabilities and relevant mitigating controls.

Method:

Select the required SL Trustzone: iec62443-sl2
From the 62443 > CWE mapping identify that an EDR or NDR component has a Hardware related CWE, CWE-1191: On-Chip Debug and Test Interface With Improper Access Control, the Control requirement for mitigation of the CWE corresponds to 62443 4-1 CR 2.13 – Use of physical diagnostic and test interfaces
Select and place the iec62443 4-2 EDR or NDR component in the SL-2 Trustzone.
Click 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.
Select appropriate CWE’s related to hardware design according to the 2021 CWE Most Important Hardware Weaknesses and apply suitable controls from 62443 4-1. Typical threats and controls will be imported according to the selected CWE. Another example CWE is CWE-1277: Firmware Not Updateable, however, this CWE is not yet associated with a control.
Select the appropriate control from the threat list. E.g. 62443 4-1 EDR or NDR 3.10 – Support for updates and add the weakness to the threat to be considered as a hardware applicable association.

Note: this is an example case and other CWE’s will have to be appropriately selected and linked to a 62443 3-3 & 4-2 Control Requirements.

*Weakness selection table for addition to a specific threat*

7.Identified controls EDR 2.13 & 3.10 can be set to required to add visibility of the hardware related controls requirements.

8. To provide clarity for the EDR 3.10 Threat, CAPEC-682: Exploitation of Firmware or ROM Code with Unpatchable Vulnerabilities is included as a new threat/attack vector in the Use Case.

*Note: if required, EDR 3.10 Control can be added as a countermeasure on the new threat.*

Basic Architecture:

Threat Model Output:

At SL-2, there are now two threats corresponding to hardware weaknesses, these are shown in the following table:

No.	Threat	Inherent Risk	STRIDE Category Flow (Manual origin)
1	An adversary introduces malware onto the asset via a physical diagnostic or test interface	High	Tampering > Spoofing (If authentication/authorisation bypassed)
2	Exploitation of Firmware or ROM Code with Unpatchable Vulnerabilities (As per CAPEC-682)	Critical	Tampering > Elevation of Privileges > (If authentication bypassed to root) Denial of Service (If device used to launch a DoS or DDoS attack)

Example fundamental hardware weakness corresponding to the identified threats:

Considering the original CWE example CWE-1191, this example weakness is related to improper access control of the on-chip Debug and Test Interface. In this example attack scenario the chip does not verify if the user is authorised to access internal registers through the debug/test interface. This weakness could potentially allow an adversary to modify a critical hardware function or access sensitive information like registers containing secrets or keys.

Preventative countermeasure overview:

Two required controls are associated with the exposed vulnerabilities. The controls corresponding to the threats are shown in the following table:

Threat name	Inh. risk	State	Control name	Status	Res. risk	Proj. risk
Use case: SL2 - Common - 4-2 - EDR2.13
An adversary introduces malware onto the asset via a physical diagnostic or test interface	High	Exposed	Embedded devices shall protect against unauthorized use of the physical factory diagnostic and test interface(s)	Required	High		Very Low
Use case: SL2 - Common - 4-2 - EDR3.10
Exploitation of Firmware or ROM Code with Unpatchable Vulnerabilities	Critical	Exposed	The embedded device shall support the ability to be updated and upgraded	Required	Critical		Critical
			Update authenticity and integrity	Recommended	High		Medium

In IriusRisk, these countermeasures are aligned to IEC 62443 4-2 and include a detailed description of how they should be implemented as well as the implementation status. This example pays special attention to the requirements for hardware threats, weaknesses and corresponding controls for mitigation. This supports the hardware designer, developer or engineer with the implementation of each individual security control down to a component or product level. Identifying threats and weaknesses early on in the design phase will produce hardware with secure functions, code and attributes and hence, a secure by design product even before all the components are unified to form a complete system.

Summary:

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

What next?

Take a look at our Operational Technology Landing Page for further information and resources.

‍