The SCADA security challenge

Have you read the latest issue of our digital (IN)SECURE Magazine? If not, do it now.

One of the less well-known aspects of information technology – but arguably one of the most critical to modern businesses – is the SCADA platform.

SCADA stands for Supervisory Control And Data Acquisition, the computer control systems at the heart of many industrial automation and control systems.

First developed in the 1960s – and evolving rapidly as the first PCs started shipping in the 1980s – SCADA-driven systems are found in energy power plants, electricity supply grids, chemical plants and many other industrial systems that require a high degree of computerized control – but also demand total, 100% systems availability.

This is Mission Critical with a giant capital ‘M’ and ‘C.’ Many organizations claim their IT processes are mission critical, but SCADA control systems truly are critical to the national infrastructure.

If the national power grid goes down, for example, it can cost a country many hundreds of millions of dollars per hour and, in the case of hospitals, air traffic control systems and the like, will actually place people’s lives in jeopardy. Lost production and commerce is one thing, but lost lives raise the security ballgame to an entirely new level of governance.

Here in the US – as in the UK and Europe – many SCADA-driven systems are connected to the Internet. Where previously these systems were connected using a dial-up modem – with password security that at the time was highly resistant to attack – the trend today is to plug these devices into the Internet using a standard Ethernet connection – or worse yet, by WIFI or some other wireless protocol that lacks the encryption and authentication needed to prevent tampering.

This approach, as you might surmise, is a ticking time bomb. Cybercriminals are not stupid – they understand weaknesses, possess the means to guarantee success, and understand the impact of an attack.

Until now the only documented exploits in the SCADA security space have targeted foreign infrastructures, but I believe that this is certain to change.

A study carried out at the end of 2012 by Bob Radvanovsky and Jacob Brodsky of InfraCritical, a US-based security consultancy – and conducted with assistance by the US Department of Homeland Security – found that thousands of SCADA-based systems accessible from the Internet have weak default passwords defending them.

The two researchers used automated scripts to interrogate the grey hat SHODAN (Sentient Hyper-Optimised Data Access Network) and identified over 7,000 vulnerable, default logins out of an initial pool of 500,000 SCADA systems.

The good news is that the Department of Homeland Security has now started to reach out to the IT admins of this particular group of vulnerable SCADA-based systems, but reports suggest the remediation progress has been relatively slow.

Against this backdrop, there are discussions making the rounds in US IT security markets that, in return for allowing their SCADA systems to be scanned – essentially vetted – by the federal government, the utilities and other critical national infrastructure (CNI) system owners will be protected against legal or regulatory action in the future.

The real issue with the security of SCADA systems is that, while you can employ software patches to make a system more secure, there is, unfortunately, no similar patch against human stupidity.

SCADA systems should never, ever, be connected directly to the Internet, because they are simply not resilient enough to hook up to the public network. They require the use of advanced layers of security – firewalls, privileged identity management, secure proxies – to be implemented as soon as possible for their defence.

I believe that the problem is rooted in the fact that – as my research teams repeatedly discover – utility companies almost without exception fail to make the requisite investments in IT security that you’d find in other industries of comparable size – unless, of course, the utilities are forced by federal agencies and auditors to take action.

Making SCADA systems more secure
Given that the very heart of our nation’s infrastructure runs on SCADA, how do we make these systems more secure? Are there really so many active threats out there?

Here’s what I believe is the heart of the issue: SCADA systems can be based on a combination of embedded controllers combined with Windows or Linux systems. This combination isn’t terribly insecure in isolation, but once connected to the Internet (as a matter of convenience and for holistic management), every component now needs to be patched and managed for access and authorization since there are no longer any locked doors keeping the wrong people out.

Corporate IT systems are – most of the time – protected by network firewalls, intrusion and anomaly detection systems, endpoint security software, and other prevailing safeguards. Once they’re connected to the Internet there’s simply no excuse for SCADA networks not to employ – at the very least – those same essential layers of security to protect against external attacks. The bad news is that a great many SCADA deployments do not even begin to utilize these broadly adopted technologies.

And the bottom line is…
The bottom line is that a great many SCADA networks are designed and deployed by electrical engineers who lack IT security training, and I believe that this engineering culture is often naïve when it comes to the threats that foreign powers and sociopaths could have on their designs. Consequently many SCADA networks have a security blind spot, with a healthy dose of attention paid to whether the controls interact safely with their physical environments but far too little focus on how well the systems can withstand cyber attacks.

We’ve also found that management teams – especially at smaller utilities -fail to understand the need to change passwords regularly – believing they can trust everyone because they know everyone.

This is a culture of: `We need to know the password for everything – because when the power is down, we need access in a hurry.’ Consequently these same admin teams, we find, have a habit of using factory/default passwords on their systems to ensure easy levels of access – at all times – for all engineers.

This is a cultural issue, and it’s one that security vendors need to address head on.

There is also an interesting sociological angle here. Criminal gangs might have diminished interest in utilities because there may be little profit in breaking into them. And while Hactivists could conceivably cause problems, our observations suggest that many of these groups will avoid infrastructure targets because of the moral implications.

This leaves state-sponsored attackers as a primary threat, and makes CNI security an issue that screams for government oversight. The reality is that governments around the world have already staged attacks on rival states’ CNI, but we hear about very few of these incidents in public. In the event of an attack on the US infrastructure – in all likelihood originating from a smaller rogue state – the outcome could constitute an act of war as damaging as any action taken with troops and physical armament.

In the US there is now a very clear focus on the CNI – and the federal government is starting to probe for vulnerabilities on these SCADA networks and then reporting back to the operators. The question we have to ask is whether it really is the government’s place to complete these probes.

The free pass concept is that, if the government or its agencies complete the scan and give the `thumbs up’ to your SCADA system security, then if your systems do subsequently get attacked, you are exempt from possible legal action.

This is a positive approach as has the potential to bring everyone – from the lowest engineer to the highest security strategist -on board with SCADA security to ensure that we are all working toward a common goal: making our CNI more secure.

Some time ago I believed it was unlikely that any government would footprint or probe other states’ CNIs. My observations have caused me change my mind, and I now believe it is naive to underestimate any foe. SCADA vulnerability is a central challenge to our national security – and we really do need to address this issue now, before a major incident takes place.

So what are the solutions?
There are a number of recommendations that I would make to ensure that SCADA-based systems are better protected. The good news is that most of these actions can be implemented using existing technologies and legislation, though there may be a need for some tweaks to the statute books. It should be remembered that we are talking about the IT systems that control our national infrastructure.

(1) Take a leaf out of the German statute books on data breach law and impose potential prison sentences on those managers that fail to take their SCADA defense obligations seriously.

(2) Impose hefty financial penalties as a stepping stone to the penalties outlined in (1) above.

(3) Issue comprehensive SCADA security guidance – in the form of white papers and best practices recommendations – and stipulate fines for those that fail to comply. A good model could be the PCI DSS rules that govern processing of payment card credentials.

(4) Use existing government cyber-warfare resources to simulate attacks against CNIs and issue confidential reports to the appropriate managers of the organizations concerned. If the organizations fail to remediate their security problems in a timely fashion (that is, within a few months), local country CERT officials will complete the planning element of the task, and a court-imposed mandate will be placed on the organization to deploy the recommendations in the planning document. Further infractions will be treated as a contempt of court process.

(5) Require CNI-based SCADA system operators to adhere to appropriate integrity verification processes on at least a monthly basis, with continuous compliance as the mainstay of the reporting system. An auditing process similar to the PCI DSS governance rules can also be applied.