The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 


You need to be a member of Energy Central to access some features and content. Please or register to continue.


FERC’s NERC CIP Notice of Inquiry Part I

I’ve been intending to provide my opinions on FERC’s recent Notice of Inquiry regarding possible changes to the NERC CIP standards. Today, Dale Peterson, founder of Digital Bond and the S4 conference, gave me a nudge by posting his own comments on LinkedIn. Dale essentially said about half (really more than that!) of what I was going to say about the NOI, although we have some differences that I’d like to explain. The second part of this post will discuss my other observations on the NOI.

In the third paragraph of the NOI, FERC discusses the NIST Cyber Security Framework (CSF). They point out that there are three sections of the CSF that they think aren’t adequately addressed in the current CIP standards:  “(i) cybersecurity risks pertaining to data security, (ii) detection of anomalies and events, and (iii) mitigation of cybersecurity events.” FERC proceeds to examine each of these areas in detail, and to point out particular risks within each of these three areas that they say aren’t adequately addressed in the current CIP standards. They then ask for comment from the industry on a) whether they agree that these are deficiencies and b) whether these deficiencies in fact pose risk to the Bulk Electric System.

The problem with FERC’s approach to the CSF is it doesn’t look at what the CSF is, and how it differs so much from the current CIP standards. A framework is very different from a set of mandatory prescriptive standards, which is what the CIP standards are for the most part (CIP-013 being one exception to that statement). Frameworks deliberately look collectively at the whole universe of risks (in the case of the CSF, it’s cybersecurity risks to critical infrastructure), and try to be as comprehensive as possible. That is, they don’t consider risk in deciding what areas of risk they will address in the framework – they include every area of risk that might possibly be important.

The whole idea of a framework is that the entity that follows it will assess each area and decide what degree of risk that area poses to their organization. They will then allocate their mitigation resources to the areas that pose the greatest risk, and either ignore or devote minimal resources to areas that don’t pose much risk to them.

On the other hand, a set of mostly prescriptive requirements like NERC CIP doesn’t give the entity any option for how they allocate mitigation resources between different areas of risk, or even within one area of risk. For example, a NERC entity can’t tell their CIP auditor they think that in general, requiring that they check every 35 days, for every software package – and every version of every software package – in their ESP, to determine whether or not there is a new security patch available is a misallocation of resources.

The entity might reason that there are undoubtedly some software products that rarely if ever have security patches issued. For these, checking every 3-6 months might be a fine interval. There are also some software products like EMS where 35 days is arguably too long an interval – they should really check say every 15 days for that. If the entity asks the auditor whether it would be a reasonable practice to decide the interval based on risk, the auditor will probably agree that yes indeed this is reasonable – while they’re writing out the Potential non-Compliance notice. Something may be reasonable, but when it comes to prescriptive standards, that makes no difference. If the standard says every 35 days for every piece of software, the entity has to do that; anything else is a violation.

And if the entity thinks that the CIP standards cause them to over-allocate mitigation resources between different areas of risk (rather than within one area, as in the above example) – so that the could use those resources much more effectively if they could decide for themselves whether or not say checking every 35 days for new patches for all software was more important than auditing their in-house-developed software for vulnerabilities (which isn’t required by CIP at all now) - they’re also out of luck. Every requirement in CIP needs to be fully complied with, no matter what opinion the entity might have as to whether or not the risk addressed by one requirement is more important than that addressed by another.

Dale provides a great example of this point, although he used it in a somewhat different context: “I doubt you would want to spend…time making sure every running service and every listening port on a large number of cyber assets is documented correctly. Especially since "CIP needed" ports and services by the system are often all the attacker needs. You likely would want to look closely at what is allowed through the security perimeter and the RTO and recovery tests that verify the RTO can be met.”

I believe Dale is implicitly saying that he thinks a lot of the effort expended on compliance with CIP-005 R1.3 – the “ports and services” requirement – is wasted, compared to what could be achieved by examining (perhaps with a layer 7 firewall?) all traffic that enters the ESP for malicious content, as well as verifying that a recovery time objective can be met for applications that might be brought down in an attack. In other words, Dale thinks R1.3 could be rewritten or even removed, and two new requirements (or requirement parts) should be developed to address the two more important issues that aren’t addressed at all in CIP currently.

These kinds of risk-based decisions are easily handled when following a framework like CSF. However, FERC isn’t really looking at the CSF as a framework, where the entity uses risk to guide their mitigation decisions; they’re looking at the CSF as a source of potential prescriptive requirements (this is what the GAO did in their 2019 report, and FERC refers to that in the NOI). In FERC’s and the GAO’s thinking, if an area of risk is included in the framework, it needs to be considered for new prescriptive requirements. But why stop there? Why not add Dale’s two suggestions as well, since I don’t believe either of them falls under the three areas that FERC identified. And I’m sure we could all think of other requirements to add on top of these.

However, the window for adding new prescriptive NERC CIP requirements closed a long time ago. The last time a CIP standard drafting team developed a new prescriptive CIP requirement was during the development of CIP version 5, which concluded with final balloting in 2012. Since then, every new CIP requirement or standard has been non-prescriptive and risk-based (even though some of them don’t actually mention risk). This includes CIP-010 R4, CIP-003 R2, CIP-014 and of course CIP-013 (plus CIP-012 is definitely risk-based as well). And the biggest driver of this change has been FERC itself, which has ordered – at least for CIP-013 and CIP-014 - that the new standards not be “one-size-fits-all”, which means they should be risk-based.

