A Great ICS Security Guidebook

Through one of the many newsletters I receive, I came across a great document from Emerson called “Cybersecurity Guidebook for Process Control”. It has a simple purpose, which certainly isn’t new: to summarize in one short document everything that an organization needs to do to secure the process control systems in an industrial plant[i].

What is new is how successfully Emerson has achieved that purpose. Every other document that I have seen that attempts to do this has been essentially a list of best practices, without an understanding of the overall goal to be achieved and how the individual practices help to achieve it. Emerson’s guidebook starts out by stating that cyber security is an organizational risk, and must be addressed using a risk-based approach. The rest of the guidebook follows very naturally from this statement. It is divided into five sections – each generally a security domain like remote access. In each section, Emerson describes something you should start doing, something you should stop doing, and something you should continue doing.

Of course, I’ll promise there’s nothing in here you haven’t heard already. But I highly recommend you not skim through the guidebook for that reason. I ended up reading it twice, and literally stopping to think about each sentence. Whoever wrote this (my guess is it was a team) put a lot of work into crafting each sentence, and there is a lot packed into each one. What they’re recommending is obviously based on a lot of experience. They have clearly put a lot of thought into what are the most effective (and the least effective) practices.

Enjoy!

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

---

[i] Even if you don’t have responsibility for securing a generating plant, I still recommend you read this. There is almost nothing in there that doesn’t apply to substations as well. If all you’re concerned about is control centers, this might be less relevant for you – but I still recommend you read it!

Dave Norton

For those of you who know Dave, don’t panic at the title of this post: He isn’t dead! But he did retire from FERC at the end of January. Because of his huge contributions to the industry and to the NERC CIP standards, and because he is a close personal friend, I want to pay tribute to him. First, I’ll give you a short summary of why Dave is so important:

1. Dave has been doing networked computing and security for 41 years. He was one of the first CISSP’s, in 1998 (for some perspective, the World Wide Web was less than ten years old then, and the Netscape IPO had only happened three years earlier. This IPO is generally seen as the wakeup call that the Internet was going to be something big – it certainly was for me. Netscape was valued at a whopping $3 billion in that IPO, which now might be the starting bid for a small startup company with mediocre prospects).
2. Dave was part of the energy sector for 17 years. 10 of those years were with Entergy Transmission in New Orleans, including going through the Katrina experience!
3. NERC got into the cyber security regulation business in 2003, when the Board of Trustees approved Urgent Action 1200. This was a voluntary standard (all NERC standards were voluntary until the Electric Power Act of 2005 set up the FERC/NERC relationship that we all know and love today), and just applied to control centers of Balancing Authorities. But it was a successful standard for what it did, since the BA’s knew the unique position their control centers played in the Bulk Electric System and felt compliance with the standard was very important. Dave was an active participant on the Standards Drafting Team for UA1200.
4. However, an Urgent Action standard is temporary, and everybody wanted a permanent standard. In 2004, NERC’s Board approved a Standards Authorization Request (SAR) for NERC Standard 1300. This would expand UA1200 to apply to other assets than just control centers – especially Transmission substations and generating stations. Of course, Dave was on the UA1300 team as well.
5. Before Standard 1300 could be put into place, Congress passed the Electric Power Act of 2005. This act allowed FERC to regulate reliability of the electric power industry, and to choose an Electric Reliability Organization to draft and enforce the standards. Of course, NERC – having been doing this since 1967 – was the only logical choice for the ERO.
6. The EP Act explicitly required that NERC develop cyber security standards. So Standard 1300 was re-drafted as eight standards in the CIP family. Dave not only continued onto the drafting team for CIP v1, but he wrote the SAR for it.
7. When FERC approved CIP v1 in January 2008, they issued Order 706. This 600+-page document stated that FERC was approving v1 because they wanted something in place, but they had far more ambitious plans for CIP and wanted substantial changes. They laid these out in great detail in the order.
8. Of course, NERC standards can’t be changed once they’ve been approved by the NERC Board, so even as CIP v1 was implemented, a drafting team was formed to draft a new version of the CIP standards that would incorporate FERC’s changes. Dave was – of course! - an active member on this drafting team, which was called the CSO706 SDT.
9. The CSO706 SDT first met in the fall of 2008 to draft CIP v2. However, they ended up drafting not only v2, but also v3 and v4. These were all “stepping stones” on the way to CIP v5, which was approved in late 2012 (if you’d like more information on all these versions and why they were developed, see this post).
10. Dave was with the CSO706 team through most of this, but he left Entergy to join FERC in 2011, which made him no longer eligible to remain on the SDT.

As you see, Dave has been at the forefront of NERC’s cyber security efforts since their beginning. He has contributed in many ways, but I’d like to illustrate the important role he played by reprinting a section from an “open letter” I wrote in October 2010. It was distributed by Honeywell, my employer at the time (I didn’t start my own blog until January 2013).

In this open letter, I described a meeting of the CSO 706 SDT that I’d just attended in Toronto. The meeting had been mainly concerned with CIP v4, which the team was in the process of balloting with NERC (it was approved by the NERC ballot body in December 2010). I marveled that, after a grueling day or two making revisions to v4 for the next ballot, the team still had time and inclination to have a freewheeling discussion of what CIP v5 should look like. Dave had earlier been chosen to lead a team to make suggestions, and he presented their ideas:

“At the Chicago SDT meeting in August, a subcommittee had been formed—led by the venerable Dave Norton of Entergy—to re-examine the foundations of CIP, and report on their findings at this meeting. Of course, they weren’t charged with making fundamental decisions—that is for the whole SDT. Rather, the subcommittee developed a very insightful “Review of Critical Issues” which outlined the fundamental considerations for the new CIP.

These “considerations” formed the basis for the SDT’s discussion of V5. While that discussion was wide-ranging, the full SDT remarkably coalesced on a framework for V5 that was a huge change from both CIP Versions 1-3 and from the version (CIP-010 and -011)[i] that was discussed in Dallas this spring. I will list below important points from that discussion, without (in most cases) identifying who made them.

The discussion started with a delineation of the fundamental problems with the current CIP standards. These include:

