Dealing With Third Parties

00:00

Hello and welcome to another penetration. Testing execution Standard discussion. Today we're going to be looking at dealing with third parties within the pre engagement interaction section of the Pee test standard. Now, quick disclaimer Pee Test videos do cover tools that could be used for system hacking.

00:20

Any tools discussed or used during the demonstrations should be researched and understood by the user.

00:25

Please researcher balls and regulations regarding the use of such tools. Again, while we're having fun and learning or doing our day to day tasks, we don't want to get into any trouble with the law. So with that, let's jump into our objectives.

00:40

So today we're going to be looking at what 1/3 party is by definition. And so by the end of this, you should understand what 1/3 party is. We're gonna just discuss some best practices when working with third parties, such as getting acknowledgement, establishing clear lines of communication, providing a clear description of what you're doing. So

00:59

these will essentially be the best practice areas, but we're going to discuss them further.

01:03

We're going to look at some high level notification requirements by providers and what some best practices would be for handling these particular types of providers. And then we'll look at some key considerations for other countries and things that you should be concerned with or be aware of when you're testing a an environment that may span multiple regions.

01:23

So let's jump into what is 1/3 party. So by its definition, 1/3 party is a group or person besides the two primary parties involved in a situation. Now this does stem out to its disputes and things that nature as well.

01:38

But when looking at 1/3 party, if myself and a customer are discussing a penetration test

01:42

and there's another party outside of that customers or clients ability to give authorization, who is responsible for a system? That person is the third party.

01:53

But some examples of third parties could be marketing agencies and attorney Internet service providers. Cloud service providers, core processor on accounting firm off the supply provider, and the list goes on. So if anyone

02:07

for any reason has a system or software on your premise

02:10

as a business, and that software or system is managed by someone other than your employees, that would be considered and should be considered 1/3 party. I have seen cases as well where email addresses are set up for third parties like attorneys or accounting firms.

02:28

But those email addresses are associated with the business that you would be testing.

02:32

But you technically wouldn't want to include those email addresses in, Let's say, social engineering or fishing attempts. Because you're technically testing parties that are not a part of the primary discussion or you on the customer.

02:46

It's always consider that web of connective ity between a client and their trusted partners. When you're getting ready to do a test and when you're scoping the test now, what are some best practices when we're talking about third parties? Now? We mentioned these in the overview

03:04

our in the objective area of our discussion.

03:07

But giving an acknowledgement is key from 1/3 party. So however, they want you to do that. Whether there's an email address on their site, there's a form that needs to be filled out. There's a particular party that you need to discuss. If the third party is just another business owner, like an accounting firm or someone who may have a system on premise,

03:27

you should responsibly get acknowledgement from that party is far is what the requirements are for testing and what they feel. The level of scrutiny should be against their systems, if any, and then, like you would with your client. We need to discuss an established, clear lines of communications. And so this involves the Who

03:46

do I talk to? If something comes up with this third party system,

03:50

what do I need to report? Okay,

03:53

and how does that need to be formatted? And how does that need to look? So who, what and how is going to be a big part of that communication strategy? And then, when getting into testing clearly defined what you intend to do,

04:06

is it vulnerability scanning against the application? Is it port scanning? Is it going to be Web application testing? Fuzzing What exactly are you planning to do against

04:16

the third parties application? And you need to clearly define that to ensure that there is one no ill will, no hard feelings now trying to work one over on somebody that they may feel is being done,

04:29

but also to ensure that you were protected adequately and that you don't put yourself or your firm at any, uh, any links of risk, or, you know, something that could come up in that as being your fault, potentially.

04:42

So let's get into some notification examples here. So the first that we're going to look at is what we should be doing with cloud service providers. And so in this case, this first example is provided by A W S

04:55

and it is available on their website. So just looking through it, they're very open and allowing customers to do security assessments or pin testing against their AWS infrastructure without prior approval for eight service is listed in the section under permitted service is all right, so right off the bat

05:14

they're open.

05:15

But there's a limited number of service is that they're allowed or that you're allowed to test against. And so there would be a permitted section or permitted service's section that they provide where you can then reference the service. Is that Aaron that so it says here to ensure these activities aligned with the policy set out below

05:32

note, customers were not permitted to conduct any security assessments on the infrastructure

05:38

of AWS or the service's themselves. So then they also provide contact information here, a link for contacting them immediately. If, during the course of the assessment, you discover security issue within the AWS service's,

05:54

so there's kind of, ah, goodwill gesture there. Hey, look, if you are testing and something happens to come up,

