Cloud Infrastructure Security

Most cloud incidents we see are not exotic. They come from identity policies that grew permissive over time, storage that became reachable through a chain of defaults, secrets committed to build pipelines, or logging that was never routed anywhere an analyst would look. Our cloud assessment reviews the account or subscription structure, identity and access management, network segmentation, data storage and encryption, secrets handling, and detection coverage. We work from the CIS Benchmarks and the relevant provider well-architected security guidance, then apply the client's own regulatory context to decide what actually matters. The output separates control gaps that create present exposure from those that create audit findings, because the two need different response timelines.

What the engagement covers

A cloud security assessment examines the environment as it is configured, not as the architecture diagram describes it. We work from read-only access to the accounts, subscriptions or projects in scope, supported by interviews with the engineers who operate them. The review covers organisational structure and account separation, identity and access management, network boundaries, data storage and encryption, secrets handling, workload configuration, and the logging and detection pipeline. Where infrastructure is defined in code, we review the definitions alongside the deployed state, because drift between the two is common and is itself a control weakness.

Comparison is made against the CIS Benchmarks for the relevant provider and the provider's own security guidance, then filtered through the client's regulatory context. A benchmark deviation that creates present exposure and a benchmark deviation that creates an audit observation are different problems with different urgency, and the report separates them so remediation effort is not spent in the wrong order.

Identity is the perimeter

In every cloud assessment we have run, the identity layer produces the highest-value findings. Roles accumulate permissions because removing one is riskier than adding one. Service principals outlive the workload they were created for. Cross-account trust relationships are established for a migration and never revoked. Wildcard resource policies appear in a hurry during an incident and stay.

We enumerate the privilege graph rather than reading policies individually: which principals can reach administrative capability, and by what path. A role with permission to modify another role's policy is an administrator regardless of what its own policy grants. We also review credential hygiene — long-lived access keys, unrotated secrets, human accounts without multi-factor authentication, and break-glass accounts whose use is not alerted on.

Data exposure and encryption

Storage review covers object storage, managed databases, snapshots, backups and message queues. Public exposure is the obvious check; the more common finding is data reachable through a chain that no single control appears to permit — a bucket policy that trusts an account, an account whose role is assumable by a partner integration, a partner integration whose credentials sit in a public repository.

Encryption is assessed for what it actually protects. Provider-managed encryption at rest satisfies many control frameworks but defends against a narrow threat: physical media access. Where the client's threat model includes insider access or key compartment separation between environments, we assess whether customer-managed keys, key policies and separation of key administration from data access have been implemented to match. Secrets management is reviewed end to end, including how build pipelines obtain credentials and whether those credentials appear in build logs.

Detection coverage

A control that fails silently is a control that has already failed. We review whether audit logging is enabled across regions and accounts, whether logs are written to storage the producing account cannot alter, how long they are retained, and — most importantly — whether anything downstream reads them. Detection coverage is assessed against a short list of scenarios that matter for the client's sector: privilege escalation, credential creation, data egress at volume, disabling of logging itself, and configuration change outside the deployment pipeline.

Output and remediation

Findings are delivered with the affected resource inventory attached, so remediation does not begin with a discovery exercise. Each finding carries a CVSS 4.0 vector, the benchmark control it maps to where applicable, and implementation notes specific to the client's tooling — a Terraform change reads differently from a console change, and the report says which one is being described. A retest after remediation confirms closure and updates the benchmark gap table so the client can show an auditor both the original position and the verified improvement.