NERC’s CIP-013 FAQ

As unaccustomed as I am to praising NERC, I have to say that the FAQ on CIP-013 that NERC released a few weeks ago (you can find it here) is spot on. I don’t have any major issues with what was said, and I think it shows the people who prepared the FAQ have a good overall understanding of the standard, which is quite different from the previous CIP standards. I’ll discuss some of NERC’s answers in this post, and hopefully later I’ll address some more in another post (although I won’t call this Part I, since I have a long history of writing Part I and never getting around to Part II).

One question I hear all the time is “Do we need to address procuring X under CIP-013?” One of the questions in the FAQ was of exactly that form: It asked “A registered entity buys equipment from a vendor with third-party software installed. What are your recommendations for showing evidence of due diligence?”

When I get a question like this, I always turn it around and ask “Could X pose any risk to the BES if procured and installed in one of our ESPs? In this case, the question would be “Could that third-party software pose any risk to the BES when you install the hardware it’s on?” Of course, the answer to that is yes, it could; there’s nothing special about buying pre-installed software that makes it not carry any risk at all. As with any procurement, you need to identify all of the risks that apply to the procurement (and installation), and determine whether they have all been sufficiently mitigated (either by the supplier or by your organization, in the case of risks that apply to you). If any of them aren’t fully mitigated and there is residual risk, you need to identify mitigations you can apply during the procurement and installation of this product.”

NERC’s answer to the above question was “The registered entity should use its SCRM plan to identify and assess the risks associated with the third party software installed. The results of this analysis would dictate what mitigations are appropriate to address the risks related to the third party software…”

Of course, you may well run your risk assessment and determine there are no significant risks that aren’t already mitigated – meaning there isn’t any residual risk to be mitigated in this procurement. In the above example, you should run through the same set of risks that you would consider for any other software procurement under CIP-013 – for example, the risk that the Supplier of the software won’t regularly patch (or otherwise remediate vulnerabilities found in) third-party and open source software that is included in their product. If you decide that the Supplier has already sufficiently mitigated all of the risks that apply to procuring the software (and also that your organization has sufficiently mitigated the risks that apply to you, such as the risk that your staff won’t install the system in a secure manner and it will be vulnerable to an attack), then you don’t have to take any particular mitigation measures with regard to the software, other than those you take with any procurement/installation of BES Cyber Systems.

The compliance risk here might come if you don’t consider all of the “normal” risks that you consider for a piece of software in other procurements, and you haven’t documented why you didn’t consider the others. For example, if you decided that the risk that a backdoor was planted in the software while it was being developed doesn’t need to be considered in this case – but you have considered this in other procurement risk assessments - you definitely need to document why you didn’t consider it here.

You might point to the fact that this system will be on a High impact Control Center network that is protected by all of the controls in CIP-005 and CIP-007; thus, it would be very unlikely that someone could even reach the system to exploit the backdoor. That’s a good reason, but you need to document it during the procurement risk assessment, not wait until you get audited three years later and have to rack your brain to remember why you didn’t consider it when the auditor asks you that question.

Another question in the FAQ follows along the same line. It reads “Is open source software in scope for CIP-013-1 and CIP-010-3?” NERC’s response is “The Supply Chain Standards are silent on terms and conditions for procured products or services that registered entities may install. A registered entity should implement its risk identification and assessment methodology for all procurements and installations of open-source software on applicable BES Cyber Systems.” 

Let me paraphrase NERC’s answer: “It doesn’t matter if it’s open source software or not. You still need to consider the risks attendant on procuring and installing it. Of course, with open source software, there are important risks you need to assess, that you don’t have with commercial software. A good guideline on these is one of the papers produced by the Supply Chain Working Group, available here.”

Another type of question I see a lot of is questions regarding contracts. A lot of people in the NERC CIP world have formed the idea that contracts have some sort of special status in CIP-013 compliance, apart from all other mitigations that a NERC entity might apply to supply chain cyber risk. One of the questions in the FAQ is “Can a registered entity provide redlined contracts, demonstrating contract negotiations, as a part of our evidence to prove compliance with CIP-013-1 R1 and R2?”

NERC’s answer reads in part “…the R1 plan should provide processes and procedures to indicate how the registered entity will meet the security objectives of CIP-013-1 and address each component of R1 Part 1.1 and Part1.2. While redlined contracts may serve as evidence of R2 implementations, the R1 plans should describe the registered entity’s methodology for identifying and assessing risks associated with applicable procurements. Contracts may be a component of the R1 plan, but the registered entity should ensure the procurement documents support the development of a contract that meets the CIP-013-1 security objectives.”

Here’s my translation of this (I took four years of NERC-speak in college, so I’m fluent in that arcane dialect): “To comply with R1 (both R1.1 and R1.2), you need to develop a plan that demonstrates how you will identify, assess and mitigate supply chain cybersecurity risks to the BES (the plan needs to include the six – really eight – risks in R1.2, but you can’t limit your plan to addressing just those risks). To comply with R2, you need to show how you implemented that plan. Contracts are one way to mitigate those risks, so the redlined contracts could serve as part of the evidence for R2 compliance.

