Blocked C2 beacon and a lost encrypted laptop: event, incident, or near miss?
A Norway-based online retailer (1,400 staff, 12 fulfilment sites) gets 14 SIEM alerts at 09:40: Windows hosts in the pick-and-pack VLAN attempting TLS sessions to an IP listed as Cobalt Strike command-and-control in the threat-intel feed. The egress proxy blocked every attempt; logs show no bytes returned beyond TLS negotiation failures. An analyst then finds a signed but revoked driver and a scheduled task created three days earlier. Separately, a regional sales manager reports his encrypted laptop left on a train. It has not checked in for 30 hours, a remote wipe is queued but unconfirmed, and he kept a local copy of a pipeline spreadsheet holding client contact data. The service desk has logged the laptop as 'lost property - IT asset' and the beacon as 'blocked, no action'. The CISO must decide what enters the incident register, what becomes a major incident, and how to explain both to the audit committee, which has asked why 'near misses' appear in the KPI pack at all.
1. Classify both situations using ISO/IEC 27035 terminology (information security event, information security incident, near miss) and state which additional facts would change each classification.
Read the worked answer
Terminology. An information security event is an identified occurrence of a system, service or network state indicating a possible breach of policy or control failure, or an unknown situation that may be relevant. An information security incident is a single or series of unwanted or unexpected events with a significant probability of compromising business operations and threatening information security. A near miss is an event that was prevented or had no consequence but could have.
Beacon. Already more than an event: a revoked driver plus a scheduled task means code executed on 14 hosts. The egress block is a control that worked on one channel; it is not eradication and does not remove persistence. On these facts I would open an incident on the 'significant probability' test - the criterion is potential, not realised, harm - but keep it below major until scope is known.
Laptop. An event until assessment shows otherwise. Deciding facts: full-disk encryption active with keys not stored on the device, wipe confirmed, whether the spreadsheet sat outside the approved data store, whether cached credentials or VPN tokens were present. Confidentiality risk drives this one, not availability.
What would change the classification. Beacon: evidence of lateral movement, valid-account use, or access to order and payment data - then major incident. Laptop: wipe unconfirmed and the file unencrypted - then incident, plus a separate personal-data-breach assessment, which is a legal judgement and not automatically the same as the security classification.
Near misses in the register. They belong there precisely because they test controls; the committee should see them separately, never netted into incident counts.
2. The service desk argues that because the proxy blocked the traffic there was no incident. Construct the counter-argument and specify the decision criteria and time limits you would apply.
Read the worked answer
Counter-argument. 'Blocked equals no incident' confuses a control outcome with an incident determination. The proxy blocked outbound TLS, but the adversary already had execution, persistence via a scheduled task, and a driver-loading capability. A blocked channel is one of several - DNS, email, USB or another port may not be blocked. The correct question is whether there is a significant probability of compromised operations, and 14 hosts with confirmed persistence meet that test.
Decision criteria (any single one triggers declaration):
- confirmed unauthorised code execution or persistence;
- use of valid accounts or credential material;
- more than one host, or traversal of a trust boundary;
- access, or plausible access, to regulated or payment data;
- attacker infrastructure still resolving or contactable;
- asset criticality, which pick-and-pack hosts adjacent to payment flows raise.
Time discipline. The assess-and-decide stage needs a clock, otherwise triage becomes the incident. I would set: acknowledge and route within 15 minutes; first triage decision recorded within 1 hour; scoping with a named incident manager within 4 hours; formal review at 24 hours. Record the decision and its reason in the register, so a later 'no incident' call is defensible rather than invisible.
Fix the taxonomy too. 'Blocked, no action' must not be a terminal state for any security-category ticket; make escalation to the security queue mandatory when a persistence indicator is present.
3. How should near misses and blocked attempts be represented in the audit committee KPI pack without inflating incident counts?
Read the worked answer
Three tiers, never one number. (1) Confirmed incidents by severity and business unit; (2) events under assessment, with the clock running; (3) near misses and prevented attempts. Report the conversion rate - near misses that later became incidents - because that is the control-effectiveness signal the committee actually needs.
Why this satisfies audit without inflation. Audit's real concern is completeness, not volume. A single 'incidents' KPI invites under-reporting from fear of a bad number, or inflation when every blocked scan is counted. Three tiers show both that reporting works and that the figures are comparable period to period.
Definitional rigour. Publish a one-page classification standard with worked examples: a blocked C2 beacon, an encrypted lost laptop, a phishing email reported but not clicked. Require reclassification to be recorded with the reason. Sample 20 tickets a quarter and have someone independent re-score them; report the disagreement rate. That is the assurance the KPI is real.
Narrative alongside the numbers. For each near miss above a threshold, state the control that worked and whether it will keep working - here, egress filtering plus EDR plus scheduled-task detection. The committee can then judge whether a blocked beacon is evidence of resilience or of luck. Avoid a composite 'security incident index'; it hides exactly the distinction you are trying to make.