# Indicator matching rule with MISP intel with too long duration **URL:** \ **Category:** SIEM\ **Created:** [July 23, 2024, 9:20am UTC](https://discuss.elastic.co/t/indicator-matching-rule-with-misp-intel-with-too-long-duration/363617 "2024-07-23T09:20:53Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![hectorGC](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/hectorgc/32/136368_2.png) [@hectorGC](https://discuss.elastic.co/u/hectorGC)\ **Post date:** [July 23, 2024, 9:20am UTC](https://discuss.elastic.co/t/indicator-matching-rule-with-misp-intel-with-too-long-duration/363617/1 "2024-07-23T09:20:53Z")
Hi all, I am testing MISP integration with a indicator match rule. In the past our team suffered a small outage of a node due to a long execution duration fulfilling the java garbage collector. We are trying again to use this intel as it is really good. The rule is as follows: ![Screenshot 2024-07-23 111039](https://us1.discourse-cdn.com/elastic/original/3X/7/7/7760a2c949753b8ffc48fb4b54d3ae4cc9dc9b7c.png) The last run took 15s but the average is around 20/30s. We have a cluster ingesting 1M logs/s v8.9.2 and we didn't have any rules with this duration. The use of observer.ingress.interface.name is referring to the Public interface to filter only for these connections to non-internal. The ASA logs per hour are around 120000 logs, and the misp logs are 700 in the period of one week with these filters. My question, is this a normal duration time for this type of rules? Or can we improved some how? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [August 20, 2024, 9:21am UTC](https://discuss.elastic.co/t/indicator-matching-rule-with-misp-intel-with-too-long-duration/363617/2 "2024-08-20T09:21:52Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.