Lew nails another one!

I was quite excited when I got RF’s latest newsletter yesterday, since I knew that Lew Folkerth was going to have his (alleged) last article on CIP-013 in it. I read it thoroughly this morning, and I have to say this is the best of his articles on CIP-013 so far. What’s also good news is that, in writing the article, he realized he was going to have to separate it into two (this has happened to me a number of times also).

In this article, Lew planned to write about CIP-005 R1.4 and R1.5, and CIP-010 R1.6 – which are three new requirement parts that will become enforceable on July 1, 2020, the same day as CIP-013-1 becomes enforceable. But he ended up devoting the entire article to just the CIP-005 parts; the CIP-010 part will be the subject of the next one. He implies this will be the last of his CIP-013/supply chain risk management articles, but I certainly hope it won’t be – there’s a lot more that can be said about this.

You can find the article by going to RF’s home page and finding the May-June 2019 newsletter, then clicking on “The Lighthouse” in the table of contents. However, Lew gave the article by itself to me in PDF format, and I’ll be glad to send that to you if you want to drop me an email at the address below. In fact, for a limited time, Lew has made available a single PDF including all four of his CIP-013 articles so far, and he is offering that for the same price as this article by itself - $0.00 (US)! You should act now to take advantage of this incredible offer! No salesman will call…

As I started reading the article, I was struck by one point after another that I hadn’t realized, and I started writing them all down. After writing down about 4 or 5, I realized I might as well just let you read the paper to get the rest, but here are the most important takeaways I got out of Lew’s article:

1. I admit that I had a fairly low opinion of the new requirement parts that the CIP-013 drafting team added to CIP-005-6 R2 and CIP-010-3 R1. This was because I thought of these as new prescriptive requirements that would conflict with the risk-based, objectives-based nature of CIP-013. I explained that in this post (and the earlier one linked in it). But reading Lew’s article made it very clear to me that CIP-005-6 R2.4 and R2.5 are objectives-based, since they give you an objective to achieve, and don’t specify how you need to achieve it.
2. However, are these two requirement parts also risk-based? My answer to that is yes, even though the word “risk” isn’t to be found anywhere in them. In determining how you will comply with the two requirement parts (that is, what technologies or procedures you should deploy), you certainly should take risk into account. You should never put a $50 lock on a $10 bike, and you shouldn’t, for example, implement and tune a layer three firewall just for compliance with R2.5, unless the likelihood and/or impact of a compromised remote access session being allowed to continue are significant.
3. A good indication that these parts are risk-based is found on page 15, where Lew discusses how you can categorize, classify and prioritize different types of communications traffic – and, of course, apply different controls to different traffic depending on its category, classification and priority. You simply can’t do this in a prescriptive requirement like CIP-007 R2 or CIP-010 R1, where you have to do the same things to every component of a Medium or High BES Cyber System, or risk getting your head cut off.
4. Lew’s item 2 on page 15 points out that these requirement parts include undefined terms, which I take to include “determine”, “system-to-system”, “disable”, and – the most glaring omission of all in CIP-013 - “vendor”. Of course, these are hardly the first cases of undefined terms in the CIP standards. CIP v5 included many undefined terms, including “generation”, “station” and “substation” in CIP-002 R1 Attachment 1, as well as terms like “programmable” (in the Cyber Asset definition), “affect the reliable operation of the BES” (in the BES Cyber Asset definition), “adverse impact” (in the BES Cyber Asset definition), “associated with” (in CIP-002 R1 Attachment 1), “security patch” (in CIP-007 R2), and “custom software” (in CIP-010 R1); so this is hardly a new development. I certainly understand there are very good reasons why all of these terms were left undefined, but on the other hand some people at NERC and elsewhere talk about the CIP standards as if they were clear as day, so that if entities are confused and get violations, it must be because they just aren’t trying hard enough. This is far from being true.
5. Lew’s point about these undefined terms in CIP-005-6 R1.4 and R1.5 is exactly the point he made in 2014, as it began to become clear that there would never be clear answers to most of the ambiguities, implicit requirements and undefined terms in CIP v5: It’s up to the entity to a) look at all the available guidelines, guidance, etc. and then b) determine and document for themselves how they are interpreting these questions and definitions (although in his article he suggests that the entity should “use commonly accepted definitions”. It would be nice if there were commonly accepted definitions for these terms, but in most cases there simply is none).
6. In item 3 on page 14, Lew notes that all data communications, including dial-up and serial, need to be included in the scope of CIP-005-6 R2.4 and R2.5 – not just routable communications. This might seem to some people to constitute a huge increase in scope in itself, but keep in mind that the fact that these are risk-based requirements is your friend. Given that there has never been a successful cyberattack over serial communications, the likelihood of such attacks is extremely low, meaning the risk is extremely low – so you just don’t have to make the same effort to remediate risks in serial communications as you do for routable communications (I’ll admit that the risks posed by dial-up communications are much higher, which is why so many entities have already mitigated that risk by not allowing dial-up at all).
7. In item 4 on page 14, Lew says “In my opinion, identification of malicious remote access sessions and disabling of such access should be achieved in seconds or minutes, not hours or days.” This might seem like a requirement to write blank checks to the current preferred suppliers of whiz-bang devices that purport to do this, but again you need to keep in mind that this all depends on the risk posed by the communications. For example, if we’re talking about a high-voltage substation that feeds all of downtown Manhattan, this might be the right approach. But if we’re talking about a relatively low-voltage substation serving mostly rural areas outside of Manhattan, Kansas, it might be overkill.
8. Lew points out in item 5 on page 14 that, since the word “vendor” is undefined in R2.5, which says “Have one or more method(s) to disable active vendor remote access…”, you are better off not trying to split hairs on the definition, but simply apply the same controls to all communications into and out of an ESP at a Medium or High impact asset.
9. Lew’s item 6 on page 14 contains some very good observations on incident response plans, for the case where you do detect some suspected malicious communications into an in-scope ESP.
10. My final observation (besides to say that you need to read the whole article, and carefully!) is on the paragraph titled “Response Planning” at the bottom of page 17. There, Lew makes the excellent point that your response to detected improper access to Medium or High impact BCS should involve “manually-initiated automated processes”. I’ll let you read the details, but this is really good advice, and might be a good principle for securing ICS in general.

  

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. To discuss this, you can email me at the same address.