At 02:14 on a Saturday, a clinic's EDR console flagged its main file server: more than 4,000 files renamed in under a minute, each with a new .lkd extension, and a file called README_RESTORE.txt appearing in folder after folder. An analyst at the clinic's managed security provider saw the alert seven minutes later. What happened over the next half hour, deciding whether this was real, how bad it was and who needed to know, is the identification phase.
On the CompTIA Security+ SY0-801 exam, identification sits under objective 4.7, which expects you to explain the activities in each phase of incident response. This lesson covers detection, triage and declaring an incident, internal and external advisories, and threat hunting, the proactive search for attackers that alerts didn't catch.
Identification turns an event into a declared incident
Not every alert is an incident. An event is any observable occurrence: a login, a file change, a blocked connection. An alert is an event that a tool has flagged as worth a look. An incident is an event or series of events that actually threatens or violates the organization's security policies or the confidentiality, integrity or availability of its systems and data. Identification is the work of moving from the first signal to a confident decision: this is an incident, it's this type, and it's this severe.
That decision matters because declaring an incident starts the rest of the plan. The incident commander takes charge, the right playbook opens, and the timeline that every later phase depends on begins. Under some laws, the date an organization became aware of a breach also starts a notification deadline, which is one more reason to record when each fact was learned. Declaring too slowly lets damage spread. Declaring everything burns out the team and teaches people to ignore the process.
Identification ends when the incident is confirmed, classified and handed to the people who will investigate and contain it. It doesn't try to work out how the attacker got in; that is the investigation phase, covered in the next lesson.
Detection comes from tools, people and outside parties
Most incidents are detected in one of three ways.
Security tools generate most alerts: EDR agents watching endpoint behavior, a SIEM correlating events across systems, intrusion detection systems, data loss prevention and email filters. Here is what the clinic's MSSP analyst saw:
02:14:07 EDR FS01 HIGH Ransomware behavior: 4,212 files renamed to *.lkd in 58 s
process=C:\ProgramData\svchst.exe user=CLINIC\svc_backup2
02:14:31 EDR FS01 HIGH README_RESTORE.txt written to 312 folders
02:15:02 SIEM CORR-114 HIGH Event 4698 (scheduled task created) "SysUpd" on 212 hosts,
source DC01
02:16:40 EDR WS-FD-07 HIGH Ransomware behavior blocked; process terminated
People are the second source. A nurse who reports a strange pop-up, a help desk ticket about files that won't open, or an administrator who notices an unfamiliar account can each start an incident. At the clinic, front-desk staff arriving at 6:30 a.m. found ransom notes on screens. By then the incident had been declared, but in many organizations a staff report is the first sign.
Outside parties are the third source: a partner who receives phishing from your domain, a researcher who finds your data exposed online, or law enforcement telling you that your network is talking to a known criminal server. Hearing about a compromise from outside often means the attacker has been inside for a while.
NIST's incident handling guidance also separates precursors from indicators. A precursor suggests an incident may happen, such as an advisory that a ransomware group is targeting clinics, or a burst of password guessing against your VPN. An indicator suggests an incident has happened or is happening, such as the mass file renames above. Precursors give you a chance to act before damage is done; indicators mean you are already responding.