Sunday, January 31, 2016

What Do You Need to Do After April 1?


January 31: I recently wrote a post that made the case that compliance after April 1 with CIP v5 (and v6) will be quite different from what compliance with CIP versions 1 through 3 was after their compliance dates. The post went on to describe how I thought NERC entities should approach compliance with v5. However, I decided that the second part of that post (the compliance approach) needed to be rewritten, which I’ve done here. I’ve also made some lesser changes to the first part. Thus, this post entirely replaces the previous one.

Introduction
What happens on April 1? My guess is you will give one of three answers:

1.    NERC CIP version 5 comes into effect;
2.    It’s April Fool’s Day; or
3.    Some combination of these two. 

My personal preference would be the third answer. CIP v5 does come into effect on April 1, but this time is very different from when previous CIP versions (or other NERC standards) have come into effect. What will entities need to do on (and after) April 1, that they didn’t need to do in previous CIP versions?

The reason CIP v5 (and when I say CIP v5, I mean v5 and v6) is so different is that there are many areas of uncertainty regarding what the requirements mean, and many entities are far behind where they should be in preparing for the compliance date – because they have been expecting/hoping for some clear guidance, which hasn’t shown up. Of course, I’ve been saying this since 2013, but here are three recent pieces of evidence:

First, I recently wrote a post discussing a recent article written by Lew Folkerth of RF on the idea of “implicit requirements” in CIP v5. Lew had stated last October at an RF meeting that he was going to work on a list of these implicit requirements. However, in his article he said, “My opinion is that we may never be able to achieve a complete list of implied requirements; the more we mature in our understanding of CIP Version 5, the more implied requirements we will find.”

Think about this. Lew has been saying for a while (and I picked up his banner) that there are a lot of things an entity needs to do to comply with CIP v5 that aren’t actually written in the standards. Now he’s saying that it will probably never be possible to produce a complete list of these items. In other words, there will probably never be a complete list of what an entity needs to do to comply with CIP version 5!

Second, in a recent post I republished a news article on the run-up to CIP v5. That article made a point that both Lew and I have made repeatedly for more than a year: For areas of the CIP v5 standards where there is ambiguity in the requirements or definitions, the only choice the entity has is to determine for themselves the right interpretation. But they need to document their interpretation and how they arrived at it – and they need especially to show they’ve considered whatever guidance NERC or their region has put out, even if they didn’t actually follow that guidance.

Third, on January 19 I listened to a NERC webinar on “Future CIP Standards Development”. NERC officially announced that a number of issues (more than eight) in CIP v5 will be referred to the current CIP v5 Revisions Standards Drafting Team for development of revised or new standards or definitions. This in itself wasn’t a surprise, since NERC has been saying this would happen for more than a month. What was surprising was that the drafting team will be addressing what I think are probably the three most fundamental areas of ambiguity in CIP v5:

1.    The definition of Cyber Asset, especially the meaning of “programmable”.[i] I have written a number of posts on this issue, but the one I like best is still the first one.

2.    The definition of BES Cyber Asset, and especially the meaning of “adverse impact” in that definition. I have written several posts on that topic, but the best is here.

3.    The concept of External Routable Connectivity. My last post on ERC was this one. However, just like with “programmable”, I no longer think there can ever be a dictionary-style definition of ERC that will address all of the current questions. There will need to be a list describing different cases (presumably with diagrams): “In case A, there is ERC; in case B, there isn’t ERC; in case C….etc.” This is similar to the discussion of LERC in the Guidance and Technical Basis section of CIP-003-6. 

So I’m happy that the SDT is actually going to address some of the basic problems[ii] in CIP v5. Of course, this means it will easily be three to four years before the new standards and definitions are drafted, approved by NERC and approved (maybe) by FERC. Until then, NERC entities will have to resolve each of the above areas of ambiguity to their own satisfaction and document how they resolved them. In addition, each entity will need to document that they considered all available NERC guidance in arriving at their own “definition”, and that this was applied consistently across their assets (for example, both Generation and T&D need to use the same “definition” of “programmable” in deciding which devices are Cyber Assets and which aren’t).

