# Importance of cyber security analysis in the operational technology system lifecycle

Laura Tinnel, Ulf Lindqvist

► To cite this version:

Laura Tinnel, Ulf Lindqvist. Importance of cyber security analysis in the operational technology system lifecycle. 16th International Conference on Critical Infrastructure Protection (ICCIP), Mar 2022, Virtual Event, United States. pp.73-101, 10.1007/978-3-031-20137-0_3. hal-05397792

HAL Id: hal-05397792

https://inria.hal.science/hal-05397792v1

Submitted on 4 Dec 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
Chapter 3

IMPORTANCE OF CYBER SECURITY
ANALYSIS IN THE OPERATIONAL
TECHNOLOGY SYSTEM LIFECYCLE

Laura Tinnel and Ulf Lindqvist

**Abstract** This research focuses on the importance of cyber security analysis in the operational technology system lifecycle. Specifically, cyber security issues are analyzed when using information technology workstations to manage modern safety instruments that are critical components of safety instrumented systems. Attack paths and security controls in real-world industrial control safety system architectures typically used in the oil and gas sector are examined to determine whether a safety-instrumented-system-mediated architecture could provide better protection against unauthorized and malicious safety instrument configuration changes than a multiplexer-mediated architecture. The determination leveraged crafted assessment questions that were answered using standard cyber security assessment methods.

The research reveals that recurring vulnerabilities exist in all safety
systems due to design issues in safety instruments, the Highway Ad-
dressable Remote Transducer protocol, third-party device management
software and safety instrument management solutions. Additionally,
device-native hardware write protection provides the best defense fol-
lowed by safety instrumented system write protection. When using
safety instrumented system security controls, a safety-instrumented-
system-mediated architecture can protect against unauthorized device
reconfigurations better than a multiplexer-mediated architecture. The
key insight is that cyber security analyses commonly used in informa-
tion technology systems must be adapted and used in the lifecycles of
operational technology systems such as industrial control systems and
safety instrumented systems to manage the safety risks induced by cyber
attacks.

**Keywords:** Industrial control systems, safety instrumented systems, cyber security
# 1. Introduction

Industrial control systems (ICSs) operate critical physical processes in manufacturing and industrial facilities, but they do not manage process risk adequately. Safety instrumented systems (SISs) independently monitor process operations and take corrective actions to bring industrial control systems back to their defined safe states when predetermined hazardous processing conditions arise [15]. Catastrophic events can occur when safety instrumented systems do not perform their functions properly, as in the case of a 2005 Texas refinery explosion and fire that killed 15 people and injured 180 [19]. The real-world consequences of such failures depend entirely on the operational context. Safety instrumented systems are used in chemical and petrochemical processing, water and wastewater treatment, power generation in nuclear reactors and elsewhere, so the consequences can be far-reaching.

Safety instrumented systems rely on safety instruments (devices) that provide inputs (e.g., pressure and temperature) required to detect hazardous process states and take corrective actions (e.g., close a valve). Attacks against safety instrumented systems can prevent corrective actions or force process shutdowns. An attack could, for example, change the safe limits on a pressure sensor that could cause the safety instrumented system to fail to take the appropriate action. Nation-state actors have already targeted safety instrumented systems [10], so attackers are well aware of the importance of these systems. More recently, malware described as a “Swiss Army Knife for hacking control systems” was discovered and found to hijack and embed malicious commands in control system communications [8]. Attacking safety instrumented systems would be an easy way to cause physical harm.

Modern safety instruments provide “smart” features such as valve partial stroke testing and advanced diagnostics. They are typically connected to a safety instrumented system using direct cabling and communicate via analog signals. Smart data is superimposed over analog communications using the Highway Addressable Remote Transducer (HART) protocol [5], the industry standard for safety instrument communications. HART enables safety systems to monitor and modify safety instrument device configurations and states.

HART implements three command types for reading device state and updating function parameters, universal, common and device-specific. All HART devices are required to implement the universal command set. Devices may implement common commands (used by many device types and vendors) and device-specific commands to support unique features.
Operators configure HART devices using HART-based handheld devices. Alternatively, they may use information-technology-based instrument management systems (IMSs) or asset management systems (AMSs) that communicate with devices via serial connections using HART, or over an Internet Protocol (IP) network using HART and HART-IP, or a proprietary vendor protocol. In the first case, packets flow through a serially-connected HART multiplexer (MUX). In the second case, packets flow from an IMS/AMS over an IP-based network to a HART pass-through safety instrumented system input/output (I/O) card to serially-connected safety instrument devices. Deployments that use information technology computers and networks with operational technology (OT) inherit all the cyber security risks associated with information technology, enabling attackers to leverage the information technology systems to target operational technology systems.

Methods used by industry to protect safety instruments from unauthorized modifications include hardware write-protect switches or software write-protect passwords on the instruments, passwords on IMS/AMS platforms that remotely manage safety instruments and a variety of unique protections provided by safety instrumented systems.

This research sought to determine if and how an attacker could exploit an IMS/AMS to change safety instrument configurations and states to create potentially unsafe conditions. Attack paths and security controls were evaluated in two common real-world safety system architectures using four product types, safety instrumented systems, multiplexers, IMS/AMS platforms and safety instruments. Several tests were conducted to determine which architecture could provide better protection from attacks using the available security controls. This chapter presents the research methodology, findings, key recommendations and insights into embedding cyber security analyses in industrial control product and system lifecycles.

## 2. Project Background and Overview

The Linking the Oil and Gas Industry to Improve Cybersecurity (LOGIIC) Consortium studies cyber security issues in industrial control systems that can impact safety. LOGIIC has completed three projects focused on various aspects of safety systems. Two earlier projects investigated safety instrumented system controllers [11, 12]. The latest project focused on safety instruments and their management [16–18], the subjects of this work.

The LOGIIC Consortium was interested in determining the ability of an attacker to compromise an IMS/AMS platform and use it to
<figure><img src="image_3.png" /><figcaption>Figure 1. Safety instrumented system architectures used in the oil and gas sector.</figcaption></figure>

alter safety instrument configurations to create unsafe operating conditions, render the safety instruments inoperable and/or seize control from operators. Instead of uncovering specific vulnerabilities in specific vendor products, the objective was to understand if different safety instrumented system architectures and configurations had inherent risks. Another objective was to evaluate the available protections (security controls), identify protection gaps and recommend design alternatives, configuration changes and policies and procedures to reduce the risk of cyber attacks on deployed safety instrumented systems.

