Devdas Bhagat wrote: >> A "signature' is a matching rule attached to a identifying diagnosis. > >The term signature used in the IDS industry, as I understand the use of >it, is "A pattern of bits in a packet (or group thereof) that signifies >an attack". That's the marketing definition, yes. But, speaking as an ex-IDS designer, and former CEO of an IDS manufacturer, I can tell you that's not the case. Many of the detection algorithms in commercial IDS look at things additional to mere patterns of bits. For example, would you call SYN flood detection by tracking SYN/ACK/RST patterns an intrusion detection signature? I sure would! But it's not looking at byte patterns in packets unless you want to make a debater's argument that the "signature" is the SYN flag. Other examples of IDS "signatures" that don't look at packet patterns involve ping-of-death, half-open-scans, etc. This is why the definition of "signature" that I use is more accurate. It's a matching rule - and the matching engine can take into account packet contents, traffic states, system knowledge, software versions, application state, etc. What you're talking about is simple "packet grepping" - no IDS did simple packet grepping after about 1997. Basically what happened in the IDS market is that the marketing folks took over the terminology and messed it up so they could differentiate their products by criticizing the way others worked. Most unsophisticated practitioners fell for it, too. >A signature triggers an action, and what action should be triggered is >defined by the rule. When you start getting into actions, then you're into the space that the marketing weenies call "intrusion prevention" But if you want to extend the notion of "action" to include "render a diagnosis" we are in agreement. Most of the first IDS products only available action was to log an alert. What's important to note, and that I try to convey in my definition, is that a key piece of the value of a signature is that it *explains* what it thinks it matched. >The general point that you are making is: >IF (condition) THEN (action) ELSE (see_next_input); Yup. And the conditional can consist of a whole lot of potential states and values, not just packet patterns. >Ok, how would you get a generic system to enunciate a risk analysis? My first reaction: "BEATS THE HELL OUTTA ME!" But I hate to admit ignorance :) I think that you'd need to have some kind of policy engine that you could describe what your organization THINKS is happening, what systems it THINKS are crucial, and what the network sensors thinks SHOULD BE happening. Then you, uh, observe reality, subtract the 2, and weight the results disproportionately based on the importance of the servers? You could maybe re-weight based on the prevalence of classes of attacks... Lots of companies in the commercial space are moving to do this kind of thing. Trusecure, Tenable, Lancope, Protego, etc. >Syslog makes a very rough attempt at this by classifying logs into class >and severity. Keep in mind that syslog was not originally designed for >security logs, but as a generic information mechanism for an >administrator to know what was wrong with the system. Actually, I talked to Eric about this at USENIX in Boston. :) Syslog was designed as a defensive measure because every application that kept a log kept its own log in its favorite place in its own format. It turned out that just dealing with them all and keeping them from growing large got to be a PITA. So Eric wrote syslogd to aggregate basically what amounts to diagnostic and transactional stuff - as a matter of system hygeine rather than security. I find it ironic in the extreme that we syslog analysts are now spending a lot of time separating syslogs into buckets; essentially undoing Eric's work with more work. >"Under normal circumstances, there should be 0.25 Mb/s of NetBIOS >traffic. This should be ignored in reporting. However, there may be >spikes of 5 Mb/s occasionally. This should not be alerted, but should >be recorded for further analysis. A spike of more than 5Mb/s or a >sustained increase in traffic over 0.25 Mb/s is to be alerted on. Both >the occasional spikes and sustain increase should be reported in summary >reports." Yup! That'd be the input to the policy engine. Tools like LanCope, Mazu, and Foundry are heading that way. >> Here's a theory: >> - It's reaching the stage where the costs are going to flip-flop >> so that it'll actually be CHEAPER to know what's good than >> to look for what's bad. This is thanks to the huge proliferation >> of hack-ware. > >It always was. The trouble was that connectivity was trumping security. "was"? mjr. _______________________________________________ LogAnalysis mailing list LogAnalysis@private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2.1.3 : Fri Aug 20 2004 - 12:15:05 PDT