The Intricacies in Penetration Test Timing
During a penetration test, the Schellman team often works with development teams, administrators, risk and compliance professionals and information security personnel; however, the initial point of contact for a penetration test may be an individual that isn’t any of those. More and more, someone from the product or procurement team may have the responsibility—or shared responsibility—of having a penetration test performed. While these individuals may understand a timeline for a specific task, they likely do not have full visibility into the entire project. Such circumstances, among others, can trigger one of the biggest challenges frequently seen in planning pen tests—timing.
To alleviate these timing issues, the best approach is to work backwards from the final task required. If everyone knows the business need is to have a penetration test report without any open findings by the end of the quarter, when does planning need to start? Where should it start?
Identifying Timing Requirements
The first step in planning ideal timing of a penetration test begins with understanding all the relevant dates. Cloud providers working with FedRAMP are granted an Authorization to Operate (ATO) as of a specific date, PCI merchants and service providers have a date on their Report on Compliance (ROC), and service providers have reporting dates or review periods in their SOC reports.
Though those compliance dates are fixed and there isn’t much flexibility in moving them, they may not be the only critical date to the project. Other things to consider and plan for could involve external influences such as a large client expecting a pen test report before a contract is signed, or a forthcoming change to the compliance requirement. Other internal factors may include the development release schedule or black-out periods when testing is not allowed (i.e., testing may not be permitted during times of high-demand). Being able to plan a penetration test with all the relevant dates in mind can help maintain efficient timing throughout the process.
Understanding the Non-Technical Aspects of the Engagement
Another way to avoid issues with timing is to consider all the elements of a given project. Though the actual penetration testing of the application, environment or in-scope system is the most consequential factor related to timing, it is only one component. Consideration must also be given to the non-technical portions of the project, including, but not limited to the following:
|
|
Working Backward from the Deliverable Date
Once all the dates are known and all the various stages are understood, the process of working backwards can commence so that clarity on when to begin a project can be identified. Let’s consider a scenario where the requirement is to have a pen test report without any open findings by September 30th. When working backwards from that date, planning likely needs to start four to five months prior. A full sample schedule of events that considers all the relevant factors can be found in the table below, beginning with the set end date:
Approximate Timing / Date |
Stage |
Details |
September 30 |
Final Day |
Clean Report Required |
September 24 |
Retest (One Week Prior to Finish) |
Retest performed and final report received from pen tester. |
August 21 to September 23 |
Remediation (One Month) |
~30 Days allocated to have development and IT teams remediate findings. |
August 16 to August 20 |
Reporting / Project Clean Up (One Week) |
Pen tester delivers report and cleans up environment. |
August 1 to August 15 |
Pen Test Execution (Two Weeks) |
Delivery of the technical assessment of environment. |
July 22 |
Environment Preparation |
If any testing is being done in a non-production environment, all preparation should be complete. |
July 15 |
Rules of Engagment / Authorization Letter |
Two weeks prior to starting the penetration test, the scope should be documented and formally understood. |
July 7 |
Kickoff / Planning Meeting |
Three weeks prior, a kickoff meeting is needed to get all necessary parties involved and to have an environment and/or application walkthrough or demonstration. |
June 30 |
Contract Execution |
Contractual paperwork, including purchase orders and other approvals need to be complete. |
June 15 |
Vendor Selection |
Third-party pen tester is chosen. |
June 1 to June 14 |
Identify Sourcing Options (Two Weeks) |
Potential options to deliver the penetration test are found. |
May 15 |
Determine Scope / |
Business driver and/or compliance requirement is identified. |
Staying Aware of Other Considerations
Of course, the above schedule makes some assumptions, such as the size of the penetration test and the amount time needed for remediation. It also skips over considerations such as holidays, time off, or any limitations with the testing environment that would require addressing before testing can proceed. Additionally, though this scenario had the technical testing running for two weeks, larger tests will run longer and some organizations may require sixty (60) or ninety (90) days to implement remediations. Moreover, for reports with a December 31st completion requirement, end-of-year holidays and time off may need to be included as well. Finally, the pen test provider may be busier at certain times of the year and may require more than the six weeks shown to properly schedule the right personnel for the task at hand. All these possible components must be incorporated into the planning stages as they apply to each unique test scenario.
All in all, leaving out consideration of any combination of these factors can often lead to timing issues throughout the penetration test process. To ensure the most efficient examination possible, it’s important to understand all the pertinent dates and factors beyond just the testing window, so that everyone involved in the test can play their part as seamlessly as possible.
About MATT WILGUS
Matt Wilgus is a Principal at Schellman, where he heads the delivery of Schellman’s penetration testing services related to FedRAMP and PCI assessments, as well as other regulatory and compliance programs. Matt has over 20 years’ experience in information security, with a focus on identifying, exploiting and remediating vulnerabilities. In addition, he has vast experience enhancing client security programs while effectively meeting compliance requirements. Matt has a strong background in network and application penetration testing, although over the past 10 years most of his focus has been on the application side, with extensive experience testing some of the most well-known IaaS, PaaS and SaaS providers.