FERC Order 822

On January 21, 2016, FERC approved NERC CIP version 6 at their monthly Sunshine Meeting. Later they released their Order 822 explaining what they had done. There was one huge surprise (for me, anyway) in the Order, as well as a few other interesting points. Here are what I think are the most important aspects of the Order.

Implementation Date Follies

Note Jan. 29: The Interested Party told me that Order 822 was indeed published in the Federal Register on Tuesday, meaning this entire section is moot. CIP v6 will go into effect on the schedule I laid out in this post. I'm leaving this section in just because a few people may find it interesting. You won't hurt my feelings if you jump to the next section.

First, FERC approved the seven CIP v6 standards. Of course, that was no surprise at all, since they had said they would do that in the NOPR they released last July. However, there was an interesting surprise regarding dates. FERC states in the Order that the effective date will be 65 days after publication in the Federal Register. FERC also states (paragraph 12) that “NERC requests an effective date for the Reliability Standards of the later of April 1, 2016 or the first day of the first calendar quarter that is three months after the effective date of the Commission’s order approving the proposed Reliability Standards.”

Let’s do the math (and I am indebted to an Interested Party who discussed this and other aspects of the Order in a furious exchange of emails as we were both reading it). If the effective date of FERC’s order is 65 days from publication in the Federal Register, this means that if it isn’t published by Wednesday January 27, the effective date of the standards themselves (per the quotation from NERC’s implementation plan above) will be after April 1. And guess what this means? It means that most of the CIP v6 implementation dates will be pushed back half a year from what they were in the original plan.

If you’ve been reading this blog, you know that the fact that FERC didn’t approve CIP v6 in December meant that the implementation dates were mostly pushed back by a quarter – so that the first implementation date for any v6 standards would be July 1 of this year, not April 1. However, that was dependent on FERC’s approving v6 in Q1. And that is currently in question.

You might ask, “What’s the problem? FERC just approved v6 in Q1!” That’s true, but FERC, by saying the effective date is 65 days after publication in the Federal Register (this may have been due to a requirement to give Congress time to review CIP v6, which happens with "major" new regulations), and by saying that NERC’s implementation plan is based on the effective date (of the order), this means that the first implementation date for v6 will be October 1, if Order 822 isn't published in the Federal Register by January 27.

However, FERC got something wrong: NERC’s implementation plan didn’t say the effective date of the standards is three months after the effective date of the order.[i] The implementation plan reads “the first day of the first calendar quarter that is three calendar months after the date that the standard is approved by an applicable governmental authority.” While it’s simply not clear, it may be that NERC really intended that the approval date (that is, January 21, or at the latest the day the Order is published in the Federal Register) should start the clock, not the Effective Date.

So it seems the v6 implementation dates may or may not be pushed back an additional quarter, meaning v6 compliance will start on October 1, 2016. It all depends on how you read NERC’s implementation plan and FERC’s Order (and FERC’s reading of NERC’s implementation plan). Of course, if the Order is published in the Federal Register by January 27, the v6 implementation dates will remain the way I described them in this post – i.e. starting on July 1, 2016. I had hoped at least the question of implementation date would be resolved by now, but it seems there is very little “resolution” in the world of NERC CIP.

Supply Chain

There were five topics that FERC brought up as potential areas for new requirements in the NOPR; they solicited comments on all of them. The rest of this post will discuss what FERC said regarding each of these topics.

One topic was whether there should be a new standard covering security of the utilities’ supply chain. The answer on that topic was unsurprising: FERC will hold a Technical Conference on this topic on Thursday January 28. They will decide what they want to do after the conference (my guess is it will take months for FERC to come out with an order on this matter).

Transient Electronic Devices at Lows

In the NOPR, FERC was clearly quite concerned about the fact that CIP-010-6 R4, the new requirement covering transient electronic devices and removable media, only applies to High and Medium BES Cyber Systems. FERC asked for comments on extending those requirements to Lows – and it seems they got lots of comments! Mostly against doing this, of course.

But it’s also no surprise that FERC still considers this a big problem, and has now ordered NERC to develop a requirement or requirements providing some protections regarding removable media at Lows.  While it is up to NERC to develop this requirement, FERC provided some guidance on what they will accept:

1. They are not asking that R4 simply be revised to apply to Low BES Cyber Systems, along with Mediums and Highs; this would place a very high compliance burden on NERC entities. They acknowledge (paragraph 35) that NERC should take into account the lower risk posed by Low BCS in developing the controls.
2. They agree (paragraph 36) that the controls for Lows can apply on the asset level (i.e. the substation, generating station, etc.), not the BCS level. Of course, for these controls to apply on the BCS level, it would probably have required an inventory of Low impact BCS, something that NERC has taken great pains to avoid.

“Communications Networks”

Currently, communications between ESPs are exempt from being in scope under CIP v5 (and v6). In the NOPR, FERC made it fairly clear that they wanted to see protection for communications between Control Centers, even Low impact ones. So I don’t think anybody will be astounded to learn that FERC did order NERC to protect such communications in Order 822.

The comments FERC received on this topic (paragraphs 42 to 51) seem to have been relatively favorable; it seems most commenters realized that communications between control centers represent a special point of vulnerability for the grid. FERC had suggested in their NOPR that latency might be an issue if encryption were used. However, paragraph 43 of the Order quotes SPP Regional Entity to the effect that encryption-caused latency won’t usually be an issue for communications between control centers, since those communications don’t require the same millisecond-level response times that communications between protective relays in substations require.

However, FERC’s directive on this matter is not cut and dried, in my opinion. That is because it seems they have expanded the scope of what needs to be protected. In the NOPR (paragraph 53), FERC stated “We also recognize that third-party communication infrastructure (e.g., facilities owned by a telecommunications company) cannot necessarily be physically protected by responsible entities.” Here they were conceding the point many utilities make: that their communications infrastructure isn’t owned by them, but by third-party providers. FERC went on to say that logical controls (i.e. encryption) would most likely be acceptable.

But their tone seems to have changed in Order 822, although I admit that both I and the Interested Party are having a hard time understanding what they really are saying. The operational phrase seems to be the one in paragraph 53, where FERC says it is ordering NERC to “..develop modifications to the CIP Reliability Standards to require responsible entities to implement controls to protect, at a minimum, communication links and sensitive bulk electric system data communicated between bulk electric system Control Centers.” (Emphasis mine)

Paragraph 54 says “..we find that additional measures to protect both the integrity and availability of sensitive bulk electric system data are warranted. We also understand that the attributes of the data managed by responsible entities could require different information protection controls. For instance, certain types of reliability data will be sensitive to data manipulation type attacks, while other types of reliability data will be sensitive to eavesdropping type attacks aimed at collecting operational information (such as line and equipment ratings and impedances). NERC should consider the differing attributes of bulk electric system data as it assesses the development of appropriate controls.”

Paragraph 56 is even more explicit; FERC says that NERC needs to protect “communication network components and data,” although they admit that not all such components and data pose the same level of risk to the BES. This paragraph concludes with the sentence “NERC’s response to the directives in this Final Rule should identify the scope of sensitive bulk electric system data that must be protected and specify how the confidentiality, integrity, and availability of each type of bulk electric system data should be protected while it is being transmitted or at rest.” (emphasis mine)

So it seems pretty clear that, for control centers (High, Medium and Low impact), FERC wants NERC to develop requirements applying to:

1. Data communications devices between control centers. Of course, these new requirements couldn’t be applied to communications infrastructure owned by telecom providers; they could only apply to devices owned and/or operated by the NERC entity.
2. Data in motion between control centers – which would usually be protected through encryption. This seemed to me to be the main intent of the discussion in the NOPR.
3. Data at rest in control centers. This is what really surprised me, since this would be the first time that actual operational data would be protected by CIP (of course, data about the BCS and ESPs themselves are protected in CIP-011-2 R1, but that’s different). It will be up to the SDT to figure out what data need to be protected and how (obviously, one means is encrypting it at rest. Another might be tighter restrictions on who in the control center can see what types of data).

Number 3 is the big one, in my opinion. Just thinking out loud, it sounds like the SDT will have to first sort through all the different types of data found at Control Centers, both at rest and in motion. Then they’ll have to figure out appropriate protections for these different types of data. Then they’ll have to develop a classification scheme for the different data types (presumably something like Top Secret, Secret, Unclassified). Finally, they’ll have to figure out appropriate protections for these different types of data, both in motion and at rest.  This will be almost as big a job as drafting CIP v5 was; certainly a lot bigger than the v6 drafting effort.

By the way, if you think there isn’t any basis in the current CIP framework for protecting data, I refer you to the definition of Cyber Asset: “Programmable electronic devices, including the hardware, software and data in those devices.” (emphasis mine) So the data in Cyber Assets have always been “in scope” for CIP, but up until now there have never been any requirements applying to those data, except as a byproduct of protecting the hardware and software.

