From a monthly security review to a daily automatic one

We ran many projects across four clouds, but no security team worked directly on cloud accounts or security resources. The security team’s role stopped at running CSPM and passing on the results.

Security reviews happened once at the end of each month, pulling consoles and logs from each cloud and checking them manually over several days.

With a monthly review, someone could give themselves excessive permissions, issue an Access Key (a long-lived credential that does not expire), or delete a key server, and we might not know for nearly a month.

What matters most in a security incident is how fast you notice. Our setup only looked after the incident had passed.

No one asked me to fix this. I decided the gap could not stay, and changed it myself.

The hard part: even a simple permission change was recorded differently in every cloud. So the work started by converting everything to one common standard.

1. Collect: Using each cloud’s official SDK (the toolkit for working with a cloud from code), I pulled audit logs and resource inventories from every project in all four clouds.
2. Normalize: I converted the differing logs to one common standard: who did what, to which resource, and when.
3. What gets reviewed: IAM (access management) permission changes, permission usage history, create/delete/change history for security groups and firewall rules, and create/delete/change history for servers and other key resources.

Normalization example (fictional data for illustration)

4. Define critical actions: Alerting on every change means no one reads the alerts, so I picked only actions that could lead to an incident: attempts to grant a permission to oneself or someone else, attempts to issue an Access Key, and attempts to stop, delete, or change key servers and databases.
5. Schedule: The review runs automatically once a day before dawn, and results go to a Google Sheet.
6. Alert and response: A confirmed critical action triggers a Telegram and Slack alert → check intent with the actor → request a correction → record as resolved.

Critical event examples by cloud (example event names as they appear in each cloud’s audit log)

Alert message example (fictional)

🔴 [CRITICAL] Access Key issue attempt
Cloud: AWS / Project: game-a-prod
Actor: user-a / Target: user-a
Time: 2025-03-12 02:14 (KST)
→ Confirm with the actor, then record the status in the sheet.

Security is less about analyzing incidents afterward and more about defining the signals that lead to incidents and building a structure that never misses them.

Without authority, “I tried this and it got better” persuades more than “we should do this”.