100,000!

Last week, this blog passed the milestone of 100,000 page views since its inception in late January 2013. In addition to those views, close to 300 people receive the email feed.

While these numbers probably amount to a slow day for most pop stars, I’m happy with them – especially with the fact that readers are increasing as time goes on.

I had thought that by now we would be far down a smooth road to CIP v5 compliance, and there wouldn’t be a need for a lot of new posts. However, I’m sad (pleased?) to report that the road to v5 has proven to be bumpy, so there’s more need than ever for these posts. Fortunately, Deloitte Advisory is very supportive of my blog efforts, so I’m not going away anytime soon…..although perhaps that’s the bad news, depending on your point of view.

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

About the CIP v5 Compliance Date….

In my webinar with Karl Perman and Steve Parker of EnergySec on August 19, 2015, (the recording of which is available here), we engaged in a good discussion on whether CIP v5/v6 would be enforceable on April 1, 2016. Our consensus was that it would not be – however, there need to be a few asterisks with this statement. In order to treat this topic appropriately, I will first go over the different statements I’ve made about this issue.

Last December, I wrote a post saying the compliance date for CIP v5 (meaning v5 and v6, and most of the other dates that flow from them) should be moved back at least six months, and hopefully a year.  In that post, I gave two reasons for moving the date back. The first was that at many NERC entities funding had been slow to materialize for the effort – due to the fact that FERC had approved v5 in November of 2013, after most organizations had finalized their 2014 spending plans.

The second reason was that many entities seemed to be dismayed by the many ambiguities in v5. Given the choice between plowing ahead with v5 despite the uncertainty and standing motionless in indecision, it seemed many entities were choosing the latter course.[i]

I was not at all surprised that this post was met with deafening indifference. I realized it was way too early for people to become convinced the situation needed to change – and certainly for NERC to be so convinced. And there was still some possibility that NERC might switch gears and start a massive effort to provide lots of guidance by April 1, 2015 – since I believed that, if a good portion of the ambiguity in v5 were cleared up by that date, the compliance date wouldn’t have to be moved back.

In March of this year, I realized it was certain there wouldn’t be much more guidance by April 1[ii], so I stated in this post: “I think CIP v5 is now in the endgame, by which I mean there will soon be no more possibility that, starting 4/1/16, the v5.5[iii] standards will be enforceable.   Either the compliance date will be pushed back or the Registered Entities will be given a “holiday” – either intentionally or unintentionally – from being assessed Potential Violations (PVs), as long as they’ve made a good faith effort to comply.”

As you can see, at this point I introduced a new idea: Even if NERC and FERC didn’t take some deliberate action to move the v5 compliance date back, the standards would not be strictly enforceable on 4/1/16. My reason for saying that was related to my second reason in the December post: the level of uncertainty regarding what some of the requirements mean (especially CIP-002-5.1 R1) is so great that it is unlikely that auditors will assess PVs for entities that are making a good faith effort to comply, but simply don’t understand one or more aspects of the requirements.

I came back to both of these ideas in a post in early July, where I said “…there is simply no way the interpretation problems of CIP v5 can be addressed in time for the standards to be enforceable on April 1, 2016.” I called on NERC, the regions and the NERC entities first to acknowledge this fact, then decide how they were going to deal with it.

Since I’m a helpful guy, I also laid out my own plan for dealing with it. It involved NERC (and FERC, although I didn’t state that explicitly) taking one or two definite actions to implement a system somewhat like what was put in place for the CIP v1 rollout: each entity had a Compliant date when they had to be compliant with the CIP v1 standards, followed by an Auditably Compliant date a year later. After the AC date, the entity could be audited – with the possibility of PVs being issued. I suggested something like this should be implemented for CIP v5.

A couple people (spoilsports, in my opinion) pointed out to me that the one-year gap in the CIP v1 implementation plan was there mainly so that entities could build up a one-year audit trail, meaning entities needed to collect logs and all of the other documentation showing their state of compliance with every requirement at each point during the year. This is quite true: Since v1 was the first CIP version, and since NERC audits are always based on the period since the previous audit (usually three or six years), there would be nothing to audit right after the v1 Compliant date. But this is obviously not the case with CIP v5, since auditors who come in soon after 4/1/16 will primarily look at the entity’s state of compliance with CIP v3 for the period up until 4/1/16.[iv] However, I did concede the point that it was pretty unlikely my suggestion of having two dates would be taken up.

Soon after this post, FERC issued their NOPR on CIP v6. As I discussed it with a Knowledgeable Party (and wrote about it in this post), I came to notice one interesting fact: If FERC wants to approve v6 in time for the compliance date for most of the v6 requirements to remain at 4/1/16, they would have to make a Herculean effort to analyze all of the comments and make some quick decisions on them. This is because comments are due on the NOPR in late September, but FERC has to approve v6 by the end of Q4 in order for the 4/1/16 date to remain unchanged.

