How can certifications be used in the “Cloud CIP” standards?

Note from Tom:

I have moved from Blogspot to Substack as the main platform for my blog. Because of my long relationship with Energy Central, I will continue to publish my new posts that have to do with the electric power industry (including my posts on NERC CIP) on EC for free. However, if you want to see all my other new posts (including posts about AI, the cloud, and developments with vulnerability management and vulnerability databases), you need to become a paid subscriber.

A charge of $30 per year (or $5 for one month) gets you a subscription to all my new posts on Substack, as well as 1200+ legacy posts that go back to 2013 (when I started my blog). Close to half of those posts deal with NERC CIP. Please start reading me on both Substack and Energy Central!

This week, we had the first meeting of what I’m calling the “CIP Cloud Risks Working Group”. I described this group in the italicized paragraphs at the end of this post. We had a great discussion – the meeting was scheduled for an hour, but we went on for two hours and could easily have gone on longer than that, if people could have stayed. We plan to meet biweekly from now on, although we haven’t decided on the meeting time yet. If you would like to join us, please email me. The cost to join is $0.00, payable by PayPal or Zelle.

It was a good meeting because we got to some really fundamental issues that need to be addressed before we can start to discuss our main topic: threats to the Bulk Electric System that will arise when systems associated with high and medium impact BES assets can make full use of the cloud (systems associated with low impact assets can already make full use of the cloud without having to worry about CIP compliance – although that’s a well-kept secret today).

One of the topics we discussed was the possible role of cybersecurity certifications like ISO 27001 in what I call the “Cloud CIP” standards (i.e., the standards that the current Risk Management for Third-Party Cloud Services Standards Drafting Team, or SDT, is starting to develop). Of course, nobody should utilize a cloud service provider that doesn’t have at least one or two of these certifications. In fact, a lot of people ask, “Why don’t we allow NERC entities to utilize any service offered by a CSP that is certified for ISO 27001 (or perhaps another cybersecurity standard)? Then there won’t be a need for any other CIP requirements, since it’s a sure bet that all the CIP requirements are addressed, at least in some way, in 27001.”

However, there are three reasons why doing this would be a bad idea. The most important reason is that taking this step would completely eliminate the burden of CIP compliance from NERC entities. In principle, the entire required CIP compliance documentation for their systems in the cloud might then be reduced to one sentence: “CSP ABC is certified for compliance with ISO 27001.”

Of course, doing this would be very popular with NERC entities. In fact, it’s safe to say that, if NERC announces this change to CIP on a Monday, by Wednesday almost all NERC entities subject to CIP compliance will have located all their OT Cyber Assets in the cloud (or at least as many assets as possible. Most Cyber Assets deployed in substations and generating facilities, and some deployed in Control Centers, will probably never be deployed in the cloud, due to latency concerns).

However, the downside of doing this is that by Thursday of that week, Kim Jong-Un and his friends will realize that the most important cyber assets controlling the North American grid are now located in a small number of CSP data centers. It would only take a small number of well-targeted missiles to bring down the whole grid – at which point there would be no point in continuing the attack, since the US and Canada would already have been reduced to the technological level of pre-industrial Europe.

The second reason is probably more realistic: Even if a requirement that NERC entities drop a CSP that doesn’t have a certain certification could get past the NERC lawyers (and it never would get past them. In fact, it might be considered an antitrust violation), it would almost never be complied with. This is because a decision by a NERC entity to use, or to stop using, a certain CSP for OT purposes will almost never be driven by the cybersecurity or compliance people, but by Engineering.

Moreover, it is unlikely that a NERC entity is going to abandon an OT provider of any type, simply because there is a concern about their cybersecurity or compliance posture. The engineers will just say to management, “Which do you prefer: keeping the lights on or complying with some cybersecurity requirement?” That will be the end of the conversation.

The third reason for not making ISO 27001 compliance an up-or-down criterion for dropping or retaining a CSP is that, even if the ISO 27001 standard covers everything NERC CIP does and a lot more, there are still many risks that apply only to cloud use - more of which are becoming apparent every month. It’s safe to say that neither NERC CIP nor ISO 27001 addresses “cloud-only” risks, like the risks I discussed in this post, this one, and this one. This means that the most important risks for the new CIP standard(s) to address are precisely the ones that aren’t covered by CIP or ISO 27001. Basing Cloud CIP entirely on ISO 27001 certification would ignore those risks altogether.

If we’re not going to include ISO 27001 certification (or something similar, like Soc 2 Type 2 audit results) as an up-or-down criterion for use of a CSP or SaaS provider, how can we utilize it in Cloud CIP? After all, the results from a certification audit contain a wealth of information about the security controls implemented by the CSP. It would be a shame not to utilize that information when determining what particular risks a NERC entity faces by using that CSP. In other words, the question is no longer “Should we use/not use CSP ABC?” Instead, it is, “Given that the decision to move to/remain with ABC has been made by others, what risks do we face by starting to use/continuing to use them?

