Rules of Engagement Part 2

00:00

hello and welcome to another penetration testing execution. Standard discussion today were in part two of the rules of engagement. So to pick up where we left off will be discussing time of the day for testing, attack reporting, permission to test and legal considerations.

00:18

So with that in mind, let's jump right in

00:22

time of the day testing. This is where certain customers may require that testing be done outside of business hours and in some cases be limited to certain time frames after hours.

00:35

So Tom of Day requirements are something that need to be established with the client or customer

00:42

prior to ever starting the engagement. If there

00:46

peak hours for sales are 11 to 3 in during the day and they cannot experience downtown, and some components of your testing could cause downtown

00:57

that needs to be noted and you need to not test during those hours. If they can experience no downtown from 8 to 5, then you should do no testing from 8 to 5 very, very, very explicit parameters here that the client would provide. I've had clients that have said I only want you testing

01:17

from one in the morning, 1 a.m.

01:19

until

01:21

3 a.m. That's it. You get in that window of time to do testing. So I had to have a tester there

01:27

testing from one in the morning till three in the afternoon at the office.

01:33

And that just is what it is. We have to accommodate their schedules. And you know, the client

01:38

ultimately rules. And when they want that testing done, if we test outside of those parameters,

01:45

then we're not sticking within the rules of engagement or the permission to test memo that opens this up for issues. So keep that in mind

01:53

when you're coming through and in determining the time of day for the testing. If you set a vulnerability skin up to run it one in the morning, and it's only supposed to run from one this ring in the morning and it runs until five.

02:06

That testing has been conducted outside of that time of day requirement, so keep that in mind

02:10

now, attack reporting. This is specific to you as the tester and they as the client reporting your attacks.

02:20

And so this is appropriate, in some cases

02:23

for the Target's organization security team to not know when you are attacking so the responses can be recorded.

02:30

This needs to be discussed with the client at length,

02:34

and the primary point of contact should be aware.

02:38

And I would say that one person on security team, especially the manager of that team, should be made aware, should be made aware of the context of the test while the test is being done.

02:50

And, you know, one would hope that they would, you know, uh, continue to keep that information confidential so that the test integrity isn't invalidated. Now, if there's someone above them

03:01

who's given you permission to do this and they are allowed to accept the risk and they're allowed Thio speak on behalf of that team and make that decision fine, so be it. That will help again with test integrity.

03:15

But, um, you should not, um,

03:19

do so in secret.

03:21

As far as like keeping the point of contact in the dark unless they explicitly tell you to attack, reporting should be evaluated again on a case by case basis. With the clients. Keep back, it may not be appropriate

03:32

to keep them in the dark. In all cases, if you're doing something that's completely open air. There's no need to evaluate the response of the security team. They don't have a security team that makes no sense of that point to keep it a secret. So we tell them when we're testing, they could be aware of that. They could see that coming in on their systems and go yet. We knew that they were attacking today, and we knew it was gonna be at this time.

03:53

Now they may have 1/3 party

03:54

who manages, longs for the environment or has 1/3 party software that tells them when systems were attacked. And so if the client owns the hardware and the underlying systems and they're really just paying for 1/3 party to monitor this,

04:09

then they may not tell that third party, and they may want to see how long it takes for a ticket to be generated or response to be generated. So again,

04:15

case by case scenario on win,

04:18

you would need to inform the client that you're attacking and give them a kind of insight as to what is being done.

04:26

So we're not going to spend a huge amount of time on the permission to test memo. We've touched on many templates on and things that you could use for writing that out again. This memo provides you the permission to test outside of your contract the dates for testing the person's authorizing the test, general parameters of the test with any restrictions.

04:45

Um,

04:46

so again, this is your get out of jail free card.

04:50

So if it's not well laid out, if you're not one of the parties that's allowed to test if the person giving you permission to do the test is not the signature on this memo, and they're not the ones that are authorized to conduct or give you permission to conduct the tests, you need to be very, very cautious. This memo needs to be air tight,

05:10

especially if you're doing physical penetration testing

05:13

air tight, which you can do when you condone it, how you can do it. And if the person that is responsible for that facility ultimately has the ability to call the police on you and have you arrested, they need to be aware that the test is being conducted. They need to approve it, and they need to give you permission to do it. If anything is missing from that memo and you step outside of that,

05:33

you're running the risk of having legal issues. So keep that in mind that permission to test mammal is huge.

05:40

Now, we're gonna touch on legal considerations at a high level here. So it is best to remember that activities common to penetration testing may violate local laws, national laws. Whatever the case may be, check the legality of common tasks based on where the work will be performed and the location of the systems in question.

05:59

I don't care if the office is in,

06:01

uh, New York. If the systems are overseas in Europe, you need to take into consideration the laws for that area. It doesn't matter. Never take

06:12

anything for planet. Never take anything at face value trust, but verify all the time. An example of this would be

06:18

that if you're capturing void calls is a part of the test

06:21

depending on the area, it could be considered wiretapping, which is, you know, a lot of times illegal without specific permissions, and Moritz.

06:29

So you need to make sure that anything that you're going to do does not violate any local or national statutes. Always, always, always do your research. Always, always, always involved. Involved council when there are questions. Now, let's do a quick check on learning

06:45

which of the following is not one of the three concepts in regular status meetings. So we talked about three things.

06:53

Which one of these was not one of those three things?

06:58

All right, so

06:59

the right answers plans. Okay, What plans does the organization have was one of those progress was one of those problems was one of those places was not a component of those those regular status meeting concepts. So

07:16

next question, true or false? Regional laws and local laws are the same with regards to penetration testing.

07:26

So that's the question. Our regional laws

07:28

and local laws the same with regards to penetration testing. Well, the response there is that they are not. You should never consider regional laws and local laws as the same with respect to penetration testing.