Security Basics: Network Intrusion Detection Systems

I am working on an updated whitepaper on the Stuxnet worm, and am asking myself how regulations like NERC-CIP and the DHS Risk-Based Performance Standards Guidance for CFATS can be strengthened to address threats like Stuxnet. One conclusion I'm reaching is that neither regulation requires much in the way of intrusion detection. Yes, they require logging of unsuccessful access attempts in a number of contexts, but this really is a poor substitute for an intrusion detection system (IDS). Ideally, an IDS tells you when an adversary has succeeded in compromising host or network protections. Defense-in-depth is predicated on alternating layers of both protection and detection, so that as an adversary works deeper into your systems, an alarm is raised. Detection raises the alarm, protection layers slow down the adversary, buying you time to shut down the attack. The advantage of detection systems over protection systems is that IDS's can be more aggressive at identifying possible attacks. When configuring an intrusion prevention system (IPS) for an industrial control system, you need to be very conservative as to your rules for shutting down attacks. You cannot afford to shut off network traffic which may be an attack, because if you are wrong, that traffic may just be essential to the correct operation of the control system. To shut off network traffic, you need to be very confident that the traffic is not needed by the control system. IDS's have no such constraint. IDS's can tolerate a small number of false positives, misidentifying allowed traffic as an attack. You do not want too many of these false alarms, because investigating each one takes time and effort. Too many false alarms and you will be tempted to ignore them all, and potentially miss the alerts indicating real attacks. That said, you still can be quite a bit more aggressive in designing rules for an intrusion detection system than you can with an intrusion prevention system, and so you can expect an IDS to detect more attacks than does an IPS. So let's look closer at what network IDS's are and how they work. We'll leave host IDS's for another day. A network IDS (NIDS) watches a stream of network traffic/packets and raises alerts when suspicious patterns are detected. This begs the first question: how does the NIDS device/software see the packets?  Grabbing the Packets As you can see in the drawing below, there are generally three ways NIDS acquire their packets: inline scanning,  taps, and  mirror ports. Inline scanning or "pass through" scanning has the packets pass through the NIDS. Nowadays, if you see an inline NIDS scanner, it is most commonly part of an advanced firewall or "unified threat manager" (UTM).  Inline scanners receive every packet on one interface, examine the packet, and forward it to its destination out another network interface. An advantage of inline scanners is that such NIDS can be extended with intrusion protection functionality. For suspicious packets, you can raise an alert and forward them. For very suspicious packets, you can raise an alert and swallow the packet, protecting the control system. A disadvantage for such scanners is that they see only the packets passing through the NIDS, not every packet on exchanged between any pair of hosts on a switch. A second disadvantage is that when most UTM's and firewalls fail, they stop passing packets at all. This restricts where you can deploy such systems, because some data streams cannot tolerate interruption as frequently as firewalls reboot or otherwise fail. Network taps address this second disadvantage. A tap is a device with at least three network interfaces - one pair of interfaces passes packets through the device, and the other interface(s) produce copies of the packets that passed through the first pair of interfaces, as an old-style "wire tap" would. The copied packets are fed into the NIDS for analysis and, if necessary, alerting. The advantage of a tap is that the electrical design is such that if the tap fails - for example the power supply fails and the tap has no power - packets continue to flow through the tap unimpeded. One disadvantage of the tap are that it is still a pass-through device, and so can see only the packets on the one wire, not on the entire switch. A second disadvantage is that because the NIDS now sees only copies of packets, it cannot prevent packets from reaching their destination, no matter how suspect those packets are. The third packet-acquisition technique is a mirror port or "SPAN" port, which is available on most modern high-end or "managed" switches. You log into the switch and instruct it to send copies of certain kinds of packets to the mirror port. The most common application is to send the mirror port a copy of all packets exchanged between any other ports on the switch. The advantage of a mirror ports is that the NIDS now sees all packets exchanged between all hosts on the switch, not just the packets on one wire. A disadvantage, again, is that the NIDS is not able to do any prevention, just detection. A second disadvantage is data volumes -- a single output port on the switch is rarely able to transmit to the NIDS all of the data the switch backplane can exchange. This can lead to some packet loss, especially when large bursts of data are processed by the switch. In practice, the loss of some packets does not substantially impair the value of a NIDS. The purpose of a NIDS is to detect attacks and raise alerts so that incident response teams can react to the attack. Few attacks consist of very small numbers of packets - most involve steps like reconnaisance, attack, compromise, downloading a rootkit, etc.. Many packets are exchanged in the course of a typical attack and even if a fraction of these packets are lost, the IDS has done its job if it raises an alert for any part of the attack. Since attackers cannot know which packets will be lost to the NIDS, they are generally unable to tailor their attacks to ensure that the NIDS will see no part of the attack.  Signature-Based NIDS The majority of NIDS products on the market are rule or signature-based. A signature-based NIDS has rules describing "bad" packets or sequences of packets. A signature-based NIDS evaluates every packet it receives against these rules and raises alerts when a rule is matched. An advantage of signature-based NIDS is that with careful rule design, you can be quite confident that a rule match means an attack is in progress, and you can be quite confident as to exactly which kind of attack is in progress. In practice though, rules are not designed that carefully and you do need to be disciplined about "calibrating" the NIDS. That is, you need to investigate the many false positives that arise after an NIDS is initially deployed and turn off or adjust rules which generate unacceptable numbers of false positives. The real disadvantage of rules-based NIDS is that such systems are unable to detect new kinds of attacks until those attacks become understood well enough to define rules for the attacks. NIDS vendors generally maintain large farms of honeypots and examine those honeypots automatically for evidence of compromise. These vendors do not produce signatures for every threat - there are too many different threats, and most occur too rarely to be worth the investment of signature development. Once a particular piece of malware has compromised a critical number of honeypots, generally somewhere between 500 and 5000 honeypots, the NIDS vendor does the work of creating and distributing a signature for the threat / attack pattern. This means that new attacks have no signatures until those attacks reach a certain volume, and it means that the most sophisticated attacks - custom, targeted attacks that are seen on only a handful of computers and then never used again - are not detectable at all by signature-based NIDS.  Anomaly NIDS A minority of NIDS vendors include an "anomaly detection" capability. Anomaly systems, one way or another, "learn" what is normal on a network or on a connection, and raise alerts if anything outside of "normal" is seen. State of the practice anomaly detection engines can be very complex, using sophisticated mathematical models to predict network traffic patterns and to raise alerts when traffic is seen which does not agree with those patterns. The advantage of anomaly NIDS is that these systems are able to detect more kinds of attacks than signature-based systems, even brand new kinds of attacks, or targeted attacks. The NIDS is not able to tell you what kind of malware is attacking you, but they do know something different is going on and can alert you to that "something different." A disadvantage of anomaly NIDS is that the mathematical models are generally so complex they are difficult to adjust manually. As a result, these anomaly NIDS need a "learning" phase, which can be continuous learning, or it can be only periodically. If an attack is in progress while the system is learning, the system will conclude that the attack pattern is "normal" and is not worthy of raising an alert. "Slow early, faster later" attacks can often get by these learning systems, because the volume of attack packets is not high enough to create an alert initially, and the slow, steady increase in attack packet volume is not caught by the continuous learning system.  Other Benefits I don't know how many times I have heard "I don't need IDS if I have IPS." Yes, intrusion prevention, especially at the network perimeter, is the first technology you invest in when starting down the road toward defense-in-depth. But soon after you have a layer or two of IPS deployed, you need to start thinking about IDS. Intrusion detection systems detect more attacks than intrusion prevention systems do, and you need that detection capability so your incident response teams can shut down attacks in progress before they make it through all of your layers of IPS. There is a second benefit to deploying an IDS though - in the course of tuning an IDS to eliminate false positive alerts, you generally learn a great deal about communications on your control networks. As a rule, you never deploy an IDS of any sort without finding something. Customers are regularly surprised at what they find running on their networks, and generally take steps to shut down unauthorized applications and users once they see what is really happening on those networks.