This in itself would be hard for FERC to do, but it could be even worse. FERC not only needs to approve v6 in Q4, but their approval needs to be published in the Federal Register. In some cases (like with CIP v5), there is then a 60-day waiting period before the Order becomes effective. So even though FERC approved v5 on November 22, 2013, it took more than two months for that approval to be effective, at the beginning of February 2014 . So if a) there is a 60-day waiting period for approval of v6 to be effective, and b) the effective date (not the date the Order is published in the Federal Register) is the one that is considered the "approval" date, then FERC has to approve v6 in October in order for the v6 compliance date not to be pushed back. While approving in December would be a stretch  for FERC, approving in October is close to impossible (it may even violate the laws of physics, probably Newton's First Law). But there is a good deal of uncertainty about a) and b) above, so I won't say it's at all certain that the date will be pushed back.[v]

Let’s look at FERC’s record for making decisions on new CIP versions. They issued their NOPR on v5 in April of 2013; comments were due in June. Once they were in, FERC took another five months - until November – to analyze them and make their decision. With CIP v1, the interval was around 14 months (on the other hand, Order 706 – which approved v1 – was around 600 pages long. No wonder it took so long to develop). The comments have to be first analyzed by FERC staff members, who then forward their recommendations to the five Commissioners – then the Commissioners take a while to make their decision. How can FERC possibly do all of this in two months, let alone one?

So I’d say it’s very possible that the implementation dates for the CIP v6 standards[vi] will be pushed back some amount of time. Of course, the v5 standards – including the eight that are going to be replaced by new v6 standards – will all take effect on 4/1/16; they were approved in 2013, and their compliance date is set in stone. However, in practice I find it very hard to imagine that any auditor would decide to issue PVs to entities for violating compliance with v5 standards that are sure to be replaced by v6 ones. Thus, in the case that the v6 compliance date is pushed back, I think v5 enforcement will be delayed as well.

The post I just referred to speculates that FERC’s likely delay in approving CIP v6 might even be a sign of their desire to see the v5/v6 compliance dates moved back. I said this because many observers (including me) expected FERC to issue an Order approving v6 in July, which would have ensured there would be no delay at all. The fact that they issued a NOPR instead of an Order, which makes it possible v6 won’t be approved in time to avoid a delay, leads me to believe that FERC doesn’t think a delay would be a big problem. In fact, they may have deliberately decided to issue a NOPR, knowing that this would give them a means for delaying v6 implementation that doesn’t require further action by either FERC or NERC; in other words, v6 compliance (and almost certainly v5 compliance) will be delayed just because of the natural process of approving new standards.

However, let’s say FERC does end up approving v6 in time for compliance with v5 and v6 to be due on 4/1/16. As I said above, because of the current confusion over the meaning of many of the requirements in CIP v5 and v6 (especially CIP-002-5.1 R1, the foundation for all of the other requirements), I still don’t see any possibility that there will be PVs issued for v5 non-compliance for some time after 4/1/16. This assumes that the entity in non-compliance has made a good faith effort to comply, but has simply not understood something – or more likely, they have understood one point (perhaps the definition of “programmable”) one way, but the auditor understands it differently. Since there will be no definitive resolution of any serious interpretation issue until a SAR or RFI bears fruit at least two to three years from now,  I can’t see any auditor issuing a PV in such a case.

There is plenty of evidence for what I’ve just said. I’ve heard one region state very explicitly that they don’t expect to be coming down hard on people for honest misunderstanding of the requirements for some time after 4/1/16; I’m told other regions have made similar statements. In fact, I had a long conversation with an important compliance person for one of the regions last week, who was totally in agreement on this. In our webinar on August 19, Steve and Karl– who have more dealings with the regions than I do – also both agreed with me on this point.

There are a few further points I want to make:

1. The requirement for a good faith effort is important. Obviously, everything I’ve just said doesn’t apply if an entity thinks they’re above the law and they don’t need to take the time to come into CIP compliance. I don’t personally know of any entities who have that attitude, but it’s possible there are a few. You still need to aim to be fully compliant on 4/1/16, and not slack off your efforts just because of something you read in a blog post.
2. One point the regional compliance person I just mentioned made to me is that entities that exhibit “massive ignorance” (I think that was his wording) regarding one or more important issues in v5/v6 will not receive a “get out of jail free” card. What he means by this is an entity that has not made any effort to seek out available guidance on a particular topic – such as the meaning of ERC – won’t get a lot of sympathy if their interpretation is far off the mark. The moral of this story is that you need to keep up your efforts to understand v5 by paying attention to all of the new draft Lessons Learned, what your Regional Entity says in their compliance meetings, etc. And of course, if you want to discuss a specific issue, you can always call your Region to find out their opinion on it.
3. You may wonder about self-reporting. Unless the compliance date is officially moved back (or FERC de facto moves it back by delaying approval of v6), I don’t think there’s any possibility that an entity won’t have to self-report any CIP v5 violations that are found after 4/1/16. Of course, I don’t think a PV will be assessed for a self-reported violation unless the Region decides there is a lack of good faith – but again, it isn’t likely that a PV will be issued for a simple misunderstanding of a requirement or definition.
4. When it comes to ambiguity, not all of the CIP v5 standards and requirements are in the same boat. In particular, CIP-002-5.1 R1 stands out because it is not only ambiguous but self-contradictory. Even more importantly, the way that 99% of the entities and auditors are interpreting this requirement (and Attachment 1) directly contradicts a good part of the wording (Don’t get me wrong here: I have no problem with the fact that compliance practice violates the wording, since I believe the way entities are complying with R1 makes much more sense than the way it is written. But the requirement will never be enforceable until the words are changed to match the practice). I have complained about this requirement in at least 50 posts in the past 2 ½ years, and there will be more coming soon. I see no way that this requirement can be fixed other than rewriting it; in my opinion, this needs to be done ASAP (including definitions of “programmable” and “adversely impact the BES”, since the lack of these is very much part of the problems with R1).
5. Since I’m not talking now about an official rollback of the compliance date (or of a separate enforcement date), I’m not sure when CIP v5 and v6 will actually be enforceable. It’s not something that will be announced by NERC, but it will occur region-by-region, as the auditors and the entities both decide that NERC has sufficiently addressed the ambiguities in v5 and v6 (my guess is it will be about a year after 4/1/16)[vii]. And I think it’s almost certain that the current version of CIP-002 will never be enforceable until it is rewritten.[viii]
6. However, if the process of rewriting CIP-002 were started today with a SAR, it would be at least three years before the final product was available; this doesn’t do much good for entities as they prepare for compliance next year. NERC should develop a comprehensive Lesson Learned (or some other document) setting out how NERC understands the BES Cyber System identification and classification process in R1. This document needs to be developed ASAP, and in my opinion should be ready at least a year before the regions expect compliance to be enforceable. The document won’t be very different from the guidance that the regions have already provided on compliance with R1. The difference is that the document will need to admit that it contradicts some of the current wording of the requirement, since that is the only way to come out with a coherent, consistent “story” of the asset identification process in CIP v5. I will very shortly start a series of two or three posts that make this point.

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

---

[i] I hear there are some entities that are still paralyzed by indecision. Of course, this is far more serious than it was last year.

[ii] Indeed, on that date there were only two finalized Lessons Learned posted, neither of which was on a controversial topic. I think there’s only one more up today.

[iii] I have sometimes referred to the amalgam of CIPs v5 and v6 that entities will actually have to comply with as “v5.5”. Most of the time, I just say v5 like everyone else does (including NERC) – although I know there are some people who don’t really understand this, and think CIP v6 is a new version that entities will have to implement after they’ve implemented v5.

[iv] Of course, all of the regions have made some provision for entities to be able to move to v5 compliance, in whole or part, before the 4/1/16 date. However, after 4/1/16, they can only be subject to PVs on what they have done since that date.

[v] I had the details wrong when I first put up this post. I appreciate an Interested Party for setting me straight on this.

[vi] To see the full compliance schedule for v5 and v6, see this post.

[vii] While I’m fairly resigned to the idea that there will never be a formal process pushing back the enforcement date – assuming FERC doesn’t delay approving v6 – I’m still not comfortable with the idea that this will all be done informally. It would be nice if NERC – or maybe the regions acting on their own – made some sort of statement saying that for a certain period of time there should be no PV’s issued for violations caused by honest confusion (or something to that effect).  As I said in a previous post on this topic, it would also be nice if the Chicago Cubs won the World Series this year – but what do you know, they’re still in contention at the beginning of September! So don’t rule out miracles.

[viii] You may wonder how CIP-002 could be unenforceable yet all of the other standards could be enforceable, given that 002 is the foundation for the other standards. I actually think this is possible. The auditors will accept whatever list of BES Cyber Systems the entity has come up with, as long as they can show a plausible process for identifying and classifying them. But once that list is accepted, they can still hold the entity to compliance with the other standards.

Lew Folkerth on ERC

I have written several times (the most recent being here) about Lew Folkerth of RFC, who has long experience and great insights on the subject of NERC CIP compliance. He writes good articles for RFC’s monthly online magazine, and that tradition continues in his article for the July newsletter (you can find the newsletter here. Then click on “The Lighthouse” on the left side).

I thought the whole article was very good, but I was at first puzzled by the discussion of External Routable Connectivity. I recommend you read at least that section of the article; however, the salient points are in this paragraph:

“Our conclusion, then, must be that the ability of any Cyber Asset outside of the ESP to reach “PLC,” by any path, will give “PLC” External Routable Connectivity. While it may be theoretically possible to demonstrate that no External Routable Connectivity to “PLC” exists in a very small network, this becomes exponentially more difficult as the size of the network increases. Also note that if this position is taken then every Cyber Asset in the ESP with External Routable Connectivity, such as “Internal Workstation” in our example, becomes an Electronic Access Control and Monitoring System (EACMS), as each of these Cyber Assets controls access to “PLC.””

Before we go further, let me say that although I have written a number of posts on ERC (the most recent being this one), I have always focused on the case of a relay in a substation connected serially to an RTU, which is itself routably connected to a control center (in fact, I don’t think I’ve seen any other discussion – before Lew’s – that didn’t focus on the same thing). The question in this case is under what circumstances that serially-connected relay can be said to participate in ERC.

The case Lew is addressing is very different. It’s an all-IP network protected by a firewall. Some of the devices (like “Internal Workstation”) are directly accessible through the firewall; others (like the “PLC”) are not. The security question behind this is whether blocking access to a particular device through firewall rules removes ERC.

I had a phone discussion with Lew about the article, and he clarified a couple points that weren’t completely clear to me from what he wrote. Here are the main takeaways:

1. On a routable network, most OS’s can be easily configured to pass traffic to another machine. So even though the PLC in his example isn’t directly accessible through the firewall, it is accessible if another machine is forwarding traffic to it – and in that case, it has ERC. So if you are claiming that your firewall is blocking ERC for some devices, you have to show the auditor that no devices with ERC are forwarding traffic to other devices. Additionally, you will have to watch the network like a hawk to make sure that forwarding isn’t turned on for a device that has ERC, toward another device that doesn’t.
2. If a device with ERC is passing traffic, it needs to be declared an EACMS. I admit I originally had a hard time understanding this point. But Lew points out in an email “by creating what is effectively a mixed-trust network within a single ESP (devices with and without ERC), the entity is using its devices with ERC as firewalls to keep ERC out of the other devices. This is why the device with ERC also meets the “perform electronic access control” portion of the EACMS definition.” Note that Lew isn’t saying that just the devices that are actually forwarding traffic are EACMS; he’s saying that every device to which external access is allowed by the firewall is effectively controlling access for the other devices on the network, since a small change in its configuration would allow that access.
3. In a further discussion, Lew pointed out that potentially every device in an ESP might have to be declared an EACMS, even if for most of them direct external access was blocked at the firewall.

The bottom line is that you need to think long and hard before declaring that some of the Cyber Assets within your ESP have ERC and others don’t, based on whether or not you’re allowing access to them through the firewall. If you bite the bullet and say they all have ERC, you will of course have a somewhat greater compliance burden, but your audits will be much easier (and you won’t stay up nights worrying that somebody – without telling you – is configuring forwarding on a Cyber Asset with ERC). Or in Lew’s words, “I think the message is simple: ‘Don’t mix trust (ERC and non-ERC) in the same ESP.’ It’s not that you can’t do it, but you’ll have a hard time documenting it. The security risk and the compliance risk make the practice inadvisable.”

However, there is an area Lew still isn’t sure about. That is the question how Interactive Remote Access (IRA) affects this. With IRA, the device needs to be reachable by the Intermediate Server, which is hopefully within the DMZ – but that means that technically the device is reachable from outside the ESP, and thus meets the definition of having ERC. So if the IS is the only device that can directly access any device within an ESP, is there still ERC?

At one point, I started writing “Tom’s Lessons Learned”. This post should be called one of “Lew’s Lessons Learned”. This is really what the Lessons Learned are for: explaining direct implications of the wording of the requirements. Note that for once I’m not complaining about any ambiguity or mis-wording of the requirements here – Lew just pointed out some important implications of the existing wording that probably aren’t obvious to most NERC entities (they certainly weren’t obvious to me!).

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

MRO Security Conference

I’m pleased to announce that, for the second year, the Midwest Reliability Organization (MRO) is presenting their Security Conference in St. Paul, MN on September 22, 2015.  Led by esteemed security professional Steen Fjalstad, this conference is a leading security event in the NERC community. And for the first time, it is open to NERC security professionals from all regions, not just the MRO.

Even better, it’s free! There’s a great list of speakers and panelists. Patrick Miller will be the keynote speaker, and Stephen Batson of Deloitte Advisory will be a panelist discussing physical security issues.

You can read about and sign up for it here. Because space is limited, I recommend signing up soon.

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

The News from Texas

On Tuesday August 11, 2015, I had the good fortune to listen and watch the webcast of “Chapter 1” of what will be a series of meetings (over the next few months) on CIP v5 run by the Texas Reliability Entity, Inc. (TRE). The series is entitled “The Hitchhiker’s Guide to CIP version 5”, and is being presented as a series of one-day meetings. You can find the slides from Chapter 1 here; there was no recording made.

The presentations were all very good, touching on various topics in CIP v5 compliance (I assume the remaining Chapters will be similar); the only problem was some audio issues for those of us on the phone, which I hope will be fixed before the next Chapter is presented. I don’t believe the date for Chapter 2 has been set. I did just notice that the webcast was only promised for Chapter 1; I certainly hope the remaining Chapters are also webcast.

This post lists the points I found most interesting – I’m grouping these simply by the order in which they occurred in the webcast, not on some judgment of their relative importance.

1.       One of the first presentations was on CIP-002, and it brought up a topic I’ve made the subject of two posts (here and here): the fact that an entity isn’t required to use the same grouping of BES Cyber Assets into BES Cyber Systems for all CIP v5 requirements. That is, the entity can do the grouping one way for one requirement and another way for another requirement. The TRE speaker brought up a good example – that I had also provided in the second of the above posts - of how this could be advantageous. Say you have a lot of devices (perhaps relays) that are all going to have to take a TFE for a particular requirement. Rather than have to do the TFE paperwork for each of those relays, they could all be declared one BCS for the purposes of that requirement; hence only one TFE is needed. You can see other examples of how this might help in the two posts linked above.

2.       Note: This wasn’t said in the TRE meeting, but – because I realize that the above example might require the “Relay BCS” to span ESPs - I’d like to point out that it is fine for BCS to span ESPs, as long as all communications between ESPs goes through an EAP. If that were not to happen, then the cyber assets in the communication path would need to be protected as at least PCAs, since they would be within a single ESP. I want to thank an Interested Party for explaining this to me.

3.       While only a list of BCS is required, it is a good idea to have a list of BCAs, since otherwise you can’t prove that all BCAs are in a BCS. I’ll take that one step further: It’s also a good idea to have a list of Cyber Assets, to show you have considered every one of them to determine whether or not it is a BCA.

4.       Note: This also wasn’t said at the meeting, but I want to point out that, in my “top down” approach to identifying BCS found in this post – not to be confused with TRE’s “top down” approach discussed at the meeting, which is a different thing – you don’t have to identify every BCA, because you start by identifying BCS. You do still need to list all of the components of the BCS, so that you can prove that cyber asset-specific requirements like patch management have been comprehensively applied. But this means there is no need to look at each BCS component to figure out whether it meets the BCA definition; that analysis isn’t required for each component, once it has already been determined to be part of a BCS. The same Interested Party explained that to me, although it was a while ago.

5.       You need to detail how you designed your ESPs, not simply show them on a network diagram.

6.       Similarly, you need to document the process you used to identify EAPs, not just list them. This process should include identifying the traffic that needs to cross the EAP.

7.       In what will I’m sure be a controversial statement, it was said that low entities should document their Low impact BCS, mainly because they won’t be able to prove whether or not they are subject to LERC (Low impact External Routable Connectivity) without this. I discussed this topic in this post, and also during my webinar with EnergySec on Wed. Aug. 19^th. I pointed out that, if an entity wants to argue that a Low impact asset doesn’t have LERC, despite having a routable connection coming into it, this will inevitably result in a list of Low BCS being required; without such a list, they could never prove they didn’t have LERC. This means you will definitely need a list if you are going to make such a claim, but I don’t think you will otherwise.[i]

8.       There was a very good discussion of virtualization; it starts on slide 49 of the presentation. Some of the points that were made included: 1) Mixed-trust virtualization (in which both ESP and non-ESP devices are virtualized on the same virtual server) is allowed (and the speaker said that NERC had admitted this was the case) - however, it is important to justify why this was done; 2) In general, you need to consider how virtualization will affect compliance with each requirement – for example, are the hypervisor and the client device in the same PSP? (They need to be); and 3) If your hypervisor hosts a BCA or BCS, it must itself be a BCA.

