Hi, I'm Alex Tushinsky.
I'm very much excited to bring you this course on the
initial first steps of a penetration test.
In this course, Pen Testing: Planning, Scoping,
and Recon,
we'll talk about the documents you'll need and how to plan out your test.
Well then walk through the steps of passive reconnaissance,
which is a foundational step in a successful engagement.
In this module, we'll look at the early steps of a penetration test engagement.
Specifically, we'll cover the project management aspect.
This includes working to identify the scope of the engagement,
the dates and times during which the attack can be performed,
and overall ensuring that you and the organization
requesting the work are on the same page.
Next, we'll also look at effective note taking.
I'll show you a couple of popular note taking applications,
and then we'll discuss various ways in which you can set up your notes.
Notes play an important role throughout the engagement.
It's how we identify what we need to do, such as the scope of the engagement.
And then, we also need our notes for the final report,
remediation,
and to answer any questions that come up during and after the engagement itself.
Having good notes can help you recreate attacks for demonstration
purposes and can be used to build an effective playbook,
a tool that you can use over and over again with other tests.
Let's begin our discussion with project management.
So you've landed your first penetration test engagement.
So what should you do first?
I'm approaching this from the perspective of a consultant or freelancer.
If you work for an organization,
you may not necessarily be part of these first initial steps.
That said,
I think it's important to understand what happens and how we
end up with the specifications for the test,
so stick with me here.
As basic protection for both you and the client,
a non‑disclosure agreement is typically signed first.
We'll talk about the details of this document later in this course,
but, essentially,
it helps protect you and the client and helps establish
a working, trusting relationship.
Next comes the part of the pen test that is crucial to a successful engagement,
but isn't always seen as an important step.
Let's take a look.
Well, of course, we're talking about project management.
And project management consists of some tasks that help shape the test
and ensure everyone involved is on the same page.
First, we have the goals and objectives.
This represents the basic premise and the expected outcome of the test.
Next, comes the scope of work,
which is a further breakdown of our objectives to outline
the actual work that must be performed.
The work comes at a cost,
so it's important to establish the appropriate budget to perform the work.
The schedule is then determined and a detailed
communications plan is established.
Lastly,
we identify all of the deliverables and outline them in a statement of work,
which is then signed off by the client, and we're off to do the engagement.
So let's unpack that.
We started with goals and objectives.
What exactly does that mean?
Let's begin with goals.
Goals are the outcome I want to see as a client.
These are achievable,
and we should be able to measure them using the SMART acronym.
SMART breaks down into specific, measurable,
achievable, realistic, and time‑bound.
Specific means each of the goals that I put in place
has a purpose and is well defined.
Measurable.
I should be able to put some sort of quantitative measure against my goal.
This could be a percentage, a value, a dollar amount,
or anything that I can look at, see a difference,
and determine if the goal is working or not.
Achievable.
When defining goals, they should be achievable.
Without the ability to identify and call a goal finished,
how would we know that we're done.
Realistic.
Along with achievable, is this requirement for the goal to be realistic?
While some may confuse the two as being similar, they are not.
For example,
you may be given a goal that requires a million
dollars spend in order to achieve.
Can you do it?
You sure can if you had a million bucks,
but because you don't, this goal is not realistic.
Lastly, we have time‑bound.
Goals can't be open‑ended and have to have some sort
of end date or end state defined.
There are several types of goals for a pen test,
for example, many organizations are obligated by contract or a
regulatory body to perform penetration tests. As such,
compliance with their legal and contractual requirements typically are a goal
for a pen test. Working as a CISO, I was always required to conduct at least
one major test per year, with my preference being on two or more focused on
different areas of the enterprise.
This however,
should not be the sole focus of a pen test. At the compliance
level, any engagement that can be called a pen test is
sufficient to check the box, as they say.
I've seen very basic vulnerability scans being executed and called a
pen test for this purpose, but it does not benefit the organization
from a security standpoint in a major way.
So the pen test should also include goals that are specific to the
applications in the network environment for the test being conducted.
That makes a difference from a security perspective and at the same time,
checks that box on the compliance aspect.
Here's an example of one of those security‑specific goals.
Identify vulnerabilities in Application X that permit a
non‑administrative account to access personally identifiable
information in software release version 3.01.
Okay.
Is that specific?
Yeah. We must identify vulnerabilities in Application X for
the non‑admin role in software release 3.01.
That's very specific.
Is it measurable? We're asked to produce 0 or more
vulnerabilities for the non‑admin role.
Is it achievable?
Seems like it is.
I'd say that given access to the application,
we can certainly perform many different attacks to see what's possible.
And finally, is it realistic?
Yes, it's realistic and quite common of a request.
Hence, this is a smart goal.
Okay, let's talk about objectives next. Objectives are how we
achieve the various goals of a pen test.
They are the actionable steps that we'll take to achieve the goal.
For example, if our goal is to find vulnerabilities
specific to non‑admin accounts,
our objectives might be to identify IDOR, or insecure direct
object references, instances or have specific objectives on
privilege escalation or backdoors.
Next, we need to determine the scope of work. First, it is helpful to
identify the list of resources and endpoints that we will be working
with. There are times this is done simply at the IP address level and at
times, by application or function. Regardless of how you determine it,
be sure to look at the work and not get fixated on the count of IP
addresses or servers.
For example, I may host 100 different applications on the same server.
So if that server is in scope,
which applications would be open to the test and which ones aren't. Then, you
may want to break down applications for features or screens.
Essentially, this identifies how a pen tester's time will be spent.
Next, we need to determine what is out of scope, and are there any
systems that we shouldn't touch, or are there any specific tests not
going to be performed? For example, a denial of service attack on the
server is typically out of scope.
Organizations also don't always want a social engineering engagement.
So it's important to establish what you can and
cannot do. And as you've guessed it,
this is dependent on having some clear goals and objectives.
Another item of note here is data. For example,
it may be out of scope for you to destroy or alter data
that is part of the attack surface.
This can sometimes make the tests a bit more challenging, as
you have to be able to stop just before executing a destructive
attack and document what you think would happen or at least a
set of possible outcomes.
The scope helps outline all of the systems that need to be tested and
what tests can be performed. Now that you have done that, you can
start building out your statement of work.
Next is the budget.
Several factors help determine this.
The first being the scope that we just talked about. Working
through 1000 different endpoints and 20 applications is different
than working through an engagement where only five endpoints and
one application are in scope.
Next comes your pricing. Whether you work for an
organization or are a freelance or consultant,
there is an hourly rate that can be applied towards scoped work.
You can roughly estimate how many hours it would take to run
each of the different pieces of the scoped work and then
multiply that out by your rate.
Many organizations also apply a 20% overhead charge here.
This 20% is used as a buffer for any overages or scope creep, but is
not typically charged if the tests come in on time.
Now that budget is established,
be prepared for it to adjust based on the last factor in budgeting,
which is the finance department.
Yes,
if the organization physically didn't allocate the
funds for the proposed scope of work,
then the scope needs to be adjusted to reflect the budget and
resources that the organization did allocate to the test or finance
needs to find other ways to fund the engagement.
Sometimes this happens, often though, the scope is reduced to
match the allocated budget. With scope and budget out of the way,
we can start to talk about the schedule.
This is determined by the availability of the
environment that you will be attacking.
Test environments can sometimes be built specifically for the test, so
knowing when the environment will become available is an important part
of you being able to schedule the work.
We also want to ensure that company resources are
available and can handle any requests or work in
preparation or during the test. For example,
do we need account setup, and how long will that take?
Do we need an implant or dropbox installed in their network?
Is there someone who can get that work done for us, and when?
What about ongoing support during the test?
Is there someone who will continuously help us, answer questions,
and onboard us so we can better understand the applications or the
network environment? All important aspects and all quickly become
dependencies on the schedule.
Is the test environment available 24/7 or is it only available
for testing after 5:00 pm and on weekends?
These are important considerations, as many organizations test
their UAT or production environments, which may be doing other
work concurrently with the testing.
They may not want to allow you to test during normal working
hours to keep the environment stable for customers or other
business‑related functions.
Your availability is also important here.
If you're going on a two‑week vacation during the test,
then it may be best to schedule things outside of that time frame.
Or you may want to break up the test in two phases where some work is done
before your vacation and some after. Vacations aside,
you may be managing multiple pen test engagements at the same
time. So take that into consideration as well, as dedication
to specific tasks is important.
You may not do well attempting to break into two or three
different environments at the same time and be able to
keep it all clear in your head.
Again, budgets and scope determine some of this to some degree.
The schedule is it influenced by the number of hours you're able
to spend on specific tasks, and this is determined by the budget
and the scope of the engagement.
Lastly, we'll be talking more about the rules of engagement document shortly.
Your schedule and the scope is important in getting
this document crafted and agreed upon.
The communication plan is one of the most important
documents of the entire engagement.
This document helps shape all of the different channels of
communication that you have for reporting the various findings.
First, is the point of contact for support.
This should be an individual or group of individuals
that answer any of your questions,
help you get set up within the environment, and ensure that
resources on the organization side provide the needed access
and support for the engagement.
The escalation path is important as well.
Here we set up channels and protocols for reporting critical issues.
In other words,
this should be a secure method of communication and should have
several people on it who can make quick decisions in regards to what
needs to be done to stop the bleeding or prevent an identified issue
from being a bigger problem.
Imagine that as you begin your test,
you identify a breach in progress or as you begin your test,
you find a piece of personally identifiable information in a
publicly accessible folder or imagine that you begin your test and
manage to crash your production environment.
These are the kinds of things that we're talking about
here that quickly need to be escalated.
You may also come across illegal activity. If there's evidence of this,
you need to be able to reach out to an independent party, as
well as key people within the organization.
This should not necessarily go through the same channel
as your support or escalation contact.
I'd have legal, CEO, or another executive, and possibly
the police, and/or the FBI on this list.
I'd also look for at least two people from legal and at least
two executives for this type of escalation.
Next is the report.
Who is the party that will accept the report,
work on remediation, or provide justification for the items you have
identified? The communications plan should also list out similar contacts
on your end. Your details, as well as an escalation path for you and your
organization should also be provided.
Lastly,
your project management aspect of a pen test wraps up with the deliverables.
These are the objectives assigned to you within the report that the
organization is expecting you to deliver that meet the project goals.
Typically, supporting material may be requested,
including how to re mediate specific items found, notes on how to
recreate the vulnerability, and any supporting information.
Some companies may request a debrief session. Here, the pen
tester is asked to go through the report and discuss the
findings with the internal team.
This may include developers, project managers,
executives, and others who are interested in understanding better the
types of vulnerabilities that have been found. Depending on the
audience, this may be a very technical discussion or may be a very
high‑level one or somewhere in between.
Lastly, remediation and retesting should be part of your budget,
scope, and schedule.
Note that organizations can be notoriously slow at patching software or servers,
so it's best to give them some time to get the fixes in place.
That said, it shouldn't be open‑ended.
Most pen testers that I've worked with provide 90‑180 day window in
which they can come back retest and update the report to reflect the
fact that the vulnerabilities that they have originally found have
been closed and are no long valid.
This remediation and retesting phase is a critical component of a pen test
because it essentially completes the goals. Without it, you have a set of
vulnerabilities and no way to gauge and identify if these are problems today
or were at the point in time of the pen test.