Open Mobile Menu


How to Get the Most Out of Your Penetration Test

Views: 2423

Written By: Scott Simmons September 14, 2016

Whether it's to comply with a security standard or simply because you recognize the need to defend your organization from online attacks, having a security specialist examine your application or network will give you a clear picture of your security posture. But what should you know to ensure that you are getting the most out of your penetration test?

The Adversarial Approach

It might be good to start by addressing a common information security myth. You may have heard of the "Blue Team vs Red Team" paradigm; defenders are Blue, attackers are Red, and they are always locked in conflict, one doing whatever they can to make life difficult for the other! This oversimplification of these roles can be very misleading. Of course, it is useful for some organizations to perform a type of penetration test in which a security consulting firm assumes the role of a sophisticated threat, attacking the target by any means possible - team members of the target organization may not even be alerted that a test is being performed.

However, often it is most useful to take a different and more collaborative “Purple Team” approach. The more your development/project team can work with your security consultant, the more thorough the security assessment can be. The specialist examining the security of your system has one ultimate goal: to identify every possible opportunity to improve security and to provide actionable guidance on how to do so. It is often best to think of a security specialist as any other kind of subject matter expert, someone with a specific set of skills and experience who is likely less familiar with your organization and systems than you are. Working to improve understanding goes both ways; your technical team can learn high-level concepts and even specific techniques from your security consultant. For example, it isn’t possible to defend against an attack like Cross-Site Request Forgery (CSRF) without understanding the mechanics of how an attacker might attempt it. Even the best and most experienced web architects learn about CSRF and other types of attacks during a penetration test. So the more open the communication channel between you and your security consultant is, the better your security will ultimately become.

Communication is Critical

Make sure that you know how to contact the security specialists and the management staff who will be performing the test. Make sure that anyone within your organization who may be affected by testing also has that information. Network systems and web applications can be very complex and it is not always obvious where security testing may lead and who it may involve. Ensuring that your security specialist can be heard by the correct stakeholder within your organization for the systems being tested can be the crucial link leading to identifying a critical flaw. For example, say a transaction within your web application unexpectedly consumes another internal API. Being able to determine the behavior of that API may allow the tester to determine whether or not an injection flaw is actually present within the system.

Environment and Scope