9.       During a discussion of scripts and Interactive Remote Access, the TRE auditors confirmed what I and others have been saying for a while (and NERC now agrees with us): that, to address the many areas of uncertainty in CIP v5, the entity needs to determine on its own what is the best way to resolve this uncertainty (after examining all of the available guidance on the issue in question). But what is most important is that the entity document how they came to whatever conclusion they reached.

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

---

[i] My point in the post and the webinar was that it might be better for NERC to simply give up the idea of having any exceptions to LERC. This is because FERC clearly doesn’t like NERC’s current interpretation of LERC, as it is illustrated in Reference Model 6 in the Guidance to CIP-003-6. IMHO, if the rule is made that LERC is present whenever there is a routable connection coming into the Low asset, this will eliminate the need for a list of Low BCS. What was said at the TRE workshop only confirms me in this opinion.

Latest Webinar Recording Posted!

The recording and the slides from the August 19 webinar that I did with Steve Parker and Karl Perman of EnergySec have been posted. The title was “What Does the FERC CIP v6 NOPR Tell Us?”  Since I was there, I can tell you it was quite a good discussion, and you’ll find some interesting points were made.

The recording is here and the slides are here.

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

Did FERC Just Weigh in on ERC?

In Part II of my recent series of posts on FERC’s NOPR from July, I discussed at some length the section of the NOPR (pages 43 and 44) that deals with Low impact External Routable Connectivity – or LERC. To summarize what I said:

