Additional Support Part 1

00:01

hello and welcome to another penetration test in execution Standard discussion. Today, we're going to be looking at the topic of additional support within the pre engagement interaction section. So before we get started, let's go with a quick disclaimer.

00:19

The Pee test videos do cover tools that could be used for system hacking.

00:24

Any tools discussed or used during any demonstrations should be researched and understood by the user. Please research your laws and regulations regarding the use of such tools in your given areas. Again, while we're having fun and learning, we want to ensure that we're safe in that process.

00:42

So let's go ahead and jump over to our objectives.

00:45

So in today's discussion, we want to understand what additional support is. How does that look? From a terminology standpoint and a contractual standpoint, we want to understand what ad hoc is or an ad hoc basis

01:00

understand some legal ramifications or potential legal ramifications and how those could be applied with additional supporter and hot work.

01:07

We want to understand the permission to test memo when we have a snippet of that will kind of go through that together,

01:15

and then we're going to look it and understand how to handle, or at least a particular way, that you can handle these additional requests. So let's go ahead and jump into additional support.

01:27

Now. Additional support is defined as any work that is not explicitly covered within the scope of the engagement. And so any time a client or customer asks you to do additional work that you know is not covered, it should be considered high risk

01:45

in terms of handling that,

01:48

um, and win terms for handling it are not properly documented, and the reason for that is

01:55

won. Any additional support could definitely contribute to scope creep. And it's not always this way for security testing and penetration testing, but definitely in things like software development circles. I know that scope creep can be huge as faras killing a project or making it

02:15

grossly unprofitable. And I've seen in some cases where

02:19

it can kill a firm, a cz far as profitability and a loss of revenue and work.

02:24

And then, from the testers perspective,

02:29

they may not consider the endoscope work as as a problem. Um, and they may do it because they feel it's the right thing to do, and so I've seen it time and time again where I manage a project on guy have engineers that go and do some work.

02:45

Then they come back and ask him, Hey, why did it take you additional two hours to do this task? And you know, we're well aware that only takes it. Let's say four it took you,

02:53

you know, six. What? What was the deviation here? What happened? Well, you know, I had a conversation with the client and they really wanted me to do some extra checks. And, you know, they seem to be really nice. And, you know, I didn't see a problem with this and I was just trying to do you know what needed to be done to go above and beyond?

03:12

Well, that makes sense. We want people thio

03:15

be somewhat sympathetic to the client. We want to have repeat business, but at the same time,

03:21

we need to properly communicate how providing additional support, especially in a security testing or penetration testing scenario, should be approached carefully and methodically. And so let's look at some examples and define what and hot work is

03:38

so add hot is a term meaning created or done for a particular purpose as necessary. And so a lot of the requests that we see

03:51

from clients are things like additional system testing. Hey, you guys are doing such a great job on this external testing that I actually have a server internally. That's very, very critical, and I would really appreciate it if you could do some testing on that system. Well, that's ad hoc. That's not a part of the original scope

04:09

assistance in remediating findings. Now

04:12

the purpose of penetration testing is definitely defined risk to identify risk and to give a client kind of the appropriate guidance and remediating that. But a lot of times, because environments very so drastically from from, you know, business to business,

04:30

it may not be feasible. Toe always build remediation assistance into that because you may not have the subject matter expertise in order to address the issue, and so that needs to be handled on a case by case basis. And it would be very, very cautious. One building that into a project

04:46

calls with vendors to explain findings. Now, this could be something that you build in as a part of the initial scoping as a part of the

04:56

of reporting and kind of post engagement activities.

05:00

But again, not everyone builds this into the scope of work. And so, you know, you might wanna handle that on a case by case basis. And then, much like with the client environment,

05:12

you know, the client may want you to explain to the vendor. So let's just say that the client is not a savvy person with respect to technology. They really don't know the difference between

05:23

a switch and around or they have no comprehension of what HTML is or looks like. They're they're running the business. They have third parties handling everything. So it would make sense in that scenario to build some time in to discuss with vendors the findings. But the vendor should have

05:42

the capability if they are the subject matter expert on the particular system,

