top of page

HOW TO WRITE A PENETRATION TESTING RFP


typing on a computer screen

  1. Do you use an RFP when sourcing a Penetration Test?

  2. Have you scoped a penetration test and not received what you thought you were asking for?

  3. Have you completed your penetration test but still feel vulnerable?


This is for you…


Emagined Security knows your frustration with penetration testing RFP’s. We actually respond to many many RFP’s and we feel your pain. This guide is designed to help you write the best RFP possible.


What Is A Penetration Testing RFP?

A penetration testing RFP is a penetration testing request for proposal. It can also be called a request for quotes, or RFQ. Your organization will want to use an RFP or RFQ to engage with a security company before deciding to have them perform penetration testing work. This will allow you to get the right service provider and ensure all of your needs are met for your penetration test.

cartoon image from an overhead perspective of a man on a laptop

Our Use Case


A few months ago, Emagined Security responded to (but did not win) a penetration test RFP. The customer ended up awarding the test to the lowest Respondent ($10,000 – at least 50% lower than any other Respondent) as their procurement process required them to buy from the “lowest bidder.”


The result was a mess.


The RFP requested a penetration test for an Oracle PeopleSoft environment. The following is an abridged redacted version of the request:


“CUSTOMER has upgraded our Oracle PeopleSoft environment and made significant infrastructure changes to the external facing components. This penetration test is to re-validate that these changes have not resulted in the introduction of vulnerabilities to the system."


"The selected consultant will conduct external and internal penetration tests against CUSTOMER’s Oracle PeopleSoft systems. The contracted tasks will mainly involve web-application penetration-testing with well-defined scoping rules.”


There were many other statements that the customer placed into the RFP that they thought would ensure they get what they need but something still went wrong:


“The consultant shall conduct vulnerability and penetration tests of the infrastructure based on industry-standard methodologies and best practices to primarily validate the confidentiality and integrity of this infrastructure.”


“Prior to conducting the vulnerability and penetration tests, the consultant will provide a set of processes and description of specific activities and tests intended to be conducted during the vulnerability scans and penetration attempts and will obtain approval.”


“The consultant will develop a final test report: This report will detail findings, conclusions, and recommended remediation activities based on the test results.”


cartoon image of man at a computer from the side view

“The customer had no clue during the bidding process that they were contracting with a Respondent that had never done real penetration testing and could be considered ‘a fake and fraud’.”

- David Sockol, Emagined CEO



After being awarded the contract, the winner assigned a single resource to the test who had limited security penetration testing experience. That resource came onsite for 4 hours, ran some scans, and then left. The winner scanned the network surrounding the web application portal and did a few unauthenticated basic probes of the front-end website. After the scan, the winner provided raw results from a tool and a cover letter to the customer calling the project complete.


The customer was furious. Here’s the breakdown…

  1. The customer paid about $2,000 per hour for an inexperienced resource.

  2. They expected a multi-week engagement and they received 4 hours of support.

  3. Unfortunately, after reviewing the request and the work performed, the customer determined the winner had met the obligations of the RFP request and subsequent contract.

  4. The customer paid the bill and then called Emagined Security to help them determine how they could avoid getting into a similar situation in the future.


Dissecting What Went Wrong…

magnifying glass

Let’s go back and read the request again and see what happened. Together, we can dissect a few of the words in the RFP and see what the minimum work effort needed to meet the request is:


First Paragraph:

  • “infrastructure changes” = network changes = network penetration testing

  • “external facing components” = focus scanning from the internet outside of the firewall

  • “re-validate that these changes have not resulted in the introduction of vulnerabilities” = spot checking on changes and not a full test

Second Paragraph:

  • “conduct both external and internal penetration tests” = need to spend at a minimum amount of time testing from both the internet and an onsite location

  • “mainly involve web-application penetration-testing” = must include some web-application front-end testing

  • “well-defined scoping rules” = do not perform denial of service testing

What these paragraphs do NOT say:

  • Must perform authenticated web application testing

  • Must perform a web application comprehensive test

  • Must test the backend applications

  • Must test the database security controls

  • Must test the mobile application

What the customer got:

  • Scanning of 1-2 IPs associated with the external website’s network (1 port open – port 443)

  • Scanning of 1-2 IPs associated with the web application front-end system

  • Scanning as an unauthenticated user to see any of the top OWASP vulnerabilities exist

  • A raw report outputted from the scanning tools with generic recommendations and a coversheet with a few conclusions

To sum it up… the customer wanted an internal/external network assessment of the entire Oracle Peoplesoft environment and a web application penetration test and what they got fell very short of that objective.


This isn’t rare…

The customer is not alone, we receive dozens of RFPs a year that are poorly worded and the respondents provide wildly different bids. This got Emagined Security thinking about how the security industry could help organizations write better RFPs.

Within our Guide to Writing A Penetration Testing RFP, we recommend that RFPs be broken into sections that ensure a clear vision with goals that are clearly stated and presented to potential respondents with appropriate questions.

  • What is needed

  • What is required

  • What is being delivered

  • What is the cost

The Free Ultimate Guide to Penetration Testing RFP will help you develop an RFP that addresses these areas. Click the button and then scroll to the bottom of the page for the download.




Comments


bottom of page