Excerpt: LOGIIC's Project 12 Safety Instrumentation Report

Editor's Note: As we wind down Cybersecurity Awareness Month, ISAGCA continues to provide a collaborative forum to advance cybersecurity awareness, education, readiness, and knowledge sharing. A critical part of this awareness is that it allows organizations to focus in on and understand the intersection of safety with cybersecurity. The following work from LOGIIC work reinforces this relationship in their report "Project 12 Safety Instrumentation."

Executive Summary

The Linking the Oil and Gas (O&G) Industry to Improve Cybersecurity (LOGIIC) consortium was established in partnership with the U.S. Department of Homeland Security (DHS) Science and Technology (S&T) Directorate to review and study cybersecurity issues in industrial control systems (ICS) that impact safety and business performance as they pertain to the O&G sector. Project 12 was conducted during 2020 and focused on the security and management of safety instrumentation. The project revealed numerous consequential and recurring findings that indicate a pervasive industry-wide security problem in safety systems. This report documents key findings and recommendations for asset owners, vendors, and standards bodies.

ICSs use safety instrumented systems (SISs) to monitor operations and take automated actions to maintain a safe state when abnormal conditions occur. Instruments such as transmitters, valve controls, and fire and gas detectors provide critical inputs and controls to safety system function. In recent years, instruments have been modernized to provide smart features such as partial stroke testing for valves.

Smart instruments are typically connected to the SIS using direct cabling and communicate via analog signals. Smart data is superimposed over analog communications using the Highway Addressable Remote Transducer (HART) protocol. This protocol enables systems to read data from instruments and modify their configurations and states as part of normal operations. HART data can be accessed by local handheld devices, through pass-through SIS I/O cards, or with a HART data multiplexer (MUX). In the latter two cases, an instrument or asset management system (IMS/AMS) can interact with and configure safety instruments using the HART protocol over an internet protocol (IP)-based network using HART-IP or SIS proprietary protocols. While the earlier LOGIIC Project 5 focused on wireless HART and handheld devices, Project 12 focused exclusively on wired HART, HART-IP, SIS proprietary protocols, and the use of an IMS/AMS.

The lack of built-in security features in the HART protocol necessitates the use of alternative methods to protect devices from unauthorized modifications. Protections considered under Project 12 included a hardware write-protect switch on the instrument, a software-based write-protect password or pin code on the instrument, password on the IMS/AMS (or its underlying operating system platform) that remotely manages the instrument, and a variety of disparate protections provided by various SIS solutions.

Project 12 defined and used a threat model in which the attacker sought to compromise an IMS/AMS and use that platform to make unauthorized changes to the configuration of safety instruments. Unauthorized changes considered by Project 12 were those that could result in unsafe operating conditions, render the instruments inoperable or unable to perform safety functions, and/or take instrument control away from asset owners. These attacker goals were examined in the context of two architectures: 1) the IMS/AMS controls instruments through a MUX and 2) the IMS/AMS controls instruments through an SIS.

Four individual assessments were planned based on the threat model, industry protection mechanisms and architectures, and a sampling of vendor products typically found in O&G sector operations. Attack avenues considered included malicious and unwitting insiders and supply chain attacks. Each assessment was conducted as a partial-knowledge test with full cooperation from the vendors.

Concerted adversaries have ample time and resources to analyze vendor products, which enables them to discover undocumented commands and vulnerabilities that can be used in attacks. In contrast, Project 12 was limited in both time and scope. Each assessment was conducted over the course of a few months using publicly available information and several weeks of hands-on testing and was constrained by defined rules of engagement (RoE). Even with these limitations, Project 12 uncovered numerous consequential and recurring exploitable weaknesses across individual assessments that indicate a systemic and pervasive industry-wide problem. This issue is mainly a consequence of four critical findings: 1) some safety system designs allow unchecked HART passthrough, 2) the current HART and HART-IP protocols have no built-in security, 3) devices do not authenticate the sources of received HART commands and many have bypassable write-protections, and 4) the industry uses unverified 3rd party software downloaded from the Internet.

Successfully demonstrated attacks used a number of commonly available attacker tools and exploited common-knowledge architectural weaknesses that were present in all four assessments. These attacks required a low to moderate level of effort to exploit and included effects that can significantly impact device safety function.

Project 12 also exposed the risks associated with the two architectures and determined the circumstances under which each architecture poses the least risk. Key findings include: 

