Forgot your password?

Electric Cybersecurity Regulations Have a Serial Problem 40

Posted by Soulskill
from the locking-the-door-before-you-finish-building-the-wall dept.
msm1267 writes "A class of SCADA vulnerabilities discussed at a recent conference is getting attention not only for the risks they pose to master control systems at electric utilities, but also for illuminating a dangerous gap in important critical infrastructure regulations. The flaws, many of which have been patched, demonstrate how an attacker could target a non-critical, serial-based piece of field equipment at an electrical substation and knock out visibility over all of a utility’s substations. 'Where serial lines come into a master station, for instance, they won’t have the same level of protection that a TCP/IP-based connection would have,' said Michael Toecker, an ICS security consultant and engineer at Digital Bond. 'There’s a complete regulatory blind spot there in the current version of the NERC standards.' Some of the non-critical devices Crain and Sistrunk talked about at S4 rely largely on physical security to keep them safe, and are not covered by NERC regulations. Initiatives such as the Smart Grid are all about pushing intelligence away from substations and into areas where it may not be practical to have adequate physical security. 'No camera. No fence. Just a lock pick away from somebody getting at that cabinet and then affecting visibility for a huge subset of the distribution system,' Crain said."
This discussion has been archived. No new comments can be posted.

Electric Cybersecurity Regulations Have a Serial Problem

Comments Filter:
  • by ZouPrime (460611) on Friday January 24, 2014 @03:45PM (#46059973)

    I've work extensively with NERC CIP v3 - there's a BUTTLOAD of blind spots in the standard, but it's also true for PCI and others, and it will also be true for NERC CIP v5.

    These regulations generally aim for basic security controls, in industries that have little to no information security culture, so they start with some basic stuff. And even this basic stuff is hard to sell and implement.

  • Re:More regulation (Score:4, Insightful)

    by fuzzyfuzzyfungus (1223518) on Friday January 24, 2014 @04:16PM (#46060265) Journal
    Have we at least considered the possibility that treating serial lines as physically vulnerable isn't the dark path to fascist totalitarianism?
  • by LoRdTAW (99712) on Friday January 24, 2014 @04:18PM (#46060301)

    TL;DR - If people can get physical access to your fieldbus network then you have much bigger problems. Network security isnt going to do squat.

    These hand waving "OMG fieldbuses are weak" articles are total BS. They either have little knowledge of houw an industrial system works or they are just looking to get published for some "street cred".

    The problem with field bus protocol designs is that they are designed for very low overhead and latencies. Field busses are usually designed as a simple master/slave protocol in which the master sends out a packet with a device address and a command and the slave might reply. Many are based on a multidrop serial bus like RS485/422, CAN and ProfiBus. The benefit of such a design is they use low bitrates which allows for some serious distance often hundreds or thousands of meters. It greatly simplifies wiring as you have a single serial line from an RTU/PLC/PAC snake around the machine or plant and control just about anything. They arent on a switched network like ethernet, its more like 10base-2. Anyone can tap the bus at any point and read/write it without much effort.

    For example a valve might have a few commands such as open valve, close valve and valve position (meaning what is the status of the valve, open or closed). So to close the valve you simply send a packet with the address and command that says close then poll the position until you see it say closed. Some valves might let you issue a command to say open 35% and then poll until you see a position value returned of 35% open. And its not only valves but motor controllers, servo motors, encoders, pressure/temperature/strain/moisture/etc sensors, you name it.

    The problem with security on a fieldbus is not only latency (more data means higher latency between a command send and then receiving a reply) but how do you implement security in a valve? How do you make it easy to program the valve to securely talk to the master station? You still have the physical access problem if someone can get at the valve and read a key from it using a programmer. And if there was a method to program the valve with yet another password to block unauthorized programming, what if the password is leaked or forgotten? A valve could be replaced but if its part of a critical system or weighs a few tons and is in an underground vault then your in trouble. Or maybe its buried deep within a machine and requires many hours of downtime to get at and replace. You still have the human weak link of someone knowing the passwords and keys. What if a particular key for a sensor network is stolen or lost? Then you have to send a team out to reprogram every field bus device to the new key. Even if the master station could issue a command to reprogram every device on the network with a new key then physical access can still enable a malicious person(s) to sniff the new key or program new keys. Security isnt a set it and forget it process, its staying continiously vigilent and MONITORING your networks both electronically and physically. And that clasehes with the cut costs/more profit mentality of todays corporations.

    So in the end all this "OMG teh networks are insecure!" handwaving is a non-problem. Fieldbus protocols arent the problem. Lazy, cheap companies who dont want to pay for physical security are the problem.

Can't open /usr/fortunes. Lid stuck on cookie jar.