Scroll to discover
Schedule Live Demo
Skip to content

IEC  62443 Example 3 - Medical devices – OT-IoT-Cloud Infrastructure

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

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. 

Requirement: 
Critically analyse the entire attack surface of an existing gas supply control system & remote patient monitoring system architecture within the IEC 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.

Method: 

  1. Select the required SL (Security Level) Trustzone for the gas supply control system: iec62443-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:

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 Total  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 Countermeasure Count 
Cloud 50
Gas Supply Control System 385
Patient Monitoring Zone 37
Grand Total  472

Risk countermeasure and weakness summary graphs:

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 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: Authorization
Attackers gain unauthorized access to the control of the environment Medium Expose Control access to AWS IoT Core resources Recommended Medium Medium
Use case: Networking
Attackers gain unauthorized network access Medium Expose Tag all resources Recommended Medium Medium

Gas Supply Control System Component Threat ~ Control Relation

Component: Serial Interface - SPI Bus

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

Summary:
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.