Intelligent instruments, particularly sensors which support the Highway Addressable Remote Transducer (HART) protocol, are susceptible to attacks and even unintentional misconfiguration which may cause the analog readings to be inaccurate or misleading.
The HART communication protocol is widely used in process control. It allows users to obtain additional information from an instrument besides its primary data point, and lets users save on wiring costs by re-using existing wiring from legacy analog instruments. This protocol, however, has several features that can make an instrument’s analog values untrustworthy. These methods are outlined below.
Engineers who write safety logic can use Safety Instrument Systems (SIS) or Programmable Logic Controller (PLC) features to protect against these untrustworthy analog values. We refer to these as ‘device state’ attacks, which are outlined in a recent white paper written by the Linking the Oil and Gas Industry to Improve Cybersecurity (LOGIIC) program. This blog shares Dragos’s research on how to protect SISs and PLCs against these types of attacks.
Analysis of the HART Protocol
We begin with an analysis of the HART protocol, highlighting some of its shortcomings, and provide recommended mitigations to defend against an attack.
The HART protocol is a hybrid analog and digital industrial automation open protocol. Its most notable advantage is that it can communicate over legacy 4–20 mA analog instrumentation current loops, re-using the pair of wires used by analog-only instruments. Because of the large installed base of 4–20 mA systems throughout the world, the HART protocol is one of the most popular industrial protocols in use today for instrumentation. It allows users to obtain additional information from an instrument, without needing to rewire a plant.
However, this protocol has several features that can make an instrument’s analog values untrustworthy. Sensors may be placed into several modes (including ‘fixed current’ and ‘loop current’ modes, for example) that can render the analog signal that they provide inaccurate. These two modes are responsible for six key attack effects and are the only two known attack effects which can universally blind the SIS to process state, as was shown in LOGIIC’s Project 12 Safety Instrumentation Report.
Engineers who write safety logic can use these features to protect against these attacks. In fact, the SIS remains one of the best places to implement this sort of detection.
Advantages of HART-Aware I/O Cards
Some SIS and PLCs use I/O cards that are HART-aware. Others do not and that can lead to real problems. HART-aware cards can make HART data accessible to the end user. Safety or other logic programs can then be written which will act if key, risky, safety instrument changes are made. Making effective use of the data will vary between SIS and add-on card vendors.
In the example provided below, we cover one specific model in using the accessible HART data in securing your SISs or PLCs. However, end users can apply this technique to other SIS with the help of their vendor documentation. Doing this can be a bit of a mixed bag: the I/O modules absolutely must have HART protocol support as mentioned above. The card or SIS vendor must also make data elements available for a user’s logic programs. Some cards may only allow ‘pass-through’ commands which originate from an Instrument Management System (IMS) (or an adversary) and may not allow data to be used within the control logic itself. This situation is just as dangerous, or may be even more dangerous, than an I/O card with no HART awareness at all. When in doubt, be sure to talk to your vendor.
How to Secure SISs and PLCs from ‘Device State’ Attacks
IMS Communications Diagram Example
Here is a solid example to drive home a few points. First let us look at how the SIS and its connected instrumentation fit with typical communication paths:
In the above example, we have an IMS with a lot of choices for how to talk to an instrument. All these paths will not be present on a ‘typical’ network, but this is how Dragos runs its lab.
- Path 1: Using our SIS example, the IMS may speak to the SIS protocol (often using a vendor-specific/proprietary wrapper, but occasionally devices support HART-IP) and to the Instrument using path 1. Bear in mind that if the SIS uses a regular analog input card without HART capability, then this communication path does not exist and the SIS cannot implement the mitigations discussed in this blog post.
- Path 2: The IMS may also speak to a multiplexer over a ‘virtual com port’ (again, this is a proprietary wrapper, dependent upon the vendor of the ethernet-to-serial gateway).
- Path 3: The IMS may also use HART-IP, or a proprietary wrapper protocol, to a WirelessHART Gateway. The gateway would then send data to a WirelessHART Adapter, which would finally relay the query or command to the instrument.
- Path 4: Finally, a local user may use a handheld field programming or calibration tool to change instrument configuration. This mechanism would not produce any network traffic at all.
Any of these communications channels may be used to initiate state attacks. This is specifically true of the SIS-blinding attacks around setting the instrument’s output current states. Spotting this kind of attack is our goal.
Three of the communications paths in the above example are proprietary. We consider HART-IP a proprietary protocol – while there are public dissectors for this protocol, the open implementations are not complete and there are conditions where identifying the key commands via that protocol simply will not work. The fourth path is not a true network path so it cannot be readily monitored.
Multiple paths, each with their own monitoring difficulties, makes it quite hard to tell when an attack is occurring. Each of the 4 communications paths could be used to initiate a state attack but monitoring for the use of the offending commands is difficult. Without custom network parsers for each of the communication channels, we have no visibility into potential attacks.
We can see that monitoring HART is painful (we handle many cases in the Dragos Platform). And, even if we are monitoring the instrument for changes, a cybersecurity platform like ours cannot immediately inform the safety system of a problem: first, the event must go through security staff, be properly escalated, and make its way to engineers. All of this takes time. Time is something that we may not have if safety instruments are being modified in a live environment. The detections and logs will be invaluable for root cause analysis and forensics, but to be proactive what is a defender to do?
Applying Control Logic to Detect & Respond to Attacks
Below we will demonstrate how to apply control logic as a mechanism for detecting, and responding to, these classes of attack. In this example we use an inexpensive SIS. This model controller has a third-party series of analog I/O cards which support the HART protocol. For the uninitiated to HART or to PLC internals, the documentation of these cards can be obtuse, but here is a good description of how the card and its related software functions:
- The card automatically polls each HART loop for devices using the HART protocol. For devices found on the loop (note that only one instrument per loop is supported!), it automatically populates a set of PLC global variables including a lot of digital data. The card does so by issuing several HART “universal” commands, which are commands which all devices must support. The card automatically copies and scales response data into the PLC variables. The variables are automagically populated in the PLC variable list using the card’s configuration import in the logic software. This cannot be configured by the end user. The automatic polling can be disabled by the user, but if the automatic polling is enabled, the variables come for free, and it is all-or-nothing for memory usage.
- The card automatically places the analog 4-20mA signal into PLC variables (for an input channel), or outputs a 4-20mA signal from PLC variables (for an output channel).
- The card manufacturer helpfully released a ladder logic project. The logic project contains around 40 rungs, which function to allow ‘pass-through’ commands to the instruments. These rungs take data, which is exposed via the PLC’s programming protocol using a tunneling wrapper, and copy the requests and responses such that a network connected IMS can communicate directly to the instrumentation.
- The card manufacturer also helpfully produced a DTM (Device Type Manager) driver, so that any 3rd-party instrument manager software which uses DTMs may have a communication shim for talking to instruments which are connected to the PLC/SIS.
Steps 3 and 4 are totally optional for anyone to use. Without loading the logic into the PLC, or using the DTM, the PLC will still function and will still poll instruments for HART data – however, there will be no ability to remotely manage the instruments using path 1 in our communications paths diagram. Instead, we would need one of the other communication paths for remote management, such as a HART multiplexer or WirelessHART system.
So, we see how our SIS will behave with our instruments. Now let us see how to implement a defense.
A Logical Argument, or an Argument for Logic
If we go back to our HART I/O card description, step 1 provides the hint of a handy solution. The HART card automatically populates some instrument variables for us, which are placed in globally accessible program data on the controller. The card vendor is even kind enough to provide a description of the HART variables, sufficient to understand the definition of some key fields.
One of these fields is a Device Status bitfield. This bitfield is transmitted with each response from an instrument and provides a few on/off status notifications for various instrument configurations. Going back to the initial problem, one of the major instrument findings was that sensors often support a ‘fixed’ and ‘loop’ current mode.
These modes cause a sensor to output either a user-defined current (for ‘fixed’ mode) or 4mA current (for ‘loop’ mode). Both have a perfectly legitimate purpose: ‘fixed’ mode may be used for calibrating instruments, while ‘loop’ mode should be used when operating instruments in a purely digital configuration, such as when multiple instruments are attached to one current loop.
When either of these modes is enabled, the instrument will emit a digital status bit in the response message, indicating that its analog signal is not to be trusted. This is stored in the HART response message ‘device status’ field, bit 4. We can write some defensive logic quite easily, as shown below:
The above logic rung compares the digital device status ‘fixed current mode’ bit on a single instrument using the mask 0b00001000. The ‘1’ bit is placed in the mask for the device status: when that particular bit is ‘1’, it means that the device is emitting a fixed current and not an analog value based on its measurement.
If the instrument is ever found to be in fixed current mode, the logic will initiate a safety trip. We are reacting to the attack (fixed or loop current modes) using HART data – if the instrument in question is truly important for plant function, and the instrument is no longer providing accurate analog data, then we shut down the process so that engineers can investigate how the instrument was reconfigured.
It really is that easy, at least with this particular hardware, and again it will provide a reaction to the spoofed signal attacks outlined in the Project 12’s “false reading” and “commissioning mode” findings under Section 4.2.4 of that report. This is the case with most hardware that is typically used in this type of environment.
Of course, whether you really want to shut down a whole plant in this case will require some engineering thought. It could be that some subset of instruments will undergo calibration while the plant is running, and thus more expansive logic requiring particular sets of instruments to be in this mode might be needed to prevent unnecessary tripping. Note that during the LOGIIC testing, no mechanism of circumventing this HART status bit was ever found. So, while instrument security is not great, there are data elements provided by the instrument which could not be forged during the test. This particular data element is one.
If your add-on card or SIS vendor isn’t populating these variables automatically, implementation will be a lot harder, but hopefully still possible. In such a case, more complicated logic may be necessary to populate the instrument variables yourself. This will involve writing logic to transmit a status request from the instrument and then parsing the result. This latter method is actually required to detect Project 12’s “digital mode” finding for actuators, which unfortunately does not set an easy-to-use HART status bit in the same manner that sensors do.
Conclusion: With Great Possibility Comes Great Nuance
All of this is great but again, it depends upon the premise that the SIS analog card can speak HART, and if it has a configuration which lets us use variables within the programmable logic in the first place. If this is not the case, then in our example architecture above, we have many proprietary-wrapped protocol paths to manage instruments, but literally no way to monitor them from the SIS.
This translates to some danger: if your SIS has HART instruments attached but has no HART ‘awareness’ – for example you are using purely analog I/O modules – then these additional, proprietary, attack paths can be used to totally blind the SIS to instrumentation status. Meaning, if you are using HART instruments either do not allow them to be remotely managed, or use HART-aware I/O modules and take some logical precautions.
In a perfect world, four things would happen to improve the security of safety instrumentation:
- SIS vendors and HART add-on card makers would expose key HART data in a way that is easy to use in programmable logic. Some vendors are already doing this, and this makes reaction simple.
- The HART standards body would augment the standard to show when actuators are placed into a digital-response mode.
- Instrument vendors would publish the details about their digital mode proprietary commands, specifically how to tell that the instrument is in digital-response mode.
- Safety engineers would share code and techniques to monitor for these classes of attack for the various SIS families – which, we hope to submit into the fantastic ISA Top 20 PLC Programming Techniques.
Ready to put your insights into action?
Take the next steps and contact our team today.