Skip to main content

Using the Interactive Forensic Dashboard

TL;DR​

The Search pack includes pre-built dashboards for needle-in-haystack investigations. Learn how to use them to search across massive datasets, find specific indicators, and selectively export only relevant events.

The Scenario​

It's 3 AM. Your security team just discovered that a suspicious IP address 131.72.198.252 has been probing your infrastructure. They need to know:

  • What datasets contain events from this IP?
  • What specific actions did this IP take?
  • Which events should we send to the SIEM for deep analysis?

Traditional approach: Export all data to SIEM, search there. Cost: $$$$. Time: Hours.

Cribl approach: Use the Interactive Forensic Dashboard to search Lake directly, export only matches. Cost: pennies. Time: Seconds.

The Pre-Built Workflow​

The Search pack you installed includes dashboards that implement this three-step workflow:

  1. Search Broadly: Enter an indicator (IP, domain, term) and search across all datasets
  2. Refine Results: See which datasets contain matches and drill down
  3. Send Selectively: Export only relevant events to downstream systems

Let's use these dashboards to investigate the suspicious IP.

Step 1: Open the Interactive Forensic Dashboard​

Access the Dashboard
  1. In Cribl Search, click Dashboards in the left navigation
  2. Find the Interactive Forensic Dashboard (from the pack you installed)
  3. Click to open it

You should see a dashboard with:

  • Time picker at the top (default: last 7 days)
  • Dataset selector (which datasets to search)
  • Term Search input box (where you enter your indicator)
  • Results panel (displays matching datasets)
Edit the Dashboard
  1. In the dashboard pack click Edit in the top right navigation
  2. Click the pencil above Dataset
  3. A nav will pop out in the right nav. Under Value add
    • default_logs
    • datatieringlogs
  4. Click save

Step 2: Search for the Suspicious IP​

Now let's find everywhere this IP appears in your data.

Run Your First Forensic Search
  1. In the Time picker, select Last 7 days (or leave default)
  2. In the Dataset dropdown, select the datasets you want to search:
    • default_logs (tier3)
    • datatieringlogs (tier2)
    • cribl_search_sample (default search sample datasets)
  3. In the Term Search box, enter: 130.253.37.97
  4. The dashboard automatically runs the search
  5. Wait a few seconds for results

Understanding the Results​

The dashboard shows you a table with columns like:

  • Dataset - Which dataset contains this IP
  • Sourcetype - What type of log (web, firewall, etc.)
  • Term - The search term you entered
  • Count - How many matching events

Example results might look like:

Dataset_Source_TERM   
 Dataset             | location             |  Match
---------------------|------------------|------------------|-------
default_logs  | s3://lake-debir-mas-f0tos | 130.253.37.97 
datatieringlogs | s3://lake-debir-mas-f0tos | 130.253.37.97

This tells you:

  • The IP appears in 2 datasets
  • Most activity is in your tiered web logs (847 events)
  • Also appears in VPC flow logs (156 network events)
  • Total: 1,003 matching events to investigate
The Power of This Approach

You just searched across potentially terabytes of historical data in seconds. The dashboard:

  • Queried multiple datasets simultaneously
  • Counted matches in each one
  • Summarized results for you
  • All without exporting anything yet

In a traditional SIEM, you'd first need to export all this data (expensive, slow), then search it.

Step 3: Drill Down to Specific Events​

Now that you know WHERE the IP appears, let's see WHAT it did.

View Detailed Events
  1. In the results table, click on the row for datatieringlogs | 130.253.37.97
  2. The dashboard automatically runs a second query to fetch actual events
  3. You should see the Events to Lake Dashboard appear (or a panel showing event details)
  4. Observe the actual log entries showing:
    • Timestamps of activity
    • HTTP requests made
    • Status codes received
    • URLs accessed

Analyzing the Events​

As you scroll through the events, look for patterns:

Suspicious indicators:

  • Multiple 401 errors (failed authentication attempts)
  • Requests to /admin endpoints
  • Requests to /api/users (potential data access)
  • Any 200 success codes after failures (successful breach!)

Example event you might see:

{
  "_time": "2025-11-10T10:18:23Z",
  "clientip": "131.72.198.252",
  "status": 200,
  "request": "GET /admin/users HTTP/1.1",
  "user_agent": "suspicious-scanner/1.0",
  "business_impact": "security"
}

This shows the IP successfully accessed the admin users endpoint - definitely worth investigating!

Step 4: Understand the Send Workflow​

The dashboard is designed to let you send matching events to a destination for deeper analysis. Here's how it works conceptually:

The Flow:

  1. You search for an indicator → Dashboard finds matches
  2. You review the events → Identify what's relevant
  3. You trigger the send → Events go to investigation dataset
  4. Stream routes them → Land in your designated destination
Behind the Scenes

The dashboard uses Search's send operator, which:

  • Pushes matching events back through Stream
  • Stream's routes process them (just like live data)
  • Events land in whatever destination you've configured
  • In your case: Tier 2 Lakehouse or a dedicated investigation dataset

This is the magic of the Cribl platform - Search and Stream work together seamlessly.

Step 5: Manual Search for More Control​

Want more control than the dashboard provides? You can run searches manually in Search.

Run Manual Forensic Search
  1. Click Search in the left navigation (leaving the dashboard)
  2. In the query box, enter: 
    dataset=default_logs or dataset="datatieringlogs" 
    | where clientip contains "130.253.37.97"
    | where business_impact IN ("critical", "security","user_experience")
    | project _time, clientip, status, request, user_agent, business_impact
    | sort by _time desc
    | limit 100
  3. Click Search

This manual query:

  • Searches the datatieringlogs dataset
  • Looks for the suspicious IP
  • Extracts structured fields
  • Filters to only critical/security events (ignores routine 200s)
  • Shows key fields in chronological order
  • Limits to 100 most recent events

Adding the Send Operator​

To actually export these events, just add | send to the end:

dataset=default_logs or dataset="datatieringlogs" 
|  where clientip contains "130.253.37.97"
| where business_impact IN ("critical", "security","user_experience")
| send

When you run this with | send:

  • Search pushes these events to Stream
  • Stream routes them based on your configured routes
  • They land in your investigation destination
  • You've exported only 47 relevant events, not 847 total matches

Result: Surgical precision. Export only what matters.

Common Forensic Search Patterns​

Here are patterns you can use with the dashboard or manually:

Pattern 2: Timeline of Disruption​

dataset="datatieringlogs"
| where clientip=="130.253.37.97"
| timestats span=5m count() by status

Visualizes attack intensity over time.

Pattern 3: Successful Access After Failures​

dataset="default_logs"
| summarize 
    failures = countif(status IN (401, 403, 404)),
    successes = countif(status == 200),
    all_requests = values(request)
    by clientip
| where failures > 5 AND successes > 0

Pattern 4: Add Other Indicators​

dataset="datatieringlogs" or dataset="default_logs" 
| where clientip IN ("130.253.37.97", "201.3.120.132")
| extend threat_label = "suspicious"
| summarize count() by clientip, user_agent, request, threat_label

Finds related suspicious activity beyond just one IP.

Customizing the Dashboard (Advanced)​

Want to modify the dashboard for your needs? Here's what you can change:

Edit Dashboard Queries
  1. From the dashboard view, click the Edit button (pencil icon)
  2. Click on a panel to see its query
  3. Modify the query as needed
  4. Click Save when done
  5. The dashboard now uses your custom logic

Common customizations:

Change default time range:

  • Edit the Time input default from "Last 7 days" to "Last 30 days"

Add more datasets:

  • Edit the Dataset selector to include more options
  • Or change the default to search dataset="cribl_search_sample"

Filter to specific event types:

  • Add a filter like | where sourcetype IN ("firewall", "auth_logs")
  • Narrows search to security-relevant data only

Auto-send high-risk matches:

  • Add logic that automatically sends critical events
  • For example: | where business_impact=="critical" | send

Real-World Investigation Example​

Let's walk through a complete investigation using the dashboard:

10:00 AM - Alert comes in: "Unusual traffic from 130.253.37.97"

10:01 AM - Open Interactive Forensic Dashboard, search for the IP

  • Dashboard shows: 847 events in web logs, 156 in network logs

10:02 AM - Click on web logs to drill down

  • See pattern: 50 failed auth attempts (status 401/403), then successful login
  • Followed by rapid requests to /product.screen

10:03 AM - Refine search to see exported data:

dataset="datatieringlogs"
| where clientip == "130.253.37.97" AND request contains "export"
| project _time, request, bytes, status

10:04 AM - Identify data exfiltration:

  • Single GET request downloaded 50MB of user data
  • Status 200 (successful)

10:05 AM - Send events to SIEM for incident response:

dataset="datatieringlogs"
| where clientip == "130.253.37.97"
| send

10:06 AM - SIEM receives 847 events for deep analysis instead of 1millions

  • Cost to cribl search 6 months of data: $
  • Total investigation time: 10-30 minutes

Traditional approach:

  • Export/Index all 6 months of web logs to SIEM first: $$$$
  • Wait 3-5 days for export to complete
  • Then search for the IP
  • Total investigation time: hours/days

Next: Query Optimization & Best Practices →