In last week’s post, we gave a high level overview of vulnerability assessments. This type of assessment results in a prioritized list of vulnerabilities in your deployment. It’s an excellent first step in knowing the state of your deployment.
The next step you should take is to conduct a penetration test.
A penetration test (or simply, pentest) is an active test of your defenses. You’re hiring a trusted 3rd party to attack your deployment in order to find exploitable vulnerabilities. The theory is that it’s better to have someone working with you do this before a malicious attacker can.
The test report is going to provide detailed information on how the attacks were conducted, what was successful, how defenses could be improved, etc.
Pentests can vary greatly depending on their goals, your deployment, timelines, etc. A few key tips for organizing a pentest on AWS include:
While you might have the skill set on your security team, it’s usually best to have a trusted 3rd party conduct the penetration test. Penetration testing is as much an art as a science. A good penetration tester is going to be able to ferret out issues with your deployment that you never saw coming.
If you use an internal resource, they will approach the test with a biased mindset. The most typical issue that surfaces is that an internal resource will either attack the most common–and well known–weak spot or avoid that option entirely. Either way, that type of test is not a close enough simulation of a real attack.
A trusted 3rd party will approach the test methodically. Working through your exposed attack surface gradually finding issues with your deployment and mapping your exploitable vulnerabilities.
AWS requests that your provide them with notification before any vulnerability scanning or penetration testing is done. They provide a convenient form to help make that process as easy as possible.
As part of the form, AWS requires:
Completing the form only takes a few minutes and will save a lot of headaches. Be sure to take the time to fill it in with the details of your test.
The first time you have a pentest done, it’s extremely tempting to provide a specific time at which the test will be conducted. In fact, that’s one the pieces of information that AWS requests up front.
Within reason, keep this information compartmentalized. Don’t tell your security team, your ops teams, or support.
Why not? Because if any of the teams normally involved in incident response knows about the test ahead of time you won’t be testing the right things.
The ideas behind the pentest is to measure you current security posture at any given time. If everyone knows ahead of time that they’re going to be tested, they are going to prepare ahead of time. While you may look better on the test report, you’re doing yourself a disservice.
When a real attack happens, no one calls ahead.
So your “attacker” has tested your defenses and found a few holes. Maybe they’ve even been able to breach all of your defenses and gain access to key customer data. Don’t panic. That’s OK. This is the whole reason you run a pentest. It’s much better to have your known testing attacker reach your customer data than an unplanned attacker with actual malicious intent.
At the end of the test, you should receive a comprehensive report detailing the results. This should include:
Even though it may be hard to read the results, take them to heart. Work through each of the issues raised in turn and fix the problem. This is the crucial step. You have to take action on the results.
After you’ve worked through the issues raised in the report, your defenses should be stronger than ever. Better yet, you know your defenses work. They’ve been actively tested.
While no security is perfect, by following the tips in this series you can be confident that you’ve taken reasonable steps to ensure that only the most determined attackers are going to have a chance at breaching your defenses.
How do you handle penetration testing in the cloud? Please share your tips in the comments! And if you’re interested in securing your EC2 or VPC instances, check out our new Deep Security as a Service for cloud servers, currently in free Beta.