On 20/08/04 14:18 -0400, Marcus J. Ranum wrote: > 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. They had better. > 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 A large number of packets with the SYN bit set to a wide range of ports? But I am fine with either definition so long as we agree to stick to one. Lets stick to yours, it sounds a lot better than the commercial one. In the general rule: IF (condition) THEN (action) ELSE (next_input), A signature is the condition part. A response is the action part. A response may have multiple subparts, including additional tests. <snip> > >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" No, I was speaking generically here. A firewall's response would be to drop a packet, send a TCP reset/ICMP port unreachable, or allow the packet through. Optionally the packet headers could be logged as well. An IDS would react by alerting the administrator. An IPS would send a TCP RST/add a firewall rule/alert/whatever else. > 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. I wrote a very generic decision rule. If you were to put in all the decisions possible, you would end up with a decision tree. > 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. This needs a) A formal description of the system, in a language that computers can understand, (FSVO understand). b) A system of weighting the risks, depending on the value of the target to the organisation. c) A formal method of specifying what the organisation thinks should be happening. We have this, in the form of firewall rulesets. d) A formal notation and analysis methodology for what is actually happening (log analysis). e) A way to classify attacks and possible threats, and weight them. f) A way to allow humans to put all of this together. Point a) is sorely missing. Point b) should be simpler, even if we need some trial and error on the actual numbers. Point d) is still dealing with very coarse grained input, and a very wide range of inputs (the use of natural language helps humans, but makes it hard for computers. We need both human readability and computer readability). Point e) has been covered in other publications. Point f) needs to wait until we have some work done on the other systems. > >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. Not really. The original situation was pure chaos. With syslog, a certain amount of formality and strictness was introduced. What we are trying to do is formalise syslog even further, and make it possible to make very fine grained classifications. > >"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"? correction: It always was cheaper to know what was goood, than to look for what was bad. The trouble was that connectivity always used to trump over security. Nowadays, it takes a few minutes more for the connectivity push to go through. Devdas Bhagat _______________________________________________ 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 - 14:20:45 PDT