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 and the are determined automatically by the platform from what happened when the event ran. The and the are qualified afterwards, either by you or by a connector.
The execution status reports : 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.
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.
The event is currently being executed on the scope. It cannot be qualified yet and is not counted in the simulation results.
The event ran through to completion on the target. Its detection status is Unqualified until you or a connector qualifies it, and it is counted in the simulation results.
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.
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.
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.
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.
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.
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.
Complementary to an event's execution status, the exploitation status records — independent of whether the action was detected. It takes one of three values:
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.
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.
The action ran as intended but produced no offensive effect, often because a security solution (antivirus, EDR) blocked it. The attacker did not progress.
Each executed event carries one of four detection statuses:
Default status; no detection information has been provided yet.
The attack simulation was missed: no log and no alert.
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.
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. Any remediation applied by the security teams can be recorded in the reaction section.
Once an event is detected, its reaction status records whether a response was taken:
- — at least one response action (response strategy) has been declared on the event after detection.
- — no reaction was recorded after detection.
Severity flags the events that matter most to detect, on two levels:
- (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.
- (yellow) — less important to detect relative to other simulated attacks.