How Not To Write A Pen Test RFP

At Coalfire, I have seen many high-quality penetration test requests for proposals as well as others which – let's just be nice and say – they lack sophistication.

The good news is that growing board-level interest in security assessment and testing has led to an increase in well-informed RFPs that truly help company leaders become more knowledgeable about the security issues they face on a daily basis. This trend comes on the heels of recent guidance to security executives from the National Association of Corporate Directors (NACD) on how to discuss cybersecurity capabilities with organizational management.

The downside of a failed pen test RFP is a no-win situation for everyone. It leaves businesses with unmet security testing needs and budgetary battles over project funding. Penetration testers, in the next go-arounds, are less likely to invest the time they need to develop proposals tailored to the specific needs of the companies issuing the requests.

I’ve combed the backlog to determine common penetration test RFP mistakes. Here are the top five:

1.)  "Penetration test without exploitation"
Occasionally, services are requested that ask for features that are incompatible; for example, a "penetration test, without exploitation." The penetration test is conducted to determine the system’s weaknesses, while the exploitation of vulnerabilities can be more simply termed as the software used to test the system’s weak spots. Without exploitation, followed by pivoting from a compromised system to find systems that can help us achieve the objective of the test, key constructs to the penetration test are lacking. Without exploitation (which is a prerequisite for privilege escalation and pivoting), the “ask” is for a vulnerability assessment, so the RFP has failed to identify exactly what is requested.

2.) Redundant service requests
We see requests that ask for both "vulnerability assessment" and "penetration testing." Penetration testing requires vulnerability information to be gathered (read: assessed) in order to proceed. Penetration testing without vulnerability assessment can't occur. The key differentiator here is that the deliverable from a vulnerability assessment is a report of vulnerabilities in the organization. Meanwhile, the deliverable from a penetration test is a report of vulnerabilities in the organization and those that were exploited as part of the testing.

3.) Vague objectives
If an organization fails to tell us what they’re testing, we lack the context of why the service has been requested. A vague objective (statements such as “understand our security posture”) tend to be rather obvious given that they’re requesting security testing services. Objectives stated in a way that defines the purpose of the test, for example, “understand our level of vulnerability to attacks” or “understand the level of effectiveness of our security program in detecting and responding to attacks against the environment” would provide the background for respondents to ask intelligent and specific questions. In the latter case, we would follow up with questions like, “Are you intending this test to be announced to your security operations team?” and “Are you looking for a stealthy approach that attempts to evade detection?” If we don’t understand what you are after based on how you wrote the RFP and without a detailed description of what we do and how we do it, it’s highly unlikely that we will understand the purpose behind the questions.

4.) Services over the organization’s maturity level
Occasionally, we propose and are awarded contracts for services from which the organization cannot immediately benefit, for example, a red team penetration test for an organization that does not yet have a security program in place. A red team attack emulates a specific, determined adversary that is intending to achieve a specific objective by attacking an entire environment. If we carry out this attack and find that the “real-world attacker” would most easily compromise the environment by walking into it and connecting to the environment, that’s where we will direct our effort. We might not address any internet-facing systems or applications, or even blink at your high-security remote access solution.

5.) Failure to define scope
This is a pitfall that is critical to the entire process. Inability to define scope in the RFP is a recipe for failure because vendors will be unable to estimate the effort necessary to specify the types of tests to be performed and determine what it would take to address the environment.

The best way to avoid these mistakes is to replace the RFP with an RFI (request for information, not specific pricing), which can provide insight into providers’ capabilities and how they can meet your needs. Furthermore, as you draft your RFI, don’t feel compelled to include requests from every corner of your business. This will result in a lengthy, but watered-down proposal. While it’s important to have buy-in from stakeholders, the objectives for this particular service should be clear and concise, so avoid the “design by committee” approach.

Finally, don’t allow the “fear of impact” to drive specific wording. Even if this is the first time your organization has done this, it’s far from the first time the vendor community has ever received an RFP. Specific guidelines, such as the rules of engagement, can be worked out when the work commences. Of course, the RFP (or RFI) is just a single step along the way toward building a more secure business model, but it also goes a long way toward ensuring its effectiveness. 

Related Content:

Black Hat USA returns to the fabulous Mandalay Bay in Las Vegas, Nevada July 30 through Aug. 4, 2016. Click for information on the conference schedule and to register.