Note from Tom:
I have moved to Substack as my primary blog platform. If you want to see all my new posts, as well as my 1200+ legacy posts dating from 2013, please support me by becoming a paid subscriber to my Substack blog. The cost is $30 a year. Thanks!
Â
My post this past Monday covered a lot of ground, so I want to summarize the main points I made. Note the points below don’t follow the same train of thought as Monday’s post:
1.     In my opinion, the purpose of the NERC “Cloud CIP” standards drafting team (SDT) is to develop new CIP requirements that protect the Bulk Electric System (BES) from cybersecurity attacks[i] due to threats in the cloud that compromise on-premises BES Cyber Systems (BCS) and as a result can negatively affect the BES itself. There are three possible vectors for those attacks.
2.     The first vector is attacks that utilize BES Cyber System Information (BCSI) stored and/or used in the cloud to guide on-premises attacks on BCS (in other words, these are attacks that happen on-premises, but are guided by BCSI stolen from a cloud repository or SaaS application). As far as CIP is concerned, this attack vector has already been addressed by the new or revised requirements CIP-004-7 R6, CIP-011-3 R1 and CIP-011-3 R2. These were drafted by a previous SDT that started work in 2017 or 2018; they came into effect on January 1, 2024. I think these requirements are fine as they stand. The current Cloud CIP SDT does not need to take further action regarding attacks that utilize this vector.
3.     For example, one possible attack using this vector starts with compromise of the database of a SaaS configuration management application. The attackers then steal information that describes how multiple BES Cyber Systems in a Control Center are configured, as well as the configuration of a firewall that protects those systems[ii]. Using that information, the gang then modifies the configuration of the firewall guarding the Control Center; they follow up by compromising several BCS within the Control Center. Having compromised those systems, the attackers then attack and compromise a relay in a substation, ordering it to operate a circuit breaker to open a line; this causes an outage.
4.     The second vector is attacks on on-premises BCS, which originate in the cloud. That is, these attacks don’t require the intermediate step of access to BCSI; therefore, they are much harder to prevent. Since these attacks originate in the cloud, they constitute “cloud-specific” risks. Because the current CIP standards say nothing about the cloud, these risks are not addressed at all by current requirements. Therefore, completely new requirements, terms, and evidence methods will be needed to address these risks in the current CIP framework. The SDT’s second Standards Authorization Request (SAR), which the SDT itself drafted last year, calls for it to “consider” these risks.
5.     For example, one of the 12 “cloud risks” that the SDT identified in their revised SAR (see my post from this past Monday, which is linked above) is “Reliance on indirect services”. By this, I believe the SDT means the risk that a cloud-based service used by a NERC entity might utilize a third-party service that they have not properly vetted. Thus, an attack[iii] originating in that third-party service might end up compromising one or more on-premises BCS operated by the NERC entity.
6.     There is a third vector for attacks that I regard as mainly theoretical, although other people may believe otherwise. It is the risk due to attacks that originate in the cloud and can compromise on-premises BCS, but which are based on threats that are addressed in compliance frameworks like ISO 27001. If the Platform CSP or SaaS provider has passed an ISO 27001 audit[iv] in the past year and any negative findings have been remediated, it is safe to assume they have addressed each of these threats.
7.     I don’t think it’s necessary for the SDT to develop new CIP requirements – or modify existing ones – to in some way “require” platform CSPs and SaaS providers to provide evidence that they comply with the spirit of any of the existing requirements, since I’m sure they’re all addressed in ISO 27001 (and if you know of a CIP requirement that isn’t addressed in 27001, please let me know. Of course, there will almost never be a one-to-one correspondence between a CIP requirement and an ISO 27001 control. In most cases, one CIP requirement will map to multiple 27001 controls). However, if the SDT feels they need to develop “cloud versions” of the existing CIP requirements for on-premises systems, the Measures section of each requirement (which is intended to provide examples of compliance evidence) should just reference the relevant section(s) of the audit report.
8.     For example, I’m sure that the threat of infection due to known malware attacks is addressed in ISO 27001; of course, the same threat is behind CIP-007 Requirement R3. The mitigations for this threat are regularly updated antivirus software and rapid patch application. If a “cloud version” of CIP-007 R3 is developed, its Measures section should reference the section(s) of the ISO27001 audit report that reference antivirus software and patch application and require verification that there were no negative findings for these sections.[v]
Â
To summarize what I’ve just said, I think there are three types of “cloud risk” that fall into the scope of the current Risk Management for Third-Party Cloud Services Standards Drafting Team. All of these risks originate in the cloud and pose a threat to on-premises BES Cyber Systems; each risk consists of attacks using a particular vector:
A.    Attacks of the first type start with exploitation of BCSI stored or utilized in the cloud. This risk can be mitigated by proper protection of BCSI in the cloud. Two revised CIP standards, CIP-004-7 and CIP-011-3, came into effect on January 1, 2024 to address this risk. I believe they do a good job of mitigating this risk, and no further action by the SDT is needed.
B.    Attacks of the second type are “pure” cloud risks. In other words, they originate in the cloud and can lead to direct compromise of a BES Cyber System; they don’t first require access to BCSI stored in the cloud, as is the case with attacks of the first type. In my opinion, this is where the SDT should spend most of their time, since the time required to properly address this type of risk with CIP requirements far outweighs the time required to address either of the other two types. Because there is a lot to be said about this type of risk, I will save my comments (beyond what I said in the previous post linked at the beginning of this post) for a new post in the very near future.
C.     By contrast, I don’t think risks of the third type are real risks, as long as the CSP or SaaS provider has passed an ISO 27001 audit recently (which I assume means in the last 1-3 years). However, if the SDT wants to create cloud CIP requirements based on the existing CIP requirements, they should make sure that the only evidence needed to prove compliance with this requirement is an ISO 27001 audit report. If they draft requirements that require a platform CSP or SaaS provider to provide other evidence of their programs for remote access, patch or vulnerability management, vulnerability assessments, configuration management, etc., it’s very likely that NERC entities will be turned down flat when they ask for that evidence. The CSP or SaaS provider will probably respond that their cybersecurity programs have already been audited for ISO 27001 compliance and they don’t think another audit is required.
Â
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.
I’m now in the training business! See this post for more information.
[i] It would be better to refer to these as “cybersecurity attack chains”, rather than just cybersecurity attacks.
[ii] Of course, I understand that most Control Centers are protected with more than one firewall, as well as other cybersecurity “layers”. Launching an actual attack like this one would require many more steps.
[iii] This is a recent example of such an attack.
[iv] Soc 2 Type 2 audits might be substituted for ISO 27001 in this post. However, as far as I know, FedRAMP is different, since a) it doesn’t have regular audits, although other means like pen tests are used to verify continued compliance, and b) FedRAMP isn’t a certification, but an authorization for certain federal agencies to utilize a cloud-based service. Of course, only a small number of NERC entities (including TVA, WAPA and BPA) are federal agencies.
[v] If the audit report shows a negative finding for one of the requirements in question, the NERC entity can request evidence that the CSP mitigated the risk behind the requirement and thereby closed the negative finding.