The research focused on two safety instrumented system reference architectures typically found in the oil and gas industry. Figure 1 shows the two reference architectures. In Architecture 1, the safety instrumented system and IMS/AMS are in the process control network (PCN). However, safety instruments are not accessible directly on this network. HART data is passed between the IMS/AMS and safety instrument devices through the safety instrumented system using a pass-through I/O card.

In Architecture 2, the safety instrumented system is not accessible via the process control network. Instead, access is via a basic process control system (BPCS) or distributed control system (DCS). As a result, the IMS/AMS cannot communicate with the safety instrumented system or safety instruments over the process control network. The IMS/AMS is connected to a multiplexer using a serial cable and HART data is passed
between the IMS/AMS and safety instruments through the multiplexer,
bypassing the safety instrumented system entirely.

Analysis of the architectures led to the formulation of the following
hypothesis:

An architecture in which a safety instrumented system mediates com-
munications between an IMS/AMS and the safety instrument devices
it manages can better mitigate device vulnerabilities than an architec-
ture in which the IMS/AMS communicates with the devices through a
multiplexer.

A series of questions were crafted whose answers could provide evi-
dence to prove or disprove the hypothesis. The questions were examined
in the context of the two reference architectures to expose risks associ-
ated with the architectures and to determine which architecture posed
less risk. Section 4.5 discusses the questions and the findings.

A key goal of the LOGIIC Consortium is to help vendors improve product security, which enhances the security of systems deployed by LOGIIC member companies. Fostering good vendor relationships is essential. Surreptitiously acquiring and evaluating products without vendor consent would damage relationships and hinder product improvements. Therefore, the research was conducted with the full support and cooperation of safety instrumented system product vendors. This impacted the evaluation design because the product sample set could not be random. Instead, the instruments used were representative of the products used by LOGIIC member companies.

LOGIIC member companies identified six safety instrumented system product types for the study and proposed candidates for each type. The product types included safety instrumented systems, IMS/AMS platforms, transmitters, fire detectors, gas detectors and “smart” valve positioners. Vendor decisions to participate or not participate in the research affected the final set of products used in the evaluation.

The assessments were limited in scope and time. Motivated adver-
saries invest ample resources and time to analyze targeted products,
enabling them to discover undocumented commands and software and
firmware vulnerabilities to exploit in attacks. In contrast, the assess-
ments performed in this research engaged partial knowledge and con-
ducted hands-on testing over a few weeks.

3. Assessment Methodology

A subset of vendor products was assigned to each of the four assess-
ments. Each product was used in one or two assessments. Architecture 1
and 2 systems were configured using the same set of products for each
assessment. These are referred to as “assessment system pairs.”
<figure><img src="image_4.png" /><figcaption>Figure 2. Overall assessment methodology.</figcaption></figure>

Figure 2 shows the overall methodology that assessed four pairs of instantiated safety instrument systems. The results were cross-analyzed to identify common issues with all assessment system pairs.

Figure 3 shows the system pair assessment methodology. Standard industry assessment methods were employed to flesh out test cases specific to instantiated safety-instrumented-system-mediated and multiplexer-mediated system pairs. The two systems in each pair were evaluated using each test case and the results were collected and analyzed.

All the assessments used the same assessment roles, threat model, rules of engagement and high-level test cases. These were captured in a test plan template that served as the basis of the detailed test plan for each assessment. The use of common templates helped ensure consistency across the assessments.

Test cases were executed at the component and system levels for each assessment system pair using the available security controls. The results of each of the four assessments were analyzed. Finally, the results across the four assessments were analyzed to draw generalized conclusions.

The test case corpus was designed to use the selected products to achieve the effects described in the hypothesis questions. The test cases covered instruments, communications and systems. The instrument and communications tests were used in the system test cases. Instrument test cases focused on command abuse. Each instrument was examined during the discovery phase to identify a sample set of commands in the HART common, universal and device-specific sets that an attacker could use to create one or more of the effects considered in the assessment questions. Table 1 shows examples of command functions that were employed. The same set of device common and universal commands (where possible) were employed to provide more consistency across assessments.
<figure><img src="image_5.png" /><figcaption>Figure 3. System pair assessment methodology.</figcaption></figure>

The communications test cases examined the use of encrypted and un-encrypted network traffic. Tests focused on network attack prevention and bypassing communications encryption. For example, when considering application-layer encryption between the safety instrumented system and IMS/AMS, malware executed as part of the IMS/AMS through a Trojan dynamic-link library (DLL) to send unauthorized commands. Some encryption implementation tests were conducted to assist vendors in securing their products. For example, the tests considered the use of self-signed certificates, unidirectional versus bidirectional authentication, and whether cryptographic components had known vulnerabilities (e.g., older Transport Layer Security (TLS) protocol versions). Specific product implementation issues were not considered in the general architecture measurements.

The system test cases applied each available security control to the instrument test cases to determine the effect of the security control on each attack. Attacks were executed with and without security controls and then serially with each applicable security control. In essence, the security controls were used as “test control knobs” to determine which
<table><caption>Table 1. Test cases abusing device commands to modify configurations and states.</caption><thead><tr><td>States</td><td>Configuration Modifications</td><td>Reset/Evasion</td></tr></thead><tbody><tr><td>Disable write protect</td><td>Password and pin code values</td><td>Wipe device alert logs</td></tr><tr><td>Place in firmware upgrade mode</td><td>Valve high-low cut off values</td><td>Wipe device history</td></tr><tr><td>Place in fixed current mode</td><td>Partial stroke values</td><td>Reset device change bit</td></tr><tr><td>Enable write protect</td><td>Alarm settings</td><td></td></tr><tr><td>Reset device repetitively</td><td>Valve positioner feedback values</td><td></td></tr><tr><td>Place in loop current mode</td><td>Valve positioner calibration</td><td></td></tr><tr><td>Force offline</td><td>Valid range limits</td><td></td></tr><tr><td>Conduct partial stroke test</td><td>Relay latching behavior</td><td></td></tr><tr><td>Value position (override)</td><td>Polling address</td><td></td></tr><tr><td></td><td>Scaling factors</td><td></td></tr></tbody></table>

controls would cause attacks to fail. The security controls included various write protection methods, IMS/AMS authentication, mechanisms disallowing connections from unauthorized hosts and various encryption schemes. Device-native write protection was the only protection common to the system pair. Since multiplexers have no security controls, device-native write protection was the only protection mechanism tested on the Architecture 2 system. Tests were also conducted to determine if attackers could bypass security controls. Interested readers are referred to [16, 17] for more details about the assessment methodology.

