Investigation of incidents

[Vladimir Suvorov]

Hello Friends!

I have been using Sagan for a long time in our small company and faced one problem, probably not me alone, namely:

How to identify the chain of events that formed the incident?

At the moment, I only get information about the incident itself, including some details

[Da Beave]

Hello Vladimir, 

That typically requires some manual digging and what type of event happened.  For example,  if Sagan triggers via a suspicious command,  then digging through auditd logs might be in order.     If it's a "login from outside home country" type of event, then it might be the result of a possible credential theft.   That can be a bit harder to determine. 

It largely depends on the event.  Do you have a scenario you can share?  

--
You received this message because you are subscribed to the Google Groups "sagan-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sagan-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sagan-users/c0023712-b038-45d5-b5c3-d8b9ba7fb8d1n%40googlegroups.com.

[st...@sroskam.nl]

For our infrastructure logs I have the same issue, because the syslog servers are locked down and that makes investigations harder.

Maybe we could add some logic:

1. If a rule is triggerd, forward the log and rule SID to elasticsearch

2. If an alert is generated, compose an elasticsearch query and add this to the alert

 - When a flexbit or xbit is used, that query should contain all relevant SID's and should be scoped on the flexbit/xbit types, to filter unnecessary logs

 - When a track_by is used, that query should contain the necessary scoping, timeframe could be an issue here, because we cannot determine the oldest relevant log based on the rule settings

- In other cases the elasticsearch query is quite simple

Would this be an option for your problem?

Best regards,

Stef

Op vrijdag 26 februari 2021 om 01:12:42 UTC+1 schreef Da Beave:

[Da Beave]

Hello, 

There has to be a means for your SOC staff or analysts to dig into data.   One way to do this is have your infrastructure logs go to the "secure" location and copy is sent to a device that is not considered "secure".    This way,  you ensure that the integrity of the logs but also give a location of staff to do more research.   Similarly,  if I have a Suricata (IDS) event trigger,   many times we have to refer to flow logs,  dns logs, tls logs,  etc to get to the heart of the issue.  Without access to that data,  it's difficult for an analyst to do their jobs. 

" - When a flexbit or xbit is used, that query should contain all relevant SID's and should be scoped on the flexbit/xbit types, to filter unnecessary logs:

I've considered doing this but need to work out the details.  You can get this information via the "saganpeek" command. 

" When a track_by is used, that query should contain the necessary scoping, timeframe could be an issue here, because we cannot determine the oldest relevant log based on the rule settings"

This data is also available via "saganpeek".   I might be able to work this into the JSON output so that it is easily correlatable.

Hope this helps!

To view this discussion on the web visit https://groups.google.com/d/msgid/sagan-users/11284fb6-bc80-49a7-8ee3-019f7b85be91n%40googlegroups.com.

[Vladimir Suvorov]

Hi! Thank you for telling me about "saganpeek", I will try to see how much it can be useful in the work

Best regards,=

четверг, 1 апреля 2021 г. в 23:34:46 UTC+3, Da Beave:

[Da Beave]

Once of the new big things for the next Sagan release is to include in the event EVE (JSON) a "correlated" nest.  This will allow you to immediately "see" how things are correlated.   That's already up in Github (Sagan 2.0.2).  

To view this discussion on the web visit https://groups.google.com/d/msgid/sagan-users/e663989f-4614-4f7c-b19f-40263f8fbe4en%40googlegroups.com.