Data Link – Layer 2

Second Part of Layers Physical Security – Layer 1

OK - Second Layer. In OSI it is the Data link layer with Collision Detect, Collision Prevent, Ethernet, Token, TDM, and all of the others. In a nutshell it is how the systems talk to each other on a point to point basis. When you are talking Ethernet and switching (especially spanning tree) you get overlap into layer 3.

There are a number of areas where it is significant from an information security standpoint for SCADA systems. In the last 10 years the conversation has become dominated by the Ethernet issues but there are other significant issues occurring as well particularly in the wireless realm.

RS-232 (now iea232) was the prominent linking mechanism for quite some time (defined in 1969). The PLC’s can play the part of either DTE or DCE depending on its function in the design. There are some huge advantages to the RS-232 usages. It supports deterministic timing meaning that actions and responses can be watched real time and reactions can be based on ladder logic layouts without much concern of a “lost” packet. It supports a sufficiently high data transfer rate for most automation processes and it has been well tested and used. RS-232 is falling somewhat out of favor as a connection mechanism in the automation world and largely being replaced by Ethernet for local connections. (boy that sentence is going to generate some hate mail) Although IP is really at the next layer it is part of this shift and in the rest of the networking world this shift happened over a decade ago. If you look at my older posts this synchs with my stand that the automation world lags the rest of the information systems cycle by two to three generations and 8 to 10 years.

There are some substantial security implications of this shift to Ethernet. First of all the shift has just started. Less than 20% of PCN’s are Ethernet but most of them (say 80 to 90%) have direct control connections to the Ethernet network via various aggregation tools/methods such as RSLinx. Ethernet, while very reliable if properly deployed, is definitely not deterministic. Multiple nodes exist on the same structure and they work on a modified collision detect structure. If one node is talking the others wait random periods of time to start. Switches mitigate a lot of this by separating the collision domains but when a destination node is receiving traffic from multiple sources there are still lost packets. This is largely overshadowed by significantly greater data transfer rates.

There are some very specific weaknesses to Ethernet that I am concerned about in the PCN world. The most prominent is ARP spoofing. Without getting into the details (I’ll save that for the follow on PDF’s I am starting to write) arp spoofing involves taking advantage of the way ethernet makes connections to allow one node to “pretend” it is another node. Although I have never seen personally, or even heard of a case of arp spoofing on a PCN the entire architecture would be very vulnerable to it. I think the biggest reason it hasn’t emerged yet is that there is no real need to do it at this point. If there is no authentication to a MODBUS IP node anyway why bother pretending you are from somewhere else. As ACL’s and in line firewalls increase in the prevalence I think the frequency of ARP attacks will increase. This could have a very significant impact on devices that are so fragile that they croak when a syn scan hits them.

Controls for the Data Link Layer are pretty simple. For Ethernet MAC filters (Recently in the form of NAC) and switch configuration shutdown of ports (which overlaps with Physical security) serve as a first layer.

NAC is emerging but still needs some development. What it really comes down to for NAC is that a device needs to talk to an end point to be authenticated in any way (let alone a fancy key exchange followed by certificate verification). Since it needs to talk it has to be given the opportunity to connect to the network. What this eventually evolves into is a means of quarantining a device in an “unauthenticated” VLAN until it is verified by some means. This inserts multiple points of opportunity to overcome the defenses. Any time the layers work against security instead of for it you can almost guarantee that someone will find a hole.

The NAC schemes that seem to be most likely to succeed involve Identification of the MAC as an accepted MAC by an authentication and verification that occurs in a quarantine VLAN. A lot of the schemes are using DHCP because it already has a means of differentiating based on MAC address but this has the weakness of not covering for static addresses. All of these NAC methods require upgrades or replacement of existing hardware for most implementations. Other NAC schemes involve searching for the bad guys and using some other mechanisms to expel them from the network.

VLANS are the next major control associated with layer 2 in the Ethernet environment. Basically they are a means of segmenting traffic into separate “networks” on the same devices. They can be set up using different mechanisms as the differentiators for which traffic belongs to which VLAN. The most common I have seen at sites is a simple port assignment. With this mechanism ports 1-6 are assigned to VLAN Bob, ports 7-12 to Alice and so on. Since each VLAN is a separate logical network they typically “cannot” talk to each other without a layer 3 connection. VLAN’s are often associated with a specific IP subnet (sorry layer three + again here).

The last part is the catch from a security perspective. Network Administrators and Engineers almost always assign a gateway for each that has no filter or ACL to prevent Bob from talking to Alice or worse yet Eve (at a completely different site) from mugging Bob. Just because they are on a different subnet does not mean they cannot talk to or interfere with each other. The problems for this don’t occur at layer 2 but when designing, operating or auditing you shouldn’t think that being on a different VLAN by itself is a protection. A further complication with VLANS set up via Port assignment is that there is often a VLAN used for management or troubleshooting that is assigned the entire port range (or at least overlaps other ranges). Any device that bridges these also serves as an entry point. It also serves to complicate the design.

VLANS can also be based on source MAC addresses, QoS classifications, IP addresses and other means but I haven’t seen that much of the more detailed assignment mechanisms in the ACS world. MAC address differentiators are sometimes used but have most of the same pitfalls of the port based VLANing. Some realistic NAC implementation mechanisms try to take advantage of MAC based VLANing to provide the quarantining I mentioned above.

Key point here. Just because it is on a different VLAN does not mean it is segregated. Try something simple. Ping it from one device to the other.

Already too much writing for the weekend. I’ll continue later this week.

Update:
Continued Here

Digg This