Cloud Security Program · Part 4 — Detection & Response: Logging, CSPM & Threat Detection

This is Part 4 of the Cloud Security Program — the moment prevention hands over to detection. The first three parts were about making bad things structurally hard: Part 1 built an account hierarchy, one governed identity, and org-wide guardrails; Part 2 wrapped a segmented, private, default-deny network around the workloads and hardened the edge; Part 3 encrypted the data, governed the keys, pulled secrets out of code, and made public exposure impossible. Every one of those controls is preventative — and preventative controls fail silently. A misconfiguration slips through, a credential leaks, a guardrail has a gap, an insider has legitimate access. This part builds the layer that assumes something will get past the walls and asks a different question: when it does, will you see it, and can you respond before it matters? That means centralized logging so nothing happens off-camera, the managed threat-detection and posture services that turn those logs into ranked findings, an alerting path that reaches a human (or an automation) fast, and incident-response runbooks rehearsed before the incident rather than written during it.

The good news is that Parts 1–3 were quietly generating the raw material for all of this. The CloudTrail / Cloud Audit Logs / Activity Log baseline from Part 1, the VPC flow logs and firewall drops from Part 2, and the key-usage and secret-retrieval records from Part 3 are exactly the high-signal telemetry the detection services in this part consume. You are not instrumenting from scratch; you are aggregating, enriching and acting on signal you already have. As before, the shape is the same across all three clouds — centralize, detect, alert, respond — so learn it once and apply it three times.

Scope of this phase

Every part of this program is scope-bounded so you know exactly when you are done.

• In scope: centralized logging (an immutable, aggregated log archive across every account/project/subscription); threat detection and cloud security posture management (the managed services that consume those logs and flag threats and misconfigurations); alerting and correlation (routing findings to a SIEM or a response queue, deduplicating and prioritizing them); and incident response (runbooks, containment automation, and forensic readiness for the cloud control plane).
• Explicitly out of scope (later part): continuous compliance reporting, drift remediation and framework-evidence mapping (Part 5) — this phase produces detections and response capability; turning that into audit-ready, framework-mapped governance is the finale.
• Definition of done: the exit checklist at the end of this part. When every box is ticked across all three clouds, you are ready for Part 5 — and not before.

The four building blocks — centralized logging, threat detection, alerting, and incident response — are a pipeline: each one consumes the output of the one before it. Build them in order, because an alert you cannot trace back to an immutable log is a dead end, and a detection nobody is on call for is just an expensive dashboard.

Building block 1 — Centralized logging

Detection starts with logs you can trust, in one place, that an attacker cannot erase. The failure mode is logs scattered per-account, retained for two weeks, and writable by the same identity that would want to delete them after a breach. The fix on every cloud is the same shape: a single, dedicated, tightly-locked logging account/project that receives an aggregated, append-only copy of every audit trail in the organization.

The two decisions that matter are aggregation and immutability. Aggregate with the native mechanism — an AWS Organizations trail writing to one S3 bucket in a dedicated log account, a GCP aggregated log sink at the organization level routing to one project, Azure diagnostic settings shipping every subscription's Activity Log to a central Log Analytics workspace — so there is one place to search and no account can quietly stop logging. Then make the archive immutable and isolated: S3 Object Lock in write-once-read-many mode, bucket retention locks, or Azure immutable storage, all in an account/subscription whose access is separate from everything else. The point is bluntly adversarial: the identity that compromises your production account must not be able to delete the evidence of what it did. An org-level trail that captures management events across every account, landing in a locked bucket the production roles cannot touch, is the foundation everything else in this part stands on:

{
  "Name": "org-management-trail",
  "IsOrganizationTrail": true,
  "IsMultiRegionTrail": true,
  "S3BucketName": "acme-central-logs-archive",
  "KmsKeyId": "arn:aws:kms:eu-west-1:444455556666:key/log-archive-cmk",
  "EnableLogFileValidation": true,
  "EventSelectors": [
    { "ReadWriteType": "All", "IncludeManagementEvents": true }
  ]
}

