Many companies are hesitant to move applications to the public cloud or use Software as a Service (SaaS) cloud applications, for fear of not being able to implement or test appropriately.
While much of that fear is based on the unknown, there are strategy changes companies should take to ensure their cloud application is properly security tested. In this expert response I will outline a few of those cloud security testing strategy changes.
Before you do anything, review the contract signed with your hosting company. Many hosting contracts require notification prior to security testing. Be clear with your company and your hosting company prior to performing any testing – outline the scope, tools involved, anticipated network load (if any), types of attacks you expect to perform, etc. If your company, or the hosting provider, has IDS or IPS technologies in place, you will need to agree on a window during which those tools will need different monitoring thresholds. Err on the side of over-communicating to avoid the element of surprise.
Remember: you don’t own the infrastructure. Your cloud solution, whether hosted at your company or at a cloud provider, will be hosted in an environment you may not be familiar with. As such, keep in mind that your testing coverage will change. Whereas internal application security testing often stopped at the application boundaries, your cloud application testing will need to probe around the edges of those boundaries. Testing for network, logical and even architectural security risks will be a very important strategy. In a way, it is a benefit to you that you can’t depend on the same networking infrastructure as your intranet. This forces you to think outside the box and test more thoroughly.
Another consideration is the need to decide between whitebox or blackbox testing. In blackbox testing, the penetration tester knows as little about the system as a real-world hacker would know. This is advantageous because, as you discover and exploit vulnerabilities, no one can challenge your report by claiming “an attacker wouldn’t know to do that.” On the other hand, whitebox testing is advantageous in that it is much faster. Not only is reconnaissance and server discovery accelerated, it’s easier to prioritize test efforts.
A big challenge to cloud security testing can be the lack of application logging to aid in focusing and enhancing your test efforts. Performing security testing in an isolated development environment means you will be able to tail logs and see evidence of your attacks’ outcomes. In a cloud environment, you will rarely be grated this level of access. Therefore, you will only be able to gauge attack success by the application’s behavior. Some tests are such that providing input into control A on screen Z will result in invalid data on page P. Be familiar with the data flow within your app and expect to have to poke all around the app to complete your testing.
In conclusion, security testing in the cloud does change things, but it’s not impossible. It’s important to plan ahead, to communicate the changes in your test strategy, and to set appropriate expectations with your management. Above all, it is critical to communicate before and during your testing—primarily with your cloud provider, but also with your IT and security organizations.