Will NERC have to audit the CSPs?

 

The NERC Standards Drafting Team that is working on what I call the “cloud CIP” problem seems to be making progress on CIP-016. This is a new standard that will include requirements that “apply” to the cloud service providers (CSPs) – although compliance responsibility will fall on the NERC entity, of course. When CIP-016 comes into effect (which I continue to believe will be 2031, give or take a year), most of the existing CIP standards will be changed in some way as well.

I believe we’re at least 4-5 years away from having all the required changes to the CIP standards (and also to the NERC Rules of Procedure – see below) drafted, balloted (multiple times) and approved by NERC and FERC. Thus, it’s too early to be overly concerned about the details of the new CIP requirements that are being discussed today. However, I’m pleased to see that the SDT is at least starting to debate draft requirements, since doing that will lead them into confronting the big issues they will need to settle before they can even think of drafting the final requirements.

One of the biggest of those issues is that of requirements that apply to the CSPs. In this regard, the SDT is facing a situation almost exactly like the one faced by the SDT that drafted what became CIP-013-1. That SDT knew that the new standard should require good cyber behavior on the part of third-party suppliers of BES Cyber Systems, but at the same time they knew that neither NERC nor FERC has any jurisdiction over those suppliers; any new requirements would have to apply to the NERC entities themselves.

However, they also knew that FERC had made clear in their order that the new standard couldn’t dictate contract terms to NERC entities. So, how were they going to require the entities to ensure their suppliers put in place adequate cybersecurity protections?

FERC had said they didn’t want NERC to develop “one size fits all” requirements that take no account of the individual situation of either the NERC entity or the supplier. While FERC didn’t explicitly use the word “risk-based”, they were clearly asking NERC to develop risk-based[i] requirements.

This is the course the CIP-013 SDT took; in fact, they took it to a fault. CIP-013-1 R1 Part R1.1 required the NERC entity to develop a “supply chain cyber security risk management plan” (SCCSRMP, although that acronym never caught on) that included “process(es) 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…procuring and installing vendor equipment and software…”

In other words, CIP-013-1 left it to the NERC entity to “identify and assess” risks posed by each supplier of BCS; left unsaid, but certainly intended, was the implicit requirement to work with the supplier to remediate any risks revealed by the entity’s assessment (e.g., in the supplier’s answers to the questions in a questionnaire).

However, one of the big problems with CIP-013 was that R1.1 didn’t provide any suggestion of what areas of supplier risk might be addressed in the SCCSRMP - the risk of compromise due to improper identity and access management controls, the risk of compromise due to inadequate remote access security, etc. As a result, I hear that a large percentage of NERC entities (with high or medium impact BES environments) simply considered the six items in CIP-013-1 Requirement R1 Part R1.2 to be indicators of the only risks that needed to be addressed in CIP-013; while those six items certainly address real risks, they were never intended to be the only ones the entity should be concerned about.

By contrast, the Cloud CIP SDT seems to be writing requirements for the CSPs directly. Of course, they understand that compliance with the requirements needs to be the responsibility of the NERC entity; however, it won’t be hard to rewrite the requirements so that the entity is responsible for making sure their CSP follows them. It seems that the requirements they’re developing now aren’t risk-based, but they are objective-based (which is NERC’s preferred term). Since you can’t achieve an objective without taking account of risk, I consider the two terms to be roughly equivalent.

The requirements seem to be written under the assumption that each NERC entity will need to negotiate with its CSP (by which I mean their platform CSP – i.e., one of the big boys) regarding what evidence they will provide to the entity come audit time. However, it’s highly unlikely that the platform CSPs will be willing to negotiate with individual NERC entities. After all, their business model is based on offering the same hamburger to every customer, not having a discussion with each one about what they want on it.

On the other hand, if the CSPs are going to have to “comply” with the requirements in CIP-016, there will need to be some compliance assessment process for them. It probably won’t be a true audit, but it will be a review of evidence of compliance with each requirement. However, it’s very likely that each platform CSP will demand to be audited by just one organization, not 100.