Turn on log-file integrity validation so tampering is detectable, encrypt the archive with a CMK from Part 3 whose key policy the production accounts cannot use, and extend coverage beyond the control plane to the data and network layers: VPC flow logs (Part 2's traffic), object-storage data events, and DNS query logs. Retention is a compliance input too — ISO 27001, SOC 2, DORA and NIS2 all imply retention windows — so set it deliberately, not by default.

Building block 2 — Threat detection & posture (CSPM)

Raw logs are necessary but not sufficient; nobody finds an intrusion by reading CloudTrail by hand. Each cloud ships a managed detection service that ingests those logs and the provider's own threat intelligence and emits ranked findings, plus a posture-management capability that continuously checks your configuration against known-bad patterns. Turn both on, organization-wide, and you convert a firehose of logs into a manageable stream of "here is something worth looking at."

Two distinct jobs are worth separating. Threat detection — GuardDuty, SCC Event Threat Detection, Defender for Cloud — is behavioural: it watches the logs for the actions of an attacker, such as credential exfiltration, crypto-mining, calls from anonymizing proxies, anomalous API patterns, or the out-of-pattern key-decrypt and secret-fetch volume you made visible in Part 3. Posture management (CSPM) — Security Hub, SCC posture, Defender's Secure Score — is configurational: it continuously checks your resources against benchmarks (CIS, the provider's foundations) and flags the state that would enable an attacker, such as a security group open to the world or a role with excessive permissions. You want both — one catches the misconfiguration before it is used, the other catches the use — and you want them enabled at the organization level with findings aggregated into a single pane (Security Hub, SCC, Defender for Cloud) so a small team sees every cloud's findings in one prioritized list rather than logging into dozens of accounts. Enable at the org root so new accounts are covered automatically:

# AWS — GuardDuty + Security Hub across the whole organization, auto-enrolling new accounts
aws guardduty enable-organization-admin-account --admin-account-id 111122223333
aws guardduty update-organization-configuration --detector-id "$DET" --auto-enable-organization-members ALL
aws securityhub enable-organization-admin-account --admin-account-id 111122223333

# GCP — Security Command Center is enabled at the organization level (Premium/Enterprise tier)
gcloud scc settings services enable --organization=ORG_ID --service=EVENT_THREAT_DETECTION

# Azure — Defender for Cloud plans enabled at the subscription/management-group scope
az security pricing create --name VirtualMachines --tier Standard

The trap to avoid is enabling these services and letting the findings pile up unread. A CSPM console with 4,000 open findings and no owner is worse than none, because it manufactures the illusion of coverage. The bridge from "detection exists" to "detection works" is the next building block.

Building block 3 — Alerting & correlation

A finding that no human or automation sees in time is not a detection; it is an audit artifact. This building block routes findings out of the provider consoles and into a path that produces action — a SIEM for correlation and hunting, a ticketing or paging system for response, and enough prioritization that the signal is not buried. The goal is a short, measured time from detection to acknowledgement to action.

The pattern is the same everywhere: findings are emitted as events (EventBridge, Pub/Sub, Event Grid), a SIEM (Security Lake/OpenSearch, Chronicle, Microsoft Sentinel) correlates them across accounts and clouds and across time so that three low-severity findings that together describe an attack chain surface as one high-severity incident, and a routing layer pages the on-call for anything above a threshold while filing the rest. Two disciplines make this humane. Prioritization and suppression: tune severities and suppress the known-benign so an alert means something — an unsuppressed console is an ignored console. Automated triage: for well-understood findings, wire a first response directly — a Lambda/Function that, on a high-severity finding, automatically quarantines the offending resource (detach the role, isolate the security group, snapshot the disk) and files a ticket, buying the human time to investigate. A minimal auto-response that turns a critical GuardDuty finding into containment plus a page:

import boto3, json

def handler(event, _ctx):
    finding = event["detail"]["findings"][0]
    severity = finding["Severity"]["Label"]
    resource = finding["Resources"][0]["Id"]

    if severity in ("HIGH", "CRITICAL"):
        # Contain first: isolate the resource, then page a human to investigate.
        isolate(resource)                       # e.g. swap SG to deny-all, revoke role sessions
        page_oncall(finding["Title"], resource) # PagerDuty / Opsgenie
    ticket(finding)                             # everything is filed for review

Correlation across the three clouds is the payoff of centralizing in Part 1 and aggregating in building block 1: an attacker who pivots from a compromised AWS role to an Azure identity leaves a trail in two consoles that only a single SIEM can join into one story.

Building block 4 — Incident response

