All language subtitles for 007 Planning a Test (OBJ 1.2)

Instructor: When it comes to penetration testing,

planning is incredibly important.

There are three major factors for any assessment.

Time cost, and quality.

These three factors are always in competition

with each other and decisions on their priority

have to be agreed upon between the penetration tester

and the organization that's contracting that engagement.

For example, if you want the assessment to be faster,

it's gonna cost you more money

or it's gonna require a lower quality threshold.

If you want a really in depth and high quality engagement,

then it might cost additional resources

in terms of people and money,

or it might take you more time.

If you want an inexpensive penetration test to be conducted

then you really shouldn't expect it to be high quality

or really quick.

Again, these are competing factors that you must consider

during your planning,

and it's also important to understand

what the company is expecting

and what you can provide during the proposed timeframe.

There are various areas of consideration

when you're planning an assessment.

This includes things like,

who is the target audience?

What is the objective?

Is this a compliance based assessment?

What resources are required?

Who will we communicate with and how often?

What product will be required to be presented

at the end of the assessment?

Are there technical constraints placed upon the engagement?

And how comprehensive will the penetration test need to be?

First, we have to ask who is the target audience

for the penetration test

and what kind of business do they perform?

Are they a small local retail store

that needs a simple payment card

industry data security standard,

or PCI DSS compliance penetration test,

or are they a large multinational bank

with offices all over the world

who want you to test all 100,000 branches?

Depending on the answer to these questions,

the scope of your assessment is gonna be vastly different

because of their different sizes, missions, and operations.

Second, what is the objective of the penetration test?

Is the organization contracting the engagement

in order to meet a compliance requirement or regulation?

Are they conducting due diligence

in their testing and software assurance

before a product is gonna be released?

Both of these are valid objectives for a penetration test

but each of them requires a different approach.

By understanding your target audience and their budget,

you can design a better engagement,

that'll more efficiently and effectively

meet their objectives.

Third, what resources will be required

to carry out the penetration test?

For example, if my company was hired

to do a penetration test on a large chain of retail stores

that's located out in Hawaii,

but that company is not allocated any funding for travel,

then my team won't be able to conduct

a physical penetration test

because our offices are not located in Hawaii

and we're gonna have to fly out there to do it.

On the other hand, if they have a really large budget,

then we can support a very large or in depth assessment

including onsite testing of their physical security

as well as resiliency to social engineering attacks.

Now, we might also be able to fly people on site,

hire contractors, have a longer timeline,

increase the scope

and have greater access to people in technology.

However, if we're given a smaller budget,

then we're gonna have to adjust the scope downward

appropriately to meet those restrictions.

Now, let's go back to the Hawaii example for a minute.

Assuming that we have a smaller budget assigned

we're then gonna have to minimize the scope

to only provide an external assessment

of those networks over the internet.

Now, if that meets the company's objectives,

then we can move into contract negotiation

and start agreeing to a price.

However, if it doesn't,

then it's gonna be important to negotiate a larger budget

in order to support an onsite assessment

or we're gonna have to turn down the assignment

and recommend they hire a penetration tester

who is local to their company.

Now, when we're looking at resources

and requirements for this test,

it's also important to consider

what resources are gonna be needed

and the costs associated with having those resources.

Do we need to be onsite

or can we achieve the same objectives remotely?

Do we need the test done from inside the company network

or from an outside perspective?

What requirements must be met during the test?

Do we need to use end-to-end encryption?

All of these requirements will take up additional resources

from the project.

For example, if we're gonna be required to test

for both known and unknown vulnerabilities,

we're gonna have to come up with our own exploits

which cost us more time, more money, and more resources,

than using existing toolkits like the Metasploit Framework

with its open source and well-documented exploits.

Next, we need to ask if this test

is part of a compliance based assessment.

If so, the engagement becomes a little easier

because there are checklists provided by most organizations

or legislative bodies, for your testers to utilize

and this will ensure that all of the appropriate devices

have been scanned to the appropriate level.

For example, a PCI DSS scan has a specific checklist

that an assessor or penetration tester

has to utilize to verify compliance

