Since MSI is a PCI scanning vendor, we are often included in various RFP/RFQ processes for the purchase of network scanning and assessment services. Over the last couple of years, one problem continually seems to raise its ugly head in RFP after RFP.
That issue is the lack of clarity in the RFP. Usually, the RFP issuer does not want to clarify the number of systems, applications, IP addresses or other relevant materials to the vendors. They want to keep that information private until after they award a contract. Below is a response I wrote this morning to a particular RFP issuer who is following this same pattern. Please read it and feel free to comment on the process, my response or any other items. I truly believe that only through communication, debate and eventual education can we find ways to take the customer and vendor pain out of these processes. Here is what I wrote in response to their posting about not wanting to reveal the number of IP addresses, except to the winner after the contract is awarded:
*Paste*
While I appreciate your process, I would suggest to you that your approach is not likely to achieve the best value for your organization.
Since you are choosing not to disclose the number of IP addresses to be assessed until after the winner is chosen, you essentially remove the very metric that the majority of scanning vendors use to create pricing models.
Thus, you force vendors to either respond with an hourly rate, or you force them to estimate the work and resources required. There is a risk to them and you in this estimation process. Their risk is that they could under estimate, thus causing themselves undue financial burdens. Your risk is that they will consistently overestimate, thus raising the prices that you get for a comparison and increasing the overall cost of the services you receive.
Of course, another possibility exists – that some vendors with ethical issues might respond to your lack of information by attempting to footprint your network and IP spaces to gather the relevant information themselves. Depending on their skills, tools and moral compass could cause a myriad of problems ranging from network congestion to denial of service attacks (inadvertent) as the various vendors who fit this model identify and map your visible Internet presence.
In our experience, the more information and clarity you can achieve in your requests for pricing information, the better. The clearer the scope of work, the more focused and relevant the responses will be and the more “real world” the costs. In every situation where we have seen prospects use the RFP process as a veil, the resulting engagements are damaged by scope creep, misunderstandings, miscommunications and higher than average costs in money AND relevant resources.
The most often quoted reason for RFP ambiguity that we have heard over the last 15 years is that the issuer did not want to “expose details to attackers”. After more than a decade and a half in this business, I have learned from experience that attackers already have exposure information. If they want it, they will simply map the network and gather it. They will also do so in ways that have little to no respect for your business processes, customer uptime commitments, maintenance schedules and other potential impacts to your business.
All of this said, again I respect your process and your right to proceed however you choose. Perhaps your intentions or requirements are not as presented above – which is fine. I simply wanted to address RFP/RFQ processes at large and I hope this information sparks discussion and comment among vendors and end-customers of security services alike.
*End Paste*
I went on to thank them for their inclusion in the process and to invite them to comment on this blog about the content. I hope they, and others do so. Please let me know your thoughts on this and other issues around RFP ambiguity. I would love to create a discussion between both vendors and customers about their ideas and feelings on the process!