“However, you should keep in mind that the important thing isn’t that you got a vendor or supplier to agree to mitigate particular risks, but that they actually did it. This means your plan must discuss not only how you will use contracts for risk mitigation where possible, but how you will verify that the supplier is actually following through on what they promised. And if they don’t follow through at some point, the plan needs to describe how you will endeavor to get them to forsake their wicked ways and keep their promise. And you’ll need to have some documentation that you did this, including copies of emails, memoranda of phone conversations, etc.”

Speaking of contracts, another question reads “What if a registered entity has a master agreement effective before the effective date of CIP-013-1 (July 1, 2020) which does not include terms associated with CIP-013-1 R1 Part 1.2 and its sub-parts, and purchase products or services after July 1, 2020; do I need to conduct a risk assessment on the vendor?”

NERC’s response reads “The risk assessment should be performed on the vendor, product, and/or service as dictated by the SCRM plan. The registered entity’s SCRM plan determines where and how the risk assessment is performed. Regarding R1 Part 1.2 and its sub-parts, while the action to renegotiate or abrogate existing contracts is not required, it is expected that mitigations are implemented to address the risks of these elements not being contractually binding on the vendor. All procurements of products or services applicable to high or medium impact BES Cyber Systems after July 1, 2020 would be applicable, under the R1 SCRM plan and R2 implementation.”

I interpret this to mean “First, you need to distinguish vendor, product or service risk assessments from the actual procurement risk assessment you need to perform for every procurement (and you should read the current NERC Evidence Request Spreadsheet section for CIP-013 for a description of the documentation you’ll need regarding the procurement risk assessment, since CIP-013 audit evidence requests will ask for this evidence and this evidence alone); you can perform the vendor risk assessment whenever you want, as long as you follow what you said you would do in your R1.1 plan (I’m recommending that my clients perform vendor risk assessments – using questionnaires – once a year).

“However, you do have to do something in order to be compliant, which is to perform a procurement risk assessment with every procurement. And since this purchase is a procurement, you need to do one of these here, and it needs to address all of R1.1 and R1.2 (which BTW is exactly what the Evidence Request Spreadsheet requires).”

I agree with all of NERC’s answer so far, but there’s one subject they’re avoiding: There’s no NERC definition of a “procurement”, meaning it’s up to the entity to define what it means. This is just like in the runup to CIP v5, when the entity needed to define for themselves what “programmable”, “affect the BES”, “reliability purposes” and other terms meant. And if you never did that, you still need to do it today, since compliance with the current CIP standards (including CIP-013) continues to be based on these undefined terms.

For example, if you don’t define these terms, you might be at the mercy of an auditor who says that you didn’t identify Cyber Assets properly, because you used the “wrong” definition of programmable. If you have your definition documented and you can show that you followed it when you identified your Cyber Assets, you will simply point to the definition and say “Since the term was never defined, this is how we defined it.” Of course, you should never get a violation if you’ve done that, but you might be open to it if you haven’t.

The same thing with “procurement”. It would be nice if it had been defined with CIP-013, but it wasn’t; and I know of no initiative on NERC’s part to draft a definition. So if you say that your procurement started with the master contract and all purchases since then are part of that procurement, then you could try to use that to justify not doing anything when you buy products after July 1 under that agreement – since they’re part of a procurement that started before the compliance date.

However, I don’t think this is a good idea. Since master agreements can go on for many years, you would essentially be saying that none of the risks are going to change at all during that time; and frankly, I think that’s a stretch. I think you’re safe in saying that, if you make two purchases three months apart under one master agreement, it’s not likely the risks would have changed much, so doing a procurement risk assessment for the first purchase will cover the second purchase as well. On the other hand, if you make two purchases under the same purchase agreement that are one year apart, I’d say you wouldn’t be justified in making the same assertion in that case.

But you shouldn’t be afraid of procurement risk assessments. As long as you have a well-defined procedure for doing them, and you have a way of generating the documentation you need during the assessment - so that you don’t have to try to recreate what you did years later in an audit – in general I think you’ll find that you will identify very few risks that weren’t mitigated before the procurement began, so that that you don’t have to mitigate many of them during the procurement itself (and perhaps none at all). At least, that’s been my preliminary conclusion as I’ve done “trial runs” of procurement risk assessments with clients.

Of course, everything I say here will depend on the auditors being in line with what NERC has said in the FAQ. Is that a good assumption? Let’s put it this way – I would feel a lot better if I knew NERC was planning a robust training program for the different Regions on CIP-013 auditing, since that will be hugely different from auditing the other CIP standards. But I haven’t heard that anything like that is in the offing. Have a nice day!

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. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.