Monday, April 18, 2016

What Isn’t in the SAR

In anticipation of the NERC Technical Conference on April 19 on the Standards Authorization Request for the next CIP version (which I insist on calling CIP v7, although I’m not sure NERC will), I have already written two posts: here and here. In the first post, I discussed what NERC included in the SAR, which of course will provide the “agenda” for the Standards Drafting Team as they embark on their multi-year effort. I promised a post on items that are not in the SAR, but perhaps should be. This is that post.

As my post from yesterday points out, I group these items into two categories: problems with the current standards that can be addressed without re-thinking the fundamental concepts of CIP v5[i] (especially CIP-002-5.1) and problems that require this re-thinking in order to be solved. I suggested in that post that it is unlikely the SDT will want to address any of the latter problems, since having to engage in a fundamental discussion will probably add 6-12 months to the whole standards development process. Nevertheless, I will list both types of problems below, starting with the first type.

Note that I won’t list here any of the items that are already in the SAR. Also note that I’m sure there are lots more of these problems than what is listed below – especially for the “non-fundamental” changes. I got a lot of these from regional meetings and webinars, and I certainly didn’t attend more than a small fraction of those.

Problems that Don’t Require Fundamental Changes
1.       Section 4.2.2:  This section states that “All BES Facilities” are in scope for CIP v5. The only problem with that is that Facilities is a NERC-defined term, and it pretty clearly doesn’t apply to Control Centers, substations, and at least multi-unit generating stations. So are we correct to assume that none of these are in scope? If so, only a few things like UVLS and UFLS will be in scope. I’m sure most entities would be quite happy if that happened, but I’m taking a wild guess that this was not the intention of the SDT. Fortunately, this problem can be fixed very easily: use a lower-case f.
2.       Cyber Assets Located at Assets Owned by Other Utilities:  The CIP-002-5.1 RSAW requires the entity to identify and classify BES Cyber Systems that it owns, that are located at another entity’s assets. Unless the other entity has taken responsibility for compliance for these BCS, their owner needs to comply for them, as if they were located at one of its own assets. There is only one problem with this: Section 4.2 says that facilities “owned” by an entity to which CIP v5 applies are in scope. In other words, it doesn’t seem NERC has the authority, by the current wording, to bring these BCS at non-owned facilities (little “f” of course!) into scope. Either they should remove them from the RSAW, or change the wording of 4.2.
3.       List of BES assets:  The entity needs to develop a list of its BES assets that fall into one of the six types listed in CIP-002 R1, but this is never stated in R1. Since this is the list of locations at which BCS can be located, it is important for the entity to have this list to show it considered all required locations. See this post.
4.       BES Cyber System (BCS) Identification Methodology:  The entity needs to develop and document a methodology for identifying BES Cyber Systems. However, nowhere in R1 is the entity required to identify BCS (they are required to classify them in R1.1-R1.3, although the word “Identify” is misused there to mean “Classify”). See this post.
5.       Phone Systems:  One region has been insisting that VOIP systems in Control Centers should be identified as BCS; as far as I know, the other regions don’t agree with this – and I certainly don’t. A NERC FAQ stated that “support systems” wouldn’t be BCAs, but in the absence of a definition of support system this doesn’t help clarify the issue. This issue could either be resolved in a fundamental way (see this post and this one), or a non-fundamental way – by perhaps simply stating in the BCA definition that phone systems aren’t covered.[ii]
6.       HVAC Systems:  Similarly, some have wondered whether HVAC systems should be in scope for CIP v5. I don’t think these should be in scope, either, although I don’t think this requires some fundamental change.
7.       Grouping BCS by the Requirement:  It is never stated in CIP-002 (or elsewhere) that the entity can group BCAs into BCS in only one way; it is permitted to group them differently for each requirement if desired. There should be a statement in R1 (or the BCS definition) that this is permissible, rather than having to rely on the fact that it isn’t explicitly prohibited. See this post.
8.       “Assets Containing a Low Impact BCS”:  This wording in R1.3 is of course in direct contradiction with the parenthetical expression immediately following, which says “a discrete list of low impact BES Cyber Systems is not required”. In practice, both entities and auditors all seem to understand that what this means is really “low impact asset”. However, IMHO it is contradictions like this that make CIP v5 unenforceable in the strict sense. This is one of those items that can be addressed either through fundamental changes (where the whole relationship between assets, Facilities and BCS will be straightened out) or otherwise. In the non-fundamental approach, it would probably be OK to simply state that, if there are any Cyber Assets performing control functions located at an asset that does not otherwise contain High or Medium BCS, it will be up to the entity to demonstrate they are not BCAs. Getting down to the fundamentals would be a much better way to solve this as well as other problems, though.
9.       “Assets Containing Low BCS”:  I’m now going to seem to contradict what I just said. There can be assets that aren’t Low impact that do contain Low BCS. For example, a generating station that meets criterion 2.1 can have Low and/or Medium BCS. If the above problem is resolved in the non-fundamental way, then there will need to be a separate list of assets that aren’t Low Impact but nevertheless contain Low BCS. Again, it would be much better to get to the fundamentals and fix this for good.
10.   Attachment 1, Criterion 2.6:  This criterion reads “Generation….and Transmission Facilities..” Since “Facilities” is only applied to “Transmission”, this means that an entire plant is Medium impact, even if only one of its units is designated as critical to IROLs, since a unit is a Facility while an entire plant is not (on the other hand, in a substation only particular lines, transformers or other Facilities are covered by this criterion, not the whole substation). However, in the Guidance the SDT did refer to Generation Facilities, implying they meant to cover just a unit, not an entire plant.  The best solution is to change the criterion to say “Generation Facilities” not “Generation”.
11.   CIP-003-6 R1 – Cyber Security Policy:  R1 mandates an annual “review” of cyber security policies, but doesn’t require, if the review identifies changes that need to be made, that these changes be implemented. This should be corrected.[iii]
12.   CIP-004-6 R2.1 – Training:  There has been some confusion about whether R2.1 requires that each of the nine training topics needs to be included in the training for each role, or not. While I think the wording is fairly clear, it obviously needs to be made even clearer.
13.   External Routable Connectivity:  The current SAR has Low Impact ERC (LERC) on the agenda, but not ERC itself. The confusion about LERC is a mirror image of the confusion about ERC, so the answer to the one should lead to the answer to the other as well. I have stated a couple times that I no longer believe there can be a technical definition of LERC or ERC – at least, one that could be understood by mere mortals without a couple PhDs in data communications and computer science, along with an EE. The only way I see this working is if the SDT just comes up with a set of use cases, e.g. “In this situation, there is ERC. In that situation, there is no ERC.”
14.   PCAs, PACs, EAPs and EACMS:  Protected Cyber Asset, Physical Access Control System, Electronic Access Point and Electronic Access Control and Monitoring System are all defined, but the entity is never told to identify them. This should be corrected.
15.   EAPs:  The definition of EAP refers to an interface on a device like a router or firewall, not to the device itself. However, Cyber Assets that contain an EAP interface need to be designated as EACMS (I learned this from an article by Lew Folkerth from the April-May 2015 RF newsletter). It needs to be stated in the requirements or at least the Guidance.
16.   Scripts:  There has been a lot of debate regarding the status of custom scripts for CIP-005-5 R2. A FAQ indicated that these need to be treated as Interactive Remote Access, meaning encryption and two-factor authentication are required, and there needs to be an Intermediate System (which might be running the script itself). This should be stated in the requirement.
17.   “Component-level” Requirements:  As discussed in this post, the majority of requirements in CIP-003 through CIP-011 apply on the level of components of a BCS, not the BCS itself. However, this is never stated in the Applicability section. I believe this could be remedied fairly easily by stating “Components of BCS” rather than “BCS” in the Applicability section for all the requirements where this is the case.
18.   “Nonprogrammable communications components located inside both a PSP and an ESP”:  This phrase shows up only in the Applicability section of CIP-007-6 R1.2 (for Highs and Mediums), and nowhere else in CIP v5. The Guidance makes clear this applies to dumb hubs, patch panels, etc. (therefore, unnecessary physical ports need to be protected in these devices, as they need to be protected for BCS). Of course, these devices are not Cyber Assets at all, which makes R1.2 the only v5 requirement that applies to non-Cyber Assets (which of course goes against the whole purpose of CIP-002 through -011). Since this is really a physical security requirement, it probably belongs in CIP-006.
19.   CIP-007 R2:  “Software” is never mentioned in R2, but of course that is the whole point of the patching requirement. Every piece of software on every component of each BCS needs to be inventoried and the entire patch management process – identification of a source for patches, evaluation for applicability, etc. – needs to be applied to it. This should be made clear in the guidance, if not the requirement (this information came from Lew Folkerth’s presentation at RFC’s April 2015 CIP v5 workshop).
20.   Firmware: Firmware patches need to be tracked and treated just like pure “software” patches in CIP-007 R2. While this is allegedly implied by the current wording, a lot of entities didn’t realize that. It needs to be made explicit in the requirement.
21.   “Security patches”:  The Guidance for CIP-007-6 R2 points out that some patches are exclusively “functionality related” and therefore are not “security patches”. Security patches are the only ones the entity needs to consider for application. However, what about functionality upgrades (typically for firmware) that improve security by for example allowing complex passwords? The Guidance gives contradictory information on these. See this post.
22.   CIP-007-6 R4.2 – Alerting:  The Guidance and Technical Basis implies that technical means are needed for real time alerting. However, the requirement allows for procedural means as well. This needs to be reconciled (from WECC’s Advanced CIP Training in Sept. 2015).
23.   CIP-010-2 R1.1.3 – “custom software”:  “Custom software” installed on a BES Cyber System has to be tracked under the configuration management program. But what is custom software? Does it include every three-line script that has ever been put in place? And what about scripts that are part of a third-party software package? This needs to be fixed, perhaps with a definition of “software” or “script”.

