SETUP GUIDES

Connect your data source

Wazuh, Splunk, and Microsoft Sentinel all connect to Strix the same way — a secure webhook. Pick your tool below for full, step-by-step instructions, field mappings, and troubleshooting.

Wazuh logoSplunk logoMicrosoft Sentinel logo

How connecting works

The same three steps for every source. The only difference is how each tool is told to send.

1 · Connect

Add the source in Strix and copy its one-time webhook URL — a unique, tokenised endpoint scoped to your org.

2 · Send

Point the tool at that URL. Every alert it fires is POSTed to Strix as it happens — no polling, no agent to host.

3 · Verify

Run Test Connection, then watch alerts land in the Inbox, score, and open cases automatically.

JiraSlackMicrosoft Teams
Wazuh logo

Connect Wazuh

Forward agent detections from your Wazuh manager into Strix.

~15 min Manager integration → HTTPS POST Manager access

Before you start

  • A running Wazuh manager (4.x) you can edit and restart (root/sudo on the manager host).
  • Agents already enrolled and reporting detections to that manager.
  • Outbound HTTPS (443) allowed from the manager host to api.redswordsecurity.com.

Step by step

  1. 1
    Connect Wazuh in Strix

    In Strix, open Integrations → Wazuh → Configure → Connect. Strix reveals a webhook URL with an embedded token — copy it now, it is shown only once. You can rotate or disconnect the token anytime from the same screen.

    https://api.redswordsecurity.com/webhooks/wazuh/<YOUR_TOKEN>
  2. 2
    Add a custom integration to the manager

    On the manager host, add an integration block to /var/ossec/etc/ossec.conf. hook_url is your Strix webhook; alert_format json sends the full alert. Optionally add <level>7</level> to forward only rule level ≥ 7 and keep low-value noise off the wire.

    <integration>
      <name>custom-strix</name>
      <hook_url>https://api.redswordsecurity.com/webhooks/wazuh/<YOUR_TOKEN></hook_url>
      <alert_format>json</alert_format>
      <!-- optional: only forward level >= 7 -->
      <level>7</level>
    </integration>
  3. 3
    Restart the manager

    Restart Wazuh so it loads the new integration. From then on the manager POSTs each matching alert to Strix as it fires — no polling, no extra agent.

    systemctl restart wazuh-manager
  4. 4
    Confirm the manager can reach Strix

    From the manager host, a quick reachability check rules out egress/firewall issues before you rely on live alerts. A 404/401 here means the host reaches Strix but the token is wrong; a timeout means egress is blocked.

    curl -sS -o /dev/null -w "%{http_code}\n" \
      https://api.redswordsecurity.com/webhooks/wazuh/<YOUR_TOKEN>
  5. 5
    Run Test Connection & admit the host

    Back in Strix, click Test Connection on the Wazuh card — Strix runs a representative sample through the same normalizer a live alert uses and flags any missing fields. Then, under Integrations → SIEM Hosts, Admit the reporting host if it shows as Pending.

Field mapping

Send as many of these as your data allows — the more you provide, the better Strix scores, groups, and enriches each alert.

Strix field
Wazuh source field
Host / Agent
agent.name
Rule ID + Severity
rule.id, rule.level
Title
rule.description
MITRE technique / tactic
rule.mitre.id, rule.mitre.tactic
User
data.srcuser / data.win.eventdata.targetUserName
Source IP
data.srcip
Process / File
data.process, data.file

You're connected when…

  • Integrations → Wazuh shows Connected with a rising Received count and a recent Last alert.
  • The reporting host appears under SIEM Hosts / Assets with a Wazuh source badge.
  • A test detection lands in the Alert Inbox with its rule, level, and MITRE mapping.
  • A rule level ≥ 12 detection auto-opens a Critical case with a linked Jira ticket.

Troubleshooting

Nothing arrives
Manager egress is blocked or the hook_url is wrong. Re-run the curl check; a timeout = firewall, a 404 = bad token/URL.
401 / 404 in the manager logs
The token was rotated or mistyped — re-copy it from Integrations → Wazuh and update ossec.conf.
Alerts arrive but no case opens
Only rule level ≥ 12 (critical) auto-opens a case; lower levels stay in the inbox for triage.
Host stuck as Pending
SIEM hosts are admitted, not auto-trusted. Admit it under Integrations → SIEM Hosts.
ossec.conf won't load
Each <integration> <name> must be unique and the block must sit inside <ossec_config>. Check /var/ossec/logs/ossec.log after restart.

What happens after you connect

Once alerts flow, every source runs the exact same pipeline — the tool you chose no longer matters. Here is the full path an alert takes.

  1. Ingest & normalize

    The alert hits your tokenised webhook and is normalized into one common envelope — the same shape whether it came from Wazuh, Splunk, or Sentinel.

  2. Score

    A multi-stage risk engine scores it. SIEM alerts get a derived, stable rule id so two unrelated detections are never mistaken for duplicates and quietly suppressed.

  3. Inbox & grouping

    It appears in a unified Alert Inbox, grouped by signature so repeat noise collapses into one line instead of flooding the queue.

  4. Auto-case + Jira

    A critical alert opens a Case, seeds remediation tasks from the alert's recommended actions, and creates a linked Jira ticket with the full analysis.

  5. SLA clock

    The case runs a staged SLA timeline so acknowledge / remediate / verify deadlines are tracked from the moment it opens.

  6. Two-way Jira sync

    Status, assignee, comments, and attachments sync both directions — moving the ticket to Done pushes the case to awaiting-verification; a Jira attachment marks it Verified.

  7. Recurrence & verify

    A repeat of the same detection folds into the open case instead of opening a second one. Verification is evidence-gated, and the case auto-closes once verified.

One-time secret

The webhook URL is revealed once and carries a per-org token. Treat the whole URL like a password and store it where your tool config lives.

Rotate or revoke anytime

Rotating issues a fresh token and instantly invalidates the old one; disconnecting stops ingestion for that source. Each source is independent.

Admitted hosts only

SIEM-reported hosts must be admitted before they enter your asset inventory, so a spoofed or noisy hostname can't slip in silently.

Frequently asked

No. All three sources push alerts to Strix over an outbound HTTPS webhook. There is nothing for Strix to poll and no agent for you to host — you configure your existing tool to send.

Ready to connect? Open Integrations in your Strix workspace.

Go to Integrations

Not sure which source fits? We'll help you connect.

Book Demo