SCADA: Mission critical, highly vulnerable, almost un-protectable.
In today’s world when most of us think about IT infrastructure, we think about the traditional environments that have firewalls, switches, routers, standard operating systems and all the associated security. We think of internet applications like Facebook, LinkedIn, eBay, SalesForce and Amazon, etc.
What we don’t think of is the SCADA environment; Networks and systems that are embedded into all our critical infrastructure, transportation systems, power plants, water treatment facilities, all factories, mining, oil production, etc. Most of us just assume these networks are like all other IT environments, that they face the same risks and deal with that risk in the same way. I’m here to tell those of you who think that way, that they don’t and they can’t. There are technical reasons why they can’t and business reasons why they won’t. They are, to some extent, the un-protectable networks.
In today’s blog we will discuss the reasons for this conundrum, and in future blogs we will drill down into real-world solutions that exist today to make these networks more resilient and secure.
First let me start with a real-world example, one particular piece of one particular SCADA environment in order to illustrate the problem.
A power company has five nuclear power stations, built or retrofitted over the past 30 years. Each of those power plants have cooling turbines. Let’s say for argument’s sake they each have 10 turbines, all from the same manufacturer. It is highly unlikely many of these run the same operating system (and yes they do run an operating system). It is also highly unlikely they run a standards-based operating system and almost guaranteed that whatever operating system it is, it has not been patched lately. Why, you ask? Well… in short, that operating system for Turbine 6, Plant 4 was custom-built and configured by a company like GE. It was made to spec specifically for the capacity and environment of Tower 6, Plant 4.
Why bring this up, you ask? Well, the basis of the protection of a ‘normal IT environment’ is to eliminate the host OS and application vulnerabilities at the source. You can’t do that in a SCADA environment where the patches and updates don’t exist. “That’s OK,” you say, “we can’t patch it but we can run anti-virus or maybe some white listing software.” These two different solutions won’t work in most SCADA environments, however. In the case of anti-virus, no one in this world would/will write an anti-virus solution for the mass market of one or two customers because the economics just don’t exist. In the case of white listing, it runs into the business side of the problem…. These turbines are very expensive (not to mention every other piece of SCADA network-enabled components throughout the power plant). In the case of a turbine, let’s go cheap and say $10 million each. They have a lifespan of 25 years, sometimes more. As such, they come with this great warranty and maintenance plan. The only “gotcha” is that the warranty and maintenance plan may be null and void if you change the pristine environment in any way or if you add latency (Turns out SCADA equipment needs hardly any bandwidth but it is super latent sensitive).
[You might also like: Application Virtualization – Seeing the Forest Instead of Trees]
In this scenario, the turbines are worth $50 million, and let’s say each power plant has other SCADA gear worth over $500 million. The business owners are forced to do a risk vs reward analysis and nine times out of 10 decide that fixing any breach after the fact would cost less than any potential loss of warranties, so they don’t add any security (the latency clause usually does for any traditional security appliances as well… in line scanning or manipulation with the data stream adds latency, this equals voided warranty, which means the business says NO!).
To compound this problem, in many cases the IT staff of organizations dealing with large scale SCADA environments are often barred from having input into these environments. The overwhelming reason given by operations teams is that IT does not understand the business risk associated with any down time. To illustrate this point at a recent conference for cyber security in oil and gas, I was given this example by a large Oil Rig Operator:
Oil rig operator: “IT isn’t allowed near my network”
Me: “Why, surely they understand the networking equipment design, etc. better than your operations team?”
Oil rig operator: “No, they certainly don’t. If I ask them for a redundant network they will give me two links from two different devices and call that redundant?”
Me: “Well I’m confused, can you explain why that isn’t redundant?”
Oil rig operator: “Well Daniel, if we go down to only one link, we no longer have redundancy and are required to shut down mission critical systems. Everyone knows redundancy means at least three links from three disparate devices. “
Clearly the problem is one of perception because the oil rig operator was right – if I or you or nearly anyone else was asked to architect a redundant network, we would have two devices and two routes…. Unless we were given the parameters to know that in this case we need to have a minimum of two links up at any one time.
That’s it for today! I hope I have illustrated the three main problems:
1) Why traditional IT management and basic security parameters are often impossible to use
2) What the business challenges are that stop us from using our traditional IT knowledge bases
3) Why traditional network-based security equipment and application delivery equipment can’t compete with business risk when it comes to solving the gaping security hole in our critical infrastructure and factories
PS: You will notice a large number of similarities with the challenges associated when trying to secure medical equipment and IoT devices. Not everything in this blog will apply to those IT areas but a lot of it will.
