If you work in complex environment, the challenges facing security operations teams are probably not simple either. Asides from the finesse required to have good governance and good opsec at the same time, the features provided by our security stack don’t always match the regulatory and compliance constraints imposed upon security teams.
Ultimately the fewer silos the security team has to work across, the better. Fewer silos provide a more holistic view of the threat landscape and lower cognitive demand on the analyst.
If you manage a SOC or lead a team, cognitive load is the linga franca of the SOC. The higher the load, the less capacity is available for threat hunting and other, high value activities.
The problem
For example - imagine an operations team that need performance and centralised logs to do their work. Now throw the security team into the mix and you have a dilemma - do you duplicate the ops data into your SIEM? Give Ops access to SIEM but limit access to certain indexes? Neither of these are great options and increase the complexity and workload on your team.
In previous Elastic iterations, Elastic serverless hasn’t had a great answer to these questions because the feature that permitted you to search across logical units of operation (a cluster in Elastic parlance), cross-cluster search, was not available.
The solution
Starting from today (16 September 2026), you can now query data from another project (similar concept to cluster in an Elastic deployment), called “cross-project search” With cross-project search you can now:
- Store the data exactly once 🙏
- Access it from other projects, just as if the indexes were in your project.
- Give projects (and teams connected to those projects) one way OR bidirectional cross project search. This means the SOC can search logs and metrics but operations can’t query SIEM, perfect!
- Use detection rules on data in a remote project (just like deployments and on-prem has had for ages). This has long been an aspiration for threat hunters and detection engineers using serverless.
- Separate detection engineering from agent management
- Store threat intelligence (once) in a dedicated project, and query it from all other projects!
Worked example
Below we are searching the FROM logs-* indexes. logs-endpoint* indexes are local and our threat intel index logs-ti* are in our threat intelligence cluster.
Notice there is no data_stream field because the index isn’t local!
{
"@timestamp": "2026-09-17T23:29:10.000+10:00",
"ecs.version": "8.11.0",
"event.category": "threat",
"event.dataset": "ti_threatbear.indicator",
"event.ingested": "2026-09-17T23:29:10.000+10:00",
"event.kind": "enrichment",
"event.module": "ti_threatbear",
"event.type": "indicator",
"threat.feed.name": "Threatbear Easy Intel",
"threat.feed.reference": "https://intel.threatbear.co/feeds/high-raw.txt",
"threat.indicator.confidence": "High",
"threat.indicator.description": "IP address from the ThreatBear high-raw threat intelligence feed",
"threat.indicator.ip": "1.1.249.7",
"threat.indicator.last_seen": "2026-09-17T23:29:10.000+10:00",
"threat.indicator.name": "1.1.249.7",
"threat.indicator.provider": "ThreatBear",
"threat.indicator.reference": "https://intel.threatbear.co/feeds/high-raw.txt",
"threat.indicator.type": "ipv4-addr"
}
Now on the threat intel project. Notice this document resides in the project, so it has a data_stream.
{
"@timestamp": "2026-09-18T09:41:47.974+10:00",
"agent.ephemeral_id": "1a018f0b-b8a5-4989-8df3-865201a93549",
"agent.id": "dbc0eb89-90f4-4362-9373-9f101fa85e9c",
"agent.name": "arabesque",
"agent.type": "filebeat",
"agent.version": "9.3.2",
"data_stream.dataset": "ti_threatview",
"data_stream.namespace": "default",
"data_stream.type": "logs",
"ecs.version": "8.0.0",
"elastic_agent.id": "dbe0eb89-90f4-4362-9173-9f101fa85e9c",
"elastic_agent.snapshot": false,
"elastic_agent.version": "9.3.2",
"threat.indicator.geo.city_name": "Felton",
"threat.indicator.geo.continent_name": "North America",
"threat.indicator.geo.country_iso_code": "US",
"threat.indicator.geo.country_name": "United States",
"threat.indicator.geo.location": "POINT (-122.06600004807115 37.040599985048175)",
"threat.indicator.geo.region_iso_code": "US-CA",
"threat.indicator.geo.region_name": "California",
"threat.indicator.ip": "98.35.45.105",
}
Does the project need to be in the same region / cloud?
Yes, this works too! This is awesome for compliance and regulatory concerns…you can build a global threat hunting team that has a global view, while the data is stored in each regulatory domain. Keep European data in Europe and Australian data in Australia!
I created a number of projects, one in AWS (us-east-1) and one in GCP (Iowa) and the process was easy to setup and seamless.
What’s next?
How access controls, namespaces and response actions work is yet to be ascertained. I think actions across clusters is a big ask at the moment, but hope that Elastic can provide a flexible, consistent and fine grained permission model.
For the time being, workflows can bridge many a gap due to their flexibility and extensibility.