Why SCADA Networks Are Vulnerable To Attack - Part 4: Controlling What You Use

Security doesn’t happen by accident – it must be built into or added to a network. Some of the key security building blocks for wired and wireless networks include encryption, authentication, intrusion detection, controlled access to network resources, and wireless airtime and bandwidth control.

Sensor and control networks are typically missing most of these building blocks. Designed to optimize response time, the short packets cannot easily accommodate the larger packet sizes associated with high security encryption.

Some controls networks, LONWORKS® for example, include an authentication mechanism, but in practice it is infrequently implemented because its use complicates key management in multi-vendor networks. Intrusion detection, for wired or wireless control networks, is typically not available, nor is firewalling or endpoint compliance – certainly not at the sensor/actuator level, and sometimes not even at the controller level.

Quick fixes to address these limitations are not easily incorporated because the protocols employed are often embedded inside microprocessors that lack the processing power and memory to support the necessary security algorithms, buffers, and certificates.

Fortunately most control networks today interface with an IP-based network for management, monitoring, and/or control. And it is at this interface that you can click the ruby slippers and apply proven security techniques like policy-enforcement firewalling to prevent the control network from launching Denial-of-Service (DoS) attacks or non-compliant devices from accessing the network.

If the control network is IP-based then the protective measures can be applied to the control devices themselves – if not, then protection can only be applied to data traversing the interface between the sensor/actuator network and the IT systems to which it is connected, i.e., the latter can be protected against the former. Either way, greater security will be obtained than if no protective measures were applied between the control devices and the network with which it is connected.

The range of available security features that may be applied depends on the control network architecture, and includes:


The protective measures afforded by these techniques can be applied prophylactically to reduce some or most of the control system’s vulnerabilities.

With regard to cost, if Wi-Fi based sensors and actuators are used, the protective measures built into the wireless LAN infrastructure can be applied at little or no additional expense. If IP-based sensors and actuators are used, there will be some incremental expense but the devices themselves will not have to replaced because they already have the essential building blocks for higher security in place. If a non-IP based control network is used then the benefits will vary.

The table below summarizes how the security features described above can be employed to enhance the security of commonly used in control networks (features specific to wireless networks are left blank when applied to wired control networks).

Conclusion

SCADA, smart grid, and energy management systems sit at the heart of industry and commerce. This blog series was intended to highlight that defending these systems against attack must become a high priority because you can't use what you can’t control.

The control networks on which these systems depend today have unintended vulnerabilities. These vulnerabilities can be corrected in whole, part, or not at all depending on the architecture and technology of the underlying network.

Consideration should be given to retrofitting security systems into existing IT infrastructure to address security concerns, removing control networks for which there are no corrective measures, and ensuring that any new control-related infrastructure is designed with protective measures built-in from the outset.

For more information on security solutions that you can apply today please visit Aruba's Web site.

Why SCADA Networks Are Vulnerable To Attack - Part 3: Firewall Both Users AND Devices

Following a rise in the theft of payment card data, the Payment Card Industry (PCI) standards council was created by the top card brands to combat such crime. The resulting PCI Data Security Standard (DSS) defines mandatory security guidelines for use by all merchants and service providers that store, process and transmit cardholder data.

Wireless LAN security is a core component of these requirements. DSS v1.1 permitted the use of WEP encryption. Indeed, many retailers wanted to continue using the WEP devices they had already purchased, not because of the encryption scheme but to avoid the capital outlays required to replace WEP devices with higher security equivalents.

While WEP encryption is easily cracked, and was subsequently banned under DSS v1.2, an ingenious method was used to protect WEP devices so they could continue in service until DSS v1.2 was implemented. This solution protected the network without requiring any changes or clients added to the WEP devices. This solution holds great promise for the protection of SCADA, smart grid, and energy control systems.

Consider the humble bar code scanner. A workhorse of both point-of-sale (POS) and logistics systems, many scanners in use today rely on 802.11b/g Wi-Fi and WEP. Data from the scanners are passed via Wi-Fi to the enterprise network. If you crack WEP you therefore potentially open a back door into that network.

Integrating a stateful, role-based policy enforcement firewall into the wireless network slams shut this back door. By blacklisting unauthorized devices – not based on the port through which they entered the network but rather by the user and/or type of device - unauthorized users can be denied access to the rest of the network.

The firewall can distinguish between multiple classes of users, allowing one common network infrastructure to function as independent networks whose isolation is ensured by policy enforcement. Guest access is separate from POS which is separate from logistics, etc.

The elegance of this approach is that it can be retrofitted to existing networks – wired and wireless using a true overlay model - without any software clients or other changes to the devices being protected. It protects any devices from any manufacturers.

This same segmentation and policy enforcement scheme can be applied to wired and wireless sensors as soon as their data hit the IT infrastructure. Access rights, quality-of-service, bandwidth, VLANs – almost any parameter can be controlled and actively managed by the stateful, role-based policy enforcement firewall. It is to the benefits of this approach, used in conjunction with additional security enhancements, that we’ll turn in the next posting.

Why SCADA Networks Are Vulnerable To Attack - Part 2: The Weakest Link

In the beginning, there was cabling - lots of cabling. Every sensor, actuator, and display was connected by a separate cable that grew like a hydra from a controller, the brains of a traditional control system. If a solenoid needed to be triggered in response to the activation of a limit switch then the signal traveled from the limit switch, through cabling to the controller, which processed the information and sent a command to the solenoid over yet another cable.

These direct wired systems were subsequently replaced with time or frequency division multiplex systems that allowed one common cable to be shared among multiple devices. Installation was simpler and less expensive, the controller was more complex and, as before, a central point of failure should its program fail to execute properly.

Next up were intelligent, distributed networks in which devices communicated directly with one another on a peer-to-peer basis, without the need for a central controller. Locally intelligent and able to communicate on shared communication medium with any other device on the network, these networks allowed reconfiguration of system functionality via software download over the network. Peer-to-peer communications allowed the direct exchange of information between any or all of the devices without intervention by any central device, eliminating the single point of failure issue.

Regardless of the specific architecture used, in all cases the objective of the control network was to deliver status information as quickly as possible to all devices that needed updates. The protocols we’re highly optimized for short control packets, and nary a bit was “wasted” on ancillary data or status.

The same optimization guidelines applied to the microcontrollers running the devices. To keep costs down and thereby allow the networks to be pervasively deployed down to the lowest cost sensor/actuator, processors were optimized for high throughput and processing short packets.

The popularity of IP connectivity spawned the development of IP-based control networks in which Ethernet or Wi-Fi forms a backbone for linking different sections of a control network. While controllers were the first devices to sit on an IP network, increasing numbers of native IP sensors and actuators are reaching the market.

Many IT departments prohibit the connection of any IP-based, control-related sensor/actuator, controller, gateway to their corporate networks out of concerns about network integrity and security. IT managers are legitimately concerned that the high offered traffic of control networks, some of which run at 100% channel utilization, will overwhelm their Ethernet networks and cause unintentional denial of services. Others are concerned that control networks, the security standards of which are rarely a high priority, could become unprotected back-doors into the corporate network.

What is rarely if ever discussed is how exposed the enterprise is to unauthorized manipulation of the control devices themselves. These systems control the power at the heart of every business and institution, and it is paramount that they be protected against unauthorized manipulation. It is to this point that we’ll return in the next installment of this series.