Penetration Test Project

Related terms:

Penetration Testing, Project Management, Vulnerabilities, Penetration Test Engi-

neer, Penetration Test Team, Pentest Project, Project Manager

View all Topics

Learn more about Penetration Test Project

Pentest Project Management

Thomas Wilhelm, in Professional Penetration Testing (Second Edition), 2013

Project Assessments
The project assessment should identify aspects within the penetration test project
that worked well, or need improvement. The primary objective of the project as-
sessment is to provide the project manager with feedback on the overall flow of the
penetration test project and which phases of the project need improvement. Topics
of interest to the project manager include the following:

Scheduling issues (too little time, too much time, and so forth)

Resource availability

Risk management

Project scope issues (too broad, too narrow, and so forth)

Communication issues

The information provided in the assessment should confirm or challenge a project

manager’s own assessment viewpoint of the project processes and should present
ideas on how the project management process can be improved for future projects.
> Read full chapter

Hacking as a Career
Thomas Wilhelm, in Professional Penetration Testing (Second Edition), 2013

CCIE Security
Honestly, I have never seen a CCIE working on a penetration test project. By
no means am I implying that having a CCIE on a pentest project is overkill or
ineffective—it is simply that the CCIE has much larger issues to deal with and gets
paid a lot more money than what a typical pentest engineer would see. It would
be fantastic to have access to a CCIE as a subject-matter expert whom you can use
on occasion, which might be possible in large organizations that have a permanent
penetration test team; otherwise, you may just need to be happy with a CCNA, CCNP,
or CCNP Security (if you are really lucky). Regardless of the difficulty, it is still
helpful to understand what areas the CCIE Security expert is knowledgeable about
so that you can target any training budget to expand the pentest team to include
these network subject-matter experts within a project.

> Read full chapter

Strategies and Tactics

Thomas Wilhelm, Jason Andress, in Ninja Hacking, 2011

Method and Discipline

Method and Discipline are the tools, resources, and processes used by management
to successfully complete a penetration test project within well-defined time, cost,
and scope. The project manager will have a significant amount of input and work
within these two factors. Method and Discipline would focus primarily on project
management processes across all stages of a penetration test project, including the
following:

• Conceptual stage

• Planning and design stage

• Executing stage

• Closing stage
Modern project management methodologies can provide a significant number of
processes that are useful within a penetration test; however, there are additional
needs surrounding system and network attacks that require an expanded under-
standing of project management. Numerous published processes (such as those
available to an accredited professional management professional (PMP) through the
project management institute) must be adjusted to meet these additional needs. A
thorough discussion of the unique project management requirements needed with-
in a penetration test is outside the scope of this book and has already been addressed
in the book titled Professional Penetration Testing: Creating and Operating a Formal
Hacking Lab (ISBN: 978-1-59749-425-0, Syngress).

> Read full chapter

Methodologies and Frameworks

Thomas Wilhelm, in Professional Penetration Testing (Second Edition), 2013

Planning and Preparation—Phase I

The ISSAF attempts to provide users guidance in the area of Planning and Prepara-
tion—an area that truly is critical to a successful penetration test project. However,
the following quote is the extent of the ISSAF’s guidance in this area (OISSG, 2006).

Phase I: Planning and Preparation

This phase comprises the steps to exchange initial information, plan, and prepare
for the test. Before testing, a formal Assessment Agreement will be signed from
both parties. It will provide basis for this assignment and mutual legal protection.
It will also specify the specific engagement team, the exact dates, times of the test,
escalation path, and other arrangements. The following activities are envisaged in
this phase:

Identification of contact individuals from both side,

Opening meeting to confirm the scope, approach, and methodology, and

Agree to specific test cases and escalation paths.

This is pretty much useless for any professional penetration test analyst. A different
methodology for planning and preparing a professional penetration test project
should be used; we will discuss some options in Chapter 5, titled “Pentest Project
Management.”
> Read full chapter

Building penetration test labs

Jeremy Faircloth, in Penetration Tester's Open Source Toolkit (Fourth Edition), 2017

Use what your clients use

This may be a bit obvious, but if your clients use a particular architecture, your
penetration test lab should probably have the same thing. This has a drawback,
though. All new clients that you contract with need to have the same type of
equipment as well, or else you will end up buying extra equipment every time you
get a new customer. This can have a limiting effect on expanding your business.

There is a drawback in selecting only one architecture on which to run penetration

test projects; by limiting your architecture, you are limiting who your customers
can be. This is not always bad, though. If your team focuses on a niche target,
such as supervisory control and data acquisition (SCADA) systems, your penetration
test team could have more work available than they can handle. Nevertheless, by
using only the equipment that your clients use, your team will be able to focus their
energies and knowledge while also keeping costs down.

Often, by using what your clients use, you run into a situation in which nobody on
your team is a subject expert, especially in a niche market. This has the unwanted
effect that the money you save (by not buying all the possible equipment combina-
tions available) can get diverted into hiring expensive subject-matter experts. Often,
hiring a subject-matter expert is just not in the budget. If this situation is familiar to
your penetration test team, a better approach is to provide additional training to the
penetration team members. This is great for the team members because they get to
improve their skills, but these training costs are not always expected by management
and can cause poor results in actual penetration test projects if not committed to.
Remember, niche training (and penetration testing is a niche training field) is much
more expensive than the more common ones; something management may not be
happy with or accustomed to.

> Read full chapter

Reporting Results
Thomas Wilhelm, in Professional Penetration Testing (Second Edition), 2013
 Out of Scope Issues
The strange part about a professional penetration test is that it seems that the test
could go on forever. Once a vulnerability is exploited, additional targets appear on
the radar—targets that often are more attractive than the system just exploited.
Given enough time and resources, a pentest team could theoretically exploit all
systems on a given network.

Unfortunately, time and resources are finite, and objectives must be defined within
the penetration test project. This does not mean that during the course of the pentest
we should ignore potential vulnerabilities that lie outside our project scope—just
the contrary. During the course of a penetration test, we need to be aware and
document other areas that our customer needs to examine at some future date. Not
only does it alert the customer of a potential problem but it also increases our chance
of obtaining future business.

There are two different findings when it comes to the term “out of scope”—the
first being findings that are discovered during the course of the penetration test
on a target system. The second includes findings that indicate systemic flaws in the
overall architecture. An example of finding an out-of-scope vulnerability within a
system would be if we discovered undocumented applications running on a system
that we were tasked to do Web scans against—we would like to know why those
applications are there even though it wasn’t something we were hired to examine.
Another example is if we were to find our target system communicated with a remote
server outside the customer’s network—a question of trust, data sensitivity, and
encryption methods on the external server would be a concern, but one that might
be outside our scope. Again, this does not mean we need to ignore the discovery
just because it is out of scope—note the discovery and include it in the final report
as something that the client should examine further.

A systemic flaw in the overall architecture is usually something that might be more
of a guess on our part, than something grounded in facts. An example would be the
discovery of weak passwords on a target system. It is possible that the only system
in the entire network with weak passwords is our target; however, there is a chance
that the corporate password policy or strong-password enforcement mechanisms
are being overlooked or undermined throughout the entire infrastructure. In cases
where we believe a specific area of concern might be prevalent across an architecture,
we need to voice our concern with the client within our final report.

> Read full chapter

ScienceDirect is Elsevier’s leading information solution for researchers.

Copyright © 2018 Elsevier B.V. or its licensors or contributors. ScienceDirect ® is a registered trademark of Elsevier B.V. Terms and conditions apply.