Hello and welcome to another penetration testing execution Standard discussion. Today we're getting into Part two of the pre engagement interactions overview just to reiterate the objectives of this particular over Veer, to provide you with a high level overview of the pre engagement interaction sections of the peace test standard.
So with that, let's jump into where we left off.
All right, we'll get into specifying I P rangers and domains. This is very important and it warrants discussion. You know you'll handle some of this in your scoping document and putting that together. But the reason we want to talk about defining targets is because one
a client may want again to be his black box is possible on this. But again, the end goal in mind is to provide risk production. It's to provide them with insight and ways that they could mitigate potential attacks.
And so, being aware of the I P ranges that belong to the client,
the internal network ranges that belonged to the client. Those two things are very important because I may have a shared modem. I may be in an office where the far wall is a shared asset between two organizations. If we have I. D s and I P s in place,
that's important to know from my testing standpoint and that could be monitored or managed by 1/3 party. We've got domain names that would be important to know. You know, we need to know if there's redirection on domains and things of that nature, so that if we start scanning an asset, that's maybe a Web application
and then it does a redirect
to 1/3 party's site
who manages some other back in processes that aren't within my control, is the owner of the asset. Then I can put my tester at risk and, you know, potentially cause issues between myself is a business owner
and the third party that I do business with us. Well, as with the firm that is doing testing so it warrants some discussions and considerations on how we would go about specifying I p ranges
we will discuss dealing with third parties. And so we'll talk about client limitations that the client does not speak for
Amazon that they don't speak for, you know, Microsoft on dhe. That's a good thing as well as your if you're a business owner consuming this content, you have you know, some control with respect to the assets that you own. Even if you have a contract with AWS or a contract with the provider of, like QuickBooks cloud service or something like that,
you still don't own
those systems in their entirety. You're essentially leasing space or leasing service from these parties, and so you can't speak for these parties when it comes to testing.
And so we'll talk about those limitations. We'll talk about cloud service providers and how to approach them. I as peas, MSs peas you know, third party providers of technology for organizations and how you know they should be approached and dressed. And then we'll talk about countries were servers are hosted. So
you know you may be a U. S based business
that's using some type of development software or third party software that maybe hosted in a country where it would be illegal. For me is a citizen to do an in maps can of that system. And so
we have to look at specific examples for this. We're gonna look at some stories where there may have been some miscommunication and some nightmares happened and ensued after that.
Well, look it. Like AWS and Microsoft and their specifics for conducting penetration, testing against assets and what their requirements aren't. So we're going to do a fool thing
on how we properly deal with third parties
now, While it's not done in every engagement, social engineering is definitely something that we could do for organizations is a part of physical penetration testing. Or maybe we do some phone calls, things of that nature. But we have to go through and define acceptable social engineering pre Texas. And so
what is appropriate for a doctor's office may not be appropriate to a separate law firm, which is appropriate for an auto parts dealer may not be appropriate for an H R firm. And so,
while you conduce do each of these tasks baiting, fishing, spear, phishing scare where, etcetera. If we're acting in a manner that where a threat actor and we're trying to mimic that, you know, I've seen e mails where threat actors will
indicate that they've, you know, caught you doing unsavory things on your workstation or, you know, they'll indicate that they're aware that you're doing something illegal,
and this can scare people. This can confuse people. This can cause unrest in the workplace. And so we want to talk about each of these areas and some of the do's and don'ts and how we properly communicate. What would we would be doing in these tasks? Because transparency
is going to be key to getting by in of upper management. If we're doing this for 1/3 party and it's going to keep us out of the hot seat if we're doing this for internal consumers or customers for our organization,
and that we don't send out e mails that contain profanity, and the next thing you know we're in the CEO is office explaining why we were doing something when we thought we had permission to do it. So
we're going to talk about defining social engineering, pre Texas and how to properly document those in the scope of service and ensure that were covered before doing any work of the sort.
Now denial of service testing will be, ah, you know, a short discussion, but it's very important to understand the language associate ID with a kind of business owners or thesent members of senior management and getting them to understand what denial of service testing is
and how that looks
being able to gauge their interest. So if they're not interested in, you know, understanding whether or not we're exposed from a confidentiality or an integrity standpoint, they're more concerned with availability. Then there may be some reasons to do denial of service testing, but
being able to properly inform the client whether it be internal or external, indicating to them in very clear terms. What denial of service testing looks like, Um, and having the environment in which we can do the testing is going to be key. We don't want to do denial of service testing on a live environment,
and I know that may be counterintuitive to some of us. But
if you know, I were working with an organization that made a $1,000,000 a month and they were pure online transactions, and I do denial of service testing against that live environment, and they have an hour of downtime because I crashed from service's and systems.
What did that cost? The organization definitely Maur than the return they would get from the pin test. Now we made you know we may be Able Thio kind of spend that and say, Well, you know, now we were aware we can put in some compensating controls, but you could do that in a properly mirrored testing environment, provide the same benefit
and have the respect of an organization that knows you could have brought
they're live environment down for an hour and cost them thousands and thousands of dollars. And so,
properly handling and communicating denial of service testing is critical in any engagement. Now we will talk about payment terms, and I know that money may not be in the purview of some of you who are consuming the content again. You know, this isn't cut off
as far as you. You know, just being a penetration tester and wanting to better understand the pee test standard.
This is more applicable to, you know, the leads, the folks, that air handling management that have to handle completion of projects. Whether you're the soft manager, the contesting lead, maybe you're a business owner trying to better understand again how the service is heir provided and rendered.
And so we'll discuss each of these areas kind of some pros and cons and things of that nature. Um, each of these areas is a payment methodology. Essentially, that's laid out in the standard. Clearly, defining all costs is something that we're adding to that to discuss.
Um, you know, a lot of times organizations will have a fixed fee,
but it won't include mileage. Or it won't include hotel stays or something like that if the engagement is out of town. And that's not always clearly defined when the engagement is started or when a contract is inked, and so that transparency within the language of a contract is always
going to be beneficial. Because when you don't surprise,
you know your client,
then you know that leads to hopefully ah, long term and happy relationship. So while money is always an uncomfortable subject, it's definitely something that we want to discuss so that we can avoid some pitfalls that organization's run into
Now. Goals are going to be a huge component of any engagement that we do so being able to define the mission what you know, what is a primary goal, what is a secondary goal and looking at business analysis so we'll get into some details there that will ensure
that our customer weather again. That's internal or external party
is well aware of what we're attempting to achieve, that they've helped us to define those goals, that we understand what it is that outcome will be and then wants. That outcome is achieved, and success has been, you know,
achieved in that. In that case, then, you know, we know that everybody will be satisfied, so defining goals will be a big part of our discussions here.
We're going to look at establishing lines of communication, and so
it is never fun feeling as a business owner to engage a party to do work.
That party gets you to sign a contract. Maybe you pay half up front, they disappear for 30 days, and then they deliver the work. And that's the end of the engagement. You didn't hear from him in between. You didn't know it was going on. You weren't sure of how things were progressing. You weren't sure if they found anything. You know it's better from an engagement standpoint
to have these clear lines of communication so that if something comes up like an incident, if there is an emergency that comes up, if there's a certain way that the client wants you to communicate feedback and data to them during the process
that should be documented and laid out on a per engagement basis. No one likes to be surprised. And so
if you find that there is a critical issue during the test, or that there could be indicators of compromise, you know, kind of pre existing on the system prior tow your engagement.
Knowing how to bring that to the client's attention in a manner that's going to meet their internal security policy requirements as well as you know, keep you in their good graces is definitely
worth discussing. And so we'll go into each of these areas will give you some examples of how each of these things look with respect to the processes and definitions.
And by the end of that particular discussion, any engagement you do moving fortune should follow some of those best practices if they're not already
now, rules of engagement are extremely, extremely, extremely important. If I have a client between noon and three every day, that gets thousands and thousands of dollars worth of business, because maybe it's a lunch, you know, crowd or something like that. Maybe there are large multi chain organization, whatever the case may be,
and they cannot afford to be down
Then we need to properly identify you know, that time of day to test and when we don't want to test and when we do. I've had clients that tell me that they can only endure testing between 12 a.m. and 3 a.m. Well,
that is the parameters in which we have to work and we have to do the testing. We want to be, you know, able to accommodate their needs and ensure that they're going to be satisfied with the results and that we don't do any harm to the organization. And so we'll get into rules of engagement. Will talk timeline,
how to properly define everything between the start in the end, a and again
start and in date is a discussion that will have on properly communicating those things. The rules of engagement Tomlin will be everything in between that so that that will be defined. Either do gan charter work, breakdown, structure, things of that nature. We're going to talk locations,
clarification and validation. We're going to look at how we handle encounters with illegal data, which hopefully we don't have happened to us often evidence handling legal considerations. And it's likely,
you know, that we will break the rules of engagement discussion up but
indefinitely going to hit all of these key areas within that rules of engagement section.
And then the last area that we're going to discuss is capabilities and technology in place. And so as a tester, we definitely want to gauge, um,
whether or not there are vulnerabilities in place or risks in place that could result in the compromise of systems.
But it's also important to understand where the organization is at with respect to responding to these various areas. And so we'll talk about benchmark testing. We'll talk about some some ways that we can do that. Some tools that could be of benefit to businesses is well, on the other end of that
again, you know, the discussions were having here are for the benefit of both business owners and leaders as well as sock managers and pin test leads things of that nature. And so we want to look at both sides of the coin. Why would she be asking for these types of benchmark tests during the penetration test.
And while that's important to the overall well being of the organization and its ability to respond to a threat,
all right, everybody. So in summary of part two of our Pee test pre engagement interactions overview will be reviewing scope creep specifying starting in dates. I p ranges in domains dealing with third parties, defining acceptable social engineering pretext, denial of service testing, payment terms,
goals, establishing lines of communication, rules of engagement
and capabilities and technology in place. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.