Managing Timestamps in Sentinel
Turn table data into an investigation timeline.
Microsoft Sentinel uses raw table data to represent what is happening during an incident while using the investigation graph. This has resulted in some confusion around timestamps and what each of them mean. A cloud security analyst will have significantly more difficulty trying to figure out what happened during an incident if they cannot discern the difference between the timestamps.
In this blog, we discuss what different timestamps mean when they are found in the Microsoft Sentinel investigation graph. We will also discuss how these timestamps can be used to help form a timeline for an incident during an investigation.
Time Generated
This is the time that an incident was generated within Sentinel. This timestamp is useful for determining when the SIEM system was made aware of the incident. Analysts can use this information to help with tracking multi-stage incidents and SOC managers can use this information to track the performance of their SIEM system.
Creation Time
This is a timestamp that represents the actual time the incident was created instead of the time that the incident was generated. There is normally only a milliseconds long difference between the timestamps, so analysts normally treat this timestamp as functionally the same as time generated.
Start Time
The time that an alert was generated in a connected data source. This timestamp can be used as the time when the incident is first detected by a system on the source network. This is useful for determining the earliest point that the incident was known about.
End Time
The end time of the alert in the source system, this is useful for determining when the detection source believes the event associated with the alert ended. An analyst can use this information to determine when the part of the incident associated with that alert ended in that detection source.
Last Updated
This timestamp represents the last time where the alert was updated. This is useful for Microsoft 365 Defender products because their alert correlation may find additional alerts that are related to an incident that already exists. Analysts can use this timestamp to see the last time the incident was updated with more information from the source system.
Last Update Time
This timestamp is a constantly changing timestamp that is connected directly to the Microsoft Sentinel incident. If an analyst changes the incident in a notable way like commenting, changing the status, or changing the severity the timestamp will be updated in the Security Incident table. Analysts can use this timestamp to find out the last time that a change was made to the incident.
Process Ending Time
This timestamp is the time that Sentinel received an alert from a source system. This is different from time generated because it is when the alert was received, not when the incident was generated based on that alert. When dealing with small differences in detection time, distinctions like these can be useful for creating a more accurate timeline.
We will continue to share best practices and lessons learned in future posts on managing data from the Microsoft Sentinel investigating graph. If the incident data will continue to be presented in this way, analysts at CyberMSI need to be able to interpret it in the most effective way possible to construct timelines for incidents in customer environments.
In closing, consider these three questions when working with Microsoft Sentinel timestamps in your organization’s investigations:
- Do we have a formal procedure for managing cybersecurity incident timelines?
- Can our analysts understand the difference between the different data ingestion times made available in Microsoft Sentinel?
- How can we use these timestamps to create useful metrics in Microsoft Sentinel features like workbooks and notebooks?