SCADA Security: 14 Obvious Points of Attack

By William T. Shaw

To reduce the probability of a successful cyber attack on a utility’s SCADA system, steps must be taken to eliminate potential points of vulnerability. However, what are the points at which an attacker will concentrate, and what types of attacks can be used?

Click here to enlarge image

The Figure on page 44 shows a simplified SCADA system architecture and the typical (and all too obvious) points from which a cyber attack could be perpetrated. These are undoubtedly not the only points of vulnerability, but taking actions to secure these will greatly reduce the likelihood of a successful attack. There are 14 well-understood ways in which an attacker could seek to penetrate your systems. Some of these vulnerabilities assume an inside attacker, others an outside attacker:

1. Any unsecured dial-in telephone line is an obvious point of vulnerability. Use of modem dial-back mechanisms and simple ID/password access controls are not sufficient to secure these points of access. Use of VPN (virtual private network) technologies, including strong authentication mechanisms (digital certificates, as well as ID/password mechanisms or even token-based passwords) plus limitations on remote login attempts, is essential if these telephone lines cannot be disconnected.

In addition, to protect against an attack by a former insider, there needs to be a policy and procedure to immediately invalidate all digital certificates (a process called revocation), system user IDs, and passwords and the electronic access rights of a person who has been terminated, who has voluntarily resigned, retired, or whose contracting services have been discontinued. (This is in addition to the obvious recovery of company owned equipment, software, credentials, keys, etc.) It is also an added deterrent to require that people with access to critical information sign nondisclosure and confidentiality agreements (as part of an employment offer or contracting agreement), which should be reviewed, making clear any ongoing obligations and legal consequences at the time of termination or contract completion.

2. Malware can be introduced into a system and/or network by someone bringing infected removable media into the facility and inserting it into a PC. Use of virus-scanning software in every PC helps to reduce the possibility of infection. However, better still would be to have a policy that discourages bringing unscanned removable media into the facility and a procedure for scanning and cleaning any removable media that must be brought into the facility. NIDS and HIDS (network-based and host-based intrusion detection systems) packages are also valuable for detecting the presence of malware that manages to slip by other detection mechanisms (e.g., malware brought in intentionally by an inside attacker who obviously ignores the stated policies and procedures).

In addition, to protect against an attack by an insider who has electronic access to systems, strong-authentication mechanisms (possibly including biometrics) can be used to prevent an insider from upgrading his or her access rights by stealing another employee’s ID/password. This also means that careful consideration needs to be given to the assignment of access rights and to the information and resources permitted under given access rights. HIDS packages (and system log monitoring and scanning programs) can also be used to identify users who are attempting either to elevate their access rights or to use resources or access information that is not permitted to them under their ID/passwords. Another concept of cybersecurity, within the area of operational security is separation of duties. This is a procedural mechanism to ensure that no single individual, regardless of access rights, has all of the access necessary to cause irreparable damage.

3. A new threat that has emerged in the past couple of years is the possibility of a Bluetooth-enabled device (cell phone, camera, laptop PC, or PDA) being infected with a virus and passing that virus to other devices (e.g., a Bluetooth-enabled laptop PC that also has an Ethernet interface) that can bridge the virus onto the SCADA system LAN. This problem becomes more complex as Bluetooth is embedded in more devices, such as printers and scanners. A virus could be passed to these devices and then find its way into a computer that accesses that device. Again, virus scanning in all laptops would aid in detecting and stopping such a virus, as would a NIDS package. A policy requiring that all such devices be turned off prior to entering an area with sensitive computer equipment (or disallowed in such areas) can also prevent such infections, because of the transmission-range limitation of Bluetooth.

4. Another potential vulnerability is any WiFi-enabled computer that also has an Ethernet connection. An attacker could use the WiFi connection to bridge the SCADA system LAN, potentially obtaining the access rights of the owner of the computer via this connectivity. A policy of disabling WiFi capability while a LAN connection is in use (or disallowing the connection of WiFi equipped devices to the SCADA LAN) can lessen this vulnerability.

5. A rogue or insufficiently protected WiFi AP (access point) can be attacked in much the same way, although this would give the successful attacker access to the LAN and additional effort would be needed to break into the systems. A NIDS package would be useful in detecting an attacker’s network access, if penetration of an AP was successful. Proper configuration of all APs (disabling DHCP, disabling the broadcast of the SSID, enabling encryption, specifying MACs for authorized users, etc.) is essential. If WiFi usage is extensive, it may be worth considering a WiFi-monitoring package, which acts like a NIDS but uses selected APs to monitor WiFi traffic. Such applications can identify rogue APs, as well as improper security settings. It might also be worth rethinking the use of WiFi; if it can be eliminated, do so and enact a policy that prohibits its usage. Obviously, enforcement of such a policy will require occasional sweeps of the facility, looking for any unauthorized WiFi devices. With WiFi being built into so many devices, it may be more prudent to accept its inevitability and take actions to manage and monitor its usage.

6. All connections between the SCADA system and other LAN/WANs must be adequately protected by firewall technology. An insufficiently configured or technically inadequate firewall can be a point of access for an external attacker. Firewall technology generally advances to keep pace with the latest attack methods employed, and thus, it is critical to keep your firewall up to date with current revisions. Where access can be restricted to a few well-known services (e.g., e-mail, web browsing, ftp) the use of an application proxy server as the firewall enhances the level of security.

7. The most basic vulnerability of a SCADA system is to an insider attack by someone who has physical access to the SCADA system itself. Such an attacker, having first taken steps to damage the restoration media, could go up to the system console and issue commands to delete critical files and applications on both the primary and the backup systems. A system-level programmer or a system administrator with root (admin) access has essentially unlimited ability to wipe out the software of the operating system, in addition to SCADA-specific programs and data files. This does not even have to happen while that person is present. A high-level batch script (running at the admin/root level) could be placed into the system for execution at a later date/time, and this script could issue the same commands that the attacker would have entered.


