CIP-003-7 and CIP-003-8

There have been many confusing developments in the history of the NERC CIP standards, but I have to say that the situation regarding CIP-003 in early 2020 really takes the cake. I’ll try to summarize it, going back to the beginning:

• When FERC approved the CIP v5 standards in Order 791 November 2013, they indicated they didn’t think CIP-003-5 R2 was adequate. This is because it just listed four policies that needed to be developed for assets containing Low impact BES Cyber Systems (which literally everyone including me calls “Low impact assets”, even though that’s not technically correct). FERC wanted more concrete measures to be taken for Lows – i.e. they required NERC to flesh out the four policies with concrete requirements.
• This became one of the main tasks of the CIP Version 5 Modifications standards drafting team, and they delivered it in CIP version 6. In v6, the four policies for Lows were moved from R2 to R1.2. R2 now became a requirement to have a plan for Low impact assets, which included the four sections in a new Attachment 1. But Attachment 1 is R2, for all practical purposes.
• When FERC approved v6 in Order 822 in January 2016, they approved parts 1 (Cyber Security Awareness), 2 (Physical Security Controls) and 4 (Cyber Security Incident Response), but they said they wanted part 3 to be changed (while at the same time approving it). In practice, this meant that NERC would have to develop a new version of CIP-003 that included the change. NERC could still have implemented CIP-003-6, followed by CIP-003-7 when it was developed, but the Implementation Plan for CIP-003-7 stated that v6 wouldn’t come into effect (it still wasn’t in effect when v7 was approved). This means that when CIP-003-7 is implemented on 1/1/20, this will be the first time compliance with section 3 has been required.
• CIP-003-6 introduced two new concepts. Low impact External Routable Connectivity (LERC) adapted the concept of External Routable Connectivity (which was developed with CIP v5, but only applied to High and Medium BCS) to apply to Low assets. Similarly, Low impact Electronic Access Point (LEAP) adapted the Electronic Access Point concept from CIP v5 to Lows. Section 3 in v6 essentially stated that, for every Low asset that had LERC, the entity needed to implement a LEAP – which essentially meant to install a firewall.
• FERC’s objection was to the word “direct” in the LERC definition. I won’t discuss the objection now, but you can read the discussion in the post I just linked a couple bullet points ago.
• In the same Order 822, FERC required NERC to develop a requirement for controls of Transient Cyber Assets (TCAs) used at Lows. This became Section 5 of Attachment 1 in CIP-003-7.
• A new drafting team, the Modifications to CIP Standards team, was constituted to address FERC’s objections in Order 822, as well as a number of other items added to their plate by NERC (including virtualization, which the team is working on at this time). I attended their second or third meeting, which was held in early July 2016 in Chicago.
• In that meeting, they – unexpectedly to me – decided that the only way properly to address FERC’s request was to radically revise Section 3. It now became essentially a risk-based requirement, requiring that the entity mitigate the risk to BCS posed by the presence of any external routable connectivity at the Low asset (even if only IT assets are routably connected externally). The highlight (for me, anyway) of the requirement was the set of “reference models” for different cases of external connectivity, found in the Guidance and Technical Basis. Since both the LERC and LEAP definitions were retired (without ever having been born in the first place!) when the v7 requirement superseded the v6 one, the reference models essentially became the new “definition” of ERC for low impact assets. The implementation date for CIP-003-7 was set for 1/1/20.
• R3 will be implemented as drafted for CIP-003-7 on 1/1/20. However, when FERC approved CIP-003-7, they said they wanted a change in Section 5, regarding TCAs at Lows. Specifically, they were concerned about Section 5.2, regarding TCAs managed by a third party (e.g. a vendor).  This requires “..one or a combination of the following prior to connecting the Transient Cyber Asset to a low impact BES Cyber System…:” It is followed by five bullet points joined by “or”, each starting with the words “Review of..” – for example, “Review of antivirus update level”.
• FERC’s objection was that just requiring the entity to “review” what the vendor has done to mitigate risks posed by TCAs isn’t enough – the entity needs to take some concrete steps to mitigate any residual risk, if they decide the vendor hasn’t done enough in this regard. Meaning, for example, that if the entity decides the vendor has done a bad job of controlling malware on a TCA, they should take steps like barring its use at Low assets.
• Of course, this meant NERC had to develop a new version of CIP-003 to include this change. Fortunately, since the CIP Modifications SDT (which developed CIP-003-7) was still in operation, NERC assigned it the task of developing CIP-003-8 (and seeing it through the ballots and comments, of course). In due course, the team developed CIP-003-8, which is identical to CIP-003-7 except for a single sentence added to Section 5 of Attachment 1. This requies the entity to “determine whether any additional mitigation actions are necessary and implement such actions prior to connecting the Transient Cyber Asset.”
• Because this was such a small change from CIP-003-7, the implementation date for CIP-003-8 was set for 4/1/20.

