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 Peterson@digitalbond.com.