This post is a departure from previous editions. It is inspired by discussions I’ve had recently with a few different online and in-person communities. I will present my view on the topic, but I’m more interested in hearing what readers think!
I’ve had a few conversations during the past month regarding so-called intrusion prevention systems, or IPS. I’m not saying “so-called” to be snarky, but to comment on an odd aspect of the security scene. Looking from the outside, one might think that an IPS could be any process, application, or service (PAS?) that seeks to prevent intrusions. However, IPS has a fairly discrete definition rooted in network-based technologies that in turn are derived from another term, “intrusion detection system,” or IDS.
Again looking from the outside of the security fishbowl (or zoo?), one might think an IDS is any PAS that seeks to detect intrusions. Indeed, if we return to the computer science research of the 1970s, “intrusion detection” was a field in which many methods were considered when trying to identify malicious actors. Prior to the widespread interconnection of computers, intrusion detection was a host-centric affair.
Starting in the late 1980s, and gaining momentum in the late 1990s, intrusion detection became increasingly associated with inspecting network activity. Todd Heberlein worked at the University of California at Davis from 1988 through 1995 on the Network Security Monitor (NSM). Vern Paxson introduced Bro (now called Zeek) in 1995 at the Lawrence Berkeley National Laboratory. In 1997 Marcus Ranum created his Network Flight Recorder (NFR). In 1998, Marty Roesch started Snort development, and Robert Graham introduced a suite of products based on his BlackICE code. A year later Ron Gula and his Network Security Wizards were developing the Dragon IDS.
As a result, the term “IDS” became associated with an application that inspects network traffic and compares it to a signature set. This was not the only approach taken (as demonstrated by Heberlein’s NSM, Paxson’s Bro, and early implementations of Ranum’s NFR), but soon IDS became a term linked to signatures and inspecting byte sequences in packets, or later, flows.
Once customers began asking if their IDS could do more than identify malicious byte sequences, the IPS market was born. The question at the time was “if you can detect it, why can’t you prevent it?” As we know the topic is far more complicated than that, but a new generation of products entered the market in the 2000s, promoting their ability to not only detect network activity, but also block it.
My experience at the AFCERT starting in 1998 convinced me that an alert-centric approach such as that offered by IDS products was necessary, but not sufficient. Therefore I gravitated towards the NSM operational model, which relied on transaction logs (like those found in Zeek and Corelight), full packet capture, and, yes, IDS alerts. However, I always considered IPS to be an entirely different beast.
In my view, NSM is about visibility, and IPS, like a network firewall, is about control. NSM sits off a network tap or SPAN port to passively observe traffic. IPS sits inline and makes pass or block decisions based on its signature set. I never considered IPS to be a product, per se, but a feature that would eventually be integrated into the king of all network control products, the firewall.
This is to some extent what has happened in the marketplace. This is where I ask my readership a question: does anyone deploy new, stand-alone IPS anymore, with the explicit intention of blocking traffic? Or do you expect your firewall vendor to provide that functionality? I know of many, many legacy IPS implementations that operate in essentially “IDS mode,” whereby traffic is inspected but never, or perhaps rarely, blocked.
Please let me know on Twitter or via comments what you think.
