Skip to content
SecuriFii

Technical testing

Cloud Security Assessment

The cloud incidents that make the news are rarely clever. They are an identity policy nobody read, a storage bucket made public by a default, a key that never expired. The provider secures the platform; how you configure what runs on it is yours, and that is where we look.

Discuss this
Standard
CIS Foundations Benchmarks
Providers
AWS · Azure · Google Cloud
Model
Shared responsibility
Access needed
Read-only
Retest
Included

Your half of the shared responsibility model

Every major provider describes security as shared. AWS puts it as security of the cloud, which it owns — the hardware, software, networking and facilities that run its services — and security in the cloud, which is yours and grows with the services you choose. Microsoft states that whatever the deployment, the customer always retains responsibility for its data, endpoints, accounts and access management. Google describes the same split, and pairs it with what it calls shared fate: working with customers to help them get their side right.

A cloud security assessment is a review of your side. We read your configuration — identity and access policy, network exposure, storage permissions, logging and monitoring, key and secret management — and test it against the CIS Foundations Benchmarks: the CIS Amazon Web Services Foundations Benchmark, the CIS Microsoft Azure Foundations Benchmark and the CIS Google Cloud Platform Foundation Benchmark.

A benchmark is a floor, not a verdict. It tells you which settings are off; it does not tell you that a role in a development account can assume a role in production, or that a forgotten function holds a key to everything. So alongside the benchmark we trace the paths an attacker would take from a small foothold to the data that matters, and where you want it, test the services you expose to the internet as well.

A review and a test

Reading the configuration and attacking what it exposes answer different questions, and the configuration changes far more often than the architecture. Most organisations need the first on a short cycle and the second alongside their network test.

Configuration review

The cloud estate changes whenever somebody provisions something, which is continuously and often without review. A quarterly review against the benchmark, with the identity paths traced again each time, keeps drift from quietly becoming exposure.

Recommended cadence
Quarterly, and after major account changes

Identity and access, network exposure, storage, logging, keys and secrets

Cloud penetration test

Attacks what the configuration exposes, within each provider’s published testing rules, and tests what an attacker could do with a leaked access key or a compromised workload identity. It belongs on the same cycle as the external network test, because to an attacker they are one perimeter.

Recommended cadence
Annually, with the external network test

Internet-facing services, serverless functions, gateways and what a compromised credential can reach

What it will ask of you

A configuration review is fast to run and slow to scope well. These are the things that decide whether it covers your cloud or only the account somebody remembered to share.

  • A complete list of accounts

    Every AWS account, Azure subscription and Google Cloud project, including development, sandbox and the ones a former team created. Attack paths usually start in the account nobody was watching.

  • Read-only access, granted properly

    A read-only role or reviewer identity in each account, created for the assessment and removed afterwards. We do not need, and will not ask for, write access or long-lived keys for a configuration review.

  • Authority over everything you want tested

    For any active testing, written authorisation from whoever owns the resources. Each provider requires testers to stay within its rules and to affect only your own resources, and some tests need the provider’s approval first.

  • Someone who can explain the exceptions

    An engineer who knows why that bucket is public and that role is broad. Some deviations from the benchmark are deliberate, and a review that cannot tell a decision from an accident wastes everyone’s time.

What it is used for

  • Evidence for ISO/IEC 27001 and SOC 2 that cloud configuration is reviewed against a defined baseline.
  • Answering customer questionnaires that ask how your cloud environment is secured and how often that is checked.
  • A baseline before or after a migration, an acquisition, or a move to a new provider or region.
  • Finding the over-permissive identities that turn a small foothold into a large incident.

Not sure this is the standard you need?

Tell us what triggered the question — a customer, an auditor, a contract clause — and we will say which of these applies, including when the answer is none of them.

Ask a practitioner

Where we come in, and where we stop

We are the assessor for your configuration: we review it, test it, report and retest ourselves. We do not assess or certify the cloud provider. Their side of the shared responsibility model is covered by their own audits and published reports, and AWS for one does not permit customers to assess its infrastructure or services themselves. Nor will we review a cloud architecture we designed for you and present it as independent assurance of our own work.

Ours

  • Scope, rules of engagement and the authorisation
  • Configuration review against the CIS Foundations Benchmarks
  • Tracing identity and network paths to sensitive data
  • Testing exposed services within each provider’s rules
  • The report, remediation guidance and the retest