1. There is no room for any error in following the current CIP standards. Dave mentioned a large entity that had missed five of 30,000 access removals in one year, and had to self-report all of these as violations. Ironically, he pointed out that this entity was doing a very good job with CIP, but those five misses (i.e. 1/6000th of the total) will loom as large for them as five misses at a small entity that might only have 200 total access removals in a year (i.e., the misses are 1/40th of their total).

2. There is no good way to work for improvement. Dave said the stigma of self-reporting a violation has caused at least some people to be fired—so who is going to stick their neck out and admit they’ve missed something, even if doing so could lead to improving the process that led to the violation?

3. While VRFs and VSLs are in theory in place to mitigate the impact on the organization of a self-reported violation, these only come into play after the violation has been reported. And most organizations will do their best to avoid reporting any violations.

4. The current standards are “one-size-fits-all.” There is no allowance for degree of impact on the BES, or for differences between control centers, generation plants, and substations. Dave also pointed out that protecting “bastion” assets—such as control centers and generation plants—is quite different from protecting field assets such as substations.

5. There is no allowance—other than TFEs—for legacy equipment.

6. There is no specification of what the controls in CIP-003 through -009 are protecting against. Thus, many entities question why they should have to implement anything at all.

7. There is no way under the current standards to incorporate the entity’s actual vulnerabilities— e.g., the results of vulnerability assessments—into the controls that are applied.

8. While many (including FERC) have pointed to NIST 800-53 as the blueprint for a new CIP, there are many problems with that. As the CISO of a large government entity—which has had to follow 800-53— pointed out, there are far too many controls required. Many of these controls provide only marginal benefit, while there are a few that provide huge benefits (configuration management, awareness and training, and personnel risk assessments). Because 90% of security threats are from insiders, controls such as these—which protect from insider threats— are much more important to implement than many others.”

  

