What is a Vendor?

When a NERC Standards Drafting Team drafts a new (or revised) requirement and they utilize an important term that has not been defined previously in the NERC Glossary, they need to consider how to let NERC entities know what they meant when they used that term. They have three good options and one not-so-good one, in my opinion. The three good options are:

1. If the term is clearly well-understood and the common dictionary definition will suffice, they don’t have to do anything. For example, the term “patch” is used many times in the CIP standards, but this term is well enough understood in the IT community that there is no need to define it further.
2. If the term is only used in one requirement, it can be defined in the requirement itself. A good illustration of this is the late, unlamented death of the defined term “Low impact External Routable Connectivity”, affectionately known as LERC. The CIP Modifications SDT took up LERC last year because FERC had ordered that the definition – which had been developed by the CIP v6 SDT and had been approved and included in the Glossary – be revised to clarify the meaning of the term “direct”. Since LERC was only used in one requirement part, the team decided to revise that single part to include the new “definition” of LERC (as well as make other changes to the requirement part itself). This eliminated the need to separately draft a revised definition and get it approved (by the NERC ballot body, the NERC Board of Trustees, and FERC); the approval of the new definition would simply be part of the approval of the requirement part itself (in retrospect, the v6 SDT should have used the same reasoning).
3. If a term is used in multiple requirements, it should be defined and voted on as a new definition to include in the Glossary. While doing this requires more work on the part of the SDT, it is the only course that will provide certainty[i]. That is, the NERC entities will understand what the term means, and the auditors will agree with them on it. This means that it will be hard for the entity to argue with any audit finding that depends on that term (of course, this assumes that the finding isn’t also based on another ambiguous term or requirement – which probably happens a lot, at least in the case of CIP).

But there is a not-so-good option as well: Provide some non-binding guidance on how the term should be interpreted (although exactly how that should be done is a big issue now, which I will discuss in another post soon). Using this option, the drafting team in effect says “Well, here’s what we think the term means, and we hope that everyone – entities and auditors – joins their hands together and sings Kumbaya while agreeing they’ll follow it. But there’s nothing to keep an auditor from coming up with their own interpretation and finding you in potential non-compliance, even if you have followed this definition. We sure hope this doesn’t happen to you, and we wish you good luck. Have a nice day!”

And here is something that should never be an option for the SDT: defining a term in guidance while implying that it has some sort of status above pure guidance - i.e. that the auditors will be in some way obligated to follow it, or at least consider it more seriously than alternative definitions. If this is done, then NERC entities – who might not know any better – may feel inclined to vote for a new or revised standard(s) based on their belief that there is no ambiguity about a key term used in the standard(s). They might be in for a rude surprise years down the road when an auditor tells them they haven’t been using what their Region considers the correct definition. When they protest that they were just following the guidance provided by the SDT, they’ll hear (hopefully not for the first time) that guidance isn’t binding on auditors – they just audit to the “strict wording of the requirement”.

Now to my story. As you may have heard, the second draft of the new NERC Supply Chain Risk Management standard CIP-013 was approved two weeks ago by the NERC ballot body, although by NERC’s rules the standard will still be revised to address the new comments and submitted for another ballot. Probably the biggest change between the first and second drafts of the standard is that the second draft included not just a revised CIP-013, but changes to two existing standards, CIP-005 and CIP-010. These standards also were approved two weeks ago, but will also be revised and submitted for a new ballot with CIP-013.

The drafting team decided to change the two other standards because a number of entities had commented on the first draft of CIP-013 that there were two requirements in that draft that should actually be part of existing requirements – in this case CIP-005 R2 and CIP-010 R1. Now I’m going to focus on the changes in CIP-005 R2, and provide a little history lesson to start out (as I love to do, in case you haven’t noticed).

The Supply Chain standard came about because FERC ordered it in Order 829 in July 2016. Paragraph 51 (page 35) of that order said “The new or modified Reliability Standard must address responsible entities’ logging and controlling all third-party (i.e., vendor) initiated remote access sessions. This objective covers both user-initiated and machine-to-machine vendor remote access.” In the first draft of CIP-013, the drafting team included this requirement (numbered R4) in CIP-013 itself. But a number of commenters pointed out that, since CIP-005 R2 already dealt with remote access to BES Cyber Systems, CIP-013 R4 should be incorporated in that requirement.

To be honest, I was a little surprised that entities would have requested this, since I could see this leading to problems. This is because FERC went beyond what was already in CIP-005 R2 in two ways:

1. R2 currently just requires controls on remote access. Once the remote session has been initiated using the required controls (an Intermediate System and encryption of the remote link), there is no further action required by the entity. By contrast, FERC wants the entity to address both real-time logging (although that has been generalized into monitoring by the SDT) and actually controlling all third-party remote access.
2. FERC wants machine-to-machine remote access covered as well as interactive remote access. Currently, machine-to-machine access is specifically excluded by the definition of Interactive Remote Access (which is of course what CIP-005 R2 is limited to). But FERC was concerned that this left a big hole, since a machine on a vendor network could have been compromised by a third party and could wreak havoc in an ESP under the control of that third party (in fact, both the 2015 and 2016 Ukraine attacks could be considered machine-to-machine access, although this came through the utility’s own network, not a vendor’s).

