Rules of Engagement Part 1

00:00

hello and welcome to another penetration. Testing, execution. Standard discussion today we're going to be going over rules of engagement now is a precursor to this. You may note that there's some topics that we had previously discussed. All of those were four kind of the syntax of the conversation,

00:19

and we will reiterate a few key concepts, as they were mentioned in rules of engagement specifically, and the role that they play in that.

00:28

So as a quick disclaimer pee test videos may cover tools or topics that have to do with system hacking. Any tools discussed or used during the demonstrations or discussions should be researched and understood by the user.

00:43

Please research applicable laws and regulations regarding the use of such tools in your given area. We will continue to generate that and reiterate that

00:53

throughout our discussions. So today's objective list is a little lengthy, but definitely worth the time. So we're going to discuss at a high level what rules of engagement are. We're going to discuss timelines, locations, evidence handling

01:10

regular Santa's meetings. I know that in the previous discussion, we touched on

01:15

status meetings, but its particular again to rules of engagement and understanding that as well as evidence handling, we will go over time of the day for testing, which is something that will be brought up in scope. Contractual language, et cetera.

01:32

Um, we're going to look at discussing attack reporting and when that is appropriate to do and may not be appropriate to do with respect to your attacks on the organization, we're going to again bring out the discussion to test memo and continue to generate why that is important. As well as discussing

01:52

legal considerations again.

01:53

Some of these may seem repetitive or redundant, but you can consume the particular discussions in any given order. And so, for the sake of rounding out the rules of engagement discussion and what should be considered an applied

02:09

to the rules of engagement, it is on Lee appropriate to reiterate some of these areas or introduce you to them.

02:15

If this is your first time joining us,

02:17

so let's go ahead and jump on over to what our rules of engagement. Well, while the scope in itself defines what will be tested,

02:30

the rules of engagement define how that testing will occur. So within the scope of service, you define what it is that you would be attacking

02:38

in which you would not be attacking. And overall, what the work will deliver.

02:45

The rules of engagement defined how that particular scope will be tested. So keep that in mind

02:52

these two aspects

02:54

I need to be handled independently

02:58

of each other so you don't do a scope meeting and the rules of engagement, meaning at the same time, each of those things should be handled independently of one another,

03:07

and they should be documented independently of one another. Now you would take into consideration the rules of engagement for a given scope.

03:15

But the scope may not dictate the rules of engagement, and vice versa. The scope may have specific limitations on the systems that will be tested, but how those systems will be tested may not be dictated by the scope. So keep that in mind

03:30

now. The first major area of discussion is the Tom Line, so we had previously looked at in the permissions memo, giving the time range etcetera for testing. So while the scope defines the start in in date for engagement, the rules of engagement

03:47

define everything in between. So this particular timeline is not so much. It starts on this day

03:53

and ends on this day,

03:57

but rather the tasks and things that will be doing in between. So the goal in this case is not to be rigid, rather having a timeline that will clearly define the work being done and by whom. Again, This comes back to communication. It comes back to accountability for the tasks

04:14

and ensuring that the client is well engaged

04:17

throughout the process. And so it is recommended that the schedule be created with either again chart with work breakdown structure, maybe just a high level representation of that work

04:30

versus a task. My task layout. It just depends on your operations, your processes and procedures for laying out the project scheduled for a client.

04:41

But there are plenty of free software is out there that provide this without you having to pay exorbitant upfront costs and things of that nature. And so,

04:50

in the interest of setting expectation and again understanding for for your sake, as the person performing the worker managing the work

05:01

whom will be involved and when, from a resource, you know, standpoint, being able to monitor that and manage that that would be beneficial to have this chart, and again it allows the client to understand who's working on what win, and it just provides extra transparency and communication.

05:18

It also ensures that you're going to meet your deadline for the drop dead date

05:25

and the end of the project. Nothing is worse than getting midway through a project and realizing that you didn't take into account certain circumstances or certain issues that may have arisen. And then you have to potentially extend that project, thereby impacting all other works on the rules of engagement.

