All language subtitles for 002 Defining the Scope (OBJ 1.2)

Instructor: Once the basic planning has been conducted,

it's time for us to begin defining the scope

of the upcoming engagement.

Defining the scope starts broadly

and then gets more detailed

as we go throughout the scoping process.

By properly scoping the engagement, everyone can understand

what to expect during the assessment,

what specific attributes will be included,

and which will be excluded.

This ensures a cost effective penetration test as well

because the team will have a clear idea

of what they should be focusing on during the engagement.

To do this,

the engagement's objectives need to first be well understood

by both the client and the penetration tester,

as it's gonna help define the overall scope

of the assessment.

Once the objectives and goals are understood,

then the penetration tester can work

with the client to determine which networks,

cloud services, and applications are gonna be considered

in scope of the engagement.

First, we have the organization's networks to consider.

These days, networks are difficult to define

because of the rise of deperimeterization

and the migration into the cloud.

In the good old days, networks were much easier to define

because most of the organization's resources

sat behind their edge routers and their firewalls.

So you could easily draw a line in the sand and say,

"This is in scope, and this is out of scope."

Unfortunately, the rise of wireless local area networks,

VPN connections, and the migration into the cloud

has really blurred the lines for us as penetration testers.

So it's really important to take the time to discuss upfront

with your client their exact architecture,

if you're gonna be conducting a known environment test.

Or at the very least, you should have some guidelines

about what is and is not gonna be part of the engagement

if you're doing an unknown environment test.

Now, speaking of the migration to the cloud,

you also need to determine

if the company's cloud assets are gonna be considered

in scope for the engagement as well.

After all, just because you've migrated a server

or service into the cloud,

doesn't mean it's automatically well-protected.

Instead, organizations are now asking penetration testers

to test not only their local networks

but also their cloud-based infrastructures and services

to ensure they're in compliance.

Cloud services are usually divide into categories,

like software as a service,

infrastructure as a service, and platform as a service.

Now, under software as a service,

the service provider is gonna provide

the client organization with a complete solution.

This includes the hardware, the operating system,

and the software applications

that are needed for the services to be delivered.

For example, your target organization

might be using Office 365 from Microsoft.

This is a software as a service solution,

and it allows the end users to access their email,

Word documents, and PowerPoint presentations

directly within their web browsers.

Sometimes, though, an organization wants

to build their entire infrastructure in the cloud,

and for this, they're gonna use infrastructure as a service.

This allows them to get the hardware, the operating system,

and the backend server software

all from the service provider and make it the benefit

of dynamic allocation of additional resources,

known as elasticity, whenever they need without the headache

of a long term commitment or buying all that hardware

and operating systems upfront.

For example, an organization might contract

for a new cloud-based web server

toast their company's website on.

The server might be built and hosted

by the cloud service provider and come pre-installed

with something like Linux and an Apache web server.

Now, their web developers

or programmers can create a custom application

for their customers and run it through this web server

without having to worry

about the underlying operating system at hardware.

The final type of service we have

is known as platform as a service.

Under this model, the third party cloud provider

gives the organization the hardware and software

that's needed for a specific service to operate.

For example, let's say your organization

wants to develop a new app for an iPhone,

but they don't own a Mac OS X system

to be able to compile it.

Well, they might lease a development platform

provided by a third party, and that's gonna allow them

to perform this service for them.

This would be considered a platform as a service model.

Now, in summary, when you think about these models,

remember that infrastructure as a service

provides the organization with everything they need

to run a given server, something like power, space,

cooling, networking, firewalls, physical servers,

and a virtualization layer.

With platform as a service, the operating system

and infrastructure is already added into that list as well

as all the things you got with infrastructure as a service.

This might include things like an Apache web server,

MySQL database, programming languages,

or even some custom-built software to help you make things.

Now, the third layer is software as a service,

and this is a hosted application that's add

to the top of the infrastructure and platform portions.

As you can see, software as a service

is much closer to your end user

than either platform or infrastructure as a service.

Now, if the organization

is using infrastructure as a service,

that means they're also gonna have a lot

of virtual machines that are operating out

in the cloud that you may need to consider

as part of your engagement scope.

On the other hand, if they're using something

like platform as a service, then the target organization

may have created their own web applications

and associate application programming interfaces,

known as an API, and those might be in scope.

Now, an application programming interface

is a type of software intermediary

that allows two applications to talk to each other.

For example, every time you use an app like Facebook,

send an instant message,

or check the weather on your smartphone,

you're actually using an API behind the scenes.

For this reason, it's really important to identify any web

or mobile applications that may become part

of the scope of your engagement.

If your team is asked to conduct a penetration test

against the company's web or mobile application,

you should clarify

and define some basic guidelines upfront.

For example, can you ask the client

to provide a discrete volume

of the total number of web pages

that you're gonna be expected to test or analyze?

Or maybe they're gonna give you a percentage.

Let's say you were hired by Facebook.

You would be unable to test their entire website

for every possible page combination, so instead,

they may state that you need to conduct an assessment

on at least 1% of their total pages.

If you're conducting application testing,

you should also ask for the various roles

that are used by that application

and then ask what permission levels

are assigned to each role.

This will allow you to run the assessment

against the application as a regular end user,

a privileged user, or an administrative, or root user

to test the effects of what each type

of user can do against that given application.

Personally, I find it best to gather information

on which applications are gonna be tested,

what platforms are gonna be used on,

and what specific scenarios

the organization is worried about

when you're defining the scope for the engagement.

For example, do they want us to test their web app,

their Android app, or their iPhone app,

or all three of those?

This is important to understand

because doing all three will drastically increase

the scope of the assessment.

The bottom line is that you need to properly identify

what is hosted locally on the organization's network,

what's being hosted in the cloud, and what's being hosted

or processed by a web or mobile application.

Once you identify that, you can then work

on defining a target list with that client

to clearly dictate what assets are in scope

and which ones are out of scope

for your particular engagement.

(light upbeat music)