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.
No comments:
Post a Comment