Friday, November 17, 2017

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

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

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

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

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

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

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

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

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

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

The views and opinions expressed here are my own, and do not reflect those of any 6organization I work with. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

Monday, November 13, 2017

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

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

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

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

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

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

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

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

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

  1. As I said above, CIP-003 will be at the v7 level in less than two years; plus a drafting team will start work on v8 of that standard soon.
  2. The second version of a new standard, CIP-014-2, is in effect.
  3. CIP-013-1, the new supply chain security standard, has been submitted to FERC for approval.
  4. Along with CIP-013, two modified versions of existing CIP standards were submitted, and will be approved along with CIP-013. These are CIP-005-6 (CIP-005 was one of the three standards that wasn’t modified when “CIP version 6” was developed) and CIP-010-3 (this becomes v3 of the standard, since CIP-010 was modified under “CIP v6” and thus became CIP-010-2).
  5. A new standard, CIP-012, is being balloted now, and will most likely come into existence as version 1.
  6. The current CIP Modifications SDT is working on modifications to other standards, because of other tasks mandated in their SAR that haven’t reached the drafting stage yet. This includes the changes required to incorporate virtualization into CIP, which will likely require modifications to most of the CIP standards (and these will of course simply increment the existing version numbers, leading to even more diversity, although it would be nice if all the standards could be brought up to the same level, e.g. version 9 or whatever the “high water mark” is at the time they come into effect[iv]).
So how are you to keep track of what versions of the different CIP standards are currently in effect? Fortunately, NERC has put on their web site – and will be maintaining as changes are made, I’m sure – a spreadsheet showing current and recent versions of all the NERC standards (not just the CIP ones). It’s called the “US Standard One-Stop-Shop”. You might want to plan on downloading it regularly so you can be sure you’re always dealing with the most recent versions (it includes links to all the standards as well as their RSAWs, FERC Orders, Lessons Learned and Compliance Guidance); this is especially important if you deal with other NERC standards besides the CIP family.

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

  • CIP-002-5.1a
  • CIP-003-6
  • CIP-004-6
  • CIP-005-5
  • CIP-006-6
  • CIP-007-6
  • CIP-008-5
  • CIP-009-6
  • CIP-010-2
  • CIP-011-2
  • CIP-014-2
And as I already said, the diversity of these version numbers is only going to increase as we go forward.

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

The views and opinions expressed here are my own, and do not reflect those of any organization I work with. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

[i] Some had “-3a” or “-3b” after them, meaning that an approved Interpretation had been applied to them.

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

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

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

Sunday, November 12, 2017

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

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

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

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

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

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

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

The views and opinions expressed here are my own, and do not reflect those of any organization I work with. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

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

Friday, November 10, 2017

The Second Lesson from CIP-014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The views and opinions expressed here are my own, and do not reflect those of any organization I work with. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

[i] For a discussion of these two acronyms, see my previous post.

Tuesday, November 7, 2017

Some Heretical Thoughts

Note: This post originally started out to be part II of II on lessons learned so far from the CIP-014 experience – that post covered the first lesson, and this post was intended to cover the second lesson. I started this post with what I thought would just be a paragraph or two expanding on what I’d written in the first post – and you can see what happened. But have no fear, I have most of the post regarding the second lesson already written, and it will appear very shortly.

Two weeks ago, I wrote a post that was intended to be the first of two, on lessons that can be learned from NERC’s experience so far with CIP-014, the physical security standard that applies to certain key substations. Why am I worried about CIP-014, since I’ve written very little about it previously? Because CIP-014 is an objectives-based (non-prescriptive), risk-based standard like CIP-013, the upcoming supply chain security standard[i]; any lessons that can be learned from the CIP-014 experience so far are very relevant to CIP-013. And I also think the other CIP standards should be replaced by objectives-based, non-prescriptive ones, so these lessons will be relevant when that long-hoped-for (at least by me. I’m not sure if anyone else hopes for them, although I believe I’ll be able to persuade my dog in the near future) day arrives.

