July 3, 2019

Last Updated on January 15, 2024

Just because you moved your virtual servers, databases and/or applications to the public cloud doesn’t mean they are somehow now magically secure. You still need penetration testing to verify your cloud environment is secure and to uncover any potential risks.
Full disclosure, I make a living conducting pen tests, so you could say I’m biased… and you would be right. But please, hear me out.
Your public cloud service provider is only responsible for securing the cloud infrastructure, hypervisor platform, etc. that they are contracted to provide. Everything from there on up is your responsibility; e.g., your configured environment on the hosted platform, and any additional application code, databases or other assets. Even in the case of hosted applications like Salesforce, you still need to manage identity and access controls and ensure that confidential data isn’t exposed due to misconfiguration.
Most cloud-based penetration testing focuses on misconfigurations and resource issues that create vulnerabilities like credential theft, data theft or leakage via unsecure interfaces, storage exposure and storage takeover.
Depending on whether your cloud instance involves hosted infrastructure (IaaS), a hosted application platform (PaaS) or a hosted software application (SaaS), you may need to test areas like:

  • Cloud storage services and ports—are any unused that should be blocked?
  • Your Amazon Simple Storage Service (S3) object storage “buckets” (especially their configuration and authentication).
  • Network access.
  • APIs that your cloud-based services are using. Non-secure or improperly used API calls can expose cloud-based services to things like credential theft, remote code execution (RCE) attacks, DDoS attacks and data leakage.
  • Your web application itself, minus whatever services are provided by your CSP.

Equally as important as scoping what to test is recognizing what not to test. The hosted foundation that you build your environment on cannot be penetration tested. Such activity will be interpreted as an actual attack and will set off alarms, get your service shut down, and probably net you some very irate phone calls as well.
Before you do any actual testing, you need to carefully examine the CSP’s policies regarding pen testing so you’re aware of their applicable restrictions and recommendations. You should also notify the CSP that you plan to carry out a pen test.
Especially because pen testing in the public cloud can “wake the neighbors” and cause problems that could impact your users, it’s a good idea to create and review a penetration testing plan. The plan should cover what will be tested, how it will be tested, why it will be tested, what automated and hands-on tools and techniques will be used, and the approach you’ll use (white box, black box, notify admins or not, etc.). You many also want to plan for ranking and mitigating any vulnerabilities that are reported.
If you need to verify security for areas of the cloud infrastructure that you can’t directly test, you may be able to confirm with the CSP that compensating controls exist. Ask CSPs for audit reports, security review documents, patching records, results from their own pen testing, or even architectural design details or configuration guidelines.
Because of the contract and service level issues that are likely involved in testing inside someone else’s data center and infrastructure, it’s a good idea to rely on experienced penetration testers for pen testing in the public cloud. If you plan to use a third-party, make sure they have experience with similar testing and can take the lead on working with the CSP so that you’re not stuck in the middle.
Bias or not, I hope I’ve made the point known that you can receive significant benefit from a penetration test of your public cloud environment.
To talk over any questions or concerns you may have about penetration testing in the cloud, contact Pivot Point Security.
For more information: