NERC’s new CIP-013 FAQ part II

This is the second in a series of posts (at least three and maybe four) on NERC’s new CIP-013 FAQ. I’ve reproduced the first two paragraphs of the first part below, with some modifications. All of the rest is different.

NERC released a new CIP-013 FAQ to the industry in December. It’s based on the CIP-013 Small Group Advisory Sessions that were held in the fall of 2019 BC (Before Covid). This is the second FAQ NERC has released based on those sessions; the first one came out last February. This new FAQ includes all of the questions and answers in the old FAQ, as well as others in an Addendum.

For this post, I continued with the questions in the FAQ, although I skipped a few where I didn’t have much to add to what NERC said. As in the first post, for each question I provided the question, NERC’s response and then my response. Note that almost everything I say in this post is shamelessly stolen from my upcoming book “Supply Chain Cybersecurity for Critical Infrastructure”, which I expect to have published in February, or March at the latest.

What if my vendor cannot adhere to one or more sub-parts (1.2.1-1.2.6) in Part 1.2 for CIP-013-1?

NERC’s answer: The registered entities are still responsible for implementation of Part 1.2 in R1. Registered entities should have documented and implemented controls for Part 1.2 in the absence of vendor adherence. For example, if the registered entity’s vendor is not notifying it of vendor-identified incidents, then it may implement a control that monitors US-CERT, ICS-CERT, E-ISAC, and NERC Alerts.

Tom’s answer: What NERC says is spot on. I would word it more generally that the entity is responsible for mitigating all risks identified in their supply chain cyber risk management plan, whether it’s a risk from R1.2 or a risk the entity identified in R1.1. There are probably a few risks that can only be mitigated by the vendor (although I have yet to identify one of those), in which case you will probably have to accept it if the vendor simply won’t do their part to mitigate the risk.

In general, there’s always something your organization can do to mitigate a vendor risk, when the vendor won’t do it themselves. However, it’s true that whatever you do will almost never be as good as what the vendor could do if they had the inclination. But you still need to do what you can.

What additional frameworks did registered entities consider in development of Supply Chain Risk Management Programs? Furthermore, are entities developing one or more risk assessment questionnaires?

NERC’s answer: Entities considered NIST, NAGF guidance, NATF guidance, EEI guidance, SOC2, and ISO 27001 in developing their SCRM programs. In most cases, registered entities used two risk assessment questionnaires, one for vendors and one for products or services.

Tom’s answer: As far as the first question goes, I’m OK with NERC’s answer, except I don’t know what they mean when they say “EEI guidance”. EEI has put out a set of recommended procurement contract terms based on the R1.2 items (although they go beyond what’s stated in R1.2), but I don’t believe they’ve put out supply chain cyber risk management guidance in general, as is found in the other frameworks or white papers that NERC mentions.

For the second question, I’m sure there are some NERC entities that put out two risk assessment questionnaires, but I have no idea who you would send a “product or service” questionnaire to, other than the vendor. But since you have to send it to the vendor, why do you say it’s different from the vendor questionnaire?

This relates to the question of whether product/service risks are different from vendor risks. I agree there are some vendor risks that have nothing to do with one of their products – for example, that the vendor won’t properly control access to your BCSI, and it will end up in the hands of ISIS. But nobody has yet given me an example of a risk that is due only to the product and not to the vendor. After all, any product risk will have to be mitigated by the vendor, right? Why not call it a vendor risk?

This is more than just a question of semantics. I think a lot of what some people call product risks are vulnerabilities, not risks. Suppose that vulnerability X (maybe CVE X) is discovered to be present in a particular software product. Vulnerabilities happen all the time, and they’re usually patched quickly (say within a month or less, with an emergency patch being rushed out when a very serious vulnerability is identified).  These aren’t risks.

The risk is that a vendor won’t quickly provide a patch for a vulnerability, or provide some other mitigation if for some reason they can’t quickly patch it. Your organization needs to ask your main contact at the vendor whether they promise to patch vulnerabilities quickly. If they won’t promise it, then you should seek to include this requirement in contract language, or simply escalate the issue at the vendor – until somebody with the authority provides you the promise you need (and it doesn’t even have to be written. Just write a memo to yourself after the phone call, documenting what the vendor said. If it was a high enough person that made the promise, the vendor will live up to it, although you may still have to push them on it).

Of course, as I’ve pointed out multiple times in blog posts (and I certainly say this multiple times in my book!), a promise alone – even if it’s made in a contract – doesn’t in itself mitigate any risk. It’s only if the vendor keeps their promise that risk is mitigated. It is up to your organization to verify they kept their promise. The best way to do this is to make sure you have a question relating to the promise on the annual BES cybersecurity questionnaire you send to them. If they promised to do X but the next questionnaire reveals they still haven’t done X, then you need to contact them and ask when they will do X. If they give you a date but blow it off again, that’s when you need to ratchet up the pressure, perhaps bringing in your lawyers if need be (but I believe you shouldn’t involve the lawyers until it’s clear you’re not getting anywhere with the people you’re talking to – and if they’re really playing around with you like this, do you really want them as a vendor in the first place?).

