Cyber security Blog articles - Obrela

Hunting at scale: the AI enabler Obrela is bringing to iSOCaaS

Written by Vasileios Pergioudakis, Head of Public Bids & Research Programs | Aug 27, 2026, 10:57:33 AM

Threat hunting is the capability every security programme claims and few can prove. As Service Delivery Lead in the EU-funded iSOCaaS project, Obrela is contributing an AI-enabled hunting capability built to make hunting measurable, not just faster.

Detection scales. Hunting does not.

A detection rule is written once, provisioned into a platform, and runs on every event thereafter without further human involvement. A hunt is a different animal. It is a question, asked by a person, against a particular body of data, at a particular moment. Someone has to translate that question into the query language of every platform it must run against, execute it, wait for it, collect what comes back, read it, and decide what it means.

Multiply that by the number of platforms in one estate, then again by the number of environments a managed provider serves, and the arithmetic stops working long before the ambition does. The industry's own data describes the consequence plainly: in the SANS 2025 Threat Hunting Survey, 61% of organisations named skilled staffing shortages as the primary barrier to a successful hunting programme, while the share formally measuring whether their hunting is effective fell from 64% to 51% in a single year. Hunting is being asked for more, and understood less.

That is the problem iSOCaaS asks its partners to solve at a level above any single organisatio, and it is the problem the enabler described here was built for.

 

What we built

Obrela's response was not to buy a better hunting tool. It was to remove the reason the work was expensive in the first place.

The Swordfish OpenXDR Databus is a technology abstraction layer that homogenises security data and security actions across the vendor platforms customers actually run. Built on top of it, the MDR Threat Hunting Orchestrator takes a single hunt package, authored and governed once in a vendor-neutral model, and executes it in parallel across supported SIEM and XDR platforms, across every environment in scope, in one pass. Our design documentation records the effect on hunt execution as a shift from hours to minutes.

The principle is deliberately narrow, and we state it rather than let a slogan do the work: author and govern once; execute natively everywhere.

What is common across platforms is the hunt's identity, scope, judgement and lifecycle, its name, the environments it applies to, the time windows, the severity and confidence, the MITRE ATT&CK mapping, the triage guidance, the version history. What stays native is the query itself. Each supported engine carries its own implementation of the behaviour, written in that engine's language, because a Kusto query and an XQL query are not translations of one another, and pretending otherwise produces worse hunting rather than better portability.

Critically, the orchestrator does not extract telemetry in order to search it. It sends each platform a query in that platform's own language, and the search executes inside the platform that already holds the data, against telemetry that never moves. Only the results come back, bounded by an explicit ceiling set on the hunt definition. Residency is preserved by construction rather than by policy, which is what makes the capability deployable in a national and cross-border setting rather than only a commercial one.

 

Where the AI sits, and where it does not

Every security vendor currently has an AI story. The useful question is narrower than the marketing: what specific job is the model doing, what happens when it is wrong, and would the system still be sound without it?

In our design, AI does two jobs. The first is entity resolution across disagreeing schemas, determining that a user field in one vendor's result set and a differently named field in another's refer to the same person, or that a host appears in two datasets under different identifiers. This is language work, not security reasoning, and it is high volume, so it is assigned to a locally hosted open-weight model. The second is the cybersecurity reasoning, explaining, in plain language, why a set of correlated results is interesting and what it appears to indicate. That is assigned to a frontier commercial model, invoked on curated hunt results rather than on raw telemetry, within Obrela's own tenancy under enterprise terms.

The model's output is treated as a proposal that must remain checkable, not as a conclusion. Every proposed correlation carries the source records it was derived from. Deterministic identifiers are preserved verbatim; where an identity can be resolved deterministically, the deterministic answer is authoritative and the model is not asked. A correlation becomes a lead for an analyst, it does not become an incident, a containment action or a notification without a person.

Correlation is strictly per-customer. The multi-tenancy of the orchestrator is an execution efficiency; it is never a data merge. And AI enrichment is off by default and switchable, remove it entirely and the orchestrator still executes hunts across every environment and every platform in parallel. The results simply arrive without a written summary. That is the correct dependency relationship between an operational capability and a probabilistic one.

 

What this contributes to iSOCaaS

iSOCaaS, Intelligent SOC as a Service for European Cyber Resilience, sets out to deliver managed SOC services tailored to sectorial, national and cross-border cyber resilience, integrating shared situational awareness, coordinated incident response and joint preparedness. Its second objective is explicit: to deliver AI-based, beyond-state-of-the-art enablers augmenting SOC capabilities for those three functions.

Orchestrated hunting is one such enabler, and it addresses each of the three:

  • Situational awareness. When a hypothesis is developed, from intelligence, from an incident elsewhere, from a published campaign, it runs against every environment in scope in the same pass, rather than reaching each one when an analyst gets to it. At sectorial and national level, that is the difference between knowing whether a campaign has touched a sector and believing it has not.

  • Incident response. Each hunt returns the matching records, a deeplink that reopens the query in the operator's own console, the ATT&CK techniques the hunt was designed around, and triage guidance authored in advance by the person who designed the hunt, at the moment they understood the behaviour best, rather than improvised by whoever is on shift. Responders receive evidence they can verify, not an alert they must trust.

  • Preparedness. A hunt that finds nothing still produces an outcome. Negative assurance, documented proof that a specific threat behaviour was looked for and not found, is a deliverable, not an absence of one. It is also stated narrowly: no evidence matching this defined hypothesis was found in the platforms that were successfully queried, within the specified window, in the telemetry those platforms retained. It does not assert that an environment is uncompromised. Narrower is stronger, and it is the form that stands up in front of a supervisory authority.

That last point matters disproportionately in this project. iSOCaaS is designed around entities in the essential and important sectors under NIS2 and their supply chains, and it carries accompanying cybersecurity insurance schemes. Both audiences, the regulator and the underwriter, ask the same question of a security programme: not did you find anything, but what did you look for, where, when, and what answered. Because every hunt is submitted as a structured definition and executed through a common pipeline, coverage, completeness, reach, latency and validated-lead rate are emitted by the machinery rather than assembled after the fact.

Where the hunt reaches four of five platforms and the fifth is unreachable, an expired credential, an API outage, a rate limit, the outcome is still delivered, and its status names what did not answer. A system that hides partial failure produces reports that are more comfortable and less true.

 

What comes next

Three developments follow naturally from the architecture and are at varying stages of research and delivery at Obrela: translating a hypothesis stated in natural language into a structured, reviewable hunt definition, with a person retained in the approval path; scoping hunts by sector, technology or asset class, so a campaign targeting a specific control system runs where that system exists; and shortening the path from a published intelligence report to an executed hunt across the full base.

Each is a capability written once against the Databus, and each therefore arrives across every supported platform and every environment at the same time. That is what an abstraction layer is for, and it is why a capability funded and validated inside iSOCaaS does not stay inside iSOCaaS.

Threat hunting should not be sold as analyst activity. It should be delivered as measurable security assurance. That is the argument, and iSOCaaS is where we intend to prove it at European scale.

 

Obrela is Service Delivery Lead in iSOCaaS, alongside project coordinator Sphynx, AI development lead CyberSafe, the Hellenic Republic Ministry of National Defence as national CSIRT operator, the Greek Ministry of Digital Governance as national competent authority, Karavias Underwriting Agency, Insuretics and Netsquare. Learn more at isocaas.eu.

Co-funded by the European Union

This project has received funding from the European Union under grant agreement No. 101190388. Views and opinions expressed are those of the author(s) only and do not necessarily reflect those of the European Union or the European Commission. Neither the European Union nor the granting authority can be held responsible for them.