I hope you’ll notice that Dave’s suggestions helped plant seeds for a number of features of the current CIP landscape, which are undoubted improvements from the previous CIP versions. These include Find, Fix and Track (#1); the Reliability Assurance Initiative (#2); High, Medium and Low-impact assets (#4); the need to treat large Control Centers as High impact (#4); and the language like “per device capability” in some of the CIP requirements, that eliminates the need for filing TFE’s (#5).

There are also several items on Dave’s list that have yet to be addressed in the CIP standards; these will need to wait for when all the standards are non-prescriptive and risk-based, like CIP-013. So we’re not finished with Dave’s agenda yet!

PS: Before he rode off into the sunset, Dave listed for me a number of changes he would still like to see in the CIP standards. I am going to expand on those a little bit (unlike me, Dave won't use two words where one will do!) and put them up as a post within a week or two.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996. 

---

[i] Tom (2018). The first attempt at a new CIP version after v3 was called CIP-010 and -011. 010 consisted of the applicability section of the new standard, which was like CIP-002-5 (it included bright line criteria and the new concept of BES Cyber Systems). 011 consisted of all the other requirements. This new proposal was unveiled at an SDT meeting in Dallas, which had a large number of on-site attendees and over 600 remote ones. There was widespread opposition to the proposal, mainly because it was such a radical change from CIP v3. The drafting team shelved that idea, so these draft standards never even were voted on. The drafting team then started work on CIP v4, which replaced CIP-002-3 with a new version based on the bright line criteria (but still using the concept of Critical Cyber Assets) – however, CIP-003 through -009 remained exactly as they were in v3. When the SDT started considering v5 in early 2011, they decided to add two more standards, which became CIP-010-1 and CIP-011-1. Of course, these had nothing to do with the original drafts that got shot down in Dallas.

Clarification to my Post on FERC Order 843

My post on FERC Order 843 got a lot of attention (as do all the posts having to do with FERC orders and NOPR’s), but several people have pointed out some confusing language in the third paragraph (I’ve italicized what is confusing):

As I discussed last week, the fact that FERC approved CIP-003-7 today seems to assure that it will come into effect on January 1, 2020.[i] And it also means that the “requirements” for physical and electronic access controls for Lows, found in Sections 2 and 3 of Attachment 1, will never come into effect (although technically they won’t be retired until 1/1/20. But they’ll be the living dead, since they will expire and be replaced by their CIP-003-7 equivalents on that date). So, as I said next week, September 1 of this year is now just Saturday of Labor Day weekend, not the great D-Day when the “LERC/LEAP” requirement becomes enforceable. Enjoy your long weekend!

Do you see what’s missing in the italicized sentence? In the sentence itself, I say that Sections 2 and 3 of Attachment 1 will never come into effect! This is contradicted by the parenthetical expression, which says they will be replaced by the “equivalents” in CIP-003-7 (that is Sections 2 and 3 of Attachment 1 in CIP-003-7) on 1/1/20, the effective date of CIP-003-7. So which is it?

This confusion could have been eliminated if I had written this sentence as “And it also means that the “requirements” for physical and electronic access controls for Lows, found in Sections 2 and 3 of Attachment 1 of CIP-003-6, will never come into effect (although technically they won’t be retired until 1/1/20. But they’ll be the living dead, since they will expire and be replaced by their CIP-003-7 equivalents on that date).”

I apologize for this omission. I can assure you that we at Tom Alrich’s Blog value clarity and accuracy above all other goals. We have made a thorough assessment of our internal processes for review of new posts, and the people formerly in charge of that task are no longer with us!

PS: Mike Johnson put up a post yesterday that points out that Order 843 was published in the Federal Register yesterday. Since this happened before the end of April, this means that the compliance date for CIP-003-7 will be January 1, 2020 - there is no longer any uncertainty on that.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

Lew Folkerth on CIP Exceptional Circumstances, and Tom Reveals a Deep, Dark Secret

I have more than once thought of renaming this blog as “Lew Folkerth’s Blog (assisted by Tom Alrich)”. I’m considering this more seriously now, having just read Lew’s latest Lighthouse article in the RF newsletter, on CIP Exceptional Circumstances.

I think what I like so much about Lew’s articles is that he has really thought about whatever subject he is discussing, and makes observations I would never make in 100 years. Of course, he does more than think about these things, since his job at RF is in Entity Development. That is, he’s not an auditor (although he was one for many years), but rather his job is to help entities do what’s needed both for cyber security and compliance – and he understands cyber security practices as well as he understands CIP, which is saying a lot.

And now I have revealed some information that I withheld when I wrote this post in January: the Region that currently has an Entity Development department is RF, and the guiding force behind the CIP part of that department is Lew! And I’ll repeat what I said then: All NERC Regions should implement an Entity Development department (which is a group that works with entities to help them understand the standards and comply with them, although in Lew’s case he works with entities as much on cyber security as on compliance).

If you don’t believe that RF actually does this for their entities (since some might interpret this as being a violation of Auditor Independence – excuse me while I genuflect), you should reflect on the second-to-last sentence of Lew’s article (which appears in all of his articles): “If you are an entity registered within RF and believe you need assistance in sorting your way through this or any compliance related issue, remember RF has the Assist Visit program.” Does your Region do this? Maybe you should threaten to move your utility to Cleveland or Pittsburgh if they refuse to consider doing it.

And – since I’ve never been one to leave well enough alone – I want to add that, if your region doesn’t do Entity Development (and it’s not inconceivable that the auditors could do it themselves, if they don’t want to set up a separate department), you should definitely ask them to start thinking about it. I believe that, with CIP-013, you (meaning a NERC entity) will definitely be at a disadvantage if your Region won’t review your Supply Chain Cyber Security Risk Management Plan before you implement it, as discussed at length (the only way I know how to discuss anything!) in the post referenced above. And for evidence of what can happen if you can’t have that review, see the sorry tale of CIP-014 audits, discussed in this post and this one.[i]

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

---

[i] I have recently heard that the situation regarding CIP-014 audits in the Region involved in both these posts hasn’t changed, and that the entities are putting their hopes in the standard being revised. I don’t want to be seen as throwing cold water on those hopes, but I’ll point out that I haven’t even heard any talk of a new SAR being developed for doing that, let alone a drafting team being in place to consider the idea.

FERC Order 843

Today, FERC issued Order 843, approving CIP-003-7. The order has several notable features, which I’ll address one-by-one.

The most important feature is NERC’s revisions to the requirement for electronic access controls at Low impact assets (and with that, retirement of the terms LERC and LEAP. Gents, we hardly knew ye! There was endless debate about both of your meanings, and now you’ve met your untimely end without ever having come into effect. Requiescat in pacem). FERC approved this “requirement” without ordering any further changes (as expected), and they also approved the Implementation Plan (which is also as expected).

As I discussed last week, the fact that FERC approved CIP-003-7 today seems to assure that it will come into effect on January 1, 2020.[i] And it also means that the “requirements” for physical and electronic access controls for Lows, found in Sections 2 and 3 of Attachment 1, will never come into effect (although technically they won’t be retired until 1/1/20. But they’ll be the living dead, since they will expire and be replaced by their CIP-003-7 equivalents on that date). So, as I said next week, September 1 of this year is now just Saturday of Labor Day weekend, not the great D-Day when the “LERC/LEAP” requirement becomes enforceable. Enjoy your long weekend!

The second important feature of the Order – and one that is controversial, although not unexpected since it was foreshadowed in FERC’s NOPR last October - is the new requirement for Transient Cyber Assets used at Low impact assets. As I said[ii] at the time, FERC had a problem with the language in Section 5.2, which deals with Transient Cyber Assets owned by third parties (usually vendors coming into the substation or generating station to maintain or modify code on their devices).

FERC’s objection is that, while Section 5.2 provides a number of examples of steps the entity could take to “mitigate the threat of malicious code” on third-party-managed devices, they all start with the word “Review of”, followed by possible mitigations the third party might have implemented. What 5.2 doesn’t say is what the entity should do if the review turns up the finding that whatever steps the third party is taking are inadequate; in theory, the NERC entity could just decide to let the third party use their TCAs (usually laptops) at the asset, and not be held in violation.

NERC assured FERC that the entity would still be found in violation, since Section 5 itself says the entity has to implement a plan “to achieve the objective of mitigating the risk of the introduction of malicious code..” This argument certainly would hold for Section 5.1 (for TCAs managed by the Responsible Entity), since all of the options listed there are clearly mitigation options. But FERC obviously doesn’t believe the argument holds for Section 5.2, since it just requires review of the third-party’s mitigation measures. It doesn’t require the entity itself to take any specific measures if that review reveals issues.

In practice, I think it’s safe to say the NERC Regions would issue a violation if they found an entity had allowed an infection to enter a substation from a third-party TCA, even though their review of the third party had already found they had deficient practices. But I agree with FERC that this really should be in the requirement itself, not just be an implied requirement (there are way too many of those already in CIP!).

Of course, Section 5 of CIP-003-7 will still come into effect as written when the standard does. But the CIP Modifications drafting team will soon need to start drafting language to address FERC’s concern, followed by balloting and approval by NERC and FERC. Of course, this revised standard will be CIP-003-8. The first v8 CIP standard!           

The last important feature of the Order has to do with FERC’s statement in the NOPR that they were considering ordering further electronic access controls on Low impact BES Cyber Systems, such as passwords. To the uninitiated in the ways of CIP, it might seem that ordering passwords in – let me check my calendar. Yes, it’s 2018! - is hardly a radical move. And I’m sure there are very few Cyber Assets anywhere in the Bulk Electric System that don’t have passwords. But to enforce this requirement would mean that NERC entities with Low assets would have to maintain an inventory of all Cyber Assets and BES Cyber Systems at Low assets. CIP version 5 would never have been approved by the NERC ballot body in 2012 if it hadn’t contained the provision in CIP-002-5.1 (stated twice there) that an inventory of Low BCS isn’t required.

However, this sacred principle has been maintained, since FERC decided not to order that NERC develop a new requirement(s) for further electronic access controls for Low BCS. Instead, FERC has ordered that NERC conduct a study of whether further electronic access controls at Lows might be needed, following the implementation of CIP-003-7. They want NERC to turn this study in to them 18 months after the effective date of the standard, or a little more than three years from now. You might want to mark that date on your 2021 calendar.

There are a few other features in the Order, but I’ll let you read those for yourselves. For heaven’s sake, I can’t do everything for you!

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

---

[i] Since technically the Order isn’t effective until 60 days after it is published in the Federal Registry, this could be pushed back to April 1, 2020 if the Order isn’t published by the end of April. I don’t think that’s likely, though.

[ii] Paragraphs 4 and 5 of the linked post discuss this issue and FERC’s reasoning.

Interesting Comments on CIP-013

Mike Johnson put out a very good post last week summarizing the comments that FERC received regarding CIP-013, in response to their January NOPR indicating they intend to approve the standard. I won’t summarize the post, but I found it most interesting to note that the comments fell into two distinct groups, depending on whether the commenter was from a NERC entity or some other organization.

In both groups, the comments were almost always uniform. For the NERC entity group, the responses almost all said[i]:

1. That FERC’s proposal to shorten the implementation period for CIP-013 from 18 to 12 months is a bad idea, since there’s a huge amount of work that needs to be done to prepare for compliance, especially for the larger utilities. I’m in complete agreement with this sentiment. Part of the reason why I says this is that – just as was the case with CIP v5 – there is significant uncertainty about what the requirements mean. Until this is cleared up in some way, NERC entities will have a very hard time putting their compliance programs in place.
2. That requiring NERC entities to apply CIP-013 to Electronic Access Control and Monitoring Systems (EACMS), as well as BES Cyber Systems, is another bad idea; FERC also asked for comments on this in the NOPR. I agree that this shouldn’t be done in the first compliance version (i.e. FERC shouldn’t order a crash “compliance filing” to make this one change, before CIP-013 takes effect at all). I do think this could be considered for the next version, which of course would take effect 2-3 years from now (but see below).
3. That before ordering that any other new systems be brought into scope (FERC suggested that Low impact BCS should be included in CIP-013, as well as Physical Access Control Systems and Protected Cyber Assets), FERC should wait for NERC to complete the study ordered by the Board of Trustees (due out this summer, I believe). I support that idea as well.

However, there was one set of NERC entity comments that stood out from all of the others: those were the comments submitted by the US Bureau of Reclamation. I don’t agree with most of what they said, but I thought their comments were quite interesting.

First, BoR says that CIP-013 should apply to all systems in scope for the current CIP standards (BCS, PCAs, PACS, EACMS, and Low impact BCS). To make up for this increase in scope, there should be a 24-month implementation period. This might sound like a fair trade-off (a scope extension for more time to implement it), except for the fact that I think NERC entities are going to want to have a say on this big extension of the scope. They can quite reasonably argue that they voted for a standard that applied to just Medium and High impact BES Cyber Systems – and they voted down the first draft in part because it applied to Lows. It is unfair to add Lows back to the scope without considering changes to the requirements themselves (the first draft had different requirements for Low BCS than for Mediums and Highs).

I think FERC would be understanding of this argument. But I really don’t see them just sending CIP-013-1 back to NERC (i.e. remanding it), then ordering NERC to draft and ballot new requirements as well as the scope increase and a 24-month implementation plan. That would effectively put off implementation of CIP-013 for another three years. FERC clearly wants to have a supply chain standard in effect as soon as possible. While they may order that NERC expand the scope, but that would come in a new version to be drafted and balloted, not in an order for a quick and limited compliance filing.

BoR’s second recommendation is even more interesting, in that they rewrote CIP-013 R1. They suggest that R1 be rewritten to read:

Each Responsible Entity shall identify, assess, and mitigate cyber security risks resulting from (i) procuring vendor equipment and software; (ii) installing vendor equipment and software; and (iii) transitioning from one vendor to another by:

1.1. Receiving vendor notification of vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity;

1.2. Coordinating responses to vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity;

1.3. Receiving vendor notification when remote or onsite access should no longer be granted to vendor representatives;

1.4. Receiving vendor disclosure of known vulnerabilities related to the products or services provided to the Responsible Entity and steps to mitigate them;

1.5. Receiving vendor verification of the integrity and authenticity of all software and patches provided for use in the entity's BCS; and

1.6. Coordinating controls for (i) vendor-initiated Interactive Remote Access and (ii) system-to-system remote access with vendor(s).

                                                                                            

Before I discuss this, I want to point out that BoR caught the obvious mistake in R1.1 that I also discovered as I was writing this post: that the drafting team left out the word “mitigate” in R1.1. This should be fixed in the next version of CIP-013, although everything else NERC has written and said about CIP-013 (and that FERC said in Order 829) points clearly to mitigation being the primary purpose of the standard; I think that will be enough to make CIP-013-1 enforceable with that implicit addition.

Let’s look at the first part of BoR’s R1 and compare it to CIP-013-1 R1. Note that BoR has taken out the entire “preamble” to the requirement – saying the entity needs to develop “one or more…plans…” I definitely don’t agree with this change. In my opinion, one of the chief virtues of CIP-013-1 R1 is that it is a plan-based requirement; I wish all the CIP requirements were also plan-based (although CIP-013 has other serious flaws, of course).

Now let’s look at R1.1 in the standard. It reads “One or more process(es) used in planning for the procurement of BES Cyber Systems to identify and assess cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s).”

BoR has taken out the language requiring “One or more process(es) used in planning for the procurement of BES Cyber Systems…”, but essentially left the rest. I pointed out in this post that combining this language (what BoR took out) with the preceding language from the preamble to R1 leaves this redundant sentence: “The plan shall include one or more processes used in planning for the procurement…” So I would heartily endorse the idea of removing this language, as long as the preamble were left in place – but of course BoR didn’t do that.

Let’s move on. BoR essentially left the rest of R1.1 in place, namely “Each Responsible Entity shall identify, assess, and mitigate cyber security risks resulting from (i) procuring vendor equipment and software; (ii) installing vendor equipment and software; and (iii) transitioning from one vendor to another”. This is of course a good thing, since I don’t want to see R1.1 ignored. But then BoR  

added the word “by” , followed by the six items they number 1.1-1.6, which are of course just rewordings of R1.2.1-R1.2.6 in CIP-013-1 itself.

In this recent post, I pointed out that almost everything I’ve heard from NERC or the Regions about CIP-013 R1 seems to imply that R1.2 is the only part of R1 that matters; in other words, it seemed to me when I wrote that post that NERC might be intending to ignore R1.1 altogether, since auditing it will be problematic (although as I pointed out a few days later, that concern may be overblown). So am I happy that BoR left the important part of R1.1 in place?

No I’m not. Because look what they did by adding “by”, followed by the six items from R1.2 in the original standard. They are in effect saying “You need to identify, assess and mitigate supply chain risks, and you do this by doing the six things below.” In other words, as long as you’ve done the six things, you’ve also done all of your risk identification and mitigation. Of course, this doesn’t make sense, since all you’ve done is implement the six things, not identify or mitigate any other risks. In other words, there is no point in having the initial paragraph in BoR’s R1. It could just list the six things in 1.1-1.6 and there would be no change in meaning.

So in rewriting R1 as they did above, BoR seems to be firmly on the side of those who think that R1.2 is the whole of the requirement, and R1.1 can be ignored. Of course, this may ultimately be how CIP-013 R1 is interpreted, by both NERC and the auditors. We’ll need to wait and see about that. In any case, I found BoR’s comments on CIP-013 to be very interesting, and I commend them for making them. 

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

---

[i] I read the NERC entity comments myself, and I agree that it was amazing how uniform they were, with one exception discussed below.

CIP-003-7 Update

I recently wrote a post pointing out that when FERC approves CIP-003-7, the current CIP-003-6 (with its LERC and LEAP language describing electronic access controls) will be sent to sleep with the fishes. In its place, the compliance date for the Low impact physical and electronic access controls requirement parts in CIP-003-7 (i.e. Sections 2 and 3 of Attachment 1) will be a little more than 18 months after FERC approval (per the implementation plan). But I also pointed out that entities can’t slack off their efforts for access controls at Low assets, because of the small possibility that FERC wouldn’t approve CIP-003-7.

It was just pointed out to me today that the agenda for FERC’s monthly Sunshine Meeting next Thursday includes CIP-003-7. Of course, this doesn’t mean they’ll definitely approve CIP-003-7, but I’d say the likelihood they would remand it – after issuing a Notice of Proposed Rulemaking in October saying they would approve the new version – is very small.

So what will be the CIP-003-7 implementation date, assuming FERC approves the standard next Thursday? It will be the first day of the first calendar quarter that is 18 months after FERC approval. That would be January 1, 2020. And September 1, 2018 will now be just another Saturday of Labor Day weekend.

On the other hand, I wouldn’t recommend you now stop working on the Low impact access controls even if FERC does what I think they’ll do next Thursday. If you get these controls implemented in 2019, you’ll be able to have a relaxing New Year’s Day 2020, assuming you’re not too hung over.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

CIP-013 R1.1 – Not dead yet!

I’ve had a few interesting discussions with people involved with CIP in various ways, regarding my recent post on CIP-013. And I’ve heard information that leads me to believe that the question I asked in that post – Is R1.2 the only part of CIP-013 R1 that NERC will enforce, or will they also enforce R1.1? – has been answered.

However, since I’ll admit that post wasn’t the most readable I’ve ever written, I’m going to summarize what I said first:

1. CIP-013 R1 requires the entity to develop a Supply Chain Cyber Security Risk Management Plan. There are two parts to this requirement. R1.1 requires the entity to “identify and assess cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s).” Notice that this requirement doesn’t provide any guidance on the risks that need to be addressed. It is up to the entity to identify those.
2. R1.2, on the other hand, lists six specific risks that must be addressed in the plan[i]. These weren’t just pulled out of the air by the drafting team, but were specifically ordered by FERC in Order 829.
3. I have been surprised that almost everything I’ve heard from NERC or the Regions about CIP-013 compliance (including in the NERC Implementation Guidance) has been about R1.2, to the point where one auditor told me that his Region would just be focusing on R1.2.
4. However, this isn’t a big surprise, because R1.2 gives auditors something concrete to audit – that is, whether the entity’s plan has credibly addressed all six risks – while R1.1 doesn’t provide anything like that. The entity is on their own to determine what risks they want to include in their plan. This makes it almost impossible to audit this requirement, except simply to give an up or down on whether the entity has made a credible effort to consider other risks. But if the entity documents that they did consider all risks, and they decided the only ones that mattered were – say - the six specified in R1.2 (which they already have to address), there’s no way they could be cited for non-compliance.
5. I contrast this with CIP-010 R4, which also requires a plan – to mitigate risks arising from use of Transient Cyber Assets and Removable Media with BES Cyber Systems. CIP-010-2 Attachment 1 – which is called out by the requirement, so it is part of it – lists a number of risks that must be addressed (and mitigated) in the plan. Here, the auditor can simply go down the list and make sure all of these are in the plan, and that the mitigations proposed for each one are credible.
6. So it seemed to me that the reason NERC was downplaying R1.1 was that they didn’t think it was auditable.   
7. I’m sure someone will say “Why don’t these people just do the right thing and follow what the requirement says? They just need to identify all their significant supply chain risks and mitigate them. After all, some of the biggest cyber incidents (the $2.7MM CIP fine in WECC, the Target breach, NotPetya, and others) have come through the supply chain.”  
8. The answer to this question is clear: One of the most important considerations with NERC CIP is reducing your compliance footprint as much as possible. For each new risk that an entity identifies in R1.1, they will have to develop and execute a plan to mitigate it. What if they fail to mitigate that risk for some reason? They might well end up paying a fine for this. What is the poor CIP manager going to say when his or her boss asks “Why did you even bother to put this risk – or any risk at all – in your plan, in response to R1.1? If you had just said there were no risks to address, or if you’d just played it safe and listed the six risks you already have to address in R1.2, there wouldn’t have been any possibility of getting this fine.”?
9. The bottom line of the post was a suggestion to NERC that, if it were really the case that they weren’t planning on auditing R1.1, they should say it. Otherwise, CIP compliance professionals were going to spend a lot of sleepless nights worrying whether they should really be doing something about R1.1 or not.