Let’s get back to my question above: What do entities need to do starting this April that is different from what they did to comply with previous CIP versions? As I’ve just shown, there are explicit and implicit requirements in v5. Let’s discuss these separately.

Addressing Explicit Requirements
Explicit requirements are ones that are stated in the CIP v5 (or v6) standards. If the requirement has a number like R1, R2 etc. in front of it, it’s an explicit requirement. However, there are two types of explicit requirements: clear and ambiguous. While the line between these two types isn’t a clear one, in general a clear requirement is one about which there is no fundamental debate. For example, CIP-007-6 R2 Patch Management is fairly clear in its concepts, although there is some disagreement around the edges. An entity that decides to take 60 days to evaluate new security patches for applicability, rather than the 35 days in the requirement, will most likely receive a PV. It would be very hard for them to argue that the requirement isn’t clear on this point.

An example of an ambiguous explicit requirement is CIP-002-5.1 R1. I have expended billions of perfectly good electrons discussing the problems with that requirement; a recent post is here. Another example is any requirement, like CIP-007-6 R1, where External Routable Connectivity is mentioned in the Applicability section. Since the definition of ERC has been turned over to the Standards Drafting Team to rewrite (presumably in CIP version 7), its ambiguity[iii] will never be resolved until that effort is completed and approved, easily 3-4 years from now.

For “clear” explicit requirements, you need to comply with them in the same way you did for requirements in CIP versions 1-3: Develop and document procedures for compliance, and make sure the procedures are applied to all of your cyber assets that are covered by the requirement in question. If you won’t be fully compliant with one of these requirements on April 1, you need to self-report a violation and work as quickly as possible to come into full compliance. A PV may be issued, whether you self-report a violation or it is discovered during an audit.

For ambiguous explicit requirements, you first have to develop and document how you have resolved the ambiguity. To use the example above, for CIP-002-5.1 R1 you need to develop and document your own methodology for identification and classification of BES assets and BES Cyber Systems. This needs to take advantage of whatever guidance has been provided by NERC or your region, but at the end of the day it is your entity that must make the decision on what is the best methodology, since the wording of the requirement itself (and Attachment 1) is ambiguous and contradictory. You also need to document that this methodology has been applied on a consistent basis across all of your assets.

If you have taken these steps by April 1, you don’t need to self-report anything. However, if you simply have not finished this methodology by April 1, and/or you haven’t finished applying it to all of your assets in scope, I believe you do need to self-report that you are in violation and work as quickly as possible to come into compliance. In other words, for requirements that are explicit but ambiguous, you need to resolve the ambiguity in some way and proceed with complying with the requirement. You won’t get a pass from your auditor if you say you just couldn’t figure the requirement out, so you didn’t do anything at all.

Addressing Implicit Requirements
It’s a different story for the implicit requirements. First, you need to identify them. How do you do this? You think about how you comply with each explicit requirement, and you look for steps you need to take that aren’t specifically stated in the requirement. For example, you may have noticed that, while the Applicability sections of many requirements list Protected Cyber Assets, EACMS, and PACS as devices to which they may apply, you are never required to identify these in the first place. So identifying them is an implicit requirement.[iv]

It would certainly help if there were a definitive list of implicit requirements. However, as I mentioned above, Lew Folkerth now says there can never be such a list; I agree with him.[v] It is up to each entity to identify implicit requirements and document how it dealt with each one. You can find implicit requirements discussed in many documents, such as the NERC Lessons Learned and in many of my posts. They aren’t usually identified as implicit requirements, but here is a rough “field guide” to some of the primary types:

1.       If you have to develop your own definition in order to comply with a requirement, doing so is an implicit requirement. Examples of this are the word “Programmable” in the Cyber Asset definition; “adverse impact on the BES” in the BES Cyber Asset definition; “External Routable Connectivity” when the communications stream to a device includes both routable and non-routable components; and “custom software” in CIP-010-2 R1. For all of these, you have to develop and document your own definition. In addition, you need to document that the definition was applied consistently across your assets. Keep in mind that the “definition” will often not be dictionary-style, but will probably be a procedure for identifying something, as in the “programmable” procedure discussed in this post.

