The NATF Questionnaire: Deciding which questions to use (part II)

Note from Tom: If you’re only looking for today’s pandemic post, please go to my new blog. If you’re looking for my cyber/NERC CIP post, you’ve come to the right place.

This is the second part of last week’s post, on NATF’s recently-released set of questions to vendors; it is designed for electric utilities, and especially those that have to comply with the upcoming NERC CIP-013-1 Reliability Standard. That post discussed the fact that a large number of NATF’s questions (more than half) don’t, in my opinion, address significant risks to operations – and CIP-013 is all about operational risks, namely risks to the Bulk Electric System.

At the beginning of that post, I listed three reasons why I try not to include questions that don’t address significant BES risks in my questionnaire (which I’ve developed with input from my CIP-013 clients). The first was simply that it wastes a lot of time – both the vendor’s time, since most of these questions require research to develop an answer (sometimes significant research), and the NERC entity’s time, since each answer needs to be evaluated (and if you’re not going to evaluate the answer, why did you ask the question in the first place?). I addressed this reason in part I.

But while wasting time is certainly undesirable, this is the least important of my three reasons. The other two are:

1. There are important risks that I and my clients have identified that aren’t in NATF’s list, although we believe they’re important to address with questions. More generally, every NERC entity faces its own set of risks, and they shouldn’t feel they can’t ask any more than what’s in the NATF questionnaire.
2. As I pointed out in this post, asking unnecessary questions increases compliance risk for CIP-013. So asking questions about risks that don’t impact the BES can literally lead you into non-compliance, as I’ll discuss in part III of this post.

Let’s look at the first of these two reasons. After going through all of the NATF questions, I found about 25 of my questions that aren’t addressed at all in NATF’s questionnaire. This includes:

a.      Does your product require authentication of firmware updates? The fact that the RTU’s in the substations that were attacked in the Ukraine in 2015 didn’t require authentication for firmware updates allowed the Russians to brick them.

b.      Do you require separate authentication for access to your software development network and/or hardware manufacturing network?

c.      Will you inform us within 5 days of any new vulnerability discovered in any third-party or open source component of your software or firmware, whether patched or not?

d.      Does your security policy prohibit the use of binary or machine executable code for which you are unable to verify the integrity of the software?

Of course, nobody has to agree with me that these questions address significant risks to the BES. But if you do, wouldn’t you want to ask them, instead of questions that you may not believe pose a significant BES risk?

You might ask “What’s to stop me from asking these questions, along with all the NATF questions?” Of course, there’s nothing to stop you, and in fact two of the vendors listed in the webinar as being on board with the NATF questionnaire (SEL and OSI) told me recently (in the posts just linked) that they’ll be glad to answer any questions provided to them. On the other hand, I’m sure they’d both like you to look through their answers to the NATF questionnaire (which I’m sure they’ll make available to customers, although perhaps not the general public) first, to see if some of your questions have already been answered there.

However, I know at least a few vendors have said at various times – and this was said during the NATF webinar, although not by a vendor – that they just want to have a single questionnaire that the whole industry will use, and they’d prefer not to answer any questions not on that questionnaire. This raises the possibility that some vendors will simply refuse to answer any questionnaires that include questions not in the NATF questionnaire.

Here’s my opinion on this issue: This is a free country (at least it was as of this afternoon at 5:06 PM Central Time). If a vendor doesn’t want to answer one of your CIP-013 questions – even though you think it addresses an important BES risk – that’s their prerogative. However, CIP-013 still requires you to assess the vendor on this risk; if they won’t cooperate, then you should probably assume (unless you have good reason not to, of course) that they likely pose a high level of risk for the questions that you asked.

This means you should take steps to mitigate these risks on your own (as NERC asserted in their CIP-013 FAQ). The strongest mitigation is to stop buying from this vendor altogether, although that’s often impossible to do. In that case, you would want to implement a mitigation that is something you can totally control. To use the example of the risk that the product will allow unauthenticated firmware updates (the basis for the first of the four questions I listed above), you could restrict physical and electronic access to the facility where the product will be located.

And this happens to be one mitigation that you almost certainly have already implemented, since any Medium or High impact BES asset is subject to compliance with CIP-005 and CIP-006, and presumably has very good controls in place for physical and electronic access. You just need to document that fact, and IMHO you shouldn’t feel obligated to implement any further controls. But you won’t always be this lucky.

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. Are you working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!