The News from WECC, Part IX?

I have been attending WECC meetings on NERC CIP since 2008 – as many as possible – and have always found quite important pieces of information in them. I’ve written a number of posts on what I learned or what went on in these meetings, some called “The News from WECC” and some with other titles. I’m guessing this might be the ninth such post, but I’m not sure. In any case, the sheer size of these meetings (always at least 250 people, usually 350-400), coupled with the size and talent of the WECC CIP audit staff (9-10 auditors), has always led to some good discussions and good information.

So it was with WECC’s “Advanced CIP Training” that I attended in Salt Lake City on September 9 and 10, 2015. This training had originally been billed as “CIP 101” (the same title used the previous year), but that was changed in the last couple of months. It seems we all graduated to Advanced even before we attended the course! Not having an overall theme for what I’m going to write, I’ll simply list the different things I learned in roughly the order they were mentioned in the meetings.

I recommend that any entity, no matter what region they’re in, take a look at the slides from this meeting. You can find them here. I particularly call your attention to the slides (in almost all of the presentations) showing likely Data Requests and Sample Interview Questions; these are good for audit preparation, even if you’re not in WECC.

What Breaks External Routable Connectivity?

As discussed in this post, FERC made clear in their July NOPR on CIP v6 that they didn’t like NERC’s idea of what can “break” Low Impact External Routable Connectivity (LERC) at Low impact assets. Specifically, they said they didn’t like Reference Model 6 in the Guidance and Technical Basis section of CIP-006-6, which stated that there can be a “protocol break” in conjunction with a change in the communications stream from routable to serial. As I discussed further in this post, this argument can well be construed as applying to ERC (i.e. for High and Medium assets) as well.

In the meeting, I asked Morgan King, the WECC auditor who had elaborated the idea of a protocol break in ERC at WECC’s January CIPUG meeting, whether he still thought that entities could claim this “exemption” – for either Low or Medium/High BES Cyber Systems. As I expected, he said no – that FERC’s opinion clearly carried weight for LERC and ERC, even though it had only been expressed regarding the former.

But even though FERC didn’t like the general idea of “protocol break”, they didn’t say there was nothing that could break ERC in the case where the end devices were serially connected, as is often the case with relays. Morgan agreed with me that, if a device that “translates” routable to serial communications requires re-authentication of the user, this still does break both ERC and LERC. And Morgan did allow for other means of breaking ERC/LERC as well (this post lists another situation that I would think fits that bill).[i]

But there’s a Catch to This, in the case of LERC

When I wrote about the NOPR, I pointed out “…if the entity is going to prove that there is no LERC at a particular Low asset – when there is clearly some routable connection going into the asset – then they are potentially going to have to identify any BCS and show that there is no LERC to any of them.” I said this because I saw no way an entity could prove that Cyber Assets at a Low asset don’t have LERC without being able to demonstrate this for every Cyber Asset. And this means there needs to be a full inventory of cyber assets at that asset.

Wanting to see if WECC saw this the same way, I first asked the question whether WECC will require an inventory of all Low BCS. The inimitable Dr. Joe Baugh, the WECC auditor who specializes in asset identification issues, said no. I then asked Joe whether if an entity were going to claim, for a Low asset that has some sort of external routable connection, that there is not in fact LERC at that asset, they would potentially need to be able to show this was the case for every BCS. He said yes, and admitted that in such a case, the entity will need to have an inventory of their Low BCS at that asset. My guess is the other regions would probably say the same thing; but as in most cases, you need to check with your region if you question this.

LIBCS

This was the first time I saw this acronym used in the NERC community, but I predict it will be a big hit. Of course, it means Low Impact BES Cyber System. And Josh Reber helpfully suggested some even better acronyms on slide 8 of his presentation. My favorite is MIBESCSWERCATAEACMSAPACS.

CIP-002

You should do an annual inventory of Cyber Assets for CIP-002 to make sure you haven’t missed any newly-installed devices. The one exception I would make to this rule is when an entity has a rock-solid change control process, and they will always know when a new device has been installed.

CIP-004

In Josh’s presentation, he mentioned that many entities had wondered what is the typical number of roles that other entities have delineated for training purposes in CIP-004-6 R2. He was quite frank: they typically see between 8 and 15 roles. Now you know.

CIP-005 (Andrews)

Joe Andrews gave a great presentation on CIP-005. Some of the points he made:

• He distinguished between “Discreet ESPs”, in which the entire ESP is contained within one PSP, and “Extended ESPs”, in which an ESP crosses between rooms or even buildings, and there is some cabling that goes outside of the PSP. The new CIP-006-6 R1.10 is intended to address Extended ESPs.
• He pointed out that to separate networks of different trust levels, you need a Layer 3 device – not a Layer 2 device with VLANs.
• He said network gear needs to be identified as BES Cyber Assets, since it meets the BCA definition. To be honest, I think there might be some disagreement on this point, so you should check with your region if you don’t agree with this.
• He said there can’t be mixed-trust VM environments. So you can’t have some devices on a VM server that reside in an ESP, and some that don’t. I believe I heard the opposite on a recent TRE webinar, but as with all questions on CIP v5, check with your own Regional Entity.

CIP-005 (King)

In case you have any doubt that some of the thorniest issues in CIP v5 are in CIP-005 (although I’d say it takes second place to CIP-002 in that regard), they will be allayed when you note that there were actually two presentations on CIP-005 at this event, totaling about 140 slides. The second presentation was by Morgan King. Two (of many) interesting points in his presentation:

• He pointed out that the NERC Lesson Learned on Interactive Remote Access provides a good guide to when a remotely-executing script constitutes IRA and when it doesn’t. See slide 85.
• He noted that an Intermediate System (IS) should be in the DMZ, but an overriding consideration is that it must be in a PSP; this is because an IS must be declared an EACMS (per the definition of IS). So if your DMZ is outside of the PSP, you need to include the IS within the ESP/PSP.

CIP-007

Eric Weston and John Graminski did an extensive presentation on CIP-007-6, which I recommend you read. Some of the interesting points they made:

• There is such a thing as an “in-line antivirus proxy device”, which in theory can protect all of the cyber assets within an ESP. They didn’t say this would eliminate the need for anti-malware software, but they did point out that it is a good precaution in case there are devices that don’t have updated A/V signatures.
• For CIP-007 R1.2 compliance (physical ports), it’s not OK to just put signs warning against use of USB devices on the PSP. They need to be on the device itself (or its cabinet if locked).
• For R1.1 compliance, a host-based firewall can be used as evidence that a service is disabled. However, this doesn’t help for purposes of compliance with CIP-010 R1.1; that is, it doesn’t constitute evidence that a logical port is not “network accessible”.
• (This point was actually made by one of the participants) You can’t justify a port just by saying “The vendor requires it.” You need to point to some reason why it has to be enabled.
• In R1.4, logging can be performed at either the cyber asset or the system level (which brings up a good point: Some of the requirements in CIP-007 can only be performed at the cyber asset level, e.g., R1 and R2. For these requirements, the words “BES Cyber Systems” in the Applicability column should be replaced with “Components of BES Cyber Systems”).
• For R4.2, the Guidance implies that real-time alerting can be accomplished with technical means only. But the actual requirement allows for procedural means as well.

  

There's a follow-on to this post here.

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

---

[i] I’m told that NERC’s comments on the NOPR introduce a new term: “security break”. It seems like it’s essentially an authentication break, which I certainly hope FERC agrees is something that would break LERC (and probably ERC as well).