Why the licence usually outlives the value
Most banks operating in the UAE have bought at least one threat intelligence feed or platform in the last few years, often bundled into a SIEM renewal or purchased to answer an audit finding. The subscription gets renewed every year without much debate. The actual use, measured by how many alerts it generates that a SOC analyst acts on, tends to flatten out within months of go-live. The gap is rarely the vendor's fault. Ingesting intelligence and using intelligence are two different projects, and only the first one usually gets budgeted or staffed.
What a threat intelligence platform is actually doing
A threat intelligence platform (TIP) is middleware, not a sensor. It pulls indicators, campaign reporting and vulnerability context from multiple sources, commercial feeds, open source feeds, and sector sharing groups, then normalises them into a common format, typically STIX carried over TAXII, so they can be deduplicated, scored and pushed somewhere useful. On its own it detects nothing. Its output is only as good as what consumes it: a SIEM correlation rule, a SOAR playbook, a firewall block list, or an analyst's triage queue.
Three things decide whether that output does anything:
- Relevance: does the indicator or technique match assets the organisation actually runs, rather than a generic industry feed
- Timeliness: does it reach the enforcement point before the indicator goes stale
- Actionability: is there a defined action attached to it, or does it just add a row to a dashboard nobody opens
Three failure patterns worth naming
Feed with no destination
The most common setup is a TIP subscription sitting beside a SIEM with no automated pipeline between the two. Indicators get exported as a spreadsheet once a week and manually loaded into a watchlist. By the time that happens, fast-moving indicators such as malicious IPs and phishing domains have often already rotated out of use. Strategic reporting, the kind describing a threat actor's methods against the financial sector, ages more slowly and rewards manual review, but it still needs an analyst to read it and turn it into a detection rule, which is where the second pattern shows up.Context with no owner
Contextualised threat data, the kind that says this campaign targets SWIFT-adjacent infrastructure or this loader is active against GCC banking customers, is more useful than a raw indicator list, but only if someone is responsible for asking whether each report applies to the organisation. In a lot of UAE SOCs that is not a defined role. It gets absorbed into whichever analyst has spare time that week, which in practice means it mostly does not happen.Compliance treated as the finish line
NESA and CBUAE expectations around threat monitoring are written in terms of outcomes, not products: organisations are expected to show they track threats relevant to their sector and can act on them, not that they own a named tool. Buying a platform to close an audit finding, then treating the purchase order as the deliverable, is the single most common reason these programmes stall. Assessors increasingly ask for evidence of use, tickets raised from intelligence, detections tuned from a report, rather than proof of purchase.Making it operational
Wire it into detection, not dashboards
The highest-value integration is TIP into SIEM into SOAR: indicators enrich alerts automatically as they arrive, high-confidence matches raise the severity of an existing detection instead of spawning a separate one, and a SOAR playbook (the FortiSOAR page walks through what this looks like in a live deployment) handles the repeatable first response, block, isolate, open a ticket, so an analyst is triaging a scored alert instead of reading a raw feed line by line.Score by asset relevance, not vendor confidence
Most platforms ship a confidence score set by the vendor. That is not the same as relevance to a given environment. An indicator tied to an actor known for targeting industrial control systems matters less to a retail bank than a lower-confidence indicator tied to a group that specifically hits card processors. Mapping feeds against the organisation's actual asset inventory and priority systems takes deliberate work up front. Skip it and the SOC drowns in indicators it has no way to rank.Staff for the analysis, not only the ingestion
A platform needs a person, even part time, reading the strategic reporting, understanding the bank's own exposure, and turning findings into either a detection rule or a briefing for management. Without that role, even a fully wired technical integration leaves a gap between having the data and changing a defence because of it.What NESA and CBUAE assessors actually ask for
In practice, evidence requests centre on process rather than tooling: how threat information reaches the SOC, how it gets triaged and closed, and whether it has ever driven a control change. A vendor name on an invoice satisfies nobody. A ticket trail showing an indicator flagged, checked against internal telemetry through the SIEM, and closed with a documented action does. Keep that trail as the actual audit evidence, not the licence certificate.
Where to start if the current setup produces nothing
Pick one feed source that already maps to the sector. Most GCC banks get more out of a financial-sector sharing group feed paired with one paid strategic feed, such as Recorded Future, than out of five overlapping generic sources. Wire that single source into the SIEM with automated enrichment before adding anything else. Assign someone, even a few hours a week, to read the strategic reporting and translate it into either a detection or a briefing. Measure the programme by tickets generated and detections tuned, not by feed count or dashboard views. A narrow pipeline that gets used beats a wide one that does not.
Isn't threat intelligence just a feed into the SIEM?
Not quite. A SIEM correlates and stores security events from the organisation's own environment. Threat intelligence adds external context, who is attacking whom and with what, so those events can be prioritised and interpreted correctly. The two are complementary: intelligence without a SIEM has nowhere to be matched against real telemetry, and a SIEM without intelligence sees only internal logs with no sense of who is actually targeting the sector. Most of the value sits in the integration between the two, not in either product bought alone.
