February 2015, Vol. 242, No. 2
Features
RTU And Process Security From The Ground Up
Recent news regarding SCADA system intrusions has highlighted the security differences between network and s. SCADA system operators must assess vulnerabilities and implement security measures at both levels.
The two-tiered, network/local-level model focuses on the technology that is typically applied and is significantly simplified when compared with those used by such industry standards as ISA/IEC 62443.
The network level in a SCADA system includes personal computers, personal computer software and common networks such as Ethernet. In ISA/IEC 62443 terminology, it includes the enterprise zone and control center zone. This level shares many similarities across a broad range of industries and often falls under the responsibility of the IT department. Given such extensive industry expertise, it receives the bulk of the attention when it comes to security.
The local level refers to the field sites. It could also be called the remote level. It includes remote terminal units (RTUs), and the processes they monitor and control at this level are specific to the industry and application. Electrical transmission system substations, gas pipeline metering stations and wastewater treatment system lift stations exemplify this level.
ISA/IEC 62443 classifies installations at the local level as control zones. It is conceivable that one control zone can have much different characteristics from another. For example, one location could be classified as more vulnerable or have higher risks than another.
The expertise needed to address this level is shared by end-user engineers, systems integrators, and the R&D teams among manufacturers of controllers, instrumentation, RTUs and software. Third-party SCADA security experts are also available. There is no shortage of industry standards that end users and providers can use to guide their vulnerability assessments and security implementations.
One problem is that many of the systems these people deal with did not originally include security as a design requirement. Now, they are retrofitting cybersecurity measures into technology, which could be generations old. Engineering hours pile up as they add or update hardware, code and test applications software and firmware.
Another problem is that the hacker community has taken an interest in SCADA systems. Highly sophisticated threats have emerged. It’s no longer just a matter of a disgruntled former contractor dialing in to an RTU and starting a pump. Since recent incidents have been specific to particular SCADA products, specialty expertise is necessary to detect and prevent future threats.
While it’s argued that industry standards do categorically address the new threats, engineers are certainly refining vulnerability assessments by including new scenarios. The scenarios require new implementation measures.
The technology to secure SCADA systems exists today. A key reason that SCADA systems are being targeted is that many of the systems now in operation remain vulnerable. Operators simply haven’t yet implemented all their security measures.
That leaves them open to numerous threats. Third parties can access networks and steal proprietary information about operations. They can corrupt data bases. They can disrupt operations by launching denial-of-service attacks that prevent communication with RTUs. They can gain remote access to RTUs and operate process equipment such as compressors and pumps. Process equipment can be operated in a manner that causes damage, creates safety risks, disrupts the process, increases power use or reduces service life.
Malicious code or entire applications can be downloaded in order to do these things undetected. The RTU provides falsified information to operators in order to make it look like everything is normal.
Today’s RTUs include numerous connections to Ethernet, serial devices, SD cards, USB devices and wireless networks. Each connection presents a security risk.
Ground-Up Implementation Measures
Operators must consider measures in terms of monitoring for intrusions as well as prevention. Often overlooked, the monitoring aspect could provide valuable information about an impending threat. Attempts by third parties to test a system’s vulnerability can be detected before they are able to gain access or launch a denial-of-service attack.
It is also very important to remember that ground-up measures at the must be done in conjunction with “top-down” measures at the network level. Network-level measures include authentication, encryption, firewalls, virtual private networks, anti-virus, and anti-malware.
Addressing Threats: Prevention
Ten years ago, the major threat at the local level was that it was simply too easy to access an RTU locally via a serial port or, even worse, remotely via a dial-up, cellular or radio network.
The increased connectivity featured by today’s RTUs increases their vulnerabilities even further. This fact shows how vulnerability scenarios must adapt to the times. Today’s RTUs can connect wirelessly to the Internet – if allowed by the system design – and have multiple connections for Ethernets, SD cards and USB devices.
Protecting the RTU at all connections prevents downloading of malicious code up to and including the entire application or project. For hard connections to the RTU – plugging-in a cable, USB stick or SD card – physical security remains the key measure. That, at least, keeps access to the RTU or site restricted to authorized personnel.
Authentication is the next level. Ideally, the RTU will force an authentication process on any device that connects to it. The reality, unfortunately, is that most RTUs lack this ability, at least for USB and SD devices. Implementing it as a firmware update could be difficult if not impossible.
That leaves it to operating procedures. Plug-in devices must always be scanned and cleared when loaded at the source device such as a PC, then transported to the local level without being plugged in to anything else.
That puts a major security burden on the source PC. Normally a network-level device, this PC is classified as the engineering workstation and requires specific security functions. They ensure that applications, which could be distributed throughout the entire SCADA system, are not infected. This installation justifies the strongest firewall, anti-virus and anti-malware on the market, backed up by extremely strict operating procedures for all connections.
The good news is that authentication is available in RTUs for other connections including local PCs via serial ports and SCADA networks over hardwired or wireless interfaces. Examples of authentication include DNP3 Secure Authentication for those networks using the DNP3 protocol and IEEE 802.1x, which uses a radius server for authentication.
Authentication ensures that messages arriving at the RTU come from the control center or other legitimate assets in the SCADA system. Note that authentication doesn’t provide data security. Eavesdroppers can still monitor network traffic and gain access to proprietary information. Data security is provided at the network level through encryption such as that provided by a virtual private network (VPN).
Addressing Threats: Monitoring And Detection
At a minimum, the RTU must be able to log all activity on local or modem ports and report it to operators on the SCADA network.
The Simple Network Management Protocol (SNMP) has emerged as a vehicle for security monitoring in SCADA networks. Traditionally used by IT to monitor components such as routers, servers and switches, SNMP is being employed to monitor remote sites. For example, such parameters as main power status, battery voltage, cabinet temperature, and door switch status can be reported via SNMP.
Similarly, SNMP can report activity on RTU ports. That information can be used for detection of an intrusion as well as an impending denial-of-service attempt. SNMP operates over TCP/IP links and can function concurrently with other SCADA protocols. While DNP3 or IEC60870-5 protocols are used to transfer process or operational information between the SCADA server and the RTUs, SNMP is used over the same physical network in a background mode, transferring “shadow data” for system health monitoring and security.
Using SNMP, the RTU operates in conjunction with a security monitoring system such as Industrial Defender’s risk mitigation platform. Other monitoring and detection measures take advantage of the alarm management and data logging capabilities that are inherent in most RTUs.
The RTU should detect entry into the physical secure zone at the local level via an access control device, that is, when a door or gate is opened and alert operators via an alarm. The RTU must be able to report that a user has plugged a portable device or PC into the local port – or gained access via a wireless link.
The RTU should log an event when the user signs on by entering a password and log an event for each value change the user makes. Operators must be aware that value changes are being made locally. The RTU should log an event when the user signs off and either log an event or clear/reset the alarm when the user unplugs the portable device or PC.
The RTU should not only report alarms over the SCADA network on a priority basis, it should also keep a date-and-time-stamped record of all alarms and events locally in non-volatile memory. Many of today’s RTU products incorporate data logging capability, including maintenance of an alarm/event log. In the gas flow computer market, this is known as the “audit trail.”
Further monitoring and detection measures are accomplished through applications programming. This is where the engineering hours could accumulate but measures are more than worthwhile. Many of these techniques come from process safety practices. Alarms are logged or lockout code is executed when process equipment is commanded to operate in an abnormal or unsafe manner.
Sanity monitoring tests for process mismatches; for example, a pipeline compressor operating when the line pressure is above a high limit. Any such process operation should include multiple high and low level limits. Those limits would be linked to alarms and lockout logic. Other examples include combinations of pumps and valves and limits on motor run times.
Conclusion
Secure SCADA systems require a combination of top-down, network-level measures and ground-up measures at the .
The network-level measures share much in common with computer and network systems across a broad array of industries. Well-practiced security measures are available. Often, the security responsibility at this level falls within the realm of the IT department.
The local-level measures are specific to the RTUs and processes they monitor and control. They require the expertise of process engineers, systems integrators and equipment manufacturers. SCADA security specialists also comprise a small but growing discipline.
Threats at the include denial-of-service attacks, which prevent communication with an RTU, disruption of process operations through downloading of operating parameters and disruption of potentially all local-level operations through downloading of malicious code, which could include the entire RTU application.
Local-level measures including physical security, authentication and rock-solid operating procedures are supplemented by such specific measures as those implemented in the RTU firmware and application software.
Author:
Kevin L. Finnan is a consultant in the oil and gas and process industries. He was previously Vice President of Marketing for CSE-Semaphore, a manufacturer of Internet-enabled automation, SCADA and telemetry products, and Director of Marketing at Bristol Babcock. He has 30 years of experience with oil and gas measurement, process automation and SCADA systems. He has been active as an author and presenter for numerous industry organizations including ISA, Entelec and industry “short courses.”
Comments