1.       FERC doesn’t have a problem with NERC’s definition of LERC: “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.”

2.       However, they do have a problem with how NERC is interpreting the word “Direct”. FERC states on page 44 that “We seek comment on the implementation of the ‘layer 7 application layer break’ contained in certain reference diagrams in the Guidelines and Technical Basis section of proposed Reliability Standard CIP-003-6.”  

3.       A footnote at the end of this phrase points to Reference Model 6 on page 36 of CIP-003-6, in which it is stated that there is no LERC because “There is a Layer 7 application layer break or the Cyber Asset requires authentication and then establishes a new connection to the Low impact BES Cyber System.” FERC clearly doesn’t understand what an “application layer break” is, and how it results in the external routable connectivity no longer being “direct” – i.e. it has been “broken”.

4.       FERC states that, depending on the comments received, they may require a revised definition of LERC, presumably to make clear that, whatever an “application layer break” is, it shouldn’t be seen as breaking the “direct” routable connection.[i]

5.       In the above-linked post, I didn’t comment directly on FERC’s issue, because I saw another one that overrides it, which is specific to the Low impact environment: NERC has of course taken great pains to emphasize at every turn of the road that an inventory of Low impact cyber assets isn’t required for compliance with any of the requirements. In order to do this, of course, they need to write the requirements so that they can be audited simply on an asset-level basis, not by requiring the auditors to look at individual cyber assets. If auditors do have to look at individual cyber assets, it’s almost inevitable that a complete cyber asset inventory will end up being an “implied” requirement for Lows.[ii]

