War is beginning.  Not in a galaxy far away, but to the industrial controls that make our life here on earth bearable.  Inside every electric utility, sewage processing site, nuclear plant, and other industrial sites there is a whole army of SCADA devices controlling and monitoring the ebb and flow power and filth.  But this army is weak and vulnerable.  Attacks on these systems can cripple vital infrastructure causing widespread damage.

The examples of this are plentiful.  In 2011 hackers were able to access critical pumps and cause damage at the City of South Houston’s water plant (read more).  Stuxnet, which grabbed headlines for a while was also a SCADA attack, although it is thought to have been designed to target Iranian nuclear plants.

While there is always a worry of zero day exploits and other widely publicized, sensational issues (like Stuxnet), many SCADA systems are vulnerable to more mundane and well-known vulnerabilities, exploits, and misconfiguration.  Compounding this problem is the aging systems that govern these SCADA devices.  In our work with SCADA systems, it is these basic weaknesses that make this environment so vulnerable.  Weaknesses such as:

  • Unpatched vulnerabilities, some of which are years old.
  • SCADA control software running on older, unsupported versions of Windows (like Windows 98!)
  • SCADA vendors who do not support patching systems
  • SCADA systems with direct Internet access, allowing for brute force attacks and drive-by exploit
  • Installation of unauthorized software on protected networks from users with local administrative rights.
  • Wireless access into SCADA networks, which facilitates brute force attacks
  • Network bridging, where the protected SCADA and corporate networks are interconnected to support some business function (such as a historical data reporting)
  • Lack of effective security controls, such as intrusion prevention or SIEM technologies, which can detect and block attacks

So what’s the worst that can happen? The news stories are really only the tip of the iceberg.  For every story that is public, there are plenty more that never make it to the light of day.  Having worked with SCADA systems for a while, the threats are very real:

  • The intruder can destroy equipment by causing it to operate beyond its ability or rated specifications.
  • Open or close control valves, cutting off coolant to equipment or releasing a toxic substance.
  • Change the HMI (Human Machine Interface) to create the opposite effect of the desired reaction to a control input – turning off a control when the operator thinks they are turning it on or giving incorrect readings lulling them into a false sense that the environment is operating normally.
  • Embed malware and command and control systems which can create backdoors for exploit later.
  • Lock out users and prevent access when needed.
  • Gather sensitive data about systems for other criminal activity.

The ultimate problem is that these systems are vulnerable for a broad range of reasons. From mere vandalism to outright cyberwarfare, the threat landscape for SCADA is complex.

Compounding this problem is the ease at locating and identifying SCADA systems.  Using a tool called Shodan a quick search for the keyword “SCADA” returns 325 results for systems facing the Internet.  Searching for “Schneider”, a manufacturer of PLC’s (Programmable Logic Controllers), returns 793 results for possible devices exposed to the Internet. Finding, analyzing and attacking SCADA systems is, frankly, fairly easy – even for inexperienced hackers.

To make matters worse, there are extremely powerful hacking kits, such as Blacole which can be rented for as little as $50.00.  These kits contain an easy to use “point and click” interface to build, deploy and manage APT-style malware.

One more challenge is that many SCADA vendors are reliant on outdated, in some cases, archaic systems.  These vendors will often explicitly refuse to support patching and other system-level security controls.  This only underscores the importance of network-layer controls.

There is no doubt that the need to protect SCADA systems is critical.

Protecting SCADA Systems

Fortunately, there are many ways to defend SCADA systems using tried and true technologies and practices.  Some of the common steps we recommend include:

  • Remove and disallow local administrative rights for end users on SCADA systems
  • Remove all direct Internet access for SCADA systems
  • Remove all direct, remote control of SCADA systems. Require users to authenticate through secured access points, such as an SSL-VPN or similar technology
  • Segment and isolate SCADA networks from corporate networks
  • Implement a centralized patching system, that updates both the operating system and all third-party applications.
  • Upgrade to the latest operating system versions
  • Deploy intrusion detection/prevention to all SCADA networks
  • Conduct regular vulnerability scans of all SCADA systems and manage vulnerabilities accordingly
  • Deploy log monitoring (SIEM) technologies to centralize all security and event logs and provide a common platform for alerts and reporting
  • Conduct regular third-party penetration tests to provide an independent view of security effectiveness

Moreover, regulations such as NERC-CIP are compelling organizations to protect their SCADA assets.  While the war on industrial controls may seem unwinnable, in reality attackers can be thwarted.  With good technologies, good practices and diligent stewardship of security controls, industrial sites can protect themselves.

Conclusion

While the threat of SCADA attacks is very real, there are ample ways to protect these networks.  Most of these protections are not science fiction, but rather tried and true technologies that can deliver real, measurable protection.  For SCADA operators the message is clear, stay grounded and fight the good fight to protect the systems and keep civilization running…for great justice.

Anitian – Intelligent Information Security. For more information please visit www.anitian.com

Share This
%d bloggers like this: