The Stuxnet bot’s attack on some business’ Supervisory Control and Data Acquisition (SCADA) systems and the Victorian Auditor General’s report asserting that these systems have operators of such systems worried. Hackers have also noticed SCADA, it was revealed at Black Hat 2010.
So what can you do to protect your SCADA systems?
SearchStorage Australia New Zealand asked two experts to offer their tips on improving SCADA security
Brahman Thiyagalingham, Logica’s Security Practice Manager told us that SCADA security problems are caused, in part, by “a switch from using serial protocols and largely proprietary technologies, to open source and common protocols. The outcome is greater business efficiency and profitability, but at the cost of increasing the vulnerability of theSCADA network, which is now susceptible to infiltration of malware and cyber attacks.”
Thiyagalingham therefore offers the following five ways to improve SCADA security:
1. Implement an industry-standard governance
SCADA operators will need to provide guidelines on setting up security governance, perform a full risk assessment, develop risk mitigation, and implement controls to mitigate risks. Of these frameworks the ISO/IEC 27001 management system standard is recognised as the premier standard for information security management, regardless of the type of industry or size of business. Furthermore, the ISO /IEC 27001 framework is technology independent and applies to both technical and non technical environments.
2. Provide training
Thiyagalingham says SCADA engineers have held long term positions and are accustomed to working in an environment that has a very slow turnaround between new technologies. Support technology lifecycles for SCADA can be up to 20 years. This means the people maintaining and operating SCADA infrastructure have little understanding of new technologies, treats and necessary protection measures needed to protect this new network environment. Training SCADA operators in security tools is therefore important.
3. Cross-functional engagement
The integration of SCADA and corporate infrastructure means decisions made surrounding corporate infrastructure can directly impact SCADA security. Operators need to enforce enhance collaboration between their SCADA engineers and IT security teams to ensure all potential vulnerabilities are considered and precautions put in place. This means regular meetings and communication across IT, security and SCADAteams.
4. Continual improvement
The Victorian Auditor-General’s report revealed that not one organisation covered had a process for continual improvement of security measures for SCADA. As most people know, security threats are evolving and changing on a day-to-day basis. Protecting SCADA security means operators need to implement a program for continual improvement from the outset.
5. Regular testing
Performing regular security testing, of both infrastructure control systems and Remote Telemetry Units (RTUs), of SCADA networks needs to evolve from a technical basis to a more risk based, process oriented management basis. Such an approach will allow utility companies and other SCADA operators to adopt a process of continual improvement, which will not only provide a level of security assurance today, but also into the ongoing future. A risk based approach will allow all SCADA operators and managers to engage with an organisation’s executives whereby they can secure the necessary resources for the ongoing development and security of SCADAnetworks.
Paul Ducklin from Sophos
Paul Ducklin, Sophos’ Head of Technology for APAC, offered these five tips:
1. Don't listen to Siemens when they tell you not to change security settings, including passwords. If you didn't design security into your systems before, then you have been remiss. Heal thyself. (Don't copy what Apple did with the root password on the iPhone. They got away with blaming jailbreakers, which was a bit of a "get out of jail free". You don'tt have that luxury.)
2. Don't connect all your Windows-based PLC supervisory systems straight to the internet "because everyone else is doing it." (Don't copy the banks. At least they carry some instantaneous financial risk, especially their machines which have great big stacks of cash inside.)
3. Don't use internet-connected PCs to compile and download your programmable logic controller (PLC) code to field devices "because everyone else is doing it". Use a separate, airgapped build-and-ship network. (Yes, it costs more. But we don't want our industrial control infrastructure to be as fragile and as privacy-enervating as The Cloud, now, do we?)
4. After following rules 1 to 3, don't get sloppy about how you
move code between your development and your build networks. If you aren't practising some sort of
strict device control (e.g. for USB keys) between those networks you are letting the side
In short: if Stuxnet _did_ infect your network, and if it _could_ have spread to your PLCs from there, you are doubly at fault. Firstly, the virus ought not to go unnoticed for very long in any reasonably well-defended network. Secondly, even on an infected LAN, policy and procedure -- plus technology -- should have guaranteed that it couldn't make the jump to the PLCs themselves.
5. Lastly, don't listen to the Stuxnet conspiracy theorists. The whole "Irael vs. Iran" fuss has distracted from the main issue, namely that _this malware shouldn't be able to run amuck in your company_. Because if it could, or did, then you are at much broader, everyday, cybercriminal risk from any number of less-well-publicised items of malware.
This was first published in October 2010