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).

Remember “Programmable”?

Anyone who was involved with NERC CIP during the period from say mid-2014 through mid-2016 (i.e. the two years leading up to the CIP v5 compliance date) will remember that for a while it seemed that the fate of the universe hinged on the word “programmable”. This is because the v5 definition of Cyber Asset was “Programmable electronic device…”, and programmable wasn’t defined. Yet it was essential to properly identify Cyber Assets, since BES Cyber Assets, hence BES Cyber Systems, could never be properly identified unless the entity had properly identified their Cyber Assets.

It has always been clear what an “electronic device” is, but there was never a definition of “programmable” – and certainly not from a major dictionary – that NERC entities felt would properly identify Cyber Assets at a generating plant or substation. The problem at these assets is that there can be all sorts of weird devices that don’t run Windows, Linux, or any other operating system you’ve ever heard of – and often don’t run any operating system at all. Yet they still could conceivably be programmable, depending on how you define it.

In 2014-2016, billions, and probably quintillions, of electrons were utilized by the various online discussions of the meaning of programmable (I myself made a modest contribution to the discussion with this post and this one, as well as mentions in other posts that I’ve forgotten). More importantly, NERC made several concerted efforts to try to explain what the word really meant. The first was a well-received Lesson Learned in January 2015, which many NERC entities thought provided a very reasonable definition.

However, this LL was both withdrawn from the website (although I still have a copy if you want to email me for it. I may have to deliver it to you by hand in the dark of night in a city far away from Atlanta or Washington, DC, but I promise I’ll get it to you!) and also directly repudiated in one of the six infamous Memoranda that NERC issued in April of 2015. That Memorandum (this of course was itself later withdrawn from the website, along with the other Memoranda. I also still have a copy of this. Since it is even more sensitive, I may have to arrange to meet you in a foreign country to exchange it with you, and I’ll probably have to wear a wig and fake mustache, and talk with an impenetrable accent) took a very harsh line, insisting that even devices that could only be “programmed” by physically changing DIP switches were programmable. Moreover, like the other five Memoranda, it claimed some sort of absolute authority – i.e. it wasn’t subject to any industry review or correction. I discussed the controversy while it was still going on, in the second post linked in the paragraph above this one.

This and the other five Memoranda produced a huge firestorm in the NERC community, which culminated in what must have been a very interesting meeting on July 1, 2015. In that meeting, it seems there was a big revolt staged by the industry trade associations. NERC not only withdrew the Memoranda, they all but admitted there would never be any definitive guidance on the subjects of those Memoranda, including of course the definition of “Programmable”.

Finally, at the beginning of 2016 NERC turned this question, as well as a number of others, over to the drafting team that was formed to address FERC’s directive in Order 822, the Order where FERC approved CIP v6 but ordered further changes to CIP. Throughout all of this process, entities couldn’t wait for the question of the meaning of programmable to be settled (and they would have been disappointed had they waited!). I recommended that they “roll their own” definition, and many did that. I also recommended that entities follow the same approach for any other area of ambiguity in the CIP standards, of which there are many. My guess is all of the larger entities did that (not because I said it, just because it was really the only logical thing to do in this situation), although I also think the smaller entities (with Medium and/or High assets) simply muddled through without doing anything in particular.

I admit I haven’t heard (or thought) very much about this question until this week, when I attended a meeting of the Order 822 drafting team (known as “Modifications to CIP Standards) in Montreal. Yet on the first day of the meeting, there was a discussion of “Programmable”! I think the topic came up because this team is now discussing how virtualization can be incorporated into the CIP standards (one of the items on their very ambitious agenda – I will have a post on that topic shortly), and the definition of Cyber Asset will have to be changed for that.

The reason the Cyber Asset definition needs to be changed to accommodate virtualization is the word “device”. There is no getting around the fact that this word means something hard, not something that is just software (my operational definition is that if you drop a device on your foot, it will hurt. If you drop a virtual device on your foot, it won’t hurt – if you can even figure out how to do anything physical with a virtual device!).

