What about the Implementation Date for Lows?

I think a lot of CIP compliance professionals have September 1, 2018 circled on their calendars in heavy red ink, given the amount of work they think will need to be done by that date. I’m referring here to the date that compliance with CIP-003-6 R2 Attachment 1, Sections 2 and 3, comes due (the other two sections having already come due). These two sections cover physical and electronic access control for Low impact assets.

However, as I pointed out in a post last November, FERC called that date into question in their October NOPR, in which they proposed to approve CIP-003-7, the revised version of CIP-003 that was approved by NERC early in 2017. The implementation plan for CIP-003-7 says it will come into effect 18 months after FERC approves it, and that CIP-003-6 will be superseded when that happens. In other words, when FERC approves CIP-003-7 (and I believe it is highly likely they will do this, since they said they would!), the clock will start running on the 18 months. And the 9/1/18 date will end up being just another Saturday on a Labor Day weekend.

So what will be the implementation date for CIP-003-7? In the post, I pointed to July 1, 2019; however, I’m not sure what I was smoking when I said that. Since the plan says the implementation date is the first day of the calendar quarter after the 18-month anniversary of the approval by FERC, this means that, for my guess to have been right, FERC would have had to approve CIP-003-7 not much more than a month after I wrote the post (i.e. in December, since I wrote the post on November 12).

Of course, FERC didn’t approve CIP-003-7 in December. If they approve it before March 31, the effective date will be October 1, 2019. And if they approve it in the second quarter, the date will be January 1, 2020.

So, unless FERC decides not to approve CIP-003-7 after all (hardly a likely scenario), CIP-003-6 will never come into effect, and CIP-003-7 will come into effect more than a year after the 9/1/18 date that everyone has circled on their calendars. You can take this as a Valentine’s Day present.

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. I would also love to talk about this; please email me at the same address.

On my Own!

As many of you know, I have been looking for a new position since last November, after falling victim to layoffs at my previous employer. I am pleased to announce that I have accepted a position with a new employer: Tom Alrich LLC (you might even say this position was made for me!).

This is literally the first time in my life that I’ve been self-employed, and it looks now like this is definitely the best move for me. I will of course be offering consulting services related to NERC CIP (both related to the current standards as well as CIP-013), but also more generally to power industry cyber security. I will work with NERC entities (utilities and IPPs) as well as with vendors to the industry. For the latter, I can provide assistance in strategy and marketing, as well as in preparing for CIP-013, which will of course affect the vendors almost as much as (in some cases more than) the NERC entities themselves.

I’m pleased to say that I already have a decent amount of work in the hopper for the rest of this year. However, I still have availability! If you would like to discuss a project – or have any other questions, want to complain about something I wrote, etc. – please call me at 312-515-8996 or email me at tom@tomalrich.com.

Complying with CIP-013, Part 2: Lost in R1.1

This is the second in a series of posts on NERC CIP-013, the upcoming supply chain security management standard. In the first post, I tried to empty my head of everything I already knew (or had opinions on) about CIP-013, and tried to focus on just what was written in the standard itself. I started with the statement of the standard’s purpose, and tried to tease out of that some good pointers on what will be required to comply with the standard. Just analyzing this single sentence showed that complying with CIP-013 will be very different from complying with any previous CIP standard.

In this post, I will look at the requirements of CIP-013 (and they’re all pretty short!). Again, I’ll try to forget anything I know about the requirements or what has been said about them, since in the end all that matters is what is written in the requirements themselves.

Let’s start with R1, which reads:

R1. 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:

Of course, this is very different from almost all of the other CIP requirements, which require the entity to put in place specific security controls – configuration management, patch management, personnel risk assessments, etc. R1 requires the entity to develop a plan, period. Sure, the plan will need to include certain items to be listed later, but those items aren’t themselves the point of the requirement; the plan is. This isn’t new; there are two currently-enforced CIP requirements that are written in exactly the same way: CIP-003-6 R2 and CIP-010-2 R4. These are also plan-based requirements.[i]

And what is the purpose of the plan required in CIP 13 R1? It is “supply chain cyber security risk management”. In the first post in this series, I already emphasized the fact that the purpose of CIP 13 is risk management, not implementation of particular controls – so the fact that R1.2 lists six particular controls that need to be in place shouldn’t be taken to mean that your plan just needs to address these controls. Your plan needs to address the mitigation of supply chain cyber security risk in general, which is a much broader topic than these six controls.

Let’s continue with the two parts of R1. R1.1 reads:

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).

Note that this is pretty curious wording. R1 left off with the words “The plans shall include:” This means that 1.1 should lay out something that must be included in the plan. Instead, 1.1 requires “one or more processes used in planning for the procurement of BES Cyber Systems to…” What does this mean? Concatenating these words with the end of R1 leads to:

“The plan shall include one or more processes used in planning for the procurement…”

Why should a plan include “processes used in planning”? This means that the plan should be for developing further plans. A plan should be for taking particular steps to achieve a particular goal, not for simply developing more plans. Wouldn’t it be simpler just to say the plan should include identification and assessment of cyber security risks to the BES from the two areas of risk listed? Why does there need to be this intermediate step of having “One or more process(es) used in planning…”?

To be honest, I’m not sure at the moment why these words are there; maybe a drafting team member (or someone else) can enlighten me on this.[ii] I recommend you ignore those words. In other words, I suggest you interpret this requirement part as if it were written:

1.1. Identification and assessment of 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).

If R1.1 were worded this way, what would an entity need to include in its plan in order to be compliant with this requirement? The plan would need to include steps to a) identify and b) assess risks to the BES from vendor products or services resulting from risk areas (i) and (ii).

What does this mean? First of all, I want to point out that item (i) really includes two risk areas, not one. Risks from procuring vendor equipment and software are very different from risks from installing vendor equipment and software. This means I would rewrite the part of the sentence after the colon as “(i) procuring vendor equipment and software; (ii) installing vendor equipment and software; and (iii) transitions from one vendor(s) to another vendor(s).”

Once we’ve made that change, I interpret R1.1 – if written as it is directly above – to require the following steps:

1. For each of the three risk areas, identify particular risks included in each one. For example, in the area of “procuring vendor equipment and software”, an entity might identify risks such as “the risk that a piece of third-party software included with the product will be infected with malware”; “the risk that the software will include known vulnerabilities that haven’t been mitigated”; etc. This is, of course, potentially a long list. However, IMHO the entity doesn’t have any choice but to list all of the risks[iii] that might be part of procuring vendor equipment and software. As we’ll see in one of the upcoming parts of this series of posts, just the fact that an entity needs to develop a complete list of risks doesn’t mean they will have to spend a lot of time and money mitigating each one; in fact, the entity might determine (and document) that some of those risks are so small that no mitigation at all is required. This is permitted, of course, due to the fact that CIP 13 is the first NERC risk-based requirement.
2. “Assess” each of these risks. What does this mean? Obviously, there are many aspects of each threat that we might assess. For example, we might assess each threat based on whether it targets our particular department or not; those that don’t affect our department can be ignored.[iv] However, what I think needs to be assessed here is the level of risk in each case.[v] I think that the entity needs to classify each of these risks according to some scheme: high/medium/low; high/low; 1 to 5; etc.

