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."