In my first post in this series, I pointed out what I think is an essential element of new CIP standards that will accommodate cloud use for NERC entities with medium and/or high impact environments: having separate “tracks” for cloud vs. on-premises systems (with the requirements for the latter being almost exactly the same as the current CIP requirements).
However, as I pointed out in this
post, the full NERC process of developing the new standards and getting
them approved by NERC and FERC – which started three weeks ago - will likely
take at least five years. This isn’t good, since more and more software and
services vendors (and especially security services vendors) are moving to a
cloud-only model, even though they know some of their electric utility customers
won’t be able to follow them there. It is likely that the security and
reliability of the North American Bulk Electric System (BES) will soon be
negatively impacted because of this situation.
In this
more recent post, I pointed out three things. First, I noted that the big
problem inhibiting cloud use for CIP systems is the fact that the CIP
requirements are based on the idea of protecting the physical device (e.g. a
server) on which a system in scope is housed – yet, the software that comprises
those systems moves rapidly from server to server all the time. Strict
application of the CIP requirements (which were mostly developed before cloud
use became widespread, and which never mention the cloud once) mandates first
that every cloud server that holds even a small piece of a system in scope for
CIP - say, an EACMS - comply with all the CIP requirements that apply to
that asset type, no matter how inapplicable they may be to the cloud.
Second, those requirements also implicitly mandate that
every server that might in the future hold part of one of those systems be continually
protected during an entire three-year audit cycle. Given that there are over 40
applicable CIP requirements and over 100 applicable requirement parts
(sub-requirements), that would require an unbelievably huge amount of work for the
CSP (applicable systems are medium or high impact BES Cyber Systems or BCS, Electronic
Access Control or Monitoring Systems or EACMS, and Physical Access Control Systems
or PACS). Moreover, the CSP would need to provide literal mountains (well, hills)
of documentation, individualized for each NERC entity that is a customer.
Finally, I noted that CIP-013-2, the supply chain security
standard, may furnish a way out of this mess in the near term, while still
allowing the full 5+-year process of drafting new CIP standards (and probably
changes to the NERC Rules of Procedure) to proceed in the background.
However, it turns out I made a mistake in both statements. In
the first statement (really, a group of statements), I made the implicit
assumption that a cloud service provider (CSP) would never “break the cloud
model” by installing systems in scope for NERC CIP on dedicated, unchanging
servers, even though the requirements were all written for such servers. But I’ve
since learned that this might indeed be an option for CSPs. If BCS, EACMS and
PACS never jump from physical device to physical device, CIP compliance
suddenly becomes much easier.
In the second statement (about CIP-013), I followed the same
implicit assumption – that systems in scope for CIP compliance would continually
jump from server to server in the cloud, meaning there would be an unbelievably
large number of servers in scope for CIP-013 compliance. However, if the
servers are unchanging (and locked within a single Physical Security Perimeter
subject to the requirements of CIP-006), this suddenly makes what I proposed in
the post – that the NERC entity declare the CSP to be a vendor under CIP-013-2,
and that the method for assessing their cybersecurity be examining their
ISO 27001 certification evidence – much more realistic.
In other words, I now like my suggestion about CIP-013 even more
than I did in April. It seems there could be a fairly easy way for usage of the
cloud by medium and high impact BCS, EACMS and PACS to be “legal” relatively
soon - maybe in two years, vs. the 5+ years that the full standards development
process will take. Of course, the full process still needs to take its course,
since it is very likely that the new Standards Drafting Team will want to see
more evidence from the CSP than just their ISO 27001 certification, and since changes
will be needed in CIP-002 to enable the “two-track” CIP compliance process I
described in the first post in this series.
What will it take for this to happen? I think the NERC Board of Trustees will need to take some action to get this all moving. It would be nice to be able to say there is currently motion in that direction. However, I don't see that now.
I do want to point out that the NERC Cloud Technical Advisory Group (CTAG) and SANS are going to sponsor a set of 6 or 7 webinars on use of the cloud by NERC entities, starting at the end of June and running biweekly through the end of August. That may raise some awareness.
Are you a vendor of current or
future cloud-based services or software that would like to figure out an
appropriate strategy for the next few years, as well as beyond that? Or are you
a NERC entity that is struggling to understand what your current options are
regarding cloud-based software and services? Please drop me an email so we can
set up a time to discuss this!
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.
No comments:
Post a Comment