Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: NetFlow for IDS |
|---|---|
| Date: | Tue, 26 Jul 2005 11:47:20 +0800 |
Thanks for these excellent comments. I would be very interested to hear from Cisco the ability of CS-MARS in respect to some of the critical points raised below. Agreed that being able to store flow information for billing and basic behavioural profiling is not rocket science, I am concerned that truly clever applications will lose out to SIM/SEMs if their actual ability to profile, aggregate and correlate anomalous activity is not clearly deifned... On 7/23/05, Adam Powers <apowers@lancope.com> wrote:
Okay, so sure, lots of technologies can take NetFlow and store it to disk. They might even extract a few stats here and there for network management/traffic accounting purposes. This kind of capability is trivial. Inclusion of vendors with this class of NetFlow support will dilute the value of the list Andy has introduced. I think the list should be limited to only those technologies that do deep analysis of the inbound Netflow PDUs. Stuff like... 1. NetFlow-based attack detection. First and foremost, the NetFlow security vendor MUST be able to detect various types of attacks based solely on the NetFlow data stream. Examples include SYN/UDP/ICMP floods, fragmentation attacks, traffic anomalies, policy violations, and scanning of various types. 2. Deduplication of NetFlow. If 2 or more NetFlow exporters see the same flow, the duplicate records must be counted and removed before processing. Non-trivial to say the least. 3. Realtime or near-realtime operation. The technology must be able to process high volume NetFlow (30,000+ flows per second) in near realtime, alarming on events as they happen vs. batch mode hourly or daily operation. 4. Normalization of NetFlow records; aka. "Flow Stitching". All of the "real" NetFlow security technologies (known affectionately as "ArOneZuCope Security"; Arbor, Q1Labs, Mazu, Lancope) allow for the consolidation of multiple NetFlow records into a single stateful record. This ability allows for tremendous data reduction in the overall amount of flow data being written to disk. 5. Client/Server determination. A single TCP socket will result in at least two NetFlow records (one in each direction of the socket; client->server, server->client). The receiving NetFlow collector must be able to assemble the two flows to determine which host was the server and which was the client. 6. Validation of NetFlow exporters. You must be able to not only collect NetFlow but alarm/alert when the exporter has failed (stopped exporting, misconfigured timeouts, etc). 7. Ability to handle and make use of v7 NetFlow ("flagless" NetFlow). v7 does not include ORed TCP flag data. Without TCP flags, NetFlow analysis is made far more difficult. Overcoming limitations of v7 NetFlow takes a good bit of thought on the vendor's part. 8. Topology discovery and accounting. NEXTHOP data in the NetFlow PDU can be used for topological mapping of the network which allows the NetFlow security technology to determine which router is electronically "closest" to a given host (for use in mitigation). The list goes on... My point is that there are "NetFlow Storage Technologies" and then there are "NetFlow Security Technologies" (aka. "You sir, are no President Kennedy"). Think TCPDUMP vs. snort in regards to Ethernet frame analysis. On 7/20/05 9:27 PM, "Ron Gula" <rgula@tenablesecurity.com> wrote:At 12:21 PM 7/18/2005, Gary Halleen (ghalleen) wrote:That list is handy, but incomplete. Cisco MARS should be added. MARS is a SIM product that receives log information from various sources (firewalls, routers, switches, IDS/IPS, host logs, antivirus, and more). It also receives netflow, and can provide very useful security-related information based on it. GaryAlong those lines, you can add any SIM that has a netflow agent or a log analyzer that can read someone else's netflow logs. Tenable's Thunder will do netflow in our 2.0 release and a quick survey of other SIMs saw other folks had netflow agents as well. Ron Gula Tenable Network Security ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. -------------------------------------------------------------------------- Adam Powers Director of Technology Lancope, Inc. c. 678.725.1028 f. 770.225.6501 e. apowers@lancope.com StealthWatch by Lancope - Security Through Network Intelligence? ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. ------------------------------------------------------------------------
------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. ------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Firewalls (was Re: IDS evaluations procedures), Ha, Jason |
|---|---|
| Next by Date: | Re: Firewalls (was Re: IDS evaluations procedures), Jason |
| Previous by Thread: | Re: NetFlow for IDS, Adam Powers |
| Next by Thread: | Re: NetFlow for IDS, Jonathan Glass (GMail) |
| Indexes: | [Date] [Thread] [Top] [All Lists] |