This is why I’ve already said that I see no alternative to having NERC (or a third party engaged by NERC) conduct an audit of each CSP on behalf of all NERC entities. Of course, the audit will just cover whatever CIP standard(s) specifically targets CSPs (the current CIP standards will hopefully survive virtually unchanged, but for on premises systems only). NERC will gather all the evidence from each CSP and make sure it’s complete and relevant, but they won’t pass judgment on whether the CSP is in compliance with each requirement.

Instead, NERC will pass the evidence from each CSP to entities who utilize that CSP for their medium or high impact BES systems. It will be up to each NERC entity to determine whether their CSP has complied with each of the requirements; if they determine their CSP has not complied with more than a few requirements, it will be up to them to decide whether, and under what conditions, they will continue to utilize that CSP.

For example, if a CSP has multiple deficiencies, the entity will need to decide whether to a) switch to another CSP, b) continue with this CSP but try to work with them to mitigate the deficiencies, or c) ignore the deficiencies entirely and keep utilizing the CSP. All three of these options are acceptable courses of action for a NERC entity, but they will need to justify their decision to the CIP auditors.

Most importantly, NERC will not issue (or deny) a certification for a CSP based on their audit results. If NERC did that, it would most likely be a violation of antitrust law. More importantly, the decision whether to use, or to continue using, a CSP will always be subject to many factors that are specific to the NERC entity. There is no way that NERC or any other organization could make the decision for a NERC entity whether to contract with a particular CSP.

Therefore, I think it is very likely that the SDT will conclude at some point (although it might take them 1-2 years to get there) that NERC will have to conduct the audits of the platform CSPs. However, there’s one huge fly in this ointment: This whole process is almost certainly not allowed (either explicitly or implicitly) by the current NERC Rules of Procedure. This means the RoP will need to be revised before the new or revised Cloud CIP standards come into effect.

What’s the process for changing the Rules of Procedure? If there is a defined process, it must be in the Rules of Procedure now. And if there isn’t a defined process, it will likely have to be drafted and approved (by both NERC and FERC) and inserted in the RoP; only then will it be possible to follow the new process and make whatever changes are required to permit NERC to audit the CSPs.  Of course, that change will also have to be approved by both NERC and FERC.

All of this is to say that granting NERC the authority to audit the CSPs will most likely require multiple years (two at a minimum, but perhaps three to four); this is why I think that 2031 is, if anything, an overly optimistic estimate of when the Cloud CIP standards will be enforced.[ii]

Since it’s likely that the Rules of Procedure changes will need to be dealt with by some other group within NERC (such as an RoP drafting team?), it would speed up the whole process if the RoP changes were pursued at the same time as the changes in the CIP standards. However, I don’t believe anyone is even discussing RoP changes now, so we can’t count on that happening. This is why I continue to believe that, barring a special intervention by the NERC Board, it will be 5-6 years at least before the “Cloud CIP” standards are implemented.

My blog is more popular than ever, but I need more than popularity to keep it going. I’ve been told I should either accept advertising or charge a subscription fee, or both. However, neither of those options appeals to me. It would be great if everyone who appreciates my posts could donate a $20-$25 “subscription fee” once a year (of course, I welcome larger amounts as well!). Will you do that today?

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] NERC’s term for risk-based is “objectives based”. I think they’re effectively the same thing, since it’s impossible to achieve any objective without taking risk into account.

[ii] This includes an estimate of at least one year for FERC to approve the new or revised standards, plus an implementation period of more than one year. These are in addition to at least two years for the SDT to draft, ballot, respond to comments, and revise the standards; that whole cycle will most likely need to be repeated three times after the first ballot, as it has with all major changes in CIP in the past. At a bare minimum, each cycle will take three months.

I will point out that there is some likelihood that pressure will build on NERC to exercise an “in case of emergency, break glass” provision now included in the Rules of Procedure. This allows the Board of Trustees, in an emergency, to order an expedited process to develop new standard(s) that will bypass the normal process. Since there’s currently not even any discussion about doing this, it’s safe to say that even this scenario will result in multiple years passing before full cloud use by NERC entities for their OT environments is permitted by the CIP Reliability Standards.