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.