I'm looking to move from our current intrusion-detection system (IDS) to an intrusion-prevention system (IPS). I've been contemplating this for a while but have hesitated because once my department places a device inline with other network gear, we become another bump in the wire and have certain responsibilities in regards to network availability.
As many of you know, an IDS typically sits on a monitoring port, sometimes called a SPAN port (in the Cisco world), and is passive by nature. The IDS device sits in promiscuous mode and listens to the network traffic passing by, and when something abnormal occurs, it sends alerts on the suspicious activity as defined by configured rules.
Take that same IDS sensor and place it inline so that all network traffic must pass through it, and you have an IPS. So basically, an IPS is nothing more than an IDS that has some additional functionality and is positioned in a different place on the network. The rules, signatures, alerts and reporting are typically all the same. Even Snort, the freely available IDS, has its own term, "Snort inline," for what is essentially intrusion prevention.
My reasoning for moving to IPS is pretty straightforward. Only a couple of people report to me, and they are bogged down with projects and daily security activities. I'd like to have a full-time person to monitor the IDS and respond to events, but I can't afford that. Meanwhile, we continue to respond to worms and other suspicious activity after the fact, either placing rules in the firewall or visiting all the affected desktops. And we can't count on our antivirus infrastructure either.
One recent worm, W32/PrsKey-A, ran rampant in our network for several days before our antivirus vendor finally produced a signature, and that happened only after we sent the vendor an infected file for evaluation.
As an aside, we were able to do our own evaluation of the worm's code and its impact. Through that evaluation, we were able to determine the files and registry settings that the worm modified, the vector that it used to propagate and the ports it was using to open a back channel. Creating a signature in our IDS would give us the ability to detect the worm's presence, but unless we were willing to generate TCP resets, we wouldn't be able to stop the worm from propagating. TCP resets, or "session sniping," can be used within an IDS to stop malicious activity. But in my experience, they're a dangerous proposition, since they can easily be abused and can negatively affect the performance of the IDS. An IPS, on the other hand, being inline, would allow us to place specific rules to actually block malicious code.
In addition to malicious-code mitigation, an IPS can assist in the enforcement of an acceptable-use policy (AUP). Currently, our AUP bars employees from using peer-to-peer file-sharing applications like Napster, Kazaa and BitTorrent. We also have policies against tools such as Skype, a free Internet phone service that uses a ton of bandwidth.
With an IDS, we can detect the use of these applications, and we can block some of the associated ports and destinations on our firewall. But some of the tools don't allow us to just put some firewall rules in place and block the application. For some of the applications, we need to inspect the traffic and set blocking rules based on the TCP/IP packet payload vs. ports and destinations.
This is where an IPS comes in handy. We can put rules in place to block unauthorized applications, and we can collect statistics and report on how much traffic is caused by unauthorized applications. That kind of data, of course, is great stuff to be able give to your CIO. CIOs like to have in hand the information that, say, 60 percent of network traffic is related to AUP violations. That sort of thing provides for great return on investment, which is always a challenge within the information security field.
Of course, intrusion prevention isn't without its shortcomings. Being inline, a failed IPS device essentially blocks traffic from leaving the network. Therefore, it's important that we choose an IPS that has the ability to fail closed, meaning that it will let traffic pass (closed in the sense of an electronic circuit - I'm an engineer at heart). The drawback to this, from the security manager's point of view, is that you would have no protection from malicious activity if a failed IPS device allowed all traffic, good and bad, to pass.
However, sometimes you have to bite your tongue to appease the network engineers and other IT department heads. I'm willing to take the risk that we open ourselves up for a short period of time rather than face the loss of revenue and productivity that would result if thousands of employees couldn't do their jobs. Nonetheless, I reserve the right to change my mind.
We're looking at products from Juniper Networks and Sourcefire. At this stage, Juniper is appealing, since we're already using that company's firewalls and have a decent support relationship with it.
As an added benefit, we may be able to get away with a single console to manage both the firewalls and the IPS. The last thing I need is another management console. What Do You Think?
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at [email protected], or join the discussion in our forum: QuickLink a1590.