Tag Archives: Industrial Control Systems

Triton: Dangerous and Puzzling – Part I

4 March 2018

Jim Finkle’s report ‘Hackers halt plant operations in watershed cyber attack’ (1) published on December 14th, 2017 on Reuters made me curious and nervous at the same time.

The report deals with a cyber-attack on Safety Instrumented Systems (SIS). SIS work independently of the Process Control Systems (PCS). They guarantee that the industrial process, e.g. a reactor or a cracker, can be safely shutdown if the PCS can no longer control the process. Since compromising an SIS may cause significant negative effects on people and environment, the most important task in Production IT Security is to prevent cyber-attacks on SIS.

Although the attack was intensively discussed in the media and by security researchers many questions are still open. With this three-part blog series I like to examine some details more closely. A detailed attack analysis gives IT security strategists the chance to derive improved means for protection of SIS.

Part I: Some facts about the Triton attack

Malware naming

FireEye named the malware TRITON (2). Triton is an attack framework created to interact with Schneider Electric Triconex Safety Instrumented Systems. Other sources name the malware TRISIS (3) or HATMAN (4).

Indicators of Compromise

“In the incident, hackers used sophisticated malware to take remote control of a workstation running a Schneider Electric Triconex safety shutdown system, then sought to reprogram controllers used to identify safety issues. Some controllers entered a fail safe mode, which caused related processes to shut down and caused the plant to identify the attack, FireEye said.” (1)

From the FireEye report, we learn: “The attacker gained remote access to an SIS engineering station and deployed the TRITON attack framework to reprogram the SIS controllers. During the incident, some SIS controllers entered a failed safe state, which automatically shutdown the industrial process and prompted the asset owner to initiate an investigation. The investigation found that the SIS controllers initiated a safe shutdown when application code between redundant processing units failed a validation check — resulting in an MP diagnostic failure message.” (2)

With this, the IoC was: A production process was shutdown by the SIS although no indicators for a failure condition were signaled by the PCS.

Preconditions for a successful attack

At least the SIS Engineering Station must be accessible from the network. The FireEye (2) and Dragos (3) report confirmed that this was the case.

The Triconex memory protection key switch must be left in Program mode long enough to allow the attacker to run the attack. The FireEye (2) report confirmed that this was the case:

“The attacker could have caused a process shutdown by issuing a halt command or intentionally uploading flawed code to the SIS controller to cause it to fail. Instead, the attacker made several attempts over a period of time to develop and deliver functioning control logic for the SIS controllers in this target environment. While these attempts appear to have failed due one of the attack scripts’ conditional checks, the attacker persisted with their efforts.”

The code is publicly available from GitHub. (5)

Threat Actor

From the FireEye (2) and Dragos (3) analysis it is clear, that this was a sophisticated attack. In-depth knowledge of Schneider Electric Triconex SIS and network intrusion technology is required to perform such kind of attack and stay undetected for a while. This indicates a state-sponsored threat actor.

What does this really mean?

Production Network Reference Architecture

Production Network Reference Architecture

The cyber attacker worked his way through the business DMZ, the business network, the production DMZ and the production partition 1 to the SIS engineering station in zone 2 of production partition 2, without being noticed by any security device, SIEM or endpoint protection. That is truly amazing.

It seems like some basic protective measures were either not fully in place or misconfigured or no one checked the logs regarding IoC and IoA.

 

From my point of view this sounds very unlikely and mysterious. I will present some alternative access scenarios in part II.