The drafting team will definitely propose a change to allow virtual devices, but it seemed pretty obvious that they don’t have the stomach to deal with the Programmable issue. One person mentioned that issuing a definition of Programmable at this point would probably require all NERC entities with Medium and/or High impact assets to go back and re-run their entire asset identification methodologies. This would almost certainly require a huge expenditure of time and money on the part of NERC entities, and I can understand why this isn’t exactly right at the top of everyone’s wish list. They did mention possibly including a discussion of Programmable in the Guidance (it isn’t there in the current Guidance and Technical Basis for CIP-002-5.1, where it would logically be found), but the issue of standards guidance in general – which was extensively discussed – brings up a whole host of issues, which I hope to discuss in one of my next posts.

Meanwhile, I was reminded that a Lesson Learned approved in 2015 included a discussion of this issue (pages 3-4, under “Capability”). I just reread it, and found it a pretty good effort. Of course, it doesn’t say what NERC will consider to be programmable vs. not, but it does list some devices that entities in the CIP v5 Transition Study considered to be non-programmable, and the fact that this isn’t disputed obviously means at least some staff at NERC and the regions consider this OK. Obviously, this isn’t the sort of evidence that would stand up in a court of law, but in the world of CIP v5 this is about as good as it gets!

So I need to tell you that I don’t think there will ever be any more certainty as to the meaning of “Programmable” in the Cyber Asset definition than there is now. While this certainly isn’t a great situation, it’s nowhere near as bad as some of the other areas of ambiguity, missing definitions, or outright contradiction in CIP v5 (and if you want a discussion of some of these, just read almost any of my posts from the end of April 2013 through say the end of 2016. I did compile a partial list of these areas in this post).

And, as I intend to discuss in one of my next posts, the prospects of getting final answers to any of these CIP v5 interpretation questions are fast approaching zero, if they haven’t already passed zero and gone into negative territory. Have a nice day!

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

Debate on Enforceability of CIP-013

The day after I published my post questioning whether CIP-013 was enforceable (based on comments by a friend of mine who works for one of the NERC regions), an auditor (from another region) emailed me his dissenting opinion. He said:

“The requirement is essentially that the Registered Entity ask for the elements of the required process(es), not that the vendor agree to them.  Therefore, the Standard is correct in that the language of the resulting contract is not in scope.  (The procurement steps include) the Request for Quotation or Bid, Request for Contract Amendment, and/or any other Registered Entity-initiated correspondence that sets forth the expectations to be placed upon the vendor.  As long as I see the expectations in the procurement documents issued by the Registered Entity, they have satisfied the requirement.

“So, while I would readily argue that the Standard is weak as water, it is not unenforceable.”

I showed these comments to my friend (I should say other friend, since the auditor is also a good friend), and he had this (friendly) rejoinder:

“The ultimate goal of CIP-013 is to modify the terms of acquisition contracts used by the Responsible Entity:

“Quoting FERC Order 829 Page 59 (Note: this is the Order that NERC develop a supply chain security standard): ‘The new or modified Reliability Standard must address the provision and verification of relevant security concepts in future contracts for industrial control system hardware, software, and computing and networking services associated with bulk electric system operations.’

(My friend continues) “In keeping contracts out of scope for audits, CIP-013 does not fulfill the underlying purpose of the Standard. There may be some things that can be audited, but the auditors will be handicapped in reviewing evidence. They will not be able to audit that ICS contracts contain provisions which satisfy the security controls of R1, and they will not be able to verify that the entity enforces these controls.

“Ultimately, this version of CIP-013 does not fulfill the definition of a Risk-Based Requirement: “[D]efine actions by one or more entities that reduce a stated risk to the reliability of the Bulk Power System and can be measured by evaluating a particular product or outcome resulting from the required actions.” [NERC Rules of Procedure, Appendix 3A Section 2.4] If the outcome cannot be measured, then the Requirement fails as a Risk-based Requirement.”

