We have recently noticed that an Azure AD a user had (18) events that spanned over 7 minutes, whereas Sentinel morphed this into (35) events spanning over 2 days. We have been told by support that "by design" it is rare but entirely possible for this to happen. We have also been told that "TimeGenerated" reflects the time Sentinel received the event, not the time when the event was created on the actual data source. This seems to conflict with Microsoft's definition of "TimeGenerated", which is "The TimeGenerated column contains the date and time that the record was created by the data source".
- If initial or duplicated events can stroll in days later, what does that mean for the accuracy of analytic rules as it sure seems like rules routinely use "TimeGenerated" as if it where the time the event was created?
- Is there a normalized field that reflects actual event creation time?
- At least in my tiny little mind Security Events are like banking transactions, they should never under any circumstances be duplicated.
Many SIEMs track three time parameters for an Event (McAfee, Splunk, ArcSight):
- Event Time - Actual time that the event happened, user A logged into system B.
- Received Time - When the event was received by the SIEM.
- Storage Time - When the event was stored.
My own experience has lead me to believe that the "Event Time" is what should be used for Security Analytics, while the other two are important for understanding SIEM performance, for example latency.
We're curious to know if anyone else has noticed this and how it's being handled.
J-
