Building a Resilient World:
The ISAGCA Blog

Welcome to the official blog of the ISA Global Cybersecurity Alliance (ISAGCA).

This blog covers topics on automation cybersecurity such as risk assessment, compliance, educational resources, and how to leverage the ISA/IEC 62443 series of standards.

The material and information contained on this website is for general information purposes only. ISAGCA blog posts may be authored by ISA staff and guest authors from the cybersecurity community. Views and opinions expressed by a guest author are solely their own, and do not necessarily represent those of ISA. Posts made by guest authors have been subject to peer review.

All Posts

LOGIIC 12 Report Provides Roadmap for Risk Mitigations

LOGIIC recently completed Project 12, Safety Instrumentation and Management, and posted the final report www.isa.org/standards-and-publications/isa-standards/logiic.  The report highlights numerous consequential and reoccurring exploitable weaknesses found during the project and provides a roadmap for the short-, mid-, and long-term risk mitigations.

Industrial Control Systems 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 inputs and controls to safety system function. Instruments have been modernized over time to provide smart features such as valve partial stroke testing.

The lack of security concepts 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.

Successfully demonstrated attacks used 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 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 lacks basic security concepts and does not include standardized 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. The IMS/AMS depends on reading values to update device status in the display.
  • The practiced method of distributing and installing device type manager (DTM) software opens the door to a supply chain attacks and poses significant risk to IMS/AMS platforms. These platforms are trusted and can be used as a launch point for device attacks that can negatively impact safety system function.

Because of this, we conclude that safety systems are vulnerable to malicious attacks that may be undetectable in practice. Extreme caution should be taken before introducing any software, which could insert malware into the process control environment. We cannot sufficiently emphasize the severity of this vulnerability.

We recommend a vulnerability mitigation roadmap of short-, mid-, and long-term actions. Short-term actions are things that asset owners can do immediately to reduce their exposure and risk. Mid-term actions are things that asset owners can do cooperatively with vendors. Long-term actions are things that standards bodies and vendors can do to improve the security of safety system products.

The full report may be downloaded here. 

LOGIIC is a collaboration of oil and natural gas companies and the U.S. Department of Homeland Security, Science and Technology Directorate (DHS S&T). We would like to thank DHS S&T for its leadership, vision, and commitment to enhancing ICS cybersecurity. We also acknowledge the numerous vendors who cooperated in this project and provided equipment and many staff hours. This project could not have been done without this support. Finally, we would like to thank the Project 12 test team, which included Dragos and Secrabus. These two organizations provided detailed technical analyses of safety system components that were critical to the success of this project.  Work performed by SRI International was funded under contract to DHS S&T.

Brian Peterson
Brian Peterson
Brian Peterson is an Information Risk Consultant who works for LOGIIC and other companies as a program and project manager. Mr. Peterson has been the project manager for LOGIIC for over 15 years. Mr. Peterson has 30 years of cybersecurity experience of IT systems, applications, and SCADA/DCS systems, such as those used in the oil and gas, and manufacturing sectors. In the last 20 years, he has concentrated on performing research of security technologies and to develop programs and implementation tools for Information Security, ICS Security, and other risk programs.

Related Posts

How to Secure Machine Learning Data

Data security is paramount in machine learning, where knowledge drives innovation and decision-making. Th...
Zac Amos Mar 12, 2024 11:10:47 AM

Fortifying Your Security Arsenal: A Strategic Approach to Safeguarding OT Security Assets from Adversarial Threats

Introduction Despite investing significant budgets and resources in security products and services. The c...
Mohannad AlRasan Mar 5, 2024 9:17:57 AM

Why Collaboration Is Essential for Cybersecurity Teams

Today’s cybersecurity workforce faces seemingly insurmountable workloads and increasing pressure to manag...
Zac Amos Feb 27, 2024 10:40:13 AM