6.       Unfortunately, it appears to me that the CIP v6 SDT went too far when they tried to point out a condition under which, even though there would be external routable connectivity coming into a Low asset, this ERC would be “broken”. And it doesn’t really matter what that condition is: it could be an application layer break, it could be a cyber asset requiring new authentication, it could be that cyber assets painted blue are considered to break the ERC, etc. In my opinion, any condition that NERC might point to as leading to a break in direct ERC will have to be on the cyber asset level, since it is only on that level that such a break would be possible. Ergo, creating such a condition will inevitably require some inspection of individual cyber assets – and therefore lead to the implicit requirement that all Low cyber assets be inventoried, at least at any Low asset for which it is claimed that an external routable connection is “broken” by some condition or other.

7.       In the post, I therefore suggested that NERC give up the idea that LERC could be “broken”. I suggested they simply state that a Low impact asset that has any external routable connection (except for the exceptions listed in the last sentence of the LERC definition, such as IEC 61850 GOOSE) has LERC, period.

8.       However, in taking this tack I was in a sense evading the question whether FERC’s unhappiness with the idea of an “application layer break” was justified. For Lows, this is no longer an issue as far as I’m concerned, since I think trying to state any condition for breaking LERC is tantamount to requiring an inventory of Low impact cyber assets (and might also require designating an ESP).

