Path: the cloud SOC

More and more of what a SOC watches lives in cloud platforms and software-as-a-service apps. The alerts look different. There may be no laptop and no process tree. Instead there is an identity, an API call and a resource that changed.

What changes in the cloud

• Identity is the perimeter. Most cloud alerts are about who did something: a user, a role, a service account, an access key.
• Configuration is the attack surface. A storage bucket made public or a security group opened to the internet can matter as much as malware.
• Audit logs are your main evidence. Each provider has its own audit trail of control-plane actions. Learn what yours records and what it does not by default.
• Things are short-lived. A container or virtual machine may be gone before you look. Evidence has to be captured quickly or logged centrally.

Skills to learn first

1. Read an audit log entry for one provider and name the identity, the action, the resource, the source address and the result.
2. Understand how roles and permissions are granted there, and how someone could assume a role.
3. Learn what a leaked access key looks like in logs, and the first steps to contain it.
4. Find out which cloud logs your SOC actually collects, and for how long.

Cloud work rewards curiosity about how things are built. Ask the platform team for a walkthrough of one account. You will learn more in an hour with them than in a week of reading.

Also learn the difference between control-plane and data-plane activity. Creating a user or changing a policy is control plane and usually lands in the audit trail. Reading objects from storage is data plane and is often not logged unless someone turned that on. Knowing which is which tells you what you can and cannot prove.

Rule of thumb:Rule of thumb: in a cloud alert, find the identity first. Almost every next question follows from who it was and what they were allowed to do.