2.       In other cases, the entity will have to develop a list, for example lists of PCAs, EACMS, and PACS. As I discussed above, even though many requirements apply to these cyber asset types, there is no requirement to actually identify and list them in the first place. That requirement is implicit.

3.        In a number of cases, the entity needs to develop and document a methodology. For example, there is no explicit requirement in CIP-002-5.1 to identify BES Cyber Systems, so the requirement itself provides no guidance on how you can do that. It’s up to you to read whatever you can about this (including the Guidance and Technical Basis for CIP-002-5.1, rogue blog posts like this one, and the Lesson Learned just released by NERC, which primarily relates to identifying Cyber Assets) and develop your own methodology. You also need to show that you applied that methodology consistently in identifying your BCS.

4.       Some implicit requirements follow from actual requirements by simply applying common sense. One good example (borrowed from an EnergySec webinar) is the fact that CIP-003-6 R1 requires an annual review of cyber security policies, but doesn’t require the entity to change a policy if the review finds the need for a change. Of course, common sense dictates you should make the change.

5.       There is a whole class of implicit requirements that deals with virtualization. Since virtualization wasn’t considered at all in developing the CIP v5 standards, the entity has to think about what makes the most sense if they have virtual machines or virtual switching. This is one of the topics that the drafting team will take up, so there will be no official word on this topic for years. However, NERC provided some “implicit guidance” in a recent document that I discussed in this post. If you have any virtualization within your ESPs, you need to address that in some way in CIP v5, not simply pretend it’s not there.                                                                                                            
So there is a lot of work that needs to be done to comply with the implicit requirements in CIP v5, starting with the fact that there is not now, and never will be, an official list of these requirements. I think there are at least 150 different types of documentation required for CIP v5, and my guess is half of these are due to implicit requirements. This is primarily why I say the paperwork burden for CIP v5 is greater by some factor (at least three or four, in some cases a lot more than that) than the burden for CIP v3, even when you allow for the fact that there are many more cyber assets in scope for v5 than for v3.

I don’t believe PVs will ever be issued directly for violation of implicit requirements. However, since an implicit requirement is always part of complying with an explicit requirement, you will almost always have to self-report a violation of the latter. For example, if your entity doesn’t develop a consistent methodology for identifying and classifying BES Cyber Systems (an implicit requirement), but instead lets each group in your organization determine for themselves how to do this, this would probably be interpreted as a violation of CIP-002-5.1 R1 - since your entity would be identifying BES Cyber Assets differently in different instances.

If you have complied with an implicit requirement but just have not yet documented that fact, you don’t need to self-report anything. Going back to the example of identifying PACS, EACMS and PCAs, you don’t have to self-report on April 1 if you haven’t documented your methodology for identifying these devices, since this is an implicit requirement. On the other hand, if you haven’t documented your methodology because you don’t have one and you have just been identifying these devices willy-nilly, you will need to self-report that, since you haven’t identified these three items consistently and this will affect your compliance with a number of explicit requirements.

Wrapping Up
The purpose of this post has been to show that the answer to the question “What do I have to do regarding CIP v5 after April 1, 2016?” is much more complex than it was with previous CIP versions. This is primarily because of the large number of ambiguous and implicit requirements in CIP v5, and the documentation needed to “comply” with them.

To summarize what I’ve said,

1.    “Clear” explicit requirements need to be treated as they always have been in previous CIP versions. Self-reports are required for any areas in which you know (or suspect) you aren’t compliant, and PVs may be issued.

2.     To be compliant with an ambiguous explicit requirement, you need to resolve the ambiguity to the best of your ability (e.g. by developing your own methodology for identifying BES Cyber Systems, since CIP-002-5.1 R1 doesn’t provide any guidance on that), document how you resolved the ambiguity, and make sure you have applied this consistently to all cyber assets. If you haven’t done this, you aren’t compliant with that requirement, and need to self-report.

