Pre-Engagement Interactions Overview 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 »
13 hours 9 minutes
hello and welcome to another penetration testing, execution Standard discussion. Today we're going to be looking at engagement interactions or pre engagement interactions. And really, this is the overview
discussion where we're going to look at everything within the pre engagement interactions component of the standard.
That way, if there's anything that you want to skip ahead to, or anything that you may want to skip over, you'll have the opportunity to kind of be aware of what the standard is made up of. What will be talking about and where will be supplementing that with maybe some stories or things of that nature to give you a better understanding of how it looks
now. A quick disclaimer. The Pee test videos do cover tools that could be used for system hacking. So we will be going over technical guidelines from time to time as we go through each section, pointing out tools and potential techniques that could be used from the penetration testers standpoint.
So with that in mind, any tools discussed or used during the demonstration should be researched and understood by the user. Please research your laws and regulations regarding the use of such tools in your given area. Now let's go ahead and skip over to our objectives
during this particular discussion. The goal is to provide you with a high level overview of the pre engagement interaction section of the Pee test standard.
So we're gonna go ahead and jump right into our first area.
So the first section that will go over is going to be an introduction to scope. And so the goal here is to look at defining a scope defining what will be tested, defining what will not be tested, how to approach scoping from internal and external customer viewpoints. And then we'll get into some scoping horse stories
so prior to ever doing a scan or prior to writing up a contract and agreeing to a price or anything of that nature.
You have to understand what it is that you'll be testing and what it is that you'll be doing. This is both, from the consumer standpoint, the business understand point as well as the testers standpoint or the manager's standpoint. So if you're not aware of what the scope is in your blindly testing systems,
you could miss out on a lot of things that would both satisfy a requirement or need that you have is a business
or could get you into a lot of trouble as theme manager of that particular test.
Now, looking at metrics, we want to talk about metrics for time estimation. That'll be the next section.
And a lot of times what we run into
is how do we adequately scope and engagement? So I know that folks will, at times, you know, when you haven't had the opportunity to do a lot of the work, Um, or this is kind of your first rodeo in scoping a project.
You know, if you've got some past results that you can go from, that will be something that will talk about how do we do that? Or if you are kind of going in tow the unknown? What d'you at in? And so we'll talk about consultant overhead planning for that unknown. And then we'll talk about about fixed fee
versus an hourly rates kind of the pros and cons of that. And we'll talk about some ethics that are tied into
time estimation and billing.
Now, scope meeting is essentially a section in itself in that you go over the scope of service and what it is that you'll be doing. So there's both a pre contract kind of deliberation versus post contract meeting.
Um, it is always, you know, a recommendation that a non disclosure agreement be put into play. And so we'll talk about how there's look and why those are important.
We're going to talk about a rough order of magnitude which will come back to assisting you in coming up with the overall cost of your particular penetration test.
Or is the business owner how you know an independent contractor or firm may come up with costs,
and then we'll talk about implicit scoping and verification of ownership of assets and things of that nature.
Now we'll have a separate discussion on additional support based on hourly rate, which is a section within the standard. We'll talk about scope, creep on a high level and how that kind of falls into the need to have additional support
hours built in, or a way to capitalize on that. If the customer wants to
avoiding undocumented requests, and so we get into when a client or business owner or any entity, internal or external, wants you to do additional work out. It was not, you know, first defined in the scope. We'll talk about legal ramifications of doing undocumented work.
Um, how we would go about the creation of a statement of work to address that
you know whether or not you do flat fear, hourly rate and then, you know, getting the countersign scope of work updated within that process.
And then we'll get into questionnaires. Now, a lot of times, especially from a business owners aspect, they may not have all of the answers. And in some cases, you know, if you are communicating directly with the owner of the business who has final say on certain things,
it may be difficult to get the information from the business owners perspective they may want to do. The test
as close to black box is possible.
But from our standpoint, we're going to go through necessary questions for, like network penetration, testing, Web application, wireless physical and social engineering type tests, as well as questions that are specific to business unit managers and system administrators.
This is important because if we do not properly define the systems within the scope or we don't ask the right questions,
we may fail to meet expectations from our from the testers perspective or from the business owner perspective. We may fail to get what it is that we're hoping to achieve out of a penetration test, as well as put our tester at risk for litigation or something of that nature. If we did not properly defined scope,
we'll talk more about that with respected third parties as well.
Now scope creep will have its own discussion. We're going to get into the dangers of scope creep. How we identify scope, creep
properly, reacting to it red flags. So when a client is asking us to do certain things that we know, we're not defined or they're trying to kind of politely ask us to do a little extra poking or prodding on a system that we know wasn't something that we were looking at initially
and then some existing customer best practices. And so you know, how would we treat existing customers versus maybe net new customers when the relationship
isn't maybe fully established? Or there's still some some kind of need for trust that we're working through. And so we're gonna talk to those processes in a talk about scope creep in depth
now. While it may seem simple, we will go into specifying start and in dates. And not just that. It will start on January 1 end on January 31st but we'll talk about drop dead dates. Will talk about retesting, timeframes, Post Report.
How do we go about handling extensions? How do we discuss those? How do we build those into contracts and things that nature and the importance of properly handling
starting in dates? To ensure that both the consumer of the test is satisfied? The customer client business partner, whatever the case, may be a satisfied and that the tester and the firm that the tester works for, whether you're the Sox manager, the penetration testing lead that you can meet your goals
and objectives by properly specifying start
and in dates.
All right, so in summary, to part one of our overview, we did an introduction to scope. We looked at metrics for time estimation. We looked at scope meeting, discussed additional support hourly based on hourly rate and the questionnaires. And so these are the first sets of topics that we're going to cover
in the penetration testing, execution standard pre engagement activities and so
get ready for part two. And with that in mind, I want to thank you for your time today. And I look forward to seeing you again, Sin.