Once the entity has included in the plan each of the above steps (and of course each of these has quite a few implied sub-steps), I think they have properly addressed R1.1 as written. But wait! Haven’t we forgotten something here? We’re going to include in our plan steps to a) identify risks and b) assess those risks. Why are we doing this? Are we going to be satisfied if we simply produce a nice list of risks, each one ranked as – for example - high, medium or low? What else could be needed?

Here’s something else: How about mitigating those risks? After all, isn’t that the whole idea of CIP 13? To actually lower the overall risk to the BES by mitigating supply chain security risks? Yet R1.1 doesn’t require the entity to include anything about mitigation in their plan.[vi]

To be honest, I think it is simply a mistake that mitigation isn’t mentioned in R1.1. It doesn’t make any sense just to identify each risk, assess it, then call it a day and go home. You need to interpret R1.1 as if it included mitigation. In other words, there needs to be a third step in the list above, reading something like:

3. For each identified risk, mitigate the risk according to the risk level assigned to it in step 2.

Of course, there is a lot more that could be said about this step, and I’ll hope to do that in some future post.

I must admit that, when I started to write this post a few hours ago, I thought I was just going to go over the words of R1 and R1.1 and tease out all of their meaning. Instead, I’ve found that R1.1 doesn’t make much sense unless two changes are made to it (the change incorporated in my revised R1.1 above, as well as adding mitigation to R1.1, as just discussed). So, with greatest respect, I suggest that NERC entities interpret R1.1 to read this way:

1.1. Identification, assessment, and mitigation of cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring vendor equipment and software; (ii) installing vendor equipment and software; and (iii) transitions from one vendor(s) to another vendor(s).

I’m having a déjà vu moment here. A little less than five years ago, in late April 2013, I set out to write the first of what was going to be a series of posts on how to comply with the CIP version 5 standards; I did this because FERC had about two weeks previously issued a NOPR saying they intended to approve v5 (just as FERC did with CIP-013 less than two weeks ago). Since CIP-002-5.1 was the first standard in order, I started with that.

In that post, as in this one, I tried to work through the steps that would be required to comply with CIP-002-5.1 R1 (including Attachment 1), and I came to a “you can’t get there from here” point – where the logic in the requirement completely broke down. That is a serious flaw in CIP 2 R1 that has never been fixed. At the time, I thought the only solution was to rewrite the requirement (and Attachment 1); I wrote perhaps ten to fifteen posts on this particular topic over the next couple of years (plus many more on other problems in CIP 2 R1), of course without success.

However, it turns out that this flaw didn’t prove to be very harmful as CIP v5 was implemented and then enforced. This is because NERC entities and auditors all came to a common interpretation of CIP 2 R1. The interpretation wasn’t based on the actual wording of the requirement and Attachment 1, but since there was unanimity among entities and auditors, everyone came to believe that this interpretation was actually the correct one.[vii]

Now I believe I’ve found a serious problem with CIP 13 R1.1 (namely the lack of mention of mitigation. The first problem I discussed is more of an annoyance than anything else), but this time I’m not even going to suggest that R1.1 be rewritten. It would easily set back implementation of CIP 13 by more than a year, and I think the solution will be the same as it was with the problem I found in CIP-002-5.1: There will just need to be a common interpretation[viii] of R1.1 that includes mitigation. In fact, I humbly[ix] suggest that my version shown above could be used as that common interpretation – I’ll even make it available royalty-free!

The views and opinions expressed here are my own, and do not reflect those of any organization I work with or for. 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.

---

[i] There is another current requirement that is, in my opinion, functionally plan-based. CIP-011-2 R1 requires an information protection program, not a plan. However, the rest of the requirement closely matches CIP-003-6 and CIP-010-2 in form. This is interesting because CIP-011 R1 was developed as part of the “CIP version 5” effort, while the other two requirements were developed several years later, as part of “CIP version 6”.

You may wonder about two other requirements that were originally part of “CIP version 5” that specifically require “plans”. CIP-008-5 R1 requires the entity to develop a cyber security incident response plan, while CIP-009-6 R1 requires recovery plans. However, I distinguish between these two requirements and the three requirements cited above: The plans referred to in CIP-008-5 R1 and CIP-009-6 R1 are actually controls that need to be implemented to protect against threats that might be realized in the future. In CIP 8 R1, the threat is that of a cyber security incident (or more precisely, the threat is that the entity will not respond in an intelligent fashion to a cyber incident and will end up making things much worse). In CIP 9 R1, the threat is that there will be outages of systems that could impact BES reliability unless quickly restored.

The only way you can deal with these two threats is to put a plan in place to address them when they are realized. So CIP 8 R1 actually requires a control – the CSIRP – to address the threat of improper response to cyber incidents, while CIP 9 R1 requires a control – the recovery plan(s) – to address the threat of inability to restore one or more systems when lost. To compare this with a requirement that doesn’t require a plan, CIP 7 R2 requires a control – a patch management program – that mitigates the threat of malicious code. All three of these are prescriptive requirements requiring one or more controls to be implemented; it’s just that in the first two requirements, the control happens to be a plan. That doesn’t make these plan-based requirements using my definition of the term: a requirement to develop a plan for addressing a particular threat or set of threats.

[ii] And I’m not in any way saying the drafting team did anything wrong here; after all, I attended at least two of their face-to-face meetings and some of the call-in meetings, and I never raised this issue at the time. In fact, I didn’t notice this issue, or other issues noted in this post, at all until I started to write the post.

[iii] I would much prefer if R1.1 referred to threats, not risks. I will hopefully address this issue in an upcoming post (and if not, it will definitely be addressed in the book that I and two co-authors are working on, regarding how the CIP standards could/should be rewritten). Briefly, I think the steps should actually be: 1) identify threats; 2) using estimated impact of each threat and the fact that risk = threat X impact, classify each threat by the relative degree of risk it poses; and 3) develop a mitigation strategy for each risk, based on its classification. This would be much clearer if CIP-013 distinguished between threats and risks.

[iv] Obviously, I’m being facetious here.

[v] And as I said in end note ii above, I think this requirement part would be much clearer if it distinguished between threats and risks.