My main concern regarding objectives-based, risk-based standards is how they will be enforced by NERC. I realized earlier this year that simply rewriting the CIP standards isn’t enough. Because the whole NERC compliance regime, as embodied in the Compliance Monitoring and Enforcement Plan aka CMEP, is based on auditing very prescriptive standards, to properly enforce objectives-based, risk-based standards will require a huge adjustment in the mindset of the auditors, as well as everybody else involved in enforcement at NERC and the regions. And it will probably require a rewrite of CMEP, or perhaps a separate CMEP for the CIP standards, vs. the other NERC standards.[ii]

The lesson from CIP-014 that I wrote about two weeks ago was that there really needs to be some sort of review by NERC or the regions of the entity’s plan, before they implement it. In the case of CIP-014, this is the plan for improving physical security of a key high-voltage substation. In the case of CIP-013, it is the entity’s Supply Chain Cyber Security Risk Management Plan. In that post, I discussed how a large NERC entity would probably never implement a planned $80MM physical security system at their key substations, because the region refused to say whether this deployment would help (or hurt) their compliance position on CIP-014.

Of course, having NERC (or in this case, the Regional Entity) review the plan before it is implemented goes against everything in CMEP – plus, as an auditor pointed out to me after he read that post, it also goes against GAGAS, the government guidelines for auditors that all NERC auditors follow. According to those two documents, auditors need to maintain their independence, and can’t provide compliance advice in advance to the entities they will audit. And I totally agree with them that this is the case.

Yet this also poses a huge problem for objectives-based, risk-based standards. Think about it: In a world of prescriptive, non-risk-based requirements (as is basically true for CIP v5/v6, although there are a number of requirements that are objectives-based, or at least non-prescriptive. On the other hand, there are no requirements in CIP v5 or v6 that are risk-based), the auditors absolutely shouldn’t be providing compliance advice up front to the entities they audit.[iii]

But objectives-based, risk-based standards don’t lend themselves to the type of audits that prescriptive standards do; in fact, it’s hard to see how the word “audit”, in the normal sense of somebody with a clipboard going through and checking a Yes or a No box after each of a set of questions, of the form “Did the entity do X?” is at all applicable for these standards. In CIP-013 and CIP-014, the entity is simply required to develop and implement a plan of some sort. The only criteria by which they can be judged to have complied or not are the two questions: 1) Did they develop a good plan? and 2) Did they implement the plan well? How would it be possible for an auditor to answer either of those questions except by using a tremendous amount of judgment, no matter how informed that judgment is by a host of guidance emanating from NERC, the regions, and other parties (and right now, of course, there is very little official NERC guidance on CIP-013 and not enough on CIP-014)?

Strictly speaking, if NERC were going to seriously audit CIP-013 and CIP-014 according to CMEP and GAGAS, they would have to make the whole enforcement process a giant gamble. The entity would have to, completely on their own or at least relying on no guidance that comes directly from NERC or the regions, come up with their own ideas on how to develop and implement their plan, and then how to implement it. At the end of this whole process, they would be subject to a single audit, where the auditors would just check Yes or No for each of the two questions in the previous paragraph. The fate of the entity’s entire CIP-013 and CIP-014 compliance programs would rest entirely on whether the auditors checked Yes or No for these two questions. If you think you’re under pressure before your CIP audit now, just imagine what this would be like!

I point this out not because I think this scenario will come to pass, but because I’m sure it won’t. It simply makes no sense to do this. How does it make sense not to provide any guidance to entities as they develop and implement their plans? What possible good would be achieved by not doing this? Just think of the example from the first post in this series: the utility that probably won’t make a particular big physical security investment, since they don’t know whether it might help or possibly even hurt their chances of being determined compliant with CIP-014? And I recently met with a utility that said they were having a hard time getting management at all interested in starting to prepare for CIP-013 compliance (despite the benefits of doing so now) because there is very little real guidance from NERC or the regions about how to develop and implement a supply chain cyber security risk management plan (more on this in a subsequent post).