Have a good weekend.


  1. Finkle J. Hackers halt plant operations in watershed cyber attack. Reuters [Internet]. 2018 Dec 14 [cited 2018 Feb 4]; Available from: https://www.reuters.com/article/us-cyber-infrastructure-attack/hackers-shut-down-infrastructure-safety-system-in-attack-fireeye-idUSKBN1E8271

  2. Caban D, Krotofil M, Scali D, Brubacker N, Glyer C, Johnson B. Attackers Deploy New ICS Attack Framework “TRITON” and Cause Operational Disruption to Critical Infrastructure [Internet]. FireEye Threat Research Blog. 2017 [cited 2018 Feb 12]. Available from: https://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-ics-attack-framework-triton.html

  3. TRISIS-01.pdf [Internet]. [cited 2018 Mar 3]. Available from: https://dragos.com/blog/trisis/TRISIS-01.pdf

  4. MAR-17-352-01 HatMan—Safety System Targeted Malware_S508C.pdf [Internet]. [cited 2018 Mar 3]. Available from: https://ics-cert.us-cert.gov/sites/default/files/documents/MAR-17-352-01%20HatMan%E2%80%94Safety%20System%20Targeted%20Malware_S508C.pdf

  5. ICSrepo. TRISIS-TRITON-HATMAN: Repository containting original and decompiled files of TRISIS/TRITON/HATMAN malware [Internet]. 2018 [cited 2018 Feb 5]. Available from: https://github.com/ICSrepo/TRISIS-TRITON-HATMAN

Prevention before Detection in Industrial IT

1 May 2017

Currently, I’m working on a paper for safety engineers about cyber security requirements for Safety Instrumented Systems (SIS). For preparation I examined some of the existing publications from other European countries, e.g. the paper ‘Cyber Security for Industrial Automation and Control Systems (IACS)‘ from the British Health and Safety Executive (HSE).

In the chapter ‘Note 5 – Define and Implement Countermeasures’ one reads:

A hierarchical approach should be adopted, for example prioritising implementation of measures such as inherent resilience, and prevention (e.g. physical security controls, authorisation and authentication) over other measures for detection.

That is diametrically opposed the Gartner’s advice ‘Shift Cybersecurity Investment to Detection and Response’. Gartner’s Sid Deshpande said in an interview:

Gartner is now recommending to companies that they shift their security spending to have at least 60 percent of their security budget to be spent on detection and response, up from 10- to-15 percent today.

I think Gartner’s advice needs to be seen in the context of the industry where one works. IT security deals with Confidentiality, Integrity, and Availability (the CIA) issues. Every industry has specific requirements regarding CIA issues. For example, integrity of product and production plays a higher role in pharmaceutical production than in the process industry. This is be shown very well with a spider diagram:

CIA-Diamond

CIA-Diamond. Click to enlarge.

In general, Gartner’s advice is useful where we have a high demand for addressing confidentiality issues. In industries, where integrity plays a major role, the Gartner advice is less useful because you cannot wait until a customer or the FDA detects that a drug has a wrong composition.

CIAS-Diamond

CIAS-Diamond. Click to enlarge.

Safety is a game changer. As soon as we face medium or high safety requirements, Gartner’s advice is counterproductive.

Have a great week.

Rethinking the Patch Strategy in the ICS Domain

5 February 2017

In the past weeks I reviewed several drafts on Industrial Control System (ICS) security. Although of limited value in the ICS Domain, patching and malware protection are key issues of all drafts.

Especially the patch process, which works moderately satisfying in the Office-IT domain, cannot be directly applied to ICS systems because ICS systems cannot be just rebooted to apply the patch.

Industrial control system patch cycle

Industrial control system patch cycle

To reboot an ICS system a shutdown of the process is required. In the worst case, the operators have to wait several weeks or months for the next scheduled plant maintenance to implement the patch and to reboot the ICS. During this time the ICS is more vulnerable against the threats mitigated by the patch.

With this, we have to design and operate our ICS systems and networks such, that they are resilient against cyber-attacks during the time until the next scheduled maintenance.

The following are examples of technical measures:

  • Isolation of ICS and SCADA systems in secured network zones inside the production network and strict flow control across security devices between the zones are basic design principles for creating robust systems.
  • A secure remote maintenance solution which is completely under control of the plant operators, ideally a rendezvous solution to keep the external service provider in the DMZ.
  • A secure and controlled remote access solution for plant operators.
  • Strict Network Access Control in the entire production network to increase resilience against attackers from internal.
  • No Internet access and personal email in the entire production network. This is a quick win! The same holds for the deactivation of USB disk devices.

Have a good weekend.