Skip to content

ISO 27001, SOC 2, the DPDP Act and manual VAPT. Book a Free Scoping Call

Cloud security

Cloud Security Assessment: Scope, Access and Deliverables

A cloud configuration review reads your settings and compares them with a benchmark; a cloud penetration test proves what an attacker does with the ones that are wrong. SecureRoot offers both. Its Cloud Security Configuration Assessment works from read-only access, grades each account against the CIS Foundations Benchmark for its provider, and returns a scorecard per account and a hardening runbook. Its Cloud Penetration Testing service includes that configuration review, then follows identity attack paths by hand, with a proof of concept behind each finding and a verified retest. In both, you create the access inside your own identity system, the scope covers accounts, identities, network exposure, storage and logging, and the work stays inside your own tenancy, as the AWS, Azure and Google Cloud policies require.

Request an assessmentContact SecureRoot

About this guide

Written by SecureRoot Risk Advisory LLP.

Two different services

Configuration review or penetration test

The difference is breadth against depth, and it decides the access you grant and the report you get.

  • Configuration review (SecureRoot's Cloud Security Configuration Assessment): reads configuration across identity, network, storage, logging and compute in every in-scope account, grades it against the CIS Foundations Benchmark for each provider, verifies the high-impact items by hand, and stops short of exploiting anything. It works from read-only access and can run on live systems during business hours. It covers AWS, Azure and Google Cloud.
  • Penetration test (SecureRoot's Cloud Penetration Testing): contains the same kind of benchmark review as one phase, then maps roles, policies and trust relationships, follows identity attack paths from a foothold, escalates across roles, pivots between services and shows what the chained path reaches in data stores, secrets and workloads. It covers AWS, Azure, Google Cloud, DigitalOcean and Oracle Cloud.

Which comes first depends on where you are. If your accounts have never been benchmarked, start with the configuration assessment, because paying for exploitation of a public bucket teaches you little. If your baseline is already clean, the penetration test is the sharper spend. A list of two hundred benchmark deviations does not tell you which three of them put customer data one API call away; that is the question the penetration test answers.

What is in scope

Accounts, identities, network exposure, storage and logging

Scope is drawn by account, subscription and project, and then by what is read inside each one. The catalogue for both services names these areas:

  • Accounts: the AWS accounts, Azure subscriptions and Google Cloud projects in scope, and the provider mix.
  • Identities: users, roles, policies and key age; trust relationships and federation with identity providers; multi-factor and conditional access on privileged identities; wildcard permissions and where they lead.
  • Network exposure: security groups, network ACLs and VPC peering, and which endpoints are reachable from the internet.
  • Storage: bucket access settings, public access settings and encryption, with encryption at rest and key rotation checked on data stores.
  • Logging: whether audit logging such as CloudTrail, Azure Monitor and Google Cloud audit logs is switched on and retained, and monitoring coverage.
  • Compute and workloads: configuration of the services running your workloads; in a penetration test, what a chained attack path reaches.

Multiple accounts behind one identity provider need care. An account boundary is only real if identity does not cross it, and estates are often rejoined by a management account, a shared build role, a cross-account trust policy or federation into each account. SecureRoot advises scoping non-production accounts in wherever those links exist. Leaving them out lowers the quote and leaves untested the path a tester would otherwise have proven.

Before work starts

What you provide

You create the access inside your own identity system and the tester works within it. Neither service asks you to share a password or an existing administrator's session.

  1. 01

    List the accounts, subscriptions and projects

    Name each one in scope and the provider it sits on. For the configuration assessment, SecureRoot fixes the CIS Foundations Benchmark version per provider at this point, so the control references on the scorecard line up with the ones your auditor reads.

  2. 02

    Create a read-only assessor role

    A read-only role at the account, subscription or project level is what the configuration assessment uses, and what the configuration phase of the penetration test uses.

  3. 03

    For a penetration test, create a limited test principal

    A second principal, scoped to the paths agreed with you, lets the tester demonstrate privilege escalation without improvising permissions mid-test. SecureRoot asks that both are created for the engagement, time-bound to the testing window and revoked at the end, which leaves your team a record of what was touched and by whom. If you would rather see the unauthenticated view first, testing can start from outside with no credentials.

  4. 04

    Name the exclusions and windows

    Agree any regions, services and maintenance windows to exclude, the testing windows, and the contacts on both sides.

  5. 05

    Share your own cloud policy, if you have one

    Where your internal cloud policy differs from the benchmark, the assessment flags the deviation, so the next assessment opens from a written position.

Provider rules

What AWS, Azure and Google Cloud allow

The major providers let customers test the resources they control, under policies each one publishes. A configuration review that only reads settings sits well inside them; a penetration test has to be planned against them. SecureRoot reads the current policy for each provider in scope during scoping rather than relying on last year's wording.

  • AWS: customers can test a listed set of services without prior approval, including EC2, RDS and Aurora, CloudFront, API Gateway, Lambda and Elastic Load Balancers. Testing other services means working with AWS Support or your account representative. AWS prohibits DoS and simulated DoS, port, protocol and request flooding, DNS zone walking through Route 53, and S3 bucket or subdomain takeover. Testing that includes command and control needs prior approval, and red team exercises, simulated phishing and malware testing go through AWS's Simulated Events form, submitted at least two weeks before the start date. Stress tests and DDoS simulations have their own policies.
  • Microsoft Azure: Microsoft's rules of engagement confine encouraged testing to your own tenant or assets you are explicitly authorised to test. They prohibit denial-of-service testing, network-intensive fuzzing or automated testing that generates excessive traffic, using credentials that are not yours, and interacting with storage accounts you do not own. A vulnerability in a Microsoft service is reported to the Microsoft Security Response Center.
  • Google Cloud: you do not need to contact Google before testing your own Cloud Platform infrastructure, provided testing follows the Acceptable Use Policy and Terms of Service and affects only your own projects. The Acceptable Use Policy prohibits testing or reverse-engineering the services themselves to find limitations or vulnerabilities, so the platform is off limits even where your projects are not.

The boundary in all three is where your tenancy ends. Your workloads, identities, storage and network configuration are yours to authorise. The provider's shared infrastructure, other tenants and the internals of a managed service you rent rather than run are not. What is in scope, what is excluded and who may change it go into the signed Rules of Engagement.

What you receive

Deliverables, as SecureRoot's catalogue states them

Cloud Security Configuration Assessment:

  • Cloud configuration findings report, with each finding rated by exposure and blast radius, the affected resource identifiers listed, and findings grouped by owning team and account.
  • CIS benchmark scorecard by account. Controls you cannot meet stay visible as accepted deviations with a reason, and false positives are discarded with a documented reason.
  • Cloud hardening runbook, with fix steps mapped to each control and infrastructure-as-code snippets, so the fix goes into the pipeline that builds the environment.
  • Re-check report after remediation: the checks are re-run once your changes land and the scorecard is reissued showing the movement.

Cloud Penetration Testing delivers a findings report with mapped attack paths, a configuration review against CIS Benchmarks, an executive summary, remediation guidance with prioritised fixes per provider, and a verified retest report. Findings are scored with CVSS v4.0 and mapped against MITRE ATT&CK.

Neither service has a published price band or timeline: both are quoted with the scope. The pricing page shows how SecureRoot prices its other testing.

Scope boundaries

What this does not cover

  • A configuration review sees configuration. It does not read the contents of your data stores, decrypt anything, or reach into running application logic, so a broken authorisation check inside your own code will not surface. It also cannot prove that an over-permissive role is exploitable, because proving that means using it.
  • A scorecard is a photograph of one moment, taken from a timestamped evidence set. A console change made the week after will not appear in it.
  • Neither service tests the provider's shared infrastructure, other tenants, or the internals of managed services. Simulated denial of service and stress testing need separate arrangement and, depending on the provider, the provider's own process. Physical intrusion and social engineering are outside both.
  • The applications and APIs running in the cloud are separate surfaces. Test them with a web application or API penetration test, and review their code with secure code review.
  • SecureRoot writes the fix steps; your engineers apply them through your own change process. SecureRoot does not change your estate.
  • A CIS scorecard is not a certificate, and neither service guarantees compliance with any standard or regulation. SecureRoot is not a certification body, a CPA firm or CERT-In empanelled.

Questions

Common questions

  • Do we need permission from AWS, Azure or Google Cloud before a cloud assessment?

    For ordinary testing of resources you control, generally no, but each provider sets conditions. AWS lists the services you can test without prior approval and requires approval or its Simulated Events form for command and control, red team, phishing and malware testing. Microsoft confines testing to your own tenant. Google Cloud requires no notice if you follow its Acceptable Use Policy and Terms of Service and affect only your own projects. All three restrict denial-of-service testing.

  • Do you need administrator credentials?

    No. The configuration assessment uses a read-only role you create. A penetration test adds a limited test principal scoped to agreed paths. SecureRoot asks that both are time-bound to the testing window and revoked at the end.

  • Is a retest included?

    Yes. The configuration assessment re-runs its checks after your fixes and reissues the scorecard, and Cloud Penetration Testing ends with a verified retest report.

  • Should we run the configuration review or the penetration test first?

    The configuration review first if your accounts have never been benchmarked; the penetration test first if your baseline is already clean. Where both sit in one programme, the benchmark work is done once.

Primary Sources

Where the Figures on This Page Come From

Every deadline, threshold and control count above is taken from the instrument itself. These are links to the primary text, not to a summary of it.

Related

Services and help that go with this

Tell us which accounts are in scope

Send SecureRoot your provider mix and the accounts, subscriptions or projects you want covered, and we will say which assessment fits and quote it in writing.

Request an assessmentContact SecureRoot