Before testing can begin, the target environment must be chosen and prepared. Sometimes it works best to test the production system directly; sometimes it makes more sense to test in a QA or some other pre-production environment. There are several things to consider when choosing the environment for your penetration test.

  • Defining Scope – This can be one of the most important parts of preparing for your penetration test. Be sure to have a clear understanding of what specifically you want tested during your security assessment, and what you want left out. A scope that is too broad can lead to testing content which is irrelevant to the business interest and to wasted effort if some components have been recently tested and have not been altered. A scope which is too narrow can lead to missing important flaws that may damage the security of your organization. For example, if your web application is protected by a Web Application Firewall (WAF) you should decide whether you are interested in the security of the whole system including the WAF or if it would be more useful to look at the application by itself to see what an attacker might do in the event that the WAF is defeated. When deciding on the scope for your penetration test, always keep in mind that real-world attackers will not be bound by these constraints. An actual adversary will have as much time as they wish to devote to an attack, so be sure to allow the right amount of time for a thorough test given the scope of the test.
  • Simulating Production - If testing in production is not the right choice for your penetration test, put in the effort to make the test environment resemble production as closely as possible. After all, it is the production environment that will actually need to withstand real world attackers. If an element of the production system is not available in the test environment, a critical flaw in that part of the system may be missed during the penetration test. Making the test environment resemble production as much as possible includes things like populating databases with dummy data and implementing TLS. The more the test environment resembles the production environment, the more useful the results of your test will be. Because web application testing can sometimes adversely affect the functionality and content of the site, it is often best to perform that type of penetration test in some safe simulated environment and not in production.
  • IDS/WAF Whitelisting - Defending against Denial of Service attacks can often mean monitoring and automatically reacting to high-volume traffic and this can be an excellent control to have in place in the production environment. This task can be handled by a Web Application Firewall (WAF) or some other kind of Intrusion Detection System (IDS). However, your security specialist may have just a week or two to perform testing and (unfortunately) real-world attackers are not bound by such constraints. Whitelisting your security tester’s IP or taking other steps to ensure that the test environment allows for a large amount of traffic from the security specialist can allow them to use every available tool at their disposal and can result in a much more thorough assessment.
  • Permissions – Always make sure that you have the proper permissions for the penetration test before it begins. If your web application is hosted by a third party, be sure to notify them that you are inviting a security professional to perform an assessment. Many providers, such as Amazon AWS, have authorization forms which must be submitted before this type of activity is allowed. Even if the target of your penetration test is completely internal to your organization, be sure to notify anyone who may be affected by the test.
  • Functionality - Make sure that the test environment works the way that the production environment does. If your test web application doesn't have a feature that is present in production, a flaw in that feature may go untested and put your system at risk. For example, it is common for web applications to send emails as a part of a Forgot Password workflow. So it is critical to ensure that the tested application is configured to send email, so that any flaws in that system will be identified and remediated.
  • We'll Do It Live - Sometimes testing in production is the right way to go. There is no worry about creating a simulation of the real thing when you're just testing the real thing. This kind of penetration test can be the right choice when creating a test environment would be just too difficult or when the production system is too complex to meaningfully copy. Often it makes the most sense to perform broad network penetration tests in the production environment, because it is too difficult to create a meaningful replica of the target. When this is the case, communication is even more important than usual; be sure to set aside time before testing begins to figure out what considerations need to be made so that no negative side-effects occur during the assessment.

Providing Access

Be sure to provide everything your tester will need before the penetration test is scheduled to begin. For example, it is recommended to provide at least two sets of credentials for each type of user role. This may sound a little strange at first; however as a part of testing the authentication mechanisms will be assessed, and in certain circumstances the expected secure behavior is for the system to lock a user’s account. When this occurs, it is much better to have a second set of credentials ready to go so that testing may continue and there is no testing delay while the first credentials are unlocked. Also, and more importantly, multiple test users will allow for the detection of several types of Privilege Escalation vulnerabilities.

The information required for the penetration test will be clearly defined before the start time of the assessment, but keep in mind that the security team may not know your systems as well as you do. Maybe your web application features a bulk upload function that requires a unique file format? Perhaps a system on your network which you would like to be tested requires a different set of credentials? Your security tester will certainly reach out to you when they cannot reach every part of the in-scope system, but anticipating the need for that information can help make a penetration test go smoothly.

Be Available

The final thing to know about how to get the most out of your penetration test is to simply be available during the assessment time window. Networks and web apps are complex things and there is no way to know ahead of time what challenges may arise during the penetration test. Open communication before, during, and after your assessment is the key to getting the most out of your penetration test.

Are you making the most of your penetration tests? Learn more about how we can help make the most out of your penetration tests. Contact AppSec Consulting today.

Scott Simmons

Scott Simmons is a Security Consultant at AppSec Consulting who specializes in the area of application security. He has extensive expertise in application penetration testing, including the use of manual techniques and automated tools to perform detailed assessments of a wide variety of applications, including web applications, web services, and mobile applications. He also has led numerous projects that involve training customers and team members on how to master application security testing tools and techniques. Scott provides targeted, practical advice to customers on how best to mitigate security vulnerabilities and keep their sensitive information well-protected.

Scott earned his undergraduate degree from the University of California at Berkeley and holds a certificate in Software Development from the Community College of Allegheny County. Before working in security, he developed fault-tolerant software for an international transportation infrastructure company. He has conducted web security training classes for multinational clients in the San Francisco Bay Area, in India, and in China.

read more articles by Scott Simmons