Data Link – Layer 2 Continued

Continued from Layer 2 See also Physical Layer – Layer 1

In the comments on the first half of the post, Dale from Digitalbond mentioned DNP3 as a layer two protocol implemented over Ethernet and correctly pointed out that Modbus IP was an application layer implementation of one of the communication protocols that ran on the older RS-232 links. Ron seconded this. There are a lot of other similar instances as well by many control vendors. They basically packetize simple direct connection communications often (always? as far as I can think) without any authentication. I can think of ones from Rockwell/ABB, Seimens and Honeywell off the top of my head. They were proprietary layer 2 communication protocols and to enable their easy use over IP networks a simple (usually very simple) packet based communication string was set up. Usually a bunch of checksums and CRC's are used to try to deal with the deviance from a deterministic network.

When layer two protocols run on layer two point ot point connections there is rarely much of an issue. Security can be handled as a physical access problem and the realistic threat pool is vanishingly small. Not to many people are willing to either separate your wires from thousands of others, climb to the top of a pole, or dig into a ditch to tap into a single link to a single RTU or PLC. Even if they were it wouldn't net much.

The real risks come from two different implementation mechanisms. Wireless deployments and efforts at implementing layer two protocols over layer 3+ designs and/or integrated with multipoint layer two mechanisms seem to present the most problems.

Now that I think about it wireless could probably be considered just another example of the last point.

A quick comment on DNP3 over IP and Ethernet from a networking standpoint (as opposed to a security standpoint, though this certainly fits with reliability and therefore availability). DNP3 uses a ton of CRC’s so it is pretty chatty from a collision domain standpoint. For smaller implementations this probably won’t show up but for larger sites and for networks that have multiple uses you will have a lot of collision storms if you either have older networking equipment (hubs) that aren't switched or you have a lot of nodes converging at a single point.

This symptom lead to one of the most common security mistakes I see made regarding a misunderstanding of layer 2 and 3 overlap. The “its ok you can’t sniff it because it is switched” response.

First of all in most cases I could care less if you can sniff most SCADA traffic (the whole AIC vs. CIA conversation). I do however care if you can interrupt traffic or worse yet insert invalid traffic (intentionally or not). On Ethernet it is a trivial exercise to do this.

So far I have been spending most of my time talking about wired communications but wireless has been around for a long, long time in the SCADA world. When used exclusively for telemetry it is mostly harmless. The one thing to be very careful of in a telemetry monitoring mode is that open loop decisions that are taken using suspect data are subject to initiating cascading failures. Decisions made remote from a site due to old or inaccurate data can easily lead to a chain of improper system and people responses.

My biggest concern with the wireless deployments and equipment I have seen recently is that they don’t seem to be learning from the mistakes in the IT world. 802.11 equipment is prevalent and it often is just used with default settings. There is a huge pool (many thousands) of people and devices specifically looking for openings in 802.11 networks. Even spread spectrum equipment is often implemented with default factory settings. This results in being able to connect to the back end networks without authentication by simply having the right equipment. Admittedly few people have this equipment but it isn’t difficult to get and is sometimes relatively cheap. Since the background connections for much of this equipment is an IP network it is often trivial to get on to the PCN (sometimes from a great distance away).

In summary SCADA controls for layer 2

For RS-232 or 485 the only real protection mechanisms is physical line security. There is an inherent risk mitigation for RS-232 due to the fact that it is only point to point. Even if you can easily tap (and interfere with) one of the connections realistically it is very difficult to affect the overall operation of the system because there are usually multiple nodes that provide correlating information and control. Unless all or most of those nodes are interfered with there is usually little risk of significant impact.

A single point tap to Ethernet and IP deployments provides access and control functionality to all nodes that are not specifically isolated on that network. This greatly increases the risk. Controls for Ethernet include MAC filters, NAC (not quite ready yet but emerging), VLAN’s, Port disabling/control, node level segmentation and dynamic monitoring and response.

Similar to Ethernet wireless implementations pose the potential risk of access to multiple nodes from a single access point. It is worse than Ethernet in that physical proximity is not essential for the compromise to take place. The easiest control for wireless is simply to not use it unless necessary. Unfortunately it is necessary (actually essential) in many, many instances. If possible, one of the most effective controls is to limit Wireless connections to a point to point model where it is not possible for any of the nodes to access the root communication network. Only the historian or system they need to report to should be accessible. If aggregation points are necessary use some means of authentication coupled with encryption. Avoid using factory defaults unless those defaults include strong node authentication. For 802.11 controls include WEP (for encryption [it makes it just slightly harder to connect and helps protect in other layers]), EAP (and variants LEAP and PEAP) , WAP and MAC filters.

Let me be clear here, I am not saying to not use these technologies. There is an enormous amount of value in using them and in many cases security is actually being improved when they are properly implemented. I am saying to use the controls that are appropriate for the level of safety or risk associated with the system the controls are on.

Digg This