Yours, and the provider’s

  • Authorising the assessment and granting read-only access to every account in scope
  • Owning remediation of your configuration, with our support
  • The security of the cloud platform itself, which remains the provider’s

How an engagement runs

Configuration review runs on read-only access. Any active testing proceeds only under written authorisation and within the provider’s published rules, and we will tell you if any part of it needs the provider’s approval first.

  1. 01Scope and accessWe agree the accounts, subscriptions and projects in scope, set up read-only access in each, and, if active testing is included, agree the targets and rules of engagement.
  2. 02Benchmark reviewEach account checked against the relevant CIS Foundations Benchmark, with every failed control confirmed by hand rather than reported straight from a tool.
  3. 03Identity and exposure analysisWho can assume what, which keys are long-lived, what is reachable from the internet, and the paths from a low-privileged identity or exposed workload to the data you care about most.
  4. 04Testing exposed servicesWhere included, testing of internet-facing services and of what a leaked credential could reach, within each provider’s published testing policy.
  5. 05ReportingAn executive summary, and findings with severity, the exact resource and setting, evidence and the fix — as a console path and as the change to your infrastructure code where you use it.
  6. 06Remediation support and retestWe work through the findings with your cloud engineers, re-review the fixed configuration and issue a retest letter you can hand to an auditor or a customer.

What you get from us

  • Executive summary written for a non-technical reader
  • Findings per account against the relevant CIS Foundations Benchmark
  • Identity and exposure paths to sensitive data, drawn out step by step
  • Remediation as console steps and as infrastructure-as-code changes where you use it
  • A prioritised backlog your cloud team can pick up directly
  • Re-review of remediated findings and a retest letter for third parties

Common questions

Do we need the cloud provider’s permission?

For most testing, no, but each provider has rules. AWS allows testing of a listed set of services without prior approval, requires approval for anything outside the list and for command-and-control testing, and prohibits denial-of-service testing outside its separate simulation policy. Microsoft has not required pre-approval for Azure since June 2017 but requires testers to follow its Unified Penetration Testing Rules of Engagement. Google does not require you to contact it, provided you follow its terms and affect only your own projects.

Is a configuration review a penetration test?

No. A review reads your configuration and judges it against a baseline and against attack paths; a penetration test attacks what that configuration exposes. Reviews usually find more, because most cloud weaknesses are visible in the configuration and never need exploiting to prove. A test confirms what an attacker could actually do. Many clients need the review more often and the test once a year.

Will you certify our cloud environment?

No. We review and test; we do not issue certificates, and a review against a CIS Benchmark is not a certification. What you receive is a dated report of what we reviewed, what we found and what was fixed, which is the evidence an auditor or a customer is actually looking for.

Our provider is certified. Does that cover us?

It covers the provider’s side: the facilities, hardware and the services as operated. It does not cover how you have configured them. A provider’s certificate says nothing about a public storage bucket in your account, and every provider’s own shared responsibility model says so.

We already run a cloud security posture tool. Why do this?

Keep running it — continuous checking is worth having. A tool reports settings that fail a rule; it does not usually tell you which of two hundred findings form a path to your customer data, or that a failing setting was a deliberate decision. The review does that, and makes the tool’s output usable afterwards.

Ready to scope it?

Send the date you are working to and roughly how large the organisation is. You will get a reply from a practitioner with an honest read on whether the date is reachable.

Start the conversation

Related services

  • Vulnerability Assessment and Penetration Testing (VAPT)

    Find what an attacker would find, ranked by what it would actually cost you — and get a report your auditor and your engineers can both use.

  • Network Penetration Testing

    Test your network the way an outsider would, then the way someone already inside would — and prove that the boundaries you rely on to keep systems apart actually hold.

  • API Security Testing

    Find the request that returns somebody else’s data — the flaw that leads the OWASP API Security Top 10 and the one an automated scanner cannot recognise.

  • ISO/IEC 27001 — Information Security Management

    Build an information security management system that survives Stage 2 — and the three years of surveillance that follow.

  • SOC 2 Type 2 Readiness

    Evidence that your controls ran for months, not that they existed on a date — the report enterprise procurement usually means.

All services

Related insights

All insights