I’m not going to take a side in this debate. These two people know a lot more about auditing than I will ever know. If you have an opinion on this question, I’d like to see it. Of course, this wouldn’t be the first time that two Regions have disagreed on some aspect of CIP!

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

FERC Asks Two Questions

I have heard from an industry source that FERC recently asked at least one of the trade associations to answer two questions (they in turn circulated these to their members):

Q1: Which, if any, of the existing CIP requirements would you get rid of and why? Do any of these requirements harm/hinder security efforts?

Q2: What would a performance or results-based approach to the CIP Standards look like? (e.g., a CIP-014 type approach) Could it help to improve compliance efficiency and certainty as well as the security of the BES? How?

FERC didn’t ask for my opinion on these questions, but since I always try to be helpful, and since I have answered these multiple times in various posts but not in one place, here is how I would answer them if asked.

Regarding Q1, my answer is very simple: Just getting rid of particular CIP requirements and leaving others makes no sense (no more sense than the “2 for 1” rule – in which two regulations must be eliminated for every new rule – makes). The problem isn’t that some of the specific things that CIP makes entities do are unneeded while others are needed. Everything that CIP requires is needed, just not all to the same degree. Plus there’s a lot more that CIP doesn’t require – controls on phishing, ransomware protections, etc. – that is also very much needed.

And that’s the point (which also brings me to my answer to Q2): By requiring that NERC entities allocate large amounts of resources to particular areas like CIP-007 R2 patch management compliance and not requiring any resources be spent on areas like phishing[i], CIP forces a misallocation of an entity’s cyber dollars.

In an ideal standard, the entity would a) come up with a list of current threats to its control of BES processes (and this list should ideally be generated externally by some group like the E-ISAC[ii]); b) get an assessment of its current control posture vis-à-vis these threats; c) from the list of vulnerabilities developed by that assessment, prioritize them by their degree of impact on control of the BES; d) develop a mitigation plan that allocates resources to each vulnerability based on its degree of impact; e) have their NERC Region review the plan and order changes if needed[iii]; f) execute the plan; g) be audited by their Region on how well the entity had executed the plan[iv]; and h) rinse and repeat – execute the whole cycle every two or three years (for larger and riskier entities) or longer (for smaller and less-risky entities. Of course, I’m talking about risk to the BES, not financial risk or something like that) – and the new vulnerability assessment must be based on the latest version of the “threat list”[v].

At one point I thought that CIP-014 was a good model for what I’m proposing, but I now think that it should have a lot more structure (like the above) if we’re talking about replacing CIP-002 through CIP-011. CIP-014 essentially tells the entity (that has assets in scope) to get an assessment and fix the problems, period. These are both steps in what I’m advocating, but they’re far from being the whole story.

I recently put together a list of the six principles (subject to later additions, of course. I don’t believe six is a magic number) that would govern the security regime I am advocating[vi]. They are:

1. The process being protected needs to be clearly defined (the Bulk Electric System, the interstate gas transmission system, a safe water supply for City X, etc).
2. The compliance regime must be threat-based, meaning there needs to be a list of threats that each entity should address (or else demonstrate why a particular threat doesn’t apply to it).
3. The list of threats needs to be regularly updated, as new threats emerge and perhaps some old ones become less important.
4. While no particular steps will be prescribed to mitigate any threat, the entity will need to be able to show that what they have done to mitigate each threat has been effective[vii].
5. Mitigations need to apply to all assets and cyber assets in the entity’s control, although the degree of mitigation required will depend on the risk that misuse or loss of the particular asset or cyber asset poses to the process being protected.
6. It should be up to the entity to determine how it will prioritize its expenditures (expenditures of money and of time) on these threats, although it will need to document how it determined its prioritization.

