Charles Marrow
Head of Center of Excellence - Embedded Device Security
January 28, 2022

IEC/ANSI 62443 Example 3 Medical devices OT IoT Cloud Infrastructure

Example xml:

Example Scenario: 
This extensive example provides a detailed overview of how a typical hospital gas supply control system, IoMT (Internet of Medical Things) and Cloud infrastructure are critical aspects of the architecture. The gas supply control system is a fundamental critical service for the hospital. The OT (Operational Technology) and patient monitoring system may well provide a back door to access the network by an unauthorized actor. This motive stresses that an essential activity is to threat model the entire architecture, exposing any weaknesses and hence identify and apply the necessary controls.  In the case where all system devices use the same core network this poses a threat to exploitation of a weak element in the network to gain access to the critical component. 

Critically analyse the entire attack surface of an existing gas supply control system & remote patient monitoring system architecture within the IEC/ ANSI 62443 standards framework. Identification of any overlapping system weaknesses may be exploited to gain access to adjacent systems on the network. Threats and Control requirements related to the OT and IoMT cloud deployment model can then be established.


  1. Select the required SL (Security Level) Trustzone for the gas supply control system: IEC/ ANSI 62443-sl2
  2. Select and place the required components as per the existing system architecture and allocate accordingly in the SL-2 Trustzone
  3. Define the IoMT device architecture within the boundaries of the Hospital network area and related application services. 
  4. Select the appropriate trustzone and place these IoMT components and services there.
  5. Define the applicable cloud components and services related to the patient monitoring system and allocate them in a private, hybrid or public cloud trustzone.
  6. Once the threat model has been updated, the threats and countermeasures will automatically be generated. Then move to the countermeasures tab to review the applicable controls for the entire system. 
  7. Controls can then be managed on a component or service basis if required.


Architecture IEC/ANSI

Threat Model Output:

374 Threats have been imported to the threat model in total with the vast majority of the threats associated with the gas supply control system, a brief summary of total threats per component is shown in the table below:

 Area Total Threat Count
Cloud 29
Gas Supply Control System 318
Patient Monitoring Zone 27
 Grand Toal  374

472 countermeasures and controls have been defined, again with the majority of these in the gas supply control system area. A brief summary of total controls per area is shown in the table below:

 Area Total Threat Count
Cloud 50
Gas Supply Control System 385
Patient Monitoring Zone 37
 Grand Toal  472

Risk countermeasure and weakness summary graphs:

Risk countermeasure

In IriusRisk, these countermeasures include the detailed description of how they should be implemented as well as their implementation status. This supports the user, developer or engineer with the implementation of each individual security control down to a component level or the systems can be dealt with by area. All seven foundation requirements from the IEC/ ANSI 62443 standard are observed in the threat model as well security aspects related to the remote cloud IoMT dedicated services:

Cloud Component Threat ~ Control Relation

Component: IoT Core

 Threat Name Inh.Risk State Control name Status Res.risk Proj.Risk
Use case: SL2 - Common - CR2.11            
 An adversary compromises a system  without knowing when he compromised it.  High  Expose  Assets shall provide the capability to create timestamps that are synchronized with a system wide time source  Recommended  High High 
       Assets shall provide the capability to create timestamps (including date and time) for use in audit records.  Recommended  High High 

Patient Monitoring Zone Component Threat ~ Control Relation

Component: MQTT Client

 Threat Name Inh.Risk State Control name Status Res.risk Proj.Risk
Use case: Authentication and Authorization            
An attacker can simulate a fake application to send commands to the MQTT client  High  Expose Enforce Application ID validation in the MQTT client  Recommended  High High 
 Attackers can extract authentication credentials from the client and use them to log in to the MQTT broker  High   Expose Use hardware security solutions to protect sensitive information on IoT devices  Recommended  High High 

This example shows how IriusRisk can be used to quickly and easily determine what the specific countermeasures for a given Security Level should be; and the importance of including the critical infrastructure, local equipment or devices in the threat model during the design or risk assessment phases. Without going into fine detail this example also demonstrates the importance of considering the entire network infrastructure for critical services, not just the individual components or isolated systems.