Certified: The GIAC GCLD Audio Course

Logging is one of those areas where early choices quietly decide whether you will be able to see reality later, or whether you will be stuck reconstructing events from partial signals and assumptions. In this episode, we focus on cloud logging fundamentals through an investigation-first lens, because the value of logs is not in collecting data, but in answering specific questions when something goes wrong. Cloud platforms can generate enormous volumes of telemetry, and it is easy to confuse quantity with coverage. The uncomfortable truth is that teams often discover their logging gaps only after a security event, when they realize they cannot prove who did what, when it happened, or how far the impact spread. A logging strategy that starts with investigation questions avoids that trap by prioritizing evidence over noise. When logging is designed to answer real questions, it supports incident response, audits, troubleshooting, and governance without becoming an unmanageable data swamp.

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.

Investigation questions are the backbone of log source selection, and they can be framed simply as who acted, what changed, and what moved. Who acted is about identity and authority, meaning which principal performed an action, under what authentication context, and with what level of privilege. What changed is about configuration, state, and control-plane actions that alter how systems behave, including changes to policies, network rules, keys, and service settings. What moved is about data and execution paths, meaning where traffic went, what resources were accessed, and whether information flowed in ways that were expected. These questions sound basic, but they map directly to the kinds of uncertainty that slows investigations and causes teams to miss the real root cause. If you can answer who, what, and what moved with confidence, you can usually build a credible timeline and scope an incident accurately. If you cannot, responders end up guessing, and guesses tend to expand incident impact and cost.

Identity and control plane logging should be prioritized first because accountability is the foundation of almost every investigation. In cloud environments, many high-impact actions happen through the control plane, including creating resources, changing network exposure, modifying identity permissions, and altering logging settings themselves. When those actions are not logged reliably, it becomes difficult to distinguish malicious behavior from legitimate administrative work, and containment decisions become riskier. Identity logs help establish whether an action was performed by a human user, an automated workload identity, or a system service, and they help determine whether the access pattern matches normal behavior. Control plane logs provide the authoritative record of configuration changes, which are often the turning points in incidents because they create persistence, expand permissions, or disable defenses. Prioritizing these logs is a practical form of least regret, because even if you collect nothing else, you at least preserve the evidence needed to understand administrative activity and governance failures. It also supports non-security outcomes, like troubleshooting outages caused by unintended configuration changes.

Network flow visibility becomes the next priority when lateral movement is possible, because many incidents progress by expanding from an initial foothold into broader access. Cloud environments may feel segmented, but segmentation often depends on configuration that can be changed, misunderstood, or bypassed, especially when teams move quickly. Network flow data helps answer what moved by showing communication patterns between workloads, subnets, services, and external endpoints. It can reveal unexpected east-west traffic that suggests scanning or internal discovery, and it can reveal unusual egress destinations that suggest command-and-control or data exfiltration attempts. Flow visibility also helps confirm the effectiveness of containment actions, because responders can verify whether suspicious communication stopped after a change. Without network flow data, teams may know an identity changed a policy, but they cannot confidently describe what that change enabled in practice. Flow logs are not always perfectly detailed, but even coarse visibility can accelerate investigations by narrowing hypotheses and revealing relationships between systems.

Application and data access logs become critical for sensitive systems because control-plane and network evidence often explains the how, but not always the impact. For systems that handle regulated data, high-value intellectual property, or privileged operational functions, you need evidence of access and actions at the data plane. Application logs can show authentication attempts, authorization decisions, and business-level operations, which are often necessary to determine whether a suspicious request succeeded or failed. Data access logs, such as object access events, database query auditing, or storage read and write records, help establish whether sensitive information was accessed, modified, or copied. These sources are also essential for scoping, because an incident is not defined only by unauthorized access, but by what the attacker was able to do with that access. The goal is not to log every application event, but to capture security-relevant actions, especially those tied to sensitive transactions and privileged operations. In mature environments, application logging is designed with the assumption that it may be the final authority on whether sensitive actions actually occurred.

Correlation is where logging becomes usable evidence rather than disconnected fragments, so timestamps and identifiers must support joining events across sources. Time consistency is more than having timestamps; it is about having comparable timestamps with sufficient precision and reliable synchronization so event ordering is meaningful. Identifiers are what allow you to connect identity events to control-plane changes, network flows, and application actions, building a timeline that can be defended. Useful identifiers include consistent principal identifiers for users and workload identities, resource identifiers for services and objects, request identifiers for API calls, and session or trace identifiers that span multiple steps in a transaction. When identifiers are missing, responders are forced into probabilistic correlation, which increases the risk of both false conclusions and missed evidence. Correlation also depends on capturing enough context in each log entry, such as source location, client type, and the target resource, so a single event can be interpreted without excessive external lookup. Designing for correlation is one of the highest returns on effort in logging, because it reduces investigation time more than any single additional log source.

To practice log source selection, consider a simple cloud application with an external entry point, a compute layer, and a data store. The investigation questions remain the same: who acted, what changed, and what moved, but the log sources you choose should reflect that application’s threat model and operational responsibilities. Identity and control-plane logs are the baseline because they establish accountability for changes and access. Network flow visibility is important if the compute layer can reach multiple internal services or if there is meaningful east-west communication that could support lateral movement. Application logs are needed at the entry and compute layers to capture authentication, authorization, and security-relevant business operations, especially where sensitive actions occur. Data access logging is essential for the data store because it provides evidence of reads, writes, and unusual access patterns, which is often what stakeholders ultimately care about during an incident. The point of this exercise is to select logs because they answer investigation questions for that architecture, not because they are available or because a checklist says to collect them.