05:46

how to remediate that based on your findings. If they do not, then you may want to approach this on a case by case basis. Now,

05:56

this is definitely a dangerous area to get into if you don't build retesting of systems into the scope of service, and they're not a part of the time frame for testing and retesting.

06:09

Then

06:10

you would either one or approach retesting of systems is a separate engagement or ensure that any

06:17

documentation our contracts covers retesting of systems. The last thing you want to do is re test the system. 30 days later, it wasn't covered by the original testing memo.

06:30

Something happens. The clients now upset. They pull you over the carpet and get you into a lot of trouble because that work was not covered by the original scope. And then there may be circumstances where you're dealing directly with someone who has permission

06:46

to allow testing on the environment like a director of you know, I t or the c i o.

06:53

And you know, you go through, you do everything by the books you provide the final report to the C I o along with recommendations.

07:00

And let's just say you know, a week later, after you've delivered, you know, invoicing, they say, Hey, you know, we'd really appreciate it if you could do some additional meetings with our shareholders and the other business owners.

07:13

Um, you know, they really want to get your feedback and really want to better understand what it is that you've delivered

07:18

well, depending on the opportunity. You know, you may want to address that again on a case by case basis. We talked earlier in the scoping conversations about that consulting 20% or that overhead that we add into an engagement to cover scenarios that may not be

07:39

accounted for initially. And so some of these meetings could be accounted for. If you're on an hourly basis,

07:46

Ah, and you give the decline an estimate for the work, and then you know you fall short of the hours, which isn't a problem when you're working out early for the client. But then when they say you know you've got some extra time, let's you know, let's do an additional meeting Well again, depending on the work and the request,

08:03

it would be best to handle that on a case by case basis.

08:05

Now let's discuss some of the potential legal ramifications or how you know these things could become legal issues foreign organization when they're not covered by the scope. So

08:18

in most permission to test memos which will look at a high level, they provide some kind of high level detail on the work. And so if the information is not covered by the permission to test memo.

08:35

Technically, you were never given authorization to do the work. And then where it becomes doubly dangerous is when none of that additional work or language concerning that work is covered by the scope of service. And so essentially,

08:50

you may do something. You know, at heart, you've got the best interest of the client of mine. You're trying to do everything you can to make sure that they have a satisfactory experience with you. But at the end of the day, if a problem comes up, there was nothing that legitimately covered you from a legal standpoint in this case.

09:09

And so at times

09:11

when we do ad hoc work, there's no written communication that approves the work. And so

09:18

there may even be some written communication. But that could be up for interpretation or not found at all. And so whoa is the is the scenario where you know ah customer says, Hey, here's an additional I p

09:33

It belongs to us. It's, you know, something that we need to have tested to ensure that things were good.

09:39

Let's say that that that belongs to a different department that department has very sensitive systems off of that address. The individual that provided the I p may have had permission to and the ability to have the others tested

09:54

you, you know, believing that they're a nice person and that everything's running smoothly. You decide to test it,

10:01

and then later that night you get a call from the organization. They're they're critical systems have been down for, you know, the last two hours, and they're hemorrhaging money now because they can't get orders processed or something came up. Well,

10:18

humans have this kind of tendency to protect themselves and to protect their livelihoods. And if you can't prove that permission was validly given, you can't prove that this person gave you permission and that they have the authority to do so. There's no legally binding documentation.

10:35

You're now on the hook for some potential legal issues, a cZ well as potentially criminal issues because you've now done damage to systems that may or may not be fixable.

10:48

And so I always remember that liability is very hot for the tester. When there's no contract language that protects them. A customer, a client can say anything they want to say when there's nothing there to prove that. And we go with that, that the customer is always right. You know, the client is always right.

11:07

And so if you're a cog in the wheel, if you're a tester in a large organization

11:13

and you go out on a limb and do work that is not covered in a contract or not covered in in any particular testing memo, you put yourself at risk, Um, and your livelihood and your family at risk. So always, always, always consider these ramifications and consider these scenarios

11:33

prior to doing any additional work.

11:35

Foreign organization.