Typical points of SCADA system vulnerability
Click here to enlarge image

Such a highly placed insider would undoubtedly be aware of alternative backup systems and operating sites and would probably have the same level of access at those facilities, as well as reasons to visit occasionally. This type of attacker has the highest chance of staging a successful attack; few technical mechanisms would prevent such an attack from happening, since this attacker would, based on his or her authority level, have the ability to disable or manipulate these mechanisms. The best mechanisms to protect against such an attack are mainly procedural, as by enforcing the use of separation of duties.

8. Along a similar line, an insider who had operational access rights on the SCADA system (e.g., a senior operator) could issue commands through the operator’s console, causing dangerous or destructive control actions (e.g., tripping circuit breakers, closing valves and stopping pumps). This would be even more dangerous if that same attacker had remote operational system access (e.g., remote X-terminal emulation or actual operator console software). Few if any SCADA systems offer any mechanism to prevent such operational abuse. It is typically assumed that if this person has been trusted with such access rights, then the person is both properly trained and trustworthy.

In the future, SCADA system vendors may offer some mechanism (e.g., a two-man rule) that precludes a single individual from issuing critical control commands. Such control actions would require the agreement of a second operator, possibly via a separate password or by biometric authentication. (The military use the two-man rule for operations like launching an intercontinental ballistic missile. Two officers must concur, or the launch can’t happen.) In the meantime, one recommendation by NERC is to perform initial and thereafter periodic background checks on all personnel who have such high access levels.

9. Just as malware can be introduced into a PC on the SCADA LAN, the same thing can happen on the corporate LAN/WAN and, if the firewall separating the SCADA LAN from the corporate WAN isn’t adequate, the malware can find its way onto the SCADA LAN and into the SCADA system computers. As with item 2, corporate user’s access needs to be managed and administered properly so that corporate computers can’t be used to access and attack the SCADA system.

10. Just as a WiFi AP can be used by an attacker to break into the SCADA system LAN, the same thing can be done on the corporate LAN/WAN, and this again places the firewall as the remaining defense between the SCADA system and an attacker. All WiFi access points on the corporate/enterprise LAN/WAN need to be suitably protected, and rogue APs, if any, must be identified and removed.

11. In a large and geographically distributed corporation, the likelihood that there are unsecured telephone connections to a corporate WAN is probably greater than the likelihood that such connections to the SCADA system exist. However, these telephone connections into the corporate WAN may pose a threat to the SCADA system and provide a path for an attacker to reach the SCADA system, if the SCADA system is interfaced to the corporate WAN at any point. Those telephone connections also need to be secured using the mechanisms described earlier (see item 1).

12. Corporate web servers, e-mail servers, and Internet gateways are constantly exposed to attackers coming across the Internet. For these computers to be useful, this is a risk that must be accepted. Most IT departments know how to set up a network demilitarized zone (DMZ), using layers of firewalls and proxy servers to isolate and protect the corporate network while exposing these same servers to the potential attackers. As with any firewall scheme, it is essential to keep this equipment up to date with security patches and the latest virus/worm updates. It is also advisable to have a suitable consultant perform a penetration test (commonly referred to as pen testing) to validate the configuration and security mechanisms. Computer-security consultants often employ white-hat (ethical) hackers, who attack your systems with your knowledge and permission in an attempt to identify (but not exploit) any vulnerability in your systems.

13. Any point-to-point connections between a SCADA system and another system through a public or private network (possibly a backup SCADA system at an alternative operating site or a regional control center) should employ VPN technology, which can run in the router at each end of the dedicated link. Most routers today can be set up with digital certificates and provide authentication and encryption, including occasional regeneration and re-exchange of the encryption keys.

14. Unfortunately, most SCADA systems use readily available, well-documented legacy, serial communications protocols for interrogating and commanding their field-based RTUs. Just as unfortunate is that a huge proportion of those RTUs are connected by single-frequency licensed radio or leased analog telephone circuits. Although some of the new network-ready RTUs are capable of IP and encryption, the vast majority of the installed RTU base are not, and quite a few of the SCADA hosts would need extensive upgrading to support secure IP. It has already been proven that a person with a radio, a laptop PC, some commercial software, and reasonable physical proximity can take control of RTUs and override the SCADA system. Tapping into a telephone line requires a bit more work, but not much-and in that case, the attacker can cut the SCADA system off entirely and control any RTU on that same telephone line.

It may not seem that hijacking an RTU presents much of a threat, but that depends on what that RTU is controlling. If an attacker were to close the right valve, shut off the right pump or trip the right transformer, the effects could propagate and be amplified by the process dynamics. Bump-in-the-wire (protocol-transparent) encryption devices, specifically designed for SCADA applications, are becoming available for securing serial communication lines. These seem to work well for asynchronous protocols, but may not work with some of the bit-synchronous protocols still used by the electric power industry. Most such devices expect to be placed between the EIA-232 port of the RTU and the modem of the RTU (unless they incorporate modem circuit and thus replace the model). With older RTUs that have a built-in modem, this won’t be a viable solution. As SCADA system owners switch from analog communications to digital communications, other security mechanisms will become available to protect these communications.

Click here to enlarge image

“Cybersecurity for SCADA Systems” is published by PennWell Corporation. The 562-page book is available from www.pennwellbooks.com.

Previous articlePOWERGRID_INTERNATIONAL Volume 12 Issue 6
Next articleNexus announces availability of hosted MDMS

No posts to display