Skip to main content

SCADA: Changing the dynamic

(Image credit: Image Credit: Wright Studio / Shutterstock)

How do we build a truly resilient security framework directly incorporating micro segmentation into the SCADA systems and our network in order to protect it, when we can’t add security controls for fear of the business consequences?

I think the solution is quite obvious on the surface: change the dynamic that has existed within our communication-centric IT world since the inception of ARPANET. What do I mean?

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 so on.

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.

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.

The questions you are all asking yourself now are “how did we get here?” and “Why would anyone build anything this insecure?” The answer is so simple: we never anticipated these networks would communicate with the outside world.

PCD and SCADA environments were meant to be ‘closed loop’ and therefore air-gapped. If you think about it, that was a perfectly good assumption. Why would factory machinery ever need to access the internet, or a power plant, or an oil rig. I could go on and on. However, this paradigm changed for two reasons.

1) Manufacturers wanted data. They wanted this data so they could analyse why two of the exact same machines could have different output, or to see predictive failures.

2) Later on, we wanted to change the system environments to compensate for the parameters we had received from the data to optimise performance and/or to stop failures before they happened (an example of this would be varying the turbine speed at a power plant during warm and cold months in order to optimise power output. The ability to do this manually saves thousands of dollars each year and allows manufacturers to scale their support exponentially).

The problem

The internet and its predecessors have all been focused on one thing – creating ease of communication. TCP IP, the foundation for our internet technology addressing a delivery system, is a very promiscuous protocol. IP addresses, by design, like to advertise where they are. Yes, we have firewalls and Network Address Translation (NAT) etc., but NAT was built to solve a different problem and so only solves half of this problem. Once I am on the network and I do a port scan, I get IP addresses.

The second part of the problem is that in today’s world, every access port is generally connected (physically and logically) to every other data centre port (or every asset port). In other words, a route exists between every port on the LAN to every other port in the LAN. You may be thinking “what about VLANS?” There was a time when this logically-connected problem was solved through the use of VLANS. That time is long gone. The advent of the laptop and wireless technology forced companies (in the interest of mobility and agility) to provision access VLANS everywhere to give every physical access port a logical route to every other access port to the data centre.

Then came VMware and the ability to v-motion. Driven again by the need for agility and mobility, we trunked all VLANS to all assets, as it seemed like a good idea at the time. The corollary is that anyone on the network (good, bad or indifferent) has a route to the key company jewels. It’s the same conundrum we keep finding ourselves in, which kills me because in the physical world we would never build a bank without doors or a vault just so it would be easier for the customers and the tellers. The good news is we don’t have to try to solve the problem the same way we have for the past 30 years. We can innovate, and instead of trying to bolt security on, we can try make security an integral part of the solution.

What I’m suggesting is not a new idea, but it is an idea whose time has come and whose proponents have finally made easy enough to be accessible to the masses: Stealth networking. Encapsulate IP in a transport protocol that is the opposite of promiscuous, and create an environment where routes to the crown jewels are transient and are created only as needed when a person/user with appropriate credentials logs on, and are automatically deleted when that person exits/unplugs.

The solution

Thus even if the “bad guy” breaks through the outer defences and gets into your firewall, he cannot go any further because the routes to infiltrate the network do not exist. If malware infects a server, lateral infection spread becomes far more difficult because there are far fewer routes (in the SCADA world there may well be none).

The best part is this solution is heavily couched in automation technology and configuration is easy as pie. Two of the leading IEEE standard protocols that have inherent stealth networking capabilities are Shortest Path Bridging (SPB) and HIP (Host Identity Protocol). Most security practitioners you talk to today will advocate micro segmentation, so think of stealth networking as dynamic micro segmentation.

The biggest risk that remains when using stealth networking (network or application-based) is that an identity can get hijacked. That is why a robust two-factor authentication system in conjunction with stealth networking technology is the best way to ensure the integrity of your systems. Out-of-band WAF and DDoS, and the best ways to ensure availability of the systems and choosing technology that adds the least latency is the key to ensuring that the systems warranty is protected.

In my opinion, if you do the things discussed above and add a cyber-security insurance policy into the mix, you will have done your due diligence and gone a long way towards protecting your company and its reputation.

We can and should do more than just meeting compliance requirements. We should do our best to protect our environment, improve corporate governance and potentially save lives.

Daniel Lakier, VP-ADC, Radware
Image Credit: Wright Studio / Shutterstock

Daniel Lakier
Daniel Lakier is VP-ADC at Radware. Daniel has been in the technology industry for over 20 years, working in multiple verticals including the energy, manufacturing and healthcare sectors