Securing SCADA Systems

I’ve written here several times about some the efforts that are underway to move to a “smart grid” for electricity distribution.  One part of most of those efforts involves the installation of “smart” electric meters, which are networked computer-based devices, rather than the electromechanical meters used for decades.   The drive to develop and install these devices has generated some concerns about the security of the resulting system.

There are, however, some more fundamental security concerns associated with the SCADA systems [Supervisory Control and Data Acquisition] that are already in place.  As I mentioned in an earlier post on potential risks to the power grid, many of these systems had their origins in the days when their data communications took place over private leased lines; today, though, many have been adapted to communicate using the Internet, because it is materially cheaper.  This, of course, presents an enormously increased system “surface” that is exposed to attack.

The SANS Institute’s Internet Storm Center has an excellent diary entry, by Manuel Humberto Santander Pelaez, who is Chief Information Security Officer for a utility company, about the challenges of implementing an information security framework in a SCADA environment.  He starts by making the obvious, but important, observation that the stakes in this security game are high; the economic and social cause of service disruptions can be severe, even if there is no objective more sinister than mischief.

He goes on to point out some less obvious obstacles to achieving adequate security.  These systems are meant to control the distribution network in real time, so anything that causes degraded response times is problematic.

SCADA systems have a very particular operating environment. Because they are real-time systems, data monitoring and orders sent to the RTU [Remote Terminal Unit, e.g., a power substation] should arrive in the shortest time possible, since an additional delay of even 10 ms can mean a massive blackout by activation of the protections of a substation. Similarly, suppliers of these systems tend to provide support on these only on a specific configuration, which is usually not too safe and lacks basic security controls such as security patches, data encryption, authentication and non default configurations.

The lack of authentication, and the common use of clear-text data transmission protocols, probably reflects the origins of these systems in a closed environment; they have just not been updated to reflect the new reality of Internet connectivity.  Because of performance concerns, the inclusion of otherwise standard protections, such as Intrusion Prevention Systems or malware detection, is usually resisted.  (In the article, Mr. Pelaez explains that his firm had to introduce a three-hour window, during which the system was manually controlled, to allow for software updates, security fixes, and malware scanning.)

The article is well worth a read; it is an interesting look at the practicalities of trying to secure a large system that was not built with security in mind.

Comments are closed.

%d bloggers like this: