All language subtitles for 005 Identifying Restrictions (OBJ 1.1)

Instructor: Every organization has

a different risk tolerance threshold.

This risk tolerance threshold

will become a big point of contention

during the planning of the timing,

the tempo and the scope of your engagement.

If the organization is quite risk averse,

you're gonna need to be extra careful

not to cause any disruptions to their operations.

And therefore, you might have a smaller scope

and perform a very tightly controlled engagement.

If, however, they have a higher risk tolerance,

then the penetration tester may be given more leeway

to conduct a larger scope or faster tempo engagement.

Always remember, there are four things

that can be done with risk:

avoid, transfer, mitigate and accept.

If an organization wants to avoid risk,

they're gonna tightly control the engagement

including the scope and the tempo.

If they wanna transfer the risk,

they may wanna move the risk to another entity

such as making the penetration tester

sign an agreement that states

that if a system crashes during the assessment,

the penetration tester

is gonna be responsible for getting it fixed

and paying for any damages

or they may want us to mitigate the risk

by only allowing the penetration tester

to conduct that assessment during certain times,

or they'll exclude testing from occurring on certain days

such as during peak business hours.

The organization can also simply accept the risk.

If they have a high enough risk tolerance,

that organization may just say,

"Go ahead and start your penetration test anytime.

We're willing to accept the risk

of any downtime that you might cause."

Now with the risk tolerance

and the restrictions agreed upon

by both the penetration tester and the client,

it's now gonna be important to determine the exact impact

of this tolerance

and ensure that the organization understands it as well.

You're gonna have to answer the question

of what is the impact to operations if things go wrong?

For example, if we begin a penetration test

and we cause a server to trip offline,

how is that going to affect the company?

They're gonna have to consider this in their risk calculus

by balancing the needs of conducting a full assessment

against their needs to continue their business operations.

As a part of this, they may exclude certain things

from the scope of the engagement too.

For example, if I hired you as a penetration tester,

I might create a scope for you to test

my company's internal network storage servers,

our web servers, our internet connection,

and all of our physical security

but I might specifically exclude our email servers,

our e-commerce servers,

our public databases and our public Wi-Fi.

Now that you understand your restrictions,

you can then go and plan and build the engagement plan

with those specific scoping limitations in mind.

These different restrictions are gonna be placed upon you

because of the risk that I, as your customer,

am willing to accept during this particular engagement.

Now your client organization's risk tolerance

will directly affect the scope of our assessment

but it will also impact our schedule and timing.

How long will we be on the network

conducting your assessment?

Will the organizational network defenders

be informed ahead of time of your schedule?

Perhaps, they're gonna know

that the penetration tester was hired

and they're gonna attack some time

within the next three months

or maybe they're being provided with the exact date and hour

for the attack window to occur.

This, again, is negotiated during your engagement's planning

and scoping phases.

If the organization wants the penetration tester

to participate as part of a red team/blue team engagement,

then the defenders should be aware

that the red team is planning to attack.

However, if you wanna simulate a true threat actor

during a penetration test,

the defenders probably shouldn't be aware of that schedule

or even that a penetration tester has been hired,

but this, again, is up to the organization

who hires you for that engagement.

Once we identify any time and date restrictions,

client stakeholder negotiations,

and the total list of included and excluded targets,

we can then build a schedule

with the organization's trusted agent

to decide how and when the penetration test

is going to occur.

Finally, you need to be wary of scope creep.

This occurs when a client starts asking for more services

than what was originally listed in a statement of work.

If, for instance, we agreed to do 10 servers

at the time of signing the contract

and drafting up the scope of work,

but now halfway through the assessment,

you come back and ask us to scan another five servers,

well, that's a big change in scope

because it's a 50% increase.

Also, this is gonna cost us additional time and resources.

I recommend that you always place a contract

in your master service agreement

and your statement of work

that either states that all changes must be submitted

as an addendum to the contract

or include a prearranged cost for expansion

beyond the initial scope.

Both of these measures will help to control scope creep

for occurring during your engagements.

Now remember, while it's easy for the organization

to simply ask for us

to scan another five servers, for example,

they are gonna stop and think about that before they do it

if you're telling them that each additional server

will cost them another $1,000

or whatever the value has been set

inside of that master service agreement or scope of work.

This, again, helps keep scope creep from occurring

and it helps it from becoming excessive

during your engagements.

Anytime there is scope creep,

document it as a change order to the statement of work.

Make it clear to your client

by stating how long it's gonna take,

the resources necessary,

and the additional cost

to make that change to the scope occur.

In addition to the client organization's requirements,

there's also gonna be some restrictions

that are placed upon you

based on the location of the client organization,

the location of the penetration tester,

or the location of the third-party hosted services

that may be in the scope of an engagement.

Remember, each country, state, city and town

has their own regulations and laws

that could affect your penetration test.

Now we're not gonna cover every law in this lesson,

but instead, you need to be aware of the fact

that there are restrictions out there

based on the different locations involved

in a given penetration test.

For example, if you're conducting

a penetration test in Europe,

you need to be aware of the GDPR regulations

and your requirement to adhere

to proper data handling techniques

for any data you obtain during the testing

because it could contain

privileged personally identifiable information

on that organization's customers or users.

There are some countries that actually view minor actions

like port scanning and vulnerability scanning

as a form of illegal hacking.

Again, before you start an engagement,

it's always best to consult with your lawyer

especially before you accept your contract

to ensure that you can legally perform

all the services that you're offering

based on the countries and the locations

that are gonna be involved in that engagement.

Finally, it's important to understand

that even some of our penetration testing tools

have restrictions placed upon them by different regulations.

The best example of this is the export restrictions

placed upon many of our tools

due to the United States Export Administration Regulations

known as the EAR.

There's also another regulation

that was created by 42 participating countries

that implements export restrictions on technologies

that they consider dual use.

This is known as the Wassenaar Arrangement.

Now the United States

is actually one of those 42 participating countries as well.

This arrangement essentially states that if a technology

can be used by both a regular commercial setting

and also used as a weapon,

then the exportation of that technology

may be outlawed by the US government

or any of these 42 participating countries.

A great example of this is encryption.

Encryption is considered a dual-use technology

and it's covered by the Wassenaar Arrangement.

For a long time,

many proxy could not use strong encryption

like 128-bit AES because of this export restriction.

If you are using a high level of encryption,

you may need to check the restrictions

regarding in which countries you may not use it from.

For example, North Korea, Iran and others

are on an export restriction list

and you can't give them that type of technology.

Another example is Wireshark

which is a powerful open-source protocol analysis tool

that can decrypt many different types

of encryption protocols

like IPSec, Kerberos, SSL and TLS.

In some locations,

it can be illegal to use a cell phone jammer,

a Wi-Fi jammer, or even a lock-picking set

as part of your penetration test.

As you can see,

many of our penetration testing tools

can also be considered surveillance tools or weapons

under this was Wassenaar Arrangement.

And therefore, they're gonna fall

under an export restriction.

So it's important to consider this

when you're dealing with your international clients

because otherwise you could be subject to fines, fees,

or even imprisonment for violating these export controls.

Again, this is a case where consulting your attorney

to ensure you stay out of trouble

is well worth the attorney's consultation fee.