IDS mailing list archives
RE: Protocol Anomaly Detection IDS
From: "Andrew Plato" <aplato () anitian com>
Date: Fri, 7 Feb 2003 18:07:54 -0800
Does anyone have any recommendations as to which systems to look into/stay away from? Below is a list of some of the ones that looked like they might support protocol anomaly detection from their marketing
hype, let me know if I left any out/incorrectly added any: Lancope Stealthwatch Tipping Point/UnityOne ISS RealSecure Guard Cisco IDS 4250 CA/eTrust IDS Intruvert Intrushield NFR Network Intrusion Detection System Netscreen/Onesecure IDP Symantec ManHunt
I can give you some real-world experience with some of these systems, not all. First I'll slice off Cisco, CA, Lanscope, and Tipping point. I have limited experience with them. Cisco I've played with a bit and for the most part I didn't like it. Intruvert is a very fascinating product. Its fast, its accurate, and it costs a fortune. Beyond that, I can't say much about them. I have not sold any of them and we never got our demo unit from them. Oh well. Netscreen and Manhunt are superficially great products, but the core engine underneath them is weak. Manhunt for example is susceptible to some fragmentation tactics. It also has a pretty limited protocol base (like 25 protocols.) And as Rob Graham pointed out, these products do mostly protocol validation, not anomaly detection. I've played with ManHunt a little bit and I was unimpressed with it. ManHunt seems to be a product that people buy when they are ordered to get an IDS, but don't really care about its output. They just need pretty reports and a UI. I do however know RealSecure Guard like the back of my hand. Guard has a number of advantages over the others. The first is that it's a self-contained IPS system. Firewall and IDS all in one. It also does detection and response in REAL-TIME. It doesn't have to go out and rewrite firewall rules. Guard is also the BlackICE engine, which is natively a protocol analyzer and anomaly detection engine. One thing about anomaly detection is that it can spawn some weird alerts. As with all IDSs, it must go through a tuning process. However, one side-effect is that anomaly based IDSs can spot misconfigured and crappy software. Software that does things that don't necessary violate RFC, but they certainly do some noisy, annoying, or highly insecure things. Using Guard (and the other BlackICE-based ISS products) I've had customers discover all sort of strange happenings on their network. One of the things I really like about Guard is that it will pick up variants of attacks. It won't always have the best names for them, but it can pick them up and alert on them. It also captures raw packet information. That much said, one thing to think about when it comes to Guard. It is not something that is intended to defend an entire enterprise (unless you have a small enterprise). Guard, and pretty much all the intrusion prevention systems, are best seen as "special use" systems. The kind of system you use to create a high-security area of your network. For example, cordoning off a mainframe or mission critical database. If you have a limited Internet access (like a single T-1) Guard would be okay. But, its not a replacement (yet) for a firewall. One word of caution - there is a whole exciting world underneath Guard and ICEcap (its management console) surface level features. Much of this is hidden unless you learn BlackICE's parameters. Make sure you get the GOOD parameter docs from ISS. Nevertheless, I should point out that I am pretty biased toward ISS and Guard: I am an ISS reseller, I do training for ISS, and I wrote all the original tech docs for Network ICE. So, my opinions are not without color. Good luck. ___________________________________ Andrew Plato, CISSP President / Principal Consultant Anitian Corporation 503-644-5656 Office 503-644-8574 Fax 503-201-0821 Mobile www.anitian.com ___________________________________
Current thread:
- Protocol Anomaly Detection IDS Michael L. Artz (Feb 05)
- Re: Protocol Anomaly Detection IDS Martin Roesch (Feb 11)
- Re: Protocol Anomaly Detection IDS Frank Knobbe (Feb 11)
- RE: Protocol Anomaly Detection IDS Sonit Jain (Feb 12)
- Re: Protocol Anomaly Detection IDS Frank Knobbe (Feb 11)
- Re: Protocol Anomaly Detection IDS Yaakov Yehudi (Feb 11)
- <Possible follow-ups>
- RE: Protocol Anomaly Detection IDS Graham, Robert (ISS Atlanta) (Feb 06)
- RE: Protocol Anomaly Detection IDS Adam Powers (Feb 06)
- Re: Protocol Anomaly Detection IDS Jordan K Wiens (Feb 06)
- RE: Protocol Anomaly Detection IDS Andrew Plato (Feb 10)
- Re: Protocol Anomaly Detection IDS Martin Roesch (Feb 18)
- Re: Protocol Anomaly Detection IDS Robert Graham (Feb 20)
- Re: Protocol Anomaly Detection IDS - Honeypots Lance Spitzner (Feb 20)
- Re: Protocol Anomaly Detection IDS - Honeypots dreamwvr () dreamwvr com (Feb 20)
- RE: Protocol Anomaly Detection IDS - Honeypots Rob Shein (Feb 20)
- Re: Protocol Anomaly Detection IDS - Honeypots dreamwvr () dreamwvr com (Feb 21)
- Re: Protocol Anomaly Detection IDS - Honeypots Gene Yoo (Feb 25)
- Re: Protocol Anomaly Detection IDS Robert Graham (Feb 20)
- Message not available
- Re: Protocol Anomaly Detection IDS - Honeypots Bob Radvanovsky (Feb 20)
- Re: Protocol Anomaly Detection IDS Martin Roesch (Feb 11)
