Author | Antai Technology
【Abstract】Methods used in industry to protect instruments from unauthorized modifications include hardware write protection switches on instruments, software write protection passwords on instruments, passwords for remotely managing instruments’ IMS/AMS, and various unique protections provided by SIS solutions. Utilizing these protective measures, Project 12, aided by the U.S. Department of Homeland Security, aims to determine whether and how attackers use IMS/AMS to alter instrument configurations and statuses, thereby creating potential unsafe conditions. Its main goal is to identify vulnerabilities in commonly used security instrument or asset management systems (IMS/AMS) solutions within the safety system architecture typically employed in the oil and gas industry, and to provide options and configurations that developers can use to design for security against the identified vulnerabilities. The Project 12 report presents findings, validation, impact assessments, and mitigation measures regarding network security issues related to instrument use and instrument systems within functional safety systems, which is very helpful for industrial cybersecurity practitioners to understand sensor-level cybersecurity issues. Antai Technology Research Institute has compiled the main content of this report for everyone’s study and reference.
Background
LOGIIC and the Automation Federation recently released the final report of Project 12 – Safe Instrument Use. LOGIIC (“Connecting the Oil and Gas Industry for Improved Cybersecurity”) is an organization sponsored by the U.S. Department of Homeland Security Science and Technology Council and member organizations such as BP, Chevron, Total, and other stakeholders in the oil and gas industry, with the main task of researching how oil and gas companies can strengthen the cybersecurity of their critical systems.
This project (Project 12) builds on previous research (Project 11), which extensively studied vulnerabilities in safety controllers commonly used in oil and gas facilities. Project 12 shifts focus to the cybersecurity status of the actual sensors that input data to these controllers. It aims to clarify the impact on safety systems if these sensors and actuators are manipulated, and the effect on the overall safety of oil and gas facilities. The ultimate goal is to enhance understanding and awareness of cybersecurity at the sensor and actuator levels.
These instruments include transmitters from fire and gas detection analyzers, pressure sensors, solenoids, and positioners. They typically communicate with Distributed Control Systems (DCS) and Safety Instrumented Systems (SIS) using non-IP communication protocols known as Highway Addressable Remote Transmitters (HART) communication. These devices are referred to as Level 0 devices in the Purdue Reference Model. Level 0 devices in modern safety system architectures in oil and gas are responsible for processing process data, which is fundamental for the operation of control systems. If the instrument devices do not function correctly, the safety control system cannot operate correctly either.
The report documents the main findings and recommendations from asset owners, suppliers, and standards organizations, revealing many indirect and recurring key findings that indicate a widespread cybersecurity issue across the industry in functional safety systems.
ICSs use Safety Instrumented Systems (SISs) to monitor operations and take automatic actions to maintain functional safety in the event of anomalies. Instruments such as transmitters, valve controls, fire and gas detectors provide critical inputs and controls for safety system functions. In recent years, instruments have been modernized to provide intelligent functions, such as partial stroke testing of valves.
Smart instruments typically connect directly to SIS via cables and communicate using analog signals. Smart data is overlaid on analog communication using the Highway Addressable Remote Transmitter protocol (HART). This protocol allows systems to read data from instruments and modify their configurations and statuses as part of normal operations. For example, HART data can be accessed via local handheld devices, SIS I/O cards, or using HART data multiplexers (MUX). In the latter two cases, the Instrument Management System or Asset Management System (IMS/AMS) can interact and configure safety instruments via an Internet Protocol (IP)-based network using HART-IP or SIS proprietary protocols. While earlier LOGIIC projects focused on wireless HART and handheld devices, Project 12 specifically focuses on wired HART, HART-IP, SIS proprietary protocols, and the use of IMS/AMS.
Due to the lack of built-in security features in the HART protocol, alternative methods are needed to protect devices from unauthorized modifications. Protective measures considered in Project 12 include hardware write protection switches on instruments, software-based write protection passwords or PIN codes on instruments, passwords for remote management of instruments’ IMS/AMS (or their underlying operating system platforms), and various protections provided by different SIS solutions.
Project 12 defines and employs a threat model in which attackers attempt to compromise IMS/AMS and seek to make unauthorized changes to the configurations of safety instruments. The unauthorized changes considered by Project 12 are those that could lead to unsafe operating conditions, render instruments inoperable, or allow changes that compromise the safety functions of the instruments out of the control of asset owners. These attackers’ objectives were examined in two architectures: 1) IMS/AMS controlling instruments via SIS; 2) IMS/AMS controlling instruments via MUX.
Figure 1 Architecture 1 (left) provides direct network connection to SIS, which serves as a communication intermediary between IMS/AMS and devices.
Project 12 conducted four separate assessments based on the threat model, industry protective mechanisms, architectures, and a sampling of typical vendor products in the O&G sector. Attack vectors were considered to include malicious and unwitting insiders as well as supply chain attacks. Each assessment was conducted as an incomplete knowledge test with the full cooperation of the vendor.
Advanced adversaries have sufficient time and resources to analyze vendor products, allowing them to discover undocumented commands and vulnerabilities that can be exploited in attacks. In contrast, Project 12 was limited in time and scope. Each assessment was conducted over several months using publicly available information and several weeks of practical testing, and was subject to explicit rules of engagement (RoE).
Even with these limitations, Project 12 uncovered numerous indirect and recurring exploitable weaknesses, indicating a systemic and widespread industry issue. These issues primarily resulted from four key findings:
1) Some functional safety system designs allow unchecked HART passthrough modes;
2) Current HART and HART-IP protocols lack built-in security;
3) Devices do not verify the source of received HART commands, and many devices have bypassable write protection;
4) Use of unverified third-party software downloaded from the Internet.
Successfully executed attacks used many common attacker tools and exploited weaknesses in the public knowledge architecture, which occurred in all four assessments. These attacks required low to moderate levels of capability and effort to exploit vulnerabilities and achieve impacts on device safety functions.
Project 12 also exposed risks associated with both architectures and identified the situations in which each architecture posed the least risk. The main findings include:
-
Attackers can change unauthorized devices at will and evade detection.Some changes could lead to unsafe operating conditions. The risk of cyber attacks directly impacts safety and must be considered alongside hardware failures and other safety issues.
-
Functional safety systems do not have simple and immediate remedies; reducing risks requires a combination of protective and detection mechanisms.
-
Compared to architectures using passthrough MUX, safety system architectures that mediate IMS/AMS and safety instrument communication using SIS with enabled protective features reduce the risk of unauthorized device modifications. If SIS protection is not enabled, the risk is equivalent to that of using MUX.
-
Hardware-based write protection is the only complete means to prevent unauthorized changes to device configurations.Only 33% of sampled devices were equipped with such hardware switches.
-
Software-based write protection can be easily bypassed; therefore, they cannot prevent these change attempts.SIS write protection effectively prevents some, but not all changes.
-
Device write protection implementation is inconsistent, even among products from the same vendor. This can lead to confusion and unintended unprotected devices.
-
Design flaws in the HART protocol complicate the prevention and monitoring of attacks attempting unauthorized changes. The protocol lacks fundamental security concepts. The HART public command set does not include security-related commands, leading to inconsistencies in the implementation of device-specific commands. This hinders detection of attempts to circumvent device security features. The protocol does not provide any means to distinguish between device-specific read and write commands. This makes it impossible for any SIS to block device-specific write commands without blocking read commands. Blocking device-specific commands would prevent IMS/AMS from displaying any status of device-specific commands.
-
The actual distribution and installation methods of Device Type Manager (DTM) software open the door to supply chain attacks, posing significant risks to IMS/AMS platforms. These platforms are trusted and can serve as launch points for device attacks.
Crucially, Project 12 concludes that the security environment is vulnerable to malicious attacks that may go undetected in practice, and extreme caution should be exercised before installing any software that may introduce malware into process control networks (PCN).
The report emphasizes: We cannot adequately assess the severity of this vulnerability.
On Cryptographic Technology Applications
Based on the issues mentioned above, it is natural to think that encrypted communication and identity authentication are the solutions to most problems. Some SIS solutions provide encrypted communication between IMS/AMS and SIS. This feature is typically disabled by default. Enabling optional encryption mechanisms significantly enhances cybersecurity and prevents password sniffing and Man-in-the-Middle attacks from non-IMS/AMS platforms. Enabling encrypted communication is not always straightforward.
Two methods of encrypted communication were considered: host-to-host encryption and application-to-application encryption. Project 12 demonstrated that when using host-level encryption, malware coexisting with IMS/AMS can craft and directly insert HART (or HART-wrapped) packets into the network stack. These packets are transmitted through the host-level encryption tunnel to the SIS. The SIS then decrypts and passes the attached HART command packets to the devices for execution.
Project 12 further demonstrated that when using application layer encryption, a trojan DTM DLL can be loaded into the IMS/AMS process space and used to invoke unauthorized device commands, which are transmitted to SIS through the application layer encryption tunnel. Similarly, the SIS decrypts the commands and passes them to the devices for execution.
In both host-level and application-level encryption, unauthorized changes are made at will, and no network monitoring system can see them unless that system can decrypt the network packets for inspection. This weakness indicates the need for multi-layered security design solutions.
Even so, the report still recommends encrypted communication between IMS/AMS and devices to prevent attacks on communication integrity and confidentiality.
If functional safety system solutions support it, use application-level encryption to prevent unauthorized changes by malware coexisting with IMS/AMS.
-
If functional safety system solutions support it, use application-level encryption to prevent unauthorized changes by malware coexisting with IMS/AMS.
-
If the security system only supports host-level encryption, use it to prevent attacks on the integrity and confidentiality of network-based communications.
-
Where possible, configure systems to always require encrypted sessions and use certificate-based mutual authentication to verify SIS and IMS/AMS.
-
If the security system does not support encrypted communication, consider using proxy solutions to establish a VPN between an authorized host and the safety instruments (if using SIS).
-
Encrypted communication complicates content-based network monitoring. If monitoring the content of communications is necessary, empty password encryption can be used to authenticate between SIS and IMS/AMS, protecting the integrity of network packets without encrypting the message content. With this configuration, attacks on communication confidentiality (including password interception) are possible, so other mitigation measures must be used.
Mitigation Recommendations
LOGIIC recommends developing a mitigation roadmap to reduce asset owners’ risks in the short, medium, and long term (Figure 2). Security system owners should immediately:
Figure 2 Project 12 Recommended Risk Mitigation Roadmap
-
Follow IEC61511-1 standards, requiring all SIS devices to have protection. Use hardware write protection switches on all devices that have them. Disable the switch only during maintenance.
-
Apply security best practices to IMS/AMS platforms to prevent attackers from exploiting the trust relationship between that platform and SIS. Use network isolation or host-based firewalls (e.g., Windows 10 Security Firewall) to prevent remote access.
-
Avoid using vendor DTMs in safety-critical applications whenever possible; instead, opt for Device Description (DD) files. If DTMs are currently in use, verify the lineage and integrity of all DTM files. Obtain DTM and DD files directly from the vendor while requesting cryptographic hashes of the relevant files to verify the integrity of all DTM and DD installers. Require vendors to sign all individual files. Verify the integrity of DTM and DD before installation on the IMS/AMS platform. Require all DTMs or DDs downloaded from the Internet to use HTTPS.
Based on the findings of Project 12, these mitigations will significantly reduce risks to functional safety systems. In the medium term, LOGIIC recommends that functional safety system owners:
Use SIS to mediate communication between IMS/AMS solutions and safety tools. Work with SIS vendors to identify and implement SIS-specific protective measures to reduce the available attack surface and thus reduce risk.
Implement a method to restrict allowed SIS network connections to only authorized hosts to prevent unauthorized hosts from making changes.
Encrypt communications between IMS/AMS and SIS where possible to avoid network-based attacks that steal passwords and alter device commands in transit.
Implement a robust monitoring system to detect and alert changes in devices and unexpected device statuses.
Utilize the findings of Project 12 to conduct consequence-based risk analyses for all operational safety systems to identify any residual risks not mitigated by applied countermeasures. Asset owners should identify and implement additional countermeasures based on risk to their operations.
Create a robust security policy for their systems. Operators should receive training on the policy and how to avoid inadvertently introducing malware into the environment.
Long-term fixes should address larger issues that require vendor product and industry-level changes. This includes implementing a secure HART-IP protocol, which is included in the HART Network Management Specification published in July 2020.
The full report includes additional findings and recommendations for asset owners, product suppliers, and standards organizations. By providing these project results, LOGIIC hopes to help improve the overall security posture of all ICS stakeholders.
References:
https://www.isa.org/standards-and-publications/isa-standards/logiic
https://isaorgwebsite.blob.core.windows.net/media/isa/media/pdf/logiic/logiic-project-12-final-report.pdf?_ga=2.48622565.21465235.1619595542-1010767051.1619595542
