FERC’s NERC CIP Notice of Inquiry Part I
- Aug 10, 2020 4:01 pm GMTAug 10, 2020 3:41 pm GMT
- 769 views
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 firstname.lastname@example.org.
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.