Cloud Telemetry, Detection, and Response

Cloud Telemetry, Detection, and Response

This lesson guides learners through useful cloud logging, detection design, and evidence-preserving response without assuming that every anomaly is malicious.

Collect evidence for decisions, not every possible event

Cloud environments produce control-plane events about identities, permissions, networking, storage, deployments, and policy changes. These records can answer critical questions during an incident: who changed a role, when a public endpoint appeared, which client accessed data, or whether a deployment introduced a new permission. They are most valuable when collected centrally, protected from routine administrators, retained for a defined purpose, and connected to workload context.

Start with high-impact events. Examples include privileged-role changes, new credentials or access keys, changes to logging or backup policies, public exposure changes, cross-account sharing, unusual data access, deployment changes, and deletion attempts. Include enough context to reconstruct a sequence: time, actor, target, action, result, source service, request or correlation identifier, and relevant ownership or environment tags.

Logging is not the same as detection. A detection asks a question, combines evidence, defines expected conditions, assigns an owner, and has a response route. “Alert on every role change” may overwhelm a team. “Investigate an unapproved privileged role grant outside the change window, especially when followed by a new credential” creates a testable hypothesis with a reason to act.

Protect the telemetry itself. If the same compromised administrator can delete logs, change retention, and disable alarms without an independent record, investigation becomes much harder. Preserve critical evidence in a separately controlled destination where practical.

Contain carefully and preserve the facts needed to recover

Cloud containment can be fast, which is valuable and dangerous. Disabling a credential, revoking a session, restricting a network rule, quarantining a workload, or rolling back a deployment may stop harm. It can also disrupt a business service, erase transient evidence, or tip off an attacker before the team understands the scope. Prepare authority and decision criteria before the incident.

Start with the question: what must be protected now? If a credential is actively being abused, revocation can be urgent. If a deployment changed a security policy, capture the change details and associated events before reversing it when feasible. If a service is leaking data, block exposure while preserving a controlled record of the affected configuration and access events. Match the action to the evidence, impact, and available authority.

Cloud response requires a current asset and identity view. Responders need to know which account owns the resource, which workloads depend on it, which identities can change it, and where logs and backups reside. A responder cannot safely isolate a service if the team cannot tell whether it supports a critical production function.

Practice a small number of plausible scenarios. Exercise a public-storage exposure, leaked access key, suspicious privileged role grant, or compromised deployment pipeline. Verify escalation routes, evidence access, containment permissions, and recovery steps. A plan that assumes provider support will be immediate or that every log is available forever creates dangerous confidence.