Usability is key: Radiflow’s IEPP vs. the HatMan (aka Trisis, Triton) malware

By Yehonatan Kfir, CTO, Radiflow

On Dec 18, 2017, ICS-CERT published a report on a new ICS-specific malware dubbed HatMan (aka TRISIS or TRITON.) The source code of the malware was recently published for anyone to download and use.

HatMan was designed to disrupt the operation of Triconex safety controllers, by allowing attackers to disable, inhibit, or modify the failsafe procedures of controller processes.

This is done by modifying the controller’s in-memory firmware to add additional programmed functionality. The new functionality provides the attacker access to read and/or modify content on the controller’s memory and execute malicious code using custom network packets.

HatMan consists of two components:

• a PC-based module for communicating with the safety controller, and
• a malicious binary code downloaded to and stored in the controller’s memory.

[inject id=’code-47fd23f73a9caecab1e206306adae7f9′]

Mitigation strategies recommended by ICS-CERT to protect Triconex devices include:

1. Disconnection from any non-essential networks
2. Elimination of possible sources of malware infiltration, e.g. the use of removable media to transfer programs
3. Regular updating of all workstations
4. Making sure the device’s physical key isn’t set to “PROGRAM” unless necessary (it cannot be programmed in the “RUN” or “REMOTE” positions)

Of these strategies, the first three would be—and should be—considered “common sense” procedures. As for #4, it would seem like a no-brainer to enact a procedure, whereas controller keys are not t

o be set to “PROGRAM” unless necessary, and instead should be set to “RUN” which would prevent receiving new firmware, thus preventing a HatMan attack.

And yet, operators often leave the key in the “PROGRAM” position, which allows their engineers to make changes to controllers remotely without having to physically access them.

Unfortunately, this is not surprising, considering the operational and financial constraints that operators face, and how they prioritize them. In this case, even though the mechanism for preventing the next potentially-catastrophic attack is pre-installed in the controller, operators still do not deem cybersecurity as a high-enough priority, and instead focus almost solely on operational efficiency.

In my opinion, this is one of the issues that the security industry needs to resolve by way of accepting the fact that operators set their priorities “irresponsibly”. Simply put, we should stop acting surprised when users choose ease of operation over security, and design solutions that don’t require them to choose between the two.

This dilemma was part of the rationale behind Radiflow’s Industrial End-Point Protection (IEPP) solution. In this solution, the Radiflow security gateway blocks all control commands from reaching the controllers, so no user or PC can change the configuration of the controller. When a configuration change is needed, the operator needs to approve such a change session and the user needs to be authenticated. Upon authorization he or she will be able to execute specific authorized configuration commands.

Radiflow’s IEPP implements a unique control-plane firewall, capable of recognizing the specific control user’s actions. By using a patented statefull method combined with deep-packet-inspection, the IEPP is able to monitor user behavior and grant rights granularly, for specific configuration changes during specific sessions. What’s more, the IEPP is able to prevent malware from downloading malicious logic to the controllers during IEPP-authenticated configuration windows. The user authentication process itself employs systems that are readily available today.

The IEPP has a “controller-like” interface, using data-plane OT protocols. This interface allows the operations team to use their SCADA server to control the IEPP gateway just like any other controller: enable changes to the controller logic at specific time-slots, get notifications of such changes, and/or prevent it from opening at all.

Another advantage of the IEPP is its smooth integration with traditional IT and OT systems. Whenever the gateway is opened for configuration changes, the IT security team will receive a detailed description of the event in their SIEM. Together, the two interfaces allow both the IT and operations teams to fully understand and control the configuration windows on the controllers.

The bottom line is that the IEPP solution provides very robust security without requiring the operator to make operational changes, or sacrifice the efficiency of operational processes.

Is this solution better than a physical key on the controller? Well… No and Yes.

No, because a physical key cannot be hacked remotely, so only an insider can change its state. On the other hand, on balance I’d have to say yes. Because if the physical key is often left in PROGRAM mode it delivers no security at all, and worse, it provides an illusion of security.

It’s time that all of us in the cybersecurity industry recalibrate our expectations from users, and start developing solutions that match the way users really operate. Developing excellent solutions that users choose not to use correctly is definitely not the right way to go.