But how about for Highs and Mediums? Does FERC’s concern shed any light on the questions regarding the definition of External Routable Connectivity (which of course only applies to High and Medium assets or Facilities)? The caveat I described in items 6 and 7 above doesn’t apply to Highs and Mediums, since there is no question that a cyber asset inventory is required for them.

Nevertheless, it really seems to me that FERC’s objection does apply to the ERC discussion. I have been spending a lot of time on the question of the meaning of ERC recently, as evidenced in this blog post and this webinar recording.  The one thing I have been quite sure about is that “application layer break” is a valid concept, and that it does “break” ERC.

As described in the blog post just referenced, I came to this idea originally after seeing Morgan King of WECC do a presentation on this at WECC’s winter CIP User Group meeting. Morgan didn’t use the same term for this; instead, he called it a “protocol break”. But he did at least try to flesh out what “protocol break” means[iii]; in the CIP-003-6 Guidance and Technical Basis (where the infamous Reference Model 6 is found), there is no elaboration of what the phrase means.

I know NERC is working on guidance on the meaning of ERC. Had I been asked to help them on this before the NOPR came out, I would have reiterated what I said in my ERC post (and the June webinar I did with EnergySec): a protocol layer break (roughly, terminating a routable session and initiating a serial session, using the normal example of a substation RTU connected routably to a control center, with a relay connected serially to it) does constitute a “break” in ERC. But now I have to change my opinion on this. FERC clearly doesn’t think that anything short of requiring re-authentication constitutes a break in ERC.[iv] I suggest NERC consider following suit.[v]

However, you may ask, “Why does it matter what FERC thinks at this point? ERC was one of the definitions developed for CIP v5, and FERC didn’t state they had any problems with it when they approved all of the v5 definitions in Order 791.” This is true, but their problem with LERC isn’t with the definition itself, but how it is being interpreted; my guess is they feel the same way about ERC – namely, that any interpretation that says a “protocol break” terminates ERC is wrong.

Nevertheless, it is true that FERC can’t directly affect how NERC interprets a requirement or a definition once it has been approved (were a NERC entity to submit a Request for Interpretation on this issue, then FERC could weigh in. Other than that, they don’t have any venue for doing so).  However, I’m not sure it’s a good idea for NERC, at this point, to go against a principle that has been clearly enunciated by FERC. Even if NERC (i.e. the CIP v5 Transition Advisory Group, which I believe is working on this issue) wants to endorse the idea of a protocol break, I’m not at all sure they should move forward with that idea.

It’s especially not a good idea to go against FERC if, come October or whenever FERC issues their Order addressing the issues in the NOPR, they order NERC to change the LERC definition to make clear that nothing short of requiring re-authentication will “break” it. Even though that wouldn’t have any direct impact on ERC, I don’t see any real difference between the LERC and ERC situations; if FERC doesn’t like the protocol break concept in the former case, they clearly don’t like it in the latter case either. It just wouldn’t be a wonderful idea for NERC to ignore their opinion on this matter.

So I’ve changed my mind on how ERC should be interpreted – not because of some technical argument but simply because I think it is bad politics not to do so.

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

---

[i] The “application layer break” was only one of two conditions NERC identified that would break the direct connection; the other was the condition where a cyber asset requires authentication and establishes a new connection to the Low BCS. FERC didn’t comment on this second condition.

[ii] Speaking of implied requirements, I and Matt Light of Deloitte will be doing a workshop on exactly this topic – implicit requirements in CIP v5 – during EnergySec’s Security and Compliance Summit in Washington, DC in September. See this blog post for more information.

[iii] See my post on ERC, already referenced above.

[iv] As mentioned in the first footnote above, FERC was silent on whether requiring re-authentication causes a break in ERC (this was the second cause of “broken” ERC pointed to by the CIP v6 SDT in Reference Model 6, after the application layer break itself). So I can’t even be certain that FERC approves of this idea.

[v] Ironically, NERC did take a position much like FERC’s in their April Memorandum on “Network and Externally Accessible Devices”. I and others criticized their position as being overly restrictive, but my position seems much less defensible now that FERC has spoken out on this subject. Of course, that Memorandum has been withdrawn, along with the other Memoranda that were issued with it. I’m told NERC is working on a new Lesson Learned addressing ERC.

Workshop at EnergySec Summit Sept. 14

