William T. (Tim) Shaw
PhD, CISSP / CIEH / CPT

In previous columns, we’ve talked about all of the things you can use to guard the primary entryways to your computer-based automation systems and critical digital assets. If you create a DMZ between your plant automation network and your corporate network, and use it to isolate the two, you make it hard for an attacker to get into your plant systems from that direction. Most corporate IT departments will have already done a reasonable job of using a DMZ, and some great honking-big enterprise firewall, to insulate the corporate network from the actual Internet. So, an attacker coming across the Internet has two major barriers to traverse and, even if they compromise a computer on the corporate network (which happens all too often due to unprotected web surfing and unsafe email practices), they still have another DMZ blocking their access.

This is not to say that this final barrier can’t eventually be overcome – never underestimate the innovative talent and downright sneakiness of your adversaries – but it will slow them down and maybe give you a chance to respond before they are able to cause any damage. Both the ISA (the SP.99 committee) and NIST (in their 800-82 special publication) highly recommend this approach, and I agree with them. A DMZ between plant site/ECC automation systems and the corporate WAN can also help to control and manage ‘authorized’ remote access to critical systems and data flows going ‘up’ to corporate business applications.

Of course, if you are casual in your use of wireless technologies in your plants, or if you allow vendors and/or your own personnel to have remote dial-in connectivity to critical systems and/or networks, then all bets are off. However, one would hope that those issues would be addressed and appropriate action taken to eliminate those attack pathways as part of a comprehensive cyber security program. I personally have never been convinced that wireless networking – which, as I’ve pointed out in previous columns, is different from wireless instrumentation technology – should ever be allowed near a critical automation system, let alone connected to one. Having said that, many plants are investing heavily in wireless networking infrastructure for its convenience and to reduce wiring costs.

To my way of thinking, this is dangerous if it provides access to critical systems (including security systems), but if you must go down that path then, in addition to having IEEE 802.11i encryption and authentication implemented on all your wireless devices and access points, having some means in place to monitor for malicious and unauthorized wireless traffic is essential.

We have, in the past, bemoaned the problem of orphaned automation systems; those SCADA and DCS (and even PLC-based) systems still essential to operations, but which are no longer supported by the vendor – often because the vendor no longer exists.Those systems, if they are less than 10 or even 15 years old, probably have an underlying platform that is modern enough to include TCP/IP-Ethernet networking and a MS-Windows or Unix-like operating system. That means that they are susceptible to current cyber attack methods and techniques as well as being vulnerable to a lot of the malware circulating through the cyber environment. Since no one would likely risk causing a problem by making anything but essential functional changes to such systems, it is unlikely that any security-related patches, if any exist, would be (or are being) installed. For such systems the best protection alternative is to isolate them with an “air gap” – and no, wireless connectivity is NOT an air gap! But if you can’t do that then you need to insulate them using firewalls and closely monitor all communications traffic directed at, and coming from, those systems. But of course neither of those strategies will protect against SneakerNet and supply chain threats.

So, to the point I made in my opening comments: what can be done about threats and attacks that make use of the manual delivery of malware via portable media and devices (a.k.a. SneakerNet) and malware buried in the bowels of software and systems you purchase? [And by ‘malware’ I mean anything from a secret ‘backdoor’ user account and password to a virus or worm that spread to other systems and wreak havoc.] Obviously you can try to have procedures and policies to prevent SneakerNet attacks. You can sheep-dip (meaning thoroughly erase) all the USB “thumb drives” and virus scan all the laptop PCs, but that is a rather daunting task, especially given the range of digital devices we all use these days.

