Hey, <br><br>I was thinking if it is possibly to build on the rule language (using snort syntax as an example and including reliability) to include other device information. For example:<br><br>alert tcp $HOME_NET any -> any 137 (msg"possible worm"; content:"iamabigbadworm"; depth:40; reliability:9; nepenthes_event:reliability:+5; firewall:to_port_137,count:50; reliability:+2; track:by_source; timeout:600 seconds; sid:1600001; rev:1;)<br>
<br>I am just making up the syntax but the idea is you have what you want to match upon within the entire distributed IDS. For instance here a worm triggers an event and in this crude example the simple content match is simple snort and this is enough to generate an alert. However say in this example nepenthes generated an alert from the same source ip it will include that information in an alert and increase the overall relaibility then if a firewall (possibly through syslog or agents) sees the source IP trying to reach that port a certain amount of times it increases the reliability.  Then the whole rule times out after 10 minutes (with the reliability:match having confirmed hostility anyway). <br>
<br>If then it generates an alert but then subsequent events get grouped under the same alert. Then what it is passed over to whatever the analysis output is it can say: this worm sig triggered then this was seen on nepenthes plus firewall activity providing more information as well as possibly creating signatures to match upon unknown threats by correlating in a rule unusual activity. <br>
<br>Having such a rule system could help tie together parts of the distibuted IDS. <br><br>Oh and while I am at it; syslog content matches perhaps could be useful because then syslog messages can be matched upon in part of the sig. i.e content:syslog,"whatthecontentis". That way syslog compatible device messages can be sent to a syslog server and then the message can be parsed for an event increasing the reach of the distributed IDS.<br>