Investigating and searching across your data estate with Cisco Data Fabric powered by the Splunk platform
After data is onboarded, landed, discovered, and promoted where it makes sense, Cisco Data Fabric provides a unified way to search across the entire data estate, and to optimize those investigations with agentic search.
You are currently at Phase 3 in the Cisco Data Fabric getting started guide. Navigate to Phase 1 for an overview of getting started with Cisco Data Fabric, or to Phase 2 for step-by-step guidance on onboarding and promoting data.
Step 6: Search across the estate
Federated Search provides the unifying search layer across the data estate, including Splunk-managed locations – Machine Data Lake raw and analytics tables, and Splunk platform indexes – as well as supported customer-managed stores such as Amazon S3, Azure Blob and Azure Data Lake, Azure Databricks, Snowflake, and archived Dynamic Data Self Storage (DDSS) data. The goal is to investigate distributed data through one search experience rather than restoring or manually copying every source first.
Match the search to the tier:
- Search Machine Data Lake raw for SPL2-powered low-frequency discovery and tightly bounded ad hoc questions. Restrict source and time ranges to control scan volume, cost, and latency.
- Search Machine Data Lake analytics tables with SPL2-powered analytics when the workload uses known fields, aggregations, grouping, sorting, statistical analysis, or repeatable batch patterns.
- Search Splunk platform indexes with SPL or SPL2 when the workload needs fast, iterative access, raw-event context, real-time content, or existing Splunk platform knowledge objects.
- Federate to customer-managed repositories with SPL2 when data sovereignty, existing lake investments, or external storage requirements mean the data should stay where it is. Performance depends on format, structure, archival state, provider capabilities, and scan volume.
Start with a narrow query that confirms the dataset and time window. Expand only after validating the results. If repeated searches against raw data become slow or expensive, use the observed query pattern to justify a targeted promotion rather than promoting the entire history.
Step 7: Optimize investigations with agentic search
Splunk AI Assistant (SAIA) provides a natural-language entry point to the search workflow. With Agent Mode enabled, an analyst can describe the investigation they want to perform instead of manually constructing each search. The assistant can break the request into tool and skill calls, run event scans, find existing dashboards, run approved searches, and summarize the findings.
By providing concrete investigation anchors – such as the affected host or user, the relevant time range, and any known source or source type (for example: “Investigate unusual DNS activity for this host over the past two weeks, then compare it with authentication and firewall events.”) – SAIA can autonomously run its own investigations with human oversight and approval. The metadata established during onboarding and discovery helps the assistant start with the correct data and avoid unnecessarily broad searches.
Agent Mode keeps the analyst in control. Non-trivial searches require explicit approval because they can consume more resources. Previously-ran searches can be tracked through audit logs, and administrators can use Splunk platform roles and capabilities to limit who can run resource-intensive searches. Validate the assistant’s summary against the underlying events before using it to make an investigative or response decision.
To get started: install or upgrade Splunk AI Assistant, confirm that your deployment meets the current platform and regional requirements, and opt in to Model Runtime. An administrator can then navigate to Splunk AI Assistant > Settings > General and enable Agent Mode. Agent Mode is available in Splunk AI Assistant 2.1 or later for supported Splunk Cloud Platform and Cloud Connected deployments running Splunk platform 10.1 or later.
Example: Investigate suspicious email or DNS activity
Consider a SOC team that indexes authentication and firewall data for real-time detections but cannot justify continuously indexing verbose DNS logs.
The team routes all DNS events into Machine Data Lake raw tier via Splunk Ingest Processor, enriched with metadata along the way. When an alert identifies a suspicious host, an analyst opens Catalog, filters to the DNS source type and affected host, and verifies that the required two-week period is available. A bounded raw search confirms that the Machine Data Lake raw table contains the relevant DNS events.
If the investigation requires repeated, low-latency correlation with existing security content, the analyst uses SPL2 to correlate DNS queries with the authentication and firewall events already in the index. The promoted copy supports fast investigation, while the complete DNS history remains in MDL for future cases. If the task instead called for large-scale domain-frequency analysis across months of data, an Analytics Table would be the better promotion target.
This example captures the Cisco Data Fabric data journey: onboard and land data, discover with context, promote selectively, and search at the tier that matches the workload. It avoids making irreversible value judgments at ingest time and gives teams a repeatable path from retained data to operational action.