Face it, objectives-based (and probably risk-based) CIP standards are here to stay. Since CIP v5, all of the new CIP requirements and standards that have been developed (this includes CIP-010-2 R4, CIP-003-6 and CIP-003-7, CIP-014, and CIP-012) have been objectives-based. This is partly because FERC ordered both CIP-013 and CIP-014 to be objectives-based (although FERC’s term for it was different – something like “not one-size-fits-all”), but also because nobody on a NERC CIP standards drafting team nowadays has an appetite for developing prescriptive standards (as I found out when I attended what turned out to be a key SDT meeting in June of 2016). The problem of a mismatch between NERC CIP standards and the NERC auditing regime is only going to get worse as time goes on.

So how will this mismatch be resolved? In the longer run, it will be resolved both by rewriting the CIP standards and by hopefully developing a separate version of CMEP for the CIP standards (since the current CMEP is fine for the O&P standards). That will of course be a huge, wrenching change for NERC and the regions. You might thus dismiss this as a pipe dream, and I would agree with you if I thought NERC had another option; but in the long run I don’t think they do. There is pressure building among the public and in Congress for the government to take more steps to secure the electric grid from cyber attack (and I wrote about how this pressure might come about in this  post)[iv]. I believe that in the next few years NERC is going to be faced with the choice of either developing a sustainable set of mandatory cyber security standards, and a sustainable compliance framework to go with them, or the responsibility for cyber security of the Bulk Electric System will be taken away from NERC (and FERC) and invested in some other agency like the Department of Energy, the Department of Homeland Security, or even a proposed Department of Cyber Security.

But in the short run, it is clear to me that the problem of the current CMEP not allowing CIP-013 and CIP-014 to be properly enforced will lead to the result that….they won’t be “enforced” at all. Auditors will review both the entity’s plan and how the plan was implemented; then they will provide advice on how the entity could improve on what they did. But this advice won’t be in the form of a Potential Non-Compliance finding (which can lead to an actual Violation), but rather in the form of an Area of Concern finding. As you probably know, AoC’s are issued now whenever an auditor finds some security practice that they think is deficient, but which is not actually in violation of any CIP requirement. The entity is under moral pressure to correct the problem, but they can’t be found in violation if they don’t.

Am I complaining about the fact that CIP-013 and CIP-014 aren’t really “enforceable”? No, I think this is much preferable to the doomsday audit scenario I described above.  But I also think there have to be mandatory CIP requirements that are actually enforced; I discussed my reason for saying this in another recent post. In brief, NERC entities will simply not get the same budgets for cyber security spending if their managements begin to perceive that the standards are increasingly being enforced on a “voluntary” basis. There really should be substantial monetary penalties when an entity clearly develops an inferior plan for CIP-013 or CIP-014, and/or doesn’t implement it properly or at all. Until a new compliance regime is in place at NERC, this simply can’t happen.

I wish to close with one of my favorite quotes from Lewis Carroll (from Through the Looking Glass, the companion book to Alice in Wonderland). Humpty Dumpty has just used a word in a very non-normal way. Alice objects that he isn’t using the word in the proper way.

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'
'The question is,' said Alice, 'whether you can make words mean so many different things.'
'The question is,' said Humpty Dumpty, 'which is to be master — that's all.'

I would rephrase Humpty Dumpty’s response as “The question is, which is to be master – you or the words?” And so I ask you, which is to be master in the case I just described, CMEP and GAGAS, or the need to have an enforcement framework that is appropriate for objectives-based, risk-based standards like all of CIP should be and like CIP-013 and CIP-014 are now? I promise I’ll have a lot more to say on this in the future. You have been warned.

The views and opinions expressed here are my own, and do not reflect those of any organization I work with. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

[i] In general, I think CIP-013 handles risk better than CIP-014, but that may be because the subject matters of the two standards are so different: purchasing policies and procedures vs. physical security of certain high-voltage substations.

[ii] My general idea is that there is a very big difference between the CIP cyber security standards and the other NERC standards, which are usually called the Operations and Planning (O&P) or “693” standards. The latter are ultimately based on the laws of physics: If you do or don’t do X, Y will happen. This type of standard has to be prescriptive, and needs to be audited in a very prescriptive manner.

