Managing Timestamps in Sentinel
Turn table data into an investigation timeline.
Azure 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 Azure Sentinel investigation graph. We will also discuss how these timestamps can be used to help form a timeline for an incident during an investigation.
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.
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.
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.
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.
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 Azure 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 Azure 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 Azure 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 Azure Sentinel?
- How can we use these timestamps to create useful metrics in Azure Sentinel features like workbooks and notebooks?