CIP-013 R3

I intend to start writing a lot about CIP-013 in the coming few months. There are two reasons for this:

First, the standard has recently made great strides toward coming into effect. With the third and final ballot passing, the chances are just about 100% that the NERC Board of Trustees will approve CIP-013 (and CIP-005-6 and CIP-010-3) this month. This will then go to FERC. A day ago, I would have pointed out sarcastically that FERC doesn’t have a quorum and may not for a while, so it’s questionable whether the standard will be returned to NERC with the notice “Nobody at this address”.

However, just a couple hours ago the US Senate confirmed two new Commissioners, meaning that soon FERC will have a quorum. Given the huge backlog that FERC has (including CIP-003-7, which includes the revised “LERC” requirement), I’m betting it may take up to a year for them to approve CIP-013. And there’s still a small chance they will simply remand it to NERC (or even kill Order 829 altogether). But my guess is they will approve it.

Second, CIP-013 is a very interesting standard. Complying with it is completely different from complying with any of the previous CIP standards; in fact, it’s completely different from any previous NERC standard (although CIP-014 comes closest to it). The good news is that it is (almost) entirely an objectives-based standard, which is what I (and many others) have been saying for some time is how all of the CIP standards should be written (there are some objectives-based requirements in the existing CIP standards, like CIP-007 R3 and CIP-010 R4. But none of the standards themselves are objectives-based. This fact is actually quite significant, as I’ll explain in later posts). This means that compliance with the standard is much more like what your organization would do if you were mandated by your organization to address cyber risks in your supply chain, and given a healthy pot of resources to do it with: You would rank the threats by the degree of risk they pose, and allocate your funds for remediation on that basis.

That was the good news. The bad news is that auditing CIP-013 is also very different, and the auditors are still going to have to follow all the provisions in NERC’s Compliance Monitoring Enforcement Program (CMEP) and Rules of Procedure; these two documents are completely focused on prescriptive, non-risk based standards.[i] So it’s very much an open question whether the auditors will be able to completely change their style of auditing, while still paying obeisance to those two documents.

In any case, I will be writing a lot about CIP-013, and here’s the first in this series. What I want to discuss now is – as those of you who are super-alert may have noticed from the title – CIP-013 Requirement 3. If all you do is read the requirement as it stands in the final draft of CIP-013, you might be excused for thinking it’s fairly innocuous. It reads “Each Responsible Entity shall review and obtain CIP Senior Manager or delegate approval of its supply chain cyber security risk management plan(s) specified in Requirement R1 at least once every 15 calendar months.”

You might think, “Hey, this one’s a piece of cake. All I have to do is stand outside some suit’s door for five minutes once every 15 months to get them to sign a piece of paper. I wish everything else in CIP were this easy.” But you’re wrong about that. This requirement just reveals the tip of the iceberg. To understand why, I’ll quote the first draft of CIP-013 (you remember that? The one that got about nine percent approval?), where this is requirement 2, not 3:

“R2. Each Responsible Entity shall review and update, as necessary, its supply chain cyber security risk management plan(s) specified in Requirement R1 at least once every 15 calendar months, which shall include:

2.1. Evaluation of revisions, if any, to address applicable new supply chain security risks and mitigation measures; and

2.2. Obtaining CIP Senior Manager or delegate approval.”

As you can see, the only real difference between the two drafts is part 2.1 in the first draft. Let’s unpack what it says:

1. There may be new supply chain security risks and mitigation measures that have appeared since your plan was last approved.
2. You need to consider these – and my guess is auditors will want some sort of assurance that you at least considered all new risks and mitigation measures, in some way or another. They won’t let you get away with saying you considered just every other threat, or just all those threats that begin with letters A through G. There isn’t really a good way to limit what you have to consider.
3. If you find any new threats or mitigation measures (and guess what? In the world of cyber security, there are new threats all the time. Fortunately, there are new mitigation measures all the time as well), you would be well advised to modify your plan to address them.
4. And since you’re not treating all the vendors and systems the same (remember, this is a risk based standard?), you really need to look – at least in principle - at how these new threats and mitigation measures apply to each BCS you purchase - or each piece of software that goes on a BCS – as well as to each vendor you purchase these from.

Does this strike any of you as a lot of work? Some people who voted no on the first ballot commented that this is really an open-ended commitment. How many news articles, blog posts, vendor notices, threat intel feeds, Tweets, etc. do you need to peruse in order to be able to say that you have at least considered all threats and mitigation measures?

You may ask me, “Why are you bringing this up? After all, the first draft of CIP-013 was voted down; what finally passed (the third draft) says nothing about addressing new risks or mitigation measures.” And I will agree with you that this directive is no longer in CIP-013 R3. However, it’s not really gone. And to find that out, you need to look no further than the Implementation Guidance written by the SDT (and here I’m quoting from the revised version that was recently circulated by the SDT – page 9, in the discussion of R3):