I have just answered the first part of Q2: “What would a performance or results-based approach to the CIP Standards look like?” My answer is that it would look like what I’ve just described. This is a results-based approach because it requires the entity to achieve a particular result (mitigation of the vulnerabilities identified in the assessment, ranked by their impact), without prescribing how that is to be achieved (of course, there will be lots of guidance on how to mitigate various types of vulnerabilities, and more importantly that guidance will be regularly updated, perhaps by the same group that updates the threat list).

The second part of Q2 reads: “Could it help to improve compliance efficiency and certainty as well as the security of the BES? How?” I will break this down into its parts.

1. Does what I am proposing improve compliance efficiency? I guess it does, but compliance efficiency isn’t the goal – efficiency of improving cyber security should be the goal. As I said at the outset, NERC CIP now forces a mis-allocation of resources toward tasks that – while certainly producing some security benefit – probably don’t produce a benefit that justifies the expenditure required; while at the same time leaving less resources for areas like phishing that aren’t part of the CIP requirements at all and are probably more deserving of resources.[vii] What I am proposing would a) reduce (but not eliminate) the paperwork burden, but more importantly b) produce a great deal more cyber security for every dollar spent, vs. the current prescriptive CIP compliance regime.[viii]
2. Does what I’m proposing improve compliance certainty? I’m not sure whether it improves it, but it certainly doesn’t hurt it. It makes compliance certainty fade as an issue, since there are no longer prescriptive requirements, whose interpretation one way or the other will make entities face million-dollar-a-day fines. An entity will still be subject to fines, but those will be for not fulfilling the promises it made when FERC approved its mitigation plan. The entity could be fined if it didn’t follow through in some way, and if it also didn’t address the corrections that the region ordered.[ix]
3. Does this help the security of the BES? Absolutely. As I said, the biggest benefit is that it effectively increases the amount of money going to BES security without in itself requiring an overall increase in cyber security expenditures (although don’t kid yourself – cyber expenditures are going to have to go up every year for the foreseeable future. That’s the world we live in).

So here are my respectful answers to FERC’s questions. If anyone has comments or wants to discuss these, email me at talrich@deloitte.com.

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

---

[i] In practice, I’m sure most utilities are now spending a lot of money to address the phishing threat. But it’s almost axiomatic that, since the CIP requirements carry the possibility of big fines whereas anti-phishing measures don’t avoid any fines, entities will spend much more on other less serious threats if they’re part of the CIP requirements.

[ii] This list should be updated regularly, at least once a year and maybe every six months. The entity could always add a threat to its own list, if its own situation dictates it should be on the list. Conversely, they could remove a threat from the list if it doesn’t apply to them or if they’d already sufficiently mitigated this. They would have to document their justification for doing this, though.

[iii] Of course, they couldn’t order changes just because some auditor felt like it. There would be guidelines for what constitutes an acceptable plan.

[iv] Normally, if the Region feels an entity has not properly addressed a particular vulnerability, they could order it to re-do or augment the steps it took to address that vulnerability. And if the Region feels the entity has really screwed up the whole effort, they could order it be redone. Again, there would be guidance on what does and doesn’t constitute successful mitigation of a vulnerability.

[v] One of the big problems with CIP now is that it is close to impossible to address a new threat. For example, virtualization has brought lots of benefits but also new potential threats. Virtualization was widely used in 2011 when the CSO 706 (CIP) SDT turned its attention to developing v5, yet I don’t think there was any real thought of addressing virtualization in v5. Now NERC really has to address it, and the drafting team is doing very good work on addressing virtualization on a conceptual level, as well as starting to develop new (or revised) requirements and definitions. However, because of the sheer number of the changes that will be required, I am skeptical they will ever be able to get all of this approved by the ballot body, at least within the lifetime of the universe as we know it. I will attend the drafting team’s meeting in Montreal next week and hope to get a better take on this effort, since I admit I have not paid enough attention to virtualization lately.

[vi] While that post was specifically about natural gas pipeline regulation, I wrote the principles so that they would apply equally well to any process-based critical infrastructure. In the next post, I discussed them in the context of the electrical power industry, which is of course where they are needed first.