A common pitfall is logging everything without a use case plan, which often produces a flood of data that is expensive, hard to search, and rarely reviewed. When teams attempt to capture every possible signal, they typically do not invest enough time in normalization, correlation, access controls, or alert tuning, and the result is a noisy environment that still fails during investigations. Logging everything also creates operational risk because storage and ingestion costs can balloon, and teams may respond by disabling logs arbitrarily to cut spend, often turning off the very sources they will later need. The deeper issue is that excessive logging without intent encourages the belief that coverage equals safety, even when the organization lacks the processes to make use of the data. A logging program should be judged by its ability to answer the key questions under pressure, not by how many terabytes it collects. Intentional logging also supports privacy and minimization principles because it reduces collection of irrelevant or overly sensitive data. In practice, a smaller set of high-quality logs that are searchable and correlated beats a massive archive that nobody can use.

A practical quick win is to start with high-signal sources and expand deliberately once those sources are stable and useful. High-signal sources are the ones that most directly answer who acted and what changed, such as identity events and control-plane audit records. Once those are collected centrally, protected from tampering, and searchable, you can layer in network flow visibility to better answer what moved and to support scoping and containment verification. After that, you can add application and data access logs for the systems where impact matters most, focusing on security-relevant events rather than every debug message. This staged approach also makes it easier to improve quality, because each new source can be normalized, correlated, and monitored properly before more complexity is introduced. Expansion should be driven by gaps discovered through tabletop exercises, incident learnings, audit requirements, and changes in architecture. When teams expand logging with intent, they build a program that grows in capability rather than in noise. The win is sustainable visibility that improves over time rather than collapsing under its own volume.

A scenario rehearsal that clarifies priorities is investigating a suspicious policy change event, because policy changes are common pivot points for attackers and common sources of operational mistakes. In that situation, the first question is who acted, meaning which identity performed the change, whether the action was interactive or automated, and whether the authentication context matches expectations. The next question is what changed, meaning the before-and-after state of the policy, the scope of resources affected, and whether the change created new exposure or privileges. The next question is what moved, meaning whether the change was followed by unusual access patterns, unexpected network paths, or anomalous data access that suggests the change was used to enable further activity. Control-plane logs help establish the change event and its parameters, identity logs help establish the principal and context, and network and data access logs help establish whether the change led to suspicious behavior. A well-designed logging set lets responders build a coherent timeline quickly and decide whether containment is needed immediately or whether the change appears benign. Without those sources, teams often overreact or underreact, both of which carry real cost.

Retention decisions must be made deliberately because they determine whether you can answer questions days, weeks, or months after an event, and different drivers pull retention in different directions. Response needs require keeping enough history to detect slow-moving campaigns and to investigate incidents that are discovered late. Audit requirements may mandate specific retention periods for certain types of events, especially around administrative actions and access to sensitive systems. Forensic needs may require longer retention for high-value environments where the likelihood and impact of sophisticated incidents are higher. Retention is not only a time decision but also a fidelity decision, because some logs may be stored at full detail for a shorter period and summarized for a longer period, depending on use. The key is to avoid arbitrary retention that is chosen only to reduce cost, because the cost of missing evidence during a real incident often dwarfs log storage savings. Retention should also consider availability and integrity, ensuring logs remain accessible when needed and protected from alteration. A retention strategy is part of your security posture, not an accounting afterthought.

A helpful memory anchor is to treat logging like a flight recorder with the right channels. A flight recorder is valuable because it captures the signals that explain what happened, not every possible noise in the aircraft. If the recorder captures the wrong channels, you may have data but still lack the evidence to understand the cause of a failure. Cloud logging is similar: you want the channels that capture identity actions, control-plane changes, key network movement, and sensitive data access, because those channels reconstruct most incidents with defensible clarity. You also want those channels to be synchronized and correlate cleanly, because a recorder that cannot be aligned across time and context is far less useful. The memory anchor reinforces that logging is about design choices made before an incident, not about scrambling to enable logs after the fact. It also reinforces that fewer, higher-quality channels can be more valuable than a massive, incoherent dump. When teams remember the flight recorder analogy, they tend to prioritize evidence quality over data quantity.

As a mini-review, start with investigation questions that focus on who acted, what changed, and what moved, because those questions directly drive log source selection. Prioritize identity and control-plane logs to establish accountability and to capture the configuration changes that often define incident turning points. Add network flow visibility where lateral movement is plausible, because it helps scope behavior and confirm containment outcomes. Add application and data access logs for sensitive systems, because they establish impact and provide evidence of meaningful actions against critical assets. Ensure timestamps and identifiers support correlation across sources so you can build reliable timelines rather than relying on guesswork. Choose retention based on response, audit, and forensic needs, and expand logging deliberately from high-signal sources rather than collecting everything without purpose. When these disciplines are applied together, logging becomes a practical investigation capability rather than a cost center and a storage problem.

To conclude, the most immediate way to apply this episode is to pick five must-have log sources for your environment based on the investigation questions you need to answer under pressure. The choice should reflect your architecture and risk, but it should almost always include identity events and control-plane audit logs because they establish who acted and what changed. The remaining sources should prioritize visibility into movement and impact, such as network flow data for lateral movement and data access auditing for sensitive stores, with application security logs where critical decisions occur. Once those five sources are collected centrally, correlated reliably, and retained appropriately, you can expand with confidence rather than expanding blindly. A logging program that begins with must-have evidence is far more likely to support real investigations than one that begins with indiscriminate collection. Pick five must-have log sources for your environment.