Even though FERC just ordered that these controls apply to “vendor” access, I was concerned that, by incorporating them into CIP-005 R2, there would be no way to keep them from bleeding into all remote access, including by the NERC entity’s own employees and computers. I figured that the only way to keep this from happening was to have a definition of “vendor” (which I was surprised hadn’t been included with the first draft) that specified exactly what this applied to. Good fences make good neighbors, to quote Robert Frost.

I admit that I didn’t pay too much attention to development of the second draft of CIP-013 until Corey Sellers, the Chairman of the SDT, spoke at the RF CIP Workshop in April, which I attended. When he brought up the fact that the remote access requirement had been moved into CIP-005 R2, I asked him whether the team had in fact developed a definition of Vendor. I don’t remember his exact words, but he said that:

1. Due to time constraints (the team has all along been very aware that they have to get the new standard – and the two revised standards – approved by NERC and on FERC’s desk by September. Of course, it’s still an open question whether anyone will be behind that desk when it arrives, since FERC hasn’t had enough Commissioners to make a quorum since February), the team had decided not to draft a formal Definition.
2. Instead, they had drafted an informal definition and inserted it in the Rationale section of the three standards in question (CIP-013, CIP-005 and CIP-010). The Rationale is found in blue boxes included among the requirements in each of the standards (i.e. in the revised drafts that were just approved last week).
3. It seemed to me that Corey implied in his answer to my question that, by being included in the Rationale and voted on along with the requirements themselves, the Vendor definition would have a status above that of mere guidance (and if he didn’t say that, he certainly didn’t say that the definition would not have any status above something that – say – I might write in my blog). Therefore, this was a good alternative to not drafting a formal definition.

I was satisfied with this answer at that time, up until the NERC CIPC meeting three weeks ago in San Diego. At that meeting, Howard Gugel of NERC had the unenviable responsibility of describing to the meeting how NERC’s revised guidance policy works (I will have a lot more to say on that subject in another post coming soon); this policy had been approved by the NERC Standards Committee the previous day, but was (and still is) still subject to Board approval.

In Howard’s talk (actually his second. On the first day of the meeting he left more questions than answers, and it was suggested he return on the second day and try again. This time he did a much better job of explaining the policy, to the extent it can be explained at all), he stated very clearly that the Rationale included with a standard was strictly to explain why the requirements had been developed in the first place, not to provide any sort of guidance on compliance. Therefore, the Rationale would not have any particular importance in audits (these weren’t his exact words, but I thought his meaning was clear).

At that point, I asked Howard why the definition of Vendor is included in the Rationale for the new and revised CIP-013, CIP-005 and CIP-010. After all, the word Vendor is crucial in all three standards, and it can certainly be said that how the entity understands that term will have a lot of importance for how they will comply. Howard didn’t have an answer for that question, except to say that it should be included in the comments on the second draft (I believe the comment period was still open the day he said that, although it closed the next day).

So it seems that Corey Sellers was mistaken when he implied in April that including the definition in the Rationale gave it a status somewhat like that of a real NERC Definition. But this is completely understandable – the Standards Committee didn’t even make that decision until two months later! I don’t blame Corey for this at all, although I do regret that the SDT didn’t take the time to do things right and draft a real Definition, even though that would have been another item that needed to be balloted and approved.

You may think this is an academic exercise since everyone knows what a vendor is. I thought so, too, until one of the SDT meetings I attended had about a half-day discussion just on what vendor means (and there was no resolution, perhaps leading to the decision not to submit a definition for approval). The sticking point was how to write the definition so that ISOs, RTOs, etc. would be excluded from being vendors. They certainly provide things like software and data to NERC entities, and the fact that they’re not specifically paid to do those things isn’t in itself a clear distinction from other vendors, since those other vendors often provide software and data without explicit payment for them.

So the bottom line is that there is no official definition of the word vendor, which appears in the new drafts of CIP-013, CIP-005 and CIP-010. Assuming the latest draft I've seen (from the SDT's meeting in Charleston, SC last week) is what gets finally approved, you should have a conversation with your Region about what "vendor" means in these three standards, long before you’re audited on them (and my guess is it will be 3-5 years before there are any audits of the Supply Chain requirements).

The danger here is that an entity will assume that the definition of Vendor in the Rationale is in some way official, since it was in the standard when it was approved by the NERC ballot body. This definition makes it clear that ISOs and RTOs aren’t vendors. But if an auditor five years from now happens to think differently, the entity may be in for a big surprise.

I really don’t think it's too likely that an auditor will be convinced that your ISO is actually a vendor, but it is certainly possible; and if it happens, you will have no real recourse beyond appealing and hoping that the people hearing your appeal will agree that you were justified (although perhaps naive) in thinking that the definition of Vendor in the Rationale had some special importance. And there are other pieces of guidance – specifically the Guidance and Technical Basis included with all the CIP standards since v5 – that most entities have also considered as close to being as “official” as the requirements themselves, but which in fact are also no more binding on the auditors (or the entities) than something I write in this blog. I will have a post on this issue soon.

  

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.

---

[i] Assuming the definition is well drafted; if it isn’t, then there still is no certainty. For example, the definition of Cyber Asset developed by the team that drafted CIP v5 used the word Programmable, which wasn’t defined. The result was that there still is no certainty (and probably never will be) about what is or isn’t a Cyber Asset. And since this is without exaggeration the fundamental definition in all of CIP, this lack of certainty has carried into almost all of the CIP standards (although there have been many other sources of uncertainty as well).