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. In this blog, I will present some of the SCADA security’s most daunting challenges along with some recommendations to secure SCADA networks. If you are new to SCADA, I recommend reading my 'SCADA Fundamentals' post, which was published earlier this week.

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.

If you are SCADA system owner or administrator, I would appreciate if you could email me your feedback on this blog post along with your experience managing them.

Introduction

Supervisory Control and Data Acquisition (SCADA) systems are used for remote monitoring and control in the delivery of essential services products such as electricity, natural gas, water, waste treatment and transportation. This blog will introduce SCADA fundamentals that will help analyze security considerations in the subsequent blog post.

I am using the terms SCADA, ICS and DCS interchangeably here. SCADA is much more than a particular technology. SCADA solutions come in many different forms, but they’re all built on the same principle – providing you with mission-critical data and control capabilities that you must have to effectively manage your operation. Usually a SCADA system is a common process automation system which is used to gather data from sensors and instruments located at remote sites and to transmit and display this data at a central site for either control or monitoring purposes. The collected data is usually viewed on one or more SCADA host computers located at the central or master site. A SCADA system can monitor and control thousands of I/O points.

Electric utilities use SCADA systems to detect current flow and line voltage, to monitor the operation of circuit breakers and to take sections of the power grid online or offline. A typical water SCADA application would be used to monitor water levels at various water sources like reservoirs and tanks. When the water level exceeds a preset threshold, the application activates the system of pumps to move water to tanks with low tank levels. Transit authorities use SCADA to regulate electricity to subways, trams and trolleys and to automate traffic signals for rail systems, to track and locate trains and to control railroad crossing gates.

SCADA components, functions and relationships

Not all SCADA systems are the same, but studying them from a security point of view, they can be broken down into the following components that are present in every system in one form or another:

– Data Acquisition

– Data Conversion

– Data Communication

– Data Presentation and Control

Each component has a well-defined function or purpose. Furthermore, each component has a specific relationship with the components that it communicates with. SCADA systems can be broken down into following major components, which form a chain. Each component communicates with the component before and after itself.

Data acquisition

The first component in the chain is data acquisition. It is not preceded by another component, but it connects to the data conversion component. Data acquisition consists of sensors, meters and field devices, such as photo sensors, pressure sensors, temperature sensors and flow sensors. Depending on the type of SCADA system these devices could be physically located hundreds of miles away from each other or could be inside the same plant. The primary function of these field devices is to sense physical parameters like light, temperature, pressure, etc., in the form of analog signals. In most cases the data which is acquired is analog. Data acquisition is also known as input output or I/O.

Data conversion

Data conversion receives data generated by the acquisition component. Remote terminal unit (RTU), intelligent electronic devices (IEDs) and in some cases programmable logic controllers (PLC) are example devices that fall under this category. The functionality of these components has evolved over the years to include analog to digital conversion, sequential relay control, process control and now even networking. An RTU monitors the field digital and/or analog parameters and transmits it to the central data control via the data communication component. Early PLCs were designed to replace relay logic systems and were programmed in ladder logic. Modern PLCs can even be compared to desktop PCs in regards to their power and functionality.

Data conversion has a two way communication with data presentation and control via the data communication component.

Data Communication

Data communication consists of some communication medium that transfers data back and forth between data conversion and data control. The communication medium could be wired, wireless, radio, satellite or others. The communication takes place using one of the many SCADA protocols. Some protocols are open standard while some are proprietary. Some example protocols are ModBus, DNP3, ControlNet, ProfiBus, ICCP, OCP, BBC 7200, Gedac 7020, DeviceNet , Tejas, UCA and others. It is estimated that that there are over 100 such protocols.

Data presentation and control

As the name suggests data presentation and control consists of devices used to monitor and control data received from various data communication channels. It may include Human Machine Interface (HMI), which the operator uses to monitor and react to alerts and alarms. It may consist of historian databases and other support systems.

I hope this was a useful introduction to SCADA systems. Another blog post on SCADA security considerations will be published later this week.