What To Look For In A Penetration Testing Statement Of Work?

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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:

N

Logging and Monitoring Does the application track users properly? Are systems actively checked?

N

Broken Authentication Is there proper authentication? Do authorization controls apply to users’ actions?

N

Sensitive Data Exposure Does the application disclose confidential information? Is the environment providing information that could aid an attacker?

N

Input Validation Are user inputs validated and sanitized? Does the application behave independently of input?

N

Output Encoding Does the application enforce output Encoding? Is there consistent interpretation of the output?

N

Filtering Layers Are there filtering mechanisms? Do they proactively defend against common web application attacks?

N

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?

N

Parameter Passing Is parameter handling secure? Could the application mishandle authorization information? Could server-side information mistakenly be sent to the user?

N

Application Logic Flow Does the application enforce logic flow? Could an attacker control the application flow at will?

N

Cross-Site Scripting Are there cross-site scripting vulnerabilities? Is there proper encoding of user-supplied input?

N

Injections Does user input construct database queries? Can an attacker craft an input to control queries beyond the programmer’s intent?

N

Path Traversals Do user inputs construct file paths? Can an attacker craft an input to escape the directory structure of the application?

N

XML External Entities Is it possible to inject XML tags or modify the XPath query?

N

Certificate Testing Are the application’s certificates current, issued by a trusted authority, in the correct domain name, etc?

N

Integer Underflow/Overflow Are there instances that result in values above or below the allowable integer value?

N

Buffer Overflow Does the application perform proper bounds checking?

N

Known Vulnerable Components Are server-side and client-side components current and secure?