FERC’s New NOPR, Part II

This is the second half of my post on FERC’s new NOPR, which was released on July 16, 2015. You can find the first half here. I recommend you read the first post before you read this. Besides repeating the not-so-surprising news that FERC intends to approve the v6 standards, the first post discussed FERC’s request for comments on their proposal (not yet a directive) that CIP be revised to provide protection for communications between all control centers in the Bulk Electric System. This post discusses the remaining issues that FERC is considering for new or revised standards. FERC is asking for comments on all of these topics.

Protections for Remote Access

FERC says they wish to have comments on “the value achieved if the CIP standards were to require the incorporation of additional network segmentation controls, connection monitoring, and session termination controls behind responsible entity intermediate systems.” They base this on statements made by two of the speakers at the April Technical Conference that suggested the need for further protections.[i] I didn’t realize that Intermediate Systems and Interactive Remote Access were so poorly protected with the current wording, but I’ll defer to others who know more than I do about this.

A New Supply Chain Security Standard?

FERC surprised me – and I suspect a lot of others in the industry – with their seemingly out-of-the-blue suggestion (Section E, starting on page 37) that there should be a standard for security of the supply chain. I don’t believe this means having armed guards accompanying trucks delivering transformers, but rather – among other things - protection against the introduction of malicious code at the “factory” level; that is, introducing malware into control system software and firmware.

I’ve certainly known for a while that some people were quite concerned about the possibility that – say – all switches sold by vendor X would have embedded malware that could be “woken up” with the touch of a button by some evil genius in a secure mountain fortress overseas, and that this would lead to a nationwide power outage. But I certainly hadn’t heard a lot of buzz from Congress about this danger, and since the FERC Commissioners and staff always seem to be paying close attention to what is being said in Congress, it was surprising – indeed, refreshing – to see this concern come out of the blue. In fact, FERC freely admits that Order 791 never mentioned supply chain risks at all, so this issue is completely different from all the others discussed in the NOPR, which otherwise all deal with concerns raised in 791.

What surprises me even more is that it’s not at all clear how FERC and NERC – which of course have no direct authority over hardware and software vendors – can write and implement a standard that will result in big improvements in this area. It will obviously have to be done indirectly, by say requiring that new vendor contracts contain certain provisions. And that makes me wonder about any antitrust implications of this effort.

In any case, I do agree with FERC that this is an important concern, and if it can be sufficiently addressed through a standard that applies to a group of customers, not the vendors themselves, then it’s certainly worth examining in more depth. Of course, this concern definitely needed to be addressed in a NOPR, not an Order. However, I believe a separate NOPR would have been better, given that this issue is so divorced from the others discussed in this document. I really doubt FERC will be able to decide what it will do on this issue for quite a while; I certainly hope they don’t hold up addressing all of the other issues in the NOPR until this one can be addressed.[ii]

LERC

This delightful acronym (EnergySec describes it as “Seuss-ian” in a recent newsletter), of course, stands for Low impact External Routable Connectivity. This concept is used (in CIP-003-6 Attachment 1) as a qualifier for how much certain Low impact assets have to be protected, analogously to how External Routable Connectivity serves as a qualifier for some Medium impact BES Cyber Systems. I believe the v6 SDT invented a different phrase because they were worried that, by using ERC in qualifying the Low assets, they might end up having the auditors treat individual cyber assets at a Low asset differently depending on whether or not they had ERC – and that would then lead to being audited at the cyber asset level, which supposedly is strictly verboten for Low assets.  But guess what, SDT? It seems the new term may not have prevented that from happening after all….However, I’m getting ahead of myself.

FERC discusses LERC in Sections 68-70 on pages 43 and 44. They have an issue with the first part of the definition: “Direct user-initiated interactive access or a direct device-to-device connection to a low impact BES Cyber System(s) from a Cyber Asset outside the asset containing those low impact BES Cyber System(s) via a bidirectional routable protocol connection.”

FERC’s issue is not really with the definition itself, but with the fact that they think the word “Direct” isn’t being properly interpreted by NERC. They point in particular to Reference Model 6 on page 36 of CIP-003-6, which purports to show a situation where there is no LERC. In the diagram, an outside system connects routably to a “Cyber Asset” (not a BCS) that is itself non-routably (serially) connected to a BCS.

At first glance, this doesn’t differ significantly from Reference Model 4, in which an “IP/Serial Converter” is in the same logical position as the Cyber Asset in Model 6. However, in Model 4 it is stated that there is LERC, while in Model 6 it is stated that there isn’t. Specifically, the description for Model 6 says “There is a Layer 7 application layer break or the Cyber Asset requires authentication and then establishes a new connection to the Low impact BES Cyber System.” This, in the SDT’s opinion, separates LERC from non-LERC.

FERC states in paragraph 70, “...we seek comment on the implementation of the ‘layer 7 application layer break’ contained in certain reference diagrams in the Guidelines and Technical Basis section of proposed Reliability Standard CIP-003-6. It appears that guidance provided in the Guidelines and Technical Basis section of the proposed standard may conflict with the plain reading of the term ‘direct.’”

To summarize the above, it appears to me (and FERC could have been a little clearer, in my opinion) that FERC wants NERC to provide explicit guidance on what “application layer break” means and why it results in the connection no longer being “direct”. If NERC doesn’t explain this well enough, it sounds like FERC will order that the LERC definition be rewritten. Were that to happen, they should probably order that the ERC definition be rewritten as well, since the best discussion I’ve heard from NERC or the regions on ERC (by Morgan King of WECC. See my recent post on ERC) also relies heavily on the idea of an application layer break (Morgan calls it a “protocol break”). 

