Chris Day, Security Consultant
4 mins read
Despite the lack of detail in this report, 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 SCADA systems 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 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 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 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.