This tip is a part of the SearchSecurityChannel.com mini learning guide, Penetration testing tutorial: Guidance for effective pen tests
As organizations look to public cloud providers like Google Inc. and Amazon Inc. to host services and applications, they require vulnerability assessments and penetration tests (pen tests) to satisfy internal policies and compliance requirements. Penetration tests in the cloud differ from pen tests on a network maintained entirely by the organization itself. This tip explains how to penetration test a cloud service provider’s (CSP’s) environment to validate CSP security for your customers.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Are pen tests allowed in a cloud?
The type of cloud (as well as the type of cloud provider) will determine whether pen testing is permitted. Most Software as a Service (SaaS) providers don’t allow testing, as it will likely impact their infrastructure. Customers using Salesforce.com, for example, are not allowed to perform pen tests. Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) providers may allow pen testing, but coordination is required. Ideally, the contractual language the customer has in place with the CSP states pen testing is allowed (the more explicit language, the better) and clarifies what kinds of tests are permitted, as well as the frequency of the testing.
Some tests are explicitly prohibited across most, if not all, CSPs, including denial-of-service (DOS) and other attacks that consume bandwidth and cloud system resources.
Once it has been determined that pen testing the cloud provider’s environment is permitted, the next step is to coordinate the test details with both the customer and the CSP. Some CSPs make their coordination requirements clear, while others must be explicitly asked how they prefer the testing to be performed. Some CSPs try to facilitate the process by providing online resources that testing firms can use for coordination. Amazon, for example, has a simple form on the AWS site that can be filled out to start the process. All CSPs require explicit permission from the customer whose resources are in the cloud. This communication between the CSP, the customer and the solution provider who is performing the test may take some additional time, and it’s best to add a week on the front end of the project for project planning.
Types of pen tests for the cloud
It’s important to learn about the types of pen tests the CSP allows. Some tests are explicitly prohibited across most, if not all, CSPs, including denial-of-service (DoS) and other attacks that consume bandwidth and cloud system resources. The primary reason for this is because systems in cloud environments are hosted on virtualization platforms with other customers’ systems (a condition called multi-tenancy). Any attacks that consume bandwidth or local system resources may impact multiple customers’ data and system performance.
CSPs are also unlikely to allow solution providers to compromise cloud resources and then use those systems to attack additional resources outside the CSP’s cloud, primarily for liability reasons. This may significantly impact the normal methods solution providers use to perform vulnerability assessments and pen tests; chaining attacks through one compromised system to attack another is a very common form of testing. For systems hosted within the same cloud, this is usually not a problem.
PaaS clouds may have specific system types hosted in their cloud, resulting in an organization’s systems being spread across multiple providers. For example, organizations may host Web servers within Amazon’s EC2 cloud, while hosting database servers with Microsoft’s Azure service. In this case, service providers need permission from both organizations, Microsoft and Amazon, for a complete penetration test of the Web application infrastructure, and there may be additional stipulations from one or both CSPs, as well.
Tools for pen testing
Luckily for solution providers, new tools are emerging that may facilitate cloud-based penetration testing. One example is Core Security Technology’s CloudInspect, a cloud-based penetration testing solution that is closely aligned with Amazon EC2. CloudInspect is designed to simplify scheduling and coordination with Amazon, and to provide more professional testing tools for the cloud. CloudInspect is easy to use. Amazon has endorsed CloudInspect as a tool EC2 customers can leverage to satisfy compliance requirements and meet security testing needs within the AWS cloud. Other assessment tool vendors will likely turn their attention to CSP testing and, meanwhile, many have cloud-based platform options, including Rapid7’s Metasploit Pro and SAINT Corporation’s WebSAINT.
Solution providers need to work with their customers to understand the kinds of systems and applications they have in the cloud, plan on additional coordination time and adjust for testing limitations when performing pen tests on cloud-based resources.
About the author:
Dave Shackleford is the founder and principal consultant with Voodoo Security, as well as a SANS analyst, instructor, and course author and GIAC technical director. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. He is a VMware vExpert and has extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as CSO for Configuresoft, CTO for the Center for Internet Security, and as a security architect, analyst, and manager for several Fortune 500 companies. Dave is the co-author of Hands-On Information Security from Course Technology as well as the "Managing Incident Response" chapter in the Course Technology book Readings and Cases in the Management of Information Security. Recently, Dave co-authored the first published course on virtualization security for the SANS Institute. Dave currently serves on the board of directors at the Technology Association of Georgia's Information Security Society and the SANS Technology Institute.