I have already written about two issues that came up during conversations with attendees and presenters at WECC’s CUG/CIPUG in Salt Lake City. Here is another, having to do with control centers and the remote devices they control.
Section 1 of CIP-002-5 Attachment 1 states clearly that High impact BES Cyber Systems are those “used by and located at” control centers that meet one of the four criteria in that section. The “located at” was clearly inserted to exclude remote devices (mostly in substations) that are controlled by the control center. Had the wording been “associated with” as in Section 2 (Mediums), these remote systems would have become High impact.
This would have required control center owners (or the substation owners, if different) to apply all of the controls for High impact BCS at those substations – two forms of physical access control, IDS, active vulnerability assessments, etc. As it is, these devices will be protected according to the impact rating of the substation – Medium or Low – not the High control center.[i]
However, at the WECC meetings a consultant friend pointed out to me that he believed that devices at substations that are controlled by a High control center are themselves High impact. When I pointed out the wording of Section 1 to him, he asserted that this didn’t matter because those devices are “in the ESP,” and therefore take the rating of the control center due to the “high water mark” principle.
I was at first taken aback by this statement and didn’t know how to respond.[ii] But I finally realized this was simply an incorrect application of logic. This is how the reasoning should go:
- High BCS are always located at a High impact control center.
- By definition, an ESP encloses all of the BCS at the control center.
- Since all BCS have to be at a control center, there is no need to extend the ESP beyond the control center’s walls (more specifically, the PSP). In practice, of course, there would be huge problems with doing this, since it would require protecting the communications media between the control center and substations.
- Since the devices in the substations are completely beyond those walls, they aren’t in the ESP and therefore the high water mark doesn’t apply.
There you have it. I wish all problems with CIP-002-5 were as easily solved.
Note: An Interested Party weighed in to point out that my footnote 1 on Medium Control Centers is probably wrong. You can see what he says here.
The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Honeywell..
[i] Note that Medium impact control centers don’t have this protection, since BES Cyber Systems only have to be “associated with” a Medium control center. However, this consideration is mitigated by the fact that some of the substations that contain those assets will themselves be Medium impact because they meet one or more of Criteria 2.4 – 2.8. For more on this wording difference, see this post.
[ii] There was a side issue that distracted me at first. I pointed out to him that most devices controlled by an EMS are connected serially, not routably. Therefore, they wouldn’t fall in the ESP. He countered that serial isn’t “exempt” in CIP v5, so these would have to be included. Of course, this is mixing several things up. It is true that BCS at a Medium asset that don’t participate in external routable connectivity (i.e. they could be connected non-routably via serial or simply not connected at all) now have some requirements that apply to them, as opposed to being completely exempt as in Versions 1-4 (that is, in v1-4 cyber assets without external routable connectivity weren’t Critical Cyber Assets at all, so no requirements applied to them).
That “exemption” has gone away in v5, but it has nothing to do with the case in point. We’re talking about including serially-connected devices (whether local or remote) in an ESP, and this is clearly something that doesn’t make sense. ESPs contain routably-connected devices, not serially-connected ones. But I focused at first on the serial issue before I realized (in writing this post) that the real issue had nothing to do with serial vs. routable, but was simply a case of incorrect logic.