The News from Texas

On Tuesday August 11, 2015, I had the good fortune to listen and watch the webcast of “Chapter 1” of what will be a series of meetings (over the next few months) on CIP v5 run by the Texas Reliability Entity, Inc. (TRE). The series is entitled “The Hitchhiker’s Guide to CIP version 5”, and is being presented as a series of one-day meetings. You can find the slides from Chapter 1 here; there was no recording made.

The presentations were all very good, touching on various topics in CIP v5 compliance (I assume the remaining Chapters will be similar); the only problem was some audio issues for those of us on the phone, which I hope will be fixed before the next Chapter is presented. I don’t believe the date for Chapter 2 has been set. I did just notice that the webcast was only promised for Chapter 1; I certainly hope the remaining Chapters are also webcast.

This post lists the points I found most interesting – I’m grouping these simply by the order in which they occurred in the webcast, not on some judgment of their relative importance.

1.       One of the first presentations was on CIP-002, and it brought up a topic I’ve made the subject of two posts (here and here): the fact that an entity isn’t required to use the same grouping of BES Cyber Assets into BES Cyber Systems for all CIP v5 requirements. That is, the entity can do the grouping one way for one requirement and another way for another requirement. The TRE speaker brought up a good example – that I had also provided in the second of the above posts - of how this could be advantageous. Say you have a lot of devices (perhaps relays) that are all going to have to take a TFE for a particular requirement. Rather than have to do the TFE paperwork for each of those relays, they could all be declared one BCS for the purposes of that requirement; hence only one TFE is needed. You can see other examples of how this might help in the two posts linked above.

2.       Note: This wasn’t said in the TRE meeting, but – because I realize that the above example might require the “Relay BCS” to span ESPs - I’d like to point out that it is fine for BCS to span ESPs, as long as all communications between ESPs goes through an EAP. If that were not to happen, then the cyber assets in the communication path would need to be protected as at least PCAs, since they would be within a single ESP. I want to thank an Interested Party for explaining this to me.

3.       While only a list of BCS is required, it is a good idea to have a list of BCAs, since otherwise you can’t prove that all BCAs are in a BCS. I’ll take that one step further: It’s also a good idea to have a list of Cyber Assets, to show you have considered every one of them to determine whether or not it is a BCA.

4.       Note: This also wasn’t said at the meeting, but I want to point out that, in my “top down” approach to identifying BCS found in this post – not to be confused with TRE’s “top down” approach discussed at the meeting, which is a different thing – you don’t have to identify every BCA, because you start by identifying BCS. You do still need to list all of the components of the BCS, so that you can prove that cyber asset-specific requirements like patch management have been comprehensively applied. But this means there is no need to look at each BCS component to figure out whether it meets the BCA definition; that analysis isn’t required for each component, once it has already been determined to be part of a BCS. The same Interested Party explained that to me, although it was a while ago.

5.       You need to detail how you designed your ESPs, not simply show them on a network diagram.

6.       Similarly, you need to document the process you used to identify EAPs, not just list them. This process should include identifying the traffic that needs to cross the EAP.

7.       In what will I’m sure be a controversial statement, it was said that low entities should document their Low impact BCS, mainly because they won’t be able to prove whether or not they are subject to LERC (Low impact External Routable Connectivity) without this. I discussed this topic in this post, and also during my webinar with EnergySec on Wed. Aug. 19^th. I pointed out that, if an entity wants to argue that a Low impact asset doesn’t have LERC, despite having a routable connection coming into it, this will inevitably result in a list of Low BCS being required; without such a list, they could never prove they didn’t have LERC. This means you will definitely need a list if you are going to make such a claim, but I don’t think you will otherwise.[i]

8.       There was a very good discussion of virtualization; it starts on slide 49 of the presentation. Some of the points that were made included: 1) Mixed-trust virtualization (in which both ESP and non-ESP devices are virtualized on the same virtual server) is allowed (and the speaker said that NERC had admitted this was the case) - however, it is important to justify why this was done; 2) In general, you need to consider how virtualization will affect compliance with each requirement – for example, are the hypervisor and the client device in the same PSP? (They need to be); and 3) If your hypervisor hosts a BCA or BCS, it must itself be a BCA.

9.       During a discussion of scripts and Interactive Remote Access, the TRE auditors confirmed what I and others have been saying for a while (and NERC now agrees with us): that, to address the many areas of uncertainty in CIP v5, the entity needs to determine on its own what is the best way to resolve this uncertainty (after examining all of the available guidance on the issue in question). But what is most important is that the entity document how they came to whatever conclusion they reached.

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

---

[i] My point in the post and the webinar was that it might be better for NERC to simply give up the idea of having any exceptions to LERC. This is because FERC clearly doesn’t like NERC’s current interpretation of LERC, as it is illustrated in Reference Model 6 in the Guidance to CIP-003-6. IMHO, if the rule is made that LERC is present whenever there is a routable connection coming into the Low asset, this will eliminate the need for a list of Low BCS. What was said at the TRE workshop only confirms me in this opinion.