“A team of subject matter experts from across the organization representing appropriate business operations, security architecture, information communications and technology, supply chain, compliance, legal, etc. reviews the supply chain cyber security risk management plan at least once every 15 calendar months to reassess for any changes needed. Sources of information for changes include, but are not limited to:

Requirements or guidelines from regulatory agencies

Industry best practices and guidance that improve supply chain cyber security risk management controls (e.g. NERC, DOE, DHS, ICS-CERT, Canadian Cyber Incident Response Center (CCIRC), and NIST).

Mitigating controls to address new and emerging supply chain-related cyber security concerns and vulnerabilities

Internal organizational continuous improvement feedback regarding identified deficiencies, opportunities for improvement, and lessons learned.”

Doesn’t this look a lot like the SDT is saying you still need to do what was in Section 2.1 of R2 in the first draft? I’ll answer that question for you (since I didn’t hear anybody say anything): Yes, it does. You might then ask, “Well, how can they remove part of a requirement from one draft to the next, but still say in their guidance that you need to effectively comply with the first draft?” I really don’t know what to say to that, except “They did it.”

And I wouldn’t suggest that you tell your auditor that you're ignoring what is in the Implementation Guidance, since in this case it goes beyond what the requirement says. Yes, I know that no NERC guidance is supposed to go beyond what the strict wording of the requirement says – that’s perfectly true. But it also may be perfectly true that your auditor’s baby is ugly, and I don’t recommend you tell him that either.

To be honest (every now and then I try to be honest. It’s a good exercise), I think this requirement is a step toward addressing one of the biggest problems with the current CIP standards: the only way they can be made to address new threats is by someone writing a SAR (which gets approved by NERC and FERC), a drafting team being constituted, a new standard or requirement being drafted, several NERC ballots, NERC BoT approval, and finally FERC approval. This process always takes years, and I’ll be writing in a new post shortly that I’m now convinced there will never be any new additions to the CIP standards unless FERC explicitly orders them (Note from Tom 12/2/2019: I never wrote this post, but I continue to believe this is the case). In other words, the threats currently not addressed by CIP, including phishing, ransomware, cloud-based threats and more, will never be addressed unless FERC issues a new order (and given the political makeup of the new FERC, it’s not likely these Commissioners will be eagerly looking for new ways to extend any regulations).

So the fact that the SDT decided (with prodding from FERC) to provide some mechanism for addressing new threats to supply chain security on an ongoing basis is a good thing. What’s not a good thing is this: Why should each NERC entity have to go through the same set of blog posts, news articles, etc. to find out if there are any new supply chain security threats or mitigation measures? Why not have an industry body which does that regularly, and provides the information to all NERC entities?[ii]

The answer is this: There is no mechanism in the NERC Rules of Procedure or CMEP to have such a body. Think about it: This body would essentially be writing new CIP requirements, since entities would have to address these new threats in some way. And the current NERC operating environment allows no way to officially incorporate new threats into CIP, within any period much less than 3 years.[iii]

And this leads me to my final question: What would need to change in order for CIP to be able to quickly address new threats? Obviously, the existing standards would have to be changed, but more importantly the whole NERC standards environment would need to be changed as well. That is, there would need to be a new CMEP (and perhaps a new RoP), or at least a new CMEP that only applies to cybersecurity standards. That way, there could be a body that could continually examine new threats, and add important ones to a list of threats that must be addressed by NERC entities subject to CIP.

This would require NERC to make a huge change. Could they do this? Of course they could. Are they likely to do this? I’d say probably not. So does this mean things will stay as they are forever? Yes it does, until either a) NERC decides to change or b) NERC (and probably FERC) no longer have responsibility for the cyber security of the electric power industry. Currently, I’d say these are about equally probable. What isn’t probable at all is that this situation – the fact that the CIP standards have no effective way to be updated to incorporate new threats – will be allowed to stay in place forever. I believe Congress will ultimately step in if NERC doesn’t do anything about this, and they'll find another organization - perhaps DoE itself (and I know FERC is part of DoE. But there's a lot more to DoE than FERC!) - that will do something about it.

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

---

[i] And before you point out to me that the Reliability Assurance Initiative – now called Risk-Based CMEP – takes risk into account, I want to point out that the risk that RAI deals with is compliance risk – i.e. the risk that your organization won’t comply with a particular requirement. A risk-based standard is one in which the entity is allowed to align their controls with the risk posed by a particular threat – e.g. the risk that Vendor A’s patches will introduce malware into your system, vs the risk that Vendor B’s patches will do so. The requirements in CIP-013 allow that, whereas most of the other CIP requirements don’t.

[ii] Of course, the E-ISAC provides information on new technical threats, but there are a lot more threats that aren’t technical ones, plus new mitigation measures just aren’t in their bailiwick.

[iii] I know there are NERC Alerts, which try to do at least something when a new threat appears – as in the case of the Ukraine attacks. But these don’t mandate anything but a report on what the entity is doing about the new threat. While I’m sure most entities will take action on the alert, they don’t mandate the entity do something, as a new CIP requirement would.