2.     You need to document how you complied with an implicit requirement, although you don’t have to make a self-report if the documentation isn’t in place on April 1. However, if you haven’t fully complied with an implicit requirement, it is very likely you have violated an explicit one (as in the two examples above); you will need to self-report that.

Feb. 3: I felt I hadn't actually answered the question in the heading in this post, so I published a follow-on to this post here.

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


[i] I certainly hope the SDT doesn’t limit themselves to just defining Programmable. I think they should consider what would be the best definition of Cyber Asset, which might not even include that word. I also think that it will ultimately be impossible to come up with a “definition” of Cyber Asset in the dictionary sense of the word. The only approach that will work, in my opinion, is some sort of list, for example “Devices with one or more of the following characteristics are Cyber Assets.”

[ii] When I say “basic problems” here, you may wonder how this relates to my recent post where I said it was time to start dealing with the “fundamental problem” with the CIP standards – namely, that they are prescriptive, while cyber security is much better addressed with risk-based standards. I regret to say that the SDT’s efforts won’t address this fundamental problem; only a complete rewrite of CIP (in a form something like CIP-014) would do that. My preference would be that NERC (and I guess FERC) decide to do that complete rewrite now. However, other than my kids and my barber, I don’t know anyone who is wholly in agreement with this idea yet. It will take a while to build up a constituency for this change. If the CIP v5 framework will be around for a number of years (not my preference!), it is still important to try to get the foundation as solid as possible, so the work that the SDT will do is important.

[iii] When I say the ERC concept is ambiguous, I need to point out it is only ambiguous in the case where the communications stream between a Cyber Asset like a relay and the control center includes both routable and non-routable (serial) components. If the stream is entirely routable or entirely serial, there is no ambiguity. In the former case, there is ERC; in the latter, there isn’t.

[iv] For that matter, you are never required to identify BES Cyber Assets or BES Cyber Systems, either. Where the word “identify” is used in CIP-002-5.1 R1.1 – R1.3, it really means to classify them after they have been identified. In developing your CIP-002-5.1 R1 compliance methodology (discussed under explicit requirements), you will need to show how you will identify BCS in the first place. I have written a lot about this problem, including in this post.

[v] I have developed a list of implicit requirements over the last five or six months, and I am continually adding to it. We at Deloitte Advisory provide it as part of the free CIP v5 workshops we have done with a number of entities in the past few months – and are continuing to do now. If you might be interested in doing this, please email me at talrich@deloitte.com.

Tuesday, January 26, 2016

Let’s Get it Right, Folks


I always look forward to EnergySec’s Weekly Update newsletter. I have almost never failed to find a few very interesting nuggets in it that I hadn’t seen anywhere else. So I wasn’t particularly surprised to find something I hadn’t seen anywhere in a recent newsletter: a link to a press release from a group called the Foundation for Resilient Societies (which I had never heard of). This press release, which quotes Joe Weiss, a well-known consultant in the area of control systems security (and who I wrote about previously in this post), uses the recent Ukrainian cyber attack to point to the fact that the CIP standards specifically don’t apply to “communications networks” between Electronic Security Perimeters[i].

The second paragraph of the press release states the problem: “Ten years after Congress passed a law with the intent of protecting the U.S. electric grid from cyberattack, electric utilities increasingly rely on the public internet for critical communications, including those between grid control rooms and transformer substations. As a result, foreign governments have been able to implant malware into the U.S. electric grid. Worse yet, no current or proposed federal regulation requires encryption or other cyber-protection of grid communications with substations.”

There are three main assertions in this paragraph. They form the basis for the entire press release.

  1. Electric utilities use the public internet for communications between “control rooms[ii]” and substations.
  2. Because of this, “foreign governments have been able to implant malware” into the grid. Note this seems to say explicitly that the “OT” networks of electric utilities have been compromised. The press release implies that the Black Energy malware that is suspected of being involved in the Ukraine attack is at least one of the types of malware referred to. So Black Energy is most likely infecting the US grid!
  3. If the NERC CIP standards or other regulations required encryption of “grid communications with substations,” these dangers might be mitigated. But they don’t require it.

