With all the furor about S4 over the past week, our readers may have missed some of the developments on the NERC CIP front.

Last week, NERC and electric power representatives (and a bunch of us consulting folks) met in both Phoenix and Atlanta for a one-day conference (so, two days total) on how to approach the development of the CIP Version 5 regulations. In the meetings, NERC staff solicited feedback on how the development team should address the various issues FERC wants fixed. The Atlanta meeting was well attended, and I heard the same regarding Phoenix.

First off…  Regulations are a pain. They are often either too specific or too vague, and tend to funnel entities into a common approach to a problem that could technically have multiple, even equally acceptable, solutions. But, the regulations also provide a means of ensuring that entities apply appropriate consideration to the collective risk to the public from computer security issues, a classic example of an externality. So, when I talk about an approach, or recommend an alternative, I’m actually concerned that the industry is reducing choices when complying, and making it more difficult to protect the electric system efficiently.

Attendees came up with many items for the drafting team to consider. I’d like to highlight a few to explain in greater detail, and offer some thoughts on pros and cons to each approach from an industrial control system security perspective. If you’re not familiar with the CIP process right now, the drafting team is updating four main areas: Identify, Assess, and Correct (IAC) Language; Communication Networks, Low Impact Assets, and Transient devices.

First off, I won’t be covering the IAC language. IAC generally refers to the regulations requiring that entities look at their infrastructure, find problems, and correct those problems on basically a continuous basis. There was heartburn that the IAC language was basically not auditable. However, it appears that NERC has an approach I’m not currently familiar with that will fit this FERC directive called the “Reliability Assurance Initiative”.

Second, a lot of the comments and approaches repeated several of the assumptions that existed in the original version of the NERC standard. As examples, I mean the fact that utilities often make use of telecommunications infrastructure provided by 3rd parties, and that encryption tends to slow down SCADA communications.  These assumptions were brought up back during development of the original standard, but haven’t been challenged since. My recommendation for this was that the development team develop a list of assumptions made during the original development that pertains to the FERC comments, and find out if those assumptions are still valid, as it pertains to the parts of the standard under review.

One of the more important comments I heard during the meeting was related to Low Impact Assets, the components of the electric system that don’t have much of a responsibility under the current Version 3 standards. These are things like smaller generation stations, and other assets that were not identified under the original V3 Critical Asset determination. The question was whether or not the owners/operators of many Low Impact Assets would have the financial and time resources to adequately participate in development, which I took to mean “Who will be the voice of Low Impact Assets?”.  This is an important question, as the controls being developed for Low Impact Assets will touch the bulk of electric assets that had no controls required under CIP V3. Entities that previously had no real CIP requirements to follow will be spending money on these regulations, so their input is valuable.

There are concerns on requiring technical controls for Low Impact, namely because FERC direction allows NERC to consider alternative approaches to technical controls. Personally, I find it odd that an industry so flush with process automation is so adverse to developing automation of a security type. Technical controls or not, NERC is required to develop objective criteria for Low Impact Assets this year. My own contribution was that NERC should look at the past 10 years of ICS security history, and develop regulations designed to prevent the types of incidents that have affected electric power and industrial cyber security in the past.

Lastly, I finally got some background on the ‘Transient Devices’ category of the changes. Transient devices refers to anything connected to the critical asset for a defined period of time, so it includes laptops, removable media, and maybe even things like mice and keyboards (though I got some sharp comments back regarding most of those). In the V5 standard sent to FERC, transient devices did not need to be protected if they were only connected for 30 minutes days or less, reducing the paperwork required for these tasks. Reducing paperwork is a good goal, but given the capability and virus history surrounding transient devices, there will need to be requirements for transient devices.

All in all, I wish there had been more technical discussion of the various approaches (it certainly makes for a better ICS security blog post), but it’s likely my view was far too ambitious for a one day conference. As always, Tom Alrich has covered the meeting as well, and his views go much farther into the regulations and motivations of the parties.

*A sharp eyed reader pointed out I had put in ‘minutes’ instead of ‘days’ for the amount of time a transient device could be connected without needing NERC CIP protections. Thanks!

title image by James Cridland