05:44

The timeline. This schedule is worth discussing and understanding by both parties.

05:48

Now the locations are important to establish in the rules of engagement for these reasons. So where the tester may need to travel is important, as well as applicable laws, which will touch on once again

06:04

that depending on the area, state by state, in the United States or region by region in other areas, whatever the case may be, laws may change depending on where equipment is located

06:15

or where offices are located. So this is extremely important in the rules of engagement and laying out those sites. Most clients will use a sample of sites for testing and so traveled to every site may not be feasible, so we may not be able to go to every sight. And so

06:34

understanding how, if you're doing internal testing that would be accomplished, whether it be with the VP in connection or some other secure form of connection into the environment,

06:45

and then that those sites in scope will be feasible in in the rules of engagement as well. The way that we're testing them will be, ah Wei that you could measure risk across the board if you're looking at 100 locations and the client wants you to test too.

07:01

Okay, fine. But that may not be an accurate representation of the entire organization or the other 98 sites. So

07:09

it's good to understand that and understand where those will be within your rules of engagement, information handling limitations and protections should be identified upfront. So when we talk about P H. I P, I s oh, that's protected health information or ah,

07:28

identifiable, personally identifiable information, payment card information, anything that's protected by a regulation

07:34

that's stored on premise

07:35

is going to need to be something that you're aware of up front so that you don't end up in a scenario where you use a tool that skims data

07:46

and you accidentally pick up Voight calls that are sensitive or medical information or payment card data or personal information. You don't want to be responsible for that information as far as it being stored on your system or skin,

07:58

and it could put you on the wrist depending on the reporting requirements. And the protections laid out for those data sets that you should be extremely careful there.

08:07

That's why up front for those locations and data sets

08:11

access validation methods should be agreed upon a fun. So if a snippet of a directory and a file name is appropriate as long as it doesn't contain sensitive information like a screenshot, if that's appropriate, that should be identified. If the client wants you to

08:28

attempt to copy that data out, I would be extremely hesitant

08:33

and would really consult local law, any compliance requirement law, any reporting requirement law and maybe even counsel to ensure that your contract as well a scope and testing documentation permission to test memos explicitly layout the terminology

08:52

and the limitations that you have within that test, to ensure that you don't end up in any legal hot water for from accessing sensitive information. I know that most requirements like hip

09:05

unless you're providing treatment for a patient directly,

09:07

you're not supposed to access that information. And so that would be in violation of that requirement for both you and the organization that gave you permission to do it. So take all those things into consideration prior to working with that data and then any illegal data,

09:24

all right, based on region.

09:26

And, uh, things of that nature encountered should be immediately reported to law enforcement

09:33

and then the customer.

09:35

And in some cases it may just be law enforcement, depending. But we're talking about illegal content such as *** that would be considered illegal. We're talking about material that could be considered illegal,

09:50

anything of that nature directions for maybe manufacturing illegal substances. Whatever the case may be, if you encounter data that is illegal, your first point of contact should be law enforcement. Now that may seem counterintuitive, but

10:05

without context of who would be involved in providing that data having that date on those systems and how it got there, you couldn't take no risk

10:16

In that environment, you can take no risk in that. With the client. You need to immediately inform law enforcement at at the point that you come in contact with that data. And the reason for that is that law enforcement will have particular ways that they'll need to handle that information that they'll need to collect it and evaluate it.

10:33

And you can never know within a client organization who put that data there and why. So you need

10:39

to always treat that information with the utmost of caution and immediately notify law enforcement. Now, I would say Ensure that you know that is in mind with, um,

10:50

any advice that council would give you. But that is going to be top of mind is that illegal content is immediately reported, so don't don't cover that. Don't provide information to the client first, Don't allow them to dictate how you handle that data immediately report it and then go from there.

11:07

Now evidence handling with respect to client data and information that you collect extreme care with respect to client data and reporting should always be taken

11:20

if you accidentally exposed information and it gets you know, reported to the masses. You're probably up the creek at that point as far as your career does. You

