Classifying Events: Snorby vs. Squil Squert

[Andrew Colfelt]

<Newb Question Alert>

Ok, so classifying events has been low on my list of priorities since first spinning-up a semi-pilot/semi-production standalone SO machine.

There are a lot of things to get one's head around and, for a data-hoarder like me, it seemed most interesting to make sure the machine was capturing as much as possible, and I could delve into the analysis phase at my leisure.

Well, the time to classify events has arrived, and it is apparent that this is just as involved an exercise as setting up the sensor, at least here in the initial tuning phase.

I have read the managing Alerts post in the wiki, here:
https://code.google.com/p/security-onion/wiki/ManagingAlerts

It has suddenly dawned on me that, if you decide to use the beautiful and magnificent Snorby, you're signing up for double the work.

Put another way, most of the SO suite rests on top of Sguil, and so the event classification effort you put in here, by using the Sguil client or Squert to classify events, propagates nicely through the system. If you categorize events using Sguil, the results of that effort will show up in Squert, and vice versa.

Events that remain unclassified inevitably destabilize the system, so there's no getting around this requirement...
( see also post #2 here: https://groups.google.com/forum/#!topic/security-onion/Rysymiw05Fg )

But Snorby is kind of off on its own. It has its own separate database and classification system, and so the effort you put in here to classify events does NOT show up in Sguil or Squert, or at least that's my impression so far.

Which leads me to wonder how and when it is appropriate to use Snorby at all ?

[Matt Gregory]

Hi Andrew,

Whether you use Squert/Sguil or Snorby is largely personal preference and based on the feature set you need.

If you don't plan to use Squert/Sguil in real time, you can auto-categorize events. See https://code.google.com/p/security-onion/wiki/ManagingAlerts

Matt

--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

[Doug Burks]

On Fri, May 2, 2014 at 6:12 AM, Matt Gregory <mgg...@gmail.com> wrote:
> If you don't plan to use Squert/Sguil in real time, you can auto-categorize
> events. See https://code.google.com/p/security-onion/wiki/ManagingAlerts

...and if you don't plan to use Snorby, you can disable it:
https://code.google.com/p/security-onion/wiki/FAQ#How_do_I_disable_Snorby?

[Andrew Colfelt]

This helps, too !

https://groups.google.com/forum/#!topic/security-onion/VyjUIF1i8wk

As for Event Classification, though, if Snorby is to be used at all, there is an inevitable risk of duplication of effort.

[ Some thinking-aloud, just in case it helps someone else following this path for the first time... ]

Since Snorby's database does not feed back to Security Onion's database, event classifications you make in Snorby do not affect events displayed in Sguil/Squert.

Likewise, events you classify manually in Sguil/Squert do not affect events displayed by Snorby.

However, events you ( very carefully ) classify automatically with a rule in /etc/nsm/securityonion/autocat.conf *do* affect both Sguil/Squert and Snorby.

This places a special incentive on methodical tuning !

But even after such tuning, Snorby users who also need Sguil/Squert for the value it provides still face the duplication of effort problem: having to perform manual classification in two places.

[Doug Burks]

Replies inline.

On Fri, May 2, 2014 at 3:40 PM, Andrew Colfelt <abwco...@gmail.com> wrote:
> This helps, too !
>
> https://groups.google.com/forum/#!topic/security-onion/VyjUIF1i8wk
>
> As for Event Classification, though, if Snorby is to be used at all, there is an inevitable risk of duplication of effort.
>
>
> [ Some thinking-aloud, just in case it helps someone else following this path for the first time... ]
>
>
> Since Snorby's database does not feed back to Security Onion's database, event classifications you make in Snorby do not affect events displayed in Sguil/Squert.
>
> Likewise, events you classify manually in Sguil/Squert do not affect events displayed by Snorby.

Correct so far!

> However, events you ( very carefully ) classify automatically with a rule in /etc/nsm/securityonion/autocat.conf *do* affect both Sguil/Squert and Snorby.

That would be correct if you were referring to tuning via PulledPork
as you would be disabling rules before they generate alerts, which
would be upstream of the Sguil and Snorby databases. autocat.conf
only applies to sguild (Sguil/Squert).

> This places a special incentive on methodical tuning !
>
> But even after such tuning, Snorby users who also need Sguil/Squert for the value it provides still face the duplication of effort problem: having to perform manual classification in two places.

Correct, most users should decide on their primary database (sguild or
Snorby) and disable the other one:

- if Snorby is your primary database, create a sguild autocat to
automatically categorize *any* incoming alert so that you won't have
any alerts in Squert or the Sguil client

OR

- if sguild is your primary database (you're using Squert or the Sguil
client), disable Snorby:
https://code.google.com/p/security-onion/wiki/FAQ#How_do_I_disable_Snorby?



--
Doug Burks