This might sound like it’s a nice discussion about semantics, but there is quite an important implication for NERC entities with Low impact assets. Remember that the v5 and v6 SDTs have gone through contortions to make it clear that an inventory of Low impact Cyber Assets isn’t required for compliance – any requirements that apply to Lows are supposed to apply only at the asset level.[iii] However, 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 do at least part of what Mediums and Highs have to do: identify any BCS and show that there is no LERC to any of them.

I started to write this section with my sympathies on NERC’s side of the argument; it appeared to me at first glance that FERC was taking things too far. However, I now see that the v6 SDT may have made a mistake by trying to, in cases where there is an external routable connection coming into a Low asset, assert that in some cases there is no LERC, whereas in others there is. It seems the only way this can be demonstrated is by looking at the individual Cyber Assets, and that will require some sort of inventory. It would probably be better if the definition just said that if there is any routable connection coming into the asset, there is LERC; if not, there isn’t LERC.

What can NERC do to satisfy FERC now? Presumably a guidance document would be sufficient, since the issue isn’t in the requirement itself, but in the Guidance and Technical Basis section of CIP-003-6. This issue should not require a new definition. But if NERC doesn’t provide guidance, or if they do and FERC isn’t satisfied with what they provide, then FERC will probably order a new definition be drafted. But note that, whatever happens, the clarification should apply to ERC as well as to LERC, since the idea of a protocol break applies to both definitions.[iv]

Transient Devices

FERC discusses the new requirement CIP-010-2 R4 for Transient Devices in Section C of the NOPR, which starts with paragraph 33 on page 20. They agree that the requirement, which applies only to High and Medium impact BES Cyber Systems, is good as far as it goes. However, they are concerned with the fact that it doesn’t apply to Lows.

To illustrate their concern, FERC says (page 26, paragraph 42) “For example, malware inserted via a USB flash drive at a single Low Impact substation could propagate through a network of many substations without encountering a single security control under NERC’s proposal. In addition, we note that Low Impact security controls do not provide for the use of mandatory anti-malware/antivirus protections within the Low Impact facilities, heightening the risk that malware or malicious code could propagate through these systems without being detected.”

To discuss the first sentence first, I wonder how many substations are connected like FERC imagines – a lot of substations all on one routable network? If there is any external connectivity in a substation, it is almost always with the control center (which should always have good security controls in place). I’m not an expert on this, but I really don’t think there are many networks where all the substations are routably connected in a peer-to-peer fashion. So I tend to agree with the SDT that the risk of a virus – carried in on a USB stick – propagating like wildfire from one substation (or generating station) to another is fairly minimal.

FERC’s second sentence points out that CIP v5 doesn’t require anti-malware measures at Lows, which FERC says heightens the risk. But I’d like to point out:

1. Just because anti-malware isn’t mandated doesn’t mean it’s not being used. Given the dangers, I doubt there are many NERC entities that wouldn’t always have measures like antivirus deployed wherever possible.
2. For devices where it isn’t deployed, my guess is they mostly are a.) not susceptible to normal malware because they don’t employ a standard OS like Windows or Linux or b.) performing real-time operations that might be hindered through antivirus software.
3. If there really isn’t the widespread connectivity among substations that FERC seems to think there is, the fact that CIP doesn’t require anti-malware at Lows doesn’t really change anything. An infection isn’t likely to spread beyond the substation regardless of whether anti-malware is deployed or not.

FERC goes on in paragraph 43 to request that NERC provide more justification for limiting this requirement to High and Medium impact BCS, and says that if NERC still can’t satisfy them, they will likely direct NERC to extend the requirement to Low BCS. This might be quite a difficult requirement to comply with, since substations are typically not manned. How do you prevent a contractor from plugging in a USB stick if it hasn’t been approved by the owner of the substation – since they will presumably already be granted the physical access they need to accomplish what they were sent to do?

This is a situation where the control, however beneficial, would be mis-applied. The controls need to be applied to the employees and contractors visiting the substation, through policies and training, as well as – in the contractors’ case – legal agreements that make clear what is expected regarding transient devices. But there should not be device-level controls for Low impact assets. If this really is an important issue, FERC should order NERC to make changes to CIP-004[v] so that the training requirements apply to Lows (or a subset of those requirements), not extend CIP-010 R4 to Low impact assets.

Here is Part III of this post.

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

---

[i] Of course, an “Intermediate System” is required of Medium and High impact facilities to control interactive remote access to systems within the ESP. So FERC seems to feel there could be more protection applied to IRA.

[ii] However, see my next post, where I speculate whether FERC actually might want to move the enforceable date for CIP v5 and v6 back from 4/1/16, and whether they’ll use a delay in approving v6 as a means of accomplishing that goal.

[iii] The first draft of CIP v5, which was roundly voted down in December 2011, contained a single requirement that applied to Lows: that default vendor passwords needed to be changed. Since the only way to audit that would have been for the entity to show they’d changed passwords on all of their Cyber Assets, this would obviously have required an inventory of those Cyber Assets. The reaction was so negative that the SDT made sure to remove this requirement in the second draft and just left requirement CIP-003-5 R2, which requires the entity to have four policies – until FERC said that wasn’t enough in Order 791.

[iv] If NERC decides to take my advice and just say that whenever there is ERC into a Low asset there is LERC, then this clarification would not involve the protocol break concept – and it wouldn’t apply at all to ERC (which is definitely a cyber asset-level concept, not an asset-level one).

[v] CIP-004-6 R2.1 already references Transient Cyber Assets in the list of training required, for Highs and Mediums. If this is so important, maybe there should be a similar training requirement applicable to Lows, and also applicable to contractors. But even though that wouldn’t be a device-level requirement, it would also be very difficult to implement; I also don’t believe the benefit from this approach would outweigh the costs required for compliance.