hello and welcome to another penetration, testing, execution Standard discussion. Today we're going to pick up where we left off in our scoping meaning part two. Now, the objectives that we didn't cover from Part one. We're gonna pick up on here and discuss the intention of the scoping meeting where we talk about dealing with suspicion
and avoiding assumptions, and then we'll round everything out with understanding regional considerations.
So with that, let's go ahead and pick up where we left off.
Now, another area that I've run into a number of times is suspicion, and this comes with customers or clients who do not have
a clear understanding of what it is you're trying to achieve. Or they don't have a clear understanding of what pen testing is. And so they may perceive your questions as a means to get data that allows you to attack their systems during the test. And so the customer assumption maybe, that you should be testing without knowledge that you should treat
their environment as though you're an attacker.
You have no knowledge of the environment. You simply know the name of the company, and you're going to go out and you're gonna hack their systems and get it and try to get into their systems. Well,
even if this is the case, even if this is what the client wants, you have to establish realistic expectations with respect to the type of testing. Even in black box testing, we have a defined parameter in which we worked within. We know what the front end looks like, but not so much the back end. And so
we have to set clear and reasonable expectations. And so your responsibilities
are really these These major points here, give or take, you should explain
that these would be ideal circumstances. And so you don't want to completely shoot down someone who maybe has a false assumption of what the world looks like or what it is that you do. So you tell him, you know, that is idea. We would love to be able to do testing in a manner that completely simulates
at the actual. We have no knowledge of the organization, and we go in guns blazing and try to figure out what's going on.
But with the environment being what it is today, we also have to convey what those legal ramifications are for us. If we miss identify a system. If we're off by an octet on an I P address, it's the accidentally scan government facilities instead of theirs.
There are some huge legal ramifications on our part for doing so, and to
what it is that we'll be testing by not scoping responsibly what it is that we'll be doing.
You could put yourself at risk because let's just say that you do go in black box style and you don't scope anything you have. No, I P's, you have no idea.
So you get in there,
you start doing the test, you do get into their systems. But then the client says, Well, wait a minute. That system that's on our network belongs to 1/3 party that we have a confidential agreement with, and you shouldn't have gotten into that. And by compromising that, you put our business at risk and you put them at risk. And you know, suddenly you're up
in a mess of litigation and potential legal action that you now have to defend yourself against with a very vague,
an unrefined scope. So it's in your best interest to deal with suspicions in a manner that kind of reiterates your responsibilities as a tester and puts them at ease and that you're trying to do what's best for them while protecting them and protecting yourself as well.
Now the next thing that is high, high, high on the priority list with any scoping meeting is to avoid assumptions. And so we make initial assumptions when we look at a rough order of magnitude. But after we do that, we want to make sure that we don't make any moving forward, and we validate everything. Assumptions air typically
for the professional, right, so you're usually the one that has to bear the burden of correcting any mistakes or correcting any assumptions. You're usually the one that walks away trying to do the work under false pretenses, and then you have to come back and clean up the mess. So assumptions air typically beneficial for clients
and that they have some plausible deniability and that you made an assumption.
You, on the other hand, have the responsibility of them cleaning up the mess. And so the best thing that you can do
is during the meeting you want to listen with the intention of understanding, not just responding, So pay attention to keywords. Pay attention to what it is your customer recline is trying to convey to you and ensure that you ask questions.
Ask is many questions. As you have to ask, until both parties are crystal clear
on what it is that is testing within the scope. It's being tested. Be very clear on what it is that you're trying to achieve. This is going to be huge and avoiding assumptions. And don't rush through a topic. So if need be, schedule another meeting until matters are clarified.
Just because you have 30 minutes on the books to discuss
what it is you're trying to achieve, and maybe your client or customer is starting to get a little frazzled, because it, you know, should be rather clear. You're the professional. You know what's best. What what is it that they're going to provide
until you feel warm and fuzzy until you feel a sense of calm and understanding for the matter, Schedule has many meanings. You need to, and my favorite analogy here, my favorite saying it comes from carpentry, but its measure twice and cut once. This essentially means that if you measure twice and you're
for sure about the link, you're for sure about the angle. You clearly understand
that what it is you're looking at meets expectation, is going to fulfill a need. And then you make that cut.
You can do so with confidence. What I found time and time again, just sticking with the carpentry references. When I rush into something and I don't really take the time to measure, I really don't take the time to cut appropriately and cleanly. I end up with something that doesn't meet my expectations. That falls short, that maybe I run out of material
applied across the board measure twice. Cut once. Don't make any assumptions
when you're working with both your livelihood and a client's livelihood.
So with that in mind, let's do a quick check on learning. So take a moment to read the questions and review the answers, and then we're going to go through both of those and provide explanation.
All right, well, if you need more time, go ahead and pause the video. So the initial question What document is best to have signed prior to any in depth meetings on scope.
Well, a service agreement may cover some of the areas that would protect both entities, but it is typically not the case when it comes to just scoping or discussing business practices. Terms and conditions also may have reference to this particular document, but it is not. The document that adds that layer of protection
does not usually contain this document in detail. And so the non disclosure agreement is the confidentiality agreement or the agreement that will protect the information provided between yourself and the customer. Wind scoping.
So what item below is a part of keeping a scope meeting on track?
Well, I can tell you that keep the agenda loose is definitely not the way that we're going to take care of that. Giving the client or customer full control of the meeting typically does not result into the discussions or the things that you need to have done in order to scope appropriately. And so
the one of the main areas here that we want to take care of that is applicable in this case is to set
clear objectives. If we go into a meeting with the understanding of what it is we're trying to achieve. We have an agenda and we facilitate and manage that meeting against the agenda.
Then we can keep the scoping meeting on track
now. With that, let's go ahead and step over to regional considerations. Now
we're not going to get into European laws or regional laws and things of that nature. But it is important to understand that when you're looking at an engagement, especially with a client or customer that has multi tenanted systems that spanned different areas,
that can change the rules of engagement. And so when we talked about assumptions
and, you know, validating assumptions, if we don't take the time to understand where a system spans, especially if it's in the scope, then that could put us into some very hot water. And laws and regulations differ by country. And so the best thing that you conduce when you're unsure and even if you think you're sure
is to seek advice of legal counsel with respect to
the system's being indifferent, geo locations or regions don't take any unnecessary risks for yourself. All right, on opportunity is not worth your freedom and is not worth your livelihood. So
if you have a multinational organization, you would be best suited to seek the advice of legal counsel before taking on any work that spends multiple regions always contact in. Review all third party requirements prior to doing any testing.
Okay, any testing of their environment. So even if the
customer client owns hardware in that like AWS environment, for some reason, if they own hardware, that's with 1/3 party cloud service provider. You still
don't have a permission to test the firewall for that facility because it's owned by the third party. You can't make any assumptions when it comes to testing those systems, and you have to explicitly review their requirements and possibly have those requirements reviewed
my legal counsel. And so with that, I just wanted to provide you with the statistics of 72% of countries have some form of legislation
regarding cyber crimes and laws that are on the books. And so a site that I found that I'd like to start at and review it doesn't have all of the laws that are specifically applicable to just
penetration testing. This is any law regarding computers, their cyber crime, but it's a great place to start. It's laid out by region.
It's the United Nations site, and so I would definitely with any engagement that spans. You know, multiple regions if you're just trying to get a feel at a high level of what kind of laws on the books definitely a great place to start. But again,
always, always, always have the final say of legal counsel before doing any work again, You want to make sure that your contracts are
as airtight as possible, that your scope of work is as airtight as possible, that you don't put yourself in any undue, risky situations.
All right, everybody. So in summary today, we discussed the other half of the intentions of scoping meeting, where we're looking at dealing with suspicions, avoiding assumptions. And then we got into some high level regional considerations. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.