Your First Logging Baseline: Detections That Matter
The first detections worth turning on are the ones that answer three questions: who changed identity permissions, who used privileged access, and who read data in bulk. All three come from audit logs the major providers already produce, so a logging baseline costs nothing before you buy a single tool. In AWS, CloudTrail already keeps a searchable, downloadable record of the past 90 days of management events in each Region, and Google Cloud writes permission-change logs you cannot even switch off. This article defines the minimum baseline for a small team, the order to enable it in, and the trade-offs that decide what waits.
What to enable first
Five signals cover most real intrusions a small team will face, and four of them run on logs that are free or on by default. Work down the table in order; each row earns its place because the underlying signal is cheap and the behavior is rare in healthy operations.
| Detection | Log source | Why it ranks early | Watch-out |
|---|---|---|---|
| Root or break-glass use | CloudTrail management events; Google Cloud Admin Activity logs | Direct sign of account takeover or emergency response | Exclude your documented break-glass workflow to avoid noise |
| Identity and policy changes | CloudTrail management events; Admin Activity logs | Attacker persistence almost always touches IAM | Baseline normal automation before alerting on every change |
| Storage made public | Storage configuration audit events | Public exposure is the cheapest path to mass data theft | Pair the alert with automatic public-access-block restoration |
| Bulk object reads | S3 data events; Data Access audit logs | Catches exfiltration after credentials leak | These logs cost money; scope them to sensitive buckets |
| Impossible-travel or anonymous access | Managed threat detection such as GuardDuty | Flags credential compromise you cannot see in raw logs | Tune to your real office locations |
The AWS floor is free
CloudTrail gives you a starting point without configuration: the console’s Event history covers the last 90 days per Region, and a trail can deliver one copy of your ongoing management events to an S3 bucket at no CloudTrail charge (S3 storage still applies). Management events capture the identity and policy changes from the table above; object-level data events are separate, more expensive, and worth scoping narrowly.
For detection logic you do not have to write, Amazon GuardDuty automatically ingests CloudTrail management events, VPC flow logs and DNS logs the moment it is enabled, with no extra configuration required, so its findings start from data you did not have to pipe anywhere. Its S3 Protection plan extends the same analysis to S3 data events when you turn that protection on.
Google Cloud defaults differ
On Google Cloud, Admin Activity audit logs are always written and cannot be disabled, even if the Cloud Logging API itself is turned off, so every permission change and service-account key creation is already on record. The gap sits on the other side: Data Access audit logs are disabled by default everywhere except BigQuery, precisely because they can generate large volumes of data. Enable them selectively, for the buckets and datasets that hold sensitive data, rather than organization-wide, and expect the log-storage bill to follow the scope you choose.
Map detections to attack paths
Ranking by attack path, not by product feature, is what keeps a small baseline useful. MITRE’s technique page for Data from Cloud Storage observes that adversaries retrieve objects straight through the cloud API when no application layer stands in front of the bucket, and that misconfiguration is a recurring cause of exposure. That is why storage made public and bulk object reads belong in the first five signals even though one depends on paid data events: both sit directly on the exfiltration path. Identity changes rank above them because they are the prerequisite step for nearly every technique that follows.
Rollout order
- Create an organization-wide trail (AWS) or confirm Admin Activity coverage (Google Cloud); store logs in a dedicated account the production team cannot edit.
- Alert on root logins, service-account key creation and IAM policy attachment from day one; these are low-volume, high-value signals.
- Enable public-access detection on storage, with automatic restoration of public-access blocks where you can.
- Turn on GuardDuty or the equivalent managed detector and let it run a full week before tuning severities.
- Only then scope data events or Data Access logs to sensitive buckets, with a recurring review of which buckets still justify the cost.
Keeping the noise down
The failure mode of a first detection effort is not missing logs; it is alerting on everything at once. Cut volume three ways: suppress your own automation identities in identity-change alerts; route data events for noisy buckets to storage instead of the alerting pipeline; and keep a written exception list for break-glass use. Detections only reduce damage when response is contained — when an alert fires, SCP guardrails can contain a compromised account while you investigate, and the log archive itself deserves protection, including the key rotation decisions you should settle before enabling KMS encryption on it.