What is a cyber incident?¶
A cyber incident is an event - or connected series of events - that compromises, disrupts or credibly threatens systems, accounts or data. It may involve sophisticated malware, stolen credentials, an abused legitimate account, accidental exposure or insider misuse. The label identifies a problem to assess and manage; it does not identify the offender or explain every event.
Start with harm and affected assets¶
Confidentiality concerns unauthorised access to or disclosure of information. Integrity concerns unauthorised change or loss of trust in data or systems. Availability concerns whether people can use them when needed. One incident can affect all three.
Ransomware may make files unavailable, alter them and create concern that information was copied. An account takeover may expose messages without disrupting the service. An insider may use valid access to obtain data for an unauthorised purpose. Authorised access does not automatically mean legitimate activity.
The incident is not the alert. The alert is one system's signal; the ticket is the organisation's developing account; the source records and impact establish what occurred.
Alert, incident and offence are different propositions¶
A security alert is generated because activity matched a rule, model or intelligence source. It may be a true malicious event, benign administration, a blocked attempt or a misleading match. The underlying records show which activity caused it.
An incident ticket records reports, assessments, actions and decisions. It may combine automated events with analysts' interpretations and changing conclusions. Identifying exactly what material has been supplied prevents a screenshot, alert, ticket and raw log from being treated as interchangeable.
An offence may be suspected within the incident, but legal and personal responsibility require evidence beyond the organisation's severity label.
Incident records come from several observers¶
Identity systems record authentication and session events. Endpoints record processes, files and connections. Cloud or application audit records show account actions. Network tools observe traffic. Responders record decisions and changes. A user or customer describes the impact they experienced.
Several records agreeing on session IDs, hostnames, account IDs and times can establish a compelling sequence. They are not automatically independent: an alert and incident ticket may both derive from the same endpoint event. Good analysis identifies shared dependencies and genuine corroboration.
A live incident creates two urgent jobs¶
Continuing harm may require accounts to be disabled, systems isolated or services rebuilt. Those actions can terminate sessions, alter logs and remove volatile evidence. Preservation cannot become an instruction to leave people, data or operations exposed.
At the same time, volatile evidence and short-retention cloud records may disappear. The practical answer is coordinated action: preserve what can safely be preserved, contain what must be contained and record every change.
AL-88021.The response event is part of the history, not noise after the “real attack”. It may explain missing traffic, changed passwords, inaccessible machines or later recovery results.
Establishing the incident is not attributing the offender¶
A compromised account identifies the digital identity used. A source address identifies a connection. Malware may identify a family or technique. None automatically names the person controlling the activity.
This separation does not weaken the incident evidence. It allows attribution to be built properly through account history, session continuity, provider records, relevant-time connections, suspect devices, communications, benefit and conduct. Several independent sources converging on distinctive events can be strong circumstantial evidence even without one “hacker caught at the keyboard”.
Report conclusions at the right level¶
“Northway's systems recorded session SES-4C18 accessing the backup console before rapid file modification on FILE-03” states the sourced sequence.
“Nora hacked the network because her old username appears in an alert” collapses account use, cause, intent and human attribution. Those propositions may later become strong through provider and device evidence, but the alert label is not doing all that work.
For ransomware, a final assessment should distinguish encryption, disruption, attempted or completed data theft, negotiation and attribution. Encryption does not prove data was stolen, and a ransom note does not prove who caused the encryption.