## 4. Research Findings

This section discusses recurring issues found in all or most assessments regardless of the vendor products. Detailed findings are available in the final project report [17]. Nearly all the findings are in the “insecure by design” category. The findings cover four areas, device command processing, IMS/AMS operator workstations, communications and protocols, and security control performance. The findings are discussed as
they relate to the assessment questions and the MITRE Common Weakness Enumeration (CWE) database of common-knowledge system design and implementation flaws [13].

## 4.1 Device Command Processing

The research discovered that device command processing is inherently risky. All nine devices in the sample set processed unchecked commands on the assumption that all the received commands were from legitimate sources. None of the devices implemented authentication or authenticated sessions. In the absence of device write protection and other external protective measures, attackers can execute any device-supported HART command at will from an IMS/AMS host platform. The conclusion is that safety instruments, in general, are subject to configuration integrity attacks.

All the devices implemented a combination of common, universal and device-specific HART commands. Some inconsistencies were observed in device implementations of HART common commands, likely due to the lack of clarity in the HART specification. Many devices implemented undocumented device-specific commands, including some that operated as toggles, which means that an attacker would not have to determine the valid command parameters to execute malicious commands.

Table 1 shows the successful test case attacks using device commands. Individual devices were subjected only to the attacks associated with supported HART commands. Some devices were subjected to additional device-specific command attacks (not discussed here.)

## 4.2 IMS/AMS Operator Workstations

An IMS/AMS workstation is a trusted platform that can be used to launch practically any attack against a safety instrumented system or other systems connected to a process control network. An IMS/AMS workstation uses device definitions (DDs) and device type managers (DTMs) for device management. Device definitions contain ASCII text files used by an IMS/AMS to perform a limited set of device configurations. Device type managers contain executable dynamic link libraries (DLLs) and text-based configuration files that provide the software needed to configure unique device features. These third-party dynamic link libraries are loaded into IMS/AMS process space so that they run as part of the IMS/AMS.

Attackers can use third-party device definition files and device type manager plugins to attack safety instrumented systems on IMS/AMS platforms as shown in Figure 4. Device type manager plugins are often
<figure><img src="image_6.png" /><figcaption>Figure 4. IMS/AMS device management.</figcaption></figure>

distributed publicly on vendor websites. The evaluated systems performed little or no checks before loading the plugins.

<table><caption>Table 2. Summary of security issues related to IMS/AMS platforms.</caption><thead><tr><td>Security Issue</td><td>Enabled Attacker Capability</td></tr></thead><tbody><tr><td>Malware embedded in and installed alongside device type manager software. Installation requires administrator privileges.</td><td>Run co-resident malware with administrator privileges.</td></tr><tr><td>No publisher or cryptographic verification of third-party plugins.</td><td>Load Trojan dynamic link library and run in IMS/AMS process space.</td></tr><tr><td>Lack of digitally-signed IMS/AMS components.</td><td>Load and run Trojan IMS/AMS components.</td></tr><tr><td>Poor attack visibility – IMS/AMS logging varies from no logging to comprehensive logging.</td><td>Attack without leaving much evidence. Possibly evade detection.</td></tr></tbody></table>

Table 2 summarizes the security issues discovered for IMS/AMS platforms. In addition to directly compromising an IMS/AMS platform, an attacker could install co-resident malware along with legitimate device type manager components. When security controls that prevent unauthorized device modifications are not installed, an attack can bypass IMS/AMS authentication mechanisms to impact device functions. Tro-
<figure><img src="image_7.png" /><figcaption>Figure 5. HART protocol packet structure.</figcaption></figure>

jan device definitions and device type managers were introduced that successfully altered the configurations of 78% of the tested devices.

## 4.3 Safety Instrumented System Communications

An IMS/AMS and safety instrumented system communicate with devices using the HART protocol enveloped in HART-IP or a vendor-proprietary IP-based protocol. The research investigated the HART 5, HART 7 and HART-IP protocols and found security issues in all three protocols.

**HART Protocol.** The IMS/AMS in Architectures 1 and 2 use the HART protocol to communicate with devices. The HART protocol has no built-in security features such as authentication and encryption.

Figure 5 shows the HART protocol packet structure. It has a preamble field for synchronization and carrier detect, start delimiter that designates the start of the packet, device address, expansion field, number representing a HART command, data size field for the data, data field and a one-byte XOR checksum for packet integrity; the one-byte XOR checksum requires a low level of effort to recompute after packet modification. Cleartext HART packets are enveloped in cleartext HART-IP or other vendor-proprietary protocol packets for transport across IP-based networks.

Security-relevant commands are not standardized. Vendors implement write protection, logging and alerting in non-standard and insecure ways, which complicate monitoring and detection of rogue configuration changes made over a network using the HART-IP protocol.

Standard, open-source penetration testing tools are available, including Wireshark parsers for HART-IP [21] and WirelessHART [20]. Additionally, the HART protocol specification is available online at [5]. Using these resources, an attacker can intercept, craft, modify, inject and replay HART commands into an IP stream at will to alter device configurations when adequate protections are not in use. HART commands can also be injected through a serial connection with a multiplexer.
<figure><img src="image_8.png" /><figcaption>Figure 6. Unauthorized device modification.</figcaption></figure>

**HART-IP.** HART-IP only applies to Architecture 1. In Architecture 1, the IMS/AMS communicates with devices over an IP-based network using HART-IP or a vendor-proprietary protocol that envelops HART packets. The HART-IP protocol has no security mechanisms and does not encrypt network packets. When coupled with Address Resolution Protocol (ARP) spoofing to intercept network packets, an attacker can create a man-in-the-middle connection to modify commands going to devices and send false information to the IMS/AMS, which is displayed to the operator. A new HART-IP protocol specification that supports encrypted network traffic was released during the research [4], but it was not assessed.

**Vendor-Proprietary Secure Communications.** Some safety instrumented systems offer a proprietary encrypted communications feature. Network packet encryption significantly improves network security and stops password sniffing, man-in-the-middle, packet replay and other attacks initiated from non-IMS/AMS platforms. However, enabling encrypted communications is not straightforward and blinds common network monitoring solutions. Furthermore, encrypted communications mechanisms can be bypassed using co-located malware or Trojan device type managers as discussed in Section 4.2.

Figure 6 shows the opportunities available to an attacker to make unauthorized device modifications. The opportunities include leveraging the trust relationships between the IMS/AMS and safety instrumented systems and employing co-located malware or Trojan dynamic
link libraries to send malicious commands through established encrypted tunnels.

