[Discussion] Text in Msgs

John Pritchard john.r.pritchard at gmail.com
Mon Oct 27 17:41:12 UTC 2008


I think this could kind of functionality could open up some very
interesting avenues for additional post-alarm processing of alerts.

Agree that rolling into an alert "name" could be potentially
problematic. This not only applies to Snort but also to a number of
SEM/SIM/SIEM/ESM applications.

But, passing some additional 'high level" (overview) in new data
field(s) could open some interesting avenues for further innovation.

For example, the returned "match" could be sent on to additional tasks
that would either additionally validate the alarm or invoke some other
automated form of action.

Take a signature designed to detect possible credit card patterns.
Once a potential pattern match is caught, the string could then be
passed to other processes to further validate or refute the trigger.
For a VISA credit card sig, the initial match might simply be on a 16
digit number sequence beginning with a "four" (which would be highly
prone to false positives). But, once "matched" the string could be
passed to another process to run a Luhn checksum algorithm on the
string; thereby, providing a significantly higher measure of
confidence whether the initial alert was "real" or just "noise".

John

On Mon, Oct 27, 2008 at 9:46 AM, Matt Jonkman <jonkman at jonkmans.com> wrote:
>
> Frank Knobbe wrote:
>> No, that's a bad idea (at least if you talk about Snort). If you create
>> new/different message texts, Snort will create a new entry in the
>> signature table (unique to msg+gid+sid+rev). Also, you would not get the
>> same text with barnyard or in barnyard (and probably flop) based
>> installs since BY only reports the sid (the msg is pulled from the
>> sid-msg.map file).
>
> We are not talking snort. This is totally different.
>
> And we'll definitely not use a db schema with this issue.
>
> Matt
>
>>
>> While you could of course fork barnyard, my concern would be the bloat
>> of the signature table due to unique msg texts.
>>
>
> No forking here, all new.
>
> Everything from the pattern matcher on up. :)
>
> Matt
>
>
> --
> --------------------------------------------
> Matthew Jonkman
> Emerging Threats
> Phone 765-429-0398
> Fax 312-264-0205
> http://www.emergingthreats.net
> --------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc
>
>
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>



More information about the Discussion mailing list