[Oisf-users] [Emerging-Sigs] New Classification System Finalization

[Kevin Ross]

Actually speaking of Suricata feature reaquests can I suggest the following
2 things for some ideas I had:

1) The option to have the session as an alert as a rule option. Or being
able to configure it somewhere for rules, so for instance rather then just
seeing the single packet you can see everything sent to the client in that
session, both client/server communication in that session or something in
the alert. I know you can do it with tags in a messy kind of way but
something easier that is in between full packet capture and the single
packet alerts would be useful to have in single alerts if desired. Even a
config option so people can enable it if that have the spare memory with
sids such as session:all,to_client,to_server and then have another thread
deal with this.

2) The option to specifiy a path to save these files too and then have rule
options or config options which say extract_pdf, extract_exe etc so if an
alert fires, say for the newplayer exploit and extract_pdf was in the rule
(or a config option like extract_pdf then sids) that the PDF file would be
carved out of the session and saved before the reasembled session was
cleared or whatever. Same could be done with exe files and other files.
This means say the javascript in PDF sig fired, you could have the PDF on
disk so that you can decompress streams, analyse, scan with AVs or whatever
else. This would obviously need to be an additional feature as I imagine it
would need more resources to hold the sessions and if an alert is fired on
them for .exe files, .pdf files etc then it would have to carve the file
out. Using tools like tcpxtract or nfex
http://blogs.cisco.com/security/network-based-file-carving/ which is more
reliable at it file carving is very useful in providing context.

Again another thread within suricata or even something else could be used to
go back over the session and carve out the file to disk. It could even save
short term PCAPs to disk and then go over them with session filters and
extract the files from the session that the alert was generated on so the
capture is on disk for a short time rather than in memory. For exes for some
people they may want to carve out certain suspicious small executables with
the policy sigs or even all executables and then have a script run clamav or
something, move infected files into another folder and then delete the
others.

What do people think? No idea of feasibility or practicality, just some
jumbled ideas.





On 31 January 2011 19:28, Matthew Jonkman <jonkman at emergingthreatspro.com>wrote:

> As you may recall, Alienvault (http://www.alienvault.com), the home of
> OSSIM, has very generously offered to the snort and suricata communities the
> classification system they've developed to better categorize and react to
> IDS events. We're excited about this, especially in suricata, and we have
> already begun the changes required to allow us at Emerging Threats Pro and
> Emerging Threats Open to distribute the rulesets in both forms.
>
> We had called an end to comments by Jan 12, but discussion has continued
> mostly privately. A few points to iron out yet:
>
> 1. Sourcefire has proposed to change all underscores to dashes.
> I feel the underscores are an important differentiator. But older snort's
> may not handle that well. Suricata will handle them fine. But having
> differing systems is going to be a challenge of course.
>
> 2. Sourcefire also proposes to lower-case everything.
> Shouldn't be a big deal if no one objects.
>
> 3. We also need to assign priorities to the events. Sourcefire in the link
> below has proposed how they might look. We need feedback there.
> Perhaps we put up a simple web app to let folks go through and prioritize
> and we can take the average over a few weeks of input?
>
> -----------
>
> Initial posts are here:
>
> http://blog.emergingthreatspro.com/2010/12/new-classification-system-proposal.html
>
> and here:
> http://blog.snort.org/2011/01/classification-comments.html
>
> The actual system is here as proposed by Alienvault:
>
> http://www.emergingthreats.net/new_classifications_v1.txt
>
> And a version proposed by Sourcefire.
> http://www.snort.org/assets/157/classifications.txt
>
> -----------
>
> I propose these steps as a way forward:
>
> 1. Lets get more feedback on the lists (the snort lists, the oisf lists,
> and the emerging lists).
>
> 2. We have an OISF brainstorming session at RSA in a week and a half (
> http://www.openinfosecfoundation.org/index.php/component/content/article/34-general-content/109-the-next-oisf-brainstorming-meeting
> )
> This is on the agenda there, lets get some more discussion and we will
> summarize this on the lists
>
> Lets call the End of February the final date, adopt an official
> classification.conf and move forward!
>
> Matt
>
>
>
> ----------------------------------------------------
> Matthew Jonkman
> Emergingthreats.net
> Emerging Threats Pro
> Open Information Security Foundation (OISF)
> Phone 765-807-8630
> Fax 312-264-0205
> http://www.emergingthreatspro.com
> http://www.openinfosecfoundation.org
> ----------------------------------------------------
>
> PGP: http://www.jonkmans.com/mattjonkman.asc
>
>
>
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro
> http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through
> Current!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20110201/cfd3fe74/attachment-0002.html>