## 4.4 Security Control Performance

Security controls that prevent unauthorized device changes were available at four locations in the two architectures: devices, IMS/AMS workstations, communications mediator (safety instrumented system only) and network. The protection mechanisms worked best when they were positioned close to the devices. In the sample set, three devices had hardware-only write protection, five had software or hybrid software/hardware write protection, one had independent hardware and software write protection, and one had no native write protection of any kind.

Tables 3 and 4 shows the effectiveness of device security control measures and the residual gaps. No single security measure comprehensively protected the entire safety instrumented systems.

All the safety instrumented systems tested in this research provided mechanisms for blocking HART commands with varying degrees of granularity. Each safety instrumented system tested also offered a unique set of protective features that, if implemented correctly, could help mitigate some the risk related to unauthorized modifications of device configurations. Additional details are not provided to maintain vendor confidentiality.

The most effective combined set of mechanisms for preventing unauthorized device modifications are hardware-based write protection, limiting device configuration commands to authorized applications on authorized hosts, and encrypting communications between the IMS/AMS and safety instrumented system. While none of the three mechanisms on its own provides 100% protection across the system, the three mechanisms together significantly reduce the cyber risk.

## 4.5 Assessment Questions and Findings

Section 2 discussed the hypothesis that drove the development of the assessment questions. This section lists the assessment questions and the findings for each question.

**Q. 1: Can an attacker compromise IMS/AMS platforms?** Yes. An attacker can install a Trojan IMS/AMS dynamic link library, device definition or device type manager on all the assessed IMS/AMS platforms if appropriate security procedures are not followed.
<table><caption>Table 3. Device security control effectiveness and residual gaps.</caption><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Hardware-Based Device Write Protection</strong><br><em>Applicable Architectures:</em> Architectures 1 and 2<br><em>Function:</em> Device will not process device update commands while the switch is in the protect position<br><em>Attacks Prevented:</em> Unauthorized updates sent to the target device from anywhere in the PCN, including when attached to the multiplexer<br><em>Devices Protected:</em> Single<br><em>Residual Gaps:</em> Some maintenance type commands on some devices<br><em>Bypassable:</em> No<br><em>Collateral Damage:</em> None</td><td></td></tr><tr><td><strong>Software-Based Device Write Protection</strong><br><em>Applicable Architectures:</em> Architectures 1 and 2<br><em>Function:</em> Device will not process device update commands until the device is unlocked by entering a passcode<br><em>Attacks Prevented:</em> Unauthorized updates sent to the target device from anywhere in the PCN, including when attached to the multiplexer<br><em>Devices Protected:</em> Single<br><em>Residual Gaps:</em> Some maintenance type commands on some devices<br><em>Bypassable:</em> Yes, sniffing or guessing the passcode<br><em>Collateral Damage:</em> None</td><td></td></tr><tr><td><strong>IMS/AMS User Authentication</strong><br><em>Applicable Architectures:</em> Architectures 1 and 2<br><em>Function:</em> IMS/AMS will not send update commands to devices without authentication<br><em>Attacks Prevented:</em> Unauthorized updates through hands-on access to the IMS/AMS<br><em>Devices Protected:</em> All<br><em>Residual Gaps:</em> Commands sent from locations other than the IMS/AMS<br><em>Bypassable:</em> Yes, running co-resident malware on the IMS/AMS host platform<br><em>Collateral Damage:</em> None</td><td></td></tr><tr><td><strong>Device Common and Universal Write Protection: SIS-Enforced Run Mode</strong><br><em>Applicable Architectures:</em> Architecture 1<br><em>Function:</em> SIS blocks HART common and universal write commands<br><em>Attacks Prevented:</em> Unauthorized common and universal command updates sent to any device from anywhere in the PCN<br><em>Devices Protected:</em> All<br><em>Residual Gaps:</em> Unauthorized updates using HART device-specific commands; some maintenance type common and universal commands on some devices<br><em>Bypassable:</em> Generally no, depends on the implementation<br><em>Collateral Damage:</em> None</td><td></td></tr></tbody></table>
<table><caption>Table 4. Device security control effectiveness and residual gaps (continued).</caption><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Device-Specific Write Protection: SIS Enforced</strong><br><em>Applicable Architectures:</em> Architecture 1<br><em>Function:</em> SIS blocks all HART device-specific commands, including read commands<br><em>Attacks Prevented:</em> Unauthorized device-specific command updates sent to any device from anywhere in the PCN<br><em>Devices Protected:</em> All<br><em>Residual Gaps:</em> Unauthorized updates using HART common and universal commands<br><em>Bypassable:</em> Generally no, depends on the implementation<br><em>Collateral Damage:</em> Breaks operator user interfaces that display device-specific values due to read blocking</td><td></td></tr><tr><td><strong>Limit Device Connections to Authorized Hosts</strong><br><em>Applicable Architectures:</em> Architecture 1<br><em>Function:</em> Whitelisting or required authentication mechanism blocks connections from unauthorized hosts<br><em>Attacks Prevented:</em> Updates sent to any device from unauthorized hosts in the PCN<br><em>Devices Protected:</em> All<br><em>Residual Gaps:</em> Some maintenance type commands on some devices; unauthorized updates from authorized hosts (e.g., IMS/AMS)<br><em>Bypassable:</em> For whitelisting, via spoofing or using an allowed IP address<br><em>Collateral Damage:</em> None</td><td></td></tr><tr><td><strong>IMS/AMS to SIS Communications Encryption: Host-Level</strong><br><em>Applicable Architectures:</em> Architecture 1<br><em>Function:</em> Uses public/private key exchange to authenticate senders and receivers; encrypts network-based communications<br><em>Attacks Prevented:</em> Unauthorized updates from PCN-attached hosts that cannot establish encrypted sessions with the SIS<br><em>Devices Protected:</em> All<br><em>Residual Gaps:</em> Co-resident malware can make unauthorized device changes<br><em>Bypassable:</em> Yes, using co-resident malware on the IMS/AMS host<br><em>Collateral Damage:</em> Blinds network monitoring</td><td></td></tr><tr><td><strong>IMS/AMS to SIS Communications Encryption: Application-Layer</strong><br><em>Applicable Architectures:</em> Architecture 1<br><em>Function:</em> Uses public/private key exchange to authenticate senders and receivers; encrypts network-based communications<br><em>Attacks Prevented:</em> Unauthorized updates from co-located malware on the IMS/AMS and from PCN-attached hosts that cannot establish encrypted session with the SIS<br><em>Devices Protected:</em> All<br><em>Residual Gaps:</em> Trojan DLLs and IMS/AMS software components can make unauthorized device changes<br><em>Bypassable:</em> Yes, using Trojan trusted components on the IMS/AMS host<br><em>Collateral Damage:</em> Blinds network monitoring</td><td></td></tr></tbody></table>
**Q. 2: Can an attacker gain administrator privileges on IMS/AMS platforms?** Yes. Administrator privileges are required to install a device type manager in every IMS/AMS platform tested. Installing a Trojan device type manager would give an attacker the ability to run malware with administrator privileges on the host operating system.