Everything from laptop PCs and tablets to smart phones and digital cameras can be used to transport and deliver malware. For example, there are viruses that spread from cell phones to laptop PCs via Bluetooth wireless communications, and there have been documented cases of network-connected printers being supplied with driver software that included a secret backdoor (Trojan) virus. You probably can’t realistically perform scans on everything that could potentially be used as a transport medium; however, you ought to give it a good try! Moreover, if there actually is secret code hidden in any major application program, just waiting to be activated, we don’t yet have the proven ability to determine that fact and find the offensive code. And what about that trusted insider that has reached his/her limit and decides this is the day to “go postal”? What can you actually do to protect your critical computer-based systems in those cases?

One of the more powerful IT cyber security technologies available to protect your cyber assets is the intrusion detection and prevention system – or “IDS/IPS” – which is sometimes combined as “IDPS”. An intrusion detection system [IDS] watches for unusual, abnormal and obviously-malicious activities that are happening within a computer and/or on the networks that interconnect computers. Properly configured and applied IDS systems can detect the fact that a program has been infected with a virus or that a worm is trying to pass a copy of itself over a network. Likewise, an IDS can identify, and even block, a wide range of network-based probes and attacks.

If you have purchased software that turns out to have a built-in ‘time-bomb’ (that is, code that is dormant until, for example, a pre-designated time/date is reached), the activation of the hidden functions will usually cause the program to act in an anomalous manner, which will alert the IDS. For example, a savvy operator might ask: “Why is that spreadsheet suddenly trying to communicate with a computer in China?”

If malware is delivered on a portable device, the act of trying to install and execute it on the target computer can be identified and possibly blocked by an IDS, but before I make IDS technologies sound like the ‘Holy Grail’ of defenses, let’s cover some basic facts about their strong and weak points…

Intrusion detection technology falls into two broad categories, with both types complimenting the capabilities of the other. The first type of detection technology is called “host based” intrusion detection or “HIDS”. This technology involves installing special software (called an ‘agent’) onto the target system(s) and letting that software use some of the processing power and other resources in order to monitor the actions of application programs and users. HIDS technology is not available for all computer platforms; basically it’s for MS-Windows and Linux variations. It actually buries itself into the operating system using the same technique as a “root kit”, which is a very, very dangerous form of malware. In that mode, the HIDS can control access to the file system, network connectivity and the ability of a program to run (a capability called “whitelisting”). As part of their installation it is typical for a HIDS to compute and securely store a ‘hash code’ value for every file, so that it can spot any unauthorized or clandestine modifications and additions, such as being infected with a virus.

It is also typical for a HIDS to gather operating statistics on applications so that it can spot anything new and different about how a program behaves. On the negative side, if you are already infected when you install a HIDS, it will consider the infection, and how infected programs are acting, as its “normal”. Also, though in most cases the resource utilization caused by the presence of the HIDS ‘agent’ is negligible, there may be instances where it could unacceptably impact real-time behavior and system responsiveness.

The second type of intrusion detection technology is called “network based” intrusion detection or “NIDS”. This technology is not intrusive and does not require the modification of any system or the installation of special software on the computers being protected.For that reason it is applicable to orphaned systems and really to any systems or devices that communicate using TCP/IP-Ethernet networking. A NIDS is generally one or more separate computers that connect to a LAN and watch all message traffic between and among the systems/devices on the LAN. Going back to the beginning of this article, when a DMZ is created to isolate corporate networks from plant networks, it is a good idea to have a NIDS situated on the “plant side” of the DMZ so that all traffic ‘up’ and ‘down’ can be examined.

In fact, it’s a good idea to place the NIDS in series and have it block malicious message traffic. Incidentally, in that case it’s considered to be an intrusion prevention system (IDPS), not just a detection system.

Likewise, within a plant site, if there are further internal network segments that connect critical systems, it is recommended to have a NIDS watching that traffic as well. A host-based intrusion detection system has capabilities not found in a NIDS, but since a NIDS is essentially invisible to the systems and devices whose message traffic it monitors, it is possible to use a NIDS in pretty much any situation. Modern LANs are built with Ethernet switches, and usually it is possible to set up a ‘mirror’ or SPAN port on a top-tier switch where a NIDS can be attached and receive a copy of all of the traffic. NIDS can detect a wide range of attacks and malware, and some can even be configured with customized rule sets that allow industrial protocol message traffic (e.g., the IP versions of Modbus or DNP3.0) to be monitored. NIDS that support user-defined rules that use the BPF (Berkley Packet Filter) syntax can examine such message traffic to see what commands are being issued, and register addresses that are being read/written.

