Goals

00:01

hello and welcome to another penetration testing, execution Standard discussion. Today we're going to be looking at goals and primarily focusing on the goals from the testers standpoint.

00:13

Now, quick disclaimer pee test videos do cover tools that could be used for system hacking. So any time we discuss tools or demonstrate the use of those tools, they should be understood by the user prior to turning around and testing those tools themselves.

00:28

In addition, you would want to research any laws, standards or applicable regulations for you given area prior to using any tools shown during this course.

00:39

Now let's go over the goals or the objectives of this and a high level. So we're discussing what goals are today, and we're going to look at primary and secondary goals. From the perspective of the tester, we will talk about how client goals could get woven into this,

00:58

but overall, we're just going to touch on what the goals should be for the tester. And then we're going to discuss business analysis at a high level and how that should play into goals and how you should use that information to make a decision on what testing methodology or processor procedure, you will take a CE faras for the client.

01:17

Now what our goals. Well, by its definition, a goal is the object of a person's ambition or effort and aim or desired result. So goals should be identified by both parties. You know Tester as well as client for a tester.

01:36

Okay, the goal should be about identifying risk that will adversely impacted clients organization. The client may want to be compliant

01:44

with a particular standard. They may have a business relationship that will be strengthened by doing the test. They may have a particular product that they're looking to implement, and they need to have their environment tested prior to its implementation. And maybe they want to do some some assessment of

02:02

the solution as long as it again is on prim and it's owned

02:06

by them, and it's not managed, maintained by 1/3 party.

02:10

Then you know, those were things to consider when we're coming up with the goals for the engagement now, primary goals.

02:20

Okay, the primary goal of

02:23

a test should not be driven by compliance Now. This may differ. If you're the person that's paying for the test, you may your primary goal may be to be compliant,

02:34

but there are several justifications for discussing this from the testers perspective. First off, we should never let a client be confused about testing,

02:45

equaling, comply, equaling security. So if I'm compliant with the standard,

02:50

it doesn't mean that I'm secure.

02:52

Let's just, you know, we'll mention a particular organization without mentioning it here, that in the US that had a huge breach of credit card information, they were compliant with PC, Idea says.

03:04

But they weren't secure. They had some measures that were not taken, some weaknesses that were discovered. And then, you know, threat actors were able to remove credit card data from the environment because of that. So we should never let a client feel

03:17

that by conducting the test and being compliant that they are secure. That would be a false sense of security.

03:23

So while many organizations undergo testing because of compliance, it should not be the main goal of the test. So affirm may be hard to complete. A penetration test is part of PC idea, says requirements. But

03:36

just because they're doing it to be compliant with PC, Idea says, and that's their goal is to be compliant. Your goal is to the tester is to identify risk, to identify things that could be up concerned that could reduce the security standing of the organization or could put

03:52

information at risk. And so those are your primary goals.

03:55

They may not always aligned with what the client is wanting to do. But as long as you

04:00

performed the test against your goal set and that you're looking to reduce risk and

04:06

increase their security posture, then you should be able to align with most all primary goals that a client may have.

04:15

Now, secondary goals for us are related to compliance. And so in this case, we can say that, yes, the secondary goal of this test will be to make you compliant. It's not uncommon for primary and secondary goals to be closely related. So

04:31

an example Given PC idea says driven tests Getting the credit cards is the secondary goal

04:36

right? Compromising the system's identifying risk doing those things definitely his primary that would allow us to then get to credit card information and do things of that nature.

04:48

It's a tying. That breach of data to business or mission drivers of the organization is the primary goal

04:56

in the case of PC Idea says So being able to say that this will impact the organization, that this will increase your risk standing, that this success is the reason that we need to do X, y and Z as faras Implementing controls is definitely the primary goal. Secondary

05:15

also means something for compliance.

05:17

Um and i t So these folks are the secondary in this, so they have to do certain things and implement controls to, you know, be compliant. And, you know, the IittIe auditors looking at compliance but really primary goals get the attention of upper management. So the c i o c e o.

05:38