The words “As a result” in the paragraph quoted above imply there is a causal relationship between items 1 and 2. That is, because electric utilities are using the public internet for substation communications, malware has made its way into the US grid. On the face of it, this wouldn’t be surprising, since almost any unencrypted traffic traversing the public internet will most likely quickly become infested with all sorts of malware.

There is one main problem with the first assertion: It’s completely false. I know of no electric utility that uses the public internet to communicate with its substations, encrypted or otherwise. The communications channel is always private (whether carrier-owned or utility-owned), often serial or Frame Relay. Where does this assertion come from? Were it true, it would be quite scary. But it isn’t.

And where does the second assertion come from – that malware has infected the grid as a result of attacks on substation communications? I have never heard of any successful cyber attack on substation communications. Given this fact, it is very hard to understand how 2 could be true. But if it nevertheless is true, where is the evidence?

The third assertion is true: NERC CIP specifically excludes communications between ESPs from being in scope. However, FERC, in their recent Order 822, ordered NERC to develop a new standard or requirements protecting communications between control centers. In the same Order (paragraph 57) FERC stated that they did not currently see the need to include communications with substations in these new requirements.

The press release seems to be advocating that FERC order that communications between control centers and substations be encrypted. While there would be a lot of problems with doing this[iii], this isn’t to say that it would never be a good idea to encrypt substation communications. But the threat requiring this step needs to be identified. Simply waving our arms and making assertions without any evidence for them doesn’t help.[iv]


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

[i] This exemption is stated in Section 4.2.3.2 in each of the CIP v5 and v6 standards.

[ii] NERC calls these “Control Centers”, not control rooms.

[iii] One concern is that serial communications probably can’t be encrypted in any useful way; they probably still constitute the majority of substation communications, and that majority would undoubtedly grow if encryption were required for substation communications. This is because utilities would remove routable communications and go back to serial. The other concern is latency, since many operations at substations need to be executed at sub second speeds, and encryption will often impose an unacceptable time lag.

[iv] There is one way in which the Ukrainian incident points to a deficiency in cyber regulations in North America: It is apparent that the substations attacked were Distribution ones, not Transmission. This means NERC CIP would never have applied to them in the first place. As I pointed out in this post, I believe that ultimately there will need to be cyber regulations that apply to the entire grid, not just Transmission. As I also pointed out, doing this will pose a very difficult political problem. 

Friday, January 22, 2016

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.

Thursday, January 21, 2016

Quick: What Happens on April 1?

January 31: I realized this post had missed the boat in several important ways, so I rewrote it here. I don't believe in removing posts, but there is no longer any reason to read this one.

Introduction
I think anybody who reads this blog will answer the question in the title in one of three ways:

1.    NERC CIP version 5 comes into effect;
2.    It’s April Fool’s Day; or
3.    Some combination of these two. 

My personal preference would be the third answer. CIP v5 does come into effect on April 1, but this time is very different from when previous CIP versions (or other NERC standards) have come into effect. What will entities need to do on (and after) April 1, that they didn’t need to do in previous CIP versions?

The reason CIP v5 is so different is that there are many areas of uncertainty regarding what the requirements mean, and many entities are far behind where they should be in preparing for the compliance date – because they have been expecting/hoping for some clear guidance, which hasn’t shown up. Of course, I’ve been saying this since 2013, but here are three recent pieces of evidence:

First, I recently wrote a post discussing a recent article written by Lew Folkerth of RF on the idea of “implicit requirements” in CIP v5. Lew had stated last October at an RF meeting that he was going to work on a list of these implicit requirements. However, in his article he said, “My opinion is that we may never be able to achieve a complete list of implied requirements; the more we mature in our understanding of CIP Version 5, the more implied requirements we will find.”

Think about this. Lew has been saying for a while (and I picked up his banner) that there are a lot of things an entity needs to do to comply with CIP v5 that aren’t actually written in the standards. Now he’s saying that it will probably never be possible to produce a complete list of these items. In other words, there will probably never be a complete list of what an entity needs to do to comply with CIP version 5!

