Dear
Reader: In April, I wrote a post discussing the fact that NERC entities can group
BES Cyber Assets into BES Cyber Systems in multiple ways, specific to each CIP
v5 standard or even requirement. I
speculated how taking advantage of this might save entities a lot of time and
money in complying with v5 – I call this “Grouping BCS on the Fly”. After the
post came out, I had three good conversations (two email, one verbal) on this
topic, which opened my eyes a lot to both the possible advantages and drawbacks
of taking this approach. I will start
with an email I received from an auditor, which as you can see urges caution
but doesn’t say this is illegal or inappropriate.
The
Auditor’s Email
“I have always maintained that you can regroup BCS
by Standard and Requirement. Just as a BCA can appear in multiple
BCS. There may be good reasons to do so, although you need to carefully
consider (whether taking the approach you discussed will provide you with any
advantages, and if so whether those advantages might be outweighed by
disadvantages).
“If you define a single set of BCS, you will have an
easier time keeping everything straight. Make a change to the environment
and you only have to update one BCS group. You can have global policies
and procedures that cover multiple BCS, and you can have multiple procedures
that in total cover all of the Cyber Assets in a BCS. (Both of these
considerations minimize the advantage of “grouping on the fly”.)
“The disadvantages are also as you suggested.
If you have different groupings of BCS for one or more Standards and
Requirements, then you have multiple lists of BCS and their component Cyber
Assets to keep up with. Make a change to the environment, and you run the
risk of not updating all of the impacted BCS documentation or not properly
applying the applicable controls. You also run the risk of inadvertently
excluding a BCA from a BCS for a given Standard and Requirement. And,
your list of High and Medium impact BCS required by CIP-002-5/R1 will be far
more complicated because the auditor will expect you to produce all of the
various lists and identify their applicability. And before you look
forward to ending up with different impact categorizations (at best, that could
occur in a generating plant; certainly not in a Control Center), the benefit to
do so might not be worth the effort it takes.
“Here is what I have learned:
“First, pay extremely close attention to the
applicability statement for each Standard and Requirement. Especially the
differentiation between Medium Impact BCS, Medium Impact BCS with External
Routable Connectivity, and Medium Impact BCS without ERC. There are huge
benefits of segregating your BCA into BCS with ERC and (grouping BCA without
ERC into a separate BCS). Some of the most problematic requirements in
the generating plant are not applicable to BCS without ERC - think about all
the smart sensors, HART-enabled devices, etc. (This means that it is worthwhile
to group as many of these plant floor devices as possible into BCS without ERC,
to avoid the difficulty) of providing the necessary physical access controls if
they are grouped into a BCS with ERC.
Note from Tom: The auditor’s point
about grouping BCS into those with and without ERC is a good one, but I don’t
think it has an impact on the question whether or not an entity adopts the “grouping
BCS on the fly” approach that I’m discussing here. For example, to comply with
the requirements where ERC makes a difference, the entity might want to group
BCA with ERC into one BCS, and BCA without ERC into another. But for other requirements, other groupings
might be easier to work with (such as grouping by OS for the patch management
requirement).
“Second, the KISS principle really applies
here. The more complicated you make your process, the more error prone it
is. Errors may result in violations. Violations may result in
financial or non-monetary sanctions. Even if there are no sanctions, you
will still have to fix the problem and do so in such a way as to preclude the
error from happening again.
“Third, another reason for KISS is that
straightforward internal controls are the controls that are most effectively
implemented. And well designed, effective internal controls are how you
gain benefit from an Internal Controls Evaluation under the Risk-Based
Compliance Monitoring and Enforcement Program. You want controls that can
survive a change in personnel, especially as there is often no overlap period
to do a proper handoff and knowledge transfer.
“The
auditor will take the time to carefully evaluate whatever the registered entity
has done. Greater complexity brings greater scrutiny because the risk of
error is greater. In the end, it is entirely up to the registered entity
to logically group their BCA into BCS. The auditor should not find a
possible violation because he/she disagrees with the grouping unless there is a
material deficiency in the lists (such as an overlooked BCA).”
(back to
Tom) So this auditor is saying he doesn’t personally see great advantages to
grouping BCS on the fly, but that it won’t be held against the entity if they
decide to take that approach.
Supporting
the Idea
Another email I received the day after the post was
from a consultant I’ve known for some time.
He pointed out that he’s working with an entity that has decided to have
ten different groupings of BCS! He agrees that having the proper
documentation (which needs to be very flexible) is key. He has promised to let me know how this
works.
I also had a verbal conversation with a compliance
person at a large entity, who said she had considered doing this but felt it
wouldn’t work well (from a regulatory risk point of view) in their
environment. But she could see one big
benefit: it makes the TFE process easier.
Let’s say you had a large set of relays that you were going to have to
take a TFE on for a particular requirement.
Instead of having to do a TFE for each, you could group them all
together as a single BCS for that requirement, while still being able to group
them in other ways for other requirements (say according to the network they’re
on, for compliance with CIP-005-5 R1).
I’d be interested in hearing from anyone else who is
trying this. I still think there could
be a lot of benefits, and I’m glad NERC and the regions have supported this as
an option for those who want to take advantage of it.
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte & Touche LLP.
No comments:
Post a Comment