with the PCI DSS standards that are used

for credit card processing.

Even though we're gonna cover the details

of those during the scoping of our assessments,

it's also important early on to be able to outline them

in the planning phase to ensure

that the organization understands the level

of resourcing that's going to be needed

to meet the proposed requirements.

Now, during our planning,

we're also gonna outline our communication plan.

Who can the penetration tester communicate with

during this assessment

and how often will that communication occur?

For example, if the chief technology officer

hired your company,

are you only allowed to speak with them

or can you also speak with

the information technology department

about the fact that you're planning to conduct

a penetration test?

The answer is gonna be dependent

on your contract with the organization

and whether they're trying to test their systems,

their personnel, or both of these.

Even if you're conducting a blind test

to see if people fall for your tricks in social engineering,

you still are gonna need a trusted agent

inside that organization

who you're gonna be able to communicate with

if something is going wrong.

This person will also contact you

during the deconfliction process to determine

if a detected attack

is actually your penetration testing team

or has some real threat actor

actually hacked the organization.

You need to have these lifelines established

well before the testing begins

so set this up while you're planning your engagement.

Next, we should ask, what product or report

will the penetration tester provide the organization

at the conclusion of this engagement?

Now, when we get to domain four,

we're gonna talk all about reporting and communication

in depth and I'm gonna provide you with the details

of a standard penetration testing report.

But keep in mind,

these can be modified by the organization

to whom you're providing the service.

Some organizations I've worked with previously

have requested the executive summary be provided

as a brief using a PowerPoint format

and others want to have something written

in long form prose.

We also need to find out how detailed

the report needs to be.

For example, if I've run a vulnerability scan

I might have a 300 page document

that I can provide to the organization

with every single vulnerability that was discovered

in their network,

but most companies would rather us prioritize

which vulnerabilities they need to address first

as well as how much time and money

it's gonna cost to fix them.

Again, this is all negotiable

and should be discussed during the planning phase.

Next, is the customer gonna place any technical constraints

on the penetration test?

For example, are you allowed to test their database servers,

their web servers, or their printers?

Any limitations or constraints have to be understood

during the planning phase

so the assessment can be properly scoped.

If I was testing an organization

that focuses on manufacturing, for example,

one of the big concerns I have

is whether or not my team and I can conduct exploits

against their ICS and SCADA systems

because these systems are very likely to break

if you're using standard penetration testing tools,

if you don't know what you're doing.

Often those systems are removed from the scope

of our assessment or maybe we're required to test them

and we're gonna bring in some specialists to assist us

to make sure we don't break anything.

Now, either of those two options is perfectly acceptable.

It's just important to agree to it upfront

and detail that decision inside of the contract

and your scope of the engagement.

Now, when planning an assessment,

it's also important to ensure that the organization

understands that the assessment is just a snapshot

of their current security posture.

If we completed an assessment today,

it can only tell the organization

what vulnerabilities existed as of today.

A new vulnerability may be discovered in a week

and it may have taken us three weeks to finalize a report.

Obviously, our assessment, and in turn our report,

are not gonna cover that new vulnerability.

When you're negotiating an assessment,

be clear that this is a point in time assessment

and this means that you're only gonna be held liable

for disclosing the vulnerabilities that were discovered

at the time of the assessment.

After all, new vulnerabilities are discovered

every single day

and you can't be expected to know

about a vulnerability that hasn't been discovered yet.

Finally, your client also needs to determine

how comprehensive the engagement needs to be.

Are you gonna go out and look for every single vulnerability

or are we just trying to find at least one way

to break into the network?

While some clients want the former, others want the latter.

This is another key consideration

as it will greatly affect the size, scope, and duration

of the assessment and the resources that it requires.

Remember, the more comprehensive the engagement,

the longer the duration and the larger the scope.

Another thing to determine

is which parts of the organization

are going to be included in this assessment?

Are we testing the entire organization

or just the information technology department?

Whichever it is,

it needs to be agreed upon upfront

during the planning and scoping phase

and then detailed in your final report

during the reporting and communication phase.

(soft tones)