Breaking the New Threat Logjam

My previous post, as well as a post from September, pointed to probably the biggest problem with the NERC CIP standards today: To address a new cyber threat through CIP, NERC has to go through its standards development process. And the time from when a new standard or requirement is requested (usually by FERC) to when the new standard comes into effect is almost always multiple years, and very often more than that (in the example I used in the previous post, the time was between 5 ½ years and 7 ½ years, depending on how you measure it).

There are two primary consequences of this:

1. There are a number of important cyber threats – phishing, ransomware, “not-Petya”-type attacks, cloud-based threats, etc. – that aren’t currently addressed in CIP at all; moreover, there is no serious effort now to incorporate these into CIP.
2. A great weariness with the process of developing new CIP standards, and trying to interpret them once developed, seems to have settled on the NERC membership since the CIP version 5 implementation experience. It is highly unlikely that any new cyber threats will be addressed in CIP going forward, unless ordered by FERC.

Of course, NERC entities are, for the most part, still investing a lot of resources in addressing ­new cyber threats outside of the CIP compliance process. But as I’ve pointed out multiple times, including in my last post, the fact that some threats must be addressed in order to comply with NERC CIP and are subject to potentially huge fines (this includes threats like malware, firewall misconfiguration, lack of proper network segmentation, etc.), while others are strictly optional, means there is inevitably a tendency to overfund controls against threats that are part of CIP, and underfund controls against threats that aren’t part of CIP.[i] And this discrepancy will only get much larger, since new threats are appearing more rapidly all the time.

Yet, as I’ve also pointed out, the industry needs mandatory cyber security standards, since it is only by having those in place that cyber security efforts will be well funded. How do we break this logjam, in which the current CIP standards suck up a greatly – and increasingly – disproportionate share of the resources available for cyber security, while still having mandatory standards?

The answer to this question flows almost directly from what I’ve just said: A new CIP standards framework that will address this problem would need to replicate, as closely as possible, the process that the entity would naturally follow on their own if they a) didn’t have any mandatory cyber standards to comply with, but b) they still had the same budget for cybersecurity that they have in the presence of the mandatory CIP standards.

And what would that process be? It would be one in which the entity

1. Ranks all of the cyber threats it faces by their degree and probability of impact – in other words, by the degree of risk that each threat poses.
2. Determines approximately what steps are required to mitigate each threat;
3. Determines the degree of mitigation that would be achieved by taking those steps;[ii] and
4. Allocates its cyber budget so that a) all of the threats above a certain minimum risk level are mitigated to some degree, and the more risky threats to a higher degree; and b) the more risky the threat, the more it is mitigated

What kind of standard would be required to implement this process? I can tell you right now that the current CIP standards won’t work! The problem is that some of the current CIP requirements are excessively prescriptive. And even though a small number of the requirements aren’t prescriptive (and I consider objectives-based requirements like CIP-007 R3 to be the opposite of prescriptive requirements like CIP-007 R2), the NERC compliance and enforcement process (embodied in CMEP and the Rules of Procedure) is itself very prescriptive. Both the CIP standards and the compliance/enforcement process will ultimately need to be changed in order for what I’ll outline below to work.

But let’s say I were given the power tomorrow to put in place what I think is needed; what would I do? I’m very glad you asked that question. First, I would scrap the existing CIP standards and put in place what is in effect a single requirement[iii]: “On a risk-adjusted basis, address the cyber security threats on the current list.” And where does this “current list” come from? I’m also very glad you asked that question. When this new standard is drafted, the drafting team will draw up an initial list of what they consider the most important threats.

However, this list would have to be maintained on an ongoing basis. There will need to be some group designated to meet regularly (I would think quarterly would be appropriate) and do the following:

1. Review current cyber threats and determine which ones should be added to the list.
2. Decide if any threats currently on the list should be removed.
3. For each threat on the list, determine a set of “criteria” that should be addressed in the plan the entity develops. I hope to have a post out very soon on what a “plan” is and how it could be audited in my desired scheme of things, but for the moment I’ll just point out that CIP-003 R2, CIP-010 R4, CIP-013 and CIP-014 all speak of a plan. The criteria are topics that must be addressed in the plan, regarding each threat. For example, for the threat of malware infection from transient electronic devices, the criteria could include items such as “The plan must address devices owned by third parties as well as by the entity”; “The plan must address how access to transient electronic devices will be managed”; etc.
4. Develop guidance on how each threat can be mitigated, and update it in the light of real-world experience addressing these threats (and not just experience of the electric power industry, but of other industries as well. After all, almost none of the threats on the list will be unique to electric power). This is probably the most important task that this group will be faced with, and it is certainly the one that will take the most effort.
5. Develop written materials that will enable smaller, less-sophisticated entities to determine whether and how a particular threat applies to them, and how much of a risk it actually poses. This is necessary in order to prevent such entities from investing a lot of time and resources toward addressing threats that probably pose very little risk to them.[iv]

