Monday, November 24, 2014

Follow-Up to Last Week’s Serial Post (not Post Cereal)

In my post
on serially-connected devices last week, I discussed the question whether
devices (usually in substations) that are serially connected to an RTU or
similar intermediate device[i]
that participates in external routable connectivity (ERC) do themselves
participate in ERC for the purpose of CIP v5.
My personal opinion[ii]
is that, if the end device communicates externally through that intermediate
device (as described in the CIP v1 CCA Identification guidance document I
referenced), then it does have ERC. If
it doesn’t so communicate, it doesn’t have ERC.

Of course, then the discussion becomes what “communicates
externally” means. There’s a lot of room
for debate on that topic – as I found out from a few other parties in emails
last week. One distinction that seems to be important is whether the
intermediate device simply translates the incoming routable messages into a
serial protocol for the end device, or whether the intermediate device does
something like polling of the end device, meaning that incoming routable
messages aren’t passed on in any way. A
terminal server might be an example of the first device, while an RTU might be
an example of the second.

However, this distinction would go away if it
were possible to hack through the RTU to the end device – because in that case
the end device would be able to
communicate externally (not by intention of course, but that’s not the issue in
cyber security). In the post, I state
that I’m assuming “If someone were to hack the RTU through the external
routable connection, they couldn’t access the connected device directly.” A footnote to this sentence says that the
entity that decides to use my “guideline” for ERC, and therefore excludes
serial devices connected to an RTU that communicates routably outside the
facility, probably needs to be prepared to convince the auditor that it isn’t
likely this hack can occur.

So
guess what happened? You’re right…The
next day I got an email from a cyber security professional at a large IOU,
providing an example in which it would be possible to do exactly that – namely,
to hack a routable connection to a remote RTU, that is itself connected
serially to one or more local devices, and attack one of those serial
devices. Here is what he said, although
I have removed the manufacturer and model name to protect the guilty (and to
save my a__ from getting sued): “You can
remotely communicate directly with any relays connected serially to a (particular manufacturer/model), log in
to the serial device and reprogram or (do) anything you could do to it if (physically)
connected directly through the serial connection (port), if it is not properly
configured.”

The moral of this story is that, if you’re
going to claim that a serial device – set up with an intermediate device as
discussed above – doesn’t participate in ERC, you need to convince the auditor
that it’s very unlikely the device could actually be attacked.[iii]

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

[i]
This isn’t to be confused with the Intermediate System – a new NERC defined
term – that forms the basis of the new requirement for Interactive Remote
Access, CIP-005-5.1 R2.

[ii]
There is supposed to be a NERC Lessons
Learned document coming out soon (in draft form) on this issue, but you can’t count
on it to a) provide a definitive answer or b) be finalized in time for you to
start your substation compliance work (and you definitely can’t count on it
having the same status as an Interpretation arrived at through the normal 2-3
year RFI process). If you need an answer
now, you should consider the “Roll Your Own” approach that I have been
discussing lately, starting with this
post.

[iii]
You might do this by demonstrating that
there haven’t been any such vulnerabilities identified by ICS-CERT or similar
organizations.