ICS Security and VLANs – Boogeyman or Helper?
Virtual Local Area Networks (VLANs) should not be counted on as a security feature of modern managed Ethernet switch networks. This is now common knowledge, both in IT departments and also in the Industrial Control Community. Indeed in Eric Byres’ article Why VLAN Security isn't SCADA Security at all he points out that switches with VLANS are not firewalls. But are VLANs the boogeyman of industrial control system security...or are they underestimated helpers? This article examines that question in detail.
“Secure VLAN” Implementations: Network Traffic is Properly Separated
VLANs were conceived by the Institute of Electrical and Electronics Engineers (IEEE) 802.1 working group to segment broadcast domains without resorting to physical network separation (i.e. implementing multiple network structures). With VLANs, network administrators and control engineers could easily define separate ISO-OSI Layer 2 Networks virtually within the existing Ethernet switch infrastructure without installing new and costly hardware and cabling.
Reviewing Eric Byres’ article on VLANs and security led me to think about the problems of forged information in the VLAN tags. It also started me thinking about how the actual VLAN implementation in the switches can have a major effect on network security.
According to the IEEE 802.1Q-2011 specification, VLANs should be completely separated. This means that no traffic that is part of one VLAN shall be visible in other VLANs. This is usually called a “Secure VLAN” implementation – as stated before, it does not offer much security, but at least traffic is properly separated.
VLANs are the boogeymen of industrial network security if they are used for separating traffic. However, when used for prioritizing traffic they contribute to the functioning of a well-designed control network and help defend against denial of service attacks.
“Leaky VLAN” Implementations: False Separation of Traffic that is Easily Hacked
Some VLAN implementations interpret the standard a little bit more freely. In these implementations, only the Layer 2 Broadcast traffic is separated. Multicast and unicast traffic is still visible in all VLANs, not just the VLAN they should belong to. This is usually called a “Leaky VLAN” implementation.
A leaky implementation still mostly prevents devices on different VLANs from communicating with one another because protocols used for device discovery (e.g. the Address Resolution Protocol, ARP) are needed to establish initial contact between devices and enable higher layer communication. Usually, these protocols operate using Layer 2 Broadcasts. So in a leaky VLAN environment, devices could potentially still communicate with each other via unicast, but they are prevented from actually discovering each other because the leaky VLAN blocks the broadcast traffic necessary to start the session.
This is even worse for security reasons, as it only suggests network separation, while most of the traffic is actually visible everywhere. A potential attacker could easily capture unicast and multicast traffic from all network devices and also attack all devices on the network. They could do this just by connecting to any arbitrary network interface, listening in on the network traffic, discovering MAC addresses and initiating connections manually. So this is another reason not to trust network security to VLANs, they can provide a very false sense of security.
VLANS do have a Role in Control Networks Designed for Security
Despite all the drawbacks with depending on VLANs as a security feature, they can be very helpful in preventing certain attacks to the network. They are also a very good supporting feature in a control network that is properly designed for security.
This supporting feature is actually not related to separating traffic, but to traffic prioritization, sometimes also called “Class of Service”. Each VLAN tagged frame, in addition to the 12 Bit VLAN identifier, also carries a three bit field, called the Priority Code Point (PCP). The PCP denotes the priority of the frame in context to the application and all other traffic in the network.
These three bits allow for a total of eight distinct priorities that are used in a strict fashion by the switch. This means that a frame of a better priority is always preferred by a VLAN-aware Ethernet switch over a frame of worse priority when queuing effects occur. A frame belonging to critical SCADA control traffic could be tagged with a better priority value than background IP traffic, so it is always preferred over uncritical background traffic.
This helps to ensure that critical traffic is treated with better priority to ensure that it reaches its destination in time – a characteristic very important in control networks.
A denial of service attacker with physical access to a network port would be defeated if the Ethernet switch is configured such that all exposed and/or unused ports are in “untrusted” mode and that port priority is set to the best effort value.
VLANs Help Defend Against Denial of Service Attacks
This functionality can also help to defend against a denial of service attack where a traffic generator is used to congest the whole network.
A potential attacker with physical access to a network port somewhere in the control network could use VLAN tagged frames with the highest priority (PCP = 7) to flood the network and occupy all available bandwidth, leaving none for the control traffic.
To prevent this, all exposed and/or unused ports of an Ethernet Switch should be configured to be in “untrusted” mode. All ports that are not exposed, or ports to which control devices are attached are put in “trusted” mode. “Trusted” means that the switch accepts the PCP that is included in the frames that are being received. “Untrusted” means that the switch, as soon as it receives a VLAN tagged frame, replaces the PCP in the received frame by the priority that is configured as port priority on that specific switch port.
By configuring the port priority on an Ethernet switch port to the best effort value (this is usually the default value configured in devices), all incoming traffic is mapped to the best effort class, regardless of what the incoming frame says the priority was. This means that the attacker cannot monopolize all the available bandwidth by giving his or her packets the highest priority. All critical control traffic can still be transmitted, because the switches treat it with a higher priority than best effort.
This technique even works when the end devices on the trusted ports, such as a PLC, do not support the sending of VLAN tagged frames. In this case, the priority that is needed for the control traffic (e.g. PCP = 5) is configured at the switch as port priority on the trusted ports. The Ethernet switch will, upon ingress of the frame, encapsulate it with a VLAN Tag with the correct port priority and upon egress towards the recipient, it will remove the VLAN tag.
Designing Control Networks for Security from the Ground Up
Thus while VLANs alone cannot do much to secure your control network, they can be a vital part of any modern control network or mission-critical network that is designed from the ground up with security in mind. This is a crucial factor of success today and will be even more so as network convergence and complexity increase over time.
Combining SCADA security tools and appliances as well as using features of today’s managed switches (e.g. VLANs, ingress policing, and redundancy for fault-tolerance), enables control engineers to build robust and secure networks.
Unfortunately, often modern Ethernet switches are not taken into account when the security design aspects of a control network are discussed.
Do you factor in switch capabilities when designing your control networks? If so, what were your experiences? I look forward to hearing from you.
Practical SCADA Security Article: "Why SCADA Firewalls Need to be Stateful"
• Blog: Why VLAN Security isn’t SCADA Security at all
• Blog: SCADA Security and Fault Tolerance - A Beautiful Pairing!
• Blog: Why SCADA Firewalls Need to be Stateful – Part 1 of 3
• Blog: Why SCADA Firewalls Need to be Stateful – Part 2 of 3
• Blog: Why SCADA Firewalls Need to be Stateful – Part 3 of 3
© Tofino Security 2013 | All Rights Reserved | Tofino Security is a Belden Brand