Who would comprise the members of this group? It will need to be a diverse group, representing the different types of organizations subject to CIP: investor-owned utilities, Independent Power Producers, Generation and Transmission coops, distribution-only coops, large municipals, small municipals, ISO/RTO’s, US government agencies, etc. And it will need to include representatives of the E-ISAC, since it is their business to constantly identify and evaluate new threats to the electric power industry.[v]

Who would run this group? I’ll say right off the bat that it shouldn’t be run by NERC itself, since this might be perceived as a conflict with their role as the regulator. Obviously, NERC will continue to be in charge of the CIP standards, but it shouldn’t be in charge of the committee that identifies threats, since if it were this might taint the list of threats as being somehow the equivalent of a new standard, which it certainly is not.

I could see this group perhaps being organized by the trade associations: EEI, NRECA, APPA and EPSA. Or maybe the Transmission Forum and Generation Forum would get together to organize this group from among their members. I could also see the NERC CIPC doing this, although it would be a big expansion of their mandate and would thus require a large additional time commitment from a significant number of its members.

So why is it important to have this group, and to rewrite CIP so that it simply refers to the current threat list, rather than simply address particular threats, as it does now? Because that is what it will take – as far as I can see – to remove the identification of new threats from the standards development process. Instead of taking somewhere between three and eight years to address a new threat in CIP (as is currently the case, given the cumbersomeness of the standards development process), CIP will potentially within a few months “address” new threats, as soon as they are identified by this group.

Before I go, I want to point out that I’ve raised this issue before, although in a different context. In this post from August, I brought up the issue (first raised in the previous post) of compliance with CIP-013 R3. That requirement mandates that each NERC entity that is subject to this standard, once every 15 months, review their supply chain cyber security risk management plan to determine whether it adequately accounts for the current supply chain cyber risks, as well as whether it takes account of new developments in mitigation techniques for those risks.

In the previous post, I had wondered whether some new body could be constituted to review new supply chain threats and mitigations, since a lot of NERC entities wouldn’t have the in-house resources to do this review themselves. I suggested that a committee of industry representatives could do this on behalf of the whole industry, although individual entities would be free to remove or add particular threats when they drew up their own list of risks, based on their own unique circumstances. I had concluded that this would never be allowed by the current NERC CMEP.

In the post last August (referenced above), I discussed an email conversation I’d had with an auditor, who said that he didn’t see any obstacle to such a body being put together; it wouldn’t involve any conflict with the current wording of CIP-013 or with CMEP. So I think such a body should be put together. It isn’t technically needed until a year after CIP-013 comes into effect, which probably means around the end of 2020, but I really think this body would be helpful even now, completely divorced from any particular CIP purpose – but simply for the general purpose of raising awareness of current cyber threats among NERC entities. As CIP-013 comes into effect, and as CIP is rewritten in accordance with my suggestions (and I’m absolutely sure this will happen, of course!), then this body could segue into these two roles, as discussed above.

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] For a fairly long discussion of why this is the case, see this post.

[ii] This is without a doubt very hard to determine in any sort of scientific way. For example, if you are going to mitigate the threat posed by phishing and you decide that training – including sending out phishing-type emails to see who clicks on them - is the best mitigating step you can take, how can you know how successful it will be in reducing the number of malicious phishing attempts that succeed in getting someone to click on them? Well, you might put this program in place for six months or a year, and monitor statistics like number of outside phishing emails that get clicked on, number of test emails that get clicked on, etc. At that point you would be able to decide whether just continuing the current program will provide enough mitigation long-term; whether it needs to be augmented with an automated anti-phishing tool or some other mitigation method; or whether it’s been totally ineffective and you need to drop it and try something else.

In general, it will be very hard to determine up front how much mitigation a particular control might provide for a particular threat; it will usually have to be an educated guess, which can later be updated as experience (both the entity’s experience and that of its industry peers) allows.

[iii] It isn’t really a single requirement, and there will be more to each requirement than just one sentence. But in principle, what I am proposing isn’t too far from this single sentence. By the way, as I’ve said before, I am working on a book, with two co-authors, that will discuss this idea in much more detail – as well as justify it much more thoroughly – than I ever could in this blog. But the book is still a long way from appearing in print (or electrons), so at the moment this explanation, as well as others that are scattered around my posts from the past year or so, will have to suffice.