[vi] And, while it might be tempting to think that R1.2 is the part where mitigation is required, that would be a mistake. As I will discuss in the next post in this series, R1.2 lists a set of six specific risks that FERC required NERC to address in this standard when they ordered its development in Order 829; it was never meant to be any sort of comprehensive list of the risks to be mitigated. R1.2 does require mitigation of these six risks, but not of any other risks.

And don’t think that R2 might save the day here. R2 just requires implementation of whatever is in the plan, nothing more. If the plan only includes identification and assessment of risks, then that’s all that has to be implemented.

[vii] Briefly, the issue is that the wording of CIP 2 R1 and Attachment 1 is contradictory. Some of the wording – especially in Attachment 1 Section 3 – leads one to believe that assets should be classified as high, medium or low impact, while most of the wording says that only BES Cyber Systems are classified, not the assets themselves. However, I’d say there is close to 100% unanimity in the NERC community that it is assets, not BCS, that are being classified in Attachment 1. And since this is working, why mess with it? I think I last raised this issue in late 2015 in this post. I don’t intend to raise it again. There are enough real problems with the current CIP standards to be discussed, without dragging out what has turned out to be a fairly harmless wording problem.

[viii] Of course, since it doesn’t make any sense just to identify and assess risks and not mitigate them, it’s very hard to see how R1.1 could be interpreted any other way.

[ix] OK, not so humbly.

An Auditor Weighs in on the Patch Management Question

Last week, I wrote a post on an interesting CIP-007 R2 patch management compliance question, related to the Spectre/Meltdown patching issue. I had guessed that, in a particular case described in that post (in item 9 near the end), the Microsoft patch would be deemed applicable and the entity would still be required to develop a mitigation plan, even though they couldn’t actually install the patch. Shortly thereafter, I received an email from a good friend, Joe Garmon, disputing my statement that the patch would be applicable in this case. You can read my summary of Joe’s argument in this post.

I thought this matter was settled, when an auditor wrote in to dispute Joe’s assertion. I have quoted his email verbatim below. I do want to point out that I’m not doing all of these posts because I think there are a lot of organizations that will be in the same situation as the hypothetical entity I described in my first post; in fact, I’d be surprised if there were any NERC entities at all in that situation. I’m doing this because I think the discussion provides good insight into an important question about CIP-007 R2 – just what the word “applicable” means. Here are the auditor’s words:

“Respectfully, Joe is incorrect.  Joe has confused applicability with installability.  The two concepts are distinctly different.

The patch is applicable to the operating system (Microsoft, Linux, etc.).  The patch is incompatible with the installed anti-virus software.  The patch, therefore, cannot be installed.  But that does not mean the vulnerability has magically gone away and it does not mean that the patch is no longer applicable.  Were the anti-virus incompatibility not to exist, Joe would be installing the patch, assuming there were no other reasons to mitigate instead.

And therefore, as the patch remains applicable (and needs to be mitigated until such time as the patch can be installed), Joe’s observation that he would not have to go back and apply the patch once he changed out his anti-virus software with something that is compatible is also incorrect.  Again, the vulnerability is addressed with a patch to the operating system, not to the anti-virus software.  It would not be applicable only if Joe was not running a version of the operating system for which the patch can be installed (e.g., a Microsoft Windows 7 patch would not be applicable to Windows 10 nor Linux).

Taking all this into consideration, Joe is incorrect on one last point.  The auditor will not give Joe an Area of Concern.  Joe will receive a Potential Non-Compliance finding.

Now, here is the real nuance.  The patch is applicable if and when the identified patch source announces the patch.  So, if his patch source is the operating system vendor or a commercial third-party patch provider (and there are many), then the patch will pop up on radar and it will be deemed applicable.  If, however, Joe’s patch source is his SCADA/EMS vendor and, for some reason, the vendor’s very poor practice is to not announce the availability of an operating system patch that is incompatible with its SCADA products, then Joe is off the hook from a compliance perspective.  That is a scenario where Joe might receive an Area of Concern.  But don’t assume the vendor’s practice is that poor.  Most SCADA/EMS vendors, if not all, will advise their clients that the patch is available but cannot be installed.  And a vendor that simply hides the incompatible patch is really doing a major disservice to its clients."

The views and opinions expressed here are my own, and do not reflect those of any organization I work with or for. 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. 

Upcoming Speaking Engagements: RSA and PDDC

I’m pleased to announce that I have two speaking engagements in the next few months:

On Thursday April 19 at 9:15, I’ll be participating in a panel discussion at the RSA Security Conference in San Francisco. My fellow panelists will be Mark Weatherford, former CISO of NERC; Marc Sachs, former Chief Security Officer of NERC (and head of the E-ISAC); and Dr. Art Conklin of the University of Houston.

Our topic will be “How can We Regulate Critical Energy Infrastructure Security?” We are asking how the cyber security of critical energy infrastructure - oil and gas pipelines, oil refineries, and of course the Bulk Electric System – can be regulated in a way that is both cost-effective and adaptable to new cyber threats. Naturally, we will draw on the power industry’s experience complying with the NERC CIP standards in our discussion.

The other talk will be at the Power Design Delivery Conference in Ketchum, Idaho (which skiers will recognize as the home of the Sun Valley ski resort. I don’t ski, but I’m looking forward to the scenery!). I’ll be speaking as part of a keynote panel discussing “Cyber Security: Threats, Compliance and Practical Protection.” My topic will be “What’s in Store for Low Impact Assets?”  Our discussion will be at 9:15 AM on the first day of the conference, Wednesday, February 28.

So if you find yourself in the neighborhood of the Moscone Center in San Francisco or the Opera House in Ketchum, please come by!

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 tom@tomalrich.com. 

Another Opinion on the Patch Management Question

Last week, I posted about the implications of Microsoft’s Spectre/Meltdown patch for CIP-007 R2 patch management compliance. At the end of the post, I discussed (in item 9) a possible issue in the case where your HMI vendor doesn’t mandate using a particular antivirus software vendor, but the vendor you are using won’t support the patch.  I further stipulated that it wouldn’t be easy to replace your A/V vendor, for some reason. In this case, I stated in the post that it seemed clear to me that, in this case, you would need to deem the patch applicable to your HMI; since you wouldn’t be able to install it, you would need to develop a mitigation plan.

