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

7/5/2016
10:30 AM
Kennet Westby
Kennet Westby
Commentary
50%
50%

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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
AlecH195
50%
50%
AlecH195,
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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
'BootHole' Vulnerability Exposes Secure Boot Devices to Attack
Kelly Sheridan, Staff Editor, Dark Reading,  7/29/2020
Out-of-Date and Unsupported Cloud Workloads Continue as a Common Weakness
Robert Lemos, Contributing Writer,  7/28/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-16271
PUBLISHED: 2020-08-03
The SRP-6a implementation in Kee Vault KeePassRPC before 1.12.0 generates insufficiently random numbers, which allows remote attackers to read and modify data in the KeePass database via a WebSocket connection.
CVE-2020-16272
PUBLISHED: 2020-08-03
The SRP-6a implementation in Kee Vault KeePassRPC before 1.12.0 is missing validation for a client-provided parameter, which allows remote attackers to read and modify data in the KeePass database via an A=0 WebSocket connection.
CVE-2020-8574
PUBLISHED: 2020-08-03
Active IQ Unified Manager for Linux versions prior to 9.6 ship with the Java Management Extension Remote Method Invocation (JMX RMI) service enabled allowing unauthorized code execution to local users.
CVE-2020-8575
PUBLISHED: 2020-08-03
Active IQ Unified Manager for VMware vSphere and Windows versions prior to 9.5 are susceptible to a vulnerability which allows administrative users to cause Denial of Service (DoS).
CVE-2020-12739
PUBLISHED: 2020-08-03
A vulnerability in the Fanuc i Series CNC (0i-MD and 0i Mate-MD) could allow an unauthenticated, remote attacker to cause an affected CNC to become inaccessible to other devices. The vulnerability is due to improper design or implementation of the Ethernet communication modules of the CNC. An attack...