**Q. 3: Can an attacker gain remote control of an IMS/AMS?** Yes. Installation of a malicious Trojan device type manager was demonstrated in all the assessed IMS/AMS platforms. The malware was remotely controlled from another point in the network and was able to modify instrument configurations.

**Q. 4: Can an attacker compromise an IMS/AMS software/system from the IMS/AMS host platform or via remote means?** Yes. A Trojan device definition or device type manager can be installed from removable media. The ability to install Trojan components in all the assessed IMS/AMS platforms was demonstrated.

**Q. 5: Can an attacker affect smart instruments by remotely controlling the IMS/AMS software using stolen or cached credentials with or without IMS/AMS administrator privileges?** This is unnecessary. The ability to install remotely-controlled Trojan device type managers in all the assessed IMS/AMS platforms was demonstrated. No stolen or cached credentials were required other than installing the Trojan.

**Q. 6: Can an attacker intercept a safety instrument password using keystroke analysis, memory leakage or network sniffing?** Yes. Safety instrument passwords were captured by sniffing the network and using a keylogger on some IMS/AMS platforms. Network sniffing is feasible in Architecture 1. The attack was blocked when optional safety instrumented system encrypted communications were employed. Eavesdropping with a serial-connected multiplexer in Architecture 2 requires access to the serial communications and cannot be done directly from the network. Ethernet-connected multiplexers are subject to eavesdropping; however, such multiplexers were not assessed. Serial communications are not encrypted.

**Q. 7: Can an attacker bypass the physical lock or password of a safety instrument to make changes to the instrument?** Yes and no. Physical instrument write-protect locks could not be bypassed using
network-only access during the allotted time. All the tested software-
based write protection mechanisms, including passwords, passcodes and
write-protect toggles implemented in software, were bypassed. Devices
implemented software write protection using HART device-specific com-
mands. Using hardware-based write protection or Architecture 1 with
active security controls blocked this attack.

**Q. 8: Can an attacker affect a smart instrument using a vulnerability exploit?** Yes. This is due to the lack of authorization checking when executing device commands that affect smart instrument state.

**Q. 9: Can an attacker change an instrument parameter to an unsafe setting while evading detection of the parameter change?** Yes, in many instances. Device settings were changed and the change bit was immediately reset to acknowledge the change on all the devices that supported the feature. This prevented the IMS/AMS from giving any visual indication of the change. Detection was mainly limited to IMS/AMS logging for *post facto* analysis. The amount of logging varied significantly for each product. In some cases, log entries inappropriately attributed changes to legitimate system components instead of malware. Alarming on changes was less common than logging. Some safety instrumented systems in Architecture 1 provided additional logging capability. The multiplexer in Architecture 2 provided no additional logs or alerts.

**Q. 10: Can an attacker cause an instrument to give a false reading (e.g., change the range on the instrument to send the wrong analog signal to the safety instrumented system)?** Yes. Devices were placed in the fixed current mode and sent false values to the safety instrumented system. Some attacks leveraged HART common or universal commands and worked across multiple vendor devices. The attack was blocked using hardware-based write protection or Architecture 1 with active safety instrumented system security controls.

**Q. 11: Can an attacker force an instrument into the commissioning mode to send the attacker-specified value to the safety instrumented system?** Yes. Devices were placed in the fixed current mode and sent designated values to the safety instrumented system. The attack was blocked using hardware-based write protection or Architecture 1 with active safety instrumented system security controls.
**Q. 12: Can an attacker cause an instrument to fail to execute authorized parameter and/or state update commands?** Yes. Devices were rendered unreachable and, therefore, failed to execute parameter update commands. Some attacks leveraged HART common or universal commands and worked across multiple vendor devices. This attack was blocked using hardware-based write protection or Architecture 1 with active safety instrumented system security controls.

**Q. 13: Can an attacker cause an instrument to go offline or otherwise become unresponsive?** Yes. Some devices were forced offline, which rendered them unreachable or completely unresponsive. Some attacks leveraged HART common or universal commands and worked across multiple vendor devices. This attack was blocked using hardware-based write protection or Architecture 1 with active safety instrumented system security controls.

**Q. 14: Can an attacker change a device password?** Yes. Passcodes were changed on all the devices that supported passcodes. If a passcode was already set, it was guessed and then changed. This attack was blocked using Architecture 1 with active safety instrumented system security controls.

**Q. 15: Can an attacker lock the administrator out of controlling a safety instrument?** Yes. Passcodes on devices were changed without operator knowledge. On some devices, passcodes were changed to strings that could not be typed using a keyboard, making it even more difficult for operators to regain control. This attack was blocked using Architecture 1 with active safety instrumented system security controls.

## 4.6 Architecture Comparison

The Architecture 1 results varied depending on the use of safety instrumented system protection features. None of the tested safety instrumented systems provide complete protection against the attacks. However, using a safety instrumented system with one or more protection features reduces the risk more than the multiplexer-based Architecture 2. When no safety instrumented system protection measures are employed, the results are equivalent to those for Architecture 2.

The research found little to prevent an attacker from making harmful changes to safety instruments when using Architecture 2. The multiplexer does not protect against rogue device command execution. It partially protects all the tested safety instrumented systems against long command strings crafted to overload device input parsers. The
<figure><img src="image_9.png" /><figcaption>Figure 7. Recommended risk mitigation roadmap.</figcaption></figure>

only completely effective way to prevent unauthorized changes is to use
hardware-based device write protection.

## 4.7 Common Weakness Enumeration Findings

The assessment findings were mapped to the MITRE Common Weakness Enumeration (CWE) [13] to determine the scope of the security issues that were discovered. All the issues mapped to one or more CWEs.

Table 5 shows the CWEs commonly found across most of or all four assessments. Some products have unique security issues covered by other CWEs (not shown).