11:31

cannot have an accident of that of that calibre. When it comes to handling client information and sensitive data, there is a large amount of trust placed in use. The tester on DSO You should always, always, always use encryption

11:46

on systems where data is being stored, making sure that that encryption Methodist legal for your given area and that you always sanitize the system that you're using for testing in between tests. The last thing you want to do is lose a system

12:03

that then ends up having client information on it that could be used to harm them. That would then require reports that be found with state agencies. Whatever the case may be that requires, you know, patient or client notification. As far as your clients clients,

12:20

it's just messy, and so you need to treat the systems and evidence that you collect with the utmost of respect and utmost of security.

12:28

Now, never

12:31

and I say ever

12:33

really use reports from customer engagements as templates. Accidental exposure is very,

12:39

very unprofessional, and I've heard it.

12:43

Thoma Thoma again in larger organizations where someone wants

12:48

to take a client report

12:50

and sanitize it

12:52

so that they could use it for sales purposes or so that they can use it to, um,

12:58

provide feedback and show kind of what this reports look like. If you've got someone who wants to get a sample report, then you write something that is going to be used for sample purposes and has no pertinent no riel information on it whatsoever.

13:16

If you ever reuse a report or give a report to someone for the sake of showing an example of the work

13:24

and you expose client information, even if it's an I P address, you've broken trust, and you could put yourself at risk for any number of legal issues as well as very high damage to your reputation is it is in testing organization. So it is not worth the risk

13:43

to provide sample reports that contain live client information,

13:48

period. And I would take that stance with anybody, even at the risk of employment, that I would not provide a report with client information in it unless the client gave explicit permission for that report to be shared with the party involved for explicit reasons that are well documented and defined,

14:09

I would not provide it otherwise. You run the risk of tarnishing reputation, damaging a client, damaging their clients and customers. It is not worth the risk. So never, ever, ever, ever reused client data as a template. There reports is a template. Their information for sales marketing doesn't matter.

14:28

Just takes one time for you to make a mistake.

14:31

One time for there to be an accident. And the next thing you know, you're in a world of hurt. So I'd avoid that topic altogether and avoid that risk altogether.

14:39

Now, we talked about regular status meetings previously. Um, it is critical.

14:46

Okay, I'm gonna say it again. Critical to have regular meetings with the customer to discuss overall progress of the test.

14:54

Now,

14:56

some would say daily, but I would say this would be agreed upon by both parties prior to starting the test reason Being dependent on scope and scale, you may not need to do daily meetings. It may just be weekly. It maybe every other week. It maybe wants him up. Whatever the test, maybe whatever the methodology, maybe whatever it is that you're doing

15:16

that would need to be agreed upon by both parties. Now the three key concepts that should be covered. Plan's progress and problems. Now let's touch on this.

15:28

So plans

15:31

are generally discussed so that the test is not conducted during a major unscheduled change or an outage. So what are the plans? What's going on in the environment? Do we need to be aware of anything that would negatively impact the test or hold the test up? So what are the plans? What are we doing? Progress

15:50

is simply an update to the customer on what has been completed so far.

15:54

So we've got that Gant chart. We've got the work breakdown structure.

15:58

We're showing progress. What we've done thus far, what we have left to do

16:03

and then we discussed problems is a potential component of that. So these are discussed in the meeting. But in the interest of, you know, making that meeting brief No more than 30 minutes really should be taken for this. Conversations concerning solutions to problems

16:18

should almost always be taken off line, so they shouldn't be mainstream. Really. The part the parts of the meeting you want to focus on

16:23

are what are the plans that the organization has. What is your progress as the tester? And what problems are you running into? That either need to be addressed so that the progress can continue towards completion? Or that the client needs to be aware of its and then address it to help them maybe reduce risk

16:44

and exposure. So those are the three court things again, these meetings really shouldn't go over 30 minutes in length. And if you can't keep it down to those three key areas than you, you know, may waste some time and may make those meetings less useful or impactful in the process. So be aware of that.