Ticura Threat Intelligence Integration

The Ticura platform delivers the industry's only real-time view of global cyber threat intelligence that is objective, auditable, and continuously optimized to protect each subscriber's unique environment — at a fraction of the cost of legacy approaches.

Ticura's threat intelligence feeds are aggregated from hundreds of different public, private, and community sources, enriched using AI, and tailored to your specific needs. The IoC Scoring Algorithm applies a qualitative classification that changes dynamically over time.

This intelligence can be queried through a threat intelligence feed and delivered directly to Firewall, SOAR, SIEM, EDR, and other security platforms — for example, Elastic Security.

To use this integration, you need:

• Access to the Ticura web application
• An active Ticura subscription with at least one configured feed
• A supported Elastic Stack version with Elastic Security enabled

This integration requires Elastic Agent. If you have none, check the Elastic Agent installation instructions. You can install only one Elastic Agent per host. Elastic Agent streams data from the REST API and ships events to Elastic, where they are processed via the integration's ingest pipelines.

1. Register for a Ticura account at https://app.ticura.io
2. Create a Threat Intelligence feed based on your requirements and save the provided API key.

1. Open Kibana and navigate to Integrations.
2. Search for Ticura.
3. Select Add Ticura.
4. Enter your feed name into Advanced Options → Namespace — this becomes part of the data-stream name (logs-ti_ticura.indicator-{namespace}), so each Ticura feed you configure ends up in its own queryable index. Use lowercase ASCII; the value also appears in the CEL request-tracer filename, the dashboard's Namespace control, and any saved searches.
5. Enter your API key into Ticura API key.
6. Select your Download Interval and your Agent, then click Save and continue to enable the integration.

After the integration is enabled, indicators are periodically retrieved and ingested into Elastic.

Each ingested event represents a single indicator of compromise (IOC) and includes metadata such as type, confidence, and scoring information.

• IPv4 addresses
• IPv6 addresses
• Ports
• Domains
• URLs
• File hashes (MD5, SHA-1, SHA-256)

The integration keeps a deduplicated, automatically-expiring view of current indicators, so anything Ticura stops publishing disappears without manual cleanup.

1. Latest-IOC transform — a continuous transform deduplicates the raw feed by ticura.indicator.uuid into the logs-ti_ticura_latest.indicator index, keeping a single document per indicator (the newest version by event.ingested, since last_seen/@timestamp need not change on a content-only update). Because the full feed is re-downloaded on every poll, this collapses the per-poll copies into one current document — the same pattern used by Elastic's other threat-intel integrations.
2. Per-indicator expiry — the transform's retention policy drops an indicator from the latest index once its source-provided ticura.indicator.ages_out timestamp passes, so expired indicators leave the active view automatically.
3. Raw-stream ILM — the raw logs-ti_ticura.indicator-* data stream rolls over every 24 hours and is deleted 1 day after rollover for storage hygiene. The latest index — queried by dashboards, saved searches, and Elastic Security's Indicator Match rules — is the source of truth for "currently active" indicators.

Raw-stream documents are tagged labels.is_ioc_transform_source: "true" and the transform's deduplicated output "false"; dashboards and saved searches filter on labels.is_ioc_transform_source: "false" to show only the current, non-expired set. Each indicator's document _id is a fingerprint of ticura.indicator.uuid and Ticura's per-object content fingerprint (ticura.indicator.fingerprint). Because the raw stream is a data stream (indexed op_type=create), an unchanged indicator that is re-exported keeps the same _id and is rejected as a duplicate (no churn), while a content change yields a new fingerprint — and therefore a new _id — so the updated version is ingested. The latest-IOC transform keeps the newest version per ticura.indicator.uuid (ordered by event.ingested, since last_seen/@timestamp need not change on a content-only update) and collapses the duplicates that accumulate across index rollovers.

Important — keep the download interval below 24 hours. Every indicator is re-asserted on each download, and the active view expires on a ~24-hour window, so a longer interval can let still-active indicators briefly drop out of dashboards and Indicator Match rules between downloads. The same interval bounds deletion: an indicator Ticura removes from the feed leaves the active set within roughly a day of its last download, and never faster than one interval — so a shorter interval also removes deleted indicators sooner.

If you need to retain raw indicator history longer (for example, for forensic queries against retired IOCs), increase delete.min_age in the ILM policy logs-ti_ticura.indicator-default_policy.

The "active" indicator set is defined by recency of download: an indicator stays in the latest index (logs-ti_ticura_latest.indicator) only while it keeps being re-asserted by the feed. The transform's retention policy removes an indicator once its ticura.indicator.ages_out (a sliding ~24-hour window, refreshed on each download) lapses.

