Episode 95 — Identification and Investigation: Detection, Advisories, Threat Hunting, Forensics, and Chain of Custody (4.7)
In this episode, we look at how security teams identify and investigate incidents, starting with the first signs that something may be wrong and moving into the careful work of understanding what happened. Identification is the phase where a team decides whether suspicious activity might be a real incident. Investigation is the phase where the team gathers evidence, builds a timeline, confirms scope, and starts separating assumptions from facts. This work can begin with an alert from a monitoring tool, an advisory about a new threat, a user report, a threat hunting discovery, or forensic evidence from a system. The process matters because a rushed conclusion can lead to the wrong response, while a delayed response can give an attacker more time. Good identification and investigation help the organization act with enough speed to reduce harm and enough care to avoid making the situation worse.
Before we continue, a quick note. This audio course is part of our companion study series. The first book is a detailed study guide that explains the exam and helps you prepare for it with confidence. The second is a Kindle-only eBook with one thousand flashcards you can use on your mobile device or Kindle for quick review. You can find both at Cyber Author dot me in the Bare Metal Study Guides series.
Detection is often the first doorway into incident identification. A detection may come from a Security Information and Event Management (S I E M) platform, an endpoint tool, a cloud alert, an identity system, a firewall, a data protection tool, or a user who reports something suspicious. The detection itself does not prove that an incident has occurred. It is a signal that deserves review. A failed login alert might be harmless if someone mistyped a password. The same alert may be more concerning if it appears across many accounts or is followed by a successful login from a strange location. Security teams look at the detection, the affected system, the user involved, the time of activity, and the surrounding events. The goal is to decide whether the signal is noise, a policy issue, a technical problem, or a possible security incident.
Alerts become more useful when they are connected to context. An alert about unusual file access means more when the team knows whether the files are sensitive, whether the user normally works with them, and whether similar access happened before. An alert about an administrative change means more when the team knows who approved the change, what system was affected, and whether the action happened during a planned maintenance window. Context prevents the team from treating every alert as equally serious. It also prevents the team from dismissing something important just because the first signal looked small. Many incidents begin with ordinary-looking events that only become meaningful when combined. A strong investigator learns to ask what came before, what came after, what else changed, and whether the activity fits the normal behavior of the account, device, or system.
Advisories are another source of incident identification. An advisory is a notice that provides information about a vulnerability, threat campaign, vendor issue, attack method, or security update. Advisories may come from vendors, government sources, industry groups, information sharing communities, or internal security teams. They help organizations understand risks that may not have triggered an internal alert yet. For example, an advisory may describe active exploitation of a product the organization uses. That does not automatically mean the organization is compromised, but it does mean the team should check exposure, patch status, logs, and related activity. Advisories turn outside information into internal questions. Do we use the affected technology? Is it exposed to the internet? Are there signs of exploitation? Do we need to patch, monitor, isolate, or notify system owners?
Advisories are useful only when they are translated into action. A team can receive many notices every week, and not all of them apply to the environment. The investigation starts by connecting the advisory to the asset inventory, vulnerability data, configuration records, and monitoring sources. If the advisory describes a weakness in a web server, the team needs to know whether any web servers in the organization match the affected versions. If the advisory includes Indicators of Compromise (I O C), the team may search logs, endpoint data, network records, or file systems for matching signs. An I O C might include a file hash, domain name, Internet Protocol (I P) address, registry change, process name, or behavior pattern. The value is not in collecting advisories. The value is in using them to focus investigation and reduce uncertainty.
Threat hunting is a more proactive way to identify possible incidents. Instead of waiting for an alert, a hunter starts with a question or hypothesis and searches for evidence. The question might be whether attackers are using stolen credentials, whether a certain malware behavior appears in the environment, or whether administrative tools are being abused in unusual ways. Threat hunting matters because not every attack triggers a clean alert. Some attackers use legitimate tools, valid accounts, and quiet techniques that blend into normal activity. A hunter looks for patterns that may have slipped past automated rules. This requires curiosity, knowledge of the environment, and a careful approach to evidence. Threat hunting does not assume that a breach has definitely happened. It asks whether the data contains signs that deserve a closer look.
A threat hunt may begin with a known technique, a recent advisory, a suspicious trend, or a gap in current detection. For example, a team might search for accounts that sign in from unusual locations and then access systems they have never used before. Another hunt might look for servers making outbound connections to rare external destinations. Another might review administrative actions that happened outside normal work hours. The hunter is not randomly browsing logs. The hunt has a purpose, a data source, and a way to decide what findings matter. If suspicious activity is found, the hunt may become a formal investigation. If nothing suspicious is found, the hunt may still improve security by revealing visibility gaps, weak baselines, missing logs, or places where detection rules should be improved.
Digital forensics is the careful collection and analysis of digital evidence. It may involve computers, servers, mobile devices, cloud resources, logs, memory, storage, applications, or network data. The purpose is to understand what happened in a way that is accurate, repeatable, and defensible. Forensics can help answer questions such as when the activity started, what account was used, what files were touched, what processes ran, what connections were made, and whether data may have been accessed or changed. Forensic work requires care because the act of investigation can accidentally change evidence. Opening a file, restarting a system, running tools, or changing settings may alter timestamps or overwrite useful data. The investigator has to balance the need to learn quickly with the need to preserve evidence properly.
Evidence preservation means protecting information so it remains trustworthy during and after the investigation. This can include preserving logs, copying disk data, capturing memory, exporting cloud records, saving alerts, documenting screenshots, and recording who handled each item. Preservation matters because evidence may be needed for internal decisions, disciplinary action, insurance review, legal proceedings, regulatory reporting, or lessons learned. Even when an incident never goes to court, good preservation helps the organization avoid confusion. If evidence is changed, deleted, or poorly documented, people may argue about what really happened. Preserving evidence does not mean collecting everything without thought. The team should collect what is relevant, protect it from tampering, and document how it was obtained. The more serious the incident, the more important careful evidence handling becomes.
Chain of custody is the documented record of how evidence was collected, handled, transferred, stored, and analyzed. It helps show that the evidence is the same evidence originally collected and that it was not changed or handled carelessly. A chain of custody record usually identifies what the evidence is, where it came from, who collected it, when it was collected, where it was stored, who accessed it, and why it was transferred or examined. This may sound formal, but the idea is straightforward. If evidence matters, the organization needs to know where it has been and who touched it. Without chain of custody, evidence can lose credibility. A security team may still learn from it, but it may be harder to rely on it for official decisions or legal processes.
Investigation also depends on building a timeline. A timeline places events in order so the team can understand the sequence of activity. The timeline may include the first suspicious login, the first alert, the first file access, a privilege change, a network connection, a malware detection, a user report, a containment action, and recovery steps. Timelines help distinguish cause from coincidence. If a file was changed before a suspicious login, that login may not explain the change. If a new account was created minutes after a privileged credential was used, that relationship may be important. Accurate time settings are critical because logs from different systems need to line up. When clocks are wrong, the story becomes harder to trust. A clear timeline helps the team communicate facts without guessing.
Scope is another major investigation question. Scope means how far the incident reached. The team needs to identify which accounts, systems, data, applications, networks, and users may be affected. A malware alert on one endpoint may be isolated, or it may be one sign of a wider compromise. A suspicious login may involve one account, or it may indicate that several accounts were phished. A vulnerable server may show no exploitation, or it may have been used as a starting point to reach other systems. Investigators use logs, alerts, endpoint data, network records, identity events, and forensic evidence to expand or narrow scope. Correct scope matters because containment and recovery decisions depend on it. If the team underestimates scope, parts of the incident may remain active. If the team overestimates scope, it may cause unnecessary disruption.
Documentation is part of the investigation from the beginning, not something added later when everyone is tired. Investigators should record what was observed, what was collected, what actions were taken, who made decisions, and why certain conclusions were reached. Clear notes help the team avoid repeating work, explain decisions to leadership, and support later reporting. Documentation also helps separate facts from assumptions. A fact might be that a login occurred from a certain address at a certain time. An assumption might be that the login was malicious. The investigation should make those differences clear. Good documentation is especially valuable when the incident lasts across shifts or involves many teams. It lets the next person understand the current state without relying on memory or informal conversation.
At the Security Plus level, you should understand the relationship between identification, investigation, and evidence handling. Detection gives the team a starting signal. Advisories bring outside threat and vulnerability information into the organization’s review process. Threat hunting proactively searches for suspicious behavior that may not have produced an alert. Forensics helps the team collect and analyze digital evidence in a careful way. Evidence preservation protects the trustworthiness of what was found. Chain of custody documents who handled evidence and how it was controlled. These pieces work together because incident response depends on good information. The team needs enough evidence to understand what happened, enough discipline to protect that evidence, and enough judgment to decide what action is appropriate based on the facts.
The main takeaway is that identification and investigation are about turning uncertain signals into reliable understanding. A detection may point to suspicious activity, but it needs context. An advisory may describe a serious threat, but the team must determine whether it affects the organization. A threat hunt may reveal hidden behavior, but the findings need validation. Forensics can uncover what happened, but evidence must be collected and protected carefully. Chain of custody keeps important evidence credible by documenting its handling from collection through analysis and storage. A strong investigation does not jump to conclusions, ignore weak signals, or treat evidence casually. It moves carefully from alert, to context, to evidence, to timeline, to scope, to action. That discipline helps the organization respond faster, explain decisions more clearly, and learn from the incident after the immediate pressure has passed.
