Security testing techniques for cloud applications are, in general, similar to testing Web applications. Like Web application security, organizations must ensure that confidential or private data remains secure, both in the cloud system and in the application and any connecting systems. Cloud application security testing is rather new and complex because the number of intersections and transfer points that need securing increase. There also are a few significant differences to be added to the testing regimen to ensure security in a cloud infrastructure system. First, keep in mind the structure of the organization's cloud system. Testing must be done within the internal cloud, as well as to any connection points to other clouds, internal and external. And testing must occur across clouds to ensure data security and integrity, and include testing security within the application.
Before starting a cloud testing effort, remember that the infrastructure is owned and managed by another organization and testers won't have the same access as they would in an internally managed system. Security testing involves tests that attack tools, networks, configuration settings and other data that will cause adverse system responses. The hosting cloud vendor must be aware of the testing in order to be prepared to support it and maintain any contractual obligations.
For effective cloud application security testing, create security-related tests that test within, without and across the cloud infrastructure system and the cloud application itself in order to ensure that business data and the cloud system used by the application is secure.
Testing within and without
Testing within and without means testing the full cloud infrastructure as a system. The scope depends on the setup for the organization and application. Cloud systems can be single and internal, or they can be multiple systems that are both internal and external. An important testing consideration is identifying the structure of the cloud system and the way the application being tested functions within the system. A tester needs to know all the connection points, including data connections and details on the transfer or data messaging services used to pass information to and from the application.
Start by testing the internal features of each cloud, and then create tests for all the connecting points or additional clouds. Note that it's important to know the nature of the cloud and if it's internal, external or hybrid. Tests need to be altered to fully test the security of data within an internal cloud and whether that data is accessible externally or via messaging systems.
Testing applications in the cloud includes penetration and data testing techniques that are similar to those used with Web applications. The difference is in the system structure and the amount of access a tester can get when the infrastructure is managed by a cloud vendor rather than an internal organization. The main goal is to verify that both data and applications are secured internally and to test all connection points because each connection is potentially a source of unauthorized entry or access.
Testing across systems
Testing across cloud systems is similar to, but different from testing from "without." Testing across clouds means testing public, private or hybrid cloud applications. Most cloud applications are designed to share data between applications, and thus between cloud systems. Again, testing is most effective when it's known what the overall structure of the cloud system is, and the ways the cloud application interacts with that system and shares information or data.
When security testing across clouds and applications, the main focus is determining if data can be improperly accessed or shared. As a tester, I want to see if I can get unauthorized access to data by manipulating the cloud system configuration and access or role security, or by intercepting messages or message queues. Focus on discovering and testing any integration or connection point that can be manipulated to allow access into the cloud system. Attempt to access message queues or insert code to transfer data to an authorized application or cloud system. It's critical to test what may seem to be simple or obvious, as well as complex pathways to verify hackers cannot gain access to confidential data.
Another significant difference to keep in mind between testing Web application security and cloud application security is that a Web application has boundaries and a cloud application does not. Because of the potential to be boundless, testers need to probe in depth around any connection points or secured boundaries. Include tests for network access, logic errors and architectural security issues. Security testing cloud applications forces testers to test outside the box because the cloud infrastructure is open by design.
Unless the organization's testing team is granted access, one major challenge of cloud application security testing is the lack of access to logs. Remember, the organization does not own the system, so access to server logs and other types of files is not available in a cloud environment. Testers must be able to determine if an issue exists by watching the application response, the data itself, and performance or timing issues visible in the application. For example, within the application, focus on validating input on one window and verifying the resulting data on any additional application windows. It's imperative to be familiar with the application data flow, valid data definitions and the workflow between applications in specific clouds -- in other words, which data can be accessed and the rules for valid and invalid data display.
Based on the nature of cloud application infrastructure, thorough testing is essential, and most of the testing should be based on application behavior or response. Plan time to test thoroughly. It's essential to an organization's business success that no unauthorized access to data is gained via an application or a cloud connection point.
Remember to plan ahead and contact the cloud vendor, both to arrange the time for testing and to notify the vendor about the types of security tests planned. Due to testing authentication, it's essential the system not be locked down, for example. Testing on a system that isn't owned or managed internally must be communicated and planned in advance.