We're speaking their language when we talk about risk, and those folks should be risk averse or at least understand what their risk tolerance is and whether or not those testing results align with that level of risk tolerance.

05:53

So business analysis eyes definitely important. We want to understand the security standing of the organization. We want to understand their maturity level when we make a decision in respect to helping them to meet their goals and to be more secure and reduced risk. So,

06:11

before performing a penetration test. It's beneficial to determine the maturity level of the clients security posture. And there are several organizations which choose to jump, like right into penetration testing

06:24

before assessing really the maturity level of the organization.

06:28

Or they use a PIN test to assess the maturity level of the organization. And this really isn't the best first step customers with immature security program. It's often best for them to perform what we call a vulnerability analysis first, and so

06:42

we can do a review of policy and procedure. We could do a review of technical controls. We can determine with some very just high level scans what the overall posture is. You know, it doesn't make sense that if you have a ship per se and there is a massive leak

06:59

in the hole and that will sink the ship at some point, you're not going to pay attention to other problems. That leak is going to be the thing that you want to get rid of because it reduces the risk of the ship's sinking. So

07:12

if we are aware that there could be major issues if we're aware that certain ports are open, that shouldn't be if We're aware that policy and procedure is not up to par and that technical controls air, not implement minute and out of minimum, some best practice areas.

07:27

Then what is the actual benefit of doing a penetration test?

07:30

It could be No, it could be. We could already know that we could get into a system and that we know that they're going to be extremely vulnerable. So it's like shooting fish in a barrel

07:41

and that may seem fun. You may go, man. Yeah, finally, a win.

07:45

But really, you're not doing any service to the client

07:48

by getting into those systems and really, you're doing them a disservice. And so in these cases, we could recommend a vulnerability analysis and do some review of the business, provide them with some meaningful feedback, provide them value

08:03

right, and give them an incentive to return. Hey, you know, once you implement these controls, once you get these things tightened up, you really hard in these systems and we feel that we've done some things to mitigate risk.

08:15

It may be best to come back and then do a penetration test, cause now we'll have a good you know, tighter security posture and we won't have some of these non best practice things open are available to the world.

08:26

Now, take that as it may. You can do this as you choose. You can go straight to penetration. Testing is a business, but really the more bang for the buck and the likelihood of re incurring re occurring business would be higher in my mind if you provide that value to an organization and you helped to be a trusted adviser and guide them toward

08:46

this method versus just going straight into a penetration test.

08:50

So with that in mind, let's do a quick check on learning true

08:54

or false clients with a very immature security program. Never having conducted a penetration test should not do a vulnerability analysis first.

09:07

Okay, so they haven't done a pin test

09:09

yet,

09:11

But the program is so immature, there's really nothing there

09:16

that you could see.

09:18

A SZ faras is risk reduction effort on their part,

09:20

so they haven't done a pin test.

09:24

Why would you want to do that

09:26

before vulnerability analysis?

09:30

Well, you wouldn't and you wouldn't you? In this case, let's read it out.

09:35

So am I Immature security program

09:37

never conducted a PIN test should not do a vulnerability, announces first. In this case,

09:43

that is false.

09:45

We want to do

09:48

vulnerability analysis first. We want to do that prior to do it in penetration test. We just got done discussing that. So if you think

09:54

that a PIN test should come before vulnerability analysis in a mature organization

10:00

again, that's an opinion that you can hold.

10:01

But you're going to provide the best value by providing this service to a new organization prior to jumping into doing a full penetration test.

10:09

So with that in mind, let's go ahead and wrap this up with are some ring. So today we discussed what goals are. We just looked at a high level definition when what there's mean for a tester versus a climate organization. We looked at the primary goals for a tester being to reduce risk

10:26

and really the secondary goals being compliance. We want to get the credit card information,

10:33

but that is secondary. The breach itself and the risk that it that it has to the organization, the things that are are apparent as faras. Those

10:45

risks are should be addressed first, getting access to credit card data is secondary to that and then with business analysis, we have to remember that we want to look at the state of an organization and understand where it's at so we can provide optimal value with respect to the type of test we conduct.

11:03

So with that in mind, I want to thank you for your time today,