I'm pleased to announce that I and Matt Light of Deloitte will be leading a three-hour workshop the afternoon of Sept. 14, the first day of the EnergySec Security and Compliance Summit in Washington, DC. The title of the workshop is "Exploring the 'Implicit Requirements' in NERC CIP version 5 – What’s not stated as a requirement is just as important as what is."

Here's a description:

More than was the case with the previous CIP versions, NERC CIP version 5 includes a number of “implicit requirements” – i.e., steps that an entity should take in order to comply with the written requirements; these implicit requirements aren’t themselves explicitly stated in the standards. They occur in many of the CIP version 5 standards, although there is a large concentration in CIP-002-5.1. Complying with them is as important as it is for the “explicit” requirements.

Tom Alrich and Matt Light of Deloitte Advisory will lead the discussion of this issue.  Matt and Tom will present the implicit requirements they have identified so far; workshop attendees are welcome to bring up others they have identified. The workshop is intended to be completely interactive, and the goal is to identify and discuss all of the implicit requirements in CIP v5, as well as how entities should “comply” with them. This will help NERC entities have a full picture of what they actually have to do to comply with CIP version 5.

At the end of the week before the Summit, all workshop registrants will be emailed the preliminary list of implicit requirements, including discussion of each. This list will be revised after the workshop, and may be revised in the future as well; all workshop registrants will receive these updates.

  

Tom Alrich has been helping NERC entities comply with NERC CIP since 2008, first with Encari LLC and then with Honeywell Process Solutions. Tom is now part of Deloitte Advisory, where he is a Manager in the Cyber Risk Services practice, specializing in Power and Utilities.  Tom started attending and writing about the NERC CSO 706 (CIP) Standards Drafting Team meetings in 2010, as CIP versions 4 and 5 were drafted.  Since early 2013, he has written a popular blog on developments in implementation and interpretation of CIP version 5.  Tom has a Bachelor’s degree in Economics from the University of Chicago and lives in Evanston, Illinois.

Matt Light is a Manager within Deloitte Advisory’s Cyber Risk Services practice. He has over 8 years of experience working with electric power utilities on critical infrastructure protection and cyber risk management, first with the US Department of Energy (DoE) and more recently with NERC. His projects have included development of frameworks for building a cybersecurity program and measuring the maturity of the program relative to industry best practices. He also has considerable experience with collaborative efforts between the US government and industry, focusing on cyber threat information sharing and analysis capabilities.

Matt has a Master of Public Policy degree from Georgetown University and a Bachelor’s degree in Materials Engineering from Rensselaer Polytechnic Institute.

There is a $300 fee for the workshop, which goes entirely to EnergySec - a good cause! I hope you can join us for this. To register for the Summit and the workshop, or to get more information, go here.

New Webinar: “What Does the FERC CIPv6 NOPR Tell Us?"

For the third time in four months, I’m joining Karl Perman and Steve Parker of EnergySec to discuss topics of interest to the NERC community as it prepares for CIP version 5 compliance. This time, we’re discussing three topics regarding FERC’s recent NOPR – a document that raised a number of important issues, and even more important questions.

The webinar will be held Wednesday August 19, 2015 from 1-2 PM Eastern Time. You can read about it and sign up here. As always, if you can’t make this time and you sign up anyway, you’ll get the link to the recording when it is posted a few days after the webinar.

See you then!

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

You May Want to Reread Yesterday's Post

As I usually do, this morning I reviewed my post from yesterday, to see if there were a few minor tweaks I wanted to make. I found some minor tweaks, of course, but I also found a major one: I realized that the scenario I outlined in that post could be accomplished without requiring FERC to issue a separate Order pushing the CIP v5 enforcement date back. In other words, the v5 and v6 enforcement dates would both be pushed back, as long as FERC doesn't approve v6 in the last quarter of 2015. No extra effort is required on either FERC's or NERC's part, for this to happen.

So you may want to reread that post, if you read it through the email feed (or if you read it online before you saw this post). There is another advantage to the revised post: It's now shorter and much less complicated. How often does that happen on Tom Alrich's Blog? It's got to be a first.

FERC’s NOPR, Part III: Will It Move the CIP v5 Compliance Date Back?

I admit this post is kind of wild speculation, but an interesting thought occurred to me as I was working on my two posts on FERC’s NOPR that were published last week. The thought relates to a previous post in which I stated (although not for the first time), that the enforcement date for CIP v5 should be pushed back a year from 4/1/16 – because there is no way NERC can provide enough guidance on dealing with the ambiguities in v5 for entities to be certain about their compliance obligations in time to be compliant by that date.

However, I admitted in that post that to make this happen would require a large number of pieces to fall into place: NERC, FERC and the entities would have to be in fairly close agreement on what needs to be done about the v5 enforcement date, and they’d all have to agree to go beyond what’s written in the v5 standards and the NERC Rules of Procedure. Also, FERC would have to issue one or two Orders to facilitate things. It could be done, but we’re talking about a lot of work on a lot of people’s part, as well as a big loss of face by NERC and FERC.