The MITRE CWEs cover system design and implementation flaws recognized by the cyber security/cyber operations communities. These security issues do not appear to be common knowledge in the safety instrumented system community. At the same time, operational technology environments have unique operational requirements for process efficiency and safety. It is believed that both communities would benefit from a joint discussion to help address the unique security needs of industrial control systems.

## 5. Recommendations

This section presents detailed actions intended to help safety instrumented system owners and operators to improve the overall security of deployed safety instrumented systems and manage cyber risk [17]. Figure 7 shows the recommended risk mitigation roadmap for safety instrumented systems. The actions are categorized as high-priority short-term, mid-term and long-term actions.

The recommended short-term actions are:

- Follow the International Electrotechnical Commission (IEC) 61511-1 Standard for safety instrumented system functional safety, which
<table><caption>Table 5. Common Weakness Enumerations (CWEs) found in the assessments.</caption><thead><tr><td>CWE</td><td>Description</td></tr></thead><tbody><tr><td>15</td><td>Improper Verification of Cryptographic Signature</td></tr><tr><td>311</td><td>Missing Encryption of Sensitive Data</td></tr><tr><td>20</td><td>Improper Input Validation</td></tr><tr><td>319</td><td>Cleartext Transmission of Sensitive Information</td></tr><tr><td>200</td><td>Exposure of Sensitive Information to an Unauthorized Actor</td></tr><tr><td>347</td><td>Improper Verification of Cryptographic Signature</td></tr><tr><td>223</td><td>Omission of Security-Relevant Information</td></tr><tr><td>419</td><td>Unprotected Primary Channel</td></tr><tr><td>261</td><td>Weak Encoding of Password</td></tr><tr><td>474</td><td>Use of Function with Inconsistent Implementations</td></tr><tr><td>262</td><td>Not Using Password Aging</td></tr><tr><td>521</td><td>Weak Password Requirements</td></tr><tr><td>267</td><td>Privilege Defined with Unsafe Actions</td></tr><tr><td>522</td><td>Insufficiently Protected Credentials</td></tr><tr><td>268</td><td>Privilege Chaining</td></tr><tr><td>523</td><td>Unprotected Transport of Credentials</td></tr><tr><td>269</td><td>Improper Privilege Management</td></tr><tr><td>602</td><td>Client-Side Enforcement of Server-Side Security</td></tr><tr><td>284</td><td>Improper Access Control</td></tr><tr><td>653</td><td>Insufficient Compartmentalization</td></tr><tr><td>285</td><td>Improper Authorization</td></tr><tr><td>656</td><td>Reliance on Security Through Obscurity</td></tr><tr><td>287</td><td>Improper Authentication</td></tr><tr><td>703</td><td>Improper Check or Handling of Exceptional Conditions</td></tr><tr><td>288</td><td>Authentication Bypass Using an Alternate Path or Channel</td></tr><tr><td>707</td><td>Improper Neutralization</td></tr><tr><td>290</td><td>Authentication Bypass by Spoofing</td></tr><tr><td>754</td><td>Improper Check for Unusual or Exceptional Conditions</td></tr><tr><td>294</td><td>Authentication Bypass by Capture-Replay</td></tr><tr><td>778</td><td>Insufficient Logging</td></tr><tr><td>295</td><td>Improper Certificate Validation</td></tr><tr><td>807</td><td>Reliance on Untrusted Inputs in a Security Decision</td></tr><tr><td>300</td><td>Channel Accessible by Non-Endpoint</td></tr><tr><td>829</td><td>Inclusion of Functionality from Untrusted Control Sphere</td></tr><tr><td>302</td><td>Authentication Bypass by Assumed-Immutable Data</td></tr><tr><td>862</td><td>Missing Authorization</td></tr><tr><td>305</td><td>Authentication Bypass by Primary Weakness</td></tr><tr><td>922</td><td>Insecure Storage of Sensitive Information</td></tr><tr><td>306</td><td>Missing Authentication for Critical Function</td></tr><tr><td>923</td><td>Improper Restriction of Communications Channel to Intended Endpoints</td></tr><tr><td>307</td><td>Improper Restriction of Excessive Authentication Attempts</td></tr><tr><td>924</td><td>Improper Enforcement of Message Integrity During Transmission</td></tr><tr><td>308</td><td>Use of Single-Factor Authentication</td></tr><tr><td>940</td><td>Improper Verification of Source of a Communications Channel</td></tr></tbody></table>

requires devices to be write-protected unless safety review permits read/write (Section 11.6.4) [9]. Use hardware write-protected switches on all devices where available. Only disable write protection during maintenance and testing.
* Apply cyber security best practices to IMS/AMS platforms to prevent attackers from exploiting their trust relationships with safety instrumented systems to launch attacks. Use network segregation or a host-based firewall to prevent remote access.

* Avoid using vendor device type managers in safety-critical applications where possible, opting instead for device definition files. Where device type managers are currently in use, verify their pedigrees and the integrity of all device type manager files. To avoid compromised device definitions and device type managers that may be placed by attackers on outward-facing vendor websites, request device definitions and device type managers that are provided by vendor representatives from a vendor-internal repository. Request cryptographic hashes to verify the integrity of all device definition and device type manager installers. Request vendors to sign all individual files. Verify the integrity of device type managers and device definitions before installation on IMS/AMS platforms. Download all device definitions and device type managers from the Internet using HTTPS.

The recommended mid-term actions are:

* Use safety instrumented systems to mediate communications between IMS/AMS platforms and safety instruments where possible (Architecture 1). Work with safety instrumented system vendors to identify and implement protection measures that reduce the attack surfaces and risk.

* Implement mechanisms that permit only authorized hosts to connect to safety instruments via safety instrumented systems to prevent unauthorized hosts from making changes.

* Encrypt communications between an IMS/AMS and safety instrumented system where possible to avoid network-based attacks that steal passwords and change device commands in transit.

* Implement a robust monitoring system to detect and raise alerts about safety instrument device changes and unexpected states.

* Conduct a complete consequences-based risk analysis of all operational safety instrumented systems using the research findings of this work to identify residual risks that are not mitigated by deployed security controls. Asset owners and operators should identify and implement additional mitigations based on risk.
<figure><img src="image_10.png" /><figcaption>Figure 8. Layered defense-in-depth approach for safety instrumented systems.</figcaption></figure>

* Create a robust security policy for safety instrumented systems. Train operators on the policy to avoid inadvertently introducing malware into safety instrumented system environments.

