Extend Splunk Detection Capabilities with Query
Query is a patented Federated Search solution for security data that does NOT require additional centralization or transformation of the data. Query enables security teams to use data to get answers and make better decisions, faster. Acting as an API gateway, Query, enables searching data where it resides without having to know the underlying data structure or search language – returning results back in a normalized OCSF format. Query can be used via a browser, Splunk App, or API. Security operators use Query to be more efficient with fewer tool pivots and reduce costs by not having to centralize or duplicate all of the data. With Query you can prevent vendor lock-in with control over how and where data is managed and stored, while receiving a complete data driven answer from any connected data source.
Our latest release of the Query App for Splunk, adds deeper integrations into Splunk, enabling a powerful new feature: Federated Detections. Detection engineers, investigators and threat hunters benefit from maintaining their entire workflow within the familiar Splunk console, saving significant time by eliminating pivots to multiple tools and achieving higher-quality detection outcomes. Federated Detections let you trigger cybersecurity alerts in Splunk from any Query connected source without additional ingestion, greatly expanding the data reach of your Splunk environment.
Before understanding Query’s Federated Detections, let’s first understand the challenges organizations are facing with regard to authoring, maintaining, and running detections.
The Detection Problem
In traditional SIEMs and security platforms, security teams rely on two detection types:
- Out-of-the-box detections – pre-configured rules that ship by default.
- Custom detections – created and managed in-house, tailored to an organization’s environment.
Detections written by security teams focus on the second category and often get tied to specific sources with organizational context, like Okta, Entra ID, and custom cloud telemetry. This requires data to be ingested into the organization’s SIEM, forcing teams into rigid pipelines. But modern environments are multi-platform by design—data lives in EDRs, SaaS logs, cloud buckets, and business apps. Forcing ALL DATA into any one system is costly and brittle.
The Query Approach
Query Federated Detections run directly against remote data – wherever it lives. They’re written once using a vendor-agnostic model (OCSF), then executed across any connected source. Here’s what that changes:
- No ingestion needed. Query uses APIs to access remote systems in real-time. Detection logic is executed where the data is—reducing infrastructure costs and removing the need to centralize.
- Native Splunk integration. Detections trigger Splunk alerts like any other rule, so workflows, dashboards, and playbooks stay intact.
- No need to know the target data structure. Write your content in industry-standard OCSF, and also consume results in OCSF.
Federated Detections decouple detection logic from data location and the vendor data model. That means:
- One detection works across multiple sources.
- No ETL, pipeline delays, or licensing battles.
- Alerts reflect live, full-fidelity data, not filtered or transformed subsets.
- Security teams stay focused on outcomes, not plumbing.
Trigger Detections From Remote Data Using Query’s Splunk App
Query’s Splunk App lets you search remote data sources directly from inside of Splunk without having to ingest the data into Splunk. The federated search results become directly available in the SPL pipeline and are visualized in the Splunk Console.
Query Federated Search inside of Splunk Console
With the v2.6 release of the Query Splunk App, available here, you can now run Federated Detections and manage your detection content in Splunk.
Leverage Splunk’s Detections Reference Content Library
Splunk has been very generous in publishing detections written by their Threat Research team. See https://research.splunk.com/detections/. (You can also get these detections in YAML format from their open source https://github.com/splunk/security_content/tree/develop/detections.) With the latest release of the Query Splunk App, our R&D team has begun to convert Splunk’s CIM based detections to the new and improved Federated Detections:
Detections content in the Query Splunk App
Before I give you an example of our new and improved modern day detection, let’s understand OCSF a bit!
Write Your Detection-Logic Over OCSF – The Common Industry Model
The security industry’s leaders came together to create the Open Cybersecurity Schema Framework (OCSF) – a hierarchical object and security event model. See here for a beginner’s guide. When you are authoring/configuring your detections with Query, you write your detections’ condition logic over OCSF events and objects in a vendor-agnostic way. The object hierarchy gives you, the analyst, the power and flexibility that was previously not achievable in flat fields, only normalization models. You can write your detections in a more natural manner with these OCSF event categories and classes:
OCSF 1.4 Event Categories and Classes
With Query Federated Detections, your conditions expression is on the vendor-agnostic attribute hierarchy of the normalized event classes. For example, here is a partial list of attributes in the Authentication event (see full list here).
OCSF 1.4 Authentication Event Class
Example Scenario: Investigating authentication failures from all authentication data sources (without Splunk ingestion)
LEt’s explore this specific Splunk Threat Research’s detection written for Okta – Okta Authentication Failed During MFA Challenge. The analyst wants to investigate login failures that included multi-factor authentication (read more on MFA Fatigue Attacks here). That may indicate an adversary attempting to authenticate with compromised credentials on an account with MFA enabled.
Can we rewrite the Okta-specific legacy CIM detection to work:
- without ingesting into Splunk, and
- use OCSF to make it applicable for both Okta and Entra ID (or any other authentication provider).
Going by the OCSF Authentication event definition we referenced earlier, the base search can be run from Splunk simply as:
| queryai search="authentication.is_mfa=True AND authentication.status_id=FAILURE"
The above would parallel search both Entra ID and Okta over those vendors’ APIs without ingesting the data into Splunk. If needed, we could further limit the detection to just the two specific data sources we care about:
| queryai search="authentication.is_mfa=True AND authentication.status_id=FAILURE" connectors="okta, entraID"
Did you notice that we are running the same normalized OCSF-based condition logic across both data sources!? Also, the Query OCSF condition is much simpler to understand and write, runs in parallel across all connected data sources, and its formatting is free from the data extraction and mappings logic seen in the original CIM-based detection. WIN, WIN!!
Also, not only did we specify the search input in a normalized way, even the results come back OCSF-normalized, while preserving the raw data. For example, here is how the Okta authentication event comes back as the OCSF authentication event (the schema example we discussed earlier):
{
"actor": {
"id": "49956ab9-ba92-5b37-9297-d9657b60787c",
"type": "User",
"alternateId": "wanda.ibarra@auzretestbedengineering.onmicrosoft.com",
"displayName": "Wanda Ibarra"
},
"client": {
"userAgent": {
"os": "Windows NT 10.0",
"rawUserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.4"
},
"zone": "The Midnight Zone",
"device": "Computer",
"ipAddress": "192.168.116.142",
"mfaAuthentication": true
},
"device": {
"id": "f50d46e6-3f6f-4747-8098-8ab445b1fd0d",
"name": "CentOS 7.0",
"os_platform": "Linux",
"os_version": "7.0",
"managed": true,
"registered": true
},
"displayMessage": "User login to Okta",
"eventType": "user.authentication.auth",
"outcome": {
"result": "Success",
"reason": null
},
"published": "2025-01-24 04:48:29.000379",
"severity": "INFO"
}Configuring the Detection in Splunk
If you want the above authentication failure with MFA to run as a detection on all your sources in a platform agnostic manner, below is how you would configure it in a Splunk instance running the Query Splunk App. You can configure appropriate intervals and thresholds from the Splunk console by going to “Settings” -> “Searches, Reports, and Alerts”, and clicking the “New Alert” button. Here is the above scenario:
Configuring federated detection thresholds, intervals, and actions in Splunk
Conclusion: Federated Detections are here!
We went through how Federated Detections let you trigger cybersecurity alerts in Splunk without additional bulk ingestion. We took the example of MFA fatigue attacks – how analysts investigated it without Query (with Splunk ingestion and CIM), and how they can improve upon that with Query. Query’s OCSF based detection logic didn’t need ingestion, was simpler to understand and write in a vendor agnostic manner, ran in parallel across multiple remote data sources, and brought a normalized set of results from multiple sources.
Splunk with Query expands the reach of Splunk content and detections to distributed data, enabling you to access and get answers from more of your security data, wherever it lives.
Please contact us for any help with access to and setup of the Query Federated Search for Splunk App and/or your Federated Detection use-cases.
