Chris Day, SCADA security consultant for MWR InfoSecurity
The beginning of 2015 saw one of the biggest cyber events ever take place. Unfortunately, it was drowned out by the news of the various divisions of Sony being hacked. At the same time, the German government quietly admitted it had suffered a sophisticated cyber attack against an industrial facility – a steel mill – which resulted in equipment damage, production downtime and which could have potentially cost lives. This event was only the second time ever a cyberattack had resulted in physical damage.
Following Stuxnet, the computer worm designed to attack industrial programmable logic controllers and ruined almost a fifth on Iran’s nuclear centrifuges, this is also the second publicly disclosed cyber attack against SCADA (supervisory control and data acquisition) equipment which has been formally investigated and attributed to a sophisticated remote attacker. This in itself is a rare event and demonstrates the credible and increasing risk to SCADA equipment, or computer systems used for gathering and analysing real time data. It is an unfortunate truth that a risk typically needs to be demonstrated in the wild repeatedly before it is addressed with the resolve appropriate to the potential impact of a successful attack.
However, unlike Stuxnet which featured sophisticated air-gap hopping methods to gain access, this attack is reported to have used less exotic, yet still credible spear-phishing (email spoofing fraud) and social-engineering techniques. The steel mill attackers were able to infiltrate the corporate network by sending a targeted phishing email that appeared to have come from a trusted source in order to deceive the recipient employee into downloading malware to his/her computer. Once the attackers obtained a foothold on the corporate system, essentially, they were able access to the steel mill by successively working their way into production networks to access the system’s plant equipment controls.
In this particular attack on the unnamed German steel mill, attackers manipulated and disrupted control systems to such a degree that a blast furnace could not be properly shut down, resulting in “massive”—albeit unspecified—damage. This event demonstrates how gaining access to and attacking SCADA systems doesn’t necessarily need to employ expensive or overly sophisticated techniques.
I have personally spent many years scoping, conducting and reporting SCADA system computer security assessments. In practically all my assessments, across several different sectors, I have noticed one common theme; a reluctance to admit or lack of understanding of connectivity between corporate and SCADA systems.
I believe I understand why this situation exists; it is typical to see an organisation’s IT and engineering as separate departments. Yet, to enable greater exploitation of SCADA metadata (such as manufacturing output or power consumption) and a lowering of infrastructure costs, it is increasingly common to find SCADA and corporate networks connected. In many instances, this fusion of networks is focused on maintaining the functionality of the corporate and SCADA systems by each group of specialists – the SCADA and network engineers. The discussion of the security implications of such a merger is often absent. It is at this junction, the known and unknown security issues of two networks have been combined into one, vastly increasing attackers’ chances of gaining access and having a negative effect against corporate or SCADA systems.
Also, we stand no hope of effectively dealing with cyber attacks against SCADA if we don’t improve our ability to share knowledge with the wider SCADA community. If organisations do not acknowledge security issues or attempt to diminish the credible, demonstrated threat for PR purposes, they are merely burying their heads deeper in the sand and perpetuating the problem. By recognising and sharing details of these attacks, we can make effective defensive countermeasures and strategies based on experience and understanding gained from studying real life attacks.
In summary, if we are connecting corporate and SCADA systems together we must ensure this union is forged securely so the networks do not share their security weaknesses with one another. These weaknesses could be in the form of vulnerable Internet exposed corporate network services, remote access for SCADA maintenance engineers or outdated SCADA workstations laden with historic vulnerabilities and operating systems. To enable robust security when combining networks, we need to be aware of the latent risks in each of the networks we are combining. We also need to also investigate the technologies present in each network to understand if new security risks would be created when combining them. Without this understanding, and an appreciation of in-the-wild attacks, we will be unable to implement effective defensive strategies and measures we need to protect SCADA systems and the Industrial and critical processes that exist upon them.