[Emerging-Sigs] priority level

Martin Holste mcholste at gmail.com
Thu Jan 29 14:21:59 EST 2009

Note: I sent this six days ago but it got lost somewhere along the way...

Part of my method is to add a table to the Snort schema called sig_severity
with a sid column and a severity column (there's lots of other cool things
you could add here for notes, etc.).  Then I run periodic queries against
the database with a  join on the sig_severity table with a script and alert
when there's an event with a severity above a certain threshold.  (I would
prefer this process not involve polling, but that's a topic for the OISF
list.)  The schema looks something like this in MySQL:

CREATE TABLE sig_severity (
sig_sid int unsigned not null primary key,
severity tinyint unsigned not null

CREATE VIEW v_events_polling AS
SELECT timestamp, sid, cid, signature.sig_sid, signature.sig_name
FROM event
JOIN signature ON event.signature=signature.sig_id
JOIN sig_severityON signature.sig_sid=sig_severity.sig_sid;

Then in cron, run this every minute:

SELECT * FROM v_events_polling where severity > 10 AND timestamp >

There are lots of ways to make the schema, this is just a quick example.
One of the many advantages of using the database to record severity is that
you can change severities on the fly (without restarting Snort, e.g. from a
web console or auto-thresholding script).  Another feature is that different
sensors (or Snort instances) can have different severities for the same
event.  As has been pointed out, severity is entirely relative to the
organization, so keeping it as application-level as possible is a good

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20090129/12506a3f/attachment.html

More information about the Emerging-sigs mailing list