WORKFLOWS

Triage and response, automated

Once an alert arrives, Strix takes it the rest of the way — scoring it, grouping it, opening a case, raising a Jira ticket, running the SLA clock, and closing the loop only when the fix is proven. Here's exactly what happens, stage by stage.

The full path an alert takes

The same pipeline runs for every source — the tool the alert came from no longer matters once it's ingested.

  1. 1

    Ingest & normalize

    An alert hits your tokenised webhook and is normalized into one common envelope — the same shape whether it came from Wazuh, Splunk, or Sentinel. Every downstream stage operates on this envelope, not the raw source format.

  2. 2

    Score

    A multi-stage risk engine scores the alert on severity, frequency, correlation, timing, and duplicate suppression. The score decides whether it's actionable or noise — and SIEM alerts get a derived, stable rule id so two unrelated detections are never mistaken for duplicates and quietly suppressed.

  3. 3

    Inbox & grouping

    It lands in a unified Alert Inbox, grouped by signature so repeat noise collapses into one line instead of flooding the queue. You triage groups, not thousands of near-identical events.

  4. 4

    Auto-case + Jira

    A critical alert opens a Case automatically — seeded with remediation tasks from the alert's recommended actions — and creates a linked Jira ticket carrying the full analysis. Non-critical alerts stay in the inbox for manual triage.

  5. 5

    SLA clock

    The case runs a staged SLA timeline the moment it opens, so acknowledge, remediate, and verify deadlines are tracked and visible — no side spreadsheet of who owes what by when.

  6. 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 comment lands on the case timeline; a Jira assignee sets the case assignee.

  7. 7

    Recurrence & verify

    A repeat of the same detection folds into the open case and restarts its clock instead of opening a second one. Verification is evidence-gated — the case only moves to Verified when proof of the fix is attached.

  8. 8

    Auto-close

    Once a case is Verified it auto-closes after a short grace window, so resolved work clears itself out of the board without a manual final click.

When does a case open?

Cases open automatically only for critical detections, so your board stays a list of things that genuinely need action — not a mirror of every alert.

Source
Critical trigger
Result
Wazuh
Rule level ≥ 12
Auto-opens a critical case + Jira ticket
Splunk
severity / urgency = critical (or High)
Auto-opens a critical case + Jira ticket
Microsoft Sentinel
AlertSeverity = High
Auto-opens a critical case + Jira ticket
Any source
Below the critical bar
Stays in the Inbox for manual triage — open a case by hand anytime
SCORING ENGINE

How risk is scored

Every alert runs through a multi-stage risk engine before it reaches you. The stages stack into one score that decides whether an alert is actionable or filed as noise — so a real threat rises and a routine event settles.

SIEM alerts are given a stable, derived rule id so two unrelated detections can never be treated as duplicates and quietly suppressed together.

  1. 1

    Base severity

    The alert's own severity sets the starting score — Wazuh rule level, or the High/Medium/Low/critical priority from Splunk and Sentinel.

  2. 2

    Frequency

    Many of the same detection inside a short window escalates the score — a burst is more urgent than a one-off.

  3. 3

    Correlation

    Related detections firing close together on the same asset raise each other, surfacing multi-step activity a single alert would hide.

  4. 4

    Timing

    Off-hours activity is weighted differently from business-hours noise — a 3 a.m. detection reads differently from the same event at midday.

  5. 5

    Duplicate suppression

    Genuine duplicates inside the dedup window are collapsed so the same event scored twice doesn't double-count — using a stable signature so unrelated alerts are never wrongly merged.

The SLA clock

Every case runs a three-stage timeline from the moment it opens, each with its own deadline based on severity. You always know what's owed and by when.

Stage 1

Acknowledge

The first clock — how long until someone owns the case. Starts the instant the case opens.

Stage 2

Remediate

Time to work the remediation tasks and push the fix. Tracked against the case's severity-based target.

Stage 3

Verify

Time to attach evidence and confirm the fix held. The case can't be verified without proof.

Two-way Jira sync

Connect Jira and cases mirror your tickets both directions — your team works where they already live, and the case stays in step. Here's how the two map.

In Jira
In Strix
Ticket created
Linked automatically when the case opens (or via Create Jira Ticket)
Moved to In Progress
Case reflects work has started
Moved to Done
Case → awaiting verification
Assignee changed
Case assignee updated to match
Comment added
Comment appears on the case timeline
Attachment added
Treated as evidence → case → Verified
Inbound sync (Jira → Strix) is driven by a per-org Jira Automation rule pointed at your case-tracking webhook. Set it up under Settings → Jira. Outbound (Strix → Jira) needs no configuration beyond connecting Jira.

Frequently asked

No. Scoring, inbox grouping, auto-cases, and the SLA clock run out of the box on every connected source. The only optional piece is Jira — connect it and the two-way sync turns on automatically for new cases.

Connect a source and watch the whole pipeline run on your first critical alert.

See the automation run end to end on your own alerts.

Book Demo