Event statuses & severity
Reference for the statuses and the severity that qualify each simulated event
This page is the single reference for how BlackNoise qualifies events. The Kill Chain, the campaign Synthesis and the other result views all rely on these definitions. For how these values are turned into a score and a grade, see Scoring & grades .
An event carries four statuses. The execution status and the exploitation status are determined automatically by the platform from what happened when the event ran. The detection status is qualified afterwards, either by you or, when the campaign uses the Automatic mode, by BlackNoise from the data of a connector. The reaction status is always qualified by you.
Execution statuses
The execution status reports the outcome of the execution itself: whether the Attack Vector carried the adversary action out on the scope. It conditions how the rest of the event reads, since an event that did not run carries neither a detection nor an exploitation result.
Waiting
The event is queued, waiting to be executed by the Attack Vector. It cannot be qualified yet and is not counted in the simulation results.
Processing
The event is currently being executed on the scope. It cannot be qualified yet and is not counted in the simulation results.
Executed
The event ran through to completion on the target. Its detection status is
Unqualified until it is qualified, by you or, in Automatic mode, by BlackNoise from connector data. It is counted in the simulation results.
Executed with warning
The event ran on the target and generated activity, but part of its results could not be parsed, so not all of the information the event was expected to return was retrieved. The event can be qualified and counts towards the detection score.
%20copie.png?apiToken=eyJhbGciOiJIUzI1NiIsImtpZCI6IjIwMjMtMDUtMDQifQ.eyJzY29wZSI6Im5vdGUtZXhwb3J0IiwibmlkIjoiSV9xYm1zczJRbVNhRFkiLCJpYXQiOjE3OTMwOTEyMDcsImlzcyI6Imh0dHBzOi8vc2xpdGUuY29tIiwianRpIjoiUF9iR3I2OWcwTFd2UDEiLCJleHAiOjE3OTU2ODMyMDd9.YXdYW5KzytmuObmMrS2l9rroI_EL80pGmYjC4L0L5yU)
Executed without secrets
The event ran on the target but no secret could be retrieved. The following events of the scenario that depend on that secret cannot be executed on this target. It can be qualified and is counted in the simulation results.
Error
An error occurred during the execution of the event. The actions performed before the error may still have generated traces, so the event can be qualified and is counted in the simulation results.
Canceled
Execution was stopped by a user with the
Stop button. The event can be run again, or you can move on to the next one. It can be qualified and is counted in the simulation results.
Unexecuted
The event was not executed because the required technical conditions were not met — for example no session could be opened on the target, or a port needed by a brute-force event was not found open by the scan events. The reason is given alongside the status. The event cannot be qualified and is not counted in the simulation results.
Out of scope
The event does not apply to the scope defined for the campaign — for example an SSH-key session creation event when none of the System Targets uses SSH keys. The event cannot be qualified and is not counted in the simulation results.
Exploitation statuses
Complementary to an event's execution status, the exploitation status records the outcome of an adversary action from the attacker's standpoint — independent of whether the action was detected. It takes one of three values:
-
Not applicable
The action produces no exploitable result by nature. This is typical of reconnaissance actions (scans, discovery), whose goal is to gather information rather than exploit a weakness.
Exploited
The action produced the result the attacker intended: the targeted weakness is validated. This is the primary alert signal for the analyst, confirming a real exposure regardless of detection.
Contained
The action ran as intended but produced no offensive effect, often because a security solution (antivirus, EDR) blocked it. The attacker did not progress.
Detection statuses
Each executed event carries one of four detection statuses. You set the status yourself or, in Automatic mode, BlackNoise sets it from the data returned by the connector (see Connectors ):
Unqualified
Default status; no detection information has been provided yet. In Automatic mode, an event also stays
Unqualified when the connector returns neither a matching alert nor a trace of its execution.
Undetected
The attack simulation was missed: no log and no alert. In Automatic mode, BlackNoise does not set this status itself, because a missing result can come from the level of integration of the tool. You qualify the event as
Undetected yourself.
Logged
The security tools produced a technical trace (a log) for the simulated attack, but no alert was raised and no reaction was taken. To be valid, a Logged proof should indicate at least the source, the destination, the date & time, and if possible the type of action recorded. In Automatic mode, BlackNoise sets this status when the connector returns no alert but the execution of the event appears in the traces or telemetry of the tool. This depends on the level of integration of each connector and tool.
Alerted
The security tools identified the simulated attack and raised an alert or a notification. To be valid, an Alerted proof should indicate at least the source, the destination, the date & time, and the type of threat identified. In Automatic mode, BlackNoise sets this status when the connector returns an alert that matches the event. Any remediation applied by the security teams can be recorded in the reaction section.
Reaction statuses
Once an event is detected, its reaction status records whether a response was taken. You always enter it yourself, including in Automatic mode:
- Reacted — at least one response action (response strategy) has been declared on the event after detection.
- Ignored — no reaction was recorded after detection.
Severity
Severity flags the events that matter most to detect, on two levels:
- High (red) — highly critical behavior, given the noise it generates and the impact of the action. Prioritize detecting and reacting to these as fast as possible.
- Low (yellow) — less important to detect relative to other simulated attacks.