Network intrusion detection can also be applied to monitoring wireless networks. By placing an NIDS at the access point(s) where wireless users are routed onto a wired LAN, the traffic can be monitored for malicious content. Some access point manufacturers actually include a basic NIDS support capability in their products. You can also use dedicated wireless access points, connected to the NIDS as sensors to monitor wireless activity.

The nice folks at NIST have written a very informative report (see Special Publication No. 800-94) that discusses the different types of intrusion detection – and intrusion prevention – technologies and how they work. It is well written, and provides many insights into IDS/IPS usage and capabilities. Using this technology with wireless LANs is a bit more complicated, but the NIST document does an admirable job of explaining the issues.

You might want to think about a HIDS, NIDS and/or IDPS system as a burglar alarm system for your networks and critical systems. Its job is to watch for known threats, suspicious behavior and actual attacks. Part of the ability of this technology to detect malware is based on having up-to-date “signatures” just like your regular virus scanning tools. An IDS (or IDPS) system must be kept updated as new threats and attack methods are identified. The sophisticated systems monitor for anomalies in user behavior and also look back over operational history and log files to see if new patterns of user or system behavior are occurring. Some vendors have developed quite advanced analysis modules to try to detect aberrant behavior in its earliest phases (i.e., when a threat agent is poking at your defenses performing reconnaissance) in order to provide enough warning to forestall a successful attack.

However, just like a burglar alarm, it does no good if the IDS sounds the alert – by sending a message – but no one is listening. One of the burdens of using this technology is the need to have knowledgeable personnel routinely review alerts and alarms generated by the IDS to see if they are ‘false positives’ or actual threat indications that should initiate a protective/defensive response. Just as with a physical security alarm system, an IDS is liable to generate occasional false alarms.

There are a number of vendors and products on the market that provide NIDS/HIDS capabilities. They can look over your organizational infrastructure and make suggestions about how best to apply their products. If your IT organization has the internal expertise you can put one together yourself, often at a surprisingly low cost. One of the best network-based intrusion detection packages available today is an open source tool called SNORT –yes, like the noise a pig makes, and it even uses a stylized pig in the logo!). Using a standard high-end PC loaded with one of the secure LINUX operating system distributions such as SE Linux – Security Enhanced and SNORT you can create a powerful and flexible NIDS; plus, the SNORT user community offers a lot of free or low-cost support and a constant flow of rule updates that address new threats.

If you want to create your own HIDs you don’t have the same level of open source options. There are some open source packages that provide some of the functionality I have discussed, such as ‘Tripwire’ for monitoring for file modifications. There are also vendors that are focusing on developing HIDS ‘agent’ software for selected industrial control systems. Because of its powerful detection and prevention capabilities HIDS technology is more complicated in many ways, and has more integration issues, than does NIDS, but that will be the subject matter for a future column... Tim.

About the Author

Dr. Shaw is a Certified Information Systems Security Professional (CISSP), a Certified Ethical Hacker (C|EH), a Certified Penetration Tester (CPT) and has been active in industrial automation for more than 35 years. He is the author of Computer Control of BATCH Processes and CYBERSECURITY for SCADA Systems. Shaw is a prolific writer of papers and articles on a wide range of technical topics, has also contributed to several other books and teaches several courses for the ISA. He is currently Principal & Senior Consultant for Cyber SECurity Consulting, a consultancy practice focused on industrial automation security and technologies. Inquiries, comments or questions regarding the contents of this column and/or other security-related topics can be emailed to tim@electricenergyonline.com.