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.