[vii] And don’t tell me that the solution to this problem is to write a SAR for a new CIP phishing standard! I don’t want the current CIP standards to be expanded beyond what they currently cover. Instead, I want a regime where all threats are considered and prioritized. I am sure phishing will be at the top of a lot of entities’ lists of threats to address, although that might not be true in five years (I’m sure there will be new threats we haven’t thought of yet by that time).

[viii] I’ve noted a couple times that I asked some entities how much of every dollar they spent on implementing CIP v5 went to cyber security vs. just compliance – the average answer I got was 50%. I doubt my plan will reduce any utility’s total spending on cyber security (including CIP compliance). However, I do believe it will increase that percentage to say at least 75 or 80%. If say two billion dollars a year is now being spent on CIP compliance by North American utilities and IPPs (and I don’t know what the full number is, although I’m sure it’s well over $1 Bn), increasing the percentage to 75% would be an effective increase of $500 million going to cyber security. That’s much more than I earn in a year.

[ix] I won’t pretend there isn’t a potential problem with rogue auditors who like to torment utilities by unreasonably saying they haven’t fulfilled their mitigation plan. There will need to be controls to prevent this, the most important being a much more extensive auditor training program and higher requirements for cyber security expertise.

The Good News is this Post isn’t about CIP. The Bad News…Well, Read the Post

On June 9, the Opinion page of the Wall Street Journal published an article by Henry F. Cooper titled “North Korea Dreams of Turning Out the Lights”. It discusses the possibility of an EMP (electro-magnetic pulse) attack by North Korea, and makes the point that this is a lot more likely than we might think/hope. Since the WSJ’s online version is behind a pay wall, I can’t link the article here, but I’ll summarize some key points and quote others.

• North Korea now probably has the ability to detonate a nuclear weapon 40 miles above Seoul – in fact, “a recent North Korean medium-range missile test that was widely reported to have exploded midflight could in fact have been deliberately detonated at an altitude of 40 miles.”
• Such an attack on Seoul would “inflict catastrophic damage on South Korea’s electric power grid, leading to a prolonged blackout that could have deadly consequences.” Moreover, since the US has about 29,000 military personnel stationed in South Korea, plus more at sea nearby, such an attack would make it very hard for the US to respond to North Korean aggression (say, if North Korea were to invade the South after an EMP attack – note this is my inference. It isn’t stated directly by the author).
• In 2001, Congress established a commission to study this danger. The chairman of the commission, William R. Graham, “noted that several Russian generals told the commissioners in 2004 that the designs for a ‘super EMP nuclear weapon’ had been transferred to North Korea.”
• An EMP attack using a nuclear warhead with a yield of “only” 10 to 20 kilotons could “inflict catastrophic damage to unhardened electronics across hundreds of miles of surface territory.” This is the range of yields that North Korea has already successfully tested. So there would be no need for them to wait until they had produced a much more powerful device.
• North Korea wouldn’t need to develop a long-range ballistic missile in order to attack the US. For one thing, there is no need for great accuracy – detonation almost anywhere over the US would produce devastating effects. For another, there would be no “need to worry about developing a reliable re-entry vehicle for their ballistic missiles” (which would be required for a conventional nuclear strike).
• And there might be an even easier way to strike the US: According to William Graham in a recent blog post, North Korea could launch a “short-range missile off a freighter or submarine or by lofting a warhead to 30 kilometers burst height by balloon. Even a balloon-lofted warhead detonated at 30 kilometers altitude could blackout the Eastern Grid that supports most of the population and generates 75 percent of US electricity. Moreover, an EMP attack could be made by a North Korean satellite.”

The article concludes “The US and South Korea should ensure their ballistic-missile defenses are effective and harden their electric power grids against EMP effects as soon as possible. The day of reckoning could come sooner than anyone in either country thinks.”

Have a nice day!

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

Is CIP-013 Unenforceable?

