Issue in getting event_metadata_eventTimestamp for MTTD calculation in Advanced report

Hello everyone,

I am working on an advanced report to build an incident response matrix. So far, I've been able to gather the MTTR, alert creation time in SOAR, and case closure time. However, I'm facing an issue where I cannot retrieve the `event_metadata_eventTimestamp`cc in the advanced reports.

As a result, I am unable to calculate MTTD (Mean Time to Detection), which is the time difference between when an alert was first detected in SIEM and when the alert was created in SOAR.

The advanced report is very detailed, and I can see custom fields, system action results, alert entities, case assignment activities, playbooksand actions. Despite reviewing all of these, I have not been able to locate the event timestamp.

Has anyone encountered this issue before? Any insights or solutions or workaround would be greatly appreciated.

Thank you.

 

image.png

0 5 386
5 REPLIES 5

You wont be able to access event fields from the Advanced Reports. However, you should be able to achieve MTTD metrics suing the Alert timestamps. You will have an Alert Start Time - This will be the time of the first event in the alert - and the Alert creation time - when the alert was created in SOAR.

You can create a custom Dimension in your advanced report calculating the difference: 

josemarin_2-1738254873029.png

And then use that to create a custom Aggregated Measure to display the MTTD: 

josemarin_4-1738255068650.png

josemarin_5-1738255083200.png

(Screenshots are from a Demo instance so that's why the number is so high - not realistic)



 

Hello @josemarin 
Thank you so much for your response! I really appreciate your insights and I was able to implement your suggestion successfully.

I just wanted to clarify one point please correct me if I am wrong. It seems like this approach calculates the time difference between when the first alert is detected and the alert creation time in SOAR.

Would there be a way to retrieve the actual alert-triggered time (event_metadata_eventTimestamp) . The reason I ask is that I have noticed several detection rules with a 12-hour or 24-hour detection window, which might impact accuracy and lead to incorrect MTTD calculations as it is adding the detection window time in the TTD minutes calculation.

Looking forward to your thoughts. Thanks!

So, the StartTime of the Alert is actually taken from the Earliest StartTime of an event which is mapped int he Ontology. The default Ontology for events coming from SecOps, maps the StartTime to a field called "timeWindow_startTime" in the event. 

josemarin_0-1738603816192.png

Which in turn, matches the "event_metadata_eventTimestamp" field

josemarin_1-1738603915605.png

I woudl suggest reviewing your ontology settings, and where the StartTime is coming from. But in theory, the TTD Minutes should be giving you the minutes between the first event timestamp in an alert (earliest event_metadata_eventTimestamp) and the creation time of the Alert in SecOps Case Management

 

Thats interesting. I also have the same default Ontology for events. starttime is mapped to timeWindow_startTime

In some of the alerts it matches the "event_metadata_eventTimestamp" field where there is no detection window provided in rules. 
However, in our detection rules, we have provided the detection window, so timeWindow_startTime is the same as the start of the detection window.

So it is not matching every time. Let me share some screenshot for reference as well.
Can you share some thoughts on what can we do in case of alerts with detection window?

deep0x00_0-1738663767680.png

 

If you want the Alert Startime to always reference the "event_metadata_eventTimestamp" you could update the ontology mapping to that field. It would not be retroactive and will only affect alerts coming into the system after the change. 

But before doing the change, I would also try to understand how you are calculating the time window. Why does the time window starts when it starts and what that time refers to. The TTD would be relevant to the rule and the type of detection you are running. 

It might then make sense to use the end time and not the start time, as the end time would refer to the latest time when all the events were available for your rule to trigger and thus the actual time of when the behavior or set of events you were aiming to detect was actually happened.