SecureState Blog

Read SecureState's award winning blog.

With the growth of cloud computing, many organizations are now finding themselves looking to move services to a cloud service provider or are often finding that parts of the business have already done so without the knowledge of the Information Security group. These organizations wrestle with what security should be applied to the cloud-based deployment as well as what they’re actually able to do from a security perspective. One area where companies seem to become lost is when talking about performing penetration testing services against their deployment. While there are some details to work out, fundamentally this type of assessment translates well when talking about applications and infrastructure deployed in the cloud.

Do we need to bother?

One question often asked is “The cloud service provider states that they perform their own penetration testing. Do we need to do it?” Absolutely. One interesting thing about the cloud model is that there is a shared responsibility model. So, while the provider may be performing their own assessments, the scope will be limited to only what they own. So, for example, if you are using Infrastructure as a Service (Iaas) the provider will stop just short of where your guest virtual system lives. If your build contains issues such as vulnerable software packages or weak authentication the provider will have no knowledge of this and therefore your systems are exposed to these vulnerabilities. However, having your own assessments performed against your cloud resources gives you the visibility into the portion of the space that you own. You can think of your cloud deployment as an extension of your existing network. All of the existing rigor you have placed in terms of controls and practices that you perform on your existing networks, such as penetration testing, should also carry over to externally hosted deployments as well.

The Right to Audit

Whether or not you are allowed to perform security assessments against your cloud-based resources is where it starts to become a little tricky. This is really dependent on what your contract language stipulates in terms of a right to audit in conjunction with the provider’s acceptable use policy. The cloud provider is servicing many customers, and their job is to make sure all of their customers’ resources are available all the time. So when outside parties come in and start talking about kicking up sand in the sandbox walls they have diligently built, they rightfully become concerned. The farther down in the stack that the responsibility line goes (See Figure 1) the easier it is to perform this kind of testing, however the team performing the penetration testing needs to fully understand where exactly the boundary is between provider and tenant regardless of the service model.

IaaS often is an easier sell to the provider for penetration testing and most large providers understand this and have provisions in place to allow testing. However, with Platform as a Service (PaaS) and Software as a Service (SaaS) this becomes an area that needs to be carefully navigated by the assessment firm, you, and the cloud provider. Make sure to read your contract language to see what it says, or better yet, make sure to add an audit and assess clause within the contract before signing up for service.


While it may be possible to perform penetration testing on PaaS and SaaS dependent upon what the provider permits, it often makes more sense to perform a Web Application Security Assessment or Web Services Assessment instead. These types of tests focus on the application layer and can provide information as to how secure the application and the data housed within the application are. Additionally, a White Box Web Application Security Assessment can be performed which audits the source code of the application and requires no interaction with the cloud provider itself, so this can be a valuable workaround for providers with a strict no security testing policy.

The Importance of Scope Definition

Since the cloud is a multi-tenant environment, it is extremely important to make sure the scope is appropriately set for the penetration test. Since resources such as IP addresses may change within the environment the penetration testers should make sure to have the most up-to-date information about your deployment as close to the start of testing as possible. This will prevent any accidental testing of resources not owned by the client and violating terms of service. Additionally, as seen above, the type of deployment will affect the scope of the assessment as well since the client’s ownership ends at various points depending on if they are an IaaS, PaaS, or SaaS model. This needs to be fully discussed with the firm performing the penetration testing services as they will need to understand how deep and wide they are permitted to go while performing their assessment. For example, if a PaaS model is being tested and a vulnerability such as command injection is found, it would most likely violate the cloud provider’s terms of service if that were to be exploited since the operating system is a shared resource across the provider’s tenants. However, for an IaaS deployment the client manages the virtual machine running the operating system so exploitation is more than likely in scope. With the right discussions and analysis up front between the client and penetration testers, proper care can be taken to provide a thorough assessment while also preventing landing in the cloud service provider’s hot seat.

Movement to cloud-based computing will continue to grow over the next few years, so understanding these points now is an important tool in making sure your deployments are as secure as possible. Fundamentally, performing penetration testing against cloud-based deployments is not much different than any other target. The main difference is making sure that proper authorization is received from the cloud service provider as well as making sure that proper communication and discussions take place with the penetration testing firm up front. Integrating this into a repeatable process within your organization will position you well for being able to understand the security of all of your resources regardless of where they are deployed.