However, one person who wrote in to me about this post, and who has in the past been a reliable source regarding what is going on in NERC-land, assured me that NERC does intend to enforce R1.1. Of course, the requirement part itself can’t now be rewritten to include a list of risks to be addressed. But it seems that other organizations – like the trade organizations - might develop such lists, and NERC would then likely approve these as “ERO-endorsed guidance”. That way, our hapless CIP manager – who after all just wants to do the right thing – would have cover when he’s asked why he identified so many risks in R1.1; he can just say it’s what the trade organization recommended, and NERC is expecting entities to follow this guidance.

However, will R1.1 be auditable because of this development? It will definitely be auditable in the sense that, if the entity either blows off R1.1 completely or just makes what’s clearly a token effort, their auditor will be justified in giving them a PNC. However, if the entity just addresses – say – half the items on the list their trade association gives them, I see no way they can be found in violation for that – although they will likely be hit with an Area of Concern. On the other hand, my guess is at least 90% of NERC entities subject to CIP-013 will in fact address all of the risks on the list that they’re following. As I said, supply chain security is a big concern, and I’ve never yet met a CIP compliance person who didn’t want to do The Right Thing – as long as they have cover for managers who question why they’re going beyond what the requirement strictly says.

If NERC wants to make R1.1 fully auditable, they can draft a SAR for a new R1.1 that requires the entity to address a particular set of risks, just like CIP-010 R4 does now[ii]. And if there’s a concern that the risks to be addressed should be dynamic, I have a better idea: Why not task a particular industry body (perhaps the NERC CIPC or the NATF) to draft an initial set of risks to be addressed in the R1.1 plan, then update this list every six months or so? And while they’re at it, they could develop and update non-mandatory guidance for complying with those risks.

