IDS vs. IPS
A firestorm of controversy exploded four years ago when consulting firm Gartner declared that intrusion-detection systems that passively monitor for malicious traffic would be "dead" by 2005, a dinosaur wiped out by intrusion-prevention systems that proactively block bad traffic.
Buying an IDS to monitor unwanted traffic is a waste of time and money, Gartner stated, urging enterprise managers to start buying in-line IPS products and step up to the plate and block the attack traffic comin' at 'em, primarily from the Internet.
Blocking the bad traffic with an in-line IPS opened the possibility of mistakenly blocking good traffic, too, yelped IDS proponents.
IPS products in 2003 were mainly in their infancy and their accuracy deeply suspect. IDS - the most well-known and popular being open source Snort created by Martin Roesch in 1998 - was a known quantity. Sure, IDS had its drawbacks, sometimes generated false positive and negatives, and most people didn't really know what to do with the massive amount of information netted in the monitoring process.
But Gartner saying IDS is dead?
"I find the logic behind their conclusions significantly flawed and their recommendations incomprehensible," was the response at the time from Roesch, CTO at Sourcefire, founded in 2001 to commercialize Snort. "To be fair, Gartner's concerns have some basis in fact," he conceded, adding, "Undoubtedly, IDS must continue to evolve in order to fully realize its potential."
Today, the issue is largely a moot point as IPS products on the market - which typically rely on IDS detection techniques to flag a problem - tend to operate in a mixed mode, allowing managers to boldly block malicious traffic or passively monitor, or both, depending on the configuration. Security vendors are often coy about breaking out figures on IDS and IPS, but IDC believes IPS began overtaking IDS in 2005. Continuous testing by independent sources helps with determining strengths and weaknesses in IPS. -Ellen Messmer
IPSec vs. SSL VPNs
When IP VPNs came on the scene in the late 1990s IPSec quickly established itself as the standard to provide secure network-layer connectivity over insecure IP networks, typically the Internet.
The appeal was obvious: it is less expensive to buy Internet access and make WAN connections over it than to buy dedicated circuits or a frame relay or MPLS service.
But IPSec is complex. The more sites that connect to each other, the more secure links or tunnels need to be defined and maintained. If IPSec is used for remote access, it requires software on every remote machine that must be installed and maintained.
Then SSL VPNs entered the scene offering application-layer secure access over the Internet using capabilities common to most browsers. The implication was that businesses interested in remote-access VPNs no longer needed to distribute and maintain client software on the remote machines.
The limitation of SSL was that the browsers could access only Web-based applications, but this challenge was met by Webifying non-Web applications or pushing Java or Active X SSL VPN agents to the remote machines on the fly. These plug-ins gave the remote computers the ability to create network layer connections comparable to IPSec, but without having to distribute dedicated VPN client software.
As a result, SSL VPNs are making great headway against IPSec VPNs for remote access and seem likely to win out in the end.
IPSec is still the preferred method of site-to-site VPNs because either technology requires a gateway anyway, IPSec is better established in this arena and many SSL vendors don't even offer site-to-site connections. For site-to-site, IPSec carries the day.