But cyber security practice is statistical. If you don’t patch one server for one day, it’s unlikely you’ll suffer adverse consequences. If you don’t patch any of your servers for one year, you will be much more likely to be successfully attacked, but even then it isn’t a certainty. However, there would undoubtedly still be some small security benefit to patching your servers every day. Does this mean that CIP-007 R2 (my poster child for a prescriptive, non-risk-based requirement) should be expanded so that NERC entities now will need to patch their servers daily? Most NERC entities – and auditors – would shudder at the mere thought of that, since it would require a massive effort and many more resources. Yet, in the prescriptive framework of NERC standards, with no allowance for risk at all, there really is no way to say what the stopping point should be – that is, on a risk-adjusted basis, the point at which any possible security benefits are outweighed by the cost. The only logical stopping point would be when there were so many prescriptive CIP standards in place that the risk of cyber attack was effectively zero. Even if that point could ever be reached – which it can’t, of course – if we got there, we would have long ago passed the point where electric utilities would have to suspend distribution of electric power and devote their entire staffs to NERC CIP compliance!

Thus, I think cyber security standards in general need to be objectives-based and risk-based. And to be honest, I don’t know of any other mandatory cyber security standards that are prescriptive and non-risk-based, like CIP-002 through CIP-011 (although there are certain individual CIP requirements like CIP-007 R3 that are actually objectives-based. However, until CIP-013 was developed, none of the CIP standards or requirements have been explicitly risk based, meaning that all systems in scope don’t need to be treated exactly the same way, but the controls applicable to them can be based on the risk they pose to the BES).

A few readers may remember that I started saying about a year and a half ago that I was working – with two co-authors – on a book about how the CIP standards can be rewritten to make them much more sustainable than they are now. I confess that we haven’t put many words on paper (or virtual paper) yet. This is mostly because my ideas were still evolving – for example, my realization mentioned above, that the enforcement program itself will need to be rethought, not just the standards themselves.

My ideas are now at a point where I think I have the whole argument in my head, at least in principle (and a lot of the argument can be found in different posts I’ve written. However, it’s in a few sentences or phrases here and there, not in any form where I can copy and paste them into the book); and I have started serious writing. This, coupled with the fact that I will have more free time for the next couple months or so, makes me hope that I will make some serious progress on the book in the near future, although I strongly doubt I’ll be able to finish it that quickly.

[iii] If you read any of my posts from say 2014 through the end of 2016, you may be surprised with this statement. Those posts coincide with the period when the industry (and I) was struggling to figure out what the wording of CIP v5 meant. I frequently suggested that NERC and the regions should go beyond what was strictly allowed by CMEP and the NERC Rules of Procedure and provide true interpretation guidance to entities, simply because there was so much in CIP v5 that was undefined, vague, or – in the case of CIP-002 R1 and Attachment 1 – completely contradictory. Ultimately, both NERC (through the Small Group Advisory Sessions) and the regions (through unofficial advice that is always provided verbally, never written down), ended up doing exactly that, not because I’d advised it but simply because it was the only thing they could do. They couldn’t continually tell the entities “You have to figure it out for yourselves. We can’t tell you anything”, and then expect the entities to meekly submit when they are assessed violations that are due to their misunderstanding what a requirement means (or at least what the region thinks it means).

So my statement that I agree that auditors shouldn’t be providing compliance advice to the entities they audit, in a compliance regime of prescriptive, non-risk-based requirements, only applies in the case where the requirements are very clear and unambiguous. This unfortunately is not the case with CIP v5, although I need to add that I don’t blame this on the drafting team. I blame it on the fact that cyber security is a discipline in which unambiguous prescriptive requirements simply cannot be drafted. A full discussion of why this is the case will probably have to wait for my book.

[iv] And I’m not taking any position on whether or not that pressure is warranted, just stating that it exists and it’s inevitably going to grow.

Friday, November 3, 2017

Moving On….

I was recently surprised to be caught in what appears to be an unannounced RIF at my former employer. While losing a job isn’t exactly number one on my list of favorite things to have happen to me, I accept it and am ready to move on.