Does this mean that FERC should require NERC to add three new requirements or standards to address the three NIST CSF areas that they identified as missing, but they need to also order they be risk-based? Well, the individual requirements or standards do need to be risk-based, but that’s not enough. Before we add even more CIP standards and requirements, all of the prescriptive requirements need to be rewritten as risk based. And then there needs to be some overall framework to let the NERC entity decide how best to allocate their resources among the different areas of risk, while at the same time achieving some basic level of security (e.g. an entity wouldn’t be allowed to say only check for new patches once a year. There would be guidelines to help the entity avoid mistakes like that).

Dale concludes his post by saying "NERC CIP, or any regulation, should not define and test an entire 'good practice' cybersecurity program. This is highly inefficient and has diverted resources from actually improving cybersecurity in the BES. The audit should verify that a cybersecurity program exists, it is being followed, and it has the most important controls, from a risk reduction standpoint, in place through sample audits."

"The NIST CSF could be used. There could be a requirement for a utility to have a Current Profile, a Target Profile and an action plan with dates to close the gaps. The existence of and compliance with these documents is easily audited in a similar way we audit secure development lifecycles (SDL). Most vendors have a SDL that they can show you, and you can ask for evidence the SDL must create for a development project and quickly determine if it is actually followed or not without being a developer."

Dale and I agree that the current primarily prescriptive set of NERC CIP requirements needs to go. Dale’s proposal about requiring the utility to gradually close gaps between their current profile and their target profile is a very good suggestion for replacing it, but I think that would require a wholesale revision of the whole NERC program for monitoring compliance with the CIP standards. I think a more realistic near-term replacement is to essentially make every standard or requirement like CIP-013: it requires entities to “identify, assess and mitigate” (although the word mitigate was left out, as I discussed in a series of posts including this one) BES supply chain cyber security risks. There could also be requirements to identify, assess and mitigate risks due to unpatched software vulnerabilities, risks due to inadequate access control, etc. While I think there will definitely be auditing problems with CIP-013 (perhaps like some of those that arose with CIP-014), I do think it can be audited without having to change NERC’s Compliance Monitoring and Enforcement program, which isn’t in the cards at the moment.

On the other hand, just rewriting the CIP standards like I’m proposing is going to be a major step. Maybe it’s just as well to do it all at once. In any case, Dale and I agree that a major change is needed. And that FERC’s idea of essentially adding more individual requirements and standards (even if they’re risk based) is simply the wrong approach.


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

Are you hot at work – or should be – on getting ready for CIP-013-1 compliance on October 1? Here is my summary of what you need to do between now and then.


Tom Alrich's picture

Thank Tom for the Post!

Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.


Matt Chester's picture
Matt Chester on Aug 10, 2020 4:27 pm GMT

Stepping back a bit-- I'm curious what you think the difference would be in how the industry and regulators would be approaching this if the issues were taken more seriously earlier on? Are some of the potential missteps and debates a result of having to play catchup faster than we could have? 

Tom Alrich's picture
Tom Alrich on Aug 10, 2020 4:59 pm GMT

I'm as much to blame for this situation as anybody else. I attended and participated in many of the CIP version 5 drafting team meetings in 2010 to 2012, when the current approach was put in place. I did have some inklings of this problem, and engaged in a few debates with the chairman of the SDT about them. But I later focused on CIP version 4, when FERC suddenly approved that in 2012. V4 never came into being, but for a year I didn't pay much attention to v5. It was only after FERC said they'd approve v5 in April 2013 that I once again started looking at v5, and I began to realize some of the serious problems in it.

But even then, I didn't realize that what was required was a risk-based approach. I've only started realizing that in the last few years. In fact, it was only when Dale Peterson asked me to speak at the S2 conference in 2016 - and asked me to explain how I would rewrite CIP if given the chance - that I actually started talking about something like what I now am. And there is now one CIP standard that is entirely risk-based: CIP-013, the supply chain standard that comes into effect on Oct. 1. That's not perfect, but it's a big step in the right direction.

Matt Chester's picture
Matt Chester on Aug 10, 2020 9:01 pm GMT

Thanks for sharing that Tom-- it's fascinating to really get an insight into the processes behind how these codes are written, what might go right and wrong, and figure out how to optimize those processes in the future. Hopefully we're now on the right pathway, and even more hopefully it's not too little too late!

Jim Stack's picture
Jim Stack on Aug 12, 2020 12:29 pm GMT

Tom,  Thanks for sharing they FERC is working on the cyber secirity isdue at all. The pubic does get to hear about what is being done at all but security failures seem to be in the new more each year. I would home each power company is working on this issue and not waiting for FERC. 

    I  am very disappointed in FERC on the Net-metering rules  for Solar PV which I feel have been their duty yet they have no national standard. It could really help if they had national rule like Germany seems to have. Is there a reason they seem so slow and lack clear standards on many issues?

Tom Alrich's picture
Tom Alrich on Aug 12, 2020 7:13 pm GMT

Thanks, Jim. I don't know the answer to your question, but I'm guessing this might be related to the fact that FERC's authority doesn't cover the whole power grid, but only the Bulk Power System - which essentially means interstate power transmission and large generation. Everything else is the jurisdiction of the state Public Utility Commissions, and net metering strikes me as something that really falls under them.

Caleb Christopher's picture
Caleb Christopher on Aug 12, 2020 4:17 pm GMT

This was a very informative read. Thank you.

Tom Alrich's picture
Tom Alrich on Aug 12, 2020 7:14 pm GMT

You're welcome, Caleb!

Get Published - Build a Following

The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »