An (ex-)Auditor comments on CIP-013 for Low impact assets

Kevin Perry, the former chief CIP auditor of SPP Regional Entity, wrote in today to comment on my Sunday post, the second (and last) in a series on NERC’s draft Data Request on Supply Chain Risk Assessment - which is currently out for comment by NERC entities. Specifically, Kevin wanted to comment on my suggestion that NERC proactively propose to include a basic supply chain security requirement for Low impact assets in CIP-013, rather than wait for FERC to order that Lows be made to comply with all of CIP-013. That would be much more burdensome and expensive.

Specifically, I suggested that NERC propose something like Requirement R5 in the first draft of CIP-013 (from January 2017), which was definitely a very basic requirement but also managed to address two of the biggest BES supply chain risks faced by all NERC entities: compromised patches and vendor remote access. That requirement read:

R5. Each Responsible Entity with at least one asset identified in CIP-002 containing low impact BES Cyber Systems shall have one or more documented cyber security policies, which shall be reviewed and approved by the CIP Senior Manager or delegate at least once every 15 calendar months, that address the following topics for its low impact BES Cyber Systems:

5.1. Integrity and authenticity of software and firmware and any patches, updates, and upgrades to software and firmware; and 

5.2. Controlling vendor-initiated remote access, including system-to-system remote access with vendor(s). 

Kevin thought this was a good idea because it would reduce a lot of supply chain risk, but also because it wouldn’t put a big compliance burden on Low-only entities (and probably zero burden on entities with Mediums and Highs that also have Lows, which is just about all of them. Those entities wouldn’t have to comply with these two new requirement parts, which are just for Lows. But they already have to comply with two parts that are very similar, CIP-013-1 R1.2.5 and R1.2.6).

Specifically, Kevin said (with my comments in italics):

I could see implementing your (of course, these aren’t mine! They were written by the CIP 13 drafting team) suggested 5.1 and 5.2 with relatively little effort.  Both can be implemented holistically.

1.       5.1 is vendor-centric and would apply to all Low Impact BCS, whether one or thousands, because the focus is on the vendor and not the Cyber Asset. Kevin is of course referring to the fact that the vendor is really the entity that has to “comply” with this requirement part. They will need to figure out a way to provide their electric utility customers with a way to verify integrity (e.g. checksum) and authenticity (e.g. digital signature) of all patches and other software they send to them. Once they’ve solved this problem for just one utility (whether they have High, Medium or Low assets), they’ve solved it for them all. It’s unlikely that many if any vendors that sell software that goes on BES Cyber Systems will balk at doing this.

2.       With respect to 5.2, putting in a gateway would be appropriate. This could be as simple as enabling/disabling a VPN account that the vendor uses to get to the supported entity’s network.  Access permissions then control where the vendor can go.  Best practice, you install the equivalent of an Intermediate System to maintain a breakpoint between the vendor and the supported systems. This requirement part will definitely be a little harder to comply with, because it does require some configuration at each Low asset. But my guess is that most entities with Low assets are already doing something like this. And if they aren’t, there are a lot of inexpensive remote access gateways for sale.

Note that Kevin isn’t saying that the only good way to comply with this part is to install an Intermediate System (as Mediums and Highs do, per CIP-005 R5.2), which would definitely be a good deal more expensive and time consuming, especially for entities with a lot of Low assets (one large entity told me a few years ago that they have over a thousand Low impact substations! Putting an IS in each one of those would be…well it would be pretty burdensome).

Kevin later emailed back to say “One more thought...  there is an added benefit.  If the entity is also a Distribution Provider, the Low impact BCS controls will also apply to the same relays in the distribution subs - no extra cost.” Such a deal!

July 18: Kevin emailed me yesterday to emphasize the point that compliance with R5.2 wouldn't be very burdensome on Lows (although I'd like to hear from anyone who thinks differently):

If the entity remotely manages its LBCS, such as over a TCP/IP network or by using a centrally managed “dial up” system to authenticate the user and then connect the user to the supported Cyber Asset, that is where you would place a central gateway to control vendor access to the company network and resources required to access the LBCS.  If the entity has a gateway device in the substation, then it is mostly a matter of adding the vendor to the gateway access list and, of course, enabling the vendor to get to the gateway, most likely through a central gateway that authenticates the vendor onto the entity network.

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. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. To discuss this, you can email me at the same address.