But as I was working on my NOPR posts, and corresponding with a Knowledgeable Person on questions about the v6 Implementation Plan, I saw a way in which FERC could move the v5 enforcement date back without anybody losing too much face, and without extraordinary changes to the Rules of Procedure. More importantly, if FERC were planning to do this, it would explain a big question I have: why FERC didn’t just approve the v6 standards in an Order, and also release a NOPR on the different topics they want to get feedback on. Instead, they issued a NOPR that said they intend to approve v6 with no firm date for doing so, and meanwhile brought up a number of pretty thorny issues they want addressed, supposedly very quickly.

Here’s what I’m thinking:

1.       As you hopefully know by now, the CIP standards that entities will actually have to comply with will be a mixture of v5 and v6. This mixture includes the v5 versions of CIP-002, CIP-005 and CIP-008, along with the v6 versions of all the other standards (there were no v6 versions developed for 002, 005 and 008, which is why those three v5 standards will “survive”).

2.       The compliance date for the v5 standards is effectively set – by the v5 Implementation Plan approved by FERC in Order 791 in 2013 – at April 1, 2016.

3.       The v6 standards also have that compliance date (with a bunch of exceptions – see this post), but with the provision that FERC has to approve the v6 standards more than three months before that date. Moreover, FERC might actually have to approve v6 up to six months before the compliance date (i.e., this October), depending on how the words “effective date” are interpreted. This means FERC has to approve v6 by December 2015 at the latest and possibly as early as October - if the v6 standards are to be enforced on 4/1/16.

4.       Given that we’re now between three and six months away from when v6 has to be approved, I – and others – found it quite odd that FERC didn’t just issue an Order approving them on July 16. Instead, they issued a NOPR that indicates they are seriously thinking of ordering a few big changes in v6. In addition to that, they are thinking of having NERC develop an entirely new standard dealing with supply chain security. They are asking for comments on all of these things, which are due 60 days from publication of the NOPR in the Federal Register; this most likely means comments are due in late September.

5.       Given this (and I here acknowledge my debt to an Interested Party for pointing out these finer points, although the speculation about the implications is entirely mine), it means the FERC staff will have, at the most, less than 90 days (September to December) and maybe even less than 30 days (September to October) to sort through the sure-to-be-voluminous comments on these important matters and make their recommendation to the Commissioners. Plus the Commissioners will need some time to decide whether or not they’ll follow those recommendations, which time also has to come out of the 30-90 days. In the worst case, if the most conservative interpretation of “effective date” is adopted, FERC would have less than four weeks for the staff and Commissioners to do the work necessary to make the decision to approve v6. Why would FERC put themselves in this kind of position, if they were sure when they wrote the NOPR that they would approve v6 (and I still believe it's inevitable they will approve it)?

6.       This is why I found it so strange that FERC issued a NOPR. They could have issued an Order approving v6, along with a NOPR requesting comments on the changes they would like to see. Assuming they want to approve the v6 standards in time for the compliance date not to have to be moved back, they are leaving themselves almost no time to make some very weighty decisions (whether to require protections for all control center-to-control center communications, whether to effectively require auditing of connectivity of individual cyber assets at Low assets, whether to extend CIP-010 R4 to bring Transient Cyber Assets used at Low impact assets into scope, whether to order the new supply chain standard, and more. All of this is discussed in my two previous posts on the NOPR).

7.       But what if the above assumption is wrong? What if FERC actually intends to have lots of time to make these decisions? In other words, what if FERC has already decided that it wouldn’t be the worst thing in the world if the v6 compliance date were moved back? If they took say nine months to do their analysis and issued their Order approving v6 in June 2016, this would result in the v6 compliance date moving back to October 1, 2016 or January 1, 2017; if they took a year for their analysis (and you may remember they took 17 months to approve CIP v1), it might move the compliance date back to April 1, 2017.

8.       You may point out – as the Interested Party did to me – that the v5 Implementation Plan is already the law of the land, meaning that if FERC doesn’t approve the v6 standards this year, all ten of the v5 standards will still take effect on 4/1/16.   I don't see a problem with this, since many NERC entities (including some large ones) have already switched their CIP compliance programs entirely over to preparing for compliance with v5. The Regional Entities aren't enforcing v5 now - just encouraging entities to start working on it. That policy could continue after 4/1/16, until a date when it was agreed that the v5 standards should be enforceable (ignoring the "Identify, Assess and Correct" language, of course - which all Regions and entities are doing now). That date might be made the same as the date that v6 becomes enforceable. For example, if FERC delays approving v6 long enough that the v6 date becomes 4/1/17, the v5 "Enforceable" date could be made to coincide with that. This would effectively result in the entire v5-v6 enforcement date structure being moved back by a year, although some of the requirement-specific dates in the v6 Implementation Plan would have to be moved back by consensus - which I don't think would be hard to achieve.

9.    Moving the date back would of course have the nice side benefit of giving NERC and the industry time to develop all of the guidance that will be necessary for entities and auditors to understand CIP v5 and v6. This would allow v5 and v6 to really be enforceable on the revised v6 compliance date.

Let me summarize what I’ve just said: Since FERC didn’t approve the v6 standards on July 16 but instead issued a NOPR asking for comments on some fairly substantial changes to the standards, this now leads to the possibility that they won’t approve v6 in time for those standards to be effective on 4/1/16. This could lead to the enforcement date for both the v5 and v6 standards being moved back (as I've advocated), without requiring any additional FERC Orders or changes to the NERC Rules of Procedure. And this might possibly be what FERC wants to happen anyway.

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