FERC’s New NOPR, Part V: The Big Problem

This is the fifth and last in a series of posts on FERC’s October NOPR. The NOPR was issued in response to NERC’s filing of two changes to CIP-003-6 R2, regarding Low impact assets; these changes were both included in CIP-003-7, which was approved by the NERC ballot body and the NERC Board and submitted to FERC early this year.

While saying they intended to approve CIP-003-7, FERC in the NOPR proposed to order two further changes to it; these changes will be incorporated in a new version of CIP-003, most likely called CIP-003-8. I discussed the first of these changes in my last post. This post discusses the second change that FERC is proposing to order, which deals with transient cyber assets and removable media used at Low impact assets. Unlike the first change, which took a long time for me to explain, the second proposed change is fairly easy to explain.

The new requirement for Transient Cyber Assets and removable media used at Low impact assets is found in Section 5 of Attachment 1 to CIP-003-7 R2. There are three parts to Section 5. Section 5.1 lays out the requirement for TCAs that are “managed by the Responsible Entity”. FERC doesn’t seem to have any problem with this part.

However, FERC does have a problem with Section 5.2. This section applies to TCAs “managed by a party other than the Responsible Entity”. ­­It lists a set of actions that the Responsible Entity can take prior to allowing a third party to connect a TCA to a Low impact BES Cyber System (which, of course, also includes simply putting the TCA – typically a laptop – on the same network as the BCS. It doesn’t have to be physically attached to a BCS). The first five of these all start with the word Review – “Review of antivirus update level”, etc. The sixth simply says “Other method(s) to mitigate the introduction of malicious code.”

In Section 3­­­9 of the NOPR (pages 24-25), FERC points out that Section 5.2 of Attachment 1, while requiring review of third-party procedures, never requires the Responsible Entity to take any particular action if their review determines that the third party’s procedures aren’t up to snuff. In FERC’s words from Section 39, “Specifically, as noted above, proposed Reliability Standard CIP-003-7 does not explicitly require mitigation of the introduction of malicious code from third-party managed Transient Cyber Assets, even if the responsible entity determines that the third-party’s policies and procedures are inadequate.” They propose to order a change to CIP-003-7 to require mitigation of the risk of malicious code posed by third-party TCAs, not just “review” of it.[i]

I don’t have a problem with what FERC is proposing here. My concern is with the timeline in which all of this is taking place. What do I mean by that? Let’s look at the bigger picture of what’s going on:

1. FERC ordered NERC to develop a requirement to address a particular threat: the introduction of malicious code to Low impact BES Cyber Systems caused by Transient Cyber Assets that have somehow become infected with malware, most likely due to defective practices of the organization that operates them. FERC intended that this new requirement would adequately address all TCAs used at Low impact assets, whether owned by the Responsible Entity or by a third party.
2. NERC developed a requirement part that adequately addresses this threat as it applies to TCAs owned by the Responsible Entity. However, FERC doesn’t believe that NERC’s proposed remedy for TCAs owned by a third party is fully adequate. Therefore, they have ordered them to develop an improved requirement, while at the same time proposing to approve the requirement as it stands in CIP-003-7.
3. FERC mandated that NERC develop a requirement for TCAs used at Low impact assets in January 2016 in Order 822. NERC’s response to that mandate was CIP-003-7, which FERC is likely to approve in 3-6 months (my guess). That will then set off the 18-month implementation period, meaning it will probably be late 2019 before CIP-003-7 comes into effect; this is a little less than four years after Order 822.[ii]
4. But as I’ve just discussed, FERC felt that, while CIP-003-7 does address what you might call the “sub-threat” of malicious code introduced to Low impact BCS by Transient Cyber Assets operated by the Responsible Entity, it needs further work before it adequately addresses the related sub-threat of malicious code introduced by TCAs operated by a third party.
5. To address that sub-threat, FERC proposes to order NERC to develop a new version of this requirement. What’s the timeline for that? Assuming that FERC will issue their order in 3-6 months (it would likely be the same order that approves CIP-003-7), the first step will be for NERC to write a Standards Authorization Request (SAR) for this revised requirement (the SAR will most likely also include a revised requirement for Low impact electronic access control, which I discussed at length in my previous post).
6. Rather than putting together a new Standards Drafting Team to address these two items (and perhaps others that FERC might order), my guess is NERC will simply add them to the SAR of the existing CIP Modifications SDT, which drafted CIP-003-7. Let’s say that SDT starts work on this in the third quarter of 2018 and takes 15 months to develop and ballot a new requirement and drop it on FERC’s desk (which is approximately what the SDT took to develop CIP-003-7, although they were under a deadline from FERC when they did that). That means FERC will have the NERC-approved requirement at the end of 2019 or early 2020.
7. Let’s say they then take six months to approve the new requirement (perhaps first issuing a NOPR); this means they’ll approve it around mid-year 2020. Let’s also assume the SDT gets aggressive and develops only a one-year implementation schedule (vs. 18 months for CIP-003-7). This means the new requirement (part of CIP-003-8, presumably), will come into effect in the middle of 2021.
8. The middle of 2021 is 5 ½ years after Order 822, when FERC originally ordered this. And – as I noted in end note ii below – if you make the case that FERC actually ordered a requirement to address the threat of malware introduced by transient devices used with Low (and Medium and High) BCS in Order 791 in November 2013, this means the requirement that addresses this threat took 7 ½ years to develop!

