Sunday, April 8, 2012

SCADA security’s most daunting challenges along with some recommendations

Six Ways to Improve SCADA Security 

Industrial control systems (ICS), distributed control systems (DCS), supervisory control and data acquisition systems (SCADA) have all been around for decades, but thanks to Stuxnet, DuQu and other major incidents, these systems have recently began receiving serious security consideration. When it comes to securing SCADA networks, we are years or even decades behind when compared to securing typical IT networks. 

1. A SCADA network is inadvertently connected to a company’s IT network or even to the internet 

Companies believe that their SCADA networks are air-gapped or separated from other networks in their organizations. In some cases, business needs require data from SCADA systems (like electric outage information, etc.) to be exposed on the internet. And during this implementation, the secure network diagram on paper starts deviating to the insecure configurations of the real world. 

A search for ‘data presentation and control’ software on the internet yields SCADA systems with management services exposed to the internet. If an organization's SCADA network is not securely connected with the IT network, worms can jump from the HR desktops or reception kiosk into the SCADA network. 

Recommendation: Based on available resources, use a mapping tool or professional service (who will use some tools on your behalf) to investigate your SCADA network connectivity and deviations from the securenetwork diagram on paper. 

Caution: Not all tools are created equal and a blind scan of your network could knock down SCADA components like PLCs, RTUs and IEDs. Thus, it is important to ask your tool vendors if the tool has ever beenused in SCADA environment and if a SCADA configuration is available.

2. ‘Data presentation and control’ now runs off-the-shelf software

Long gone are the days when control systems ran on proprietary or custom platforms. Most SCADA systems today use off-the-shelf operating systems, standard browsers and other technologies which are used in desktop environments. Hackers can easily create exploits that target the underlying software vulnerabilities to infect and propagate their worms.

Recommendation: Use your IT experience to deal with IT problems. Scan for vulnerabilities in your IT and SCADA networks and patch them as soon as possible. Our research has shown that patching is the most simple yet effective solution. In some cases patches cannot be applied, and I will discuss that issue in the next section. 

There are various technical security benchmarks (like CIS) and compliance standards available for off-the-shelf systems like Windows, Solaris, Oracle, Apache and others. Use a policy compliance system to make sure that off-the-shelf systems are configured securely. Anti-virus, IDS, firewalls and other well-known IT solutions will also be helpful.

3. Control systems not patched

In many SCADA systems, the underlying OS or applications have not patched for years. It’s not fair to blame SCADA system administrators in all instances because there is little guidance from SCADA vendors regarding whether or not an OS patch is safe for SCADA software. 

For example, Microsoft releases patches every month. Without any guidance from SCADA vendors on the compatibility of the patch with their SCADA software, SCADA system administrators will not apply the patch. In some cases the underlying OS is a modified version of the standard OS. Some vendors may quickly translate and re-release the OS patches from Microsoft for their modified OS, while other vendors may not be as quick to release the patch.

Recommendation: Demand your SCADA vendor to provide guidance on patching Microsoft, Adobe, Oracle, etc., for all software used in the setup. If acustomized version of the standard OS is used, then demand quick release of customized patches. If possible, invest in a lab where you can test for patch compatibility yourself. Use a vulnerability management system to identify missing patches.

4. Authentication and authorization

In many instances ‘data presentation and control’ software is not capable of basic authentication and authorization. Even if the software is capable weak configuration, shared or default passwords render these features useless. If a worm gets on the machine it can easily manipulate a SCADA environment provided that it knows how to communicate with the SCADA control software via default password or nopassword set.

Recommendiation: Configure SCADA control software to use per user authentication, authorization and logging controls. In addition to strong passwords, use a smart token based authentication scheme. 

5. Insecure ‘datacommunication’ protocols

Decades ago, SCADA protocols were not designed with security in mind as networks were air-gapped and this thing called as Internet did not exist. However, 20 to 30 year-old protocols like Modbus and DNP3 still exist and thrive in SCADA networks.Manipulating PLCs running on such protocols is trivial, and upgrading to newerprotocols (like secure DNP3) often requires you to replace components, which can be costly.

Recommendation: If your system is already using newer protocols with key management and secure communication, make sure they are configured to use these newer features. Investigate your upgrade options and the costs associated with them. If upgrades are not possible, determine whether there is a way to tunnel the communication through secure channel.

6. Long life span of SCADA systems

Finally, the achillesheel of SCADA systems is their long lifespan, which is often measured in decades. These systems are built to last, and unlike PCs, which are easy to replace, it’s difficult and costly to replace even part of a SCADA infrastructure. 

Recommendation: There is no easy fix for this. While designing new systems or expanding existing systems, consider the long life cycle and architect your infrastructure accordingly so that components are easily upgradable or replaceable.

No comments: