Penetration testing, the practice of testing a computer system, network, or hosted application to discover vulnerabilities that may be exploited by hackers, is a necessary evil these days, when security breaches are making the national news and hacked companies, such as Home Depot, have to pay out big settlements.
The value of this type of testing is that it keeps the security team on its toes and allows it to understand issues as they arise. Compared with the cost of recent settlements, pen testing is cheap insurance that one's security is the best it can be and that any vulnerabilities will be identified and corrected ASAP.
The growth of cloud has led to some interesting angles on pen testing. Cloud-based applications need to be pen tested, as do their on-premises counterparts. However, pen testing applications that run in public clouds come with some complexities you must deal with, including legal and technical obstacles. To help address the challenges, here are five steps on how to approach cloud-based pen testing.
Step 1: Understand the policies of the cloud provider
Putting private clouds aside for now, public clouds have policies related to pen testing. In many cases, you must notify the provider that you’re carrying out a test, and it puts restrictions on what you can actually do during the pen-testing process. So, if you have an application that runs on a public cloud and would like to pen test it, you’ll need to do some research first regarding the process your cloud provider recommends. Not following that process could lead to trouble. For instance, your pen test will look a lot like a DDoS attack, and it may shut down your account.
All cloud providers proactively monitor their infrastructure for anomalies. In some cases, humans may give you a call to find out what’s up. In most cases, cloud service providers have automated procedures in place that shut down the system without warning when it perceives a DDoS attack. You could come into the office the next day and find that your cloud-delivered storage systems, databases, and applications are offline, and you’ll have some explaining to do to get them back up and running.
Another problem is that of being a noisy neighbor: Your pen test could take up so many resources that it affects the others on the cloud. Public clouds are multitenant and therefore must manage resources between tenants. If your pen test saturates the system, you may get an angry call from your cloud provider asking you to knock it off, or again, it could just shut down your account.
The long and short of this is that there are rules of the road when it comes to public clouds. You have to understand the legal requirements of the pen testing, as well as policies and procedures, or else you’ll quickly find yourself off the cloud system.
Step 2: Create a pen-testing plan
Those who plan to do a cloud application pen test first need to create a pen-testing plan. Items covered in the plan should include:
- Application(s): Identify and include user interfaces and APIs.
- Data access: Identify how the data will be pen tested through the application or directly to the database.
- Network access: Identify how well the network protects the application and data.
- Virtualization: Identify how well the virtual machines isolate your workload.
- Compliance: Identify the laws and regulations you need to comply with within the application or database.
- Automation: Identify the automated pen-testing tools (cloud-based or not) that will be employed for the pen test.
- Approach: Identify the application admins to include or exclude in the pen testing. If excluded, it could be more telling to see how they react, thinking that it’s a real attack. However, most application admins resent this approach.
The test plan should be agreed to by the pen-testing team, and each part of the plan should be followed. Any exceptions that occur are really part of the results, such as an application admin seeing the pen test occurring and killing access for the pen-testing team.
Step 3: Select your pen-testing tools
There are many pen-testing tools on the market. While pen testing cloud-based applications with on-premises tools is a popular approach, there are now cloud-based pen-testing tools that may be more cost-effective. Moreover, they don’t require huge hardware footprints. It’s a cloud pen testing a cloud.
What’s important about the tool is that it can simulate an actual attack. Many hackers use automated processes to find vulnerabilities, such as guessing passwords repeatedly or looking for APIs that provide access directly to the data, and you’re really trying to simulate those types of procedures.
It may be the case that your pen-testing tools can’t meet your requirements. If you run into this problem, you may want, as a last resort, to write your own system for pen testing. This is to be avoided if possible, though, because you’ll be in charge of maintaining that system, which will cost way more than if you leverage an existing tool.
Step 4: Observe the response
When executing the pen test(s), look for these things:
- Human response, or how the application admin team and application users respond to the pen test. If the test is not disclosed, the responses will be more telling. Many may react by just shutting the system down, while others may diagnose the issue first, before identifying and elevating the threat. This also includes the humans at your client provider; how they respond is just as important.
- Automated response, or how the security system itself can spot and respond to the pen tests. The response should be tiered, ranging from simply blocking an IP address that generates the pen test to shutting the application down entirely. In any event, security and application admins should be alerted as well, and descriptions should be sent about what corrective action was taken.
Both human and automated responses should be documented. This is where you’ll find any deficits in how the system and humans responded to the threat, and thus how well the system is secured.
Step 5: Find and eliminate vulnerabilities
While this is an obvious step, the outcome of this whole process is a list of vulnerabilities that are discovered by the pen testing. The list may run well past a hundred issues, or as few as two or three. If there are none, then your pen test may not be as effective as it should be, and you may want to re-evaluate and retest.
Vulnerabilities found while pen testing cloud-based applications typically look something like this:
- Access application data allowed using xxxxx API.
- API access granted after 10 attempts.
- VM not isolating the workload properly.
- Application password guessed using automated password generator.
- VPN allows outside access if DNS is disabled.
- Encryption not compliant with new regulations.
- Other problems.
Of course, the types of issues you’ll find will vary, depending upon the type of application and type of pen test you run.
Also, keep in mind that there are different layers. The application, network, database, storage system, etc., should be tested separately, and issues should be reported separately. The layers should also be tested together to see how they interoperate and if there are issues there as well. Report what occurred at each layer, holistically; it’s a best practice.
Make sure to work with your cloud provider regarding not only the legal and policy issues that are part of pen testing, but also how it recommends you perform pen testing on your applications in its cloud. Most will have a process to follow that will yield the best results from your efforts.
Final pen-testing suggestions
Another point to consider is who’s doing the pen testing. If it’s done in-house, then count on the fact that some issues will not be found. Internal testing teams, no matter how good, always seem to miss things. They are too close to the trees and too familiar with the application, which can cause complacency and lead to oversight. An alternative would be to hire white-hat hackers who can give your cloud-based applications a run for their money.
Research best practices that apply to your cloud provider, the types of applications you will test, and any compliance requirements you’ll have to meet. Using the approaches that others adopted is a good jumping-off point, but you need to understand that your pen-testing approaches and tooling may need to be customized for your specific requirements.
Pen testing is not an option these days. It’s the only way to prove that your cloud-based applications and data are secure enough to allow the maximum amount of user access with the minimum amount of risk.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
