Pentesting_preparation_checklist.md

Penetration testing preparation checklist 1.1

About

This document outlines the preparation, activities, and considerations required to establish a minimal external penetration testing program.

Penetration testing preparation checklist

• Understand why you want a pentest: First and foremost, why are you looking to perform a pentest? Is this for a compliance checkbox, to enhance the security of your product/environment proactively or reactively, based on a customer request, or for some other reason? This can help set the direction, urgency, and path forward for executing a pentest.

• Establish initial scope and capture it in a scoping document: The pentest project manager will need to determine an initial scope and to capture it in a scoping document. This should be shared with engineering, product, compliance, and other applicable stakeholders to ensure the scope is correct and comprehensive.

• Identify budget: For external penetration tests you will need to find a budget to pay for the engagement. For internal pentesting, you will need to ensure the pentesting team has prioritized your engagement over another and can support your timelines.

• Identify external pentester: If you lack an internal person who is qualified and available to perform the pentest, you will need to identify an external vendor.  There are hundreds of vendors offering this service, and using LinkedIn or word of mouth to find a good vendor is advisable whenever possible. It's important to create a shortlist of 2-3 vendors and determine which has the right skills, cost range, and timing for your engagement.

• Onboard external pentester: When using an external company, it can take several weeks or months to onboard the new vendor if it's the first time you're using them. This is because each company's vendor security/onboarding processes varies, signatures from multiple stakeholders or 'stamps' may be required, and response times can also be slow depending on workload volume. It's critical to start this process early to avoid delays. Once you have decided the test needs to occur, begin this process even before locking in all details of the engagement.

• Stakeholder identification: It's critical to determine which stakeholders need to be involved in all aspects of the pentest process. Typically, this will involve looping in:
  

  • The engineering manager owning the products, features, or systems in scope for the engagement.
  • A software engineer responsible for, or very familiar with the codebase.
    
  • An operations point of contact, possibly from site reliability engineering (SRE) when one or more systems are involved.
    
  • The product manager when a product or feature is involved.
    
  • A pentest project manager, an individual coordinating the engagement.
    
  • A representative from the compliance team, when there is a compliance tie-in.

• Confirm scope with stakeholders: The scope should be captured in a planning document that will ultimately be included in a statement of work (SOW) with the external company.

• Confirm timing of product release: If you're testing a new feature that isn't live, you will need to know the go-live date. It's recommended the testing wrap up 2-3 weeks before go live to give engineering the 2-3 weeks to fix any vulnerabilities prior to release. The exact details on must fix items should be outlined in a vulnerability management process.

• Establish SOW with vendor: After identifying a vendor, work with them to establish a statement of work. The statement of work should specify the scope, price, days/weeks the engagement lasts, travel costs, reporting requirements, and retesting details. If you omit any of these, you may be charged a higher fee later to include them.

• Budget approval: Once costs are known, work with the budget approver to adjust scope as needed, or to approve.

• Finalize SOW: Now that budget is approved, timing is established with eng and outlined in the SOW, and you have double checked the scope, sign the SOW and lock it in with the vendor. This may require signatures from leadership, and/or legal, so anticipate this extra step timing wise.

• Get access to materials: The pentesters will need access to the following materials depending on the scope of the engagement
  

  • One or more systems for performing the testing
    
  • Obtaining the necessary source code and configuration files (excluding production secrets). Transmitting the source code should only be performed via secure channels, or by placing the code on a company owned asset that remains in the office during testing.
    
  • Two accounts for each 'role' involved in the product or system (e.g. User, Manager, Administrator)
    

• Slack/Instant Messaging/IRC channels: During the engagement the testers will have questions, have difficulties logging in, or may cause the testing environment to go offline. It's critical they have a venue, such as a slack channel with all key stakeholders to raise issues as they come up. This saves valuable time when things go wrong or there are questions. This is also a good venue for the testers to share findings with the right stakeholders, as they are discovered. The pentest project manager should monitor this channel actively to support the engagement.

• Plan engagement meetings:
  

  • Scheduling the kickoff meeting with key stakeholders and the external testing company is essential. During this meeting eng/product should provide an overview of the products/systems utilized and answer questions the testers may have.
    
  • Schedule one or more check-in meetings to ensure the testing is going as planned. This will enable course correction or additional support early which increases the chance of a successful engagement.
    
  • Schedule a final readout with key stakeholders from security, compliance (when applicable), engineering, and product. Invite other people involved in the process as optional but ensure key owners of the risks identified during the pentest are present in the final readout.
    

• Communicating issues to risk owners: Before the pentest concludes issues will be uncovered by the testers. It's important to immediately notify impacted engineering teams, this will enable them to verify if the issue is real and if so to remediate it quickly. If the issue isn't real it can then be excluded from the report or downgraded in priority if determined not to be as important as initially thought. Once a list of verified issues exist, create a parent jira ticket for the pentest engagement and link each issue as a child ticket and assign them to the correct engineering/operations owners. Ensure you speak with them about these issues prior to filing them to ensure you aren't slamming an unaware team with substantial work.

• Analyzing risks for bigger learnings: Each identified risk should be analyzed to determine what actions may be possible to prevent its recurrence or introduction moving forward. Specifically you should ask:

  • Is this something our automation can easily detect? If so, determine a path forward to automate detection moving forward.
  • Is this something that keeps reoccuring? If so, there may be a security control that could be created to solve the issue proactively, for example a security framework (e.g. anti CSRF, improved auth framework, output filtering, etc...).

• Scheduling a retest: After the pentesting engagement ends, engineering/operations will implement security fixes for identified findings. It's important to schedule a retest to verify the fixes have been implemented correctly.

• Retest report updates: In addition to performing the retesting, it's a good idea to also have the tester update the pentest report to indicate if issues were fixed, or mitigated in such a way that could downgrade priority. When customers, auditors, or regulators ask for a copy of the report it will capture if identified issues are remediated or not.

Checklist version 1.1 copied from Sectemplates.com