Triton/TriSIS - In Search of its Twin

The recent discovery of ICS-specific malware which targets Schneider Electric's Triconex Safety Instrumented Systems (SIS) with demonstrated capability of modifying system logic/programing, should prompt us to ask, "What is missing here?" Is the malware known as either Triton or TRISIS really an isolated capability that only focuses on the safety system inside of a larger industrial process? Or is there a more nefarious 3D chess game in play here?

Triton/TRISIS uses a library of protocol calls to download instructions to the safety controller in order to exercise their own programming. Everyone is surprised that a threat actor would spend time to focus on developing a safety system capability attack capability. Safety products have historically been more isolated than the DCS at a plant/facility (this has been slowly changing as convergence initiatives have shared networks, workstations, instruments).

Context matters, why target an SIS controller? There are two primary impacts that can be achieved and shown in Figure 1 below: 1) triggering a safety shutdown by reducing thresholds, etc. and 2) to deny the SIS of shutting down a process during dangerous conditions. If we consider normal architectures and the challenges associated with access then you realize that the larger more accessible and flexible DCS would be an easier target to accomplish a process shutdown. In fact, a DCS offers far more attack options to accomplish a controlled shutdown of a process. This leads me to believe that the "power over the safety controller" was likely to be used to deny a safe shutdown vice simple process disruption.

Denying a safety shutdown can be used by an attacker in a more random fashion of hiding until the process itself would float out of safe conditions based on operations or events or it can be waiting for the attacker to use an enabling attack on the DCS. In our ICS Kill-Chain (see Figure 2 below) we categorize impacts/actions in three categories a) Enabling, b) Initiating, c) Supporting. I believe Triton/TRISIS was designed to be a 'Supporting Attack' as an amplifying attack module in a larger operation that would include a DCS-targeted enabling attack with supporting modules (e.g. spoofing, etc.).

This leads me to ask, where is Triton/TRISIS' DCS-focused twin? It is possible that the targeted facility was merely a test and development environment for Triton/TRISIS or it was an environment to test additional malware to include the twin (did the facility look beyond the SIS?). I believe the ICS community should be on watch for a sister capability that takes control of a DCS to drive a process into unsafe conditions. The combination of Triton/TRISIS and Capability-X would allow an attacker to drive a process into a hazardous state and achieve effects that range from equipment damage to release of materials/chemicals used in the process. I don't believe that opportunity (found access to a Schneider Electric Triconex) is enough to invest the resources and time to develop a one-off capability for process disruption. Access to the Triconex at the facility would indicate to me that the attacker could develop greater access to the DCS and other systems. Let's go back to the ICS Kill-Chain model and now ask where is the one-two punch that may justify this investment?

Michael Assante, Director of Industrials and Infrastructure and SANS ICS & SCADA Lead at SANS Institute

To view all upcoming SANS ICS courses and events, click here.

Free Stuff Reminder

• Download the "What Will Your Attack Look Like" poster here
• Get the latest ICS resources here
• Join the conversation in the ICS Community Forum where ICS professionals share lessons learned, ask questions and connect with others passionate about securing our critical infrastructure.