Problems that Require Fundamental Changes
24.   Section 4.2:  This section states that “Facilities, systems and equipment” owned by entities subject to v5 (under section 4.1) are in scope. I have never been able to figure out what this means. Does it mean an entity has to evaluate every PC owned by the Accounting department, and every monkey wrench owned by Operations, to determine whether they’re in scope? I think something like “Facilities, assets and control systems” would be much better. But this needs to be done in the context of helping CIP-002 decide what it wants to be when it grows up – so it’s a fundamental issue.
25.    Breaking up CIP-002 R1: In CIP versions 1-4, describing how to identify and classify Critical Cyber Assets required three or four requirements. In CIP v5, the required steps (none of which are explicitly identified in the first place) are all compressed into R1, and this is one of the big reasons for the confusion regarding R1. I think there should be separate requirements, perhaps reading a) Identify assets that fit into one of the six types in R1 (these are the locations at which BCS can be found, not the assets that get “run through” the criteria in Attachment 1. See this post); b) At assets/Facilities meeting Medium or High criteria[iv], identify BES Cyber Systems and classify them according to the rating of the asset/Facility[v]; and c) List BES assets that don’t “meet” one of the High or Medium criteria, and that have control systems, as Low impact.[vi]
26.    “Affect the Reliable Operation of the BES”:   At the heart of the definition of BES Cyber Asset are the words “affect the reliable operation of the BES”; yet there is no explicit guidance provided on how this will be determined, although the discussion of the BROS in the CIP-002 Guidance and Technical Basis does provide some help. If “affect the reliable operation of the BES” means “aids in fulfilling one or more BROS”, this needs to be made explicit in the definition.
27.   “Facilities”: Criteria 2.3 to 2.8 all apply, at least in part, to Facilities, a NERC-defined term. In the case of 2.3, this means a unit in a generating plant. In 2.4 to 2.8, it means a line, bus, transformer, etc. typically found at a substation. This means that – with the exception of what seems to be an error in criterion 2.6, as noted below – none of these criteria apply to assets, either generating plants or substations. Of course, the majority of NERC entities and – probably – auditors understand these criteria as applying to assets. In general, there is nothing wrong with doing this, except that an entity might end up considering more BCS as being Medium impact than are actually required to be. But the difference needs to be made clear to the entities, possibly in the Guidance. This needs to point out that an entity can classify its BCS at a substation in two ways: either designate all BCS at a substation that "meets" one of criteria 2.4 to 2.8 as Medium impact, or separate out the Medium from the Low impact Facilities at the substation and classify their associated BCS as Medium or Low respectively.[vii]
28.   Transmission vs. Distribution Facilities:  It is well understood that in CIP-002 Cyber Assets associated with purely Distribution Facilities are not in scope for v5, even though the substation itself may be a Medium impact one. But if entities are going to officially be given the option of treating an entire substation as Medium impact, they need to be told how to separate out the Transmission from the Distribution systems. This presumably would require determining which Facilities fall under the BES definition and which don’t, although even that isn’t necessarily easy, as discussed in this post. In any case, this needs to be explicitly stated, at least in the Guidance.
29.   “Associated with”:  In order to classify a BES Cyber System as Medium or Low impact in a substation, the entity needs to know which substation or Facility it is "associated with", since Section 2 of Attachment 1 says that Medium BCS are those that are “associated with” any asset/Facility that meets one or more of the Medium criteria.  But "associated with" is not defined (note that I’m somewhat torn between saying this is a change of the first vs. the second type. It could in theory be possible to simply define “associated with” without requiring other fundamental changes – but a fundamental change might eliminate the need for “associated with” altogether. This item should really be listed in both categories).

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.

[i] In this post (as in most others), when I refer to CIP v5 I’m implicitly referring to v6 as well.

[ii] There are of course other means of resolving this dispute as well, such as mortal combat with rapiers.

[iii] This point was made at an EnergySec webinar last year.

[iv] Of course, as currently written the criteria don’t officially apply to assets or Facilities, but to BES Cyber Systems, even though everyone interprets them that way. Again, this is one of the problems that keeps CIP v5 from ever being enforceable, even though it may not be causing day-to-day problems.

[v] Naturally, there is at least one exception to this. In criterion 2.1 generating plants, some or even all of the BCS may be Low impact, even though the plant is technically “Medium”.

[vi] Unless the entity can demonstrate that none of these control systems would be BCS.

[vii] Understanding that “Facilities” isn’t a synonym for “assets” is important in other cases, as well. For example, the argument NERC used in their Lesson Learned on far-end relays relies on the reader understanding this distinction. See this post.

No comments:

Post a Comment