Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities & Threats

10:30 AM
Kennet Westby
Kennet Westby

How Not To Write A Pen Test RFP

The downside of a failed request for a penetration test proposal is a no-win situation for everyone. Here are five common mistakes to avoid.

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.

Kennet Westby is a founding partner of Coalfire and serves as its president and chief security strategist. Mr. Westby has over 20 years of leadership experience in IT security, IT controls design and implementations. Mr. Westby provides cyber risk advisory to some of the ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
7/8/2016 | 1:04:55 PM
Discussion Continuation
Peerlyst users commented on this article on https://www.peerlyst.com/posts/how-not-to-write-a-pen-test-rfp
97% of Americans Can't Ace a Basic Security Test
Steve Zurier, Contributing Writer,  5/20/2019
TeamViewer Admits Breach from 2016
Dark Reading Staff 5/20/2019
How a Manufacturing Firm Recovered from a Devastating Ransomware Attack
Kelly Jackson Higgins, Executive Editor at Dark Reading,  5/20/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-05-22
CSV Injection was discovered in ProjectSend before r1053, affecting victims who import the data into Microsoft Excel.
PUBLISHED: 2019-05-22
A CWE-754 Improper Check for Unusual or Exceptional Conditions vulnerability exists in Triconex TriStation Emulator V1.2.0, which could cause the emulator to crash when sending a specially crafted packet. The emulator is used infrequently for application logic testing. It is susceptible to an attack...
PUBLISHED: 2019-05-22
A CWE-200: Information Exposure vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause the disclosure of SNMP information when reading memory blocks from the controller over Modbus.
PUBLISHED: 2019-05-22
A CWE-248: Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause denial of service when reading invalid physical memory blocks in the controller over Modbus
PUBLISHED: 2019-05-22
A CWE-248 Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause a denial of Service when sending invalid debug parameters to the controller over Modbus.