[iv] I’m assuming that the larger entities will have the necessary expertise on staff to determine whether particular threats apply to them or not, and also to estimate the risk that each of these poses. But it’s possible that larger entities would also need some of this help as well.

[v] However, it’s important to remember that the E-ISAC, at least as currently constituted, only addresses what I would call technical threats. This includes new varieties of malware, new attack vectors, etc. The E-ISAC doesn’t address threats that can only be addressed through procedural means, such as the threat of malware being introduced from transient cyber assets and removable media. Those threats are sometimes addressed in the CIP standards, but increasingly are not, for reasons already discussed in this post.

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.

FERC’s New NOPR, Part IV: The Other Shoe Drops

This is the fourth post in a series on the NOPR that FERC released in October. The NOPR accomplished two primary goals: 1) FERC announced that they intend to approve CIP-003-7, which was approved by NERC and submitted to FERC early this year; and 2) FERC proposed to order NERC to make two important changes to CIP-003-7, which will have to be incorporated into a new version of CIP-003. This post will focus on the first of those changes; the next (and last) post in this series will discuss the second change.

The first change that FERC ordered has to do with the changes that the CIP Modifications Standards Drafting Team made to the requirement for electronic access control for Low impact assets in CIP-003-6. These changes were balloted (twice) and endlessly discussed by the NERC community in 2016. The final version of CIP-003-7 was approved by NERC and sent to FERC early this year.

These changes were made because FERC, when they approved “CIP version 6” in Order 822, ordered that NERC modify the definition of low impact external routable connectivity (affectionately known as LERC) to clarify the meaning of the word “direct” in the definition. However, when the new CIP Modifications Standards Drafting Team started discussing this issue, they realized that what was really needed was a modification of the requirement for electronic access controls for Low impact BES Cyber Systems. Hence, what was delivered to FERC was a modification of Section 3 of Attachment 1 of CIP-003-6, not a new definition of LERC (the LERC definition was also modified, but it was removed as a separate definition and incorporated into the language of the requirement itself).

In their NOPR, FERC said they intend to approve the revised requirement language. That will come into effect 18 months after FERC issues the actual order approving CIP-003-7. However, they did also indicate that they wanted further changes, beyond what is now in CIP-003-7. What they asked for was interesting on a couple of fronts, and I’ll discuss that now.

FERC’s “Proposal” for these changes is found in Sections 27-32 of the NOPR (starting on page 22). After saying they intend to approve CIP-003-7 as written, FERC then says “However, NERC’s proposed revisions to Reliability Standard CIP-003-7 regarding the LERC directive and electronic access controls for low impact BES Cyber Systems raise certain issues.”

What are these issues? FERC immediately goes back to Order 822, stating “The directive was based on the concern that responsible entities could avoid adopting adequate electronic access protections for low impact BES Cyber Systems by simply installing a device, such as a laptop or protocol converter, in front of the BES Cyber System to ‘break’ the direct routable connection.”

I went back to Order 822 to try to verify what FERC said in the NOPR; and frankly, I’m a little confused. Here is what I think they are saying:

1.      In paragraph 27 of the NOPR (right after the sentence quoted above), FERC says “In Order No. 822, the Commission directed NERC to develop modifications to the LERC definition to eliminate ambiguity surrounding the term “direct” as it is used in the definition.” I agree that is true.

2.     From re-reading the discussion of this topic in Order 822 (starting in paragraph 73 on page 44), it seems FERC was exclusively concerned with making sure there was an adequate protection device (a LEAP) in every case where there was LERC (i.e. Low impact external routable connectivity). I don’t see anything in Order 822 that suggests FERC was asking NERC to go beyond just requiring Low assets with LERC to have a LEAP. But FERC is saying that in Order 822 they really ordered NERC to require Low assets to install “adequate electronic protections” for Low BCS[i], and they’re implying that these should go well beyond having a LEAP.

3.     In paragraph 28 of the NOPR, they state “…proposed Reliability Standard CIP-003-7 does not provide clear, objective criteria or measures to assess compliance by independently confirming that the access control strategy adopted by a responsible entity would reasonably meet the security objective of permitting only ‘necessary inbound and outbound electronic access’ to its low impact BES Cyber Systems.”   In Order 822, FERC seemed quite content to follow NERC’s lead and limit the enforcement of “only necessary inbound and outbound electronic access” to LEAP devices (e.g. firewalls). If there was LERC, the entity needed a LEAP. If there was no LERC, the entity didn’t need a LEAP. End of story.

