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 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
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-15564
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be map...
CVE-2020-15565
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 Intel HVM guest OS users to cause a host OS denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs....
CVE-2020-15566
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, o...
CVE-2020-15567
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes...
CVE-2020-15563
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 HVM guest OS users to cause a hypervisor crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM g...