Cloud penetration testing

A cloud penetration test looks at what you have built and configured in your cloud accounts. Typical areas are:

• Identity and access: who and what can sign in, with which permissions, and whether any of those permissions are wider than they need to be.
• Exposure to the internet: which services, storage and management interfaces can be reached from outside.
• Storage and data: whether data stores are protected and encrypted as intended.
• Network separation: whether environments that should be kept apart, such as production and development, really are.
• Logging and monitoring: whether the activity during the test was recorded and noticed.
• The workloads themselves: the servers, containers and applications you run there, which are often tested alongside.

The NCSC’s guidance on the shared responsibility model explains that security is split between you and the provider, and the split depends on the kind of service. Whatever the service, some things stay with you: checking it meets your needs, configuring it securely, deciding what data goes into it, and controlling who has access.

Those are exactly the things a cloud test examines. The more you build yourself on infrastructure services, the more there is to test; with software-as-a-service, the test usually narrows to your settings, accounts and integrations.

Each major provider publishes its own terms for security testing of resources hosted with it:

• AWS: its penetration testing policy lets customers test their own resources on a list of permitted services without prior approval, restricts denial-of-service testing, and asks for advance notice of some simulated events.
• Microsoft Azure: Microsoft’s rules of engagement apply to customers and the consultants they authorise, and rule out denial-of-service testing and access to other customers’ data.
• Google Cloud: testing must stay within the acceptable use policy and your agreement with Google, and some products have their own notification rules.

These terms change, so ask each firm how it checks the current rules for your provider, and keep the confirmation with your scope.

• List the accounts, subscriptions or projects in scope, and the regions you use.
• Say which services you rely on, and which workloads or applications should be tested alongside.
• Decide whether you want a configuration review, a penetration test, or both, and ask firms to price them separately.
• Agree the access you will give: read-only access for a review, and test identities for any assumed-breach scenario.
• Name anything out of scope, such as third-party SaaS you cannot authorise testing of.
• If card data is involved, say so: the PCI DSS requirements then shape the scope.

The NCSC’s penetration testing guidance describes a typical engagement as scoping, testing, reporting and follow-up, so agree all four up front. The free scoping template has a cloud section.