Everybody and welcome to the next video.
So in this video we're gonna be going over the first phases of an engagement.
So the first thing you need to do is identify your scope and your goals for the for the actual assessment
or engagement.
Now what is the goal a goal in this case is we want to identify the outcome of the test or engagement.
We also want to know what the sub's goals are.
So for example if we're looking at a segmentation testing maybe we are looking at firewall rules as
well as as well as maybe from the reverse side of it.
So there might be some sub goals inside of the main assessment which is checking network segmentation.
Same thing goes for corporate testing.
Maybe we're just testing the corporate network.
However if we see away from corporate into prod then that can be a sub goal as well.
So we want to identify what we are aiming to look for in this particular test.
Now keep in mind you don't have to write down every goal like pop five machines or anything like that.
You want to be somewhat generic with what you're what you're doing but the goal is that you want to
be able to portray this out to a larger audience.
We need to also keep track if there's any extra services we were asked to test.
So in some cases we might be working on a network segment and they might be OK.
We've got docker containers on this particular network and we want you to go out and test that while
you're while you're there.
If that's the case if it can be done in the amount of time that you have accumulated for then you can
go ahead and add that testing as part of your goals.
Now this is normally one to two sentences in normal situations sometimes this can be a list of items
with one sentence for each sub goal and then one main goal.
It really just entirely depends on the situation and what the reporting style is for the company you
work for or if you're a consultant whatever consulting agency you happen to be consulting for.
Now none of this is hard in stone it's just making sure you have this information identified ahead of
time makes it worthwhile so these are some of the type of goals that we can do.
This is again not an all inclusive list but we've got segmentation testing the single service like a
web application or some customer service an entire network which is not normally the case because it's
just too much to do parameter testing perimeter testing.
Corporate DEV PROD you get the picture.
Any any of these can be goals and each one of these could have sub goals depending on your architecture
and your organization.
Now what is scope scope is the second half of what we're going to be looking at in this video.
So this is the range of the assessment.
So what can we touch.
What can we not touch what's off limits.
What are the restrictions inside of each of those.
So sometimes there might be some issue with being the service being a little flaky and that's something
you need to be noting down now.
This legacy said this can be from anything from a single service to a host to an entire network segment.
But you need to understand what the scope is.
Because if you have a set block of eyepiece that you're allowed to touch or you have one single IP you're
allowed to touch.
If you go hitting off a bunch of different ones you're gonna set off a bunch of alarms.
Things could go down.
It's it's not a good situation you want to make sure you stay within the scope that you define especially
if you are on a consulting position where if you're on a cost you're working as a consultant for a customer.
You do not want to start hitting machines out of scope that's going to be detrimental to the company
you work for or you if you own your own company you don't want to put yourself in a situation where
you take down a service that was outside of the documentation that was signed and agreed upon by both
parties and this works the same way for an internal red team.
You still need to identify what your scope is.
There's less repercussions if you happen to scan another host than if you are a consultant.
However the importance is still the same.
You still want to make sure you keep within the scope that you have defined and everybody has agreed
upon.
Now why is all this important.
It sets a reasonable understanding of the desired outcome.
So what the scope is what the goals are.
So this allows for other teams and executives to quickly assess whether this was successful or not based
on your outcome of the reports that you provide.
And this also allows service owners to see what host will be affected and any restrictions put in place.
So this is a good dead tidbit of information that you're going to want to have just in case any service
owner sees that their names coming up in an assessment of some services that they own.
And then you want to make sure that they are well informed.
So in case they are having a maintenance for example or they're expecting heavier traffic than normal
or maybe there's some issue that they're trying to work out that's sensitive to how much traffic.
And if you push it over the edge you could bring down the service.
So these are just some things that you need to keep in mind.
So you need to make sure you know how to identify the scope which is just as simple as going out and
figuring out with your other team members what you want to attack and what scenario you want to work
with then you identify the goals as well from the scope that you're wanting to test and you can also
do that vice versa.
You can identify.
I want to test Jenkins I want to test this web app over here.
I want to test the VANOC services that are installed and then you can scope it accordingly.
So you can go about it either way in some cases you might want to go to a single network segment and
then see OK I see these services here.
This mainly looks like a web app area.
So we're going to only focus on web apps and that might be your goal.
So take some time understand the difference between the scope and the goal and know how they work together.