Remote Access

The NOPR raised the possibility of additional controls being needed for remote access, but FERC clearly isn’t ready to order those yet. Instead, they have directed NERC (paragraph 64) to “..conduct a study that assesses the effectiveness of the CIP version 5 remote access controls, the risks posed by remote access-related threats and vulnerabilities, and appropriate mitigating controls for any identified risks.” NERC needs to submit a report on the study by April 1, 2017. 

LERC and Other Black Holes

In their NOPR, FERC had expressed serious reservations about the definition of Low Impact External Routable Connectivity (LERC) in CIP v6. Their reservations were not so much about the wording of the definition itself as about the way NERC applied it in the Guidance and Technical Basis for CIP-003-6, where they provided a series of reference diagrams. A couple of these diagrams referred to a “layer 7 application layer[ii] break”, as something that eliminates LERC; assets without LERC don’t need a Low Impact Electronic Access Point (LEAP).

In Order 822, FERC is concerned (paragraph 65) that the discussion in the Guidelines seems to contradict the word “direct” in the LERC 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.” Their remedy (paragraph 73) is to direct NERC to fix this contradiction. They suggest NERC could do this by modifying “the Low Impact External Routable Connectivity definition consistent with the commentary in the Guidelines and Technical Basis section of CIP-003-6.” They direct NERC to submit this modified definition one year after the effective date of v6.[iii]

Would you like to know my opinion on this issue...? I didn’t think so, but I’ll tell you anyway. I have written close to ten posts on ERC, and LERC is almost the same thing. In each post, I thought I’d finally had the concept nailed down, only to be back writing another post a couple weeks later because it became clear there was another aspect I hadn’t considered.

I now think of ERC and LERC as black holes (like “Programmable”); it will never be possible to come up with a dictionary-style definition for these terms. The best that NERC can do – without ending up with the same problems all over again – is to come out with a set of use cases like they did in the Guidance to CIP-003-6. However, rather than bringing in a fictional concept like “layer 7 application layer break” – or unicorns or centaurs – they should simply say, “In case 1, there is LERC; in case 2, there is no LERC; etc.”

One reason I believe this is because, even if the SDT were somehow to develop a dictionary-style definition that covered all of the possible use cases they could think of, it would clearly be far too subtle for anyone to understand who didn't have a PhD in Data Communications. Almost no auditors or end users would be able to understand and apply it, so the disputes over ERC would continue unabated.

I am also convinced of this opinion by reading FERC’s discussion in paragraph 74: “As discussed above, NERC clarifies that the purpose of the ‘direct’ language in the Low Impact External Routable Connectivity definition is to distinguish between scenarios where an external user or device could electronically access a Low Impact BES Cyber System without a security break (direct access) from those situations where an external user or device could only access a Low Impact BES Cyber System following a security break (indirect access); therefore, in order for there to be no Low Impact External Routable Connectivity, the security break must be ‘complete’ (i.e., it must prevent allowing access to the Low Impact BES Cyber Systems from the external cyber asset).”

As far as I can see, the logic in this quotation is completely circular. It says that the word “direct” in the definition distinguishes between cases where external users can access BCS without a security break (i.e. “application layer break”) from cases where there is a “complete” security break. And what is a complete security break? Why, it’s one that prevents direct access! Let me save you a lot of time, SDT members: Just look for use cases to explain when there is and isn’t LERC. Don’t try to square the circle or invent a perpetual motion machine and come up with the once-and-for-all definition of ERC and LERC. Such a definition just isn’t to be found, and even if you do find something it will be useless for purposes of determining compliance.[iv]

Of course, the changes FERC is ordering will all go in CIP version 7; it now is clear this version will not be easy to develop at all. I hope to have a post out on this topic very soon.

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

---

[i] It is possible that NERC made a mistake in their 2200-page filing of CIP v6 and misquoted their own implementation plan. Since I don’t feel like downloading that file and searching through it, I’m not going to pursue this question further. I'm not too concerned on whose fault this mistake is, but I am wondering what can be done about it.

[ii] Of course, this is redundant, since Layer 7 is the Application layer in the OSI model.

[iii] I was surprised FERC didn’t tell NERC to ditch the idea that there is something called an “application layer break” altogether. In the NOPR, they seemed to be going that way.

[iv] One of the issues NERC wants the SDT to address – as discussed in NERC’s webinar this week – is ERC. So presumably both LERC and ERC can be dealt with together.