# Threat Intelligence View Not Using securitySolution:defaultThreatIndex **URL:** \ **Category:** Elastic Security\ **Created:** [March 11, 2026, 2:37am UTC](https://discuss.elastic.co/t/threat-intelligence-view-not-using-securitysolution-defaultthreatindex/385403 "2026-03-11T02:37:47Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![logalicious](https://avatars.discourse-cdn.com/v4/letter/l/dfb087/32.png) [@logalicious](https://discuss.elastic.co/u/logalicious)\ **Post date:** [March 11, 2026, 2:37am UTC](https://discuss.elastic.co/t/threat-intelligence-view-not-using-securitysolution-defaultthreatindex/385403/1 "2026-03-11T02:37:47Z")
I am working on developing threat intelligence integrations and have noticed that most integrations use the `logs-ti_*` naming format for both the original index (e.g., logs-ti\_crowdstrike.ioc-default) and the transform destination index (e.g., logs-ti\_crowdstrike\_latest.dest\_ioc-6). This causes problems when using the default `logs-ti_*` pattern because the pattern matches both indices - effectively duplicating effort on already resource intensive enrichments and visualizations. I did some digging and found the `securitySolution:defaultThreatIndex` setting in Advanced Settings and changed this to the alias that points to the transform destination index. Now when I am creating threat intelligence rules, it uses the alias - great, but the IOC Intelligence view does not change. I am still seeing duplicate IOCs from both the original index and transform destination index in these results. This causes slow load times and inacurate metrics. Additionally, the documentation says to not overwrite the default pattern: > By default, only the `logs-ti_*` index pattern is specified. Do not remove or overwrite this index pattern, as it is used by Elastic Agent integrations. According to this, you should leave the `logs-ti_*` pattern, but then all Kibana features will be using duplicated data sets due to the issues described above, so this approach is confusing to me and does not seem to be efficient. It would make more sense to have Elastic’s threat intelligence integrations write to indices that do not match the `logs-ti_*` pattern and only reserve this pattern for transform destination indices or threat intelligence integrations that do not leverage transform jobs. > **[Update default Elastic Security threat intelligence indices - Configure advanced...](https://www.elastic.co/docs/solutions/security/get-started/configure-advanced-settings#update-threat-intel-indices)** > > The securitySolution:defaultThreatIndex advanced setting specifies threat intelligence indices that Elastic Security features query for ingested threat indicators. This setting affects features that query threat intelligence indices, such as the... > **[Enable threat intelligence integrations | Elastic Docs](https://www.elastic.co/docs/solutions/security/get-started/enable-threat-intelligence-integrations)** > > The Threat Intelligence view provides a streamlined way to collect threat intelligence data that you can use for threat detection and matching. Threat... ---
**Author:** ![logalicious](https://avatars.discourse-cdn.com/v4/letter/l/dfb087/32.png) [@logalicious](https://discuss.elastic.co/u/logalicious)\ **Post date:** [March 12, 2026, 2:30pm UTC](https://discuss.elastic.co/t/threat-intelligence-view-not-using-securitysolution-defaultthreatindex/385403/2 "2026-03-12T14:30:00Z")
It looks like threat intelligence source indices are controlled with an ILM policy that has a hot tier max age of 1 day and delete min age of 2 days. So I guess while the data is duplicated for ~2 days, that is the best that can be achieved while using Elastic’s current approach. Not too bad, but I still think there is room for improvement here. Specifically, it would be nice if the threat intelligence view respected the `securitySolution:defaultThreatIndex` setting or if the source indices did not use index names that match the `logs-ti_*` pattern. For example: >