Detection and alerting are worthless if the response is improvised. The final building block is organizational as much as technical: runbooks written and rehearsed before the incident, containment actions pre-authorized so responders are not waiting on approvals mid-breach, and the forensic readiness — immutable logs, snapshot capability, break-glass access — to investigate and recover. In the cloud the control plane is the new battleground: an attacker's most valuable move is not touching a server but assuming a role, and your response must operate at that layer.

Four things separate a rehearsed team from a scrambling one. Runbooks per scenario: for each likely incident — compromised credential, public data exposure, crypto-mining workload, ransomware on a volume — a written, versioned runbook that names the containment steps, the forensic captures, and the recovery path, so the response is a checklist, not an invention. Pre-authorized containment: the actions that stop the bleeding — revoking a role's sessions, disabling a KMS key (crypto-shredding from Part 3, now a containment tool), quarantining a network, disabling an identity — pre-approved and ideally one automation away, because the value of containment decays by the minute. Forensic readiness: the immutable logs from building block 1, the ability to snapshot a disk or memory before you terminate anything, and a documented chain of custody. Break-glass access: a tightly-controlled emergency path — a locked-down role, MFA, alerting on its every use — for when the incident has taken out your normal access. Then the discipline that ties it together: rehearse. A tabletop or game-day against a simulated finding, at least twice a year, is what converts a runbook from a document nobody has read into muscle memory — and it routinely surfaces the missing permission, the stale contact, or the containment step that does not actually work.

Definition of done — Detection & Response exit checklist

You are ready for Part 5 when every one of these is true, in each cloud you run:

• Centralized logging: control-plane, data-plane and network logs aggregated to a single dedicated log account/project/subscription; the archive immutable (Object Lock / retention lock / immutable storage) and isolated from production identities; log-file integrity validation on; retention set to your compliance requirement.
• Threat detection: the managed threat-detection service (GuardDuty / SCC Event Threat Detection / Defender for Cloud) enabled org-wide with new accounts auto-enrolled; workload protection (CWPP) on for the workloads that warrant it.
• Posture management (CSPM): continuous configuration checks (Security Hub / SCC posture / Secure Score) enabled org-wide against a named benchmark; findings owned, not merely collected.
• Alerting & correlation: findings routed off the console into a SIEM (Security Lake/OpenSearch / Chronicle / Sentinel) that correlates across accounts and clouds; high-severity findings page an on-call; benign findings suppressed; a measured detection-to-acknowledgement time.
• Automated triage: for well-understood high-severity findings, an automated first response (containment + ticket + page) in place.
• Incident response: per-scenario runbooks written and versioned; containment actions pre-authorized and automatable; forensic readiness (immutable logs, snapshot capability, chain of custody); a break-glass access path with alerting; the whole thing rehearsed in a game-day at least twice a year.

Tick every box and you have moved from hoping nothing gets through to knowing when something does and being ready for it. Leave a gap — the log archive a production role can delete, the CSPM console nobody owns, the runbook nobody has rehearsed — and the detection layer becomes the thing you thought you had during the post-mortem.

What's next

Part 5 — Govern & Comply is the finale, and it is what makes the previous four parts durable. Everything you have built — the account structure and guardrails, the network, the data controls, and now the detection-and-response layer — has to stay built as the estate grows, teams change, and hundreds of engineers ship daily. Part 5 covers policy-as-code so your guardrails are version-controlled and tested like software, continuous compliance so posture is measured against ISO 27001, ENS, NIS2, DORA, SOC 2 and GDPR every day rather than the week before an audit, drift detection and remediation so the estate cannot silently decay, and the evidence mapping that turns all of this program's controls into an audit story you can hand an assessor. The detections and immutable logs you stood up here are a major source of that evidence — proof that monitoring exists and works. It ships next month.

Standing up detection and response is also where a platform stops being optional at scale: ISMShed ingests your detection coverage, logging posture and incident-response readiness as continuous, framework-mapped audit evidence across ISO 27001, ENS, NIS2, DORA, SOC 2 and GDPR — so the visibility this phase produces becomes your compliance narrative rather than a screenshot you scramble for during an audit. And if you would like experienced hands to design the logging architecture, tune the detection services and write and rehearse the incident-response runbooks across your own AWS, GCP and Azure estate, Axelia's cloud-security and GRC consultants run the program alongside you. See the attack before it becomes a breach now, and the governance work in Part 5 has something real to attest to.