What’s the definition of “vendor”?

If you're looking for my pandemic posts, go here.

Recently, I attended a web conference that included CIP compliance people from NERC entities in one Region and some of the CIP auditors for that Region. The auditors provided a good summary of lessons they’d identified from reviewing CIP-013-1 supply chain cyber security risk management plans ahead of the 10/1 compliance date (and if you haven’t had your plan reviewed by your Region, I strongly suggest you do so, before 10/1 of course).

The auditors pointed out that one thing they’d observed in most plans they reviewed was that they didn’t include a definition of “vendor”, since there is no approved NERC Glossary definition of the term. They initially stated that NERC entities subject to CIP-013-1 should use the definition that is found in the Rationale section of the standard: “The term vendor(s) as used in the standard is limited to those persons, companies, or other organizations with whom the Responsible Entity, or its affiliates, contract with to supply BES Cyber Systems and related services.”

The first question you might have is “What’s the difference between a definition that’s found in the Rationale section of a standard and one that’s found in the NERC Glossary? The difference is that a Glossary definition is voted and approved by the NERC ballot body, approved by the NERC BoT, and finally by FERC; the Rationale is none of these.

The CIP 13 Standards Drafting Team originally discussed developing a definition of Vendor that they would put through the whole approval process (along with CIP 13 itself). However, they were then worried this might delay the whole project (and they were mindful of FERC’s requirement that the new standard be developed, approved and delivered to them for approval within about a year after they issued Order 829 in July 2016 – which was way too short), so they decided to handle it differently.

They at first inserted the definition into a blue box in the second draft of the standard – there were a couple other items also inserted in blue boxes, as I recall. They supposedly tried to make clear that the blue boxes weren’t part of the standard, but a lot of people didn’t get the message, and thought that they were voting for the definition as part of the standard itself – since after all the blue boxes were included in the Requirements themselves. After an uproar about this, from then on the definition was relegated to the Rationale section, which is very explicitly stated not to be part of the standard – although FERC seemed to have missed that memo when they “endorsed” this definition in Order 850, which approved CIP-013-1 in October 2018.

So like a lot of things in the NERC CIP world, this definition lives a precarious existence between being kinda sorta an official one and something that doesn’t carry any more legal heft than my definition – you might call this definition one of the Living Dead of NERC CIP (there’s a whole host of such zombies walking around).

I often quote Lew Folkerth of the RF Region, who writes the great articles on CIP and BES cybersecurity that appear under the Lighthouse brand in the RF newsletter (I don’t know whether or not Lew has an online store with Lighthouse-branded merchandise. If so, I’ll buy a sweatshirt). In his article from the May/June 2019 newsletter (which you can get by going here, clicking on Standards and Compliance and then Outreach, and finally downloading the PDF labeled 00b. This contains all five of the articles Lew has written about CIP-013 and supply chain, so you get five for the price of one! Such a deal), Lew said (on page 15 of the PDF) “While the term “vendor” is defined in the Rationale section of the Standard, remember that this section is considered to be guidance and is not enforceable.”

In Lew’s July-August 2019 article (next in the PDF), he included this paragraph: “The term “contract” also appears in the definition of “vendor” in the Rationale section of the Standard, but that definition does not appear in the enforceable elements of the Standard. The definition may be useful as guidance, but be cautious about relying on the exact wording. For example, the use of “contract” in the definition appears to restrict the application of CIP-013-1 to only those parties with which the Responsible Entity has a formal contract. This restriction is not supported by the enforceable elements of the Standard, which means you cannot rely on that aspect of the definition.”

I completely agree with this statement. The word “contract” seems to limit vendors to organizations with which yours has a written contract. This ignores several cases where there is no contract.

The most important example is Cisco and Microsoft, and other behemoths like them. Both of these organizations are very important for supply chain cyber risk management of the BES, but neither one of them directly sells you anything. Raise your hand if your organization buys directly from Cisco without any intermediary organization. How about Microsoft? HP? Dell? I didn’t think I’d see any hands. I can (almost) guarantee you don’t have a contract directly with either one of them.

All of these companies – which I call Suppliers – develop software products or manufacture hardware products (or both), but they use dealers (which I call Product Vendors) to take care of delivering the products to you, collecting payment, etc. (many of the Product Vendors also provide services like support, installation and maintenance, but I call them Service Vendors when they do that. Of course, almost all Suppliers are also Service Vendors as well, for example when they provide maintenance contracts). Your do have a contract with the Product Vendor, but that’s not going to have any terms addressing the Risks that are due to the Supplier – such as a secure development environment, software integrity and authenticity, etc. The Product Vendor can’t sign a contract that binds Cisco or Microsoft to do something.

Another example is an emergency purchase of say a Cisco firewall from Best Buy. Your company doesn’t have a contract with BB, other than the fine print on the back of the receipt. But good luck trying to negotiate those terms, especially when you need the firewall immediately to help restore power. And again, the main sources of supply chain risk are the Suppliers, not the Product Vendors – whose primary risk is that they may ship the product to you insecurely.

Another example is another utility that your utility acquires products or services from. There might be some charge to your utility, but it also might be as part of a broader give and take between the two organizations. The other utility needs to be treated as a Vendor (in my nomenclature), even though no money changes hands when this happens, and you don’t have a contract in place with them.

I pointed this out during the call with the auditors, and another auditor answered that the Region wasn’t going to require entities to follow the definition of vendor found in the Rationale section. So this leaves you in the same position as you’re left by:

1.      The lack of a definition of Procurement in CIP-013;

2.      The lack of a definition of “programmable” in the Cyber Asset definition (the most fundamental definition in NERC CIP, BTW);

3.      The lack of a definition of “affect the BES” in the definition of BES Cyber Asset; and

4.      Other logical gaps in the CIP standards and definitions.

In all of these cases, and certainly with the term vendor, you need to document in your program (in this case, in the CIP 13 R1 plan itself) how you are interpreting the word. More importantly, you need to follow that definition consistently, as long as you’re following that version of your plan (you can change your CIP 13 plan at any time, though, as long as you follow a consistent process for doing that - which itself needs to be in the plan).

So if three years from now you get audited and the auditor disagrees with the definition of vendor that you used, you just need to say “There is no official definition, so we used one that, based on our reading about CIP-013 and supply chain security in general, seemed to make the most sense.” That’s all you need to say.

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 hot at work – or should be – on getting ready for CIP-013-1 compliance on October 1? Here is my summary of what you need to do between now and then.