However, on Friday I got an email from a longtime friend and a very knowledgeable CIP expert, Joe Garmon, Senior Manager of Safety and Security Manager at a G&T coop in Florida (who emphasized that his opinions were solely his own). He pointed out that, for the patch to be applicable, it would have to work in the current software configuration – you shouldn’t have to take extra measures like replacing your A/V vendor in order to get the patch to work. Given that the patch would only work if you replaced your antivirus vendor (as in the case we’re discussing), then it’s not applicable. Moreover, even if in the future you replace your A/V vendor with one that will support the patch, you’re not obligated to go back and install this patch.  This peculiarity is due to CIP-007 R2.2, which only requires that you review patches for applicability released since the last evaluation, and per R2.3 you only have to install or mitigate patches that are applicable.

Of course, having said the above with his compliance hat on, Joe put on his security hat. Then he said that it would obviously be a good security practice to take other mitigating steps if you couldn’t deploy the patch; and if in the future you do replace your A/V vendor, you should certainly try to install the patch then (although, since MS patches are cumulative, you would only have to install the most recent patch available at the time).

Of course, Joe said he expects that an auditor who came across this situation – where the entity had not installed the patch but not taken any mitigation measures - would issue an Area of Concern to the entity, indicating they should mitigate the threat addressed by the patch. But this shouldn’t be a matter of compliance with CIP-007 R2.

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 tom@tomalrich.com. 

Complying with CIP-013, Part 1: The Purpose of the Standard

This is the first in what will probably be a long series of posts on CIP-013 – although they certainly won’t all be contiguous. The purpose of these posts is to help you understand the main issues involved with CIP-013, so that you can start planning how you will come into compliance by the effective date (which, as I noted last week, is likely to be no later than October 1, 2019). As I have already pointed out (and will continue to!), I am now an independent consultant and would love to discuss with you how I might help your organization both plan and implement your CIP-013 compliance program – and this applies to vendors as well as NERC entities. Just drop me an email at tom@tomalrich.com.

In this post, I’m going to pretend that I’m looking at CIP-013 for the first time, and that I haven’t been part of previous discussions about it. What can I learn by simply reading the standard? This might seem like just an academic exercise to you, but remember: The standard as written is the only thing you can hang your hat on. Any other guidance – including the Implementation Guidance prepared by the drafting team – has no official status for compliance. It’s important for you to understand what the standard actually says, and then weigh what other people – including me – say about it.

The first sentence in the standard describes its Purpose: “To mitigate cyber security risks to the reliable operation of the Bulk Electric System (BES) by implementing security controls for supply chain risk management of BES Cyber Systems.” What do you notice about this?

The first thing I notice is that the word risk is used twice. By contrast, I don’t think any of the other CIP standards use that word at all in their Purpose statements. For example, CIP-003’s Purpose statement reads “To specify consistent and sustainable security management controls that establish responsibility and accountability to protect BES Cyber Systems against compromise that could lead to misoperation or instability in the Bulk Electric System (BES).” CIP-007’s Purpose is “To manage system security by specifying select technical, operational, and procedural requirements in support of protecting BES Cyber Systems against compromise that could lead to misoperation or instability in the Bulk Electric System (BES).”

The CIP 3 and CIP 7 Purpose statements speak in engineering terms. They are both based on the faith that putting in place certain “management controls” or procedures – namely, those specified in the requirements - will provide adequate protection to BES Cyber Systems. But CIP-013 doesn’t talk this way. It doesn’t say there are certain specific things that a NERC entity needs to do in order to have good supply chain security. It just says there are risks present in supply chains, and they need to be “managed”.

Note there is no mention of eliminating risks, or of “protecting” BES Cyber Systems. The Purpose statement admits up front that risks will never be completely eliminated and BCS won’t ever be completely protected. The best we can do is mitigate the risks so that they’re “manageable”. Is this some sort of cop out? Has NERC lost its nerve? After all, wasn’t its goal always to protect the BES from cascading outages, etc? Now NERC is just saying “Well, we can never really protect the BES from supply chain risks. The best we can ever hope to do is reduce the risk that some supply chain compromise will cause a cascading outage.”

Of course, I’m sure you agree with me that NERC is right here: The best that can be done is to mitigate cyber risks to the supply chain, not eliminate those risks and “secure” the supply chain. In fact, this is really the case for the other CIP standards. Their faith that certain procedures or other controls will “secure” BES Cyber Systems, or that BCS can be “protected”, is misplaced. Really, all of the other CIP standards – including their Purpose statements – should be rewritten so that they follow the path that CIP-013 has blazed for them.[i]

We now know that the goal of CIP-013 is mitigation of risks, not implementation of particular controls. This right away tells us that we need to look at this standard very differently from the previous NERC standards. What are some of the obvious differences?

1. The risks to be mitigated in CIP-013 are risks to “the reliable operation of the Bulk Electric System”, not to the organization. Of course, since the other CIP standards are also focused on threats to the BES, this may not seem like a particularly remarkable statement. However, when we talk about supply chain risks in general we’re often thinking about organizational risk: the risk that a key supplier will go bankrupt and the organization will have to pay a lot of money to transition to another supplier’s systems, etc. We need to keep in mind, as we talk about the risks we’ll be addressing in CIP-013 compliance, that the only risks that matter are risks to the BES. Even if we know that a particular risk – like a key supplier going bankrupt – does actually pose a BES risk, we need to make sure we document it that way, since the controls we implement to mitigate a particular risk will be different depending on how we frame that risk, and since the auditors will want to see that we are actually mitigating risk to the BES, not just to the organization.
2. “Mitigation of risk” isn’t a measurable concept, so the CIP-013 requirements won’t be auditable in the same way the other CIP standards are. There’s no way an auditor can say “You haven’t mitigated enough risk, so I’m going to find you in violation.” There will have to be some other way you will be measured (of course, I’ve written a number of posts on this question of auditability recently, but I’m pretending that I’m reading CIP-013 for the first time, so I’ll ignore those for the moment).
3. CIP-013 R1.2 may seem to be a requirement like those in the other NERC CIP standards: It requires the entity to do six particular things. So you might ask “Why do you say this standard is so different? Won’t I be found non-compliant if I don’t do one of these six things?” It’s certainly true that you will be found non-compliant if you don’t do one of the six things. However, what’s different is that these six things are only one part (and not a big part) of what you need to do to comply with CIP-013. It’s everything else that’s very different from the other CIP standards.
4. When we talk about cyber security controls in the context of the other CIP standards, we’re always talking about controls that the NERC entity puts in place, regarding its own systems and procedures. However, a good portion (although certainly not all) of the controls that will need to be implemented for CIP-013 compliance will actually be ones that a vendor puts in place, regarding its own systems and procedures. At the same time, vendors don’t have to comply with CIP-013; NERC entities do. How will this work, where the burden of compliance will be somehow split between the vendor and the customer (i.e. the NERC entity), but the responsibility for compliance lies completely with the customer? The answer: This is still To Be Determined, and it’s unlikely there will be some sort of clear, universally-adopted answer to this question any time soon (and perhaps ever). Have a nice day.
5. The last part of the single sentence in the Purpose statement says you will have to implement “…security controls for supply chain risk management of BES Cyber Systems.” I believe this marks the first time that the phrase “risk management” has appeared in a NERC CIP standard (or for that matter, in any NERC standard). In all of the other CIP standards, the controls wouldn’t be described as being for risk management but for cyber security. But this is a clue that we’re not in Kansas anymore, Toto: What is going to be required is a risk management exercise, not a particular set of controls.

