We get many requests about the ability to use the event time rather than the capture time for NWFL, so I wanted to take some time to clarify my rationale behind using capture time as the default and how you can still get to and use event time.
There are several issues with the use of event time:
1. Not every message has an event time:
%SOPHOS Infected file \"C:
Documents and Settings
Administrator
Local Settings
Temporary Internet Files
Content.IE5
KLY74HAJ
eicar[1].com\" has been deleted...
(Note: Syslog messages have a timestamp provided in the header, but this is not necessarily the actual event time.)
2. All event sources may not be time synchronized and/or use the same time zone. It isn't uncommon especially for large organizations to have event sources using different time zones. Usually you see network devices using UTC, but many times servers are set to use the local time zone. Also, not all event sources are synchronized on time.
3. Some timestamps are incomplete (e.g., RFC 3164 syslog messages have no year in the header timestamp.)
4. Some event sources may send old messages or messages in batches.
If we look at the process of capture, messages are being "pulled" off the wire in real-time and that stream is processed (this is something that occurs with all SIEM/Log Management tools). Usually the expectation is that the messages are coming into the collection device in time order. The easiest thing is to mark the messages as they come in with a timestamp from the collection system. Then when the message is passed to other parts of the software, like a near real-time correlation engine, the sequence of time is ordered and predictable and it doesn't matter if the event sources are using different time zones or have non-synchronized system clocks. So now when the correlation engine looks for 5 failed logins in 5 minutes, it doesn't have to "back in time" to count a message that had an event time that is 30 sec before the first message it received, so you can see that there are technical reasons for using capture time as the default.
However, it is understood that event time is very important, so there is the capability in the product to be able to extract the event time (if it exists) and use it in Investigations and reporting.
In /etc/netwitness/(ng or 9.0)/envision/etc, there is a file called table-map.xml. Go to the line that says:
And change it from flags="Transient" to flags="None".
After you restart the NwLogdecoder service, Nextgen will write the Event Time meta to disk. The default is to extract it into memory for use with feeds and app rules, but not available for Investigator or Informer. After, you change it to non-transient, you will also have to change your index-concentrator.xml to make it available for Investigator and/or Informer. From that point on, event time will be extracted, written to disk and indexed. (NOTE: Indexing event.time, may impact the performance of indexing, so it should be tested 
). My personal opinion is that this is a good compromise, where we operationally use capture time, but have the ability to access the event time.
One other point about using event time, is that when users do an investigation, they think in terms of their current time, so if I want to look for events that occurred in the last 24 hours, they think in terms of 24 hours from the time now on the clock. Then what happens is that when you do a temporal search you have to think in terms of the time on the event source rather than the actual time. For example, if I wanted to see all of the logins in the past 24 hours for the user "paul", but I have some event sources that are on BST and some on EDT, I probably am going to miss some of the messages. However, if I used capture time, I would see those messages (granted, I might also get some old messages outside of that time window, but I would rather have more than I need than to miss out on messages.)
Anyway, a long post of my views and rationale (at least in my mind) as to why capture time is the default. Thoughts???
Paul W. Stoecker, Ph.D.
Principal Software Engineer
Content Analytics Research Team
RSA, The Security Division of EMC
o: 508.599.2743 | c: 302.379.3375 | e: paul.stoecker@rsa.com<mailto:daniel.reich@rsa.com
