A Statement of Work or “SOW” is a key document for your penetration testing project. If you are at the stage of executing an SOW, it should mean that you have completed your vetting process and will be locking in your penetration testing vendor. Today, we discuss some of the key elements that you should look for in a penetration testing SOW to ensure you, as the purchaser, are protected and know what you are getting.
Key Items to Look For in a Penetration Testing Statement of Work:
- Scope – Ensure that the scope of the proposed project has been captured accurately, including key information such as the number of IP addresses, testing restrictions (time windows), key delivery dates, any travel requirements, etc. All of these items will usually factor into the price so as the buyer, you want to be sure that the firm correctly scoped the project so that you’re not paying too much and they’re planning to assess your entire scope.
- Deliverables – At the end of the day, the key output of any penetration testing project are the final reports. Be sure that the SOW clearly articulates exactly what documents you will receive. At a minimum, this should generally include an executive summary and a technical findings report.
- Price – This goes without saying, but the SOW should have a fixed price for the requested assessment services most of the time. Be sure to cross reference the penetration testing proposal or quote to ensure that the price in the SOW is the price that you originally saw in the proposal. The SOW is a legal document and therefore will supersede any prior documentation.
- Completion Date – Odds are that you have a key date that you are tracking on for your penetration testing project to be completed. Even if there is no specific date, it is best practice to ensure that some end date is indicated to ensure that you can hold your penetration testing vendor accountable to complete the project on time.
- Location of Work – In the event that work will need to be at a specific location, be sure that it is explicitly called out within the Statement of Work. The last thing you want is to get half way through the penetration test and get into a disagreement on where you pentester should be, whether that be a specific onsite location or remote.
- Payment Schedule – The project payment schedule should not be overlooked. Every firm is different and we have seen 100% upfront, 50% upfront and 50% after project completion, 100% following project completion, and just about any other variation you can imagine. Make sure you’re aware of the required schedule and you’ve got business buy-in, as delays in payment could delay project execution or report delivery.
All companies are different and the Statement of Work may vary, however, in our experience, the aforementioned items should always be included. Penetration testing project documents can often times have legalese that may be confusing and may require review by a legal team to ensure you understand what you are executing. Have any questions on a penetration testing Statement of Work?
Penetration Testing Checklist
Here’s a checklist of what we might look for:
Logging and Monitoring
Does the application track users properly? Are systems actively checked?
Is there proper authentication? Do authorization controls apply to users’ actions?
Sensitive Data Exposure
Does the application disclose confidential information? Is the environment providing information that could aid an attacker?
Are user inputs validated and sanitized? Does the application behave independently of input?
Does the application enforce output Encoding? Is there consistent interpretation of the output?
Are there filtering mechanisms? Do they proactively defend against common web application attacks?
SSL Encryption Analysis
Does the web server support the security levels of the encryption ciphers? Are certificates supported on both the server-side and client-side?
Is parameter handling secure? Could the application mishandle authorization information? Could server-side information mistakenly be sent to the user?
Application Logic Flow
Does the application enforce logic flow? Could an attacker control the application flow at will?
Are there cross-site scripting vulnerabilities? Is there proper encoding of user-supplied input?
Does user input construct database queries? Can an attacker craft an input to control queries beyond the programmer’s intent?
Do user inputs construct file paths? Can an attacker craft an input to escape the directory structure of the application?
XML External Entities
Is it possible to inject XML tags or modify the XPath query?
Are the application’s certificates current, issued by a trusted authority, in the correct domain name, etc?
Are there instances that result in values above or below the allowable integer value?
Does the application perform proper bounds checking?
Known Vulnerable Components
Are server-side and client-side components current and secure?