4.      However, FERC seems to have now re-defined “necessary inbound and outbound electronic access” to include other considerations like authentication and password complexity, although they emphasize there need to be clear criteria for what is required. In paragraph 31, FERC goes back to the CIP v5 requirements for High and Medium impact BCS to find these. They say “For medium and high impact BES Cyber Systems, auditors use the following criteria to review whether the access control strategy is reasonable:  (1) whether the electronic access was granted through an authorized and monitored electronic access point (Reliability Standard CIP-005-5, Requirement R1); (2) whether the electronic access granted to individuals/devices was evaluated based on need (Reliability Standard CIP-005-5, Requirement R1.3); (3) whether the entity has mechanisms to enforce authentication of users with electronic access (Reliability Standard CIP-007-6, Requirement R5); and (4) whether the responsible entity routinely uses strong passwords and manages password changes (Reliability Standard CIP-007-6, Requirement R5).”

5.      In other words, FERC is now saying that just having a firewall isn’t enough to protect Low impact BES Cyber Systems when they are routably connected to the outside world. Instead, the four controls just listed also need to be in place.

6.      But they’re actually even going beyond that. They’re saying (paragraph 29) that an entity that owns Low impact BCS should have an “access control strategy” (presumably a documented strategy. What in the NERC world doesn’t need to be documented?). This strategy will of course need to include the four “criteria” listed in bullet 4 above. FERC continues by saying “In order to ensure an objective and consistently-applied requirement, the electronic access control plan required in Attachment 1 should require the responsible entity to articulate its access control strategy for a particular set of low impact BES Cyber Systems and provide a technical rationale rooted in security principles explaining how that strategy will reasonably restrict electronic access.” So NERC entities with Low BCS will not only have to implement the four types of controls, but they will have to include these controls (and possibly others) in a documented access control strategy for Low BCS.

I need to point out that I’m not saying FERC has done anything wrong here; they certainly have the power to require NERC to do more than they asked them to do previously. They have clearly had a change of heart (as well as a change of Commissioners, of course) since they issued Order 822, and they now believe that simply throwing a firewall in front of BES Cyber Systems located at a Low impact asset isn’t enough to protect them; rather, other controls are needed. It is hard to argue with that, of course.

And there’s one more point to be made before I let you go: What do you think all of this means for the supposedly set-in-stone principle that an inventory of Low impact BCS will never be required? Yup, I agree. Once CIP-003-8 (which is of course the version that will include everything that FERC is proposing to order in the NOPR) comes into effect, this principle will sleep with the fishes.

But I do want to remind you that this is just a NOPR, not an Order. FERC is soliciting comments on everything I’ve just mentioned. If you have any comments, you should speak now or forever hold your peace!

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 also says (in paragraph 73, right after the sentence quoted above), that “As the Commission noted in Order No. 822, the desired clarification could have been made by including the security concepts from the Guidelines and Technical Basis section of Reliability Standard CIP-003-6 in the definition.” I have looked backwards and forwards in the GTB for CIP-003-6, and I haven’t found any general discussion of security concepts. There is certainly a lot of discussion of when LERC is or isn’t present, but that just relates to the question of whether or not an entity needs to install a LEAP at a Low impact asset. There’s nothing to suggest that NERC had somehow laid out some basic security concepts in the GTB, that they should then have required that entities follow for Low impact assets – but didn’t for some nefarious reason. 

FERC’s New NOPR, Part III: What’s ahead for Lows, especially in CIP-013?

One of the things that struck me about FERC’s October NOPR was its tone regarding Low impact BES Cyber Systems. This is most evident in the discussion of electronic access control in Section 31, pp 19-20, which addresses the requirement for Low impact electronic access controls in CIP-003-7. FERC did say they would approve CIP-003-7 R2 Attachment 1 Section 3.1, which was developed to comply with FERC’s directive in Order 822 that NERC address what FERC saw as an ambiguity – and, in truth, a loophole – in the language of CIP-003. However, in this section they went further, and ordered NERC to start developing a new Low impact electronic access control requirement that goes beyond what is in CIP-003-7.

I will go into the substance of what FERC said about this topic in the next post in this series, but I’ll jump the gun a little and point out that FERC told NERC that they have to develop specific controls for Lows in four areas: Electronic Access Points, evaluation of access based on need, authentication of users, and password management. FERC brings these up in the context of electronic access control, but they have clearly moved beyond anything they’ve ordered before in the way of electronic access controls for Lows, which has until now has pretty much meant firewalls (and, in case you wondered, they’re making it almost inevitable that an inventory of Low impact BES Cyber Systems will be required to comply with these new requirements. More on that in the next post).