• Attackers can make unauthorized device changes at will and evade detection. Some changes can result in unsafe operating conditions. The risk of cyberattack directly impacts safety and must be considered along with hardware faults and other safety considerations.
• There is no simple and immediate remedy for securing safety systems; risk reduction requires a combination of protection and detection mechanisms.
• Safety systems architectures that mediate IMS/AMS and safety instrument communications using an SIS with enabled protective features pose less risk of unauthorized device modification than do architectures using a passthrough MUX. If SIS protections are not enabled, the risk is equivalent to that of using a MUX.
• Device hardware-based write protections are the only fully protective means to prevent unauthorized device configuration changes. Only 33% of sampled devices had hardware switches.
• Software-based write protections can be bypassed with little effort; therefore, they do not protect against these changes. SIS write protections effectively prevent some, but not all, changes.
• Device write-protect implementation is inconsistent, even across the same vendor products. This can lead to confusion and accidentally unprotected devices.
• HART protocol design deficiencies complicate the prevention of and monitoring for attacks attempting unauthorized changes. The protocol lacks basic security concepts. The HART common command set does not include security-relevant commands which leads to inconsistent implementation across devices using device-specific commands. This hinders the detection of attempts to circumvent device security features. The protocol provides no means to differentiate device-specific read and write commands. This makes it impossible for any SIS to block device-specific write commands without also blocking read commands. Blocking device-specific commands prevents the IMS/AMS from displaying the status of any device-specific commands.
• The practiced method of distributing and installing device type manager (DTM) software opens the door to supply chain attacks and thus poses significant risk to IMS/AMS platforms. These platforms are trusted and can be used as a launch point for device attacks.

Critically, Project 12 concluded that the safety environment is vulnerable to malicious attacks that may be undetectable in practice and that extreme caution should be taken before installing any software, which could introduce malware into the process control network (PCN). We cannot sufficiently emphasize the severity of this vulnerability.

Figure 1. LOGIIC Project 12 Recommended Risk Mitigation Roadmap

LOGIIC recommends a roadmap of mitigations to reduce risk to asset owners over the short-, mid-, and long- terms (Figure 1.) Safety system owners should immediately: 

• Follow the IEC 61511-1 standard, which requires that all SIS devices have write-protection. Use hardware write-protect switches on all devices that have them. Disable switches only when conducting maintenance.
• Apply security best practices to the IMS/AMS platform to prevent attackers from exploiting the platform’s trust relationship with the SIS to launch attacks. Use network segregation or a host-based firewall (e.g., Windows 10 Security firewall) to prevent remote access.
• Avoid using vendor DTMs in safety-critical applications where possible; instead, opt for device description (DD) files. Where DTMs are currently in use, verify the pedigree and integrity of all DTMs files. Obtain DTM and DD files directly from vendors. Request cryptographic hashes to verify the integrity of all DTM and DD installers. Ask that vendors sign all individual files. Verify DTM and DD integrity before installation on IMS/AMS platforms. Required that all DTMs or DDs downloaded from the Internet use HTTPS.

Based on Project 12 findings, these mitigations will substantially reduce the risk to safety systems. In the midterm, LOGIIC recommends that safety system owners: 

• Use the SIS to mediate communications between IMS/AMS solutions and safety instruments. Work with the SIS vendor to identify and implement SIS-specific protective measures to reduce the available attack surface and therefore, risk.
• Implement a means to limit allowed SIS network connections only to authorized hosts to prevent unauthorized hosts from making changes.
• Encrypt communications between the IMS/AMS and SIS where possible to avoid network-based attacks that steal passwords and change device commands in transit.
• Implement a robust monitoring system to detect and alert on device changes and on unexpected device states.
• Conduct a consequences-based risk analysis of all operational safety systems using Project 12 findings to identify any residual risk not mitigated by applied countermeasures. Asset owners should identify and implement additional countermeasures based on risk to their own operations.
• Create a robust security policy for their systems. Operators should be trained on the policy and how to avoid inadvertently introducing malware into the environment. 

Longer term fixes should address larger issues that require vendor product and industry-level changes. These include implementing the secure HART-IP protocol that was included in the HART Network Management Specification published July 2020. 

The full report includes additional findings and recommendations for asset owners, product vendors, and standards bodies. By providing these project outputs, LOGIIC hopes to help improve the overall security posture of all ICS stakeholders.

To read and download the full report, click here.