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