FERC clearly believes that Low impact BCS constitute a point of vulnerability for the BES, and they’re moving to strengthen the controls on them. This isn’t because they think that the physical assets NERC classifies as Low impact are actually much more impactful than NERC thinks they are. It’s because FERC sees the entire BES as being in some way connected on a logical level. You may scoff at this by pointing out that there is no such thing as a continent-wide IP network connecting any BES assets, let alone all of them. But if you consider serial communications as in some way hackable, then this idea gains a little more plausibility (although just a little, in my opinion).

In any case, this is what FERC believes, and they will be requiring that CIP-003-8 have more electronic access controls for Lows. But I think there is another likely area in which FERC will try to strengthen cyber security controls on Lows, and that’s CIP-013.

For those of you keeping score at home, CIP-013-1 was approved by NERC and submitted to FERC at the end of September. My guess is FERC will act on it within six months, possibly even earlier (I was quite surprised by the speed with which they acted on CIP-003-7, given that they’ve only had a quorum since August, and there were a lot of other items on their plate from the 5 or so months they didn’t have a quorum).

You also probably know that CIP-013-1 only applies to High and Medium impact BCS (although the first draft did include Lows, on a reduced scale). In Order 829, which ordered this standard, FERC just said that the standard should apply to BES Cyber Systems without specifying any impact levels, so the drafting team wasn’t explicitly disobeying FERC in limiting the scope to Highs and Mediums.

You may also know that there is only one FERC Commissioner remaining from the four that voted on that standard (and that Commissioner, Cheryl LaFleur, dissented from the vote, although her objection was that FERC wasn’t giving NERC enough time to develop the new standard – which I totally agreed with at the time), so the majority of the Commissioners now are newly appointed.

Finally, you probably also have heard somewhere that there is a new Administration in Washington, which many people believed would be very skeptical of any new or extended regulations – and whose appointees to FERC might be expected to oppose any major extension of the CIP standards, such as ordering NERC to include Lows in the next version of CIP-013. However, if you thought that, you would do well to take a look at the language in the NOPR, since FERC seems not only willing but eager to extend requirements on Lows. In my opinion, they believe Lows might be the weak underbelly to the whole BES.

This is all to say that I now think it quite likely that, when they approve CIP-013-1, FERC will also order NERC to develop a new version that brings Lows into scope in some way. So if you have responsibility for Low impact BCS, you might circle 2021 on your calendar as the possible date when this new version, probably CIP-003-8, will come into effect. And if you’re nearing retirement, you might want to aim for 2020! It’s supposed to be a good year.

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

FERC’s New NOPR, Part II: You Need to Lose the Idea of CIP “Versions”

This is the second in a series of four posts on the NOPR that FERC released in October; you can read the first one here. As I said in the first post, I just got the chance to spend quality time with the NOPR this past weekend, and I’m writing 4 or 5 posts on interesting things I learned from it.

In the NOPR, FERC said two things. First, they intend to approve CIP-003-7, making this the first “version 7” CIP standard to come into effect. Second, they ordered NERC to draft two important changes to CIP-003-7. This, coupled with the fact that NERC’s Rules of Procedure require these changes to be made in a new version of the standard, ensures that a NERC drafting team will start work on the first “version 8” CIP standard in early 2018.

I’m sure some of you remember when it was possible to state clearly that all of the CIP standards in effect were part of the same version. Less than two years ago, all of the CIP standards in effect had a “-3” after them[i]; there was no question that we were living in the “CIP version 3” world. When the “CIP version 5” standards came into effect in July 2016, we now had two sets of suffixes. Standards CIP-002 through CIP-009 all had “-5” or “-5.1” after them[ii]. Standards CIP-010 and CIP-011 both had “-1” after them, since these were new standards; but they had been developed and balloted with the “-5” standards, so there wasn’t any confusion about their being part of “CIP v5”.

However, when FERC approved CIP v5 they ordered modifications, as they have done when they approved every other CIP version. These required new versions of the standards being modified, as explained above in this post. NERC put together a standards drafting team to make these modifications, but they were explicitly not referred to as the “CIP version 6” drafting team. Instead, they were dubbed the “CIP Version 5 Revisions” SDT, giving the somewhat misleading impression that it was possible to modify a NERC standard without incrementing the version number[iii].

Previously, whenever FERC had approved a new CIP version but ordered changes, all of the CIP standards had been “revved” to the new version, even if they weren’t affected by those changes. For example, when FERC approved CIP v2 in 2009, they ordered a single modification: revision of CIP-006 to add a requirement for escorted access of visitors into the ESP. However, the team that developed this modification to CIP-006 also incremented the version number for all the other CIP standards, so they all had the “-3” suffix when they came into effect in 2010.

