- Synacktiv's primer for analysts new to AWS starts with how the environment is organised: accounts, identities, permissions and regions.
- WebPulse argues that knowing this map helps teams read activity logs, which the primer calls the primary source of incident information.
- Leaders can ask teams to list accounts, long-lived AKIA keys and regions in use, and to name AWS-capable responders in advance.
An incident is a poor moment to learn how your own cloud is built. That is the argument of this story. It draws on a new primer from the security firm Synacktiv, written for analysts who are new to AWS.
Synacktiv does not say that a map must come before a log search. It calls activity logs "the primary source of information analyzed in the event of an incident." The idea that analysts read logs better when they know the layout is WebPulse's own view. The primer's content supports it.
What Synacktiv published
Synacktiv wrote the guide for forensic and security analysts who do not know AWS. The firm says AWS has issued a comprehensive incident response plan. It adds that most companies find the plan hard to apply during a real incident.
The guide is a starting point. It does not replace AWS documentation or training. It leaves out networking and the cost of different services.
This story covers the parts on how AWS is organised, who holds permissions, and where logs sit.
How an AWS environment is organised
An AWS environment is built around an organization. The organization holds accounts. Each account is an isolated container for resources.
One management account runs the whole organization and centralizes billing. Member accounts do the actual work, such as test and production systems. Accounts can be grouped into organizational units that share common rules.
One detail stands out for investigators. Synacktiv says resources can be deployed straight from the management account. It calls that practice generally discouraged in production and a possible sign of an anomaly. The structure itself can be a clue.
Four kinds of identity
AWS gives access to identities. An identity can be a person or a piece of software.
The root user is the one top-level identity in each account. It has full administrative privileges. IAM users sign in with a password or with permanent API keys. Those keys start with AKIA.
Federated identities come from an outside provider such as Okta, Microsoft Entra ID or Google. They use temporary keys that start with ASIA. IAM roles are temporary identities that users or services can take on.
The key prefix tells an analyst what kind of credential they are looking at. Synacktiv ties AKIA keys to IAM users and ASIA keys to federated identities that assume roles.
WebPulse's reading: a permanent key has no built-in expiry, so an analyst may ask who created it and where else it is stored. A temporary key points back to a role or an outside identity provider, so the questions turn to who assumed that role and how they signed in.
Permissions come in layers
Permissions are written as JSON documents in the IAM service. Several types can apply at once.
Identity-based policies attach to users, roles or groups. Resource-based policies sit on the resource itself, such as an S3 storage bucket. Permission boundaries cap what an identity can be given.
Service Control Policies set a ceiling for a whole organization, unit or account. They bind each account's root user. Synacktiv notes that a Deny rule in one of these policies takes precedence over all others.
Older access control lists were deprecated in 2023. Some environments still use them. So what an identity could do depends on how several layers combine. The same holds when an attacker controls that identity.
Regions and logs
AWS regions are separate geographic areas. They are isolated by default. A resource in one region cannot be reached from another unless someone sets that up. Not every service exists in every region.
Synacktiv tells responders to verify and confirm all the regions normally in use.
WebPulse's reading: a search of only one familiar region could leave gaps.
For logs, the guide names two main services: CloudTrail and GuardDuty. The part reviewed here introduces them. It does not explain how to use them.
What leaders should ask
The lesson here is that cloud forensics starts with orientation. Tools matter, but so does knowing the terrain. Teams can settle that before an incident.
Put five questions to your team:
Can they list every AWS account and organizational unit we own? Which identities hold permanent AKIA keys, and why? Permanent keys have no built-in expiry, so each one is worth a named owner. Does anything run directly in the management account? Which regions do we normally use? If our team lacks AWS depth, who do we call, and have they seen our setup?
Synacktiv's guide is a starting point, not a full playbook. Its message is practical. Learn how your cloud is built before you need to investigate it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Synacktiv.
