Hacker v Slackers

Hackers are regularly trying to break into the country's key commercial and industrial networks, said the UK government's security minister Lord West of Spithead in August this year.

He told the press: "If you take the whole gamut of threats, from state-sponsored organisations to industrial espionage, private individuals and malcontents, you're talking about a remarkable number of attempted attacks I'd say in the thousands. Some are spotted instantly; others are much cleverer."

His was a general warning that echoes those from security experts over the past several years. It's usually assumed that these attacks target only the office or corporate IT networks, which is often true, but now there's a more specific threat, to SCADA-based process control networks. The threat is growing and its consequences are potentially catastrophic.

Yet disturbingly, the cyber threat to SCADA systems has been met with laxity and complacency - when it's even acknowledged in the first place. As David Robinson, country manager of data security company Norman Data Defense Systems (UK) says: "I've met many control engineers who are ignoring this problem, saying things like: 'We'll tackle it when we next change systems.' But that could be in five years' time."

That's way too far off; control engineers need to do something now, he says. And he has a point, especially if industry wants to avoid incidents like the chaos a Polish teenager is accused of causing earlier this year to the tram system in the city of Lodz, and an attack in 2003 on a US nuclear power plant notable because they're rare examples for which details are in the public domain.

In the Polish incident, a 14-year-old allegedly turned the Lodz tram system into his personal train set derailing four trams and injuring at least 12 people after modifying a TV remote control to change track points. According to police, he had sneaked into tram depots to gather the information he needed to build the device, and news reports at the time expressed surprise at the ease with which the control system had been hacked.

In the 2003 attack, a software virus called the Slammer worm, which targets Microsoft SQL servers, penetrated the Davis-Besse nuclear plant in Ohio. It did so first through the unsecured network of a Davis-Besse contractor, then hitched a ride along a T1 high-speed phone line between that network and Davis-Besse's corporate network, from where it entered its plant network and disabled a safety monitoring system for five hours.

Thankfully the breach did not pose a safety hazard, as the plant was offline at the time, but the incident is a classic case of the vulnerabilities in process control systems that commonly persist to this day.

Investigators found that the plant's engineers had presumed their control systems were protected by a firewall for the entire network corporate as well as process control against traffic from external networks, but the T1 line was one of multiple points of entry to the network and Slammer simply bypassed the firewall. Once it had done that, there was no internal protection against it.

Unreported incidents

Many such incidents go unreported or are unattributable because of victims' understandable reluctance to own up to them. But thanks to the Industrial Security Incident Database which is being relaunched in the new year as the Repository for Industrial Security Incidents it's possible to see a trend in the number of attacks. And that trend shows a sharp jump since 2001.

There are several reasons for this, as business development manager at safety technology company MTL Instruments Philip Nunn explains: "The key reason is the widespread adoption of Ethernet.

"Other factors are that SCADA systems have become increasingly interconnected and there's greater public awareness of SCADA and control system protocols," he adds.

The uptake of Ethernet, which is a commercial off-the-shelf (COTS) technology, means that SCADA systems are no longer proprietary and highly customised, so hacking into them no longer takes specialised knowledge. Also, it's not enough to protect networks with only a firewall to the outside world the 'bastion' model as one of the greatest threats is from within, either from contractors as in the Davis-Besse case or plant employees. Some form of segregation is needed.

"The trouble with perimeter security is that it protects only the perimeter," says Robinson. "If your only form of protection is against the outside world then all it takes is for an employee to connect an infected laptop or USB memory stick, for example, and you'll soon have malware all over the enterprise's network."

The irony, as Nunn explains, is that these incidents are usually accidental, caused by employees who don't understand the system and didn't know their hardware was infected.

Layered defence

Robinson and Nunn advocate a 'defence in depth' approach that includes a layered network architecture to give multiple levels of protection using firewalls at crucial nodes of the network and hardware-based security appliances such as MTL's Tofino at the control device level. Nunn adds other examples such as updated asset management, regular security patches, anti-virus software and host hardening, where applications that are not needed are switched off.

But as Robinson points out, such measures on their own are not enough. "The limitation with, say, firewalls is that they work simply by shutting ports, but malware doesn't care which port it uses as long there's one open, through it goes.

