- Adoption of standardized technologies with known vulnerabilities
- Connectivity of control systems to other networks
- Constraints on the use of existing security technologies and practices
- Insecure remote connections
- Widespread availability of technical information about control systems
These trends have moved SCADA networks from proprietary, closed networks to the arena of information technology with all its cost and performance benefits and IT security challenges. The transformation continues to be gradual and may take ten or more years to complete, as expensive legacy systems hang on. This leaves the SCADA community with a large challenge of providing the appropriate IT security for a mission critical network with systems and applications unfamiliar with the general IT environment and its inherent security risks.
New SCADA systems are emerging that have better security features, and this improvement is likely to continue as customers demand certified secure solutions. A number of efforts are underway to retrofit security onto legacy systems, but these efforts are having limited success and can be expensive. The SCADA community will need to find compensating security controls until secure systems are available and insecure legacy systems move on. Intrusion detection and security monitoring are possible compensating controls.
Evaluates Data Traveling Over
A strong information security program includes a variety of technical and administrative controls to prevent intrusions and unauthorized activities from internal and external threat agents. However, even with a set of strong security products and security policies it is impossible to ensure that a network is secure. For this reason, networks that are mission critical or contain sensitive information are deploying intrusion detection and cybersecurity monitoring systems.
Consider the physical analogy to this cyber situation. A critical building has locks on the doors, safes, and other mechanisms to prevent unauthorized access.
This same building will also deploy a set of physical monitoring systems, such as cameras and motion detectors, just in case a breach of security transpires. The monitoring systems identify breaches and enable a quick response.
A variety of product and service solutions have come on the market to create the cyber equivalent of cameras and motion detectors. These include:
Network intrusion detection sensor (NIDS) products: A device that sits on the network and evaluates data traveling over the network. A NIDS typically connects to SPAN ports on switches, so a single sensor can evaluate all or most of the traffic on a subnet. The data matches up to data related to a hacking exploit—a signature. A NIDS may have more than 1,000 signatures, and each new exploit typically requires the development of a new signature.
Host intrusion detection sensor (HIDS) products: This is software that loads on a host computer system. A HIDS system identifies attacks using signatures or behavior analysis and attempts to prevent the attack. A HIDS is generally an active defense that combines attack identification and response.
Audit log analysis products: Computer systems, applications, infrastructure equipment, and most other IT hardware and software can generate an audit log. Some of the log entries will identify successful and failed intrusion attempts. There are a variety of systems available that gather log information from various sources and present it in a useful format to a network administrator or security officer.
Managed security system provider (MSSP) services: Security incidents occur on a twenty-four-hours-a-day, seven-days-a-week (24x7) basis. An organization needs a team of security experts working around the clock to monitor, evaluate, and quickly respond to information gathered from NIDS, HIDS, audit logs, and other sources. Many companies outsource these tasks to MSSPs. In addition to the manpower, MSSPs have developed sophisticated correlation and analysis engines to process the massive amount of data received daily. As an example, MSSP engines will reduce 5 million events a day to 200 or fewer events that require human evaluation. A small number of product vendors sell correlation and analysis engines for large organizations that want to keep this function in-house.
There are a number of commercial NIDS and HIDS vendors, and the open source NIDS and HIDS solutions have earned respect and are in wide use. In general, commercial vendors offer better support and easier-to-use products, while open source solutions are more flexible and the software is available for free.
One should take care when selecting an MSSP. The industry is in transition, and a number of vendors have gone out of business or have merged with others. When selecting an MSSP consider the following:
- Formal, documented processes for analyzing and acting on an event
- Technical skill of the secure operations center (SOC) staff
- MSSP portal and other tools to look at the events in real time
- Financial stability and focus on the MSSP business
- Vendor neutral or at least support for your systems
Vertical markets associated with high-value information and networks are currently implementing these solutions. Financial service, pharmaceutical, e-commerce, and government organizations are some of the early adopters.
Monitor the Firewall Logs
In recent years, a number of SCADA systems have deployed intrusion detection and security monitoring products and services originally intended to work in a general purpose IT environment.
The NIDS sits on the control center local area network, to identify attacks against the control servers and the human-machine interface (HMI), and on the demilitarized zone (DMZ), to identify attacks against decision support servers (DSSs), Web servers, and other systems that users on the enterprise can access.
The firewalls provide perimeter security for the SCADA network, and their audit logs provide information about enterprise users attempting to access the SCADA system. Similarly, audit logs of routers, switches, and other infrastructure systems are available for monitoring.
Perhaps most importantly, the system monitors the operating system audit logs of the control servers and other key systems for security events. Some organizations also monitor Web server and database application logs.
The monitored information from all of the above logs and the NIDS transmits to an MSSP or undergoes in-house evaluation. Monitoring the network at various points allows the MSSP to better remove false positive indicators and to more accurately classify the severity of an attack. Below are a few examples to illustrate the benefits:
Enterprise attack stopped at the firewall: A firewall with a well designed rule set will stop most attackers on the enterprise network from accessing the control center. By monitoring the firewall logs, a security officer will be able to identify attempts to penetrate the firewall and can deal with the disgruntled insider. This also is an early warning mechanism. Perhaps the first attempts fail, but a persistent attacker may eventually get through. By monitoring the logs, the security officer has the ability to limit the time window for an attacker.
Enterprise attack stopped at the DMZ: An attacker on the enterprise network may attack a Web server or DSS on the DMZ. Typically, the system would record the attack on the firewall logs, the NIDS on the DMZ, and on the server log. Not only would the multiple data points confirm the attack, they could also indicate whether the attack was successful.
Buffer overflow attack on control server: A variety of systems, such as HMIs, PLCs, and other control servers, need to access control servers. An attacker can access a system or send spoofed buffer overflow messages to a control server. The NIDS will identify the attack, and the control server audit logs will often identify if the attack was successful or not. This also could be true for denial of service attacks and a variety of other attacks.
Hacking reconnaissance by a disgruntled insider: An attacker typically begins an attack by scanning the network and servers to identify vulnerabilities. The NIDS will identify these scanning attempts and stop the attacker if he or she is successful.
A best-practice deployment of the NIDS and audit log analysis that is performed 24x7 will help identify the intrusion attempts that most commonly afflict TCP/IP networks. Because most of the "script kiddies" and low to moderately skilled hackers do not develop exploits and lack knowledge of SCADA systems, these technical and administrative controls will stop the most common threat agents.
As to a HIDS, there are risks involved with adding software to a control server and with automated response. The added software issue is the same as antivirus software. Some of the HIDS software inserts itself in the TCP/IP stack and acts as an intermediary. There could be a number of performance and timing issues with this type of product. Vendors and users must certify the HIDS agent will not conflict with the SCADA application.
Automated response is a more contentious issue in the information security industry today. The NIDS and HIDS have the ability to automatically reconfigure systems if they identify an intrusion attempt. This automated and fast reaction prevents unwanted exploits. The danger with an automated response is an attacker can potentially force an intrusion detection system (IDS) to shut down key parts of the network or server. In effect, the attacker can fool the IDS into attacking itself.
The recommendation at this point is to use log analysis with 24x7 monitoring rather than a HIDS or any other type of automated action. One should certainly and carefully consider any use of an automated action before implementation.
Anti-Script-Kiddie Hackers
The primary limitation of the current intrusion detection and cybersecurity monitoring solutions is they have no knowledge or intelligence of SCADA applications and protocols. Although attacks against a Microsoft IIS Web server using the hypertext transfer protocol are well addressed, an attack on a SCADA control server using the Modbus protocol is not even considered. So the current systems are excellent against script-kiddie hackers and other novices that use exploits easily available on the Internet; they are not adequate to detect attacks by a cyberterrorist, disgruntled insider, or skilled hacker with knowledge of SCADA systems.
SCADA applications and protocol intelligence need to supplement all of the products and services mentioned earlier.
As to future solutions, consider that SCADA applications typically log a great deal of information. In fact, the system saves many of these logs to historian servers and maintains them for a variety of important business purposes such as billing, maintenance, and regulatory compliance. Most log entries are operational and reflect sensor information or actuator actions. However, there is a subset of events in the SCADA audit logs that could help identify intrusions or other unauthorized actions. Some examples of useful security information in these SCADA logs are:
- Escalation of user privilege in the SCADA application
- Changing a display (perhaps to fool an operator)
- Failed login attempts indicating a password cracking effort
- Disabling alarms to hide a physical attack—a blended threat
Transporting the SCADA logs to an MSSP or correlation engine is straightforward and available today. Control servers generally support syslog or other simple log transport protocols. This can transfer the entire log. Ideally the SCADA application, or an agent program certified by the SCADA vendor, would identify and send only security-related entries to save bandwidth and reduce the amount of data an MSSP would need to analyze.
One will need to modify the MSSP and correlation engines to understand the implications of the SCADA logs. Additionally the security staff in the SOC must understand SCADA networks and the log formats to gain the full value of this information. In summary, success will take cooperation between the vendors, users, and MSSPs. This has already occurred for the more mainstream applications such as databases and Web servers.
No Negative Impact on Network
A second type of customization required for SCADA systems is the addition of specialized signatures for the NIDS. These signatures will relate to SCADA protocols such as Modbus, Profibus, OPC, and FF. As known vulnerabilities are uncovered for a SCADA application, corresponding signatures can also develop. Note that it is naïve to expect that no one will find the vulnerabilities that exist in SCADA systems when discovery in virtually every enterprise application is already a fact. SCADA vendors could also be proactive in developing signatures that would identify the most common attacks on their particular systems.
The SCADA signature set could be an effective compensating control for a major security problem: field communications. There is virtually no security for control center to field, remote terminal unit or programmable logic controller, communications. It is simple to fool a field device to take a dangerous command. Conversely, it is possible for a cyberterrorist to access a TCP/IP-based field device to attack the SCADA control servers and take down the entire SCADA system. Because field devices have a typical lifetime of ten to twenty years, this problem will be around for a long time even if solutions embedded into SCADA systems were available today.
A SCADA signature set could identify unauthorized or unusual field communication. With the right user interface, a SCADA user could characterize expected field communications in terms of IP addresses, protocols, parameters, and frequency into NIDS signatures. The NIDS would then identify potential attacks via the SCADA field communications. With the right user interface it would be a simple matter to deploy these additional signatures. The NIDS is a passive system, so there would be no negative impact on the network or performance.
Today, SCADA users can deploy sophisticated intrusion detection and cybermonitoring products and services that will help identify attacks from the most common threat agents. This early identification will help stop the attacks before they are successful or will at least limit the damage.
In the future, SCADA-specific signature sets for NIDS systems and SCADA application log analysis will add to the existing IT systems. Ideally, this information and corresponding SCADA knowledge will integrate into the correlation engines and, in conjunction with the SOC staff, provide a true SCADA security monitoring solution.
This Is a War
Where do we put systems such as Web servers that we want everyone on the Internet to access? Not on the Internet (untrusted) because they will not be protected. Not on the internal (trusted) network because we don't want to allow everyone to go there.
So they go in a semi-trusted segment that the community calls the DMZ after the military term.
In the process control world, the process control network is trusted. The enterprise is untrusted, and a DMZ contains decision support servers and other SCADA/DCS that contain information needed by the enterprise.
We are seeing many of the Web servers related to Web-based HMI going on DMZs as well.
| About the Author |
Dale Peterson leads the SCADA Security Consulting Practice at Digital Bond, Inc. Contact Dale at [email protected].
