BrickellTechnologies

Service

Cloud Security Posture Assessments

AWS, Azure, GCP and Kubernetes, reviewed the way an attacker reads them: not as a list of misconfigurations, but as a set of paths from wherever they land to whatever you care about.

Get a scope and a price contact@brickell-tech.com

Configuration lists versus attack paths

Every posture tool will hand you a few hundred findings ranked against a benchmark. That is useful and you should have it. It is also why cloud security work stalls: the list has no narrative, so it gets triaged by severity label, and the severity label has no idea how your account is actually wired.

We work the other direction. Start from where an attacker realistically lands, which is usually a leaked key, a compromised laptop, an SSRF in something public-facing, or a build runner, then follow what that position can reach. The output is a small number of paths, drawn end to end, each with the one change that severs it.

What we look at

Identity, first and mostly

IAM is where cloud compromises are decided. Roles that can pass a more privileged role, trust policies with a wildcard where an account ID should be, OIDC federation from a CI provider scoped to the whole repository instead of one branch, service principals holding credentials that outlive the person who created them. In Azure the equivalent conversation is about Entra roles and consent grants, and it is usually worse because nobody has read it in years.

The exposed edge

Storage that is public, or effectively public through an ACL nobody reads. Databases reachable from a wider CIDR than intended. Management planes on the internet. Snapshots and AMIs shared beyond the account. Secrets sitting in environment variables, user data, or a Terraform state file in a bucket with looser permissions than the resources it describes.

Kubernetes

RBAC bindings that amount to cluster-admin by another name, workloads running privileged or with hostPath mounts, missing network policy so any pod can talk to any pod, and the node IAM role that a compromised container inherits. We check the cluster and then check what it gives you in the account underneath, because that pivot is the actual impact.

Build and deploy

The pipeline usually holds more privilege than any human in the organisation and gets a fraction of the scrutiny. We review who can trigger it, what a pull request from outside can make it do, where its credentials live, and whether a compromised dependency would reach production without a person in the loop.

What you get

Findings mapped to the CIS Benchmark and to MITRE ATT&CK for Cloud, because auditors want the first and your engineers think in the second. Each path gets a diagram, the specific resources involved, and a remediation written as the actual policy change rather than "apply least privilege". Where a fix is genuinely hard we say that too, and suggest what to monitor while you work on it.

If compliance is the driver, this pairs directly with compliance readiness, since most of the cloud controls an auditor asks about are the ones we just reviewed.

Questions we get asked

We already run a CSPM tool. What does this add?

Your CSPM tells you a bucket is public and a role is over-permissioned. It does not tell you that the over-permissioned role is assumable by the CI runner that builds pull requests from forks, which is the sentence that actually matters. Posture tools list conditions; we chain them into paths and tell you which chain reaches your production data.

Do you need production access?

A read-only role is enough for the posture review, and we prefer it: SecurityAudit and ViewOnlyAccess in AWS, Reader plus a directory read in Azure, roles/viewer with IAM read in GCP. If you also want the exploitation half proved rather than argued, that needs a scoped, written-down escalation of access, or a copy of the environment.

Which do we need, a posture assessment or a cloud penetration test?

Posture assessment if the question is "how is this configured and what is wrong with it". Penetration test if the question is "can somebody get from the internet into our data". They overlap, and most clients want the review first because it is cheaper and it usually surfaces enough to keep the team busy for a quarter.

Does the cloud provider need to approve testing?

For AWS, Azure and GCP, testing your own resources within their published rules no longer needs an approval form for common service categories, though some activities still do and simulated denial of service always does. We check the current policy for whatever we are touching and keep the confirmation with the engagement record.

Do you cover Kubernetes?

Yes, and it is often the most productive part. RBAC that grants pod creation is effectively node-level access, service accounts get mounted into pods that have no business holding a token, and the boundary between namespaces is thinner than most teams assume. We look at the cluster and at what a compromised pod can reach in the cloud account underneath it.

Also from us

Related services

Penetration Testing

Network, web app, API, mobile and internal testing done by hand. You get the attack path, the proof, and a retest once it is fixed.

Vulnerability Assessments

Full-estate scanning, then a human pass to strip the noise and rank what is left by real reachability instead of raw CVSS.

Endpoint Security

CrowdStrike Falcon rollouts, policy tuning and legacy AV migrations, run by people who break into endpoints for a living.

Compliance Readiness

Gap assessment first, then the recurring scanning and pentest evidence your SOC 2, HIPAA, PCI DSS or CMMC auditor asks for.

Know what an attacker would reach first.

Tell us what you run and what worries you. We will come back with a scope, a fixed price and the earliest week we can start.

Request a scope Email us