However, the CIP v6 team opted not to do this, and instead only incremented the version number of the standards that were modified (I had assumed that they would end up incrementing all the version numbers and calling the package CIP v6, but this didn’t happen. About a year later I attended a NERC presentation on the new standards in Atlanta where they did actually call them CIP v6, but in general NERC has studiously avoided using The Version Number that Dare not Speak Its Name). So when “CIP version 6” came into effect last year, six of the standards had “-6” after them, while three had “-5.1” or “.5” after them. And since both CIP-010 and CIP-011 were modified, they now had “-2” as a suffix.

When it became apparent that there would no longer be a consistent version number for all the CIP standards, I raised a protest, saying this would be confusing. But a few experienced NERC professionals pointed out to me that, in the other NERC standards families like COM and EOP, it has been a long time – if ever – since these standards were all on the same version number. I responded that, since so many CIP professionals came from other standards environments like PCI and HIPAA, where the version numbers were always uniform, they wouldn’t be used to this.

Now I realize this was a losing battle. Consider the other CIP changes since “CIP v6”:

1. As I said above, CIP-003 will be at the v7 level in less than two years; plus a drafting team will start work on v8 of that standard soon.
2. The second version of a new standard, CIP-014-2, is in effect.
3. CIP-013-1, the new supply chain security standard, has been submitted to FERC for approval.
4. Along with CIP-013, two modified versions of existing CIP standards were submitted, and will be approved along with CIP-013. These are CIP-005-6 (CIP-005 was one of the three standards that wasn’t modified when “CIP version 6” was developed) and CIP-010-3 (this becomes v3 of the standard, since CIP-010 was modified under “CIP v6” and thus became CIP-010-2).
5. A new standard, CIP-012, is being balloted now, and will most likely come into existence as version 1.
6. The current CIP Modifications SDT is working on modifications to other standards, because of other tasks mandated in their SAR that haven’t reached the drafting stage yet. This includes the changes required to incorporate virtualization into CIP, which will likely require modifications to most of the CIP standards (and these will of course simply increment the existing version numbers, leading to even more diversity, although it would be nice if all the standards could be brought up to the same level, e.g. version 9 or whatever the “high water mark” is at the time they come into effect[iv]).

So how are you to keep track of what versions of the different CIP standards are currently in effect? Fortunately, NERC has put on their web site – and will be maintaining as changes are made, I’m sure – a spreadsheet showing current and recent versions of all the NERC standards (not just the CIP ones). It’s called the “US Standard One-Stop-Shop”. You might want to plan on downloading it regularly so you can be sure you’re always dealing with the most recent versions (it includes links to all the standards as well as their RSAWs, FERC Orders, Lessons Learned and Compliance Guidance); this is especially important if you deal with other NERC standards besides the CIP family.

For your amusement, here are the current effective versions of all the CIP standards, according to the most recent version of this spreadsheet:

• CIP-002-5.1a
• CIP-003-6
• CIP-004-6
• CIP-005-5
• CIP-006-6
• CIP-007-6
• CIP-008-5
• CIP-009-6
• CIP-010-2
• CIP-011-2
• CIP-014-2

And as I already said, the diversity of these version numbers is only going to increase as we go forward.

The moral of this story? We all need to disabuse ourselves of the idea that there is any longer a “version number” for the CIP standards as a group. Instead, we all need to be checking regularly that we are working from the current version of each standard.

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] Some had “-3a” or “-3b” after them, meaning that an approved Interpretation had been applied to them.

[ii] The “-5.1” was the result of an error correction that NERC made before FERC approved the v5 standards in November, 2013.

[iii] I believe this was done because of the real wounds incurred by some NERC entities during the great CIP v4 debacle, when different groups – sometimes within one NERC entity - had different opinions about whether v4 or v5 would be the next version that entities would have to comply with. In April of 2012, FERC surprised the industry (and certainly me!) by approving CIP v4, while CIP v5 was actively being drafted. I have a theory about why they did this (which was later obliquely confirmed to me by a FERC staff member), but it’s too involved to go into here (if you’re interested in this, you can email me at tom@tomalrich.com and I’ll be glad to tell you the whole sad story. Let’s just say that FERC’s approval of CIP v4 – when they were not really intending to have it come into effect – caused a lot of confusion in the industry, and undoubtedly resulted in at least some NERC entities spending substantial sums of money that came for naught. It wasn’t exactly FERC’s finest hour, in my opinion).