The recommended long-term actions, which require vendor product and industry-level changes, include:

* Implement the secure HART-IP protocol [4].

* Implement vendor-proprietary encrypted protocols.

The detailed set of recommendations are provided in the final project report [17]. The following are the summary recommendations for the various stakeholders:

* **Asset Owners and Operators:** Asset owners and operators should protect safety instrumented systems from dangerous conditions induced by attacks using a disciplined, holistic approach to security design. While a fully-secure, zero-risk state can never be achieved, risk can be reduced by applying multiple overlapping protections that limit the overall attack surface (based on Architecture 1), by identifying gaps where residual risk exists and by monitoring and alerting for evidence of attacks that are attempting to or have taken advantage of the gaps. Figure 8 shows a layered defense-in-depth approach to security that orchestrates prevention and detection mechanisms to fortify the overall environment against network-based, insider and supply chain attacks.
As demonstrated in Tables 3 and 4, Architecture 2 has fewer options for layering security mechanisms. Its use of a serial-based multiplexer obviates network-based and safety-instrumented-system-based mitigations and a multiplexer provides no security features. The only means to stop unauthorized device modification attacks is to use built-in device protections. These issues render IMS/AMS compromises difficult to stop or detect. Asset owners and operators who must use Architecture 2 should consider disconnecting their IMS/AMS platforms from process control networks to reduce the risk of compromise by network-based attacks. Strict policies and procedures should be used in both architectures to protect against supply chain compromises of the trusted platforms.

* **Safety System Operators:** Humans are often the weakest link in system security. Social engineering is used to deceive operators into accidentally introducing malware into systems. This risk is typically managed by training, limiting access and implementing security controls. Operators should be educated about security-relevant features of safety instrumented systems as well as security policies and procedures.

* **Safety Instrumented System Product Vendors:** Safety instrumented system product vendors should evaluate and refine safety instrumented system standards and designs to address modern realistic attack paths and motivated attackers. Safety instrumented system designs should be assessed for common exploitable weaknesses found in the MITRE CWE. Weaknesses should be addressed to shore up products.

* **IMS/AMS Product Vendors:** IMS/AMS product vendors should improve their IMS/AMS platforms to reduce the risks of compromise and attacks over process control networks. Signed components and safety checking of third-party device type managers should be implemented.

* **Safety Instrument Vendors:** Safety instrument vendors should implement non-bypassable physical write-protected switches on all new products. Individual device type manager files should be cryptographically signed. Provide a cryptographic hash with each device type manager file to IMS/AMS vendors and operators for verification.

* **Safety Instrumented System Vendors:** Safety instrumented system vendors should provide thorough documentation, training
**SIL 1:** Rated for use to avoid relatively minor incidents.

**SIL 2:** Rated for use to avoid more serious but limited incidents, some of which may result in severe injury or death to one or more persons.

**SIL 3:** Rated for use to avoid serious incidents involving multiple fatalities and/or serious injuries.

**SIL 4:** Rated for use to avoid disastrous accidents (note: not achievable for electronically programmable devices).

Figure 9. IEC 61511-1 safety integrity level ratings for safety instrumented systems.

and hands-on support in securely configuring safety instrumented systems. Additional security controls to address the gaps listed in Tables 3 and 4 should be evaluated and implemented.

* **International Electrotechnical Commission:** The IEC 61508 Standard should be revised to require non-bypassable write protection mechanisms. Also, the IEC 61511 Standard should reinforce the requirement for non-bypassable write protection. The device read/write mode should not be permitted above the Safety Integrity Level 2 (SIL 2). Figure 9 shows the IEC 61511-1 SIL ratings for safety systems; each level represents an order of magnitude reduction in risk [9].

* **Device Type Manager Standards Body:** The device type manager standards body should encourage all vendors to provide asset owners and operators with device definition and device type manager installer cryptographic hashes and a method for verifying the hashes. All device definitions, device type managers and configuration files should be cryptographically signed.

* **HART Standards Body:** The HART standards body should augment the HART protocol command specifications to include a means to differentiate device-specific read and write commands. This is needed to enable external protection mechanisms to block commands that update configurations while not blocking read-only commands. The standards body should work with vendors to develop standard HART commands for configuring security-relevant mechanisms.

# 6. Discussion

The industrial control system community has an excellent track record of conducting rigorous safety analyses based on standards. However,
safety analyses have not traditionally considered cyber attacks that could impact safety. For example, proof testing is an industry practice used to uncover systematic errors in safety instrumented systems [7]. Vendors specify what should be tested and when, but cyber security concepts are not included.

Attacks against safety instrumented systems can have dire consequences and these systems have already been the subject of such attacks. White hat security analysts have also focused on safety instrumented systems. In 2013, BShev and Malinovsky [2] presented their findings on HART, HART-IP, IMSs and device type managers. They concluded that the HART and HART-IP protocols are insecure. As in the case of this research, they found ways to attack IMS platforms through device type managers. In 2014, BShev [1] presented his work on HART as an attack vector at DEF CON Russia. Since these works were disseminated nine years ago, the security issues have neither been discussed openly nor addressed. While there are some overlaps with this research related to the findings, this research has focused on information technology interfaces to operational technology systems and has found additional security issues.

U.S. Department of Energy National SCADA Test Bed personnel have examined security defenses for SCADA systems [6]. They found two issues in common with the findings of this research, cleartext communications and weak or no authentication. Had their recommended mitigations been applied to safety instrumented systems, some of the security problems discovered in this research would not have persisted. Such findings need to be shared effectively with the industrial control system community. One approach is the LOGIIC Consortium model, in which industrial control system product vendors participate in assessments and are made aware of the issues that are discovered. The industrial control system community should also consider alternative methods for effective knowledge transfer.

All the phases of the industrial control product and system lifecycles should incorporate cyber security analyses because it is much less costly in terms of lives, dollars and reputation to find and fix problems early in a lifecycle instead of after deployment. Vendors should include adversary-minded cyber security experts in the design process to ensure that designs are free of common-knowledge vulnerabilities [14] and design weaknesses [13] that can be leveraged by attackers. Proof testing and other safety analysis processes should evolve to incorporate cyber security expertise and relevant concepts. Vendors and asset owners should engage penetration testers to periodically assess products and deployed systems to ensure they are not subject to current and future
ICS-CERT advisories [3, 14]. Passing these tests should be required by the IEC 61508 and IEC 61511 Standards to receive and maintain a SIL 2 or higher rating (Figure 9).

# 7. Conclusions

