Tom’s Lessons Learned No. 1: “Adverse Impact”

NERC released a draft FAQ document on April 1.  Question 33 reads “When identifying BES Cyber Systems, what is the definition of adverse impact?”  This is a serious question, and one I wrote a long post on in December (not that I ever write a short post, of course).   I was therefore quite interested in NERC’s response.

And what was their response?  It is three sentences, but the substance is that “adverse impact” means “..a negative effect on the reliable operation of the BES..”; in other words, “an adverse impact is a negative impact”.   I’m really glad to hear that, since I wasn’t sure whether “adverse” meant negative or positive.  I can’t count the number of times I’ve heard a speaker say, “I want to salute Mr. X for the tremendously adverse impact he has had on our community.”

The FAQ response also refers to comments by the SDT on “adverse impact” (last full paragraph on page 60).  The substance of the SDT’s comment (which is two sentences) is “..the term adequately conveys the meaning of an impact that has a negative effect on the reliable operation of the BES and therefore does not need to be added to the NERC Glossary of Terms.”

To summarize, NERC gave a non-answer that referred to a non-answer the SDT had previously given; essentially, they both said the meaning of “adverse impact” should be obvious and nothing more needs to be said on this question.  Now, I realize this is just a draft and therefore may change before it’s finalized.   But the fact that somebody at NERC (or perhaps one of the regions – I know they’re farming these things out now) thought they were providing some sort of service with this “answer” is pretty disheartening.  The point of FAQs is not just to list frequently-asked questions, but to answer them.   

Here is why the meaning of “adverse impact” is an important question that needs to be addressed:  The definition of BES Cyber Asset is “A Cyber Asset that if rendered unavailable…..would, within 15 minutes….adversely impact…Facilities, systems or equipment, which, if destroyed….would affect the reliable operation of the BES.”  NERC clearly thinks there can’t be any real question about the meaning of “adverse impact” (and by implication, that the person who asked the question was an idiot who doesn’t understand plain English).  I beg to disagree, and since NERC doesn’t want to answer this, I will.

Before I start, I want to point out one place where I and the SDT agree: that “adverse impact” doesn’t need to be defined in the NERC Glossary.  This isn’t because I agree with NERC’s assertion that the meaning is obvious – it isn’t at all.  Rather, it is because answering the question of what this term means can’t be done in a one- or two-sentence definition.  Rather, it requires a description of a procedure that an entity could follow to determine the meaning of “adverse impact”, in the case of a particular Cyber Asset under consideration as a BCA.

In other words, the question is much better answered in a Lesson Learned (or in the CIP-002-5 Guidance and Technical Basis, had the SDT chosen to do that) than in a FAQ, which is geared for much pithier, black-and-white answers.  So here is my Lesson Learned on the meaning of “adverse impact”.

I believe the reason both the SDT and NERC punted on answering this question is that there is a myriad of “adverse impacts” that a Cyber Asset could have.  These could include impact on frequency or voltage, impact on the ability of controllers to be aware of the status of the grid, impact on the ability of the grid to recover from an event, etc.  It’s clearly impossible to enumerate all the possible ways that adverse impact could happen. 

So the question should really be “How do I determine whether a particular Cyber Asset’s being rendered unavailable or misused will adversely impact the BES?”   As I concluded in my December post on this question (which I updated in January), the best way to think about the impact a Cyber Asset has on the grid is to go back to CIP v1-3. 

There, Critical Cyber Assets were those defined as “essential to the operation of” Critical Assets.  While “essential to the operation of” is too limiting a definition of “adversely impact” (since I can certainly conceive of Cyber Assets whose misuse would adversely impact a Critical Asset, yet which wouldn’t be considered essential to its operation), the principle is a good one – and one that would have saved much  confusion if it had been followed in the drafting of v5.  In v5, the equivalent procedure is to first look at the impact of the Cyber Asset on the Medium or High impact asset or Facility it’s located at or associated with.  If the Cyber Asset’s unavailability or misuse would have an adverse impact on the operation of the asset or Facility (and thus on the BES itself), then the Cyber Asset should be considered a BES Cyber Asset.[i]

