Skip to main content
Question

Multi-stage queries and SOAR dashboards - An advanced use case

  • November 6, 2025
  • 2 replies
  • 91 views

malzahnOptiv
Forum|alt.badge.img+3

In another thread my organization got a great solution for MTTX calculations in dashboards using new mutli-stage yara-l capabilities.

Now we are trying to apply this for a more advanced MTTX metric.  

We are calculating an MTTR (Mean Time to Resolve) metric, but *if* the case was set to a “paused case stage” for a duration, we want to subtract that duration in the metric.  It seems like this should be 2 additional yara-l stages: one for the pause event and one for the unpause event.  But not all cases pause, so joining these stages in the root seems to ruin the logic.  Furthermore, logic to ensure that the stages happen in the right order needs to be added in, e.g., The “pause” event must happen before the “unpause” event.

Is it possible with the current release to construct this metric with the optional stages?

2 replies

cmmartin_google
Staff
Forum|alt.badge.img+10

I tested this and as far as I can tell the audit logging for a case being paused and resumed is not written into case_history.  In the UX I can see we write comments to the Wall, but reviewing the case table I don’t see those are audited into the Dashboard case table.

 

My initial thoughts would be we may not have the available audit data, prior to working out how you do the query.  Have you reviewed and found if the underlying data you need is available?


malzahnOptiv
Forum|alt.badge.img+3
  • Author
  • Bronze 4
  • 10 replies
  • November 14, 2025

I tested this and as far as I can tell the audit logging for a case being paused and resumed is not written into case_history.  In the UX I can see we write comments to the Wall, but reviewing the case table I don’t see those are audited into the Dashboard case table.

 

My initial thoughts would be we may not have the available audit data, prior to working out how you do the query.  Have you reviewed and found if the underlying data you need is available?

 

Hi Chris!

In this specific SecOps instance the administrators have configured a case stage called “Waiting Client.”  When the case is changed to that stage the pausing starts.  When it comes out of that stage the pausing ends.  Does that make sense? The audit data is the case stage change events.  The issue is that this is an optional condition. We can’t figure out how to express that in yara-l.

 

Thanks