The solution to notify the CSP beforehand seems easy but has a few caveats. Communication is key here, and the method of communication is just as important to 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. The actual test should not deviate from this notification. The most important aspect of the limitations of cloud service penetration testing is where the responsibilities of the system start and end. This means it is important whether the target system is running within an IaaS (Infrastructure as a Service), PaaS (Platform as a Service) or SaaS (Software as a Service) configuration. IaaS will allow for much more intrusive and broad testing than SaaS, because of the difference in the level of responsibilities and possibly the risk to multi-tenant shared systems. For example, in an IaaS configuration, the Operating System of a target server is managed by and dedicated to the customer. In a SaaS configuration, this is not the case. A penetration test could affect the target and possibly cause an outage for other customers using that same shared system. In the worst case, there could even be an unintended information leak from another cloud customer. Determination of the responsibilities helps to set the scope of the test.
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 to another network via a VPN tunnel or multiple Network interfaces. Pivoting from a compromised cloud-based host to an external non-cloud system is usually not allowed by CSP’s which is something to keep in mind. 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 either. An attack such as this is very hard to separate from other, non-authorized attacks due to it’s 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 on other customers of the often shared CSP resources. A lot of the issues and limitations mentioned are not new. Solutions have been created, and these can be successful. It is quite common for CSPs to have their own internal penetration testing team and additionally to use a third party tester as well. Microsoft has an active offensive Red Team and a Defensive Blue Team within their Azure platform. Other large providers most likely have similar systems in place. While this effort will keep the platform itself secure, customer systems and applications are still out of the CSP’s scope. As mentioned earlier with regards to the limitations, these customer systems are naturally the responsibility of the customers themselves. Some CSP’s offer their own internal penetration testing team to customers as a paid service. This takes away from a lot of the 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 their own tests, items such as pivoting could be amongst the options as well. Nettitude is another example of a cloud penetration testing provider, but most larger specialized security firms can now offer this service up to a certain level. Time has not stood still around Cyber Security while the connected world moved more and more towards cloud solutions over the last decade. Several large breaches of internal corporate systems have proven cloud security might not be so bad in comparison after all. With this move, Penetration testing has adapted to the new challenges. New external services have sprung up, and existing services both on the side of the cloud provider and on the side of customers and third parties have incorporated the new methods and technologies.
