NERC CIP: Which way to the cloud?

I’m pleased to report that probably the number one issue in the world of NERC CIP – the fact that NERC entities with medium and high impact BES Cyber Systems (BCS) can’t implement them in the cloud today, while remaining compliant with the CIP standards – is now officially “heating up”. In fact, it seems to me there is widespread consensus in the NERC community, including among NERC entities, NERC and Regional Entity staff members, third party software and service providers, and – last but certainly not least – the cloud service providers themselves, that there needs to be a “legal” pathway to the cloud for those NERC entities that feel comfortable implementing some of their medium and high impact systems in the cloud.

I used to be quite pessimistic that this day would ever dawn, since it seemed to me that we would never get the whole NERC CIP community to agree to fundamental changes in the CIP standards, especially given that these would entail major changes in NERC entities’ compliance programs. And guess what? I still believe we’ll never get that agreement, at least for a long time.

Then, what has changed? A Standards Authorization Request (SAR) was submitted to the NERC Standards Committee earlier this year[i], which contained an innovation I hadn’t thought of: having two “compliance tracks” for medium and high impact BCS. One track would be what I call “Classic CIP”. Entities wishing to follow that track could continue complying with the existing CIP standards (although with small modifications to CIP-002); nothing at all about their current compliance programs would need to change.

However, if a NERC entity wishes to locate high and/or medium impact BCS[ii] in the cloud, they would need to follow a new “Cloud CIP” track.[iii] I have recorded my ideas on how this new program would work in a document that will be the basis for a discussion that I will engage in with Lew Folkerth of the RF NERC Regional Entity, at RF’s monthly Tech Talk webinar. It will be held on Monday, October 23 from 2:00 to 3:30 Eastern Time (note 10/22: I mistakenly put 1:00 to 2:30 ET in this post when I originally put it up). It is open to anyone, and no pre-registration is required. The attendance URL is included in the page linked just above.

I will be one of two speakers; I’m not sure whether I’ll be first or second. However, the other speaker is someone I’ve known for a long time, who is (without exaggeration) one of my favorite people: Shon Austin, a CIP auditor with RF (and previously with the SPP Regional Entity). His topic is directly related to mine: He is discussing the project that developed CIP-004-7 and CIP-011-1, which will become enforceable on January 1, 2024. Note that neither my disicussion with Lew nor Shon's presentation will be recorded, in accordance with RF's longtime policy.

The changes in these two standards are what will allow BES Cyber System Information to be stored in the cloud (BCSI has also been “prohibited”, with even less justification than BCS) – among other “modern third‐party data storage and analysis systems”. Shon, being an auditor discussing CIP requirements that will be in effect in less than three months, will have to be much more careful than I will – since I’ll discuss my general ideas regarding a way forward. If Shon makes a mistake, it will be painfully obvious in half a year, whereas if I make a mistake, I’ll be retired by the time it becomes obvious - if anybody even remembers what I said then. Some of us have all the luck.

See you there!

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 tom@tomalrich.com.

---

[i] I don’t know what the status of that SAR is. My guess is it wasn’t accepted, but that’s OK. Before there can be any serious SAR, there needs to be rough consensus in the NERC CIP community about how to address this problem. There has been almost no serious discussion of the topic so far. Maybe the webinar described in this post will help get that discussion going. 

[ii] High and medium impact Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS) are also currently prevented from being located in the cloud, due to similar (but not identical) considerations as those preventing high and medium BCS. In fact, it can be argued that the fact that EACMS are not currently allowed in the cloud has significantly degraded the level of BES security from what it could be otherwise; this gap is continually widening, as managed security service providers increasingly move toward providing their services primarily or entirely using cloud-based analysis. 

Any plan to permit BCS in the cloud should include a plan to permit EACMS and PACS. In fact, it seems to me that, since addressing EACMS (and perhaps PACS) in the cloud will be much easier than addressing medium and high impact BCS, and since the security return on investment will be higher (at least initially), it would make sense to make EACMS the initial focus of the “Cloud CIP” effort. The icing on the cake is that it’s likely that nothing that would be required to make EACMS in the cloud “legal” would not also be required as part of the BCS effort. So, the BCS effort won’t be set back much (if at all) by the decision initially to focus on EACMS. Indeed, the SAR that was submitted this year makes that suggestion. 

[iii] Entities that wish to implement some of their BCS in the cloud, and other BCS on premises, would need to follow the Classic CIP track for the latter and the Cloud CIP track for the former. It is likely that only a small percentage of entities that decide to take advantage of the cloud for BCS will be able to implement all of them in the cloud; some BCS need to remain local by their very nature.