I heard an interesting comment this week from a friend on the staff of one of the Regional Entities, who is very knowledgeable about CIP and NERC enforcement in general. His opinion is that CIP-013 is unenforceable, as it stands in the second draft – the one now being balloted. Why does he think this? Here’s the smoking gun: the note below CIP-013 R2 (and since it’s a note, not part of the blue boxes, it does need to be considered as a binding modification of the requirement. I’ll have more to say on those blue boxes in one of my next posts – there is more going on with them than meets the eye) reads

“Note: Implementation of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Requirement R2: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.”

My friend points out that he has no problem with the first sentence. In fact, this thought was part of FERC’s Order 829, which ordered NERC to develop the standard; it was also in the first draft of CIP-013. His problem is with the second sentence, which was in neither Order 829 nor the first draft. And of the two parts of the second sentence, his problem is with the first part.

What is the problem? Let’s look at the requirement it’s attached to. R1.2 requires development of a supply chain cyber security risk management plan that includes (but isn’t limited to):

1.     One or more process(es) used in procuring BES Cyber Systems that address the following, as applicable:

a.      Notification by the vendor of vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity;

b.     Coordination of responses to vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity;

c.      Notification by vendors when remote or onsite access should no longer be granted to vendor representatives;

d.      Disclosure by vendors of known vulnerabilities;

e.      Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System; and

f.       Coordination of controls for (i) vendor-initiated Interactive Remote Access, and (ii) system-to-system remote access with a vendor(s).

R2 requires implementation of that plan. In an audit, the Responsible Entity is going to have to demonstrate that they have taken steps to get their vendors to provide all of these things. There are various ways to do this, and they can vary according to the risk posed by the vendor and/or the risk posed by the product or service being purchased. It is certain that many entities will attempt to achieve these goals by using legal contract language, at least in the case of some of their vendors.

My friend’s concern is that the first part of the second sentence of the note essentially says that the actual terms and conditions of a procurement contract are out of scope for the audit. This means that the auditor can’t ask the entity to show him or her a vendor contract, to demonstrate their assertion that they have used contract language to address one or more of the items listed in R1.2 for a particular vendor.

So let’s say the entity shows their auditors the section of their plan that describes how they will address each of the six items in R1.2, and the plan says that, for very important vendors like their EMS vendor, they will address all of the items using contract language; it looks at first glance like they’ve complied with R1.2, since they have a proper plan for achieving the objectives listed above.

Now the auditors move to R2, which requires the entity to implement the plan. They get to the section of the plan that corresponds to R1.2, and tell the entity that they would like to see evidence that they have complied with this part of the requirement for each of their top ten vendors, starting with the EMS vendor. And since the plan says that the entity will use contract language to address the six items in R1.2, at least for this vendor, the auditors request to see that contract to verify the language is actually there – or more likely, that the language is acceptable as evidence of compliance. At that point, the entity points them to the second sentence of the note and (politely) repeats that the “actual terms and conditions of a procurement contract” are out of scope. Therefore, they don’t need to produce the contract.

So how are the auditors going to verify the entity’s assertion that they have complied with R1.2 for their EMS vendor using contract language, if they aren’t allowed to see the contract? My friend’s answer is that the auditors can’t verify this assertion without being allowed to see the evidence. And what if the entity asserts they have used contract language to address R1.2 for all of their vendors? Then the auditors aren’t going to verify compliance – at least for the items in R1.2 - at all for this entity. Do you see any issue with this?

But other than the fact that it’s not enforceable, my friend doesn’t have any big problems with CIP-013.

Note: There were two follow-up posts on this subject, including this and this.

Any opinions expressed in this post are those of the author, not necessarily those of Deloitte.

NERC, FERC, LERC, ERC

