With more and more companies taking advantage of cloud computing for on-demand infrastructure and additional resources, penetration testers are being called upon to perform more security testing on virtualized environments. Clients may require testing for compliance standards like PCI DSS, or they may be evaluating multiple cloud providers for the most secure option. The cloud brings with it a new set of considerations for testers, as a virtual environment could house multiple tenants on the same architecture.
The first thing to decide is whether you are outsourcing pen testing to a third party or keeping it in-house with your security team. With a third party you will only need to mitigate any contract and SLA problems. Be sure to vet a third party thoroughly, asking exactly what they will test, what tools they will use, scan policies, whether they used white-box or black-box testing (in black box, the tester infiltrates without any previous knowledge of the environment, while white box is the opposite).
Either way you’ll need to know exactly what will be tested including which applications, database servers, devices including storage, and devices.
Are you testing on behalf of a service provider or a tenant? Tenants lease infrastructure from a service provider based on one of three models: Infrastructure as a Service, Platform as a Service, or Software as a Service. In an IaaS deployment, the virtual machine and everything on it is under control of the tenant, giving you leeway to attack everything up to the hypervisor. In PaaS, the provider sets up everything needed for a given application, up to and including pre-installed databases, so you have fewer options—really only the application and interface. Testing PaaS deployments can negatively affect other tenants. SaaS is a turnkey solution offering very few opportunities for testing, but you can still check out the application interface and API key management. If testing on behalf of a provider, every piece of the infrastructure is in play, so be thorough.
If you are testing a service provider for IaaS or PaaS, you should inquire about their existing security process. Ask about equipment types and architecture diagrams, security policies, patch management, and hardening or security audit protocol. For PaaS, you will need to check patches and updates for all relevant software.
Do you need permission from your cloud provider? Pentests can violate terms of service, not to mention laws. Make sure you don’t end up with your client’s service shutdown and data lost because the provider was unaware of your penetration test and treated you the same as any other attacker. Ask the cloud provider if they have a policy in place regarding security testing, and provide them with the expected time and date of the test and which virtual machines you plan to attack. They may request that you provide the IP address of the testing source, as well as the planned IPs and virtual machines you plan to test.
White box testing means you’ll know more about the environment and potential security holes. Black box testing might be more realistic as far as the conditions under which vulnerabilities are discovered, but you’ll have to work backwards to figure out what caused the vulnerability. Gather information directly from the provider to save time. Normally this would be a reconnaissance step, in which the tester explores the security measures in place, network settings, and other details to plan their route of attack. If you are testing on behalf of a cloud provider, or if you already asked permission to test your own cloud environment, your service provider may be able to give you these details ahead of time, allowing for more in-depth testing and sparing you the effort.
Talk to an infrastructure consultant today.
Testers should take care to only infiltrate their own instances, IPs, and ports. In IaaS or PaaS you will be sharing resources with other tenants and could impact their performance, which could violate your Terms of Service. When you notify your service provider about pen testing, ask what might be off limits due to multiple tenants.
Choose your favorite vulnerability scanners and back them up with manual validation. Check common web exploits and other application weaknesses. Your target will likely depend on the instance you are auditing: Microsoft Exchange server, database, backup server, storage, and/or application host. Attack the instance both from within the internal network and outside of it (employee vs. outsider hack). Your ultimate report should include details about security groups, who can access the API calls, and authorization protocol.
Web application firewalls (WAF) and reverse proxy servers should be disabled for the most useful results. Although these tools are handy, you want to discover holes in your own apps and code, not necessarily vulnerabilities in a firewall. For more complete results, run vulnerability scans on existing host security features like firewalls and Border Gateway Protocol (BGP) diversion while digging deeper via pen test into services and applications on your virtual machine.
Penetration testing in the cloud isn’t much different from traditional environments, but it does require additional planning and communication. Try to gather as much information as possible ahead of time, and work with the smallest amount of contacts at the service provider as possible, unless organizing a security test to see how their detection team reacts to penetration testing. This helps ensure a more legitimate, normal environment. If you’re unable to test any portion of your cloud, make sure to get configuration files, security audit policies, and previous penetration testing results from the provider. Read your Service Level Agreement (SLA) thoroughly and make sure you will be covered in the case of a security breach. Security in the cloud is still a combination of careful planning and constant vigilance.
Cortney Thompson is the Chief Technology Officer of Green House Data, a data center services company offering cloud hosting, colocation and managed IT with a sustainable focus. Cortney is a networking expert and a member of the NSF International Committee for Environmental Server Standards.