Experiment Simulated Attacks On Natural Gas Plant

An experiment conducted by ICS/SCADA security experts reveals how utilities could spot malware and cyberattacks on their automation environments on the fly merely by continuously monitoring the customarily predictable behaviors of those networks and systems.

ICS/SCADA automation networks -- unlike typical IT networks -- operate in predictable bandwidth usage, traffic patterns, and CPU usage, for example, so any anomalies or changes to the norm indicate something's awry -- a malware infection, DDoS, brute-force attack, or even a random equipment failure, experts say.

Security experts from ICS/SCADA consulting and services firm TI Safe recently built a testbed of a simulated natural gas plant ICS/SCADA network to see whether continuous monitoring could flag attacks. The researchers captured the baselines, or quality-of-service parameters, of the simulated network, and waged denial-of-service, malware, ARP poisoning, and remote shell attacks on the simulated industrial network that included a programmable logic controller (PLC) and supervisory station system. They used open-source tools such as nmap to watch for any uncharacteristic activity or behaviors of the systems, and spotted blatant changes when the attacks hit.

They got some dramatic results: Their nmap scans, for instance, displayed a marked spike in incoming and outgoing traffic with the PLC. Overall, they found, continuous behavior monitoring was more effective than traditional signature-based defenses.

"We infected machines in the environment and made some errors in the switch ... to give us evidence on how it would report switch failure and malware infection," says Marcelo Branquinho, executive director at TI Safe, who worked on the experiment.

[Test network aims to simulate real-world effects of attacks on critical infrastructure to help power plants and other operators better lock down their environments. See SCADA 'Sandbox' Tests Real-World Impact Of Cyberattacks On Critical Infrastructure.]

In a white paper recently published on their research, Branquinho and Jan Seidl included graphical data generated by the open-source Zabbix monitoring tool that shows obvious and unusual traffic spikes detected by their nmap open-source scanner when rogue traffic was sent to the PLC. "In a normal situation, nothing happens -- there's a straight line" for the traffic, Branquinho says. "When something goes wrong, you have some spikes."

The testbed included a Wago 741-800 PLC and some hardware simulating an industrial natural gas plant using a TofinoScada Security Simulator, a Windows 7-based supervisory station, a Debian Linux 6-based monitoring server, two virtual machines, and a Debian Linux 6 machine Modbus traffic sniffer server. The Zabbix monitoring software ran on Debian Linux with MySQL 5.1 as the back-end.

The "attacker" machine was a Linux-based HP laptop that unleashed ICMP flood denial-of-service attacks, remote access shell exploits via Metasploit Meterpreter, and Address Resolution Protocol (ARP) poisoning attacks.

"Once the irregular network traffic has been captured and analyzed by the monitoring software, the security team will use the data dumps to assess what is really happening on the network. The anomalous traffic is compared to traffic from baseline to provide important information about which servers (or equipments) are generating the anomalous traffic, ports and services that may be involved, and which network protocols are being used," the researchers wrote in their report.

Jim Butterworth, CSO at HBGary, says he believes the continuous monitoring approach makes sense for the ICS/SCADA environment. "Their experiment was very controlled, in a small sandbox, but I think it could scale" to large infrastructures, he says. "It's very feasible to normalize the behavior of a Windows box," for example, because its purpose would be very specific in a process control network, he says. "Getting to the norm [in these environments] completely makes sense, even down to the Modbus traffic."

This approach could help catch a worm attack like Stuxnet, too: The peer-to-peer communication method used in these types of attacks would be spotted, Branquinho says. An infection would show response time changes uncharacteristic of the network, for example. "We're talking about real-time networks with a very fixed response time. If a device responds in 10 seconds and then starts to respond in 20 seconds, something is happening to it," he says.

Stuxnet appeared to have sabotaged the supervisory screen used by the operator watching the centrifuges, so the attack was masked, notes Branquinho. "If they simply trusted the supervisory screen ... you wouldn't see the attack happening because you wouldn't know that the speed of centrifuges had changed," he says. Monitoring the parameters of the actual devices and their traffic would flag that something had gone wrong, according to Branquinho.

Most automation network operators running firewalls and intrusion prevention systems aren't inspecting their logs today, he says. "People should have some tools to integrate all of the logs and to generate human alerts," he says.

Open-source tools are an option for building out a continuous monitoring environment in ICS/SCADA today, the researchers say in their report. "For industrial automation environments, with their unusual protocols, there are few commercial tools available for purchase, and the customization of an open source tool that fits the monitoring needs should be considered."

But it's not just a matter of downloading and firing up an open-source monitoring tool. "You've got to have some knowledge to understand what could happen to the environment. Which risks is the environment exposed to?" Branquinho says.

And for some highly regulated utilities, dropping in an open-source tool isn't a given, warns HBGary's Butterworth. "Everything is so controlled," he says, so not all tools would be authorized under regulatory rules.

The full report on TI Safe's experiment is available here.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.