Roll Your Own, Part V: Serial (killers?)

If you haven’t read at least the first post in this series, I recommend you go back and do that..... But in case you didn’t listen to what I just said, here is the premise of this series:

1. There are many ambiguous areas in CIP Version 5 – definitions that are missing, requirements that aren’t clearly written or are outright contradictory, etc.[i]
2. NERC is trying to plug some of these gaps, but they’re running around like the little Dutch boy, sticking their fingers in as many holes as they can, while new ones appear every day.
3. Meanwhile, entities need answers to these issues now – more to the point, they really needed them many months ago.  The April 1, 2016 compliance date for Highs and Mediums isn’t going away – in fact, by my calculations it gets one day closer every day.[ii]
4. That is why it seems a number of entities have independently hit on the same solution to this problem: They’re developing their own definitions or interpretations to fill the gaps that they run into.  However, they’re also making sure to document their work, as well as justify their interpretations in the light of any other guidance that might currently be available.  As shown in this and this post, I’ve gotten support from auditors for this stance, as well as other NERC entities.

So today I wish to address another area where I think NERC entities should consider “rolling their own”.  First, I’ll tell you why I’m bringing this up.

I’ve started to do “CIP Version 5 Workshops” for several entities, and have more lined up.  In these, I spend a few days to a week onsite, going over whatever they always wanted to know about CIP Versions 5 and 6 (and now 7!) but were afraid to ask.[iii]  I recently did workshops for two different Transmission entities in two weeks, and was struck by how similar their issues were.

To be specific, both of them had the same top two concerns about CIP v5.  The first is the transfer-trip relay issue.  I’ve written about that in a couple posts (including this one).  I thought the question was pretty settled, but I now realize there’s still misunderstanding about what NERC’s “ruling” applies to and what it doesn’t, plus disagreement over whether NERC’s reasoning was valid at all. But that’s for another post.

The second concern has to do with serially-connected devices in substations, connected to a device like an RTU that might or might not have external routable connectivity.  However, there are really three questions people have about the status of these devices, and it’s important to keep them straight.  While in my opinion the first two questions have straightforward yes/no answers, the third question requires either rolling your own interpretation or waiting for NERC to maybe (or maybe not) kinda sorta address the problem in their upcoming Lessons Learned document.  The choice is yours.

The first question people ask is, “Can a serially-connected device in a substation (a digital relay, etc) be a BES Cyber Asset?”  And the answer to that is an unequivocal yes.  If you’ll go back to the BCA definition, you’ll see it nowhere makes reference to the device’s connectivity, only to whether its loss or misuse can impact the BES within 15 minutes (when needed).  If it does impact the BES in 15 minutes, it’s a BCA; if not, it’s not.  Whether it’s serially or routably connected, or not connected at all, doesn’t matter.

Next question: Given that the serially-connected Cyber Asset is a BCA, does it need to be within an ESP?  This is a good question, since in CIP Versions 1-3 it would have had to be within an ESP if it was a Critical Cyber Asset.[iv]  But CIP-005-5.1 R1 says nothing about BCAs or BCSs having to be within an ESP.  An ESP has to include any routably connected Cyber Assets[v], but doesn’t have to include anything else.  So our serially-connected relay doesn’t have to be in an ESP.  Practically speaking, it’s kind of hard to understand what it would mean to say that the relay did have to be within an ESP, since the definition of ESP (balloted with the v5 standards) refers only to devices that are routably connected.

Now we come to the real question: What if the serial relay is connected to an RTU that is itself routably connected to the outside world?  Does it now itself participate in external routable connectivity (which I’ll abbreviate ERC from now on)?  Of course, this is a big deal, since the number of requirements that a BES Cyber System will have to satisfy is much larger if it participates in ERC than if it doesn’t.

This is quite a different question.  NERC does have it on their list of “Planned Lessons Learned”, so there will presumably be something out on it in the future.[vi]  And if you’re not in a big hurry, you might just want to wait for that (however, keep in mind that the Lessons Learned documents don’t have the status of true Interpretations - which take several years to produce since they have to be balloted by NERC and approved by FERC.  And also keep in mind that the first posting will just be a draft for comment, so the final LL document won’t be out for another month or so after that.  And lastly, keep in mind that the document may not take a definite stance on this issue anyway, either yes or no).

