In my previous post,
I described how an RFC auditor, Lew Folkerth, expressed opinions at last week’s
CIP Workshop in Cleveland that agreed closely with what I had written the
previous week in this
post. He had reached the same conclusion
before I had reached it, so he certainly wasn’t repeating what he had read in
some disreputable blog. I won’t repeat
what these two previous posts said, other than that I think the topic is quite
important for any NERC entity that needs to comply with CIP version 5.
And now I’m pleased to report that another
auditor from another region – who I thought might perhaps thoroughly disapprove
of the idea of “rolling your own” CIP v5 definitions and requirements – seems
to basically agree with the concept. In
fact, it also seems that he has been seeing entities doing this for a
while. So I may not actually be starting
a revolution by advocating this approach, but merely reporting on one that is
already in progress.
This second auditor does make one point about
this whole idea that I may not have emphasized enough in the previous two posts
(although I completely agree with it): He reminds NERC entities that, as they
“roll their own” requirements and definitions, they need to make sure they are
firmly rooted – as much as possible – in the actual wording of the current CIP
v5 standards.
This may seem obvious – it seems intuitive
that nobody would simply make up a new requirement or definition to replace the
current wording in CIP v5. Yet, this
auditor says that he has already seen “too many proposed compliance approaches
already where the approach does not align with the language of the standard.” He also says that often it seems the
“proposed compliance approach” is from an allegedly reputable consulting
organization that presumably “may not know how to put a solution into place
that aligns with the requirement (or they may feel it is too expensive or
otherwise not worth the effort) and cuts some corners.” So caveat
emptor.
Furthermore, the auditor points out “entities
should also make sure perfection (or elegance) is not getting in the way of
good enough. I have seen two similarly sized and configured entities
solve a problem and achieve compliance – one with a very expensive (to license
and then to maintain) technical solution, and the other with an Excel
spreadsheet. A spreadsheet might not be ideal, but if it works and you
only have 18 months to get something into place, it just might be the trick
until you can do your process improvements further down the line.”
I’d like to expand on his last sentence. What I think he’s saying is that it does no
good to purchase an automated solution when you don’t properly understand the
process on which it needs to be based.
And – as I’ve said repeatedly over the last year and a half – it is
literally impossible to completely understand the processes required to comply
with some of the requirements of CIP v5.
Each entity will need to develop its own definitions and interpretation
of each requirement where there is ambiguity (this applies especially to
CIP-002-5.1 R1, but also to other requirements where there are ambiguities but
there is no longer enough time for NERC to address those in a comprehensive
fashion).
By the same token, the developers of any
automated solution have to develop their own interpretations as well. The trick is for the entity (i.e. the
purchaser of the automated solution) to figure out whether the
“interpretations” at the basis of the automated solution in question are ones
it agrees with or doesn’t. You should
never assume that, just because a vendor has spent a lot of time coding some
software, that they must have some privileged knowledge of what the CIP v5
standards really mean; they don’t.
I guess the best way to summarize what this
auditor says is that a lot of CIP v5 compliance money and effort are already
being wasted, both on consultants who aren’t trying to adhere as closely to the
v5 standards and definitions as possible, as well as on “elegant” purchased technical
solutions that may end up not being as good as a spreadsheet-based approach.
The other takeaway, of course, is that this
auditor does agree that, where there are ambiguities in the CIP v5 requirements
and definitions, entities need to “roll their own” requirements and
definitions, while keeping as close to the actual wording as possible[i]. There
are certainly some requirements and definitions where there is no ambiguity,
and these should be followed to the letter.
The views and opinions expressed here are my
own and don’t necessarily represent the views or opinions of Honeywell.
[i]
The auditor elaborated on some cases where entities (or the consultants they
had hired) were not adhering as closely as possible to the v5 wording. He said, “I am seeing issues with ESP
definitions, Interactive Remote Access, and the like. I am also seeing
entities argue that the standards apply to BES Cyber Systems (true) and
therefore nothing can apply to a unique Cyber Asset itself (not so true – I
have yet to see how you apply a security patch to a BES Cyber System that is
comprised of Linux servers, Windows workstations, and Cisco networking devices,
without getting into Cyber Asset granularity)."
He continues, "I am not so much saying “roll your own” as I am saying
the entity needs to carefully read the requirements and do what the
requirements say. If you are supposed to have an encrypted tunnel between
an external workstation and the Intermediate System (the requirement is to
terminate the encrypted tunnel at the Intermediate Device), then terminating
the encrypted tunnel at a VPN concentrator or firewall (the DMZ border) and
then passing clear text traffic to the Intermediate System is not
compliant. Similarly, since the requirement is to have outbound rules for
permitted traffic and deny everything else, having a full Class C outbound
permit command to any port, anywhere, is not compliant unless you can justify
why such broad permissions are needed."
No comments:
Post a Comment