Second, in a recent post I republished a news article on the run-up to CIP v5. That article made a point that both Lew and I have made repeatedly for more than a year: For areas of the CIP v5 standards where there is ambiguity in the requirements or definitions, the only choice the entity has is to determine for themselves the right interpretation. But they need to document their interpretation and how they arrived at it – and they need especially to show they’ve considered whatever guidance NERC or their region has put out, even if they didn’t actually follow that guidance.

Third, on January 19 I listened to a NERC webinar on “Future CIP Standards Development”. NERC officially announced that a number of issues (more than eight) in CIP v5 will be referred to the current CIP v5 Revisions Standards Drafting Team for development of revised or new standards or definitions. This in itself wasn’t a surprise, since NERC has been saying this for more than a month. What was surprising was that the drafting team will be addressing what I think are probably the three most fundamental areas of ambiguity in CIP v5:

1.    The definition of Cyber Asset, especially the meaning of “programmable”.[i] I have written a number of posts on this issue, but the one I like best is still the first one.
2.    The definition of BES Cyber Asset, and especially the meaning of “adverse impact” in that definition. I have written several posts on that topic, but the best is here.
3.    The concept of External Routable Connectivity. My last post on ERC was this one. However, just like with “programmable”, I no longer think there can ever be a dictionary-style definition of ERC that will address all of the current questions. Again, there will need to be a list: “In case A, there is ERC; in case B, there isn’t ERC; in case C….etc.” This is similar to the discussion of LERC in the Guidance and Technical Basis section of CIP-003-6. 

So I’m happy that the SDT is actually going to address the basic problems[ii] in CIP v5. Of course, this means it will be easily three to four years before the new standards and definitions are drafted, approved by NERC and approved (maybe) by FERC. Until then, NERC entities will have to treat all of the above areas of ambiguity as implicit requirements for the entity to resolve to its own satisfaction, and to document how it resolved them.

Let’s get back to my question above: What do entities need to do starting this April that is different from what they did to comply with previous CIP versions? As I’ve just shown, there are explicit and implicit requirements in v5. Let’s discuss these separately.

Addressing Explicit Requirements
I call requirements explicit when there isn’t any fundamental ambiguity in them. For example, CIP-007-6 R2 lays out a process the entity needs to follow for patch management. I won’t say it’s crystal clear, and I know there has been a lot of discussion at regional meetings about what it means. But I believe the parameters are clear enough (35 days, etc) that entities have a good road map on how to comply. I believe the majority of the requirements in CIP v5 are quite clear, and don’t implicitly require any unstated “requirements”.

So for explicit requirements, I believe the entity needs to have all of their procedures in place and documented on April 1. If they don’t, they will need to submit a self-report and try as quickly as possible to develop and document their procedures. In other words, they need to do what they had to do with previous CIP versions, as well as with other NERC standards.

If an entity hasn’t complied with an explicit requirement of CIP v5, I believe a PV might be issued, just as in previous CIP versions.

Addressing Implicit Requirements
It’s a different story for the implicit requirements. For all of these (and I realize I’m not providing a list here, since as Lew says there can be no complete list. I have discussed a lot of these in blog posts over the past three years, although I haven’t usually referred to them as implicit requirements), it is up to the entity to decide how to address each one. For example:

