Lew Folkerth on ERC

I have written several times (the most recent being here) about Lew Folkerth of RFC, who has long experience and great insights on the subject of NERC CIP compliance. He writes good articles for RFC’s monthly online magazine, and that tradition continues in his article for the July newsletter (you can find the newsletter here. Then click on “The Lighthouse” on the left side).

I thought the whole article was very good, but I was at first puzzled by the discussion of External Routable Connectivity. I recommend you read at least that section of the article; however, the salient points are in this paragraph:

“Our conclusion, then, must be that the ability of any Cyber Asset outside of the ESP to reach “PLC,” by any path, will give “PLC” External Routable Connectivity. While it may be theoretically possible to demonstrate that no External Routable Connectivity to “PLC” exists in a very small network, this becomes exponentially more difficult as the size of the network increases. Also note that if this position is taken then every Cyber Asset in the ESP with External Routable Connectivity, such as “Internal Workstation” in our example, becomes an Electronic Access Control and Monitoring System (EACMS), as each of these Cyber Assets controls access to “PLC.””

Before we go further, let me say that although I have written a number of posts on ERC (the most recent being this one), I have always focused on the case of a relay in a substation connected serially to an RTU, which is itself routably connected to a control center (in fact, I don’t think I’ve seen any other discussion – before Lew’s – that didn’t focus on the same thing). The question in this case is under what circumstances that serially-connected relay can be said to participate in ERC.

The case Lew is addressing is very different. It’s an all-IP network protected by a firewall. Some of the devices (like “Internal Workstation”) are directly accessible through the firewall; others (like the “PLC”) are not. The security question behind this is whether blocking access to a particular device through firewall rules removes ERC.

I had a phone discussion with Lew about the article, and he clarified a couple points that weren’t completely clear to me from what he wrote. Here are the main takeaways:

1. On a routable network, most OS’s can be easily configured to pass traffic to another machine. So even though the PLC in his example isn’t directly accessible through the firewall, it is accessible if another machine is forwarding traffic to it – and in that case, it has ERC. So if you are claiming that your firewall is blocking ERC for some devices, you have to show the auditor that no devices with ERC are forwarding traffic to other devices. Additionally, you will have to watch the network like a hawk to make sure that forwarding isn’t turned on for a device that has ERC, toward another device that doesn’t.
2. If a device with ERC is passing traffic, it needs to be declared an EACMS. I admit I originally had a hard time understanding this point. But Lew points out in an email “by creating what is effectively a mixed-trust network within a single ESP (devices with and without ERC), the entity is using its devices with ERC as firewalls to keep ERC out of the other devices. This is why the device with ERC also meets the “perform electronic access control” portion of the EACMS definition.” Note that Lew isn’t saying that just the devices that are actually forwarding traffic are EACMS; he’s saying that every device to which external access is allowed by the firewall is effectively controlling access for the other devices on the network, since a small change in its configuration would allow that access.
3. In a further discussion, Lew pointed out that potentially every device in an ESP might have to be declared an EACMS, even if for most of them direct external access was blocked at the firewall.

The bottom line is that you need to think long and hard before declaring that some of the Cyber Assets within your ESP have ERC and others don’t, based on whether or not you’re allowing access to them through the firewall. If you bite the bullet and say they all have ERC, you will of course have a somewhat greater compliance burden, but your audits will be much easier (and you won’t stay up nights worrying that somebody – without telling you – is configuring forwarding on a Cyber Asset with ERC). Or in Lew’s words, “I think the message is simple: ‘Don’t mix trust (ERC and non-ERC) in the same ESP.’ It’s not that you can’t do it, but you’ll have a hard time documenting it. The security risk and the compliance risk make the practice inadvisable.”

However, there is an area Lew still isn’t sure about. That is the question how Interactive Remote Access (IRA) affects this. With IRA, the device needs to be reachable by the Intermediate Server, which is hopefully within the DMZ – but that means that technically the device is reachable from outside the ESP, and thus meets the definition of having ERC. So if the IS is the only device that can directly access any device within an ESP, is there still ERC?

At one point, I started writing “Tom’s Lessons Learned”. This post should be called one of “Lew’s Lessons Learned”. This is really what the Lessons Learned are for: explaining direct implications of the wording of the requirements. Note that for once I’m not complaining about any ambiguity or mis-wording of the requirements here – Lew just pointed out some important implications of the existing wording that probably aren’t obvious to most NERC entities (they certainly weren’t obvious to me!).

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.