All language subtitles for 008 Validating the Scope (OBJ 1.2)

Speaker: Once the rules of engagement

have been agreed upon,

the type of assessment and strategy chosen

and the scope has been defined and identified,

it's now time to validate

the scope of the engagement with the client.

Validating the scope of the engagement

involves confirming all of the requirements,

the scope and the details of the engagement

before you gain final approval and permission

to move into the next phase

and conduct information gathering

and vulnerability scanning.

Your penetration testing team should always ensure

that the target organization has a good set

of system backups and recovery procedures as well.

This way, you can ensure that

if something goes very wrong during the engagement,

a partial or full recovery can be performed

to restore operations.

During the validation of the scope,

your team should also verify that they know who to contact

within the client organization if something goes wrong,

something needs to be deconflicted, or if they discover

an exceptionally high risk vulnerability.

When you're validating the scope of the engagement

with the client, you should also review all of the key areas

from the statement of work and the rules of engagement

to ensure that there are no areas of confusion.

This will include a thorough review of several items

including the scope and the in-scope target assets,

what is excluded from the scope

and what's considered out of bounds,

what strategy will be used such as an unknown,

partially known or known environment test,

what the timeline will be for any testing,

as well as any constraints placed upon your working hours,

any restrictions or applicable laws

that will apply to this engagement

as well as any third party service providers, services

or off-site locations that are being considered.

And finally, the proper communication channels to use

during the assessment in order to provide updates

to key stakeholders.

Now, once we have our discussion with the organization,

we're going to find that certain applications,

systems, networks and even users may be placed

on the allowed or excluded target list for the engagement.

Now, an allowed list contains a list of authorized targets

while an excluded list contains a list

of unauthorized targets that we can't go after

during our engagement.

Many organizations have numerous boundary defenses

such as unified threat management systems,

firewalls, intrusion prevention systems

that could block your access from the internet

when you're conducting a penetration test.

These systems are most commonly used to allow

or prevent outsiders from accessing the network

and operate by listing the IP addresses

or ports in the access control list

as either permitted allowed or denied.

Now, depending on the scope of your assessment,

your target organization

may allow your penetration testing system

to be placed into an allow list to bypass some

or all of these boundary defenses.

For example, if the organization wants you

to conduct an internal assessment,

they might allow you to have a VPN connection directly

into their network by placing you into an allow list

in order to simulate what an insider threat

or authorized user might be able to accomplish

during an attack.

On the other hand, the organization may be more interested

in seeing if you're able to bypass their external firewalls

and their intrusion prevention systems

during an external assessment.

In this case, they're not going to add our systems

to their allow list or allow us to bypass them directly

and instead they'll make us work for it.

Another concern is that

if the organization's network defenders

catch your penetration testing team during your assessment,

they could add your systems to their block list.

And effectively block us

from directly accessing their systems anymore.

This could require us to find a new way

to bypass their boundary defenses

in order to break into that network.

Now, if time is running out during your assessment,

you may need to talk with a trusted agent

within the organization to have them unblock your systems

or even a you to the allow list within the boundary device

so that you can continue to meet the other objectives

of the penetration test

if those boundary devices are becoming too difficult

to bypass or exploit.

This should be accounted for

during your planning for the engagement

by thinking about possible security exceptions

that you may need to ask for as a contingency.

Many organizations have a lot of different security devices

on their networks, including intrusion prevention systems,

web application firewalls, network access control systems,

certificate pinning, and company policies.

Depending on which policies and systems are being utilized,

the penetration tester may need to ask for an exception

to be allowed into one of those systems

to be able to conduct their penetration test

and be able to connect fully to that network.

For example, maybe the penetration tester

was hired to test the application

behind the web application firewall

and not the firewall itself.

In this case, adding an exception

to the web application firewall to allow them to bypass it

would become a reasonable request.

Finally, you need to realize that some networks,

as part of their network access control or NAC,

do require a digital certificate to be installed

on the network device prior to it

being able to connect to the network.

We call this certificate pining.

Now, if they do, you may need to ask the organization

to provide you with an exception

to their certificate pinning policy.

In which case, the organization could provide you,

as the PenTester, an authorized digital certificate

for your workstation in order for you

to connect to their network

without tripping their NAC sensors.

Again, it depends on what they're trying to focus on

during this engagement.

If they're not trying to test the NAC sensor,

it'll be okay to bypass it.

Now, as with a lot of things

in the planning and scoping stages,

there really is no right or wrong answer here.

Other than what you have negotiated and agreed upon

between your penetration testing team

and your client organization.