I’ll be honest: If any of you know of particular job opportunities I ought to pursue, I’d appreciate your letting me know. Email me at And I’ll also be honest in saying that I’d like to know soon about those opportunities, since from early indications it looks like I won’t be on the market for too long. I’m not trying to be coy about this; I’m just stating the truth.

Of course, no matter where I end up, I intend to keep writing this blog. You won’t be rid of me that easily!


The views and opinions expressed here are my own, and do not reflect those of any organization I work with. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

Thursday, October 26, 2017

My CIP-013 Presentation at GridSecCon

As usual, NERC’s annual GridSecCon conference, which was held last week in beautiful St. Paul, Minnesota, was a great success. Every year I say this was the best one ever (I’ve only missed two since it began seven years ago), and this was no exception, both for the great programming and for the very competent organization. This year, attendance passed 500 for the first time. Congratulations to Bill Lawrence and the great team that organized the conference.

I had been asked to be part of a panel on supply chain security. Of course, this being a NERC conference (and the panel being led by Howard Gugel, who is in charge of standards development for NERC), most of the focus of the panel was CIP-013. I was certainly no exception to that rule! In starting my presentation (which I tried to hold to seven minutes – I think I succeeded), I admitted that I would be covering a lot of ground in a short time, and rather than forcing people to take a lot of notes I said I’d write up my presentation (and perhaps embellish it) in a post this week. So here it is!

I didn’t have the time or the inclination to do some sort of general disquisition on CIP-013: how it came about, what’s in it, etc. – I assumed the audience would have some idea of this. I also didn’t go into why I like the standard so much and why it’s so important that it is risk-based, since I’ve already discussed these topics. Rather, I just titled the presentation “Important Observations on CIP-013”, and I discussed ten observations that I thought would be of interest to the audience.  Here are the observations (in boldface), and my discussion of them (which definitely goes far beyond what I had time to say at GridSecCon).

CIP-013 is very simple. R1: You develop a plan. R2: You implement it. R3: You review it every 15 months. So the big question is: What should be in your plan? I believe all cyber security requirements should be objectives-based, and the requirements in CIP-013 are certainly that. So the whole question becomes, what is a good plan? Of course, this is where the real work comes in. Because there’s nothing in the requirements themselves – except for the six mandatory items listed in R1.2 – that tells you what needs to be in the plan, or even how to put the plan together in the first place. There’s the excellent – but far too short – Implementation Guidance developed by the drafting team, and I’m sure there will be a lot of other documents written that provide some form of guidance (including my posts, of course), but in the end your organization is going to have to decide for itself how you will put together your plan.

You need a supply chain cyber security risk management plan. It must address risks (threats) from a) procuring hardware and software; b) installing hardware and software; and c) transitions between vendors. Note there are three areas of risk that must be addressed in CIP-013, not just one; FERC specified that the standard needs to address all three. Just about everything I’ve read about the standard (including most of what I’ve written) focuses exclusively on the first area, vendor risk. But the other two areas are just as important, and they are focused much more on what the asset owner does, not the vendor. Since the requirement says all three areas must be addressed, you probably could receive a PNC if you simply omit either b) or c).

Even though R1.2 lists six particular items that need to be in your plan, you will make a big mistake if you confine your plan to those items. I wrote in a post recently that it’s very possible the only way you can get a Potential Non-Compliance finding from a CIP-013 auditor – other than simply blowing the whole standard off as unimportant – is if you omit one of these six items from your plan.

But this doesn’t mean the auditors won’t look at the rest of the plan at all. They will take a comprehensive look at your plan, and if they believe you’ve missed something, they’ll issue an Area of Concern. You would be well advised to address that AoC, even though strictly speaking you can’t be found in violation if you don’t. There are two reasons for this: 1) It’s The Right Thing to Do; and 2) You don’t want to get on the bad side of your auditor. Remember, even though your auditor’s baby is ugly, it’s not a wonderful idea to say that to him or her. The same goes for ignoring an AoC.

