Additional Support Part 2

00:00

Hello and welcome to another Penetration, testing, execution Standard discussion. Today we're going to get into additional support part two. And with that, we're going to cover the objectives that we did not cover in part one. So we're going to get into understanding permission to test memo and how to handle requests. So with that,

00:19

let's go ahead and jump into where we left off.

00:21

Next thing that we're looking at here is an excerpt from a permission to test memo. There are many, many, many, many, many, many, many examples of this out there. So let's walk through the language of this particular one. So there was some language prior to this first section here,

00:40

and essentially

00:42

it goes through the purpose of the memo. And so it says that it grants authorization to specific

00:48

members of the information security team. And so this is our information security team. So this is an internal memo, Remember?

00:57

Even if you're a member of the security team and your day to day job is not penetration testing, you should always seek to get permission to do testing on the organization. There should be some type of validating documentation or contract language that provides you the permission to test.

01:15

And in this case, they specify vulnerability, assessments and penetration testing against

01:19

this organization's assets. So

01:23

this is a narrative essentially, that's being provided to give context to the testing. And so, to that end, regarding the language above now again, not legal advice here, but just interpreting the document. The undersigned.

01:38

But tests to the following

01:41

first section

01:42

name of Tester, name of tester and name of tester have permission to scan the organization's computer environment equipment to find vulnerabilities. The permission is granted

01:53

from the given dates, so that's a lot to take in in the first paragraph. But let's say that you've got 20 members on the security team

02:02

and one of these three

02:07

is gone and they back fill that person with a different individual. Well, they never update the permission to test memo

02:16

that person could be at risk, and so specific individuals were named in this, and they're the only ones from the given dates

02:25

that are allowed to do the testing. So if it is before the given date or it is a day after the given date, that authorization is now rescinded. There should be no further testing outside of the period provided by the very specific individuals named in this document. And then, too,

02:44

we have the approval for

02:46

and they are indicating that they have the authority

02:50

for testing against the information technology assets of the organization.

02:54

Now

02:57

I have seen instances

03:00

where the person that manages the systems may not be the owner of the systems, So the C i o may not have permission to grant authorization for testing against a financial database. They may not have permission to grant testing against H R databases,

03:17

so you need to ensure

03:20

that win permission is given by the approve er that that approve ER is in fact the owner and authorized

03:28

party to allow you to test that system. Because if something goes wrong,

03:32

this individual may not be the one that was able to grant you final say, Now their name is on. The document is giving you permission.

03:40

But the other thing that we want to look at is a section that we really don't lay out,

03:46

and that's additional permissions or restrictions. So

03:52

in these documents, it never hurts to have a bullet list of specific systems that this person is giving you authorization to test. It should be in the scope as to what is there, but it never hurts to have this memo in a drawer in digital copy with digital signature

04:10

giving you permission countersigned and signed by the original party

04:15

to test those systems. The only thing that's going to do for you is that if something comes up and there is an issue, this person, the person in line to here, is going to have to explain initially why they gave you permission to test systems that they did not have the authority

04:32

to test that they did not have the ultimate say so in their health and well being.

04:36

So this is just a example. There are many other templates out there, and as always, I do advise that if you're ever uncomfortable with a document, if you need to have something interpreted, if you don't feel that it's correct,

04:49

involved legal counsel again. This is not legal advice. This is just one of many examples of a document that's that's considered a no applicable test memo. Um,

05:01

and again, it's always sensible toe have such a document in place. Now let's go through some handling steps or some. Tepes accepts that we can take the handle requests outside of the scope. So in this case, first and foremost, if you are not

05:21

the project manager,

05:23

if you are the individual who is conducting the work, you're not the consultant that owns the firm. You're not. You know, you are just the individual that's conducting the test against the scope of service you have nothing. Outside of that is faras project management or authority. In this process,

05:40

you need to see feedback.

05:42

Don't make any decisions to do any work,

05:46

however menial it may seem

05:48

outside of the scope of service, unless you seek feedback in approval from your supervisor or manager. Now, if you are the project manager,

05:58

the first thing you need to do is validate the contract language on handling requests

06:02

are there and that you know, rates

06:06

that apply. So that's the first thing you want to do is go back. Check the contract, see if such language was provided. See if such weight rates were provided and you know from that point,

06:18

validate that the client accepts those rates.

06:21

Folks, individuals have

06:25

a very hard time remembering language that is specific to monies that were not included in an original estimate.

06:33

Again,

06:34

it is in part the client's responsibility to understand those rates and to know that they exist.

06:42

But people have a very strong tendency to forget. And when the bill comes due, they tend to be very, very good at

06:48

feigning. Ah, lack of acknowledgment that that was not explicitly provided or that it was snuck in on him. So always provide kind of validation. Hey, per our scope of service in the contract language, these rates, you know, would cover the work that you're requesting. And did you accept these rates?

07:08

Yes, I do. Okay. Good. Let me get an updated scope of work together. You may, at that point in area for here, get some pushback words like, Can't you just do the work? I accept the rates. No, no, no. We need to have a thorough documentation

07:24

that updates the scope of work or amends the original scope of work. You have to ensure again the permission to test memo doesn't or may not cover scope. Our scope. People work. That's outside of scope.

07:38

So we want to make sure we get an updated document and then have the client approved and get a copy of the scope signed encounter signed by both parties. That way, the client has been informed. They understand exactly what work is being added to the scope.

07:55

There should be no confusion again, assumptions. As we discussed in the previous discussion,

08:01

assumptions can hurt. Hurt hurt hurt you from the provider side, the person doing the work, the tester, the whatever the case may be. So having that counter signed by both parties and then approved would clear you to then conduct the world.

08:16

Now, take this with a grain assault. If you've got a process already for handling requests outside of the scope of work,

08:22

then then you know, use that modify it, do what you need to do. But this, in my mind, is a great process for ensuring that if you're approached by a client, that one numeral uno here, the tester has a method

08:39

to escalate that feedback and they know that they should not do anything outside of that. And then the project manager will take over and get any parties involved to handle the remainder of this and get that approved And then once it's all done, guess what? Then it comes back and you get the test or involved again and they're clear to go and everything's good, right?

08:56

So that's a great way to handle requests outside of the scope.

09:03

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

09:07

So take a moment to review the questions and think about the appropriate response.

09:13

If you need additional time, go ahead and pause the video.

09:16

So first, what term best?

09:20

Okay, defines

09:22

what a permission to test memo is. So what term? What bit of information here best defines a permission to test memo?

09:28

Well, the 1st 1 is a document that allows the tester to do anything to the environment. Well,

09:37

we know that that's definitely not the case. It should have very specific information and very specific dates and data on the testing. So the best definition is a document that provides specific details on who contest what systems in an environment.

09:52

So that is the best definition of the two provided

09:56

and then, true or false, there is a minimal risk or minimal risk in conducting undocumented work for clients, especially if they seem like nice people. Well, the response would be that is false, regardless

10:13

of whether or not a person seems nice or otherwise undocumented. Work on scoped work is of high risk for the tester and the firm conducting the work, the risk, the burden, the liability falls on the party conducting the works and, regardless of how person seems

10:31

always seek to update the scope

10:35

and seek to properly document the extension to that and any additional fees or or things that apply.