In August, I
put up a post
discussing machine-to-machine remote access into an ESP. The problem is that such
access is not covered by CIP-005-5 R2, the requirement that protects
Interactive Remote Access into an ESP. This is because the definition of
Interactive Remote Access contains the sentence
“Interactive remote access does not include system-to-system process
communications”. In other words, IRA only applies if there is a
human being sitting at the keyboard of the remote computer that is
communicating with devices in an ESP, not if that remote computer is operating under
the control of a script or other program.
Many think
this provision amounts to a dangerous loophole in the CIP standards, since it
is clear (to me, anyway) that a remote machine acting autonomously could cause
as much or more damage in the ESP as a machine operated by a human being.[i] This
concern seems to have risen to the forefront fairly recently. Had it been a big
concern last year, I assume NERC would have added it to the list of changes
that the current “CIP v7” Standards Drafting Team is working on,[ii] but
they didn’t do that.
The most
important expression of dissatisfaction with this situation came from FERC in
their July Order 829,
which required NERC to develop a new CIP standard covering security of the
supply chain. In that Order, they listed four areas the new standard should
address, one of which is “Vendor Remote Access to BES Cyber Systems”. Their two
discussions of this topic (pages 36-38 and 49-52) make clear that they are very
concerned about the lack of protection for machine-to-machine remote access
into ESPs. They point out (page 51) “When the interactive remote access
management controls of Reliability Standard CIP-005-5, Requirement R2 do not
apply, a machine-to-machine remote communication may access a BES Cyber System
without any access credentials, over an unencrypted channel, and without going
through an Intermediate System.”[iii]
What does
FERC ask NERC to do regarding vendor remote access? FERC says (page 36) “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.” How does this objective
compare to CIP-005-5 R2?
- Most importantly, it brings remote vendor machine-to-machine
access into scope for CIP.
- It applies only
to remote access by vendors. This isn’t to say there is no problem with
any other remote access, but only that a supply chain standard can only address
remote vendor access. If other remote machine-to-machine access is to be
covered by CIP (and the only other significant remote access into ESPs
that I know of is access from the entity’s own IT network), this will need
to be done by revising CIP-005 R2.
- It doesn’t mandate encryption and two-factor
authentication, as CIP-005 R2 does.
In my opinion, both of these controls are somewhat irrelevant when
it comes to machine-to-machine communications, although they are very
relevant for user-initiated communications. Of course, entities that have
Medium or High impact assets will have these controls in place already for
user-initiated remote access.
- It requires “logging and controlling”[iv]
all vendor-initiated remote access sessions, both machine-to-machine and
user-initiated. Note that neither of these is required in CIP-005 R2. This
may be due to the fact that these capabilities may require some sort of
deep packet inspection, which was a very new technology when CIP v5 was
being developed. FERC may feel that DPI is now at the point where CIP
should take advantage of it.
I basically
support what FERC has ordered, although the CIP Supply Chain SDT will need to
make sure that the requirements they develop aren’t too onerous. For example,
if they are going to require the ability to monitor all vendor remote access in
real time and terminate a session when it takes a malicious turn, this will
require a very significant technology investment, plus raise the possibility
that essential vendor remote troubleshooting sessions will be terminated
because of false positives in the session monitoring technology. This will
obviously hurt BES reliability, not improve it.
So I think
machine-to-machine remote access by vendors will be adequately addressed in the
new Supply Chain standard. How about machine-to-machine remote access by non-vendors,
which I believe means principally devices on the NERC entity’s own IT network?
My next post will discuss the issues there, and how I think they can be
resolved.
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte Advisory.
[i]
Some point out that even a machine will have to get through whatever firewalls
the entity may have in place, so that constitutes control. But most firewalls only
deny or permit access. If the remote machine has access permission already but
has been commandeered by some nefarious actor, it will usually be free to do
whatever it wants once it is inside the ESP. In fact, this seems to be almost
exactly what happened in the Ukraine attacks.
[ii]
Just because it isn’t on the SDT’s agenda, this doesn’t mean they couldn’t
address it. But I haven’t heard any discussion about that, and frankly these
people have enough to do in their current agenda that I’m sure they couldn’t take
on another major effort at this point.
[iii]
FERC clearly did not see this problem when they approved
CIP v5 in November 2013. If they had, they would presumably have ordered that
NERC fix it in CIP v6.
[iv]
In the next paragraph on page 36, FERC states “controls adopted under this
objective should give responsible entities the ability to rapidly disable
remote access sessions in the event of a system breach.” This appears to be the
primary objective of requiring the capability of “controlling” remote access
sessions. As I was writing this post, I received an email from the new CIP Supply
Chain SDT that includes a discussion draft of a proposed CIP-013 standard. This
requires entities to “restrict” and “monitor” vendor remote access, as well as to
“Detect and respond to unauthorized third-party remote access on a BES Cyber
System.” I’m not sure these requirements completely address what FERC is asking
for in the word “controlling”, but I’m sure the SDT (with participation by FERC observers) will
figure this out.
No comments:
Post a Comment