Wednesday, December 3, 2014

Sean McBride Weighs in on Serial


I was pleased to receive an email from Sean McBride, co-Founder of Critical Intelligence, about my most recent post on serially-connected BES Cyber Systems in Medium impact substations (this post was a follow-up to the first post, and his comments apply equally to that one).  I’ve always had tremendous respect for Sean, who has really done great service to the electric power industry through his company.  I recommend you spend a couple minutes on his website to see if his services would benefit your company, by keeping you abreast of new vulnerabilities affecting the particular control systems in your environment.

There was an added “bonus” in his email: He mentioned that he is a blogger, too, and provided this link.  I went to his blog, and was really impressed by the very interesting (and so far unknown to me) information he presented, as well as his very fluid writing style.  I also really liked the brevity of his posts - which are very different from those of a certain CIP v5 blogger, who writes seemingly interminable pieces that require the better part of a day to get through - and read about 6 or 7 of them in my first shot.  I’m definitely putting Sean’s blog on my bookmarks bar and will go to it regularly.

We sent about four emails back and forth, but here is the principal point Sean made: Probably the biggest “vulnerability” for serially-connected devices in substations is not that an attacker can hack the device coming in through an RTU that communicates routably with the outside world.  Rather, it is just the reverse: that someone knowledgeable will physically break into the substation, hack into the serial device (e.g. a relay) and use the DNP3 vulnerabilities[i] demonstrated in the last couple of years by Adam Crain and Chris Sistrunk to attack the EMS system itself.

I agreed with Sean that this is a real concern from a cyber security point of view.  But I also pointed out that I don’t see this as something that CIP directly addresses, other than by the fact that the substation needs to be physically secured under CIP-006.  There is nothing in CIP (any version) that says that communications protocols need to be secured, especially for communications between the substation and the EMS.[ii]

While Sean understood my point, he did add "It is super important that electric system operators understand that if an adversary gets access to an insecure-by-design level 1 protocol (DNP3, Modbus, etc -- serial or TCP), then it is ‘game over’ -- the attacker can do what he wants.”  And there you have it: Whether or not CIP requires it, all Transmission Owners/Operators should look into securing the serial protocols they use to communicate with substation devices, both from the EMS and within the substation itself.  And this applies to more than just DNP3 – also to other serial protocols like Modbus.

Before I finish, I do want to bring up another point that Sean made.  This had to do with my third footnote in the second post on serial.  That note referred to the final sentence of that post, which read “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.”  My footnote said “You might do this by demonstrating that there haven’t been any such vulnerabilities identified by ICS-CERT or similar organizations.

Sean’s comment on this was similar to his comment on the other issue: “…any device speaking an insecure by design protocol (e.g. DNP3, Modbus) is essentially open for abuse.”  I take this to mean that simply demonstrating to the auditor that there aren’t any publicly exposed attacks against a particular type of device at this time doesn’t also demonstrate that there never could be an attack – especially when a protocol has been shown to be insecure already. 

So now I’ve contradicted myself in just a few paragraphs (I believe this is a new record for me – usually I wait until at least the next post to contradict myself).  In the first part of this post, I told you I didn’t think you had to address the DNP3 vulnerabilities in order to comply with CIP; in the second part, I implied you might need to demonstrate to the CIP auditor that you have taken steps to address DNP3 vulnerabilities.  To quote Emerson, “…consistency is the hobgoblin of little minds.”   I certainly don’t want to be accused of having a little mind, especially by Emerson.


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

[i] Technically, the vulnerabilities aren’t in the DNP3 protocol itself, but in its implementation by the majority of vendors.  However, IMHO this is a distinction without a difference.  If a protocol is insecurely implemented in the great majority of cases, it is an insecure protocol.

[ii] Since communications between ESPs is explicitly ruled out as a subject of CIP, the external communications aspect of the DNP3 problem is definitely out of scope for CIP.  But I’m not prepared to say that internal communications using DNP3 (e.g. between an RTU and a relay in a substation) are definitely out of scope; this is because of FERC’s directive to NERC in Order 791, saying that “communications networks” within the ESP also need to be secured.  Since that directive was mainly concerned with the issue of cabling (and switches/hubs) between devices within the ESP, which (cabling) goes outside the PSP, I’m inclined to doubt that Order 791 really requires the DNP3 problem to be addressed for internal substation communications.  But it’s an interesting question.

No comments:

Post a Comment