Certified: The GIAC GCLD Audio Course

In this episode, we focus on evidence preservation, because evidence discipline is what separates a controlled investigation from a story built on guesses. When a cloud incident happens, the environment is dynamic, logs can roll over, resources can be recreated, and responders can unintentionally erase the very signals they need. Reliable evidence supports accurate decisions in the moment, such as what to contain, what to remediate, and what to communicate to leadership. Defensible evidence supports the follow-on needs that often appear later, including audits, regulatory questions, customer inquiries, and internal accountability. Evidence is not just for legal teams. It is for engineers and security professionals who want to know what happened, prove what happened, and prevent it from happening again. The exam angle is straightforward: scenario questions often reward the candidate who preserves and validates evidence before taking irreversible actions, because that is how real incidents are solved.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Start by defining evidence sources across identity, the control plane, and data, because cloud investigations are rarely limited to one log stream. Identity evidence includes authentication events, token issuance, role assumption records, privileged group membership changes, and access key usage. Control plane evidence includes API calls that create, modify, or delete resources, policy changes, network rule modifications, and administrative actions that affect logging and security posture. Data evidence includes access logs for storage and databases, object reads and writes, exports, snapshot activity, and indications of bulk access or exfiltration. You want to think of evidence as a set of narratives that must align. Identity answers who acted. Control plane answers what was changed. Data access answers what was touched or taken. When those narratives match, your confidence increases. When they diverge, you have a clue that either telemetry is missing or a compromise path is not yet understood.

Evidence quality improves dramatically when you capture identifiers consistently, because cloud environments include many similar resources and many regions. Capturing timestamps precisely matters because you will be correlating events across multiple systems, and small time discrepancies can change conclusions. Regions matter because activity in an unexpected region is often a strong anomaly, and resource behavior can differ by region. Account IDs and tenant identifiers matter because they define the administrative boundary where actions occurred. Resource identifiers matter because names are not always unique, and resources can be recreated with similar names after deletion. If you capture these details early, you make later correlation possible. In practice, a strong evidence record includes the exact time window, the region, the account context, and the specific resource IDs involved, along with the identity that performed the actions. That is how you avoid confusing two similar assets and drawing the wrong conclusion.

When exporting logs, do it carefully while preserving original retention settings, because the export process itself can create risk if mishandled. Logs are often configured with retention policies that keep them for a defined period, and responders sometimes change those settings during an incident without realizing the side effects. Increasing retention can be helpful, but changing settings may also trigger unexpected storage behavior, indexing changes, or cost spikes that cause later rollbacks. Export should be treated as copying evidence, not altering evidence. You want to retrieve the records you need while ensuring the original log pipeline continues to function normally. If you must adjust retention, do it deliberately and document it, so the reason is clear later. Also remember that exporting is not enough if the export destination is not protected. Evidence stored in a location that an attacker can modify is not defensible evidence. The goal is to preserve integrity of both the source and the exported copy.

Snapshot configurations before changing policies or network rules, because configuration state is often the key to understanding why an attack succeeded. If you change a policy first and then try to explain what was wrong with the original, you may have lost the proof. Capturing configuration snapshots gives you a before picture that supports analysis and accountability. This includes identity policies, role assignments, trust relationships, network security rules, routing tables, storage access settings, and logging configurations. Configuration is evidence because it defines what was possible at the time of the incident. An attacker might have succeeded because a policy allowed broad access or because a network rule exposed a service. Without the original state, you are left trying to reconstruct it from memory or partial logs. A disciplined approach is to snapshot first, then change. This can feel slow during containment pressure, but even a quick snapshot can preserve essential context for later investigation.

Preserving disk and memory artifacts can also be valuable when feasible and safe, because cloud incidents sometimes involve compromised workloads where local traces exist. Disk artifacts can include malicious binaries, altered configuration files, persistence mechanisms, and local logs that are not shipped to centralized logging. Memory artifacts can include running processes, injected code, and active network connections that may not be visible elsewhere. Feasibility matters because you may not always be able to capture memory safely, and doing so can require specialized access and careful handling. Safety matters because touching a compromised system can alert the attacker or change system state in ways that reduce evidence value. The right mindset is to preserve what you can without increasing risk, and to prioritize artifacts that answer key questions, such as what executed, how it executed, and what credentials were present. Even when you cannot capture everything, a deliberate decision about what to preserve is better than a rushed attempt that destroys evidence or creates downtime.

Documentation is part of evidence, and you should document actions taken during response with clear justifications. In a cloud incident, responders change configurations, revoke access, isolate resources, and rotate secrets. Those actions are necessary, but they also alter the environment, which means they can confuse later analysis if not recorded. A good record includes what was done, who did it, when it was done, and why it was done, tied to the containment goal at the time. This is not paperwork for its own sake. It is how you prevent the team from arguing later about whether an action was correct, and it is how you explain to stakeholders why a business-impacting choice was made. Clear justifications also help you improve the playbook. If you can see which actions worked and which actions created friction, you can refine response procedures. In investigations, the actions of responders can look like attacker actions if not documented, so clarity protects both accuracy and trust.

