ICS Security and VLANs – Boogeyman or Helper?

Submitted by oliver.kleineberg on Thu, 2012-08-09 08:51

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.

Related Content

Practical SCADA Security Article: "Why SCADA Firewalls Need to be Stateful"

 

Download this Article and receive:

  • How Stateless and Stateful Firewalls work
  • How a PLC can be attacked using the HTTP protocol
  • The relevance of Stateful Firewalls in today’s ICS

Related Links

 

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

Comments

7
Submitted by Chris Huntley (not verified) on Thu, 2012-08-09 19:09

Using correctly designed and configured switches (e.g. leaks excluded), with secure SNMPv3 management, can provide the complete isolation of critical traffic on some ports from untrusted traffic on other ports.
This does not stop DoS of course, but does prevent spoofing etc.
Plus this does not need any security-key management.
The article's author should have indicated how to tap the power of VLANs for the isolation of untrusted traffic, not throw them out with the kitchen sink because some products are unsuitable.
Even the esteemed IEC 62351 standard (for securing communication channels for power system protection) recommends the use of VLANs, particularly for time-critical applications.

Submitted by Eric Byres on Fri, 2012-08-10 10:30

Hi Chris

First I want to be clear that I am not against the use of VLANs in control systems. They are a very useful technology for managing traffic flows and QoS. I am also very much in favour of using them to enhance security as Oliver suggests in the above blog. The more layers of defense we can bring into play, the better.

Where I get concerned is when people use VLANs as their sole isolation technique. As you know, VLANs were not designed to be a security solution - they were designed as a traffic management solution. So I disagree with your statement that “correctly designed and configured switches can provide the complete isolation of critical traffic”. VLAN hopping via double tags is an easy technique to execute and far too few switch products provide defenses against it (BTW, the Tofino was specifically designed to detect and prevent this attack).

So by all means, use VLANs to improve your control network security. Just don’t use them as your primary Business Network to Control System Network isolation technique. That is just too risky in my opinion.

Submitted by Bob Lockhart (not verified) on Mon, 2012-08-13 11:36

Agree VLANs are only part of the solution - they are no more a magic bullet than whitelisting (which btw I have never heard a vendor make that claim for either technology).

I was also hoping for some discussion of whether or not VLANs are a useful architectural construct in cordoning off very old serial devices from modern IP-enabled devices, given that the two categories might not have the exact same security needs. Even if complete isolation cannot be assured.

What I don't understand is how it is possible to explain in great detail how VLANs can prevent DoS attacks and then claim that VLANs "cannot do much to secure your control network." If preventing DoS on a reliability-focused control network isn't much, what is???

Submitted by Eric Byres on Thu, 2012-08-16 12:19

A discussion of whether or not VLANs are useful for cordoning off old serial devices is an interesting idea. Oliver and I will discuss and maybe it will be a future blog.

Now your last sentence takes Oliver's comments out of content. What he actually wrote was "VLANs ALONE cannot do much to secure your control network" (my emphasis on "ALONE"). His key point is that VLANs can be a useful arrow in the security practitioner's quiver, but not on its own - it must be used with other defences.

And while I also have never heard a vendor make the Silver Bullet claim for VLANs (unfortunately I have for white listing), it is the end-users that do make it. Many times I have been told "Our control system is secure because we use VLANs, so we don't need firewalls, white listing, etc." It is the end user, not the vendor, that this blog message is directed too.

Submitted by Joel Langill on Sun, 2012-08-19 15:12

I guess if you only consider VLANs as described above, it would appear that they really do not add security to the architecture. Sure, I try to explain to people that VLANs alone really don't count as much of a security control. However, when you consider VLANs as a form of Network Segmentation, it takes on new light.

Segmentation is covered by all major standards and best practices including ISA-99, ISO-27001/2, NIST 800-53, etc., and are really the foundation of more advanced security controls that comprise a true defense-in-depth position. VLANs provide layer 2 segmentation, that will not necessary prevent a particular security breach, but equally important, they provide "post-event" network isolation that is vital in limited the speed and ease of lateral propagation of network-borne malware.

If you look at the details contained within the soon to be released ISA 99.03.03 (which will probably be released as IEC 62443-3-3), VLANs can in fact be used for network segmentation for these security Zones that possess a Security Assurance Level (SAL) of 1 [reference SR 5.2]. This may seem insignificant, but when you consider that based on the recent RISI data, most ICS events are in fact caused by "accidental" or "unintentional" actions from "insiders". This is how I would interpret SAL-1 controls for SR 5.2.

Remember, if you can't "prevent" an attack, make sure that you can "detect" it once it occurs, and have the necessary controls in place to "contain", "mitigate" and "investigate" the event.

Stay secure!

Submitted by oliver.kleineberg on Mon, 2012-08-20 15:46

Hi Joel.

When considering VLANs as one of the components of your network security architecture, one has to make sure that the technology implemented in the LAN is really "Secure" and not "Leaky" as described above. Only then can you be sure that the VLAN actually segments traffic. Usually, all Technical Reports, White Papers and Standards (including IEEE 802.1Q) assume that this is the case with VLANs, but you can't rely on it... as it is specific to the silicon that is used in the switches.
So when you have a leaky implementation, you can still use it for means of protecting your network against bandwidth starvation by implementing CoS (Class of Service) features. But only a "secure" implementation really gives you the opportunity to do both: Network/Traffic Segmentation and CoS.

And I agree with your statement, that detection is just as important as containment, mitigation and prevention. In modern switched automation networks, usually a Network Management System is in place that configures and monitors all network devices. It usually can draw a topology map and can alert the user to any deviation from standard operation, such as failing links, deviation from standard network load, device administration, etc.

This is why I always say that security in modern, switched automation networks is and can never be a single feature and a single device, but everything comes down to getting your systemic approach right. Too many people are still thinking in fixed terms: "This is a firewall, it will make my network secure." or "This is a switch, it will transport my frames." There is no single, simple answer. But the more you think in systems and utilize all strengths of the involved technologies, the more secure and robust your network will be. Understanding your specific VLAN (implementation) and how it can be used is one piece of the puzzle.

Submitted by Rick fell (not verified) on Mon, 2012-08-27 15:02

When is it ok to share your virtualized infrastructure and when not. Consider the following:
An off-shore oil rig needs Internet access for its on-site contractors, a local business LAN for common access to local file and printers and on-shore email, two CCTV networks one for security and one for watching the flares and compressors, a bunch of LCN's, some CSN's, a PCN, wi-fi for the maintenance crew and wireless to some instruments, IP phones, a DMZ to buffer the business net from the ICS, and a remote operations center on-shore. Firewalls are used to enable restricted access between security zones.

To minimize cable runs and switch counts, the network design team makes heavy use of vlan trunking. The data flow diagrams are reviewed and determine the right controls are in place and testing shows only authorized IP addrs can get to where they need to.

However, the many LAN switches have Internet, ICS, SIS, IP phone, business LAN/PIN ports on them. Adding to the mix are VIrtualized hosts on common hypervisor servers running OS's for the ICS and PIN... also trucked to these same switches. Going to shore - MPLS, or VRF router virtualization is used.

ISA-95, ISA-99/IEC-62443 do not appear to address virtualized layer-2, layer-3 and higher, nor where virtualized services are shared among level 2, 3, 3.5 nor 4. Yes, we're using layer 3 firewalls, but missing all the traffic that is running around and parallel to it.

We need some standards around virtualization - and not be limited to how it's used within a single security zone.

Add new comment