Melpomene - Fotolia
A holistic security approach should always include penetration testing. Not only is it good practice to conduct regular penetration tests on all enterprise IT systems, but it is quite often also a requirement to maintain compliance with PCI DSS or other regulations. With the move toward the use of more cloud infrastructure and applications, some complications can arise around cloud pen testing.
Cloud service providers such as Amazon, Azure and Google manage the security and availability of their cloud infrastructure like any large enterprise. They monitor and investigate security events and incidents. Cloud service providers, or CSPs, need to be able to differentiate between a customer's penetration test and an actual attack on the environment. If there's a mix up, site traffic could be dropped, blocked or blackholed by DDoS protection or intrusion prevention systems. Not only would this cost the CSP valuable time and resources, but the shared nature of a cloud environment means this could negatively impact other users as well.
The importance of communication
Notifying the CSP about cloud pen testing before there is a problem seems like an easy fix, but there are a few things to keep in mind. Communication is key, and the method of communication is just as important as the message itself. The CSP will need to be alerted in a timely, clear and precise manner. The notification should include the time and scope of the planned test, and the actual test should not deviate from this notification.
Most providers such as Amazon and Microsoft have instructions, limitations and authorization request forms available on their websites. Google works a little differently. It states there is no need to contact Google about cloud pen testing as long as the tester adheres to the Acceptable Use Policy and the Terms of the Service agreements. Google also notes that penetration testing is only allowed to affect the tester's projects.
Limitations on cloud penetration testing
It's important to consider the limitations on cloud service penetration testing. This means being aware of what your responsibilities are for the system being tested. The configuration of the target system -- IaaS, PaaS or SaaS -- will determine the tester's level of responsibility. For instance, IaaS systems will allow for much more intrusive and broad testing than SaaS, because of the difference in the level of responsibilities and the potential risk to multi-tenant shared systems. Also, in an IaaS configuration the operating system of a target server is managed by and dedicated to the customer. This is not the case in a SaaS configuration. A penetration test could affect the target and possibly cause an outage for other customers using that same shared system.
Another aspect to consider when planning a penetration test on a system within a cloud platform is whether pivoting is required. Pivoting is a common attack technique where a system is compromised to attack another system via that obtained access. This might, for instance, circumvent firewall filtering. It could also allow the attacker to leverage a trusted service between two hosts or to jump on another network via a VPN tunnel or multiple network interfaces. Keep in mind that pivoting from a compromised cloud-based host to an external non-cloud system is usually not allowed by CSPs. This could limit the penetration tester, but will not be an issue for a real attacker, which means the test is incomplete.
A distributed denial of service attack (DDoS) is usually not permitted in cloud pen testing either. An attack such as this is hard to separate from other, non-authorized attacks due to its distributed characteristics. The hundreds or thousands of source IP addresses covering multiple simultaneous DDoS attacks cannot be confidently split. This can trigger automatic mitigation systems and that will negatively impact other customers of shared CSP resources.
Cloud penetration testing techniques
It is quite common for CSPs to have their own internal penetration testing team and to also use a third-party tester. Microsoft has an active offensive red team and a defensive blue team within its Azure platform. While this effort will keep the platform itself secure, customer systems and applications are out of the CSP's scope.
See Infosec Institute's accompanying article on Penetration Testing and Cloud Platforms
Some CSP's offer their own internal penetration testing team to customers as a paid service. This takes away many planning and communication concerns of the customer and also reduces the number of mandatory limitations to the testing methods. A DDoS attack can be directly targeted at a system from the internal cloud network, for instance. This will limit the impact to the bandwidth and the resources of other customer's systems. Because the CSP has much more control over its own tests, techniques such as pivoting could be amongst the options as well.
Many large third-party security firms now offer a specialized cloud pen testing service up to a certain level.
Several large breaches of internal corporate systems have proven cloud security might not be so bad in comparison. So as more organizations move to the cloud, penetration testing adapts to the new challenges. New external services have sprung up, and existing services on the side of the cloud provider and on the side of customers and third parties have incorporated the new methods and technologies. Overall, the cloud pen testing process should not be much different from the traditional penetration test.
Learn how penetration testing varies for different CSPs
Find out how to conduct a successful pen test on AWS
Discover the most important areas of the PCI Penetration Testing Guidance