This is how we came to the situation in which NERC entities with Low BCS will implement CIP-003-7 on 1/1/20 and CIP-003-8 on 4/1/20, even though the two versions are close to identical. In fact, they really are identical, if you just apply a little common sense. In ordering the change that led to CIP-003-8, FERC seemed to be assuming that NERC entities, upon learning that a vendor doesn’t have good anti-malware controls for their TCAs, will completely ignore this information and won’t make the slightest attempt to restrict that vendor from using the TCA in a Low substation or generating plant.

Anybody with the slightest familiarity with how electric utilities operate (or almost any other company with a competent IT department) when it comes to preventing malware infections on their networks will know that the discovery that a vendor isn’t doing a good job of preventing malware on their TCAs will set off alarms all over the place, and the vendor will probably not be allowed to bring any laptop at all onsite until the utility is absolutely sure the problem has been fixed. In fact, the vendor might be terminated for this reason. The impact of a malware infection is so great that no competent organization would even consider not taking drastic measures in a situation like this.

In other words, the wording in CIP-003-7 was fine as it was. It would be nice if it had included more than just requirements for “review”, but it’s 100% certain that it would have been interpreted as requiring mitigation of any problems found in the review – both by entities and auditors. In fact, I think the problem was actually addressed in CIP-003-7. The five bullet points in Section 5.2 that begin with “Review” are followed by a bullet point that reads “(or) Other method(s) to mitigate the introduction of malicious code.” This could have been worded better, but I think it is essentially saying that, if the review turns up a problem, the entity must deploy other method(s) to fix the problem – like ban the vendor from the substation or plant altogether.

As it is, because FERC was so worried that NERC entities are, well, stupid enough not to do anything when they know a TCA may be full of malware, NERC was forced to do the following:

1. The SDT had to debate the change and come up with a first draft.
2. The draft had to be submitted to the NERC ballot body for a ballot and comments. It didn’t pass.
3. A second draft had to be developed, which was then approved.
4. It then was cleaned up by the legal staff, and submitted to the Board of Trustees for their approval.
5. The Board approved it, and it was submitted to FERC for their approval.
6. FERC finally approved it – this time without asking for any further changes! – earlier this year.
7. Finally, the entities will need to implement CIP-003-8 on 4/1/20, even though it’s 100% certain that their procedures will need no change at all (although some documentation will have to be changed, and everyone will need to be reminded on 4/1/20 that from now on they’re complying with CIP-003-8, not CIP-003-7). And I can assure you that NERC entities with Low assets have spent a lot of time worrying about this change and whether it’s really as simple as it looks, or whether there’s actually some monster hidden in the added sentence, that’s going to jump out and bite them in an audit three years from now.

Tell me, do you think the Bulk Electric System will be one bit more secure when CIP-003-8 is implemented than when CIP-003-7 is implemented? I didn’t think so; neither do I. This was an entirely unproductive exercise. FERC shouldn’t have required the change in the first place. However, if NERC’s Rules of Procedure had allowed a minor change like this to be developed and inserted in a four-hour meeting (which is probably all that would have been required), rather than requiring an effort by a number of people spread out over about a year's time, FERC’s directive wouldn’t have required much work and time to address.

And here, Dear Children, lies the moral of our story: Nobody is to blame! Everybody was doing their jobs. FERC’s rules don’t allow for requirements that are badly worded, even though the real meaning will be crystal clear for everybody; they need to be changed, period. And NERC’s Rules of Procedure don’t allow a standard to be modified once it’s been approved by the Board of Trustees. Given that, it was inevitable we would go through this whole process, even though probably every single person involved realized it was all a waste of their time.

And since I’m a Big Picture sort of guy, here’s the Big Picture: This is the problem across the board with NERC CIP. A huge amount of time is spent (by NERC, FERC, the Regions, and NERC entities) developing, approving, complying with and enforcing requirements that are often wildly inefficient and – in cases like this – completely ineffective. But thank God, everybody is doing their job!

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. My offer of a free webinar on CIP-013 specifically for your organization remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.