Of course, the reason for having regular updates of the list of risks is that things change fairly rapidly in the cyber security field (you might have noticed this!), so a static list of risks isn’t sufficient. And strategies for mitigating those risks also change rapidly. There really does need to be an industry body that updates both the list of risks and the mitigation guidance on a regular basis.

By the way, having such a body will also address a need I pointed out in this post on CIP-013 R3. According to the CIP-013 Implementation Guidance, “In the Requirement R3 review, responsible entities should consider new risks and available mitigation measures, which could come from a variety of sources that include NERC, DHS, and other sources.” I pointed out in the post that it doesn’t make sense for every NERC entity with High and Medium impact BCS to have to figure out for themselves every year what are the important new supply chain threats and what the most up-to-date mitigation measures are. It would be much better if a central body could do this, meeting on a regular basis.

I’ll go further than this. I think this same body (or perhaps a different one, although I don’t know why that would have to be the case) should develop and update a list of all cyber risks to the BES, not just supply chain risks. That way, NERC entities (and power market participants in general) would be able to allocate their cyber security resources to address the most important current risks, and they would have up-to-date guidance on how to mitigate those risks.

Along with this, I would also like to see the current CIP standards themselves replaced with essentially a single requirement: “Address all of the threats on the current list[iii].” My proposed industry group would meet probably quarterly to update the list of threats[iv] and identify new mitigations.

