27 July 2010

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.

Why SCADA Networks Are Vulnerable To Attack - Part 1: Unintended Consequences

This multi-part series discusses the security vulnerabilities of the sensor/actuator controls at the heart of SCADA, smart grid and energy management systems, and proposes a means of containing, if not fully addressing, the limitations of these systems.

* * * * * * *

In the 1980s the proximity access card was introduced to the building security market. Until that time, gaining access to high security facilities – including many government agencies – required one to physically insert a magnetic stripe or Wiegand card into a reader.

Proximity card readers from Schlage, Sielox, Indala, and others overcame the inconvenience of swiping a card by using radio energy to sweep the area in front of the reader.
Users needed only to place their wallet, purse, valise, or ID badge near a reader and the radio energy would be picked up by their proximity card.

A tuned circuit internal to the card would resonate when within range of the reader, generating a unique radio signature that would be captured and analyzed by the access control system. If the signature matched that of a valid card already programmed into the system, access would be granted. Simple, elegant, and convenient, proximity card systems quickly grew in popularity.


Problem was, this innovative technology had profound, unintended consequences. It allowed the surreptitious identification of people with access privileges to high security facilities. One could use radio energy to sweep a crowd of people and, by virtue of their proximity card, pick out persons of interest based on their signatures generated by their proximity cards. At a time when the Cold War was steamy hot and espionage was rampant, the proximity card was a new-found tool for adversaries.


The unintended consequences of a new technology are not usually discovered until after it's in use, sometimes widespread use, by which time available remediation options might be limited or very expensive. Such is the case with SCADA, smart grid, and energy management systems, which are now front and center in the effort to better manage energy consumption and lower greenhouse gases. Unintentionally vulnerable to manipulation and unauthorized access, these systems can literally turn out the lights, stopping a utility or enterprise cold in its tracks.

(
Photo: www.brightsecuritygroup.com)

15 July 2010

Is there a role for Wi-Fi in offloading traffic from cellular networks?

We are today witnessing a mobile device boom driven by distributed workforces that need secure anywhere-connectivity, and consumers who want always-on Internet access. Smartphone sales grew 29% year-over-year in 2009 to surpass notebook sales (1), and dual-mode (Wi-Fi/cellular) phones and smartphones will more than double from 2008-2013 to 130.9 million units (2).

One consequence of the flood of mobile devices is growing congestion on cellular data networks. Slow and dropped network connections are legion in large metropolitan areas like Beijing, New York, and San Francisco. Cellular data traffic is rising beyond sustainable network capacity, and there are no signs that it abate any time soon.


This problem is compounded by the challenge carriers face in obtaining acceptable ROI from their massive infrastructure investments. Value-added services like video help a carrier’s bottom line, but the more bandwidth-hungry video booms, the greater capacity is squeezed. Sticky new services and applications needed to secure customer loyalty only add to bandwidth woes.


One solution is to offload bandwidth-intensive multimedia traffic to nearby Wi-Fi networks, a process called “cellular offload.” In theory pushing traffic from overcrowded cellular networks onto high capacity, high-speed Wi-Fi networks should alleviate network congestion. The challenge for carriers is ensuring that bandwidth relief doesn’t come at the expense of the customer experience…or at the customer’s expense.


Cellular offload must be simple to initiate, the quality of service on Wi-Fi must be equal to or better than that offered on cellular, and there should not be cost penalties to the user. That’s a tall order. Many a manufacturer of metropolitan mesh Wi-Fi networks that has attempted cellular offload has failed.


Why? Because metro mesh networks were designed for e-mail and Web access, and not high-density, latency-sensitive data, voice, and video applications. Mesh technology is available that can handle these types of applications, Azalea Networks being a noted example, but metro mesh vendors have so fouled the market that customer resistance is high though not insurmountable.


Cost penalties are another concern. Some carriers, ATT among them, are trying to convince subscribers to pay twice for cellular offloading – once for cellular data service and once for a home Wi-Fi access point to handle traffic that the cellular network can’t. Even if the economics did work for a consumer, this stop-gap crumbles the moment users step foot outside their homes. A system-wide solution – not an ad hoc one – is the only way to address the dilemma.


A corollary to Parkinson’s Law says that data expands to fill all available bandwidth. So while some pundits say we’ll obtain bandwidth relief from 4G cellular (most studies say otherwise), those networks will attract applications that are even more bandwidth heavy.

What we need a commuter lane to handle network overspill and ensure that essential and urgent cellular traffic has the bandwidth it needs. Wi-Fi networks can be that path, if constructed correctly and with the right building blocks, and can do so at a price that is affordable to implement on a vast scale.


So let's stop blaming the rising popularity of Web-enabled smartphones and start focusing on using Wi-Fi to solve the problem.


(1) Dataquest Insight: PC Vendors' Move Into the Smartphone Market is Not Challenge Free

(2) Dataquest Insight: Factors Driving the Worldwide Enterprise Wireless LAN Market, 2005-2013