Chain of custody matters even in cloud, because exported records and snapshots must be trustworthy if they are used for serious decision-making. Chain of custody is the ability to show that evidence was collected, stored, and handled in a way that prevents tampering and supports integrity. In cloud terms, this means controlling who can access exported logs and snapshots, recording access to them, and storing them in a way that is difficult to alter after the fact. You want to know when evidence was collected, by whom, where it was stored, and whether it was copied or accessed later. This becomes especially important when incidents involve insider risk or when external parties may request proof of what happened. Without chain of custody discipline, your evidence can be challenged, and you may lose confidence in your conclusions. Even if you never go to court, a defensible evidence process improves internal credibility and reduces the risk of incorrect remediation.

A practical exercise is writing a short evidence note for one alert, because this builds the habit of capturing the essentials under time pressure. An evidence note should be concise and structured around the critical details that enable correlation later. You want to capture the time window of the alert, the identity involved, the resource affected, the region and account context, and what the alert indicates occurred. You also want to capture immediate supporting records, such as the relevant log entries, configuration snapshots, and any correlated events that occurred shortly before or after. The note should distinguish between facts and hypotheses. Facts are what the logs show. Hypotheses are what you think might be happening. That distinction prevents confirmation bias and helps teams investigate objectively. Over time, these short notes become an incident timeline, and timelines are one of the most valuable investigation artifacts.

A common pitfall is overwriting logs because of misconfigured rotation policies, especially when organizations have not thought through retention for investigations. Logs can be overwritten when retention is too short, when storage limits cause rollover, or when pipelines fail and events are dropped. During incidents, teams sometimes discover they only have a few hours or days of logs, which makes root cause analysis much harder. Another risk is that responders may change logging settings to reduce cost or noise without realizing they are shortening retention in a way that hurts investigation readiness. The defensive correction is to treat log retention as part of security posture, not just an operational setting. You should know what your minimum investigation window is and ensure the logging configuration supports it. You should also monitor log pipeline health, because silent logging failures create the worst kind of evidence gap: the gap you do not notice until after an incident.

A quick win that strengthens evidence defensibility is immutable storage for high-value audit trails. Immutability means records cannot be modified after they are written, which reduces the risk of attacker tampering and increases trust in the evidence. High-value audit trails often include identity logs, control plane logs, and critical data access logs, because those categories describe the most important actions in cloud. If those logs can be altered or deleted by an attacker with administrative access, the investigation may be blind. Immutability does not eliminate all risk, but it changes attacker economics because they must either compromise the immutable store or accept that their actions will be recorded. It also supports compliance needs because you can demonstrate integrity controls for audit records. The practical point is to choose which logs deserve the strongest protection and to implement immutability where it produces the most value, rather than trying to make everything immutable without a plan.

Now rehearse collecting evidence during active containment pressure, because this is where evidence discipline is most likely to fail. Imagine you detect suspicious behavior and must contain quickly, such as revoking credentials or isolating a workload. The temptation is to make changes first and ask questions later. A disciplined approach does both in a controlled order. You capture key identifiers and a minimal set of logs that establish baseline facts, then you snapshot relevant configurations, and then you execute containment actions. If time is extremely tight, you capture the smallest evidence set that will preserve context, such as identity events, control plane actions, and a configuration snapshot of the affected resource. You then proceed with containment and continue collecting evidence as the situation stabilizes. This rehearsal teaches that evidence preservation is not an all-or-nothing choice. Even under pressure, you can preserve critical context if you have a practiced routine and you know what evidence is most valuable.

To keep the process simple under stress, use a memory anchor: who, what, when, where, how. Who refers to the identity involved, including the account, role, or service identity that performed actions. What refers to the actions taken and the resources affected, with precise identifiers. When refers to the time window, with timestamps that support correlation. Where refers to the region, tenant, account, and network context. How refers to the mechanism, such as an API call sequence, a role assumption chain, a policy change, or an application path. This anchor is powerful because it produces an evidence record that is usable. If you capture those five elements, you can reconstruct a credible story and support accurate response. If one element is missing, you know exactly what you need to find next. It turns evidence collection from vague diligence into a structured habit.

As a mini-review, evidence discipline begins with recognizing that cloud evidence spans identity, the control plane, and data access, and that these narratives must be correlated. High-quality evidence collection depends on capturing core identifiers like timestamps, regions, account IDs, and resource identifiers, because correlation fails without them. Exporting logs should preserve original retention settings and protect the integrity of both source and copies. Configuration snapshots should be taken before changes, because configuration state explains what was possible. Disk and memory artifacts can provide deeper workload evidence when feasible and safe, but they must be handled carefully. Documentation of responder actions with clear justifications prevents confusion and supports trust. Chain of custody practices protect evidence integrity and defensibility. Pitfalls include log overwrite through weak retention and rotation, while quick wins like immutable storage strengthen audit trails. Scenario rehearsal shows how to preserve essential evidence even during active containment, and the who, what, when, where, how anchor keeps the process consistent.

To conclude, preserving cloud evidence correctly is not optional if you want investigations to be reliable, remediation to be accurate, and incident reporting to be defensible. Evidence gives you facts, and facts prevent overreaction, guesswork, and misdirected fixes. When you define evidence sources, capture identifiers, preserve logs and configurations, and document your actions, you build a foundation for both containment and long-term improvement. When you maintain chain of custody and protect high-value logs with immutability, you increase trust in your records even when attackers attempt to cover tracks. Use the who, what, when, where, how anchor to keep collection simple and complete under pressure. Create an evidence checklist for your environment.