Roll Your Own, Part VII: The Return of Lew Folkerth

A week after I’d posted my first post in the “Roll Your Own” series in September, I attended an RFC meeting on CIP v5 where Lew Folkerth (of RFC) gave a presentation that seemed to agree strikingly with what I had just posted.  It wasn’t that he’d copied me; in fact, he had clearly been thinking about this issue long before I had, and frankly had a more sophisticated take on it.  I summarized his discussion in this post.

Now, Lew has documented his position in a very good article in RFC’s newsletter (you can find the newsletter here; his article is on pages 8 and 9).  I highly recommend you read the article, but here are my main takeaways:

1. When he sent me the article, he pointed out that he’s not a big fan of my phrase “roll your own”.  He much prefers something like “do the best you can with what you’re given”; I certainly agree that is also a good description of what I’m talking about.
2. My approach has been fairly narrowly focused.  Briefly, I’ve been saying in the “Roll Your Own” posts that, because some requirements in v5 are ambiguous, and because some required definitions are simply MIA in CIP v5, the entity needs to come up with its own interpretations of the former, and essentially create the latter as best they can. 
3. Lew is taking a broader view of the problem – and requiring more work of the entity.  He’s saying that, in any case where an entity has honest doubts about what a requirement means (and where there hasn’t been good guidance provided by NERC or the Regional Entity), the entity needs essentially to rewrite the requirement so it applies directly and clearly to the entity’s own situation. 
4. Specifically, he says the entity should “Determine what the Requirement intends to accomplish in the context of the entity, and how the entity will address this intent.”  Having rewritten the requirement so that it includes this, the entity needs to comply with the rewritten requirement in the same way they would if they were just following the given language of the requirement; this should be repeated for each requirement where there is ambiguity.  Essentially, he’s saying you need to come up with “Entity X’s CIP Version 5”[i], and simply comply with that[ii].  
5. You can hopefully see that this goes well beyond what I’ve been saying, since I’ve been focusing on clarifying the wording of each requirement, not on determining the intent of the requirement and how it applies to the entity’s specific environment.  I do agree that Lew’s approach is superior, although it will require more work of the entity, especially in determining the “intent” of the requirement.[iii]
6. Lew uses R1 from CIP-010-1[iv] as his example, pointing out that the entity really needs to define the term “software” so that the requirement reflects “what the Requirement (meaning the original requirement) intends to accomplish in the context of the entity”.  He stresses that, if you simply take “software” to mean all small scripts, etc, you will be creating a huge burden for yourself, for little or no gain in BES reliability.  This part of the article is worth the price of admission (actually far more, since it’s free) all by itself.
7. Lew also puts this in the context of RAI (especially his Step 3).  That is certainly something that entities need to think about more and more as they determine how they will comply with CIP v5.

  

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

---

[i] As in other posts, I’m using “CIP Version 5” in the way it’s commonly used: to refer to the mixture of v5, v6 and v7 standards that entities will actually have to follow, not the ten v5 standards approved by FERC in Order 791. See this post for a list of the actual standards you will have to comply with.

[ii] Of course, I’m not saying (and Lew isn’t either) that the entity needs to rewrite every requirement in v5.  Most of the requirements are fairly clear, and don’t need to be interpreted by the entity.  However, the ones that aren’t clear (especially my favorite, CIP-002-5.1 R1) can cause lots of problems.

[iii] I don’t think Lew means “intent” in the sense of “the intent of the Standards Drafting Team”.  I have previously written that trying to discern that intent, or use it to interpret the requirements of v5, is a fool’s errand.  I believe he’s simply saying that, by closely reading all of the v5 requirements, the Guidelines and Technical Basis and the Lessons Learned, as well as using background documents like ES-C2M2 or the SANS Critical Security Controls, you can get a good idea of what the requirement would mean in your environment.

[iv] He writes “CIP-010-1 (and -2)” in his article, since I think he wrote it before v7 made its appearance on the scene.  In fact, the version that entities have to comply with will be the v7 version, or CIP-010-3.  Things move fast here in the NERC CIP world.