In the next post in this series, we’ll start looking at the CIP-013 requirements themselves.

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 tom@tomalrich.com.

---

[i] The idea that all of the CIP standards should be replaced by risk-based ones is one of the four principles of the book that I and two co-authors are working on. We hope to have it published by the end of 2018, and perhaps sooner than that.

A Good Explanation of Spectre/Meltdown

I recently saw a very good blog post on the Spectre/Meltdown vulnerabilities and their impact on Industrial Control Systems. I especially like the very simple analogy they set up to explain why for single-user systems there isn’t much danger.

The post is on Indegy’s web site. They have a very interesting product you might want to investigate, for visibility into ICS networks.

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 tom@tomalrich.com. 

FERC will Approve CIP-013, and There’s one Surprise

In FERC’s Sunshine Meeting this morning, they issued a Notice of Proposed Rulemaking that says they intend to approve NERC CIP-013, the supply chain security risk management standard, as well as the accompanying modifications to CIP-005 and CIP-010. Of course, the interesting part was what they also said. Here is my summary:

First, they find that NERC did a good job of drafting a standard that carries out what they mandated in Order 829. However, Commissioner LaFleur, in her statement concurring with the Commission’s decision, says “The proposed standards would provide significant flexibility to registered entities to determine how best to comply with their requirements. In my view, that flexibility presents both potential risks and benefits. It could allow effective, adaptable approaches to flourish, or allow compliance plans that meet the letter of the standards but do not effectively address supply chain threats. I hope that we will see more of the former, but I believe the Commission, NERC, and the Regional Entities should closely monitor implementation if the standards are ultimately approved.”

What Commissioner LaFleur is asserting is similar to what I’ve been (at least implicitly) saying in my recent posts about auditability of CIP-013: There really isn’t much in the requirements themselves that would allow NERC to reject a plan that was clearly inadequate. However, I’ve also been saying that I’m not too concerned about whether plan-based standards like CIP-013 are auditable or not. What matters is whether the NERC entity can get assistance from their Regional Entity, over the course of developing and implementing their plan, in making sure their plan is a good one and is implemented well. This goal isn’t furthered by audits (or at least, audits are a very inefficient way of furthering it); I described another way that the Regions could provide this assistance in this post.

Second, FERC questioned why CIP-013 only applies to Medium and High impact BES Cyber Systems, not Low BCS or Medium and High Electronic Access Control and Monitoring Systems (EACMS), Protected Cyber Assets (PCAs), or Physical Access Control Systems (PACs). Since NERC is currently conducting a study (ordered by the Board of Trustees when they approved CIP-013 last August) of additional supply chain risks, including those associated with Low impact BCS, the Commission stated that this study should go forward, although it should also look at risks associated with PACs and PCAs.

However, regarding EACMS, the Commission stated that the risks associated with these systems are sufficiently clear that there’s no need to wait for a study. Accordingly, FERC proposes to order that EACMS be included in the applicability of CIP-013, and is seeking comments on this proposal. Since NERC standards can’t be modified once approved by the Board of Trustees, this means that the CIP-013 drafting team will need to develop a modified CIP-013 (as well as CIP-005 and CIP-010) that includes EACMS in the applicability section.

The above two items in the NOPR aren’t terribly surprising. However, there is one item that was surprising (or at least I was surprised by it), relating to the implementation date for the three new or revised standards. FERC believes that the current 18-month implementation plan is too long by six months. They are proposing (and seeking comments) to order NERC to change this to 12 months. In other words, in the same Order in which FERC approves CIP-013 (and the revised CIP-005 and CIP-010), FERC would order NERC to revise the CIP-013 Implementation Plan.

FERC is seeking comments on this proposal, but I sincerely doubt they’re going to change their mind on this. So let’s say FERC issues their Order this May. NERC will have to revise the Implementation Plan[i] to 12 months. 12 months after this May is obviously May 2019. Since the Implementation Plan says that the effective date will be the first day of the calendar quarter after this, it means the effective date of CIP-013 will be July 1, 2019. If FERC issues their Order after June of this year, the effective date will be October 1, 2019. In either case, this will be before the implementation date I had been anticipating, which is either January 1 or April 1, 2020.

So, as of today, you have less than 21 months to implement CIP-013, and perhaps less than 18 months. I don’t think any medium-to-large NERC entity should wait any longer to at least develop a plan for implementing CIP-013 compliance by July 1, 2019.

And – as I mentioned in my last post – Tom Alrich Consulting would be pleased to discuss with you how we might help you develop your plan to come into compliance with CIP-013-1, CIP-005-2 and CIP-010-3. If you would like to set up a time to discuss this, please drop me an email at the address below. Since I happen to know the owner of TAC very well[ii], I’ll make sure he pays close attention to you!

 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 tom@tomalrich.com.

---

[i] And if you think this revised Implementation Plan would probably be voted down by the NERC membership and would therefore be null and void, you’re engaging in wishful thinking. If the NERC membership doesn’t approve a new or revised standard (or implementation plan) that has been ordered by FERC, the NERC Board of Trustees is required by the Rules of Procedure to develop this themselves and submit it to FERC. In other words, the NERC membership will have two options: a) approve the new standard, or b) have the Board approve it anyway. Isn’t choice wonderful?

[ii] OK, perhaps not that well. He’s always surprising me.

It’s Time to start Planning for CIP-013!

In October, I wrote a post pointing out that, even though the likely implementation date for CIP-013, the new supply chain security management standard, was more than two years away, there were good reasons to at least start the compliance planning process. The main reason why I made this assertion was that vendor contracts come up for renewal all the time. If your NERC entity knows what cyber security language you should request for CIP-013 purposes and can get it incorporated in new contracts, you will be saving yourselves many times more effort when CIP-013 comes into effect, since it is always harder to get vendors’ undivided attention when there isn’t a new contract on the horizon.

That argument is still valid, but there are a couple more that demand even more attention. First, I heard this morning that FERC has CIP-013 on their agenda for their meeting this Thursday. They will almost certainly do one of two things: a) Issue a Notice of Proposed Rulemaking (NOPR) stating their intention to approve CIP-013 and asking for comments; or b) Issue an Order approving CIP-013. In either of these cases, they could also make clear their intention to order changes to the standard, which would then have to be drafted and voted on as CIP-013-2. But either way, CIP-013-1 will be on the path to implementation.

