Why VLAN Security isn't SCADA Security at all

Over the years I have been asked by a number of control engineers, “Our IT dept says we have VLANs, so why do I need a firewall?”

Back in the mid-90s, I was a big supporter of Virtual Local Area Networks (VLANs) for security. Unfortunately, I have seen so many issues with this technology that I no longer believe it provides effective security.

VLANS - good for traffic management

Don’t get me wrong - VLANs are great traffic management tools. VLANs work by having Ethernet switches insert a “tag” (basically a 4-byte field) in to the header of each Ethernet message. Other switches on the network can read this tag and make decisions on whether a message should be forwarded.

This allows the switches to provide limited traffic filtering, primarily for managing broadcast traffic. And managing broadcast traffic is important, as incidents like Brown Ferry Nuclear have shown us.

VLANS - not good for security

But switches with VLANs are not firewalls. They operate at layer 2 (the Ethernet layer) and don’t understand the “state” of the messages flowing through them. This makes the spoofing of VLAN tags trivial – there is no check to detect if a tag has been adjusted by a hacker. Thus the hacking community has lots of tools designed to bypass switch-based security.

Dr. Paul Dorey, the former Chief Security Officer at BP made this clear in numerous speeches to the control industry "A router (or switch) is not a firewall so don't try to use it as one."

Many IT experts have also warned of the dangers of depending on VLANs for security. For example, the SANS organization reported on this issue over a decade ago:

"Try not to use VLANs as a mechanism for enforcing security policy. They are great for segmenting networks, reducing broadcasts and collisions and so forth, but not as a security tool." - SANS Intrusion Detection FAQ

But still people think that VLANs are security solutions, resulting in this excellent blog by John Kindervag for the Payment Card Industry (PCI) on why depending on VLAN Security isn't a good idea. Now this blog is referring to security for credit card systems, but I think it is fair to say that what is good practice for protecting a credit card database is good for protecting a safety system in a refinery or a control system in a nuclear facility.

Use a Stateful or Deep Packet Inspection Firewall

If you want security for your control system AT A MINIMUM you need to use a Stateful firewall that will block all traffic EXCEPT permitted protocols between permitted hosts. Even better is to use a Deep Packet Inspection firewall like the Tofino Modbus Enforcer or Tofino OPC Classic Enforcer (these are our Tofino Security products, so note my bias). These filter the traffic at both the TCP/IP layers and at the top layer of the protocol stack, offering a really robust security solution.

Usually the interest in VLANs is because of IT teams wanting to use IT network technology to solve a plant floor security issue. VLANs are good tools, but deploying them for security reminds me of the old saying “When the only tool you have is a hammer, everything looks like a nail.” If you want good security for your control system, you need to pick the right tool, not the handiest tool.


RSS Feed Subscribe to the "Practical SCADA Security" news feed



VLANs are great for separating traffic, provided:

- Your network is configured and maintained by skilled networking staff
- Your networking equipment is not physically accessible for anybody but your networking staff
- All ports availlable to non networking staff is configured as an access port (not allowing trunking)

And of course it goes without saying that the concept of VLANs only separates traffic. VLANs themselves don't make the decision to pass/deny any traffic. That allways has to be some other mechanism in the device itself (e.g. in an L3 switch or firewall) or a separate device. Of course a firewall will always be the better tool to make decisions on allowing/denying traffic over a router, as the latter was never design for this purpose.

One caveat you didn't touch is the availlability of bandwidth. If you share physical links with other unknown/uncontroled VLANs, you have to consider the fact that they might fill up all availlable bandwidth. On a control bus, I would not like to see that happen.

Some good points here - I think we are agreeing that VLANS are fine, when used for what they are designed for by teams that know how to make them work. Unfortunately I see them get extended to applications that don't fit and deployed in ways that aren't secure. Perhaps my biggest concern is with the use of L3 switches or routers as the filtering point on the inter-VLAN traffic, which you correctly point out, were never designed for that purpose (but unfortunately get used that way).

You also raise a very interesting concern that I neglected to mention - the issue of the availability of bandwidth for the control system. We saw some very interesting DoS effects from shared switched networks during the worst of the Slammer infections. I am aware of at least one electrical company that lost their SCADA links because Slammer overloaded the other traffic circuits on the shared switches. Though not ideal, one can use the QoS settings to help prevent this, but how often do people actually use the QoS settings in a control LAN. My guess is "rarely".

One thing I didn't see in the original article is what is the author's opinion on using firewalls to filter traffic between VLANs? Are there any inherent security risks that are associated with a 'Firewall on a Stick' type of configuration?

Any thoughts would be appreciated. Thanks!

Using firewalls to filter traffic between VLANs definitely is an improvement. My first concern with VLANs is always the fact that people use packet filter ACLs on routers for separation. Of course the firewall probably won’t fix bandwidth issues unless QoS filters are set on the switches, but at least the big security issues are addressed.

Do the issue you discuss apply to MPLS defined networks as well?

I find it interesting that the 'VLAN spoofing' bogey-man as a reason not to rely on VLAN isolation.

I'm pretty sure that if I define 'untrusted' ports to be on a particular VLAN and to only transmit or receive untagged frames that there is no spoofing opportunity. If a sensitive application (such as IEC 61850-9-2 sampled values) has a separate VLAN and only the ports for the sending and receiving devices are in that VLAN, and ingress & egress filtering is applied by the switch there will be no way of spoofing.

This does depend on switches supporting symmetric VLANs, and many do not. Too many think that putting a port 'into a VLAN' means only allowing frames tagged with that VLAN out of the port, but accept anything coming in. This is a weakness in implementation, not in 'secure VLANs' as a philosophy.

I am yet to see a firewall that works well with high volumes of multicast layer two traffic, such as GOOSE and sampled values (IEC 61850-8-1 and IEC 61859-9-2).

Add new comment