An alert in detail
What one security alert page shows: the facts, the score behind it factor by factor, what a live response would actually have done to the account, and a simulator for trying a change without saving one.
The alert, and where it stands
The chain of signals that fired, written out in one line, with the severity and the status beside it.
The facts
The client, the account, the rule that fired, when it was detected and last seen, and the score. A Ticket line appears here only when this alert has a ticket, and this one has none.
Elise Triage
Elise's own read of the alert, with Re-run Elise triage beside it. An alert the confidence engine scored but Elise has not read yet says Not yet triaged, as this one does.
Confidence breakdown, and the band it reached
Every factor that contributed to the score, in contribution order, with its weight. Positive weights push toward containment and negative ones push away, such as the network this org's own workforce regularly signs in from at minus 15. The highlighted row is the margin, the smallest factor whose removal alone would have dropped the score below its band. The last line names the band the score reached.
What a live response would have done, and the levers for asking what if
Armed-path verdict
The honest answer to one question: if this org had been armed Live when this alert arrived, would this alert have locked the account. It is worked out once, when the alert is recorded, and only read back here, so opening this page never runs it again. It applies the same blast radius cap and systemic cohort guards a real live run would, so a firing that looks severe can still read that it would not have locked. An alert recorded before this was built says the verdict is not available rather than guessing one.
The levers
One row for each factor that pushed the score up. The checkbox approves the factor and takes its weight out of the sum, and the box on the right holds a different weight to try instead of the real one.
The band threshold
Moves the reached band's own threshold, for the simulation only, and Apply runs it.
Current and Simulated
The band and score today's settings give this alert, next to the simulated pair, with a sentence naming the move. With no lever touched the two match, and the line underneath says the combination still reaches the original band.
Why it works this way
Nothing in the What-if simulator is saved. To make a weight or a threshold permanent, open CyberSentry, then Response Rules, then the Confidence Engine, and edit its thresholds there.
The verdict and the score answer different questions. The score says how sure the engine is; the verdict says what a live response would actually have done to the account, guards and all.
Elise's triage pass never opens a ticket by itself. A ticket comes from an armed response rule or from the confidence engine's own bands, so an instance with neither armed opens none, and this page carries no button to open one by hand.
Questions this page answers
What does "Armed-path verdict" mean?
The honest answer to "if this org had been armed Live when this alert arrived, would this specific alert actually have locked the account?" It is worked out once, when the alert is recorded, and only read back here - opening this page never re-runs it. It reflects the SAME blast-radius cap and systemic-cohort guards a real Live execution would apply - so a firing that looks severe can still show "would not lock" if, say, too many accounts had already triggered the same guard that hour, or a shared signal across several accounts read as one legitimate mass event across the organization rather than a single-account incident. Alerts recorded before this feature shipped show "not available" rather than a guessed value.
Was this helpful?