The difference between these two cases, as far as the implementation timeline goes, is that an Order would start the clock ticking on the 18-month implementation plan for CIP-013, meaning compliance will be due about 18 months after this Thursday (the due date would probably be October 1, 2019). However, if they issue a NOPR (and I believe this is the more likely course) and allow 3-4 months for comment before issuing their Order, the compliance date will be either January 1, 2020 or April 1, 2020; my guess is it will be the latter.

So does April 1, 2020 sound like it’s a long time away? If you are a small organization (with one or more Medium or High impact assets), this might in fact be a long time. But if you’re a medium-to-large organization, you can’t wait much longer to at least begin your planning process for coming into compliance with CIP-013. I have been discussing what CIP-013 compliance requires with some NERC entities in the past few months, and I can assure you it’s probably a lot more than you thought. In fact, I will soon start a series of posts on what is needed for CIP-013 compliance, so you can understand why I say this.

However, there’s another reason why it’s important to start CIP-013 compliance soon, that I realized when I wrote this post last week. The gist of the post is that plan-based requirements (like those in CIP-013) need to be treated differently by the NERC Regional Entities than prescriptive requirements (like many of those in most of the other CIP standards). When an entity is required to develop and implement a plan, as in the case of CIP-013 R1 and R2, there really needs to be some mechanism for the Region itself to be able to review the plan before it is implemented. The post describes such a mechanism, which was suggested to me by an auditor; most importantly, it’s a mechanism that’s already in effect in one Region and could be replicated in others.

So, while I can’t promise anything, I think it’s a good assumption that by maybe a year and a half from now, most if not all of the Regions will be able to review your CIP-013 supply chain cyber security risk management plan and offer you comments on it. The comments won’t touch on whether the plan is “compliant” or not, but will touch on how what you are proposing in the plan compares with best practices. My guess is most NERC entities will welcome being able to have this review, to avoid the problems that were discussed in relation to CIP-014 (another plan-based CIP standard) in this post and this one.

So let’s say your entity waits a few months, then starts leisurely thinking about what CIP-013 requires. Meanwhile, FERC issues their Order approving the standard and the compliance date is now set for April 1, 2020. You realize that you now have a little more than 18 months to become fully compliant. You accelerate the compliance planning process, and as soon as possible start to implement compliance (remember, you will have to be compliant on the effective date of the standard). You make a Herculean effort, and you are finished – including having a fully developed plan – by say February 2020.

You might feel pretty good about this, but let’s say you then decide to ask your Region to review your plan. They say they’ll be glad to do this, but since a number of other entities have just asked the Region to review their plans, it will be more than say six months before they can review yours and report back to you on it (say they’ll get back by August 2020).

This means you will have to start implementing your plan in April, without having the benefit of any feedback from your Region. The main reason you asked for the review was to be able to hear and act on the results before you started implementing the plan; while it will still be good to have those results, it would obviously have been much better to have them at least a few months before April 1. You will have to start implementing the plan without knowing what your Region thinks of it.

Ideally, it would have been better if you could have finished your plan say by October 1, six months before the CIP-013 implementation date. That would have given your Region time to review and comment on the plan, as well as given you time to change the plan to reflect those comments – all before the April 1, 2020 compliance date. But obviously, this would have required starting the CIP-013 process earlier, like say around January 2018!

The moral of this story is of course that you should really start thinking now about the different structures required for CIP-013 compliance, and how you will implement them at your organization. And now here’s the sales pitch: Tom Alrich Consulting is prepared to help you do this thinking! The first step might be a set of workshops over say three days to a week, including the different groups that will be involved with CIP-013 compliance – and unlike the previous CIP standards, CIP-013 will require substantial involvement from Supply Chain and Legal, as well as Cyber Security, IT and NERC Compliance. With the experience of those workshops, I can work with you to develop a roadmap for your CIP-013 compliance implementation – and leave enough time for review by your Region! Like more information on this? Drop me an email at tom@tomalrich.com. 

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 tom@tomalrich.com. 

An Interesting CIP Compliance Question

I have known Monta Elkins of Foxguard Solutions for three or four years, and have a lot of respect for him. If you’ve never seen his demonstration of hacking into a power drill and making it play the Darth Vader theme, you’ve missed something! So I was intrigued when he contacted me last week and said he wanted to discuss an interesting CIP compliance question he’d come across, which relates to the new Spectre and Meltdown vulnerabilities in Intel (as well as other) chips, and to Microsoft’s efforts to patch them. I’ll tell you up front that I’m not sure about the answer to this question. But here are the facts[i]:

1. Two weeks ago, Microsoft released a software update to address these two vulnerabilities (as well as other unrelated issues). However, they warned that, once the update was installed, some antivirus software packages would cause the “Blue Screen of Death” and refuse to boot the PC.
2. To show that their software is safe to use with the new update, Microsoft is requiring that A/V vendors set a particular Windows registry key, although it is also possible for the user, or an organization, to set it apart from the A/V vendor.
3. But here’s the kicker: If the user tries to install the update without the registry key being set, none of the patches will be installed. Moreover, since Microsoft’s monthly software updates are now cumulative, no further patches will be installed in subsequent months, until Microsoft changes the requirement for the registry key.
4. While the majority of A/V vendors do now seem to support the update and have updated the key, some have not. And this leads to our NERC CIP question.
5. CIP-007 R2 requires the NERC entity to designate a patch source; it will often be the vendor of application software running on a BES Cyber System –and the BCS in question here will often be an HMI (human-machine interface). That vendor will approve Microsoft patches for installation with their product; if they don’t approve them, you won’t install them.
6. Often, the vendor will also require your organization to use a particular brand of A/V software. There are three cases to consider:
7. First, let’s say your HMI vendor requires you to use an A/V vendor that has set the registry key. In this case, you don’t have to worry – your Windows patches will continue uninterrupted, as long as you have applied the most recent A/V update before you apply the Microsoft update. There will obviously be no change in your CIP-007 R2 compliance status.
8. Second, let’s say the vendor requires you to use an A/V vendor that has not set the registry key, and you (or your organization) don’t want to set it yourself (I know I would certainly have issues with doing that on my own!). In this case, since Windows patches are likely to cause serious problems, the software vendor won’t approve any patches for release, until either a) Microsoft relaxes their policy or b) the HMI vendor decides to find a different A/V vendor, one that will set the registry key. Since the vendor is your patch source and they’re not releasing any Windows patches, you don’t have any obligation to install Windows patches (or even consider them as applicable) under CIP-007 R2.
9. Finally, let’s say your HMI vendor doesn’t require that you use any particular A/V software, and you chose an A/V vendor that has not now set the registry key. This is where the compliance question comes in. The HMI vendor will presumably continue to approve Windows patches and send them out, but you won’t be able to install them, unless you change your A/V vendor. If you can’t change your A/V vendor for some reason, what do you need to do to comply with CIP-007 R2?

