In late March, the US government, via its Computer Emergency Readiness Team (US-CERT) was forced to issue a series of alerts after an independent researcher published a list of some 34 vulnerabilities in a variety of industrial control systems known generically as SCADA systems.
These SCADA, or supervisory control and data acquisition, systems are found in a variety of industrial plants ranging from water and waste treatment to food and pharmaceuticals and even nuclear power plants. As such, they play a vital role in the monitoring and production of key products and services but have until now been largely overlooked by cyber criminals. The revelation that they contain serious software flaws which might render them vulnerable to attack, however, is causing great concern among a range of different stakeholders.
Here we’ll take a look at SCADA systems, what they are used, for, how they work and what the risks are, before looking at what can be done to harden these systems against attack.
What are SCADA systems?
As we’ve mentioned, SCADA systems can be found industrially in a range of manufacturing or production environments including power plants and refineries, or in infrastructure environments for example controlling oil or gas pipelines and electrical power transmission. SCADA is the name given to the centralised computer system which monitors the entire distributed environment of a power plant or oil refinery, for example. The actual control actions are carried out by the Remote Terminal Units (RTUs) or by Programmable Logic Controllers (PLCs), according to the instructions sent to them by the SCADA, and are usually related to the heating, ventilation, air-conditioning or energy consumption.
As you can imagine, with such a broad range of potential uses, SCADA machinery can be found in both public and private sector owned plants, but with such a potentially vital role in the smooth operation of key processes and industries, it is imperative they remain free from interference by cyber criminals.
Are SCADA systems safe?
It has long been suspected that these systems were lacking when it comes to security, but the discovery of 34 vulnerabilities by security researcher Luigi Auriemma, was still a massive blow to the makers of SCADA systems. It appears as if the manufacturers were relying too much on security by obscurity. This is the rationale that hackers would ignore such systems because they’d have to spend far too long researching the technology to generate a decent RoI. The vendors were also likely still in the mindset that many of the systems were not connected to the internet and therefore more secure, although increasingly SCADA systems are actually being networked because of the superior efficiency gains and improved manageability that can be achieved.
Despite researcher Auriemma never having worked with SCADA systems before, he managed to find a wide variety of problems with the vendors he tried, namely Siemens, Iconics, Datac and 7-Technologies. His “quick experiment”, as he described it, appears to have required worryingly little research and effort. In no uncertain terms, Auriemma wrote that these systems should be treated no differently from other software:
“In technical terms the SCADA software is just the same as any other software used everyday, so with inputs (in this case they are servers so the input is the TCP/IP network) and vulnerabilities: stack and heap overflows, integer overflows, arbitrary commands execution, format strings, double and arbitrary memory frees, memory corruptions, directory traversals, design problems and various other bugs,” he wrote.
After downloading a free trial of some of the products he got to work and, in some cases after as little as a couple of hours, managed to find the vulnerabilities. Although the SCADA makers have tried to play down the seriousness of the discovery, some of the vulnerabilities allow for remote execution of arbitrary code if the SCADA system is connected to the internet, meaning a hacker could manipulate a SCADA connected machines from a remote location anywhere in the world. Other vulnerabilities included stack overflows, multiple integer overflow, double memory corruption, buffer overflow and directory traversal, all of which are remotely exploitable.
Stuxnet, a warning
The first serious case of SCADA flaws being exploited via cyber attack came with the discovery of the Stuxnet worm in 2010, regarded by many in the industry as a game-changer. It is now believed that the Israeli or US government was behind the attack, launched to disrupt Iran’s nuclear programme by hacking SCADA systems in its uranium enrichment and nuclear plant and forcing machinery to misfire.
This attack was highly unusual in its incredible sophistication, exploiting four zero-day vulnerabilities in order to achieve its goal, but nevertheless it proved that SCADA systems could be hacked and physical machinery controlled remotely. It should have been a warning to SCADA makers. These systems were only damaged, but theoretically a SCADA system could be hacked to cause much longer lasting damage at a nuclear facility or power plant, which could have serious repercussions on the safety of a country’s critical national infrastructure.
What can be done to minimise risks?
The central problem facing many IT administrators tasked with managing SCADA systems is that the machinery and systems they control – such as power plants or oil refineries – cannot be disrupted in any way while the SCADA software is taken offline to patch or update. As a result, the “if it ain’t broke don’t fix it” mentality tends to hold sway in many of these environments and security comes second to operational performance.
This is certainly changing, though, and that old reliance on security by obscurity has been shot down by the high profile nature of Stuxnet and the 34 vulnerabilities released by Auriemma. The networking of many SCADA systems today has also changed the way IT teams need to think about security updates. Instead of patching maybe once or twice a year, the update cycle has shifted so that patches can be applied once or twice a day if necessary, via the internet. However, almost certainly environments will still contain a mixture of modern, Ethernet connected kit and legacy machinery, which makes patch management more problematic.
Aside from developers engineering SCADA software with fewer holes, or re-engineering existing systems, the key way of mitigating the risk of attack, as advised by US Cert and Trend Micro experts, is to minimise the amount of equipment that is connected to the internet. Stuxnet actually managed to infect SCADA systems by jumping this ‘air gap’ between machine and internet, however it was highly unusual in its sophistication. Most of the time, minimising network exposure will severely limit hackers’ ability to infect control systems. US-CERT recommends the following: “Locate control system networks and devices behind firewalls, and isolate them from the business network. If remote access is required, employ secure methods such as Virtual Private Networks (VPNs).”
A better balance certainly needs to be struck between achieving operational efficiencies with networked and internet-connected SCADA systems and reducing the risk of attack as far as possible. Whatever happens, SCADA makers should assume that these vulnerabilities are just the tip of the iceberg and be on their guard for future attack.