But let’s say you’ve been spooked by my saying there are only 332 compliance days left and you want to finalize your BES Cyber System identification in your substations now - so you can then go on to figure out what you actually have to do to comply by April 1, 2016.  This means you do need to roll your own answer to this question.  Where can you turn to at least get started on this?

Fortunately, there is a well-written NERC document that can provide some help on this question.  It’s the guideline on identifying Critical Cyber Assets that NERC published in 2010, that applied to CIP v1-4.    I refer you to page 28, where – in a section titled “Serial Cyber Assets that are Accessible via Routable Protocol” - it states “..serially connected Cyber Assets can meet the qualifying connectivity criterion in Requirement 3.1, if a routable connection is used to communicate outside the preliminary ESP.”[vii]  R3.1 is the provision, in CIP v1-3, that a cyber asset must participate in ERC to be a CCA.

I must admit that for the last four years I’ve been interpreting this to mean, “If the RTU has external routable connectivity, then any device attached either serially or routably to it does itself have ERC.”  However, a customer recently convinced me otherwise by pointing to the clause “if a routable connection is used to communicate outside the preliminary ESP.”  He pointed out that, at least for the RTU’s that his entity uses in their substations, the devices connected to the RTU don’t actually communicate with the external world.  All the RTU does is poll the device and pass those results up to the SCADA or EMS system.  If someone were to hack the RTU through the external routable connection, they couldn’t access the connected device directly.[viii]

I’m not going to tell you how to roll your own interpretation of this issue.  But this might be something you want to use: “If a BES Cyber System is connected serially to an RTU (or similar device) with ERC, it only participates in ERC if it communicates with devices outside the substation[ix].”[x]

December 13: This post turned into a series of four, with some good "guest speakers" weighing in. The second in the series is here, and the final post, which tries to summarize the discussion, is here. But they're all worth reading.

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

---

[i] I’m not saying that v5 is totally unique in this regard, since v1-v3 both had a lot of ambiguity.  I think it’s more serious in v5, primarily because CIP-002-5.1 is really written from two different points of view, which never seem to get along or even try to reconcile with each other.  A lot like Congress these days.

[ii] In fact, there are 332 working days between today (Nov. 16, 2014) and April 1, 2016.  I considered putting a standard header on all my posts from now on, showing the working days left ‘til compliance.  But I decided that might get boring – as well as depressing.  Nobody would want to open up a post.

[iii] I started doing these because I realized some entities weren’t moving on v5 yet – or were just making faint stabs in that direction – because they were in effect paralyzed by the questions in their minds.  I don’t pretend to have the answers for what a particular entity needs to do; that’s up to them in the end.  But I can help facilitate the discussion among the different groups involved, and make sure it’s based on the latest facts about the new standards, their interpretations, their implementation schedules, etc.  If you’re interested in this for your entity, please email me at talrich@hotmail.com.

[iv] I’m gliding over a point here, which was that, without external routable connectivity, there wouldn’t be any CCAs at the asset in CIP versions 1-3.  But a cyber asset could have ERC and still be serially connected, as we’ll see in a moment.

[v] Remember, this requirement is talking about a local routable network, not external routable connectivity.

[vi] NERC phrases the question quite well: “Are serial based systems with local serial connections considered to have External Routable Connectivity if they are remotely accessible via routable protocol?”

[vii] I do recommend you read the entire section of the document.  It’s just four paragraphs, for heaven’s sake.

[viii] Of course, the key here is whether the customer is actually right that there is no way to hack the connected device – the relay, etc. – through the RTU.  I simply don’t know enough to say whether that’s the case or not; I’m sure there could be cases where this could happen.  So anyone rolling their own serial definition should make sure they have an answer to this question, if the auditor asks it.  And documenting that answer would be a great idea.

[ix] I’d say it’s likely that almost all of the devices to which this question applies will be in substations.

[x] Note I’m not saying “outside the ESP” as in the V1 guidance.  As has been noted, a serially-connected BCS doesn’t itself have to be included in the ESP.