A pretty obvious example is the DCS in a generating plant.  If this is unavailable or misused, the plant will probably shut down; the DCS definitely meets the test of potentially having an adverse impact on the BES, because the plant impacts the BES.  Now let’s look at a less obvious example, the fire suppression system in the control room of a 500kV substation.  The Facility with which this system is associated is presumably the 500kV line[ii].  Most of the time, that line will clearly operate whether or not the fire suppression system is working.  However, when there’s a fire, the fact that the system has been disabled will probably mean the line will be opened or even incinerated.  This will obviously impact the BES.

It may occur to you to ask, “What if the Cyber Asset in question has only a small impact on the Medium or High impact asset/Facility?”  While it may be true that there is a small impact on the asset/Facility, you should remember that what’s important is the impact on the BES if the Cyber Asset is unavailable or misused.  If you can prove to the auditor that there is no way the unavailability or misuse of the Cyber Asset – even if it does impact the asset/Facility itself – can result in any impact to the BES, then I think you would be justified in not declaring it a BES Cyber Asset.

But - in case you were thinking it - you can’t go beyond this and say, “The asset/Facility that this Cyber Asset is associated with actually only has a small impact on the BES, and therefore this Cyber Asset isn’t a BCA.”  You might have gotten away with that in CIP v3, by making sure your RBAM showed that a particular asset (say a generating station) had minimal impact on the BES; therefore, it wasn’t a Critical Asset and didn’t have CCAs.  But in v5, if an asset/Facility meets one of the bright-line criteria, it is inherently considered to have an impact on the BES; you don’t get to second guess that judgment.

So this is the first draft of the first Tom’s Lessons Learned document (I realize the language would need to be made more formal were this to be an actual NERC Lessons Learned document.  Fortunately, Tom’s Lessons Learned aren’t as formal as NERC’s).  I will leave it out for a 30-day comment period; at that point, I’ll consider any comments and then declare it finalized.  Now that I think of it, I have already written a number of posts that could well be considered Lessons Learned, including this, this, and this.  A little rewriting will turn these into LLs as well (although whether I get to that task remains to be seen; maybe I’ll at least publish a list of LLs I’ve written that have been “disguised” as regular posts).  But I’m sure there will be more topics I’ll identify in the coming months that need to be considered as LLs.  From now on, I’ll write these as LLs.

I do want to point out that I’m not trying to compete with NERC on LLs.  If they are working on an LL, I’m certainly not going to develop my own.  However, as I’ve said repeatedly, there are probably hundreds of topics that require LLs that NERC doesn’t even have plans to address; these are what I will focus on.

Maybe I’ll even have a little contest with NERC, to see who can have more finalized Lessons Learned by say the end of this year.  What do you say, NERC? 

April 17: I just reread this post for the first time since I posted it, and was surprised to see how much my thinking had changed by the time I wrote the second post (on more or less the same topic, except I expanded it).  The main difference seems to me - and I don't pretend to be an expert on Tom Alrich's posts, which I find quite long and over-written - that I moved from considering the process of determining adverse impact to be a one-step process, to considering it truly a two-step one.

I say this because, in this post, I considered that it was a foregone conclusion that a BES asset would impact the BES (if lost or degraded), so the only thing that really made a difference was whether or not the Cyber Asset could adversely impact the asset in the first place.  In the second post, I opened up to the possibility that, even though the Cyber Asset does impact the asset, it doesn't impair the asset's performance of one or more BROS; therefore, the impact on the asset doesn't translate into an impact on the BES itself.  This is why I did a complete 180 degree change on the question of whether the fire suppression system would be a BCA, considering it as such in this post but changing my mind (with prompting from an auditor) in the second post.  

My motto has always been "Often wrong, but never in doubt."

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

---

[i] And I assert this is in fact what 99% of NERC entities are doing anyway, as they identify their BES Cyber Systems.  Instead of following the strict language of Attachment 1 and looking at the impact of a system on the BES itself, they’re looking at its impact on the asset/Facility it’s located at (if High impact) or associated with (if Medium).  If you think about it, there’s really no other approach that makes sense.

[ii] Note it is not the substation itself.  Substations – and multi-unit generating plants and control centers – don’t meet the NERC definition of Facility (or the definition of Element, which is at the heart of the Facility definition). If you don’t understand that, I refer you back to this post.