Poor Log filtering

[RomanZeltser]

Today is May 12th, and as you can see from the snapshot above, the filter simply does not work.

Is it common for your environment, too?

[ScottMoore1]

The problem is the filter works on the "time" meta, which is the time the log was received by the Log Decoder.  What you are referencing is "event.time", which is the time the log was created by the device.  There are many reasons why "event.time" is problematic for filtering:

1) Not all devices create one

2) Not all times are easily parseable.

3) TZ information is absent.

And the list goes on.  But "time" is always present in every log created.  "event.time" and "time" are usually quite close if received via syslog.  It's only when logs are received via batch processing that the two times might diverge significantly.  There has been a lot of work in version 11.0 to give more options for using event.time however.

[RomanZeltser]

Well, I am looking forward to the version 11.x because what I see in the filtered log makes no sense. It even makes no sense in the Reports. 

Let's say, I need the report of events for the last 24 hrs filtered for CnC only. Generated report shows the correct graph but below it, you can see many events that happened as far as 3 weeks ago. This is absolute shortcoming of RSA Netwitness.

Thank you!

[ScottMoore1]

That only makes sense if it takes 3 weeks to load your logs.  You might want to look into your log infrastructure with LC and VLC and make sure everything is configured correctly.

Also, post the full meta from one of the logs you are seeing so we can see the time and event.time meta.

[RomanZeltser]

It is NOT as it should be.

===============

Roman Zeltser

Sr. IM Security Analyst

CDR Associates

307 International Circle

Suite 300

Hunt Valley, MD 21030

P: 410-560-2269 x.1261

rzeltser@cdrassociates.com<mailto:rzeltser@cdrassociates.com>

[EricPartington]

Please post more details about the logs in question.  As mentioned by Scott, the logs appear to have arrived at the decoder in the last 24 hours but the event.time in the log message appears to be from 3 weeks ago.  

How are the logs for that device being sent ?

file reader, odbc, syslog ?  

Is the date set properly on that device (UTC) ?

is there queuing that is delaying the logs from arriving at the decoder ?  

Batch process that was restarted ?

Service Account that was unlocked and the logs are catching up ?

Many reasons why the could have legitimately happened.