Have a Question About the BreachLock Cloud Platform? Enter it below.
21 April, 2022
Web Application Penetration Testing Checklist
There’s an old saying that holds value in this scenario regarding Web Application Penetration Testing – “Begin with the End in Mind.” One of the biggest components of ensuring that your organization gets the most value out of a Web Application Penetration Test is proper planning, which cannot be overlooked. Once you can articulate what exactly it is that you are looking to gain from a Web Application Penetration Test, it is easier to develop an action plan that caters to your organization’s objectives. Businesses often call this approach an ‘Outcome-Based Approach.’
Whatever your organization’s reason is for planning a Web Application Penetration Test, following this checklist of questions that need to be answered before you start can help relieve some of the intricacies involved in the process.
What is your organization’s objective of getting a PenTest done?
a. Gain customer’s trust by demonstrating proactiveness in security measures with an assessment of the current security posture
b. Regulatory or industry-level compliance/standards
c. Security Posture Assessment/Management
d. Attack Surface Management
What Is the Scope?
a. What environment should you be conducting the PenTest in, staging or production?
b. Do you need BlackBox or GreyBox or Whitebox testing?
What is the best tool or vendor for the job?
a. Traditional consultant-based approach
b. Automated Testing approach
c. Modern Penetration Testing approach that uses A.I. and Human PenTesters both
What is the best time to schedule your Penetration Test?
a. How often should I be conducting Penetration Testing?
b. What are the triggers for a PenTesting activity?
What is your plan for remediation?
What is your organization’s reason for getting a Web Application PenTest?
There are cases in which businesses are simply considering Web Application Penetration Testing as a proactive security posture procedure and there are cases when it’s required for compliances, vendor assessments, and client requests. Some of these compliances include:
- PCI DSS
- NYDFS 500
- ISO 27001
Having an in-depth understanding of what is required by a vendor or client out of a PenTest will set you on the right path to move deeper into the planning phase.
What is the scope of the Web Application PenTest?
When planning to begin a PenTest on your organization’s Web Application, providing your selected vendor with the scope of what needs to be tested is especially important. The Rules of Engagement should also be agreed upon at the beginning. Businesses often struggle with identifying the scope of PenTests, as there are multiple variables involved. However, the scope of the engagement should be derived from the objective of the PenTest, reaffirming the idea of the ‘Outcome-Based Approach.’ For example, for PCI DSS compliance testing, all the applications and systems coming in the Card DataHolder Environment (CDE) should be included and it should also include a plan to test the isolation of CDE to non-CDE environment.
Another example: if you have made significant changes to an application, it’s best that the organization test the recent changes/additions to see if the changes made caused any vulnerabilities to arise.
There is also the decision between a White Box, Grey Box, or Black Box Penetration Test to consider. It is extremely important that your vendor has the correct information to ensure that the results of the PenTest live up to its requirements and objective. For example, if an organization requesting a blackbox test for a web application that only has a Form-Login page, and the entire application and interfaces are behind the login, the BlackBox PenTest results will not be helpful.
It is equally important to understand the environment in which you want the Web Application to be tested. Most organizations, due to fear of a disruption in business, get the staging environment of the application PenTested
What is the best tool or vendor for the job?
The key to finding the right tool or vendor should also stem from the objective of testing. Organizations often use a traditional Penetration Testing approach for compliance-based testing and rely on consultant-based model entirely. The traditional model has proven to be effective in the past, but it is not scalable in the current digital era.
Similarly, organizations looking at assessing the current security posture take a tool-based approach which gives them scalability and comprehensiveness, but it often misses the business context and testing of business controls.
Additionally, credibility of the vendor is an especially important factor that determines the admissibility of the reports by auditors.
For example, organizations in Financial Services and Healthcare Technology require their PenTesting vendors to be ISO 27001 certified due to the rigorous nature of the certification process.
ISO 27001 requires vendors to go through a meticulous 6–12-month process to earn their certifications. An ISO 27001 Global Report done by IT Governance found from a survey of vendors in over 53 countries that 71% of them reported receiving requests from clients for proof of ISO 27001 certification, proving that ISO 27001 is a widely recognized industry standard across the globe. Additionally, industry recognitions, certifications, and compliances such as CREST and SOC II are equally important.
Some other considerations to make when choosing the right Penetration Testing vendor are whether or not they employ in-house or outsource/crowdsource their Penetration Testers, what kind of tools they use internally, and whether or not they use third-party services to share details about PenTest results. Having a third party in the mix for reporting purposes can pose an entirely new set of privacy risks, especially before remediation efforts have been completed. Any of these concerns can easily be put to rest by doing your due diligence to source the best partner for the job.
When is the best time to schedule a PenTest for your Web Application?
In any organization, there are always going to be peak business hours that drive traffic on its Web Application. It goes without saying that those peak business hours are not an ideal time of the day to plan a PenTest. The best way to work around this is to monitor trends in traffic over time to ensure that you can work with your Penetration Testing vendor to schedule the PenTest at the least disruptive time in case its activities had any temporary adverse effects on the performance of the application. When working with a skilled Penetration Tester, it’s unlikely that any issues would arise, but it is best to er on the side of caution.
Another thing to keep in mind when planning to schedule your PenTest is any major updates to your WebApp or any industry-wide announcements of a new vulnerability. Any changes to the code or structure of a Web Application could be a place for a new vulnerability to make way.
In order to receive the maximum value out of PenTest engagement and investment, organizations should take a periodic assessment approach with on-demand testing on an ad hoc basis. For example, the compliance may suggest getting a PenTest every quarter, but the organization should be cognizant of requesting an ad hoc PenTest if there are significant changes made to the system/application or if the threat landscape has changed significantly.
What is your plan for remediation?
Directly after receiving Web Application Penetration Test results, you’re going to want to get right to work with understanding the vulnerabilities detected, especially any critical, high, and medium ones. More often than not, vendors don’t offer a channel to speak with the PenTesters to get context and clarity on reported findings. However, it is a crucial step towards an effective remediation via prioritization.
It’d serve your organization well to have a solid plan for remediation efforts as far as delegating remediation efforts to your developer team and having a timeline goes to prepare for a retest. Traditional models also don’t offer workflow integration to assign the findings to the concerned team and because of manual management of spreadsheets and word documents, quite a lot of valuable information falls between the cracks. Rest assured – there are vendors out there who are receptive to this pain-point in the Penetration Testing process and have implemented innovative ways around it.
Depending on the goal of the PenTest, it may be best to focus on specific types of vulnerabilities that are most closely related to specific functions or bits of information stored in the Web Application. Having the appropriate business context before remediation efforts begin can make a positive difference in your team’s ability to prioritize remediation efforts on exploitable vulnerabilities that have the greatest effect on your business.Back To Other Posts