Friday, June 19, 2015

Grouping BES Cyber Systems on the Fly

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