Integration between ExtraHop and Demisto

Hi all,

I’ve some queries on how we can control the information being pushed by ExtraHop into Demisto via possibly triggers (or any other way).

We noted that ExtraHop pushes deduplication via ‘DETECTION_UPDATE’ event over to Demisto which can be quite a lot for alert such as ‘Weekly Summary: Weak Cipher Suites’.

  1. How does ExtraHop utilize the deduplication to push large amount of information from ‘Investigate Sources’ and ‘Investigation Clients’ section of the alert? Possibly each device/client IP per deduplication? If not, how does it push these data into Demisto?

  2. In event where there is a new machine learning/rule based alert which has several deduplication, could we can control the number of deduplication being pushed from ExtraHop?

  3. Is there any better alternative to whitelist alerts that we pushed to Demisto via specific record fields (e.g. client IP or hostname) other than hiding the entire alert via the UI or ignoring categories? Possibly any separate custom triggers? Or nested triggers for the ‘DETECTION_UPDATE’?

  4. Apart from those already defined demisto fields in the ExtraHop-Demisto bundle, is there any other fields from the records that we can push to Demisto?

Thanks!

Hi Bryan,

Welcome to the ExtraHop forums!

The Demisto integration deduplicates detections based on the id property. The DETECTION_UPDATE event fires each time the detection is modified so that integrations have the opportunity to look at the latest version of the detection.

Can you clarify what you mean by controlling the number of deduplications?

The supported Demisto trigger exposes a subset of detection fields for filtering. If you’re willing to make your own trigger, you can copy the current one and then use any of the properties of Detection to decide whether or not to send the detection to Demisto. For example, you can use Detection.participants to inspect the devices and IP addresses associated with the detection.

My coworker @swagatdasgupta would love to discuss this use-case in more detail. Can you share some detection types where you’re interested in having additional fields to send to Demisto, and what those fields are?

Hi,

Thanks a lot for your response.

Can you clarify what you mean by controlling the number of deduplications?

Just some background information. When we first integrated Demisto and ExtraHop together, we noticed several deduplication events in Demisto’s warroom for detection such a s, ‘Weekly Summary: Weak Cipher Suites’ which used up resources from Dbot. From ExtraHop UI, as the detection is ongoing, we noticed the counts under ‘Investigate Sources’ and ‘Investigate Clients’ increases which we reckon will fire the ‘DETECTION_UPDATE’. Hence, I would like to check if there’s any way for us to control the threshold of the deduplication (DETECTION_UPDATE)? Possibly by trigger? Would like to ensure moving forward if there’re large amount of deduplication for potentially new detection that was identified by the cloud services/rule-based, we are able to at least ‘control’ it. Or maybe fire an email to notify of large amount deduplication if possible.

The supported Demisto trigger exposes a subset of detection fields for filtering. If you’re willing to make your own trigger, you can copy the current one and then use any of the properties of Detection to decide whether or not to send the detection to Demisto. For example, you can use Detection.participants to inspect the devices and IP addresses associated with the detection.

What would be the recommended way to do it? Should we input the filters for specific detection title in the demisto trigger? Or should we create another trigger to filter and do a nested trigger (if possible)? Or is there any UI that allow us to input specific filter for some detection and hide the alert? Or to run certain filtering triggers to hide a specific detection title using priorities level (e.g. putting filtering triggers as the top priority to reduce noise before any processing)?

My coworker @swagatdasgupta would love to discuss this use-case in more detail. Can you share some detection types where you’re interested in having additional fields to send to Demisto, and what those fields are?

As we have potentially new detection coming in on a regular basis with Demisto integration in sight, we are trying to identify if there is any other fields we could potentially send to Demisto on the fly. Are we limited to the ‘Detection’ section on in the Trigger API Reference? What are the other corresponding fields in Demisto does the bundle support as there are several other information from the Reveal(x) and Demisto integration reference. (Please find attached image for corresponding fields).