I must admit that, when I started writing this post, it seemed to me this was a question that didn’t really have an answer. But now that I’ve written it, the answer seems fairly clear: Under CIP-007 R2.2, you would likely determine that this patch is applicable (after all, it was released by the vendor of your HMI). You of course can’t install it, so you need to develop and implement a mitigation plan for whatever vulnerabilities were addressed by the patch, per R2.3.

If you have any other ideas about this, I’d like to hear them. 

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 tom@tomalrich.com.

---

[i] A lot of this discussion is based on this article from Computerworld.

When and how can you receive Advice from your Region on your Plan?

I recently wrote a series of posts about “plan-based” requirements (e.g. CIP-010 R4 and CIP-013 R1) and raised two main questions about them. The first was whether they could be strictly audited using the standard NERC auditing framework (which is embodied in the Compliance Monitoring and Enforcement Plan, or CMEP). My answer to that question was that they are auditable to various degrees (depending on how they are written), but none of them are auditable in the strict sense that the prescriptive CIP requirements (like CIP-007 R2) or the Operations and Planning requirements (like FAC-003 R1) are auditable.

The second question was more important; I only delved into this question in the last post  in the series. This question is effectively[i] “Given that the real goal of auditing is promoting the reliability and security of the Bulk Electric System, is it possible that trying to audit plan-based requirements (which, as I’ve pointed out several times, are the wave of the future for NERC. In fact, all of the important new CIP requirements developed since CIP v5 have been plan-based) using the standard NERC auditing framework will actually hinder this goal?”

And my answer to that question was yes. In that post, I referenced a previous post  I had written on CIP-014 enforcement. CIP-014 was the first plan-based standard to be approved by NERC, and the NERC Regional Entities are already auditing it. In this post, I recounted a conversation I’d had with a CIP physical security compliance person at a very large utility, who had been rebuffed by his regional auditors when he asked them a question about whether a particular technology – that this entity proposed to implement in their substations subject to CIP-014 – would likely be determined to be appropriate to include in the Physical Security Plan required by CIP-014 R5.

He was flatly turned down when he asked this question, on the grounds that answering it would constitute a violation of the principle of auditor independence: If the auditors answered it for him now, when they came to audit him later (perhaps years later), they would in effect simply be auditing themselves. On the face of it, this seemed to be the only possible answer that the auditors could have given. But the unfortunate result of this was that the utility he worked for would most likely cancel their plans to implement this technology (which would cost $80 million to deploy to all of their CIP-014 substations).

In my post, I pointed out that this clearly seemed to be a case where the standard NERC audit framework was actually working against the goal of enhancing the physical security of the BES. I further hinted that, given the choice between maintaining that standard framework and securing the BES, I would choose the latter any day. I was thus preparing to suggest that the standard NERC auditing framework – which works very well for the NERC Operations and Planning standards, but not for the CIP standards, and especially the plan-based ones – be replaced with a new auditing program just for the CIP standards.

However, as has happened before, an auditor had written in to me about this issue, and in an email dialogue he pointed out that not only is it not necessary that there be a new auditing framework, but that the elements required to deal with this problem are already in place in at least two of the NERC Regions, and could be implemented in the other Regions as well. In the rest of this post, I won’t usually quote the auditor directly, but I will include his ideas, as well as my interpretation of them, without necessarily saying at every point whether they are his or my ideas. After I initially wrote this post, I sent it to the auditor to review for any mis-interpretations on my part, and he corrected those.

Before I discuss this further, I want to make sure we all understand what the big problem is. It is not that plan-based requirements are not very auditable (if they are auditable at all) under NERC’s CMEP; I’ve already stated that I consider auditability to be a distant second to the main concern. The main concern is the security of the BES, and the problem is that, as exemplified in the case I just discussed, that goal will not be aided if, for plan-based requirements, NERC entities can’t get their NERC Region to review their plan before they implement it. Additionally, when it comes to implementing the plan, the entities would be greatly helped if they could ask their Region to review the implementation while it’s in progress and point out potential problems. The case just discussed is an example of how auditing concerns can prevent NERC entities from getting the advice they need on complying with plan-based requirements. As we have just seen, this problem has already appeared for CIP-014, and it will appear in spades when FERC approves CIP-013 and entities start working seriously on their supply chain cyber security risk management plans.[ii]

In my opinion, here is what is needed to address this problem:

1. NERC entities, when faced with plan-based CIP requirements, will of course first have to develop the plan mandated by the requirement (the Physical Security Plan mandated by CIP-014 R5, the supply chain security plan mandated by CIP-013 R1, the Transient Cyber Asset/Removable Media plan mandated by CIP-010 R4, etc). In the process of developing the plan, they need to be able to ask their Region questions about what should be in the plan, what are best practices for mitigating the threats addressed by the plan, etc.[iii]
2. Once they have developed their plan, the entity needs to be able to take it to their Region and ask them to review it. The review won’t tell the entity whether the plan is “compliant” or not; rather, the reviewer will point out whether the plan doesn’t address any threats that should be addressed in the plan, and whether the mitigations proposed follow best practices as the Region understands them. If the entity can’t get this review, they will have to take a deep breath, hope the plan they’ve developed is one their region will think is good, and then implement the plan. The danger is that they may go a long way down the road to implementation (or even finish it) before their next CIP audit, and that the auditors will then tell them the plan had a lot of problems and needs to be redone. Of course, that could possibly lead to a lot, or even most, of the work the entity has done implementing the plan needing to be re-done as well.
3. If the Region does the review and sees problems with the plan, they will point those out to the entity. At that point, the entity could elect to re-work the plan to fix the problems, or else to dismiss the Region’s advice if they think it isn’t well-founded for some reason.
4. If the entity did re-work their plan, they would be well-advised to ask for a new review from the Region, to make sure they have addressed whatever objections the Region brought up.[iv]
5. Once the entity was satisfied that it had a good plan, it would start implementing it. However, at any point during the implementation, the entity could request of their Region that they review the entity’s implementation work so far, and let them know of any developing problems they see (e.g. that the entity isn’t implementing everything in the plan, or that they are implementing parts of it badly).
6. If the Region does point out problems with the implementation, the entity has the choice either to try to address these problems or to dismiss them if they don’t think they actually are problems that need to be fixed – just as in the case of the plan review.