"For example, OPC uses the same port, 135, as RPC. Internally it's left open, externally it's shut. But there's a huge amount of malware around that uses port 135, simply because malware creators know it's left open," he says.

"So you also need some form of networking monitoring and malware detection software, such as Norman Network Protection, which acts as an internal security gateway, so that when you are attacked by malware it can detect it, isolate it and then allow you to shut it down at the next appropriate opportunity."

There are other issues with firewalls. "If you bought a typical firewall you'd get one designed for an office, one that couldn't be managed by an engineer in a control environment," says Nunn. "So you need one configured for the control network, one that deals with protocols like Modbus TCP and Ethernet IP as opposed to a string of numbers, and which has a GUI that control engineers are familiar with.

"And of the three types of firewall Packet Filter, Stateful Inspection and Application Proxy Stateful Inspection is the way to go, but even then only as a minimum for meaningful protection."

Control engineers may baulk at the introduction of such mainstream IT products and the need for familiarity with them, but that's the price of COTS. And the fact that control and corporate networks are different but interconnected means it is vital that the IT and control engineering functions work together here.

Taking responsibility

For a start, who should be responsible for control network security? Robinson is clear on this: "Day-to-day security should be within the remit of the control engineers," he says. "But for overall security, engineers tend to have limited knowledge usually gained from using their PC at home while the IT people see so much more of the possible threats to security that they're better placed to respond appropriately to it."

But IT-style solutions are not always appropriate in control networks. As Nunn points out: "There's an underlying need to balance security with flexibility in control networks. For example, unlike an IT system, you can't simply try restarting a control system if there's a problem, nor can you afford to have something like a three-strike password lock-out on it. So there's a fundamental need for security products tailored to the control industry."

IT people and control engineers which, it's fair to say, have not always seen eye to eye also need to learn from each other. "What's needed now is a more company-wide view of security," says Robinson, "one where the two groups understand each other's requirements."

He says one good way to achieve this is through job swaps. Another is to train control engineers in IT technologies. "That way, you could create a subset of IT people to provide a tailored service for the control engineers," he says, conceding though that budgets for such training as well as people with skills in control engineering as well as IT can be hard to find.

The situation, however, is changing. Justin Lowe, a management consultant at PA Consulting who focuses on SCADA security, says: "In the past there was a gap between the skill sets of IT people and control engineers. These days there's much more of an overlap the growth of IT-based control systems has fostered a convergence between them in terms of working together. As a result, I'm now seeing more interest from IT people in focusing on the control side; there's no way that would have happened five years ago."

Proper management required

Yet all this technology will be as nothing without proper management, so who should have overall responsibility for an organisation's security? "I think it should be a mix of people," says Lowe. "In terms of accountability, it should be someone at professional engineer level, but for ongoing monitoring and maintenance it can be someone at the administrative level."

Lowe also says that, should company culture permit it and providing it's tailored to the control system environment, part or all of the security management can be outsourced. "For example, you can outsource the management of the firewall(s)," says Lowe, "something that could well find favour with a typical IT department that is used to managing Internet firewalls but has never encountered the range of weird protocols circulating in a control system environment.

"And make no mistake, firewalls need ongoing management and maintenance they are not 'fit and forget' technology," he says.

But whichever approach you choose, responsibility for security needs to go all the way to board level. But who should have it? "I've seen it sitting with various functions but in general I think it's more a role for operations and the COO," says Lowe. "But whoever takes it on, you must have someone at board level."

And if the worst comes to the worst, and a major attack does succeed, what's the best way to deal with it? "Plan for the worst scenario and be prepared for it," says Lowe.

"This is a really weak area in many companies because of people's natural focus on technology. It's critical to have a fast response plan and some continuity planning, such as a spare or back-up system, in place."

However, he warns against a blanket approach to back-up. "A prime example is a safety system, which obviously needs a back-up; other, less critical systems may not," he says. "You have to make some risk-based decisions, something people tend to forget about. It's a combination of technology and management."

So there's a consensus. Don't ignore the fact that cyber attacks are real and occurring regularly and do something about it. You have been warned.