Segregation is key when you're running SCADA over IP, says Ken Munro. Even more so if it's for nuclear power.
The usefulness of the UPS (uninterruptable power supply) cannot be underestimated. When electricity supplies fail, it gives you enough time to save data and power down safely. Its existence is testament to the frailty of our national infrastructure. We understand that supplies fail, but do we understand why? The people who design SCADA (supervisory control and data acquisition) systems do.
These systems help manage many facets of national infrastructure, including water, gas, electricity, oil, electricity and nuclear power. SCADA systems enable the resources we use in our daily lives to function and to do so safely and consistently. SCADA was developed as a way to manage large-scale industry and utility data in as efficient a way as possible. There is a safety component, but permanence of supply and minimal interruption are its main reason for existing.
Over the past ten years, convergence of SCADA systems and IP has become the norm. This has delivered cost benefits to operators. Rather than having dedicated switched networks supported by SCADA specialists, a system can be managed with ordinary TCP/IP technology and associated skills.
SCADA systems operate in isolation, restricted to the control of whatever systems or processes they have been assigned and are protected from outside interference. Because of the impact that SCADA system failures can have, they will never, one should hope, be publicly accessible via the internet.
Good practice could be to run IP SCADA systems over a private wide area network (WAN). This does not make them invulnerable, but it does provide some protection against web-based attackers. Physical network segregation would be ideal, but negates the cost benefits of converging SCADA with IP.
Implementing SCADA using IP networks must be done with caution. A system that controls regional electricity supplies should not be available across a corporate network. Segregation is the key, and so is quality of service (QoS). Putting SCADA on a WAN reduces the risk from harm. However, it must be properly segmented, perhaps with virtual local area networks. QoS is crucial to preserve bandwidth. If the bandwidth allowed for SCADA is consumed by other network services, SCADA will not be able to communicate.
If a worm was introduced to a SCADA system, the network "noise" created could cause a failure. A payload wouldn't be necessary; just tying up the network could be enough. But then SCADA IP systems can be just as unreliable without intervention. A badly constructed TCP/IP request can cause failure.
Some nuclear power stations are using SCADA over IP via wireless and bluetooth. While using wireless options is cheaper than drilling through blastproof walls to lay network cables, it isn't very resilient against signal blocking. A cordless phone signal can knock out a home WLAN. It doesn't take much to apply the same technique to a SCADA network. A directional antenna broadcasting a high power 2.4 GHz blocking signal could render a SCADA WLAN useless.
Testing the security of SCADA systems is also problematic. Their sensitivity has led the National Infrastructure Security Co-ordination Centre to caution that live systems should not be tested, saying: "SCADA or DCS (distributed control systems) are often safety-critical. Often paper-based tests or tests against exact replica systems are more appropriate." There is an argument that testing the security of SCADA systems may actually be little more than a distraction from the real problem of migrating 20- or 30-year- old infrastructure to keep up with IT.
And if a SCADA system is attacked and caused to fail, how will it affect the particular environment? The difference between a valve or switch failing to open or close can be critical. Will it fail "safe" or will it fail Three Mile Island-style?
- Ken Munro is managing director of SecureTest. He can be contacted at firstname.lastname@example.org.