A direct consequence: if downloads stop — agent down, network/API outage, expired or revoked API key — the latest index drains and is empty within roughly 24 hours of the last successful download. Dashboards and any Elastic Security Indicator Match rules built on it then stop matching. The failure is silent (no error in the active view — it simply empties), and the emptying tends to happen relatively abruptly around the 24-hour mark rather than gradually.

This is inherent to a feed that signals removal by omission (Ticura sends a full snapshot each download and does not emit explicit delete events), so "currently active" can only mean "seen in a recent download." It is not specific to a misconfiguration. Recommended practices:

• Monitor ingest freshness. Alert if no ti_ticura documents have been ingested recently (well under 24 hours) — for example, watch event.ingested on logs-ti_ticura.indicator-*, or the health of the integration's agent and the logs-ti_ticura.latest_indicator-default transform. Because the active view empties silently, this monitor is your early warning, not the dashboards.
• Keep the download interval well below 24 hours (see above) — both so still-active indicators are refreshed before they expire, and so transient blips are absorbed by the CEL input's built-in retries.
• Do not shorten the retention window to delete removed indicators faster. The window doubles as your outage tolerance: a shorter window evicts removed indicators sooner but also empties the active set sooner during any outage (a short window would drop coverage during a brief network blip). The ~24-hour window is a deliberate balance for a feed that has no explicit delete signal.

Three dashboards are bundled, all scoped to event.module: ti_ticura and labels.is_ioc_transform_source: "false" — the transform's deduplicated, non-expired latest set. The default time range on each is set wide (≥ 30 days) because @timestamp reflects per-indicator observation time (threat.indicator.last_seen → first_seen), which can be days or weeks old for still-active IOCs. The "currently active" semantics is enforced by the scope filters, not by the time range.

Strategic view of the current feed: counts and distributions by type, country, industry, actor, malware family, MITRE technique, and feed source.

The dashboard has nine interactive controls at the top, with hierarchical chaining — each control's options are filtered by selections made to its left:

Tactical view focused on what to act on right now:

Strategic time-series view of how the feed is evolving:

The integration ships nine pre-built saved searches under Discover. They are filterable, exportable, and ready to be embedded into custom dashboards or used as the source for Indicator Match detection rules.

The integration maps indicators to the Elastic Common Schema using the threat.indicator.* field set.

GeoIP and ASN lookups use the GeoLite2 databases bundled with Elasticsearch — no external API calls or keys required.

The integration mirrors Ticura's MITRE ATT&CK enrichment into the canonical ECS threat.* field set so Elastic Security's MITRE matrix, detection rules, and timeline views pick it up automatically.

Different indicator types populate different ECS fields. The integration always sets threat.indicator.type for filtering.

IPv4 / IPv6 indicators (ticura.indicator.main_type: IPV4 / IPV6)

• threat.indicator.ip — the address
• threat.indicator.port — only set when ticura.indicator.sub_type: IPV4PORT
• threat.indicator.geo.{country_iso_code, country_name, city_name, region_name, location} — GeoIP-enriched
• threat.indicator.as.{number, organization.name} — ASN-enriched

Domain indicators (ticura.indicator.main_type: DOMAIN)

• threat.indicator.url.domain — the domain name
• threat.indicator.name — same as the domain
• dns.{question, answers, resolved_ip, type, response_code} — present when the source includes DNS resolution data

URL indicators (ticura.indicator.main_type: URL)

• threat.indicator.url.full — the full URL
• threat.indicator.url.{domain, scheme, path, original, …} — additional URL components are populated only when Ticura includes them in the feed; the pipeline stores them as-is and does not decompose url.full

Hash indicators (ticura.indicator.main_type: HASH)

• threat.indicator.type: file
• threat.indicator.file.hash.{sha256, sha1, md5} — populated based on ticura.indicator.sub_type (HASHSHA256 / HASHSHA1 / HASHMD5)
• threat.indicator.file.{name, size} — when the source includes them

These are preserved alongside the ECS-mapped fields for per-field provenance (see Field Provenance below).

The ticura.indicator.merged.{countries, industries, actors} fields are deduplicated, sorted unions of the ticura.indicator.* and ticura.indicator.additional_info.* equivalents — query these when you don't care which source the attribution came from.

The integration ships a single ILM policy logs-ti_ticura.indicator-default_policy with the following defaults:

hot:    rollover at max_age: 24h
warm:   min_age: 0s
delete: min_age: 1d
		

This is tuned for re-asserting threat-intel feeds — each ticura.indicator.uuid resolves to a single latest entry (the newest content version, deduplicated by the transform), while indicators Ticura removes from the feed age out within ~48h. If you need different retention semantics:

