Forging a SCADA defence strategy

A security testers response to the recent Steel Mill cyber-attack in Germany - and the realities that operators of industrial systems are now facing

Last month, drowned out of the news by Cyber events against the movie and gaming sectors, 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 a potentially life-threatening situation.

The paper containing brief details on this incident is available in German from the Federal Office for Information Security but can be translated using online services. Page 31 contains the relevant paragraphs though unfortunately, and deliberately, this paper contains limited technical details.

Despite the lack of detail in this report, I believe a lot can be learned from the event.

Following Stuxnet, this is the second publicly disclosed cyber attack against SCADA 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. 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 and social-engineering techniques. This event demonstrates gaining access to, and attacking SCADAsystems doesn’t necessarily need expensive or sophisticated techniques.

I have personally spent many years scoping, conducting and reporting SCADA system computer security assessments. In practically all my assessment, 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 in an organisations 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 SCADAsystems 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 an attackers chances of gaining access and having an 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 SCADAworkstations 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.




MWR is an accredited member of The Cyber Security Incident Response Scheme (CSIR) approved by CREST (Council of Registered Ethical Security Testers).
MWR is certified under the Cyber Incident Response (CIR) scheme to deal with sophisticated targeted attacks against networks of national significance.
We are certified to comply with ISO 14001 in the UK, an internationally accepted standard that outlines how to put an effective environmental management system in place.
MWR is certified to comply with ISO 27001 to help ensure our client information is managed securely.
As an Approved Scanning Vendor MWR are approved by PCI SSC to conduct external vulnerability scanning services to PCI DSS Requirement 11.2.2.
We are members of the Council of Registered Ethical Security Testers (CREST), an organisation serving the needs of the information security sector.
MWR is a supplier to the Crown Commercial Service (CCS), which provides commercial and procurement services to the UK public sector.
MWR is a Qualified Security Assessor, meaning we have been qualified by PCI to validate other organisation's adherence to PCI DSS.
As members of CHECK we are measured against high standards set by CESG for the services we provide to Her Majesty's Government.
As a Certified Simulated Attack Manager and Certified Simulated Attack Specialist, MWR are authorized by CREST to perform STAR penetration testing services.