I’ve gone a little off the subject here, but the point is that all supply chain security risks are due to either the vendor or the customer organization. I don’t see “product risks” as a third category, although if you want to use the word with the understanding that you’re really talking about a certain type of vendor risks, I’m fine with that.

What is the registered entity’s obligation to mitigate an identified risk, if the vendor does not agree under the contract, for example, shipping and delivery?

NERC’s answer: A vendor’s intentional or unintentional ability to adhere to the conditions of an agreement as it relates to CIP-013-1 should be identified and assessed as a risk. As with all of the risks, it is the responsibility of the registered entity to mitigate them accordingly. As an example, the registered entity may address this risk by the implementation of internal controls and processes such as using reputable shippers, tracking shipments, and requiring signatures on delivery.

Tom’s answer: NERC’s answer is fine, but I want to add that I consider shipping and delivery to be a risk that applies to the customer, not the vendor. After all, legal title to the product being shipped usually passes to the customer at shipment (that’s what F.O.B. means – free on board. If you want to drive to the vendor and pick the product up, that’s OK. But if you want the product shipped a particular way, it’s up to you to make clear to the vendor that’s what you want and it’s up to them to accommodate you – although you should expect to pay more if you’re asking for something more than “normal” shipping, e.g. requiring chain of custody information).

What is sufficient evidence to document cases in which vendors refuse to meet the CIP-013 R1 Part 1.2 Requirement Parts?

NERC’s answer: In this case, the procurement documents (e.g., RFP and vendor response evaluation matrices) used for a specific applicable procurement, along with any contract language connected to the procurement can serve as primary evidence the registered entity pursued its due diligence for the R1 Part 1.2 Requirement Parts, when the vendor failed or refused to comply. As stated in R2, vendor performance and adherence to a contract is beyond the scope of R2, so the responsibility of compliance rests on the registered entity to demonstrate it implemented its Part1.2 processes as far as it could reasonably go without negating the procurement. Since the registered entity identified risk, it is incumbent on the registered entity to enact mitigating measures that would address the vendor’s refusal to meet the Requirement Parts.

Tom’s answer: NERC’s answer is correct, but they didn’t answer the question. That’s because I believe the person who asked the question was essentially saying “I believe that if I just document that a vendor won’t do something that they’re supposed to do per one of the Requirement Parts of R1.2, then I’ll be off the hook for the Requirement Part itself. If I can just get NERC to tell me what the required evidence is, that will validate my belief and I can start going home at 5:00 from now on.” I don’t think they were looking for NERC to tell them the truth, which is that they’re on the hook to mitigate the risk behind the Part as much as they can, even if the vendor doesn’t cooperate at all.

This means that, if a vendor won’t cooperate, you should focus on showing first that you really tried to get them to do it. You don’t just throw some contract terms at them and, when they refuse to sign them, declare that you’ve done all you can to comply with that Part. You can have a talk with them, explain the importance of the item you’re requesting (e.g. notification of incidents they identify, per R1.2.2), and suggest they give you a letter, an email or even just a verbal agreement (which you then document in a memo to yourself), since contract language isn’t agreeable to them. In fact, whenever there’s a choice, I would try for the letter, email or verbal statement first, and only go to contract language when they refuse to provide one of those others. It will be a lot less expensive to your organization, plus I’d say there’s a good chance they’ll agree to what you want without your putting a legal gun to their head.

It also means that the important documentation in this case is copies of emails, etc. showing that you tried to convince the vendor to agree to – using the example of R1.2.2 – notify you when they identify an incident that could affect the security of one of their products that you have installed in an ESP. It’s not the email they send you when they refuse to do sign the particular contract ter,m you stuck under their nose. If you were turned down when you simply asked them to do this (and I would give it 2-3 tries before giving up), you will need to provide a description (and some kind of evidence) of what you did to mitigate the risk, even though it will never be as good as if the vendor had agreed to do it.

For example, in the case of R1.2.2, one way to mitigate the risk that the vendor won’t notify you of an incident with one of their products is to monitor the ICS-CERT emails and other sources, where you might expect to see an announcement of e.g. a new vulnerability in one of the vendor’s products.

Is it time to review your CIP-013 R1 plan? Remember, you can change it at any time, as long as you document why you did that. If you would like me to give you suggestions on how the plan could be improved, please email me so we can set up a time to talk. Also, if you work for a supplier trying to figure out what you need to do to help your power industry customers comply with CIP-013-1 (without wasting money on unneeded certifications), please contact me.

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.