Recently, I read a RFP issued by a customer. The main topic focused on a perimeter security but a paragraph mentioned the protection of SCADA environments. I’ve no practical experience with SCADA and I tried to find relevant information about the deployment of security solutions in such environments. Here follows a compilation of information about this technology. This is just an introduction, I’m not a “guru”.
SCADA means “Supervisory Control And Data Acquisition“. It refers to the use of computers to monitor and control an industrial process. From a console (called HMI – “Human Machine Interface“), operators can interact with a bunch of sensors and programmable controllers. To explain shortly, it’s possible to collect information from a sensor (the “Acquisition” phase) or interact with active components (the “Control” phase). Practical examples are: to read the pressure in a pipe and to control the opening of a valve to reduce the pressure. SCADA could be compared (very rough comparison!) with SNMP: You can poll the value of SNMP OIDs from a network devices like a switch or receive traps and change the value of certain OIDs.
SCADA is used in multiple domains: industrial (example: energy production), infrastructure (distribution) or facilities (buildings, cooling or heating systems, airport luggage handling systems). By reading those examples, you immediately realize that the environments where SCADA components are deployed are really critical. Bad interpretation or unexpected behavior can have major impacts up to the highest level: risk of body injuries or even death! Can you imagine a SCADA environment controlled by hackers? That’s basically the scenario of the latest Die Hard movie. Scaring? But this is not a movie: vulnerabilities have already been discovered for SCADA products!
The different components of a SCADA infrastructure must exchange information via a communication link. In the first generations of products, this was performed over serial or modem connections. Today, the last generation uses (what a surprise!) TCP/IP networks. Ethernet is commonly used but, for longer distance (example: to manager railways infrastructure), communication are based on SONET links. Helas, TCP/IP means also more vulnerabilities. Note that a SCADA infrastructure does not rely on a unique standardized protocol. A lot of them have been developed and understood by most of the manufacturers (good examples are nice names like IEC 60870-5-101 or 104, IEC 61850 or DNP3). Old protocols are replaced by common networking protocols over IP. The “web madness” also reached the SCADA products manufacturers: more and more web interface are available to manage the components (more friendly interfaces).
What are the risks associated to a SCADA infrastructure?
- First, IP protocols are routed protocols. Packets can be routed/NATed. The SCADA components must be physically separated from any other IP network. Installing a firewall between the organization LAN and the HMI console is not enough with today’s attacks. Of course, any Internet connectivity must be prohibited.
- By introducing web interfaces, manufacturers increase the risks to introduce web vulnerabilities. Check out the OWASP Top-ten for more information about risks associated to web applications.
- DoS (“Deny of Services“) attacks. Attackers could try to interrupt communications between the components or flood a component with false-positive information.
- Common mistakes are the lack of controls and the principle of “security by obscurity”. SCADA protocols are obscure protocols but it does not mean they are not vulnerable.
- Network outages: components must be able to exchange information in real-time without any interruption.
Those issues can be classified in two main types of threats: Unauthorized accesses to a control station (HMI) or injections of rogue packets on a SCADA network.
How to protect a network carrying SCADA protocols? First, physically disconnect the network segment used by the SCADA components from the rest of your network. Still today, too many SCADA devices are directly available on the Internet. Protect against inappropriate physical access to the network. Switches must be properly secured: all unused ports must be disabled, port-security must be enabled (example: by learning the MAC addresses). Perform end-point authentication for all devices connected to the SCADA network (using VMPS, 802.1x or any other solution). If packets must cross other segments (business or technical requirements), encrypt all the traffic using a VPN or a SSL tunnel.
At host level (the HMIÂ or console), restrict physical and logical access to the console. Prevent any communication with another network. Those hosts must be dedicated to the SCADA applications and never exchange e-mail, web traffic which are common sources of malwares and viruses. Local security must be enforced using anti-virus, anti-malwares or host-based IDS. Another good practice is to work with while lists of applications. Also, automatic patching can be disabled to prevent any unexpected reboot or problem. Patches must be validated first on a test system before being installed in the producion environment during defined intervention time-windows.
Like other networks, IDS and firewalls can be deployed. Intrusion Detection System could detect suspicious or malformed SCADA packets injected on a network. On Scadapedia, there are SCADA signatures ready to be used with Snort, a well-known open source IDS project. Signatures cover the following protocols: Modbus/TCP, DNP3 and ICCP. Some firewalls solutions exists for filter SCADA protocols. Those are commercial products and often based on a Linux kernel with iptables and a bunch of specific rules. Finally don’t forget to add some visibility on top of your SCADA network:
- Monitor the components health using a monitoring tool.
- Collect information about your network. Restrict the amount of trafic to the minimum to keep the network performant.
- Monitor the network response time and availability.
Another interesting project is called the SCADA Honeynet Project. It simulates several industrial environments. The ISA (“International Society of Automation“) developed a standard (ISA99) called: Security for Industrial Automation and Control Systems: Establishing an Industrial Automation and Control Systems Security Program. It addresses manufacturing and control systems whose compromise could result in situations like: the safety of public or employee, loss of confidential information, loss of profit, impact of the national security.
To conclude, protecting a SCADA network is like any other network: the CIA-principle must be respected. But with two main differences:
- Specific “obscure” protocols not supported by the common security devices (deployed solutions must be adapted to the SCADA protocols).
- Incident can have major impacts on infrastructure outside the IT infrastructure or on people.
Pretty good overview. You allude to some of the prickly problems in SCADA-tons of legacy systems, patching will break some apps, incompatiblity with some network devices and best practices, and real-time or predictable latency issues for control systems.
This is one vertical which would be well served by high assurance operating systems for control systems.
The Digital Bond blog focuses on these issues and they do a nice job.