06:00

please notify us immediately. And you know, I can't say that that would protect you because you violated the terms of their penetration testing policy. But if you do something in good faith, maybe that will give you some some hopes of protection there

06:13

now. It also indicates that if they receive an abuse report for the activities related to security testing, they afford it to you when responding, please provide the root cause of the reported activity in details of what you've done through. To prevent the issue from re occurring, you can learn more here. Resellers of AWS Service's are responsible

06:32

for their customers security testing activities. And so if I'm a reseller,

06:38

my customer takes on my service is, and then my customer gets testing done against the environment that I'm not aware off. I'm responsible for probably not community keeping that on an accurate and timely manner.

06:49

Now Microsoft also has slews of documentation on penetration, testing and how that should be conducted. It also indicates here that

07:01

there are some prohibited testing activities, meaning things that you should not do within the environment. And so they want to allow their customers to test the environment.

07:12

But they place some restrictions on that. And so this is just a snippet of the list but gaining access to data that is not wholly your own. Scanning our testing assets belonging to any other cloud customers performing any kind of denial of service testing, performing network intensive, fuzzing

07:30

against assets except

07:32

your azure virtual machine. And so, as we can see here, both of these parties

07:40

are open to the idea of testing with restrictions, and those restrictions typically start to come up when the lines are blurred between what is your equipment? What is your data? What is other parties? Data Again, you can't speak for and be responsible for

07:58

other customers information you can only be responsible for and test against what is the clients and what they have authorisation to allow you to test against. And so

08:07

if you blindly provided

08:09

testing against an AWS service and it was not one of the eight service is that was allowed. If you blindly test against a Microsoft environment and you do don't olive service testing,

08:20

then you're in violation of these rules of engagement, and you could be subject to issues. So always, always, always take it upon yourself to learn more about the service's and to ensure that you understand

08:31

what's going on with them. Now let's talk a bit about some kind of notification. Best practices for iess piece. So it is always best to review the Iast peas, terms and conditions

08:45

with the customer. So as the customer Hey, when you received your service is from the eyes p. Did they provide you any terms and conditions? Was their documentation that was provided?

08:54

And it's good to note

08:56

that there are scenarios where nice p may shun and block certain traffic. I've even seen where, um, your business I P address could be blacklisted entirely in that process, and then you have to go through a lengthy scenario where you communicate with the I S P. You've gotta provide documentation.

09:16

So it would be in the best interest of both yourself and the client to understand what traffic against their network or out of their network could be seen as malicious and block

09:26

as well as with your own eyes. P If you are a service provider, if you provide penetration, testing security testing service is and you do so you know from your business I p address.

09:37

It would be good to understand what you should provide to the ice p to help them understand the nature of your business, what they could see as far as traffic from your i p.

09:46

So that they don't and, you know, brought block you with the intention of stopping malicious activity when in fact you were just doing your day to day business and you're trying to help other people. Now if the ice p also it's good to know, provides Web hosting,

09:58

then clear communication needs to be provided with all concerned parties with respect to the I S. P

10:05

and the customer prior to engaging. So any concerns that the I S P may have or that the customer may have in this engagement needs to be addressed prior to testing. If there's any murkiness, any gray area, anything that is left unsaid,

10:22

then it's best to ensure that that is either addressed or left out of the scope of testing.

10:28

Now, when we get into M S, P's and MSs peas, these air typically third party providers of manage service's or manage security Service's they may manage hardware. They may manage firewalls any number of pieces of equipment they could least networking equipment. And so

10:46

who me

10:48

in scope service's or equipment?

10:50

Then the providers should be notified. They should be aware of the testing. Now if the MSs Pierre MSP will not be notified

11:00

full response testing purposes. So we want to know how quickly they may notice an attack and respond to it. Ownership of the device being tested should be questioned by you. The tester, meaning

11:11

if the equipment is least and is technically the property of the M S p r M S S P. You have a responsibility to notify if you do not, and you test equipment. Software service is that air owned holy by the MSP Ramesses P. That means that the customer has no ownership

11:31

in that device or service.

11:33

Then you could put yourself at risk for issues. So if the device is explicitly owned by the provider permission should be sought. And if the customer insists that they are the owner of the service or equipment and simply the M S P R M S S P is providing

11:50

kind of like a labor service or a help desk type service or they're providing analysis against software that the customer client owns,

11:58

then you should seek documentation. Seek proof

12:03