Before I describe my ideas on this question, I want to point out that I think the revised CIP standards should have two “tracks”: one for on-premises systems and one for cloud-based systems. The former track should consist of the existing “on-premises only” CIP standards, even though those standards need a lot of improvement. The SDT has more than enough on their hands in dealing with the cloud; fixing the on-premises standards will need to wait. Moreover, by not requiring on-premises systems to make any change to their existing CIP compliance program, the SDT will avoid the major problem that the CIP Modifications SDT encountered when they tried to fundamentally revise the existing CIP standards in 2018.

The earlier discussion has shown that there are two types of risk that apply to cloud-based systems: “cloud-only” risks and risks that apply both to on-premises and cloud-based systems, which I will call for the moment “hybrid” risks. The cloud-only risks will need to be addressed with a separate set of requirements from those that address hybrid risks. I have some ideas on how to address the cloud-only risks, but they will need to wait for another post (probably very soon).

For now, let’s focus on hybrid risks. I think the SDT should develop a list of the hybrid risks it wishes to address. They will fall into two groups:

1. Risks on which existing NERC CIP requirements are based[i]. For example, the risk on which CIP-004-7 Requirement R4 Part 4.1 is based might be written, “An employee who does not need access to high or medium impact BCS, EACMS or PACS will receive access and use it to compromise one or more such systems, causing an adverse impact on the Bulk Electric System.” And the risk on which CIP-007-6 Requirement R3 Part 3.1 is based might be written, “Malicious code might be introduced into a medium or high impact BCS, EACMS, PACS or PCA.” Of course, both risks would have to be rewritten to apply to the cloud.

2. Risks addressed by one or more controls in ISO 27001 which are not addressed by current NERC CIP requirements - but which the SDT considers worth addressing in Cloud CIP. Of course, there are hundreds of controls included in ISO 27001 that don’t address current CIP risks – for example, A.8.10 Information Deletion and A.8.11 Data masking.

Regarding the second type of hybrid risks, what will happen if the SDT decides that the risks behind 50 ISO 27001 controls are all worth addressing in Cloud CIP? Does that mean they will have to develop 50 new requirements? And will NERC entities need to develop a compliance program, with separate evidence, for each of those 50 requirements?

No. I’m thinking there could be a single requirement that refers to a list of ISO 27001 controls; this list will include the hypothetical 50 controls of type 2 and the perhaps 30-60 controls of type 1 (i.e., controls that map to NERC CIP requirements). Each row on the list will include an ISO 27001 control and its number (e.g., “Physical security monitoring” paired with “A.7.4”).

That requirement (which might even be its own standard) will state that the NERC entity needs to examine the ISO 27001 (or Soc 2 Type 2) audit report for each of the platform CSPs or SaaS providers that it utilizes. Then, the entity must determine whether any of the controls listed has a negative finding in the report, as illustrated in the table below.

If there is a negative finding for an ISO 27001 control, the NERC entity will be required (by the new requirement) to verify that the CSP or SaaS provider has implemented the control[ii] or an equivalent mitigation for the same risk.

To summarize this post, a CSP’s or SaaS provider’s ISO 27001 (or Soc 2 Type 2) certification is useless as a “go/no go” gate for determining whether a NERC entity should purchase services from the CSP; this is mainly because OT purchase decisions are almost always driven by Engineering. They are very seldom based on cybersecurity or compliance considerations (except perhaps in the case of a major cybersecurity breach at the CSP). Thus, creating a CIP requirement for this would be a waste of time, if for no other reason than it would probably be shot down by NERC or FERC for legal reasons, including possibly being an antitrust violation.

However, the certification can be very helpful if the audit report is used to provide evidence for whether the CSP has mitigated particular “hybrid” risks (i.e., risks that apply to both on-premises and cloud-based products and services). These can include both risks addressed by the current CIP requirements (with their corresponding ISO 27001 controls) and risks mitigated by important ISO 27001 controls that do not map to CIP requirements.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at [email protected] or comment on this blog’s Substack community chat. If you would like to join my CIP Cloud CIP Risks Working Group described in the italicized paragraphs at the end of this post, please email me. The group’s first meeting is already scheduled.

[i] This assumes that one of the goals of the SDT should be developing new cloud requirements that address the same risks as the existing CIP requirements – e.g., a cloud configuration management requirement like CIP-010 R1, a cloud vulnerability assessment requirement like CIP-010 R3, etc.

[ii] Even if there was a negative finding for a control in the ISO audit report, it would presumably already have been implemented by the time a NERC entity reads the report. This is because the report should always be delivered first to the CSP or SaaS provider, and they will presumably move quickly to implement any missing control.

The entity will need to verify that the control has in fact been implemented, if there isn’t some note to that effect in the report. If there is a note, or if the provider has otherwise verified to the entity that the control was implemented, the NERC entity should change the entry in the fourth column of the table to “No”.