[iv] However, as I’ve pointed out recently, I consider it highly unlikely that the CIP Modifications SDT will ever complete any of the remaining items in its SAR, unless they’ve reached the drafting stage. This includes virtualization, which is certainly a great idea - but it will probably take more than ten years to get all of the required changes drafted and approved (I’m not kidding about this). But the team still has CIP-012 on its plate, and I believe CIP-003-8 will be added soon, as discussed in the previous post in this series. So the drafting team members aren’t going to be lacking for ways to occupy their time!

FERC’s New NOPR, Part I: More Time to Comply for Lows!

On October 19, FERC issued a Notice of Proposed Rulemaking, stating that they intend to approve CIP-003-7, which was submitted to them early this year after a lively debate within NERC last year. To be honest, while I skimmed through this document when it came out, I haven’t had time to spend some quality time with it until this past weekend. And in doing so, I realized there are a few posts I should write about it. Here’s the first one.

Every time FERC has approved a new version of the CIP standards, they have taken the “yes, but…” approach. They approve the proposed standards, but then they order some improvements to them. Because the NERC Rules of Procedure don’t allow a standard to be modified once it has been approved by the NERC Board of Trustees – and this always happens to a proposed new standard before it is even submitted to FERC – these improvements always have to be addressed in a new version of the standard.

So it will be in this case. NERC will need to start work soon on drafting a new version of CIP-003 that will address FERC’s further mandate in this NOPR. Since the drafting team that developed CIP-003-7 is still meeting, I would think this will be added to their Standards Authorization Request (SAR), rather than NERC’s having to constitute a new SDT for this task. Meanwhile, FERC will almost certainly approve CIP-003-7[i], and that version will presumably come into effect before the new version of CIP-003 does (which I assume will be CIP-003-8).

Buried within the NOPR is an interesting notice. In section D paragraphs 45 and 46, FERC stated their intention to approve the CIP-003-7 Implementation Plan, which was of course approved and submitted with the proposed standard itself. That plan calls for an 18-month implementation period (after the date of FERC’s Order approving the CIP-003-7), but it also calls for the effective date of CIP-003-6, the currently-approved version, to be replaced with the CIP-003-7 effective date.

The effective date of CIP-003-6 is Sept. 1, 2018, but this will now be replaced by the effective date for CIP-003-7; moreover, on the effective date of CIP-003-7, CIP-003-6 will be “retired”. So what will be the effective date of CIP-003-7? Assuming FERC approves it in three months (it could be longer), and given that there’s an 18-month implementation period, this means that NERC entities won’t have to comply with CIP-003-7 (and specifically, Attachment 1 Sections 2 and 3, since the rest of the standard is unchanged from v6 and has already come into effect) until at least 21 months from now, or about July 2019. So NERC entities effectively have been given close to an additional year to implement specific controls on electronic and physical access at Low impact sites.

You may want to include the FERC Commissioners in your holiday card list. They’ve given you an early present.

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] The NOPR just says they propose to approve it. If they had actually approved it, they would have issued an Order to do so. I am a little surprised that they wrote a NOPR rather than an Order, since they don’t seem to have any doubt that they will approve CIP-003-7. It may be that, given that the Commissioners are all new except for one (Commissioner LaFleur) and therefore only one of them approved Order 822 (which ordered this change), they want to gather some new comments to confirm that they should approve it.

The Second Lesson from CIP-014

Two weeks ago, I wrote a post that discussed the first of two lessons that can be learned from NERC’s experience so far with CIP-014, the physical security standard that applies to certain key substations. I think these lessons should have implications for CIP-013, since both of these standards are objectives-based (non-prescriptive) and risk-based. After a follow-up post to the first one, this post discusses the second lesson.

I learned both of these lessons from a friend who is in charge of CIP physical security compliance for a large utility (I need to point out that he wasn’t trying to teach me lessons! I learned them from what he told me). He described a meeting on CIP-014 between some auditors from his NERC region and some of the entities in the region. In the meeting, the auditors were asked how they would audit the entity’s implementation of the physical security plan for important substations. They asked this question because CIP-014 R5 requires the entity to develop and implement a physical security plan.

My friend was quite surprised when he heard the auditors’ answer. They said they were going to look at various measures of how far along the entity was in implementing the plan at the time of the audit. They would look at (among other things) the number of physical security devices put into place but not connected, the number connected but not activated, and the number fully connected and activated. They would then presumably compare these results with some measures (and how they would come up with those is anybody’s guess) of where the entity ought to be at this stage of the implementation process. Also presumably, they might issue a Potential Non-Compliance finding if the entity was too far behind where they thought they should be at this stage.

