SIEM Forwarding Quickstart

Set up SIEM forwarding end to end — enable a saved search, install the Event Forwarder, and verify events reach your SIEM.

This guide walks you through the full SIEM forwarding setup: enabling forwarding on a saved search, installing the Event Forwarder, and confirming that events are flowing to your destination.

Prerequisites

• Spyderbat Nano Agents deployed and healthy on the hosts you want to monitor

• org:ManageSiemForwarding permission (contact your org admin if you don't have it)

• A destination ready to receive events: a SIEM, Splunk instance, webhook endpoint, or a Linux host with disk space for log files

Step 1: Enable SIEM forwarding on a saved query

The Event Forwarder only delivers records that a saved search has already selected for forwarding. Complete this step first — skipping it means the forwarder has nothing to deliver.

If you don't have a saved search yet, create one first. Two common starting points:

• Forward targeted events (recommended): create a query scoped to what you actually care about — for example, schema model_spydertrace with filter score > 50 for high-scoring traces, or schema event_redflag with filter severity = "high" for high-severity flags only.

• Forward everything (use with caution — high volume): use filter * to match all records in a schema. Start with model_spydertrace to get behavioral traces, or event_redflag to get all security flags.

Then enable the SIEM Forwarding toggle on at least one saved search. See SIEM Forwarding — Enable forwarding on a saved query for detailed instructions.

To confirm forwarding is enabled, open Saved Searches: expand the Search icon in the sidebar, then click Saved Searches. Scroll right in the table to the SIEM Forwarding column — it should show a checkmark (✓) for your query. (The column may be off-screen at standard viewport widths.) Alternatively, click the SIEM Forwarding filter button at the top of the table to show only SIEM-enabled queries.

Step 2: Install the Event Forwarder

Choose your deployment method:

Kubernetes: Follow the Helm Chart guide.

Linux: Follow the Traditional Installer guide.

Both guides require these two values from your Spyderbat console:

spyderbat_org_uid: YOUR-ORG-UID
spyderbat_secret_api_key: YOUR-API-KEY

Your org UID appears in the URL of any org-level page (for example, the Dashboard). Navigate to such a page first — the API Keys page (/app/user/apikey) does not include the org UID in its URL. To generate an API key, see How to Create and Use a Spyderbat API Key.

A wrong org UID produces zero events with no error message. If your API key has access to multiple orgs, double-check that you're using the UID for the org where you enabled SIEM forwarding.

Create a dedicated service account for the API key rather than using a personal account. API keys can expire — check your key's expiration date and rotate before it lapses to avoid a forwarding outage.

Step 3: Verify events are flowing

Linux:

sudo tail -f /opt/spyderbat-events/var/log/spyderbat_events.log

You should see ndjson records appearing within a minute or two of activity that matches your saved query. Each record is one JSON object per line.

Kubernetes:

kubectl logs -f statefulset.apps/sb-forwarder-event-forwarder -n spyderbat

The forwarder logs status as JSON. Look for lines where the "message" field reports new record counts:

{"schema":"event_forwarder:meta:1.0.0","message":"5 new records (0 invalid, 5 logged)",...}

A log that shows the forwarder running but reports zero new records usually means no activity is currently matching the saved search — not a forwarder problem. Run the saved search manually from the Search page to confirm it returns results.

Troubleshooting

No events after several minutes:

1. Check that SIEM forwarding is enabled on at least one saved search. Open Saved Searches (expand the Search icon in the sidebar → Saved Searches) and scroll right to the SIEM Forwarding column — it should show a checkmark (✓). Alternatively, use the SIEM Forwarding filter button at the top of the table to show only SIEM-enabled queries.

2. Run the saved search manually from the Search page. If it returns no results, no activity matches — adjust the query.

3. Confirm the forwarder is running. On Linux: journalctl -fu spyderbat-event-forwarder.service. On Kubernetes: check the pod logs above.

4. Verify credentials: a wrong org UID silently produces zero events (no error), while an invalid API key causes authentication errors in the forwarder logs.

Service fails to start on Linux (crash loop):

If the forwarder crashes repeatedly on startup, check the logs for a DNS or URL error:

sudo journalctl -u spyderbat-event-forwarder.service --no-pager -n 20

A common cause is an incorrectly formatted api_host — the value must be a hostname only, without a scheme (correct: api.example.com, not https://api.example.com). After fixing the config, clear the failed state before restarting:

sudo systemctl reset-failed spyderbat-event-forwarder.service
sudo systemctl start spyderbat-event-forwarder.service

Duplicate events:

Run only one Event Forwarder instance per organization. Multiple instances poll the same API endpoint independently — each one receives and delivers the full event stream, causing duplicates in your SIEM.

Events stopped flowing after working previously:

API keys can expire. Check the forwarder logs for authentication errors, then generate a new key and update the config.

Related pages

• SIEM Forwarding — full architecture and reference

• Spyderbat Event Forwarder — detailed forwarder reference

• Panther Webhook Configuration

• Saved Searches