I’m not saying any of this will be easy to implement. Obviously, the CIP standards would need to be rewritten, and there would need to be changes to the NERC Rules of Procedure[v]. But my feeling is that, if this isn’t done, in a few years someone in Congress will ask “Hey, why don’t the power industry cyber security regulations even address phishing or ransomware?” As I discussed in this post (at the end), if someone from NERC then tells them “Well, we have this complicated standards development process that makes it very hard to address new threats, and even then it takes years”, this Congress person (or Senator) is likely to start asking why DHS or DoE (or even a new Department of Cyber Security) doesn’t take over from NERC. Why indeed? After all, it’s the country’s power grid, not NERC’s.

I will be continuing to beat on this drum on my RSA panel next week, in a series of blog posts after the panel, and hopefully in a book coming out this year (although I am painfully aware that this is the third year in a row that I’ve promised a book by the end of the year!). You have been warned.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

---

[i] R1.2 doesn’t actually talk about specific risks, but rather specific risk mitigation steps that must be taken. However, it is easy to go back from the mitigation steps to the actual risks. For example, R1.2.4 “Disclosure by vendors of known vulnerabilities related to the products or services provided to the Responsible Entity” maps to the risk of unknown software vulnerabilities in vendor products or services.

[ii] FERC’s January NOPR saying they would approve CIP-013 made it clear that they won’t simply approve the standard, but they’ll order further changes in it, such as including EACMS and probably BES Cyber Systems at Low impact assets. These will of course have to be included in a new version (v2) of the standard, so NERC could add the changes to R1.1 onto the SAR for the team drafting the new version. I suggest they also include a mandate to add the word “mitigate” to R1.1, since, as I pointed out in this post, the word seems to have been omitted when CIP-013 was drafted. The whole standard makes no sense if the entity is just required to identify and assess risks, but not to mitigate them!

[iii] In case you’re worried that this requirement would require an exponential increase in your current budget, consider the fact that not all risks would need to be mitigated to the same degree, or even at all. But you would decide which risks were the most important to address, rather than the CIP standards themselves, which are currently based essentially on the set of risks found in 2008, when the team that ultimately drafted CIP v5 first met.

[iv] I’m deliberately using the word threat here, not risk. I define risk as threat X probability X impact. Probability and impact will vary greatly by the entity, while the threats are the same for all. What the entity needs to do about each threat will be determined by its probability and impact for the entity, i.e. the risk posed by that threat. If the threat is a very low-risk one for that entity, they wouldn’t need to devote many (or even any) resources to mitigating it. I would like to see “risk” replaced by “threat” throughout CIP-013, but since it’s there now I’m not suggesting we mess with it. Since none of the other CIP standards consider risks at all, it is a big step to have CIP-013 do that.

[v] I think what would be needed is a separate RoP (or at least CMEP) for cyber security standards. I think the existing RoP probably works pretty well for the 693 standards, although I don’t have enough experience in the latter to say that for sure.

I Have One Free Pass to my RSA Presentation

