One of the most difficult challenges for security professionals when it comes to moving to a cloud environment centres around the increased complexity of domain ownership as it relates to penetration testing. The key reason for this is that in a private cloud environment, meaning the entire infrastructure is physically located in domains where the organization has full control over every aspect, security teams generally maintain control of the infrastructure from a policy standpoint, and can perform various security processes without requiring the intervention of outside resources. Once the infrastructure is moved off-site to a hosted model such as IaaS, PaaS or SaaS, suddenly the provider becomes an extension of your IT team and part of the security equation. This is just the beginning of the effect cloud has on vulnerability and penetration testing.
If your organization requires the need to perform penetration tests on your cloud-based environment, there are many factors that will influence how complex the process will be. Firstly, the SLA between you and the cloud provider will have the largest effect. Depending on whether your SLA includes a clause for penetration testing, you will have varying levels of control over the process. You need to ask whether the SLA allows for internal resources to provide the pen test (assuming you have the internal resources) or if it must be done by a resource designated by the provider. In addition, the SLA should stipulate what domains you have control over for testing, and what specific vulnerabilities can be tested (some types of test might affect the overall compliance state of the infrastructure and can be excluded). This must be measured against the goals of your security team, as if it doesn’t meet the requirements, there is no sense performing the test.
The second key issue (assuming you get permission from the cloud provider to perform the pen test) is what kind of service your organization subscribes to. This will define exactly what you can and cannot test. In IaaS models, you have significantly more control over the environment and the types of tests that you can perform versus in an SaaS environment where you are less likely to test anything outside the actual application. In IaaS environments, its recommended that you review any documents from the provider that relate to to security policies and network architecture design. If you are utilizing them for the penetration tests, ask them to perform a vulnerability scan on your portion of the infrastructure. Keep in mind, that in an IaaS model, you are responsible for most of the security and any gaps that the provider may have.
If you are using SaaS, the provider will have most of the control over security policies, but you should ask for penetration testing performed on the web layer to make sure that there are no web application vulnerabilities, and that they check for these regularly or use a web application firewall to protect your resources. It is also important for any type of service model to ask the provider what kind of testing they do (black, grey or white box), what they test for (top 10 or top 20 OWASP vulnerabilities), and what kind of reports they provide.
If you plan to perform the tests yourself, you will need to work with the provider to ensure that any tools and processes you use does not affect the integrity of other customers who might share the provider’s infrastructure. Standard tests that might work for an internal environment can wreck havoc on cloud environments as they may bypass some of the security controls in place to protect the individual virtual environments. It is the customer and the provider’s responsibility to ensure that if these tests are to be performed, that the scope is agreed upon in advance.