Scoping Meeting Part 1
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
Hello and welcome to another penetration testing execution Standard discussion.
Today we're going to be looking at the section pertaining to the scoping meaning in the pre engagement interactions section. So before we get started, let's do a quick disclaimer.
So the pee test videos do cover tools that could be used for system hacking. Any tools discussed or used during the demonstration should be researched or understood by the user. Please research your laws and regulations regarding the use of such tools in your given area.
While we wanna have fun and learn in the same vein, we also want to ensure that we stay out of trouble with the law.
So let's go ahead and look at our objectives for this particular discussion.
So today we want to understand the components of a non disclosure agreement, so we're not going to get into deep details. But we'll talk about non disclosure agreements at a high level. We want to understand the intention of the scoping meeting.
We're gonna talk about what that will entail, as well as topics on avoiding tangents, dealing with suspicion, avoided assumptions, and then we will round everything out with a quick discussion on understanding regional considerations. So with that, let's go ahead and step into our non disclosure agreement area.
So a non disclosure agreement is essentially a contract to which the parties agreed to not disclose information covered by the agreement. And so that is critical when we're talking about proprietary information or sensitive information, etcetera.
And so typically these agreements will protect or work to protect confidential information.
And it is usually pertaining to information that may be kind of secret sauce. And so, you know, the seasons that go into, like here we've got, you know, Kentucky Fried Chicken they may not want to disclose, or if they're going to disclose their secret ingredients. They may not want you to be aware of that.
It may be software that's proprietary to a testing firm or something of that nature that you'll be reviewing.
And so sections that you'll typically find in a non disclosure agreement are the definitions and exclusions of confidential information. So what is considered in this case to be secret sauce
obligations for all parties that are involved, so people's or parties
and then Tom periods Now, unless you are on attorney or ah, counselor with respect to the law. I would always suggest that you seek the advice of counsel when signing or creating such documents. And the reason for that is
these sections, while typical, are really up to negotiation by both parties. And so, you know, if you do business with an organization that says you cannot discuss anything involving our business for your lifetime,
well, I mean, that may be acceptable depending on the information or what it is that you're doing. And so it always makes sense to have any legally binding document reviewed by counsel to ensure that it's both in the interest of the party that you're serving
is well as yourself. And it doesn't put you at any, you know, kind of undue risk. You always want to make sure that the risk isn't isn't something that you're, you know, maybe not willing to stomach for that particular engagement.
let's go ahead and jump into that. Once we get through the non disclosure agreement, we want to start looking at our scoping meeting. And so there are really two parts to the scoping meaning Okay, so in the 1st 1 what we're going to do is determine what it is that the client needs. And so a big part of that
is what is it that you're trying to achieve? What is it that you need, and so that could then determine what it is that we're going to do with respect to testing. So are we doing physical testing? Is that network centric? Is it Web application centric? Is it wireless centric
that all will need to be dictated in that kind of first meeting? And really, this doesn't need to be,
you know, a two hour long affair.
Really, It needs to be done, probably in about 30 minutes. You should be able to walk away with pertinent information and essentially come up with a rough order of magnitude. And the goal of that rough order of magnitude
is essentially that you're going thio attempt to come up with what it is that the work will look like and what it is that you'll be doing.
And there may be, in this case, some initial assumptions that are made. But
you know, nothing is going to be definitive is of yet you're trying to come up essentially in this first meeting with an idea of what it is that you know will be achieved and what kind of work it is that you'll be doing
now. Once you step away with then information, you'll eventually come back for part two of the meeting. So in this particular meeting, you should have already established the rough order of magnitude, and you should kind of understand what it is that you're doing. The goal of the second meeting is to validate assumptions.
And so this validation of assumptions is where we're going to explicitly understand what is within the scope, what is within the range. What is it that we're testing
exactly and verifying that the customer owns all targets within the environment. And so these are just a few examples of some particular targets,
but the sky is the limit they could have. Custom Web applications could be a mail server. It could be any number of things within this scope of service or this testing range that the Kleiner customer may want you to review. So your job as the tester
is to ensure that we walk away from this meeting with an exact understanding of what is going to be in the scope and then We will refine
that rough order of magnitude into a scope that will then you know better justify what the cost will be. Well, better align with goals and things of that nature, which we'll talk about later,
and then it'll allow you to better designate the actual rules of engagement on stuff like that. But until you come up with the exact systems that will be tested and all of that is explicitly defined, it would be dangerous to make any assumptions
and to move forward with any testing prior to doing those things.
Now there's some key areas that we want to talk about when we're looking at doing a scoping meeting, and the first of those is avoiding tangents. Now, a lot of times
what you'll run into. His folks do want t kind of contribute and have some small talk. But tangents, air really conversations or topics that do not contribute to the meeting goals, which
it's okay to ask how someone's family is doing. It's okay to, you know, engage in a little small talk between kind of getting everything done. But the line share of the meeting should not be, you know, laden with small talk, and so by its its actual definition,
a tangent is a different line of thought or action. So if you start talking about Web applications in the 1st 5 minutes of the meeting, and the goal is to understand what what the Web application looks like and what it is that you'll be testing,
and then the customer client starts to veer away from that and talk about topics related to the network. But maybe not so much the Web application. Well, if the goal of the conversation again, we're looking at the goal. If the goal of the meeting was to discuss the whim application
and you know what it is that they're hoping to achieve through the service you're providing, and then they start to talk about their network and the network really doesn't have any tie into the Web application. While it may be relevant to a degree, you know, to have knowledge about the network or what it is that the Web application sits on,
if it's not going to contribute to the scope, if it's not contributing to the overall goal being met,
then it is considered a tangent. So ways to avoid This
is to have clear objectives for the meaning. So when you go into the meeting, the first thing that you want to do is define the objective of the meeting, so that can be done and supported by our second bullet, which is Do you have an agenda
that you provide prior to the meeting? And you reiterate that agenda when the meeting starts as well as concludes? And so these 1st 2 things were critical.
You really can't have an agenda for the scope meeting if you don't have a clear objectives in mind for the meeting. So by coming up with those objectives, you define an agenda for the meeting and provide that well ahead of time, and then you you as the tester or the person that is managing the team
should facilitate the meeting and lead any discussions throughout the meeting.
If you allow other parties to lead the meeting or run the meeting, you could very quickly find yourself on a tangent or talking about topics that are not contributing to the overall goal of the meeting. So the best way to avoid tangents within a meeting is to essentially
have those three things laid out prior to the meeting and then stick to the measure going through it
again. Small talk isn't a bad thing,
but it can't run the meeting. It can't be the only thing you do.
All right, everybody. So today we finished out the first part of our scoping meeting discussion. So we discussed the components of a non disclosure agreement and the intention of the scoping meeting covering our first objective techniques for avoiding tangents. When we get back into port, to will finish the other components of the intention of the scoping meaning
and 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.
Scoping Meeting Part 2
Additional Support Part 1
Additional Support Part 2
PTES Questionnaires Part 1
PTES Questionnaires Part 2