To make a long story short, FERC identified a serious threat and ordered NERC to develop a CIP requirement to address it, but it won’t come into effect until between 5 ½ and 7 ½ years after FERC’s order. And this isn’t very different from the experience with other new standards or requirements that FERC has ordered. Developing a new NERC standard or requirement, going through the process of new ballots and revisions, waiting for FERC to approve the standard once it’s been submitted to them, then following whatever implementation plan was developed and approved with the standard – all of this is at best a multi-year process, and can often take longer.

Now, I assume all of my readers know that things move very quickly in the cyber security field. A new threat can appear one day, and if an organization doesn’t deploy defenses against it within say two weeks, they are putting themselves at serious risk (think of the Apache Struts threat and Equifax). So let’s look at the threat of malware from transient devices. This threat had already been around for probably ten years when FERC ordered that NERC develop a requirement that would apply to Lows. Adding five years from FERC’s order until implementation of the new requirement (and of course it was actually more than that), this means this particular cyber threat took about fifteen years to be addressed in the CIP standards.

And this is a case where a threat has been included in CIP (or will be, anyway). As I pointed out in a post in September, there are a number of important current cyber threats – phishing being the best example, but also including ransomware, Not Petya, cloud- and virtualization-based threats, etc. – that aren’t addressed in CIP at all. Moreover, there is no movement now to include them in CIP.

And the reason for this (as I discussed in the September post) is simple: As I’ve just shown, the process for incorporating a new threat into the CIP standards takes somewhere between three and eight years, and that’s once NERC (or someone else) decides a new standard is needed and writes a SAR for it. And because the process is so long and convoluted, it seems there are now no further proposals for addressing threats not already addressed by CIP[iii]. The only exception to that is FERC orders for new standards (like CIP-013), which NERC will always comply with. But even FERC isn’t trying to make NERC address every new threat that comes along; as I said above, the threat posed by transient cyber assets had been around for ten years before FERC got up the nerve to order NERC to address it. FERC obviously knows they can’t push the NERC engine too fast, for fear it will simply freeze up.

So the CIP standards framework is simply unable to respond with any degree of alacrity to new cyber threats. Of course, it’s true that most players in the power industry do a good job of protecting themselves against new cyber threats, outside of CIP compliance. And it’s also true that NERC can put out NERC Alerts for serious threats; these don’t mandate any particular actions, although they do require entities to report to NERC on what steps they are taking to address these threats.

But as I discussed in the September post, this system of having some threats addressed with mandatory requirements, while others are addressed strictly on a voluntary basis, isn’t a good one. For one, it is a very inefficient way of addressing threats. More importantly, it results in a severe distortion of how entities spend their resources addressing cyber threats, since NERC entities are strongly incentivized to lavish resources on threats which happen to be addressed in the CIP standards (and thus carry substantial potential penalties for non-compliance) vs. those that aren’t, regardless of the level of risk that each of these threats might actually pose on their own.

What’s to be done about this? My next post will discuss how I would fix this problem, were I given power to change both the CIP standards and the NERC compliance regime embodied in CMEP and the Rules of Procedure. Of course, once I lay this out, I expect the phone to be ringing off the hook (to use a quaint expression, since I don’t know any phone nowadays that still has a hook!) with requests from FERC and NERC to actually implement this. Just you wait!

The views and opinions expressed here are my own, and do not reflect those of any organization I work with. 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.

---

[i] FERC doesn’t seem to have a problem with Section 5.3 of Attachment 1 of CIP-003-7 R2, which deals with Removable Media managed either by the Responsible Entity or by a third party (although it never mentions who manages the Removable Media). This is most likely because 5.3 requires both detection and mitigation of any malicious code found on those Removable Media.

[ii] Actually, you could make the case that FERC mandated a requirement for TCAs used at Lows in November 2013, in Order 791; using this as the start date, it will have taken six years for the CIP requirement developed in response to this mandate to come into effect. I say this because, in Order 791, FERC first mandated that NERC develop a requirement for transient devices used with BES Cyber Systems. They didn’t say they wanted a requirement that would apply just to Medium and High impact BCS, but that is how the “CIP v6” drafting team interpreted this mandate (when they produced CIP-010-2 R4). FERC probably intended that the requirement apply to Lows as well, which may be why they ordered NERC to develop a Low impact transient device requirement in Order 822.

[iii] I believe there’s another reason for the fact that nobody in the NERC community has much enthusiasm for extending CIP to address new threats: I think the community has been put through the ringer on CIP version 5. With CIP v5, there there were many ambiguities in the requirements and NERC tried using various means to clarify those ambiguities, only  to have all of their efforts founder on the fact that NERC isn’t allowed to provide any real guidance on the meaning of an ambiguously-worded requirement. The result is that the ambiguities haven’t been addressed yet, and probably never will. Entities are responsible for coming up with and documenting their own resolutions of each area of ambiguity, as I first realized when I wrote this post in 2014. I know that the last thing most entities want is to have any more bruising battles over the meaning of new requirements, when these are likely to prove as inconclusive as they did with CIP v5.