This research has evaluated attack paths and security controls in common safety instrumented system architectures. Four instantiated system pairs, each using different products, were tested, following which cross-system analysis was performed to illuminate recurring issues that affect the broader industry. The evaluation was conducted with full cooperation from safety instrumented system and device vendors and security experts. Recurring product-independent vulnerabilities were identified in all the safety instrumented systems tested due to insecure designs of safety instruments, IMS/AMS plugin mechanisms and the HART protocol. The design flaws enable attackers to bypass all software-based device-native write protection mechanisms.

Hardware-based device write protection is the most effective security control, but it was absent in 66% of the sample set. All the assessed safety instrumented systems offer write protection that can be used in safety-instrumented-system-mediated systems. As a result, Architecture 1 can provide better protection for safety instrument devices if security controls are enabled and configured correctly. However, if no safety instrumented system security controls are employed in Architecture 1, the safety instrumented system acts as a pass-through, just like the multiplexer in Architecture 2. In this case, Architecture 1 provides no added security benefits over Architecture 2 aside from the opportunity to perform network-based monitoring. Safety instrumented system security controls are not well known or understood in operational environments. While safety instrumented system security controls are available and can provide protection, they are often not used.

The industrial control system community has the opportunity now to plan for and address cyber threats during all the stages of the safety instrumented system lifecycle. It is time to enhance traditional safety instrumented system standards and processes to include cyber security concepts and analyses that will fortify safety instrumented systems against cyber attacks before they are deployed in operational systems.

The opinions, findings, conclusions and recommendations expressed in this chapter are those of the authors, and should not be interpreted as representing the official policies or endorsements, either expressed or implied, or position of the U.S. Department of Homeland Security, U.S. Government or the participating oil and gas companies.
## Acknowledgements

The LOGIIC Consortium is a partnership between the U.S. Department of Homeland Security (DHS) Science and Technology Directorate and member companies in the U.S. oil and gas sector. This project was co-funded by the U.S. Department of Homeland Security under Contract no. HSHQDC-16-C-00034. The authors thank DHS Program Manager Mr. Gregory Wigton for his guidance and support. The authors also thank the LOGIIC Consortium members for providing leadership, domain expertise and funding. Additionally, the authors thank the Project 12 test director and subject matter experts who conducted the hands-on assessment portions of the project.

## References

[1] A. BShev, HART as an attack vector: From current loop to application layer, presented at DEF CON Russia (www.slideshare.net/dgpeters/17-bolshev-1-13), 2014.

[2] A. BShev and A. Malinovsky, HART (in)security: How one transmitter can compromise a whole plant, presented at the International Practical Infosecurity Conference (www.slideshare.net/DefconRussia/alexander-bolshev-alexander-malinovsky-hart-insecurity), 2013.

[3] Cyber Security and Infrastructure Security Agency, ICS-CERT Advisories, Arlington, Virginia (www.cisa.gov/uscert/ics/advisories), 2022.

[4] FieldComm Group, Section 10.2: HART-IP security, in HART Communication Protocol Network Management Specification, Austin, Texas, pp. 92–97, 2020.

[5] FieldComm Group, HART Protocol Specifications, Austin, Texas (www.fieldcommgroup.org/hart-specifications), 2021.

[6] R. Fink, D. Spencer and R. Wells, Lessons Learned from Cyber Security Assessments of SCADA and Energy Management Systems, Technical Report INL/CON-06-11665, National SCADA Test Bed, Idaho National Laboratory, Idaho Falls, Idaho, 2006.

[7] P. Goteti, Proof testing safety instrumented systems, presented at the 2018 Spring Purdue Process Safety and Assurance Center Conference (engineering.purdue.edu/P2SAC/presentations/documents/Proof Testing Safety Instrumented Systems.pdf), 2018.

[8] A. Greenberg, Feds uncover a “Swiss Army Knife” for hacking industrial control systems, Wired, April 13, 2022.
[9] International Electrotechnical Commission, IEC 61511-1 Ed. 2.1. 2017: Functional Safety – Safety Instrumented Systems for the Process Industry Sector – Part 1: Framework, Definitions, System, Hardware and Application Programming Requirements, Geneva, Switzerland, 2017.

[10] B. Johnson, D. Caban, M. Krotofil, D. Scali, N. Brubaker and C. Glyer, Attackers deploy new ICS attack framework "TRI-TON" and cause operational disruption to critical infrastructure, Mandiant, Reston, Virginia (www.mandiant.com/resources/attackers-deploy-new-ics-attack-framework-triton), December 14, 2017.

[11] LOGIIC Consortium, Cyber Security Implications of SIS Integration with Control Networks, Technical Report, SRI International, Menlo Park, California, 2011.

[12] A. McIntyre, LOGIIC Safety Instrumented Systems Final Public Report, Technical Report, SRI International, Menlo Park, California, 2018.

[13] MITRE, Common Weakness Enumeration (CWE), Bedford, Massachusetts (cwe.mitre.org), 2022.

[14] MITRE, Cybersecurity Vulnerability Enumeration (CVE), Bedford, Massachusetts (cve.mitre.org), 2022.

[15] RealPars, What is a safety instrumented system? Rotterdam, The Netherlands (www.youtube.com/watch?v=W2YUNnfATBY), 2018.

[16] L. Tinnel and M. Cochrane, Getting to the HART of the matter: An evaluation of real-world safety system OT/IT interfaces, attacks and countermeasures, *Proceedings of the Cyber Security Experimentation and Test Workshop*, pp. 27-35, 2021.

[17] L. Tinnel and U. Lindqvist, LOGIIC Project 12 Safety Instrumentation Final Report, Technical Report, SRI International, Menlo Park, California, 2021.

[18] L. Tinnel and U. Lindqvist, When safety instrument control goes rogue, presented at the *Industrial Control Systems Joint Working Group 2021 Spring Virtual Meeting* (www.youtube.com/watch?v=PeRvdC07VYw), 2021.

[19] U.S. Chemical Safety and Hazard Investigation Board, Investigation Report: Refinery Explosion and Fire (15 Killed, 180 Injured), Report no. 2005-04-I-TX, Washington, DC (www.csb.gov/file.aspx?DocumentId=5596), 2007.

[20] R. Wightman, WirelessHART-Parser, GitHub (github.com/reidmefirst/WirelessHART-Parser), 2017.
[21] Wireshark Foundation, Highway Addressable Remote Transducer over IP (HART-IP), Davis, California (wiki.wireshark.org/HART-IP), 2020.