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.
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.