This being my first year presenting at RSA, I didn’t realize I get two free passes to the events I’m involved with next week. If you will be attending with an Exhibits Only pass, these will get you into my event specifically – but not the whole conference, unfortunately. So if you would like to attend the panel discussion I’ll be part of next Thursday morning (April 19) from 9:15-10AM, please email me ASAP at the address below. Of course, please don’t ask for it and then not show up!


In an unrelated area, Mike Johnson has a good post up giving you URL's to comment and vote on two CIP changes that will soon be balloted: Modified CIP-002 and Control Center definition (aka the TOCC issue) and CIP-012 (protecting communications between Control Centers).

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

Will the Real CIP-013 Please Stand Up?

I’ve come to realize that there are now two distinct schools of thought on what CIP-013 is. Since, as some other person from Illinois once said, a house divided cannot stand, I feel this issue needs to be resolved soon. One way to resolve it would be the American Way – that is, with guns. However, I don’t think that’s really the best way to deal with this problem, although - as you’ll see soon - I’m not sure there’s any better way available.

It’s quite easy to differentiate these two schools of thought. One school believes that CIP-013 R1.1 is what the standard is all about, with R1.2 taking a minor role; the other believes that R1.2 is the full story. And who are in these two camps? In the R1.1 camp there’s…well, there’s me and…FERC Order 829, although the four FERC Commissioners who approved that Order are all gone (the lone dissenter, Cheryl LaFleur, is still on the Commission. Her dissent had nothing to do with this question, though). So it’s just me and a two-year-old piece of paper. I would almost certainly have the support of my cats, but they died years ago.

In the R1.2 camp, there’s just about everybody (or so it seems) at NERC and the Regions. And given this, it’s certain that close to 100% of NERC entities will also be in this camp, since any NERC compliance professional who took a position in direct opposition to NERC and their region would (and should) be fired immediately. Given these two lineups, why am I even raising this issue? Why aren’t I simply conceding that the R1.2 camp has won the day?

I could at this point make a noble statement about being willing to defend my position to the death, and start comparing myself to Joan of Arc. But that’s not really it. Whatever I think is the correct interpretation of CIP-013, I’m not willing to burn at the stake to defend it. But I think most people involved with NERC CIP – including many if not most at NERC as well as the Regions – don’t understand that there really is a choice in interpretations here. I would like to lay out the fact that there is a choice, so that at least these people can make a conscious decision on what constitutes the better interpretation of CIP-013. And I will be quite happy to live with whatever NERC says on this matter.

So what is the choice? Let’s start with the first camp (me). CIP-013 R1.1 (including the opening paragraph of R1) reads

Each Responsible Entity shall develop one or more documented supply chain cyber security risk management plan(s) for high and medium impact BES Cyber Systems. The plan(s) shall include: 

1.1. One or more process(es) used in planning for the procurement of BES Cyber Systems to identify and assess cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s).

I have analyzed this part of R1 in mind-numbing detail in this post, so I won’t repeat all of that. As I mentioned early in that post, the opening paragraph of CIP-013 says that the entity needs to develop a “supply chain cyber security risk management plan”, period. It doesn’t say you’re supposed to do one thing or the other, and within 35 or 60 days. It just says you have to have this plan.

The rest of R1 – that is, R1.1 and R1.2 – is presumably there to tell you what should be in the plan. And, to get back to my idea of there being two schools of thought regarding CIP-013, the R1.1 school believes that this part defines what the standard itself means – although this school (meaning Tom Alrich and his dead cats) readily admits that the six things in R1.2 must also be in the plan. So what does R1.1 tell us about CIP-013? You can read the whole story in the post I just referenced, but here’s a quick summary:

R1.1 lists three “risk areas” in supply chain security, each of which must be addressed in the plan. The first is (with a slight rewording of the requirement) “cyber security risks to the Bulk Electric System from vendor products or services resulting from procuring vendor equipment and software.” The second is “cyber security risks to the Bulk Electric System from vendor products or services resulting from installing vendor equipment and software.” The third is “cyber security risks to the Bulk Electric System from vendor products or services resulting from transitions from one vendor(s) to another vendor(s).” This means your plan needs to identify risks in all three of these areas, and say how you intend to mitigate[i] them. Also note that the risks to be addressed are from “vendor products or services” (my emphasis). They’re not just risks from stuff that you bought, but also from services that you bought.

So what do you need to do to comply with CIP-013, assuming that R1.1 is the right way to understand the standard? You “just” need to a) identify all of the important risks from each of the three areas; and b) mitigate those risks. Of course, I put ‘just’ in quotation marks because identifying all of the risks seems like a daunting task. How can one entity possibly identify all the risks in each of the three areas?

The answer is it can’t. However, this wouldn’t pose a big problem if CIP-013 were going to be audited in a “non-prescriptive” way – that is, if the auditors were simply going to ascertain whether you made a good effort to identify all risks, and then confirm that your plan discussed how you might effectively mitigate all of those risks[ii], based on the degree of risk they pose.

But, as we all well know, NERC auditing doesn’t work this way. Ideally, the NERC auditor will have a checklist of what is required; they will then go down this list to confirm whether or not you have done each of these things.  Obviously, R1.1 can’t be audited this way. This is why last December I wrote a post saying that CIP-013 wasn’t auditable, except for R1.2. What I was thinking was that this might be a wake-up call, so that NERC might think about how CIP-013 could be audited, while still preserving the principle that it requires a plan for managing supply chain risks – as R1.1 says.

But if R1.1 can’t be audited, the result is inevitable: NERC, the Regions and the entities will all ignore it. Instead, they’ll focus simply on the six things that are required in R1.2. These can be audited. So this brings us to the second school of thought: R1.2 is all that matters in CIP-013. The six things that are required in that part are all the entity needs to worry about as they implement compliance with CIP-013, and they’re all the auditors will look at. Very few entities are going to go to the trouble of trying to identify a full set of risks in R1.1 if they aren’t going to be audited on how well they’ve identified them. Because – as all CIP compliance professionals know by now – if you say in your plan that you’re going to mitigate a particular set of risks, then you’re likely to receive violations if you don’t do that. It’s better not to list any risks at all in R1.1.

For evidence of this belief (that NERC intends to ignore R1.1 and focus almost entirely on R1.2), I point to three sources:

1. The Implementation Guidance for CIP-013 focuses almost the entire discussion of R1 on the six things required by R1.2. Yes, there is a discussion of how the entity can put together a team to brainstorm about supply chain risks, and there is a fairly random collection of bullet points of things that the team might consider. But there is no guidance on what types of risks to look for, how to determine whether they’re real risks, etc. Most importantly, there isn’t a list of risks that need to be addressed (for why this is important, see the end of this post). Meanwhile, the R1.2 discussion is very focused and detailed. This is clearly what the drafting team has in mind when they talk about implementing compliance with CIP-013.
2. You may have seen NERC’s webinar on CIP-013 a few weeks ago (although I haven’t seen any recording or slides being made available from it, which is too bad). As I pointed out in my post about that webinar, there was little (and really no) discussion of anything else being required in CIP-013, other than the six items in R1.2.
3. During the CIP-013 discussion at WECC’s CIP Workshop last week, when I asked the auditors whether anything else was required beyond the six things in R1.2, I was told – using a few more words, but meaning the same thing – no.

If I’m so sure that NERC doesn’t intend to enforce anything more than compliance with R1.2, and if I say I’m OK with that, why am I even writing this post? Why not just go forth and tell people to focus solely on R1.2 and they’ll have all they need to comply with CIP-013? The reason is that, after all, R1.1 is in the standard. If an entity just focuses on R1.2, will they receive a PNC (potential non-compliance) finding in an audit three years from now because they ignored R1.1?

In other words, I can’t believe that it’s really going to be this easy: that FERC, NERC, the Regions and the entities will all come to some magical – and completely unspoken – agreement that R1.2 is all there is in CIP-013 and R1.1 can be ignored. There needs to be some statement or guidance to that effect, presumably from NERC. Otherwise, the CIP people at the entities will have trouble sleeping for the next few years, wondering if they really did the right thing by completely ignoring R1.1.

How could this problem have been avoided? I used to think that CIP-013 was almost the perfect standard, since it doesn’t prescribe any particular activities, but simply requires the entity to develop and implement a risk management plan. But I now realize that this isn’t enough. The entity can’t be simply told to go off and find some risks, then go mitigate them; given how NERC audits are conducted, they will inevitably find few or no risks, since for each risk they find, they now have to develop and implement a plan to mitigate it – and there is huge compliance risk attendant on that.

As I discussed in this post, I think the drafters of CIP-010 R4, the “CIP v6” requirement for Transient Cyber Assets and Removable Media, came upon the solution to this problem (and by the way, CIP-014 also suffers from this problem. This has shown up in audits, as discussed in this post. I’ve heard some talk of NERC deciding to rewrite the standard to fix the problem. This would be nice if it happened, but is probably wishful thinking). This requirement is plan-based, just like CIP-013 is. But the requirement doesn’t just tell the entity to go out and identify some risks and put them in their plan, as CIP-013 R1.1 does. Instead, Attachment 1 (which is part of the requirement itself, not just guidance) lists a number of items that must be included in the plan, for example, mitigating the risk of introducing malicious code from a laptop. So the entity knows that its plan must include mitigating the risks posed by malicious code; in fact, Attachment 1 provides suggestions for two ways to do this (antivirus software and application whitelisting), while allowing for “other methods” as well.

Now the auditors have something they can audit: They can go down the items in Attachment 1 and make sure the TCA/RM plan addresses each one of them. And not only that, they can determine whether the plan for mitigating each risk in Attachment 1 is effective. If the entity doesn’t include one of the risks in Attachment 1 in their plan, or if they propose a mitigation strategy for one of the risks that is clearly ineffective, they can receive a violation.

So the problem with CIP-013 is that this approach wasn’t followed when the standard was drafted, partly because nobody suggested it (I certainly never did, even though I attended several meetings in person or on the phone) but more importantly because they were under a very unrealistic deadline from FERC to deliver the standard to them in one year (which I hope to address in another post soon).

So what would I like NERC to do? I’d like them to do one of two things. The better course would be to a) admit that R1.1 lacks a list of risks that should be addressed in the plan, but at the same time b) either draw up themselves, or authorize another entity like the CIPC or NATF, to draw up a set of risks that entities should include in their plans. Entities couldn’t be issued a violation if they didn’t include one or more of these risks in their plans, but my guess is almost all of them would, since they’ll want to stay on the good side of NERC and the regions - and besides, it’s The Right Thing to Do. Supply chain risk management is something every organization should be doing anyway; this will give NERC entities that aren’t currently doing it a push to do so. Then, once FERC approves CIP-013 and (as I expect) includes a mandate to make changes (like including Lows and EACMS) in a new version, NERC can include in the Standards Authorization Request a mandate to draw up something for R1.1 like Attachment 1 of CIP-010 R4. This would then make R1.1 auditable, starting with the next version.

And what’s the not-so-good course? If NERC doesn’t like this idea and is fine with having R1.2 be all that’s required in CIP-013, they should say that is the case, and that they’re going to ignore R1.1. That way, entities will be able to sleep at night

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post. To discuss this, you can email me at the same address or call me at 312-515-8996.

---

[i] As I pointed out in the post referenced above this passage, the word “mitigate” seems to have been left out of R1.1, so that strictly speaking the entity is only required to “identify and assess” risks, not actually do anything about them. Of course, this makes no sense (and very much contradicts everything else that NERC and FERC have said about this), so I’m assuming it’s simply an error. It would be nice if it could be fixed before CIP-013-1 comes into effect, but it will most likely have to wait until at least v2.

[ii] And, as I’ve said before, since CIP-013 is a risk-management standard, the entity can base all of the actions in its plan on the level of risk. For higher risks, more mitigation would be required. For lower risks, little or no mitigation would be required. In other words, just because the entity is required to identify “all” of the risks from each of the three risk areas in R1.1, this doesn’t mean they need to devote the same level of resources (or even any resources at all) to mitigation of each risk. In fact, they will do what they would do in the absence of a mandatory standard (but with the same budget available): mitigate the highest risks to the highest degree, and devote fewer or even no resources to mitigating the lesser risks.