• Keep "removed" indicators queryable longer: increase delete.min_age (for example, to 7d to retain a week of dropped-indicator history in the warm tier).
• Reduce storage overhead during normal operation: there isn't any with this policy — only one backing index is in hot at a time.
• More aggressive removal: set hot.rollover.max_age shorter (for example, 12h) so dropped indicators are gone from storage within ~24h.

Edit the policy via Kibana's Stack Management → Index Lifecycle Policies. Changes apply immediately; existing backing indices pick up the new phase definitions on the next ILM poll (default 10 min).

Every document carries event.dataset: ti_ticura.indicator, event.module: ti_ticura, and observer.vendor: Ticura for whole-event provenance.

For ECS-canonical fields that the integration may populate by mapping from Ticura-specific fields (for example, threat.technique.*, event.severity), the original Ticura-namespaced field (ticura.indicator.technique.*, ticura.indicator.risk, …) is always preserved alongside. The mapping uses override: false, so a value Ticura supplied directly in the ECS namespace is never overwritten.

You can therefore distinguish three cases per field:

When preserve_original_event: true is enabled in the integration settings, the full raw JSON delivered by Ticura is also retained in event.original as an audit trail.

• Each feed is unique to the subscriber.
• Access is controlled using subscription-specific credentials. The API key is sent only over HTTPS, redacted from request-trace logs, and removed from any persisted in-memory state by the CEL input.
• Feed content reflects the configuration defined during the Ticura feed setup.

• Indicator relevance and confidence can change over time.
• The volume of ingested indicators depends on your feed configuration.
• Indicators are mapped to ECS threat.indicator.* and are ready for use by Elastic Security's prebuilt threat-intel Indicator Match rules, or any custom Indicator Match rules you build.

This is the Indicator dataset.

{
    "@timestamp": "2026-05-28T10:00:00.000Z",
    "agent": {
        "ephemeral_id": "358d3b95-fa75-46dd-85e5-241ee6bf8d87",
        "id": "90c88b35-7a07-4155-876f-ee05f8acf484",
        "name": "elastic-agent-39899",
        "type": "filebeat",
        "version": "9.4.2"
    },
    "data_stream": {
        "dataset": "ti_ticura.indicator",
        "namespace": "21612",
        "type": "logs"
    },
    "ecs": {
        "version": "9.3.0"
    },
    "elastic_agent": {
        "id": "90c88b35-7a07-4155-876f-ee05f8acf484",
        "snapshot": false,
        "version": "9.4.2"
    },
    "event": {
        "action": "indicator-update",
        "agent_id_status": "verified",
        "category": [
            "threat"
        ],
        "dataset": "ti_ticura.indicator",
        "ingested": "2026-06-26T12:25:49Z",
        "kind": "enrichment",
        "module": "ti_ticura",
        "provider": "Ticura",
        "risk_score": 80,
        "severity": 80,
        "type": [
            "indicator"
        ]
    },
    "input": {
        "type": "cel"
    },
    "labels": {
        "is_ioc_transform_source": "true"
    },
    "observer": {
        "product": "Ticura",
        "vendor": "Ticura"
    },
    "related": {
        "ip": [
            "192.0.2.10"
        ]
    },
    "tags": [
        "type:Curated"
    ],
    "threat": {
        "feed": {
            "description": "License: n/a",
            "name": "Ticura Curated",
            "reference": "https://www.ticura.io"
        },
        "indicator": {
            "confidence": "High",
            "description": "Test IPv4 malicious IP.",
            "first_seen": "2026-05-01T10:00:00.000Z",
            "id": [
                "aaaa0001-0001-0001-0001-000000000001"
            ],
            "ip": "192.0.2.10",
            "last_seen": "2026-05-28T10:00:00.000Z",
            "marking": {
                "tlp": "CLEAR",
                "tlp_version": "2.0"
            },
            "modified_at": "2026-05-28T12:00:00.000Z",
            "name": "192.0.2.10",
            "provider": "Ticura",
            "type": "ipv4-addr"
        }
    },
    "ticura": {
        "indicator": {
            "ages_out": "2026-06-28T12:00:00.000Z",
            "confidence": 75,
            "confidence_category": "high",
            "feed_ingest_timestamp": "2026-06-26T12:25:49.722Z",
            "fingerprint": "4210a52f45deada10decb7547d4f5804155ffe7e6ab179d9ce517ec3a849468d",
            "is_inbound": false,
            "main_type": "IPV4",
            "risk": 80,
            "risk_category": "high",
            "sub_type": "IPV4",
            "uuid": "aaaa0001-0001-0001-0001-000000000001"
        }
    }
}
		

This integration includes one or more Kibana dashboards that visualizes the data collected by the integration. The screenshots below illustrate how the ingested data is displayed.

← →

×

×

×

×