CIP-013 is risk-based: You should classify vendors and systems by risk, and apply controls based on the risk level. This is very different from the other CIP standards. The emphasis here is of course on risk management. If you define risk as threat times impact, you can see the difference between the CIP-013 requirements and most (although thankfully not all) of the existing requirements in CIP-002 through CIP-011, which I’ll call prescriptive requirements.

Like non-prescriptive requirements, prescriptive requirements are designed to address a particular threat (or set of threats). However, prescriptive requirements assume the impact of the threat is equal to 1 – the maximum. They also assume that the impact doesn’t vary according to the importance of the cyber asset(s) being protected. With the impact always being one, this means the risk corresponding to each threat is always the same. It also means that no BES Cyber System can be treated any differently from any other BCS in the facility, since each one is assumed to carry the same level of risk (and please don’t tell me that this is what the High/Medium/Low impact rating does in the other CIP standards. Even though CIP-002 R1 and Attachment 1 are written - although not consistently - to make you believe that the impact rating is an attribute of the BES Cyber System, in fact the rating is treated literally 100% of the time as an attribute of the asset itself. Once the asset is designated High, Medium or Low impact, every BES Cyber System within it is treated exactly the same as every other BCS within it, both by NERC entities and by auditors).

Unlike NIST and other cyber standards, “risk” in CIP-013 doesn’t mean risk to the organization. It means risk to the Bulk Electric System. But you also shouldn’t use the H/M/L classifications from CIP-002. You won’t be helping yourself if you do. Some organizations – including all owned by the federal government – are used to ranking risks posed by computer systems, for compliance with FISMA, NIST CSF, and other frameworks and standards. But the risk considered in these other frameworks is almost always risk to the organization itself.

NERC CIP – indeed, all the NERC standards – treats of risks to the Bulk Electric System; that is what NERC standards are designed to protect. So a payroll server for a utility could be hacked and they couldn’t pay their employees for months, causing many of them to quit. This would of course be a terrible thing for the organization, but as long as there isn’t any direct BES impact, it doesn’t mean anything to NERC CIP. This is why CIP only applies to OT systems, and not all of those, either.

And you shouldn’t classify your BCS using the impact level from CIP-002 R1. There’s a good reason for this. Since CIP-013 only applies to High or Medium BCS (although your plan can cover Lows as well. In fact, I can think of reasons why it would require very little additional work to include them in your plan now. I’ll have a post on this sooner or later), you will then have all high or medium risk BCS for CIP-013! So if your plan says you need to do X for high risk BCS, Y for medium risk, and Z for low risk, you will have to follow that and treat every Medium impact BCS from CIP-002 as a medium risk CIP-013 BCS. You won’t be able to put the set of controls Z on any BCS, since you’re not allowing for there to be any lows!

Of course, you don’t have to rank your BCS for CIP-013 purposes as high, medium and low risk. You can rank them as 1,2,3,4 or high/low risk, for example. It’s probably better if you adopt a different nomenclature for risk in CIP-013 than High/Medium/Low, to avoid the inevitable confusion with CIP-002 R1.

CIP-013 is also threat-based: You should make sure that your plan in principle addresses every threat, based on its level of impact (i.e. the risk). You should rate each threat according to its risk, then determine the appropriate level of controls – if any – based on the risk.

You might well ask, “How can I possibly address every threat to a BES Cyber System? There is literally an infinite number of them. There’s probably a small risk that a truck carrying a BCS to our facility will be overrun by a herd of elephants and the BCS will be crushed. How can I even identify all the threats, let alone mitigate them?” And this is where risk comes in; remember, risk is your friend in CIP-013 compliance! You need to consider all the threats (in each of the three risk areas discussed in the previous slide) and determine both the likelihood and impact of each threat; this yields the risk, of course.

Then you need to rank the threats by the risk that corresponds to each one (of course, you don’t have to rank them highest to lowest; you just need to group them in whatever number of risk levels you’ve decided is appropriate). This gives you your prioritized list of threats you need to address. And you can not only prioritize the threats, you can draw a line somewhere in the list and say “Below this line, the risk is so small that I don’t have to do anything more to mitigate it.” You then don’t have to even consider those small risks, although you have to document you are doing this consistently (not arbitrarily saying “Hey, I really don’t think this threat poses much of a risk. I won’t do anything about it). For example, I think it’s safe to say that no NERC auditor will every find you in violation of CIP-013 because you didn’t even consider the threat that a hurricane would pose in Nebraska!

