SCADA Security for Critical Infrastructure (part 1)

Within the past two years, the term SCADA has begun to be thrown around as a common occurrence, however, SCADA has been around for 50 years or so, since the 1960’s.  SCADA is not new, however, due to recent events such as the emergence of Stuxnet, SCADA has been thrust into the limelight of building automation and security for critical infrastructure.

SCADA architectures can be classified into three categories:

1. Monolithic (1st gen SCADA)
2. Distributed (2nd gen SCADA)
3. Networked (3rd gen SCADA)

A Networked SCADA architecture is what most of the systems today are running as; which is where the concern about security comes from.

The first step towards securing SCADA systems (aside from JFK’s 1963 memorandum establishing the National Communications System (NCS)), was Reagan’s 1984 Executive Order 12472, Assignment of National Security and Emergency Preparedness (NS/EP) Telecommunications Functions.  In short, some of the more important NS/EP requirements include: enhanced priority treatment for voice and data services, secure networks, restorability, international connectivity, interoperability, mobility, nationwide coverage, survivability, voice band service in support of presidential communications, and scaleable bandwidth.

SCADA systems usually consist of the following:

• Field data interface devices (RTU’s, PLC’s), which interface to field sensing devices and local control switchboxes and valve actuators.
• Comm systems (radio, cable, satellite, etc) used to transfer the data between the field data interface devices and control units and the computers within the SCADA central host.
• Central host computer server(s) (sometimes called a SCADA Center, master station, or Master Terminal Unit (MTU)
• A collection of standard and/or custom software (sometimes called Human Machine Interface (HMI) software or Man Machine Interface (MMI) software) systems used to provide the SCADA central host and operator terminal application, support the communications system, and monitor and control remotely located field data interface devices.

The field data interface devices are essentially the ‘eyes and ears’ of a SCADA system.  In order to make sense of the data being gathered by these devices, remote telemetry units (RTU’s) are used to provide an interface between the field data interface devices (think water flow meters, alarm states, valve positions, etc) and the SCADA system.  HMI/MMI software allows workers to monitor the devices in the field and provides dashboard like interfaces or command-line methods of doing so.  This is where a malicious attacker can conduct surveillance on critical infrastructure, or even alter the field devices by changing configurations or launching attacks against them.

This concludes part 1 of SCADA Security for Critical Infrastructure.  Stay tuned for part 2 next week where I will outline vulnerabilities within HMI/MMI software, show real-world examples (with screenshots) and provide a rundown of popular exploitation methods.