My most recent post dealt (in part) with Felek Abbas’ response to the question whether a “jungle mux” should have an ESP around it. The day after I posted it, I realized there was an error in my footnote, which read “Of course, this isn’t to say that the serial devices that connect to the mux don’t have external routable connectivity; they still do, since the external routable communications stream crosses the asset boundary. If the mux controls electronic access, as does the device in Reference Model 5, then no further measures should be required for the entity to comply with the Low impact electronic access control requirement part in CIP-003 R2. If it doesn’t, then some further step will be needed, like a firewall or data diode.”

I replaced the footnote with the one quoted below, but the email feed had already gone out to the 500+ feed subscribers (whose names I can never see, in case you wondered). I thought it would be interesting to see how many of them caught the error, so I didn’t otherwise acknowledge it. I waited and waited and…guess what? Nobody seems to have caught the error. This means one of two things:

1.       None of my readers realize that a device that can be in an ESP is Medium or High impact, not Low (and therefore what I wrote in the footnote about ERC crossing the asset boundary and Reference Model 5 is irrelevant, since these concepts only apply to Lows); or

2.       Nobody reads my footnotes.

Since I know that I have a lot of readers who would spot this error very quickly if they read it, I have to conclude that number 2 is the case. That’s OK – I’m not complaining because nobody reads footnotes. It just means I need to avoid putting important information in footnotes (and I’ve already started doing that. I used to have posts with 8-10 footnotes, but lately I’ve hardly ever gone above two. I’ll try to bring that down to zero).

So here is the new footnote that I inserted in place of the erroneous one. I’m making all of this into a separate post because a lot of people have kind of forgotten the difference between LERC and ERC, and – while a lot of people know that “LERC” has been retired and the definition is now built into the requirement part in CIP-003-7 R2 – probably most (including me) have forgotten what the issues are with ERC, and where things stand in fixing that definition.

“Of course, this isn’t to say that the serial devices that connect to the mux don’t have external routable connectivity. Whether they do or don’t depends on what happens at the jungle mux. The definition of ERC is “The ability to access a BES Cyber System from a Cyber Asset that is outside of its associated Electronic Security Perimeter via a bi-directional routable protocol connection.” If all the jungle mux does is convert the routable communications stream to serial and send it to the proper device, then there is ERC. If the mux performs some sort of authentication, then this probably removes that ability, and there is no ERC.

“However, I’ll admit this is still an ambiguous area, and that points to an interesting irony. That is because FERC’s qualms about the ERC definition (discussed above in this post) led to a change; but the change was in the LERC definition, not ERC. When FERC ordered NERC to clarify the meaning of “Direct” in the LERC definition – in Order 822 approving CIP v6 in January 2016 – they weren’t reacting to problems with LERC since it wasn’t in effect yet. They were really responding to the discussions about ERC in 2014 and 2015 that I described above (I linked above to just one of the posts I wrote on this issue. Others include this one, this one, and this one (in the order I wrote them). I believe FERC was especially concerned about the idea that mere protocol conversion “breaks” ERC.

“If you want to plow through these three posts, you will see that, by the third one, I had concluded (in conjunction with Morgan King, a WECC auditor who has weighed in a lot on technical issues like this) that mere protocol conversion didn’t break ERC, but requiring re-authentication would. I thought when I wrote the third post that this was the last word on the subject. However, in this post, which was written a few days after the third one, I reported that another auditor said this wasn’t enough to break ERC – that there had to also be ‘reformulation of the user’s commands and the acting as a proxy for the user’.

“At this point, I threw up my hands and decided ERC was a black hole – I could write 100 posts and never get to the bottom of the problem, which was that the definition needs to be rewritten. This is one of the tasks on the CIP Modifications SDT’s agenda. I think they should build on the very good work they did with the LERC issue last year and base their new definition of ERC on use cases similar to the Reference Models they developed for CIP-003-7 (although some of those models won’t apply because the new Section 3.1 “defines” what used to be LERC in terms of the asset’s boundary, in order to avoid requiring a list of BCS at Lows). I think any attempt to write a dictionary-style definition will fail. They just need to say ‘In these particular cases, there is ERC. In these particular cases, there isn’t ERC.’”

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