My friend – and others at the meeting – rightly raised the question what all of this has to do with compliance with CIP-014. As the auditors described it, they weren’t going to audit the entities on how well they’ve fulfilled the requirements – which, to be succinct, require the entity to develop and implement a physical security plan. To properly audit the requirements, the auditors would have to determine whether or not the entity’s plan is a good one, and whether they properly implemented it.

And why weren’t the auditors going to audit compliance with the actual requirements? I’m assuming this is because there aren’t any criteria in the requirements themselves for what would be a good plan vs. a bad one, or a good implementation vs. a bad one. Of course, CIP-013 is the same way: The entity is only required to develop and implement a supply chain cyber security risk management plan. The requirements themselves say nothing about what that plan should contain (except for six particular items listed in R1.2, which were ordered by FERC. These have to be included in the plan, but they in no way constitute the whole plan).

Instead, the auditors were saying that the entity would be judged on some artificial constructs that can definitely be measured, but have no relation to the question whether the plan is a good one or whether or not the entity is doing a good job of implementing it – which is what the standard requires. Naturally, my friend found this idea kind of problematic!

This relates to a problem I brought up (at great length, I’ll warn you) in this post from about a year ago: that drafting teams are often under pressure to put measurable requirements in the standards they’re developing, even when the quantities being measured aren’t really very germane to the actual objective of the requirement. And, since the CIP-014 drafting team seems to have resisted this pressure, evidently the auditors at the meeting my friend attended were pushing this one step further. I’ll trace out what I think their logic was:

1. The requirements in CIP-014 don’t provide any sort of measurable criteria to audit.
2. The auditors could try to figure out how to effectively audit the requirements of CIP-014. But this would require them to use judgment (how else can you determine whether the entity has developed a good plan, or whether they’ve done a good job implementing it?), and use of auditor judgment on this scale isn’t countenanced in CMEP or GAGAS[i].
3. Therefore, they developed some measurable criteria to audit, even though these have nothing to do with the central purpose of CIP-014: developing and implementing a good physical security plan for key substations.

I want to point out that I have no idea whether what the auditors said they would do at this meeting will ever see the light of day, in the region in question or anywhere else. This is because: a) I’m getting this whole story second hand; b) I have no idea whether the auditors dropped these ideas after that meeting; and c) I don’t know whether these ideas were shared with other regions or not. And you may notice I’ve gone out of my way not to clue you in on which region was involved here.

But I’m not criticizing the auditors anyway. They are between the proverbial rock and a hard place. On the one hand, they’re faced with a standard that presents no measurable criteria to audit, meaning an application of judgment is required. On the other hand, the documents that govern what they’re supposed to do – CMEP and GAGAS, as well as the NERC Rules of Procedure – adamantly reject the idea of the auditor’s exercising judgment in a situation like this one.

In my opinion, the only thing for the auditors to do in this case (and the only thing that ultimately will be done, I’m sure) would be to review the physical security plans and use their own judgment to determine whether they’re good or bad. Of course, if they don’t like the plan, they can’t issue a PNC unless the entity had simply not developed a serious plan at all. But they can at least issue an Area of Concern that points out deficiencies in the plan or its implementation; the entity would then be well advised to address the AoC, even though they couldn’t strictly speaking be found in violation if they didn’t do that.

But, since GAGAS and CMEP absolutely prohibit an “audit” that consists of nothing more than an application of the auditor’s educated judgment, the auditors – and NERC themselves – would have to acknowledge that CIP-014 R5 (the requirement to develop and implement a plan) isn’t really auditable at all, except in the case of gross disregard for the requirement.

What do I think will happen with CIP-014 enforcement? I am pretty sure that, when it comes to the actual audit, the auditors won’t invent criteria like the ones described above. They will do what the auditors for CIP-013 will do, as I described in this post: They will use their own judgment, guided hopefully by an ample set of guidance documents from NERC as well as other parties. If they find deficiencies in either the physical security plan or its implementation, they will issue an Area of Concern. This isn’t like a Potential Non-Compliance finding, which can ultimately lead to a violation finding. The entity will need to remediate this AoC, but in the end they can’t be held in violation for not doing so.

I would write a lot more on this idea, except I already wrote it all in my last post; so please read (or re-read) that. I’ll just point out that entities subject to CIP-014, as they approach the time when audits start, should be on their guard against attempts by the regions to enforce spurious audit criteria (I somewhat doubt this will happen, but ya’ never know!). And now that I think of it, the same goes for entities subject to CIP-013!

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] For a discussion of these two acronyms, see my previous post.