Skip to content

Cut alert volume

Cut the queue down to the alerts that matter.

Your detections aren't the problem. The volume they produce is. Classification, grouping, and enrichment turn a thousand alerts into a queue an analyst can actually finish.

Click through Alert Navigator in the Demo Center →

The situation

What this usually looks like

If more than two of these are true, the work below is the work you are already doing by hand.

  1. Analysts start the shift behind and end it further behind.

    Throughput is capped by reading speed rather than by judgement.

  2. The same event arrives as a dozen separate alerts from four tools.

    Twelve reads, one decision, and eleven of them thrown away.

  3. Nobody trusts the queue order, so everyone works from the top.

    Severity collapses into arrival order and the ranking stops meaning anything.

  4. Real incidents are found late, not because they were invisible but because they were buried.

    Detection time gets measured from when somebody reached it, not from when it fired.

The mechanism

See, decide, act, and then wait.

Four movements, in order. The fourth is the one that matters: nothing destructive happens without a person releasing it.

  1. 1

    See

    Every alert in one shape

    Alerts are read from S3 as Cribl Parquet, staged in a Redis queue, and normalised before anyone opens them. Whatever produced them, they arrive looking the same.

    • Amazon S3
    • Cribl Parquet
    • Redis queue
    • Any SIEM
  2. 2

    Decide

    Classified, with the reasoning attached

    An Isolation Forest model calls each alert a true or false positive and scores its confidence from 0 to 100. The features that drove the call are listed, and the alert is tagged with its MITRE ATT&CK technique and attack stage.

    • Isolation Forest
    • Confidence 0-100
    • MITRE ATT&CK
    • Feature breakdown
  3. 3

    Act

    A queue you can actually finish

    Confirmed threats open or update a Jira ticket. False positives are documented and closed with the determination attached. What reaches an analyst arrives with every address, domain, hash and account already enriched.

    • Jira
    • Create and close
    • Enriched on arrival
  4. 4

    Gate

    The classification stays yours to make

    Changing a classification opens a three-step gate: a reason, then the ticket action, then the confirmation. Every confirmation and override is captured as reinforcement signal, and the console tracks agreement, disagreement, and whether enough has accrued to retrain.

    • Reason mandatory
    • Analyst feedback loop
    • Drift watch

The gate

Where the volume goes

Every agent on the platform resolves to one of three outcomes. Alert Navigator's gate is the classification itself: nothing reaches a ticket without a person naming why.

Runs on its own

Auto-execute

High-confidence, well-understood classifications are actioned and documented without waiting for anyone.

The ruleA failure is flagged for retry, not silently dropped.

Waits for a person

Analyst gate

Changing a classification opens a guided three-step gate before anything reaches Jira.

The ruleA reason is mandatory. There is no way past it.

Logged only

Monitor

Low-risk signals are logged and watched without action.

The ruleReady to escalate if the behaviour changes.

Confidence colours the queue before you open anything: 70 and above reads green, 50 to 69 amber, below 50 red.

Who does the work

One agent owns this end to end.

You can turn one on and add the others later. A connector configured for one is available to the rest.

Also named in this outcome

Coming soon

Action Feedback

Closes the loop on security actions, capturing outcomes and feeding them back to tune detection and training.

Questions

The things people ask first.

  • Does it close alerts on its own?

    It closes what it's confident about and documents the determination on a Jira ticket, so a closure is a record, not a disappearance. Changing a classification always goes through the gate, where a reason is mandatory before the ticket action runs.

  • Can I see why it decided something?

    Every alert exposes the features that drove its classification, the confidence behind it, and the MITRE tactic it mapped to. The classification is checkable rather than asserted, which is what makes agreeing or overriding a one-click decision.

  • What happens to my overrides?

    They are reinforcement signal. The platform tracks decisions processed, model-analyst agreement, disagreement count, and whether enough disagreements have accrued to trigger a retrain, with a table of exactly where the model and your analysts diverged.

  • Which SIEM does it need?

    Any. Alerts are read from S3 as Cribl Parquet and normalised on the way in, so the source tool is a detail, not a dependency. Okta, AWS CloudTrail and the usual threat-intel feeds attach as enrichment.

  • How would we know it's working?

    Noise reduction is the headline measure, alongside mean time to triage and mean time to resolve. Model health carries accuracy, precision, recall and F1 with trend indicators, plus the training sources behind them.

The other outcomes