As I mentioned in a recent post, I was able to listen to almost the entirety of RFC’s day-and-a-half CIP v5 workshop two weeks ago, and found it really worthwhile (I hope the recording will be posted on NERC’s v5 Curriculum site, but it’s not there yet). Scott Mix of NERC made four – count ‘em – presentations, all good. But a subject he brought up in his last presentation was particularly striking, and made me realize there could be a whole new dimension of CIP v5 compliance that I hadn’t realized.[i]
Scott’s presentation (it wasn’t on the original workshop list, and the links to his slides weren’t provided with the other slide links) was about the draft Lesson Learned on “Grouping BES Cyber Assets”. The first paragraph of the Guidance reads:
“Registered entities may choose to create different groupings of BES Cyber Assets to comply with individual CIP Version 5 standards. For example, all the Energy Management System (EMS) servers at a Control Center and the associated backup Control Center could be grouped together as they are categorized at the same impact level. Alternatively, it may be best to group Microsoft Cyber Assets, Linux Cyber Assets, and other Cyber Assets (e.g., network or disk servers) according to the software patching requirements (as the patch sources may be different and released on different release cycles) for compliance purposes.”
In other words, there’s no reason why the entity needs to just create one set of BES Cyber Systems while complying with CIP-002-5.1 R1, and stick with that same set through all of the remaining standards; you can create BCS in one way for the purposes of one standard and in another way for another standard. In fact, even though the LL doesn’t say this, I don’t see that v5 even prohibits you from using different BCS groupings for different requirements within a standard.
The idea that you could do this has been around for a while, since before the LL; it was clear from the start that there was no wording in the v5 requirements that prohibits this. An auditor and I had discussed it last year, but at the time it seemed obvious to both of us that trying to track this would be a nightmare. If you wanted to have let’s say five different BCS groupings, you would have to document which grouping you were using for each requirement, and make sure you didn’t mix BCS between groupings. For example, say you have one grouping you use for CIP-005 and another for CIP-007. You need to make absolutely sure you don’t forget and use a few of the 005 BCS while complying with 007, or vice versa. And you would need to make it impossible for people in the field to make this mistake as well. Of course, you also have to manage this as long as CIP v5 is in effect, through personnel turnovers, etc. It will be quite a job.
Going through an audit would be even more of a challenge. You would have to show the auditor that you were consistent in your use of different BCS groupings for different requirements. Just as important, you would have to prove you had never left any BES Cyber Assets outside of a BCS, since the definition of BES Cyber System makes it quite clear that every BCA must be part of a BCS. And you would need to show the auditor a “map” linking each BCA to the BCS it was part of in each BCS grouping.
Because of these complexities, the auditor and I agreed it wasn’t likely that any entity would want to change BCS groupings like this. Moreover, it seemed clear that no NERC region would allow this to be done, because of the complexity it would introduce into the audit process.
So I was surprised to hear Scott Mix not only say it was possible to group BCS differently for different standards, but that it might offer entities some real advantages, since different standards/requirements lend themselves better to different groupings. For example, as the Lesson Learned suggests, complying with CIP-007-6 R2 (Patch Management) would obviously be much more efficiently done if BCAs were grouped into BCS by operating system – Linux systems in one, Windows 7 in another, Windows 95 in a third (OK, this one is a joke. I hope there aren’t any Windows 95 boxes anywhere on the BES!). Other requirements that would be much more efficiently addressed with an OS-based grouping would be CIP-009-6 R1-R3, Backup and Restore.
On the other hand, CIP-005-5 R1 (ESP) will be much easier to comply with if all of the BES Cyber Systems are grouped as I suspect most entities are grouping them now: by function. Every BCS that is connected to a network must be within an ESP. Yet suppose the entity wanted to comply with this requirement by grouping BCAs by OS as I just described; and say the asset in question was a large generating station with multiple buildings. There might be Linux BCAs scattered among different buildings, yet if they were all to be in one ESP, this would require having the ESP span multiple buildings. While this isn’t forbidden, it might cause some logistical challenges that the entity would rather avoid.[ii] So a functional grouping – where all the BCAs within a BCS would be on the same network – might be a better approach for this requirement.
Am I saying that every entity subject to CIP v5 (with High or Medium impact assets) should go back and consider whether it might be better for them to group BCAs into BCS differently for different v5 standards or requirements? Yes, I am. I can see some potentially huge savings in ongoing compliance costs resulting from this.
But I’m not saying that all entities actually have to use more than one BCS grouping in their CIP v5 compliance program. For one thing, just because of the number of BCS that are involved, this is a strategy that will benefit large entities much more than smaller ones. Yet for the large entities, that hopefully started their v5 compliance effort in earnest sometime last year, it may well be too late to implement this strategy. However, given the possible payoff, I think every entity should at least give this idea serious thought.
BTW, this is another reason why I’m advocating that the CIP v5 compliance date be pushed back by a year. It would have been wonderful if NERC had made it clear – say – last summer that having different BCS groupings was a possibility. Unfortunately, at this point I’m not sure anyone will be able to take advantage of what Scott so eloquently suggested in Cleveland. It will take a lot of work to implement.
The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte & Touche LLP.
[i] Unfortunately, there was an outage in the webcast audio for about 20 minutes, but that came after Scott had convinced me of his point – the subject of this post. Since the outage seemed to be communications-related, it hopefully won’t appear in the recording.
[ii] This discussion wasn’t included in Scott’s presentation, as far as I can remember. This is my own reasoning, and Scott can’t be blamed for it.