IEC/ANSI 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/ 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.

Method: 

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:

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:

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:

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/ 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

Patient Monitoring Zone Component Threat ~ Control Relation

Component: MQTT Client

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.