Hi folks,
This is a short article I wrote for InfoSecIsland. Normally I wouldn’t post something like this on a political blog, but the conversations here on Stuxnet were as intelligent as any other. This was written with my Day Job hat on but is not a pitch for AlienVault specifically – any SIEM will do – but since AlienVault has the Open Source SIEM the topic cannot be discussed without bringing them up anyway.
Background
Control System networks are electronic systems for controlling the physical world. These systems are deployed in virtually every aspect of modern life from power grids to transportation, manufacturing, agriculture, building control and more. Since 1979 these systems have been becoming increasingly similar to the Information Technology (IT) networks which have developed over that time. Today, most Control System networks are based on the same TCP/IP protocols that run on the Internet and use computer systems which are vulnerable to the same attacks which plague business and home users.
In June of 2010, the first malware specifically designed to attack Control System networks was found in the wild. Stuxnet, a complex worm that targets Siemens’ WinCC Control System server software, uses a vulnerability involving USB thumb drives to compromise the Windows operating system of WinCC servers. Once installed, Stuxnet subverts the WinCC software itself and then pushes altered software to the Programmable Logic Controllers (PLCs) that control very high speed motors. Since the motors Stuxnet is designed to target operate at between 807 Hz and 1210 Hz the popular conclusion that this worm was targeted at the nuclear centrifuge installation at Natanz, Iran, is generally supportable (the United States restricts exports of similar motors above 600Hz due to their use in refining nuclear fuel).
Regardless of the target, Stuxnet defines a pivotal point in time. Concerns about the vulnerability of control system networks crystallized at the moment Stuxnet was identified. Going forward the questions now revolve around, “How soon?” and, “How often?” rather than “What if?”
As we look at our responses to Stuxnet we are well served to be extremely pragmatic about our choices. Solving the numerous issues involving the security of individual devices and processes has caught many industry experts in its many-faceted trap. It is pragmatically unlikely that the answer to solving Critical Infrastructure security concerns will be found through the gradual hardening of individual components of the problem. A more broadly adoptable and timely solution is required.
A Probable Solution
The nature of Control Systems is Reliability. The implications of this implacable fact have stymied IT Security experts’ attempts to translate the Best Practices of information security into actionable guidance for their Control System peers. Understanding these implications is the key to determining how best to address the issue of securing these systems.
Control System networks architecturally consist of two primary components that can be classified as “Actuators” – where electronic command translate into physical action – and “Controllers” that tell the Actuators what to do. The Actuators in most cases today are PLCs (Programmable Logic Controllers) connected to some sort of switch or motor. The Controllers in most cases today are Intel computers running Microsoft Windows and some sort of Industrial Control software. Vulnerabilities in the operating system can (and in the case of Stuxnet, did) lead to a compromise of the Controller and the Industrial Control software running on it, and therefore to a compromise of the physical process itself. The Control software itself may (and in the case of Stuxnet, did) have additional vulnerabilities to compound the problem.
The common argument among industry experts is that Controllers need to be made more secure. Common methods suggested include applying security patches from the Operating System vendor and installing other security software such as Antivirus or Host Intrusion Detection applications on these Controllers. While this would seem an obvious approach to mitigate risk this approach has not been adopted in any measurable amount. While the security benefits of taking this approach – including the likely mitigation of Stuxnet itself – would to the casual observer appear to be sufficient to motivate Control System owners and operators to follow this advice, the decrease in reliability related to the ongoing deployment of relatively untested software patches or relatively unknown host security software has been perceived as a greater threat than the likelihood of the attacks they are meant to address. Given that the vast majority of these systems have not suffered significant downtime due to cyber attack over previous years this supposition has – at least for now – been proven correct.
In the face of a post-Stuxnet future, many are correctly pointing to the need to secure the Controllers and Actuators themselves. Certainly, improving the security of these devices in any form is a step in a positive direction. However, two critical questions need to be asked if this path is going to be considered as the primary means for addressing the vulnerabilities throughout our critical infrastructure:
“How do we secure all of these devices?”
and
“When will we know a device is secure?”
The first of these questions speaks to the logistical issue of moving an entire global industry from a given set of practices to a new set. Experience shows that in any case a significant change in process takes years to fully propagate throughout massive human infrastructures such as the one under discussion. Additionally, as stated above, the balancing of risks to business and operational processes in the Control System industry adds further barriers to executing on the specific tasks associated with applying remedies to the situation via the Controllers and Actuators themselves. Even assuming it will become possible to influence all Control System operators to implement the routine of testing and applying software patches and adding host security tools to their production systems, it is only realistic to assume that it will take many years to achieve this state.
Putting aside all of those issues and assuming that every the Control Systems in the world was diligently applying software patches as quickly as possible and deploying Controllers with security tools built in, the second question should still be a major concern. How will we know that any device is secure? Even in IT environments where significant effort has been expended to secure hosts and systems we suffer continuous breaches. So, if the end result of many years of effort to secure devices on Control System networks results in nothing more than an at-best moderate increase in reliable security, this may be fairly summarized as an unsuccessful approach.
Monitoring Control System networks, however, is an approach that can be deployed today with little to no decrease in the reliability of the subject control system. Monitoring is also an approach that can scale from “no-touch” virtually risk-free solutions to as deeply integrated with the Control System process as the operators choose. Freely available tools – such as AlienVault’s OSSIM – can be used to establish monitoring practices on Control System networks without interfering with process reliability, providing dramatically increased ability to identify and respond to attempted attacks. Commercial solutions – including AlienVault’s Unified SIEM – can scale up to any size necessary as well as monitoring to any depth required.
SIEM – Security Information and Event Management – technologies are systems which at the most basic level consume event information from devices and applications on a network. The deployment of SIEM technologies during the past decade on IT networks has both grown in complexity to include integrations with more complex systems as well as broadened to include large numbers of small-to-medium organizations. The maturity of technologies and practices in the SIEM space indicate that their applicability to the issue of security on Control System networks would be a pragmatic and probable approach to achieving real gains. Examples such as Metro Madrid – the world’s sixth-largest urban transportation system – demonstrate how a facility in the most critical environment can use Open Source SIEM tools to make immediate gains and then evolve into a full commercial SIEM implementation.
For the purpose of illustrating the capabilities of SIEM technologies in this realm, we will look at how the AlienVault Unified SIEM would detect and defeat the Stuxnet worm in various representative scenarios.
A No-Touch Solution
The most readily adoptable solution will be one that has little to no impact on the reliability of the Control System it is implemented on. An AlienVault Unified SIEM (commercial) or AlienVault OSSIM (open source) installed on a Control System network could in the least-invasive scenario be installed with a single Ethernet connection to a network switch located between the Controllers and Actuators. The SIEM system would monitor and model traffic on the network, creating a baseline of activity against which anomalous behavior will stand out. The AlienVault SIEM will also sniff traffic with Intrusion Detection System (IDS) technology to detect attack traffic crossing the network. In this configuration, the Stuxnet virus would be detected after it has infected the WinCC server, as it scanned the network for additional hosts to infect. This behavior would cause an alarm in the AlienVault SIEM console, contacting operations staff and allowing mitigation to begin immediately. The network traffic generated by Stuxnet would in no situation be expected to be seen on a Control System network, therefore the SIEM alarm would unambiguously prove that the Control System network has in fact been compromised.
AlienVault Unified SIEM or OSSIM could be deployed with more visibility without introducing significant unreliability into the Control System by allowing certain devices to provide it with log messages. Industrial Control System switches and routers tend to be DC-powered and ruggedized versions of the devices used for similar purposes on IT networks, and in many cases these devices are capable of sending syslog or other status messages to external devices. The Windows operating systems on Controllers is capable of either providing certain log information or allowing external systems to poll them for status information. An implementation where the AlienVault SIEM is configured to consume log messages from Controllers, switches and routers will be able to detect Stuxnet or a similar attack as it is attempting to compromise the Controller itself or as the compromised machine attempts to communicate across the network.
With a deployment of SIEM technologies even at this most basic and non-intrusive level, attackers would have to both compromise a host without creating any unique condition which would betray them and then execute the attack across the network without causing any anomalous network traffic. The Stuxnet worm would fail to defeat such a deployment and future attacks would have to have a much more sophisticated approach to have a reasonable chance of success.
A More-Touch Solution
The push for host security on Controllers is not misguided. These devices by their very nature rest at the center of all major threats to Control Systems. The resistance among the Control System community to host security software is not misplaced, either. There is a very real risk that host security software on a Controller might either erroneously block an necessary action or cause an unforeseen loss of function due to malfunction or configuration. A very small rate of occurrence of such incidents could quickly multiply the realized downtime of deployed Controllers and introduce both a financial as well as safety risk that may be at best unacceptable and at worst more of a threat than cyber attack itself.
There is a safer compromise between doing nothing to secure Controllers and instituting strict host security on them. Host IDS software such as that included with AlienVault Unified SIEM can be installed on Controllers in “listen only” mode without any ability to block or otherwise interfere with the Controller’s functions. A SIEM deployed on the Control System network would consume the event information from this HIDS software and any anomalous activity on the Controller – such as the permission escalation and file copying performed by Stuxnet – would trigger an alarm in the SIEM. Any loss of communication with the HIDS software would also trigger an alarm in the SIEM. The level of sophistication of the attackers and their knowledge of the specific network being attacked would have to be much higher than even the “No Touch” scenario described above to have a reasonable chance of success.
The final escalation of defense would be to introduce Intrusion Prevention System (IPS) technology inline between Controllers and Actuators. While this introduction of automated traffic-blocking capability may in most control system situations be seen as too high-risk, in scenarios such as Stuxnet is believed to be designed to attack – nuclear and other high-value sites – well-planned use of IPS might prove to be justifiable. AlienVault solutions include this functionality, other SIEM solutions can integrate with separate IPS tools.
In Summary
In the shadow of Stuxnet it is no longer diligent for Control System operators to put off addressing the issue of computer-based attacks on their systems. Neither is it realistic to expect Control System operators to introduce the level of uncertainty intrinsic in securing the Controllers themselves rapidly or in large numbers. Monitoring with SIEM technologies is the only available method that provides the security necessary while avoiding decreases in the reliability of the Control Systems and their related industrial processes.
Over the long term, as both security and Control System technologies and practices mature further, improvements in technology and process will likely improve the visibility SIEM can provide in these scenarios. Next-generation PLCs could support digital signatures and other self-validation methods and could provide status messages to the SIEM, increasing the detail of monitoring. However the component technologies develop, setting a baseline of monitoring with SIEM technologies will address immediate needs and support future advancements.
46 comments