Services / Testing
Cloud Security Posture
A configuration assessment of every cloud account, subscription and region you own, against a hardened security baseline.
The problem
Your cloud grew organically. There are accounts nobody remembers creating, IAM roles with wildcard permissions granted for a deploy in 2023, and at least one storage bucket that someone made public to fix a demo. The auditor will ask for evidence of secure configuration, and nobody knows what the current state even is.
The method.
Enumerate the whole estate first
Every account, subscription and project in every region, including the regions nobody uses, which is where the forgotten resources sit. Discovery runs from the organisation and billing APIs, because an account nobody remembers is not going to be on the list you were handed.
Assess against a hardened cloud baseline
A configuration assessment across identity and access, logging and monitoring, networking, encryption, and storage, measured against a hardened cloud security baseline. Every finding cites the specific control and the exact resource, so it is verifiable and fixable rather than merely alarming.
Go after identity, because that is where the compromise happens
Over-permissioned roles and wildcard policies, unused permissions granted long ago and never revoked, access keys that have never rotated, root and break-glass account usage, cross-account trust relationships, and privilege escalation paths where one identity can quietly assume another. This is where cloud breaches actually start, and it is where automated posture scoring is weakest.
Verify the security-relevant configuration an auditor will sample
Control-plane logging enabled in every region and retained; encryption at rest on databases, volumes and buckets, with key management and rotation; network exposure: security groups open to 0.0.0.0/0, public database endpoints, exposed management ports; and backup configuration with an actual restore test date attached.
Prioritise by exposure and blast radius
A public bucket with customer data, a database open to the internet, and an over-permissioned CI role are the findings that matter. Missing tags are not. Findings are ranked by what an attacker could reach and by what the blast radius would be if they did.
Fix forward, in code
Remediation guidance is written against your infrastructure-as-code and your guardrails (service control policies, organisation policies, preventive controls), so the misconfiguration cannot simply be recreated by the next engineer in a hurry. Console fixes are point-in-time; policy guardrails are permanent.
What is cloud security posture assessment?
A cloud security posture assessment evaluates the configuration of every account, subscription and region in a cloud estate against a hardened security baseline, covering identity and access, logging, networking, encryption and storage. It identifies misconfigurations such as public storage, over-permissioned roles, disabled logging and internet-exposed databases, each tied to a specific resource and baseline control.
What are the most common cloud misconfigurations?
Over-permissioned IAM roles with wildcard policies granted for a one-off task and never revoked; access keys that have never been rotated; control-plane logging disabled in regions nobody thought they were using; storage buckets made public to solve an immediate problem; security groups open to 0.0.0.0/0; and databases with public endpoints. Identity misconfiguration is the one that most often turns a small mistake into a full compromise.
How often should cloud configuration be assessed?
Continuously. Cloud configuration changes with every deployment, and a quarterly assessment describes a state that no longer exists. The practical approach is continuous baseline testing that alerts on regression from an approved baseline, backed by preventive guardrails (service control policies or organisation policies) so that the highest-risk misconfigurations cannot be created in the first place.