Computer Attacks - Every month security researchers discover hundreds of new worms and viruses attacking the world's computer systems, but usually few in supervisory control and data acquisition (SCADA) and process control take notice. In early July 2010, however, a new type of computer worm was discovered that shocked experts in the industrial automation community. Called Stuxnet, this worm had been designed specifically to attack the Siemens WinCC, PCS7 and STEP7 control systems. Suddenly industrial control systems had moved from an accidental target to the center of the bullseye.

Of course, in one sense this should be no surprise. Security personnel in the U.S. have been warning of the potential for a cyber attack to be its next Pearl Harbor for years. Richard Clarke, the chief counter-terrorism adviser to President Bill Clinton at the time, raised the prospect over a decade ago, and the comparison has proved enduring; this year alone CIA Director Leon Panetta and Admiral Dennis Blair, the former Director of National Intelligence, have echoed him, and Clarke himself has also been back with his book "Cyber Wars: The Next Threat to National Security."
He paints a catastrophic scenario. The "electronic Pearl Harbor" would start with the collapse of the Pentagon's computer network, followed by a meltdown of Internet service providers. Blows to the power grid, refinery fires and toxic releases at chemical plants would all follow.

Many have rejected this scenario as fanciful, but Stuxnet shows there is cause for concern. Even without a cyber-war, we can estimate that there are 400 to 500 cyber security incidents in Fortune500 companies in the U.S. alone each year, and in Europe it is probably worse. In the processing industries and infrastructure, the Repository of Industrial Security Incidents (RISI), which records cyber security incidents directly affecting SCADA and process control systems, shows the number of incidents increasing by about 20% a year over the last decade.

For all that, though, the truth is probably that the next cyber security incident we see is more likely to call to mind the Titanic than World War II.
In that case, an unforeseen accident sunk the vessel, in part because its bulkheads only extended 10 feet above the waterline and failed to make compartments fully watertight. Water from damaged compartments was able to flood undamaged ones, dragging the "unsinkable" ship down.
It is an apt illustration for most cyber security failures. Consider some examples: the Zotob worm that shutdown 13 assembly lines at Daimler Chrysler in 2005; Browns Ferry nuclear plant in 2006, where redundant drives controlling the recirculating water system failed, probably due to excessive traffic between two different vendors' products on the control system network; or the Hatch Nuclear power plant near Baxley, Georgia, which was forced into an emergency shutdown after a software update to a computer on the plant's business network.

They provide some important lessons for cyber security:

• Hackers are not the biggest risk. There are numerous other examples of intentional attacks like Stuxnet. In Queensland, Australia, for example, the Maroochy Shire sewage spill in 2000 was the result of a deliberate attack on the SCADA system by a disgruntled applicant turned down for a job with local government. However, such cases remain the minority. RISI figures show that less than a quarter are intentional attacks. Instead, almost 50% of incidents reported have been caused by malware, including viruses, worms and Trojans, not specifically targeted at the facility affected. Many of the remainder are pure accidents. The most common security incident remains the unintended consequence.
• Internet security is not enough. Daimler Chrysler had professionally installed firewalls between the Internet and the company's network, but the worm still made its way into the control system, probably from a laptop. From there it was able to travel from plant to plant in seconds. Or consider the 2008 attack on the Lodz city tram network in Poland. A 14-year-old boy used a modified television remote control to change track points, derailing four trams. Any protection of the central control system against untrusted networks was rendered entirely redundant. The hacker was not even using a computer, much less the Internet.
• Poor systems design and, in particular, a failure to contain communications in appropriate areas or sub-systems is a key problem. This is perhaps most obvious in the Hatch nuclear example. The safety system there was well designed, right down in the nuclear reactor. Understandably, it included a database to monitor cooling water levels, among other variables. However, it also included a direct link to a similar database in the business network, and, unfortunately the data flowed both ways. The result was that when software in the business system was upgraded, zeroing the database there, it did the same to the database in the reactor. The automated safety system interpreted this as a drop in water cooling levels and triggered a shutdown. The plant was offline for two days.

Defining Zones

Behind all of this, of course, is the move away from proprietary networks in process control and SCADA systems to standard platforms, such as Windows and Linux, and open standards such as Ethernet, TCP/IP and web technologies. The benefit this has brought to process control systems is significant: integrating different vendors' technology used to be a significant project, both financially and in terms of time. It can now be a morning's work. Similarly, few would now forego the business benefits of integration with enterprise and third party networks.

However, it has also introduced vulnerabilities. Control systems can no longer rely on security through obscurity. Instead, they need the same protection against network attacks and vulnerabilities that have long plagued enterprise IT systems.
Unfortunately, as the examples demonstrate, perfect security is unachievable and, even if it were, would be unaffordable. What is required therefore is network security that protects against external threats, while preventing problems that do materialize in one part of the system spreading to critical control systems. The solution is security zones.

Based on the ANSI/ISA 99 and IEC 62443 standards, key automation and control devices should be grouped into zones that share common security level requirements. Any communication between these zones must then pass through a conduit, a path that regulates the flow of data between zones to allow them to communicate securely.

Making A Start

The most obvious objection to implementing security zones is the upfront work involved, particularly when it comes to existing plant networks, and that is just one reason that the process should start with a thorough risk analysis. This will clarify, and where possible quantify, the business consequences should the threats identified materialize. These may be in terms of lost production, repair costs, clean-up costs or fines, not to mention environmental damage and loss of life. Identifying the potential to incur these costs will be key to defining the business rationale for implementing a robust cyber security system and gaining management support for it.

Furthermore, a risk analysis focused on the operational zone will help clarify the distinction between the threats facing the control system against those more commonly considered in the IT environment. This is vital because much of the knowledge needed for the exercise will come from the company's IT department, which will have the expertise in server and fire wall management, disaster recovery, backup and restore procedures, and so on. It makes sense to make use of this. Control systems are, after all, similar to mission critical servers in the IT space.

However, the priorities in the control room are not the same. IT personnel are primarily focused on protecting the company's intellectual property; process control security is about protecting the physical assets, the plant, its people and the surrounding environment. Similarly, patch management, firewalls, anti-virus software and encryption must all be handled radically differently in a control environment. The analysis will help highlight these differences.

Finally, a risk assessment should help reveal the vulnerabilities that are actually in the system. It will, for instance, necessarily involve an inventory of the networks that will reveal where design drawings may no longer be up to date, and should help to determine where the risks actually lie. This will prevent any security strategy focusing just on high profile, but low probability events, such as a terrorist attack. Instead, the whole range of everyday threats can be identified, revealing the close interconnection between security, safety and reliability. The plant can then priorities dealing with the high probability, high impact vulnerabilities. That, in turn, should leave it as well placed as possible even if Clarke's worst fears do turn out to be true.