that is the case you don't want to make. The mistake of testing against service is that are owned by 1/3 party who can then seek retribution or some type of action against you for the testing that could cause damage or harm to their organization.

12:18

Now, as always, what would any discussion be on third parties if we didn't have some considerations for other countries? So the biggest thing that we want to remember to do here is to always validate the location of off premise devices or servers.

12:33

Now I have seen instances where a customer or client swears up and down that a server is located in a U. S. Based facility, and the service provider has told us that our equipment, our physical equipment that we owned is housed here in the United States.

12:48

but there may be some backup redundancy. There may be some copies of the server that are made for back up purposes and their contract. Whatever the case may be, there's any of those things, and it's replicated Thio, a site that is out of state or out of country,

13:05

and it's still accessible. But for all intents and purposes, the primary data sets are housed in a U. S. Based facility. That could be a problem, because now we are essentially testing a server that is in a different country.

13:18

And so you have a responsibility to review the laws for that country before beginning any test.

13:24

Now you can involve legal counsel if need be, but I always recommend that you involved legal counsel when there are questions of laws and regulations for other countries, especially if you're not an expert in the legal system,

13:39

never assume all right, this is critical as well. Never assume that a firm will take responsibility for any laws violated by the tester. Now this is important for my managers for sought managers. For security managers. Team leads when you scope work

13:58

and you assign a person to do the work

14:01

you are putting that person's livelihood and well being at risk.

14:05

If you do not do your due diligence to understand the laws and regulations in that area, and for my tester's that air reviewing this information, you are ultimately responsible for your actions. And so, if you are a penetration tester that's becoming familiar with the pee test standard or you're looking to consult

14:26

more on your own,

14:26

you have a responsibility to question whether or not the laws and regulations of the particular country where the system's reside have been evaluated and you have been properly informed on the do's and don'ts of testing their systems. If you cannot get straightforward answers,

14:45

then you should not assume that the client you're working with will take responsibility for your actions. And you should assume that you will ultimately be the person that is responsible for answering for your actions. And so if you are not comfortable with any component of a test that involves another country or 1/3 party,

15:03

always take the time to stop and question what it is that you're doing to ensure that you stay out of trouble.

15:11

Now, with that in mind, let's go ahead and do a quick check on learning.

15:16

True or false, it is okay

15:18

to keep a service provider in the dark. So you contest how they respond to attacks when they don't explicitly own the equipment being tested.

15:28

It's a true of false.

15:31

All right, pause the video if you need to take some additional time to think this through. So it is okay to test

15:39

a service providers response time, you can keep them in the dark win.

15:45

They don't explicitly only equipment being tested if this component was not here.

15:50

Okay.

15:50

And it's okay to keep the service provider in the dark so you can see how they respond to two attacks that would be false

15:56

when we add this component

15:58

indicating that they don't explicitly only equipment being tested. So this piece here makes the difference and it makes the overall statement true. If any component of that were changed where the service provider does explicitly own a service or piece of equipment, you have a responsibility to ensure that the service provider is both informed

16:18

and approves of the testing and any limitations choir to testing being conducted. So always keep that in mind. Prior to doing any testing where you're looking at response time.

16:30

So with that, let's do a quick summary of everything we talked about here today. So we discussed what 1/3 party is. This is anyone that is not yourself and the client in a discussion. And if the client doesn't have authorization to allow you to test the system, then that is considered 1/3 party. You have to get permission.

16:48

We looked at and discuss some best practices when working with third parties.

16:52

So, as always, get acknowledgement established. Clear lines of communication provide a clear description of what you're doing. Don't try to be sneaky. Don't try to be covert, be transparent and ensure that you're protecting yourself. And then we discussed notification requirements by providers. So we looked at cloud service providers like A W S

17:11

and Microsoft.

17:11

They're open to allowing security testing and give very particular parameters

17:18

In doing so, if you violate those parameters, then you're not within the the, you know area that is approved that could result in some issues. We talked about some best practices for I S P s and ensuring that we, you know, figure out whether or not something is hosted by the I S. P, and we determine based on their terms and conditions what would be allowed?

17:37

And then we looked at M S, P S and M SS peas

17:41

again looking at what is explicitly owned by the third party and ensuring that we stay within the parameters of what is owned by the client and otherwise getting permission

17:51

from the third party when it is not. And then we discuss in considerations for other countries remembering that you, as the tester, are responsible for your actions. No one else is going to come to your rescue and explaining why you did what you did. If you were ever unclear on something or you ever questioned something, stop

18:10

asked, get clarification and ensure that you're protected.