1.       Sometimes the entity will have to develop their own “definition” (like for “Programmable”, ERC, “custom software” in CIP-010-2 R1, etc), in order to comply with an implicit requirement.
2.       In other cases, the entity will have to develop a list, for example lists of PCAs, EACMS, EAPs and PACS. Even though many requirements apply to these cyber asset types, there is no requirement to actually identify and list them in the first place. That requirement is implicit.
3.       In still other cases, the entity will need to document how they are interpreting a particular phrase, like “adverse impact on the BES” in the BES Cyber Asset definition. Again, this doesn’t have to be a dictionary-type interpretation, but could be a procedure for determining whether or not there is adverse impact. You also need to document that you applied this procedure consistently in identifying your BCAs.
4.       In a number of cases, the entity needs to develop and document a methodology. For example, there is no explicit requirement in CIP-002-5.1 to identify BES Cyber Systems in the first place, so the requirement itself provides no guidance on how you can do that. It’s up to you to read whatever you can about this (including rogue blog posts like this one) and develop your own methodology. You also need to show that you applied it consistently in identifying your BCS.
5.       Some implicit requirements follow from actual requirements by simply applying common sense. One good example (borrowed from an EnergySec webinar) is the fact that CIP-003-6 R1 requires an annual review of cyber security policies, but doesn’t require the entity to change a policy if the review finds the need for a change. Of course, common sense dictates you should make the change.
6.       There is a whole class of implicit requirements that deals with virtualization. Since virtualization wasn’t considered at all in developing the CIP v5 standards, the entity has to think about what makes the most sense if they have virtual machines or virtual switching. This is one of the topics that the drafting team will take up, so there will be no official word on this topic for years. However, NERC provided some “implicit guidance” in a recent document, that I discussed in this post. If you have any virtualization within your ESPs, you need to address that in some way with CIP v5, not simply pretend it’s not there.                                                                                                            

So there is a lot of work that needs to be done to comply with the implicit requirements in CIP v5, starting with the fact that there is not now, and never will be, an official list of these requirements. I think there are at least 150 different types of documentation required for CIP v5, and my guess is half of these are due to implicit requirements. This is primarily why I say the paperwork burden for CIP v5 is greater by some factor (at least three or four) than the burden for CIP v3.

However, I don’t believe PVs will ever be issued for violation of implicit requirements – unless that leads to a violation of an explicit requirement. For example, if your entity doesn’t develop a consistent definition of “programmable” but instead lets each group determine for themselves what this word means, this could possibly be interpreted as a violation of CIP-002-5.1 R1 because your entity would be identifying BES Cyber Assets differently in different instances.

Of course, there is no requirement to self-report a violation of an implicit requirement unless it leads to a violation of an explicit requirement, as I’ve just discussed. For example, this means the entity doesn’t have to self-report that it doesn’t have its definition of “programmable” documented on April 1. However, the entity still has to apply that definition consistently across all its High and Medium assets, and document that it has done so.

Wrapping Up
The purpose of this post has been to show that the answer to the question “What do I have to do regarding CIP v5 after April 1, 2016?” is much more complex than it was with previous CIP versions. This is primarily because of the large number of implicit requirements in CIP v5, and the documentation needed to “comply” with them.

To summarize what I’ve said,

1.    Explicit requirements need to be treated as they always have been in previous CIP versions. Self-reports are required for any areas in which you know (or suspect) you aren’t compliant, and PVs may be issued.
2.    Implicit requirements will not generally lead to PVs or self-reports, except in the case where violation of an implicit requirement leads to violation of an explicit one. However, they need to be complied with and documented before an audit, and the entity needs to show that any definitions or methodologies shown were applied consistently.

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


[i] I certainly hope the SDT doesn’t limit themselves to just defining Programmable. I think they should consider what would be the best definition of Cyber Asset, which might not even include that word. I also think that it will ultimately be impossible to come up with a “definition” of Cyber Asset in the dictionary sense of the word. The only approach that will work, in my opinion, is some sort of list, for example “Devices with one or more of the following characteristics are Cyber Assets.”

[ii] When I say “basic problems” here, you may wonder how this relates to my recent post where I said it was time to start dealing with the “fundamental problem” with the CIP standards – namely, that they are prescriptive, while cyber security is much better addressed with risk-based standards. I regret to say that the SDT’s efforts won’t address this fundamental problem; only a complete rewrite of CIP (in a form something like CIP-014) would do that. My preference would be that the SDT decided to do that complete rewrite now. However, other than my kids and my barber, I don’t know anyone who is wholly in agreement with this idea yet. It will take a while to build up a constituency for this change. If the CIP v5 framework will be around for a number of years (not my preference!), it is important to try to get the foundation as solid as possible, so the work that the SDT will do is important.