And not only does the risk level help you prioritize the threats you face, it helps you determine the level of controls required. The riskiest BCS and vendors need to have the most stringent controls; the least risky should have the least stringent controls. Of course, this is very different from the other CIP standards!

The above has covered the six points in my first two slides. My final slide listed four points, and was titled “Some Lessons from Healthcare…” This was because I had been talking with a group of cyber security consultants at Deloitte who had been working for four years in the area of medical device security – working both with the vendors and with the hospitals (which are of course the equivalent of electric utilities in “our” space).

The medical device industry has been complying for four years with mandatory cyber security regulations from the Food and Drug Administration. These apply to the vendors, not to the hospitals. However, the hospitals are just as concerned about the vendors’ compliance as are the vendors themselves, so you could say that the hospitals are also subject to the regulations. Since this is a lot like the CIP-013 situation, it is informative to hear about this industry’s experience with mandatory cyber standards.

Utilities and vendors need to partner to secure purchased BCS. Dealing in a hands-off way doesn’t do much to advance security. One way to “cooperate” with a vendor is to throw some contract language over the wall to them and say “Here, Mr. Vendor. Put this language in your contract or else!” The vendor’s lawyers will then review the language, edit it to their taste and throw it back over the wall to you. Your lawyers will edit that document to their taste and throw it back…etc, etc. Of course, this is all great fun and ensures full employment for the lawyers. But it has nothing to do with making the BES more secure.

How about this approach: Your cyber and supply chain people sit down with the vendor’s cyber and sales people and say “How are we going to solve this problem – i.e. the product security and CIP-013 compliance problem – together? Let’s explore the different options….” You look at how the vendor could change their processes, how they could get you better information about their security and the security of their products, how they handle post-implementation support, etc. Sure, you can also discuss contract language and agree on language you both can live with. But that shouldn’t be the main focus of the discussion. It should be cyber security, and there are much better ways to achieve that besides contract language.

Of these two approaches, which do you think will actually increase cyber security? I’m going to go out on a limb and say number two. And by the way, I’m not saying you need to do this with every vendor. Remember the thing about risk? You will want to do this with the riskiest vendors – i.e. those who sell the systems whose loss would have the biggest impact on the BES; for other vendors, maybe contract language and a questionnaire would be enough. Or maybe just contract language, for the least-risky vendors. But if you’re dealing with your EMS vendor in the paper-over-the-wall manner I just described, I think you should seriously rethink how you’re treating supply chain security.

Legacy devices also need to be secured, even though CIP-013 is silent about this. Again, utilities and vendors need to work together to secure legacy devices. CIP-013 only covers BCS purchased after the standard comes into effect. But there are lots of legacy devices in the field, and it’s almost axiomatic that they don’t have as good a level of security as new systems. What should you do about those?

Fortunately, your discussions with vendors on how you’ll cooperate for CIP-013 compliance are the perfect opportunity to discuss legacy systems. What are ways that both of you can cooperate to improve security in those systems? Don’t wait for the next serious vulnerability to make the headlines.

Incident response is the biggest test of cooperation. There’s nothing like a good ol’ hair-on-fire cyber incident to test how well you and your vendor can work together. But guess what? It’s much better not to wait for an incident to find out how well you cooperate, or whether you can cooperate at all. When you have the meeting with your vendor to discuss CIP-013 compliance, bring this up as well.

Procurement needs to lead the conversation; vendors are much more likely to listen to the people who write the PO’s! I realize this may shock you, but vendors tend to pay the most attention to the people who actually issue the PO’s. If you (Mr/Ms cyber/CIP person) want your vendor to do something important, don’t just bring this up to them yourself. Get your procurement people to make the actual call.

The views and opinions expressed here are my own, and do not reflect those of any organization I work with. If you would like to comment on what you have read here, I would love to hear from you. Please email me at