In reading this, you may have already thought of the objection that first came into my mind when I realized these steps would be required in order for the entity to be sure they had a good plan (and that they were implementing it correctly): How would it be possible for the Region to provide these services to the entity, then turn around and audit them later without having their auditor independence completely compromised?

The key to resolving this question is that the Region will need to have what is known as an Entity Development program in place; currently, one Region does have such a program, and I was told another Region is now putting one in place. The point of this program is for the Region to have a formal way of providing advice, like the above, to entities outside of an actual audit[v]. In general the staff members for this program will be separate from the auditors, although the auditor pointed out to me that it isn’t impossible for the CIP auditors to also provide Entity Development services, assuming the entities trust them not to mix the two functions.

One absolute requirement for the Entity Development staff is that they be knowledgeable in the subject matter of the plans they are providing advice on – for example, if they are providing advice on the Physical Security Plan in CIP-014, they need to understand physical security for substations. Of course, this requirement isn’t something to be taken lightly, since such people – with electric utility experience – may be hard to find. So putting together this staff may be a multi-year process.

While the Entity Development staff will in theory just be providing best practices-type information to the entity, it is likely that they will sometimes, in the process of reviewing an entity’s plan, discover some element of non-compliance. When this happens, they will point this out to the entity, but they won’t be able to provide advice on what the entity should do to remediate this non-compliance; that would probably compromise auditor independence.

Of course, the Entity Development staff wouldn’t report these instances of possible non-compliance to the auditors, and the report wouldn’t become part of the record for the entity’s next audit. However, when receiving a report like this from Entity Development, the entity that requested the plan review will need to decide whether to self-report a violation; and if they do self-report, they need to also “discover the scope and extent of the non-compliance” (to use the auditor’s words), as well as mitigate the non-compliance[vi].

If the entity does self-report, and the issue that was the subject of the report is discovered as part of the next audit, the entity won’t be subject to a Potential Non-Compliance (PNC) finding for the same issue, covering the same time period that was self-reported. Of course, if the entity doesn’t self-report and the potential violation is discovered, the entity would be subject to a PNC, which of course will be more serious since it was discovered at audit.

The auditor did also point out that there is a way that the Region can provide advice on whether a plan is likely to be found compliant or not, but they can only do this during the period before a standard becomes enforceable. If the entity develops their plan and specifically asks the Region for a “readiness assessment” of the plan, then, depending on available time and resources, Regional staff (either auditors themselves or Entity Development staff) can perform, to quote the auditor, “a non-binding, no risk, no consequence ‘audit’” of the requirement for developing the plan.[vii]

For example, suppose your entity wishes to have your Region review your CIP-013 supply chain cyber security risk management plan before the CIP-013 compliance date (which I am currently expecting to be toward the end of 2019, assuming FERC approves CIP-013 this spring). You would of course have to first develop the plan (and this would have to be done well before the compliance date), then request a readiness assessment of your compliance with CIP-013 R1.

Of course, developing your CIP-013 plan in the first place will require having some idea of what should be in the plan. There is the 13-page Implementation Guidance produced by the CIP-013 drafting team; this is a very good document as far as it goes, but it is nowhere near a comprehensive guide to developing the plan. There will also be more guidance coming from other sources (including specifically the North American Transmission Forum, although I’m not sure that will be available to non-members), and NERC is now considering a CIP-013 “Transition Study” similar to the one for CIP v5. In this study, a small number of early adopters will share their experience with NERC, to help them develop Lessons Learned (remember those?) and other guidance.

And there will be another source of guidance: I have been thinking about what should be in the CIP-013 plan and discussing this with an auditor, and I plan to write a series of posts (probably not consecutive posts, of course) about this question. Unlike the NATF, I’m not on NERC’s list of approved guidance providers, so you’ll of course have to take whatever I say with a grain of salt (but in fact the same applies to the approved providers like NATF, since NERC specifically says that no guidance these approved providers turn out they will itself be “approved” by NERC). But I hope you’ll find my posts on this subject to be helpful, and I’ll welcome any feedback you have on them.

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 tom@tomalrich.com.

---

[i] I say “effectively” because I now have a better way of wording the question than I did when I wrote that post.

[ii] This is because the requirements in CIP-013 provide very little “guidance” on what should be in a good supply chain security plan, even less so than the guidance that CIP-014 R5 provides to guide entities in developing their physical security plans.

[iii] Of course there is, and will be, guidance provided on these questions by various industry organizations. However, the guidance NERC provides will be very limited due to NERC’s limited interpretation of what guidance they are allowed to provide. NERC entities will need to weigh all the guidance they find, but in the end what will count most for them is what their Region says. This is the way it has been since CIP version 1, although this trend intensified with CIP v5.

[iv] It bears repeating that the Region’s review of the plan won’t be for the purpose of saying whether it is compliant with the requirement or not, but only a) whether all of the threats that should be mitigated in the plan are in fact addressed; and b) whether the proposed threat mitigations actually follow best practices. It is possible that whoever reviews the plan will notice something in the plan that is non-compliant and will point this out to the entity; it would then be up to the entity to decide whether they want to revise their plan to address this concern, or whether they think the observation is mistaken for some reason. In any case, the observation made by the Region wouldn’t become part of the audit record, and wouldn’t be passed to the auditors when the entity was next audited.

[v] The auditors have always been able to point out Areas of Concern covering cyber security practices that aren’t within the scope of CIP, when they notice something regarding the entity’s practices during the course of an audit. But there has never been an official way for them to provide such advice outside of an audit – and, as I pointed out earlier, an audit will often come a year or two after the entity has started implementing their plan. It will be much better if the plan can be reviewed as soon as it is developed.

[vi] The auditor did explicitly warn against what might be a temptation: agreeing with the opinion that your plan was non-compliant in some way and fixing whatever the problem was, but then still not self-reporting the issue. While it is true that the friendly advice of possible non-compliance that you receive from Entity Development will not in any way be reported to the auditors (and even if it were, they would ignore it), it is still very likely the auditors will discover that at a certain point your documentation changed, from reflecting the old non-compliant wording in the plan to reflecting the new compliant wording. Of course, the penalty for non-compliance discovered in an audit is likely to be much more severe than for a self-report.

[vii] Of course, the readiness assessments are nothing new. The Regions conducted a number of these during the run-up to the CIP v5 enforcement date. They were very helpful, both to the entities that received them and to the auditors that conducted them. However, the auditor did caution that there is no way that the readiness assessment will be able to issue an opinion that the plan seems to be compliant. The team will point out gaps in compliance and recommend steps for remediation; after that, the entity is on its own to determine what it should do with the information.