WEBVTT

0:00:03.660000 --> 0:00:09.800000
 The pre engagement phase of any penetration
 test, regardless if it is

0:00:09.800000 --> 0:00:14.060000
 a standard penetration test or a
 web application penetration test.

0:00:14.060000 --> 0:00:18.200000
 So in this video, we're going to be
 taking a look at what is typically

0:00:18.200000 --> 0:00:23.660000
 done before you begin a professional
 web application penetration test

0:00:23.660000 --> 0:00:28.540000
 and the reason why I included this
 video in this section is primarily

0:00:28.540000 --> 0:00:33.940000
 because it is very important to understand
 what happens in both of these

0:00:33.940000 --> 0:00:39.200000
 phases. So pre engagement comes before
 the engagement begins and the next

0:00:39.200000 --> 0:00:43.440000
 video which will focus on documenting
 your findings and reporting comes

0:00:43.440000 --> 0:00:45.960000
 after the engagement is completed.

0:00:45.960000 --> 0:00:50.100000
 And you'll see how everything we've
 covered in this section sort of ties

0:00:50.100000 --> 0:00:52.460000
 in together when we get
 to the next video.

0:00:52.460000 --> 0:00:57.060000
 But for now, we're starting off
 with a pre engagement phase.

0:00:57.060000 --> 0:00:59.560000
 So what is the pre engagement phase?

0:00:59.560000 --> 0:01:03.400000
 The pre engagement phase of web application
 penetration testing and penetration

0:01:03.400000 --> 0:01:08.100000
 testing in general is a crucial step that
 lays the foundation for a successful

0:01:08.100000 --> 0:01:10.660000
 and well-planned security assessment.

0:01:10.660000 --> 0:01:15.680000
 It involves preliminary preparations,
 understanding project requirements,

0:01:15.680000 --> 0:01:20.020000
 and obtaining necessary authorizations
 before initiating the actual testing.

0:01:20.020000 --> 0:01:24.380000
 During the pre engagement phase, the
 penetration test and the client must

0:01:24.380000 --> 0:01:29.700000
 sit down, discuss, and agree upon a number
 of legal and technical details

0:01:29.700000 --> 0:01:34.260000
 pertinent to the execution and the outcomes
 of the security assessment.

0:01:34.260000 --> 0:01:39.540000
 So it's essentially the process of
 sitting down with the actual client

0:01:39.540000 --> 0:01:43.660000
 you're performing the web app NTest
 for and agreeing on various things.

0:01:43.660000 --> 0:01:45.840000
 Now, what are you agreeing on?

0:01:45.840000 --> 0:01:50.760000
 Well, basically speaking, I can break
 it down into these primary sections.

0:01:50.760000 --> 0:01:55.700000
 So this can be sort of summarized because
 they are treated as documents.

0:01:55.700000 --> 0:01:59.380000
 This can be one or more documents with
 the objectives to define the following.

0:01:59.380000 --> 0:02:05.180000
 So firstly, defining the objectives
 or rather the goals and the scope

0:02:05.180000 --> 0:02:06.460000
 of the engagement.

0:02:06.460000 --> 0:02:09.600000
 I'll get into what each
 of these pertains.

0:02:09.600000 --> 0:02:12.860000
 Secondly, very important, the
 timelines and milestones.

0:02:12.860000 --> 0:02:17.740000
 So typically, you want to sit down
 with the client and you first start

0:02:17.740000 --> 0:02:21.000000
 with the goals. What that means
 is what are their goals?

0:02:21.000000 --> 0:02:22.600000
 What are the client's goals?

0:02:22.600000 --> 0:02:25.800000
 What do they want to get
 out of the web app NTest?

0:02:25.800000 --> 0:02:31.180000
 And then based on that, that pretty
 much leads to you defining or the

0:02:31.180000 --> 0:02:33.220000
 client defining what the scope is.

0:02:33.220000 --> 0:02:37.220000
 And the point is that the scope is closely
 related to the goals and the

0:02:37.220000 --> 0:02:41.060000
 scope doesn't come before the goals because
 that wouldn't make any sense.

0:02:41.060000 --> 0:02:45.480000
 The scope essentially refers to what you're
 allowed to test and what you're

0:02:45.480000 --> 0:02:48.280000
 not allowed to test, which is where
 you have the terms in scope and out

0:02:48.280000 --> 0:02:52.220000
 of scope. And then from that, based
 on the goals and the actual scope

0:02:52.220000 --> 0:02:56.940000
 of the engagement or the web app NTest,
 from that, you would be able to

0:02:56.940000 --> 0:03:00.360000
 derive a timeline based on everything
 that needs to be done.

0:03:00.360000 --> 0:03:04.400000
 Now, you would not be able to do this accurately
 if you were using a methodology

0:03:04.400000 --> 0:03:07.160000
 like the one I showed you
 in the previous video.

0:03:07.160000 --> 0:03:11.520000
 But once you've done that, you then move
 on to laying out the liabilities

0:03:11.520000 --> 0:03:17.280000
 and responsibilities tied to the actual
 engagement of the web app NTest.

0:03:17.280000 --> 0:03:19.840000
 As I said, I'll explain what that means.

0:03:19.840000 --> 0:03:24.920000
 You also have explicit mention or statement
 of the authorized action.

0:03:24.920000 --> 0:03:28.460000
 So this is where the client will tell
 you what you can and cannot do with

0:03:28.460000 --> 0:03:39.500000
 regards to your web application you
 cannot cause any damage to the data

0:03:39.500000 --> 0:03:41.040000
 stored within it.

0:03:41.040000 --> 0:03:44.480000
 Pretty much just rules of engagement.

0:03:44.480000 --> 0:03:48.380000
 You then have the expectations and
 deliverables which are derived from

0:03:48.380000 --> 0:03:51.940000
 the goals and the scope and
 the scope of the engagement.

0:03:51.940000 --> 0:03:57.560000
 So this is where it's clearly defined
 now what the client expects based

0:03:57.560000 --> 0:04:00.820000
 on what you had agreed on in terms
 of the objectives and the scope.

0:04:00.820000 --> 0:04:05.460000
 And then the deliverables will be defined
 by you in alignment with the

0:04:05.460000 --> 0:04:06.700000
 actual expectation.

0:04:06.700000 --> 0:04:12.200000
 So if they ask you to perform a if they
 ask you to perform input validation

0:04:12.200000 --> 0:04:18.360000
 testing or injection testing on their web
 application, that's their expectation

0:04:18.360000 --> 0:04:22.460000
 is to get an understanding as to whether
 a particular web application

0:04:22.460000 --> 0:04:27.240000
 of theirs is vulnerable
 at all to SQL injection.

0:04:27.240000 --> 0:04:31.000000
 From that, you can say the deliverables
 will be that will you know, we'll

0:04:31.000000 --> 0:04:32.600000
 do this and this and this and this.

0:04:32.600000 --> 0:04:34.820000
 This is the methodology we'll use.

0:04:34.820000 --> 0:04:37.680000
 And you know, this is what
 the outcomes will be.

0:04:37.680000 --> 0:04:42.820000
 Regardless of the actual results, you
 will get to know, you know, to a

0:04:42.820000 --> 0:04:46.940000
 certain extent based on these particular
 techniques we will utilize whether

0:04:46.940000 --> 0:04:49.760000
 the web application is indeed vulnerable.


0:04:49.760000 --> 0:04:53.860000
 If it is, we'll actually document
 and report our findings.

0:04:53.860000 --> 0:04:56.140000
 If not, we'll also report that.

0:04:56.140000 --> 0:05:02.460000
 And then the statement of
 is more so financial.

0:05:02.460000 --> 0:05:06.300000
 Now, this is sort of a basic
 way of looking at it.

0:05:06.300000 --> 0:05:12.040000
 But I can sort of break it down into
 again, sort of break down the pre

0:05:12.040000 --> 0:05:15.820000
 engagement steps into how they
 are typically defined.

0:05:15.820000 --> 0:05:19.840000
 Because what I highlighted previously
 is sort of a basic approach to it

0:05:19.840000 --> 0:05:21.900000
 that is sort of a macro approach.

0:05:21.900000 --> 0:05:26.200000
 And this is sort of the preferred method
 or the preferred way of going

0:05:26.200000 --> 0:05:31.860000
 about it. So, typically what I do in a pen
 test is I start off by understanding

0:05:31.860000 --> 0:05:34.200000
 the project objectives
 or the goals, right?

0:05:34.200000 --> 0:05:38.140000
 So clearly define the objectives and goals
 of the pen test with the client.

0:05:38.140000 --> 0:05:41.800000
 So, you know, what are you looking to?

0:05:41.800000 --> 0:05:43.300000
 What are your goals here?

0:05:43.300000 --> 0:05:46.040000
 What do you want as the outcomes?

0:05:46.040000 --> 0:05:48.280000
 Why are you looking to do this?

0:05:48.280000 --> 0:05:52.340000
 Have you experienced any attacks previously
 that are sort of driving this?

0:05:52.340000 --> 0:05:55.340000
 Are you looking to improve your security
 posture and all of that stuff

0:05:55.340000 --> 0:06:02.220000
 factors into, you know, my actual, my
 actual implementation plan or how

0:06:02.220000 --> 0:06:07.600000
 I define the actual engagement in terms
 of how we'll perform it, etc.

0:06:07.600000 --> 0:06:10.540000
 So the objective is to understand what
 the stakeholders aim to achieve

0:06:10.540000 --> 0:06:11.780000
 through the testing process.

0:06:11.780000 --> 0:06:14.400000
 That brings us to the scope definition.

0:06:14.400000 --> 0:06:19.600000
 So remember that comes that comes after
 you have understood the goals

0:06:19.600000 --> 0:06:24.440000
 and objectives. So, with regards to
 the scope definition, this is where

0:06:24.440000 --> 0:06:27.660000
 we identify the scope of the penetration
 test, including the specific

0:06:27.660000 --> 0:06:31.880000
 web applications, URLs and the
 functionalities to be tested.

0:06:31.880000 --> 0:06:35.500000
 And we define the scope boundaries and
 limitations, such as which systems

0:06:35.500000 --> 0:06:39.900000
 or networks out of scope for testing
 that can typically be derived, you

0:06:39.900000 --> 0:06:44.320000
 know, based on the objectives or what
 the goals are of the pen test.

0:06:44.320000 --> 0:06:46.800000
 You then have the authorization
 and legal requirements.

0:06:46.800000 --> 0:06:49.900000
 So this is where you obtain proper
 authorization signed authorization

0:06:49.900000 --> 0:06:54.740000
 from the organization's management or
 the application owners to conduct

0:06:54.740000 --> 0:06:55.960000
 the penetration test.

0:06:55.960000 --> 0:07:02.440000
 So typically the CTO, CIO or CISO, and
 ensure that you're getting it from

0:07:02.440000 --> 0:07:08.260000
 the individual that has the appropriate,
 the appropriate role or the individual

0:07:08.260000 --> 0:07:12.100000
 who is essentially allowed to sign
 off on this, because you never want

0:07:12.100000 --> 0:07:15.620000
 to be in a position where you
 are essentially liable.

0:07:15.620000 --> 0:07:19.200000
 So ensure that everything is signed
 before you do anything.

0:07:19.200000 --> 0:07:22.540000
 So essentially ensure that the testing
 activities comply with any legal

0:07:22.540000 --> 0:07:28.000000
 or regulatory requirements, and that
 all relevant permissions are secured.

0:07:28.000000 --> 0:07:31.260000
 You then have your rules of engagement.

0:07:31.260000 --> 0:07:34.740000
 This is where you establish a set rules
 of engagement that outline the

0:07:34.740000 --> 0:07:37.860000
 specific rules constraints and guidelines
 for the testing process.

0:07:37.860000 --> 0:07:43.900000
 So this is what you'll be doing, where
 you'll start, where you'll stop

0:07:43.900000 --> 0:07:46.920000
 in terms of things that you can do.

0:07:46.920000 --> 0:07:49.960000
 Of course, this is something you'll
 agree on with the client.

0:07:49.960000 --> 0:07:54.160000
 Like they can tell you, for example,
 what I just said previously, if you

0:07:54.160000 --> 0:08:00.440000
 can't use any particular web shell, for
 example, you'll find a file upload

0:08:00.440000 --> 0:08:02.840000
 vulnerability, just stuff like that.

0:08:02.840000 --> 0:08:09.740000
 And also guidelines, for example, if
 they wanted you to use the OS top

0:08:09.740000 --> 0:08:14.720000
 10 as a reference point, or even the
 web security testing guide, then

0:08:14.720000 --> 0:08:17.540000
 you can also, that can
 also be put in there.

0:08:17.540000 --> 0:08:20.360000
 The point is that you mutually
 have to agree.

0:08:20.360000 --> 0:08:23.600000
 So the client and you yourself, regardless
 of whether you're an individual

0:08:23.600000 --> 0:08:27.660000
 or a company. So you include details
 about the testing schedule, testing

0:08:27.660000 --> 0:08:31.240000
 hours, communication channels,
 and escalation procedures.

0:08:31.240000 --> 0:08:36.180000
 Essentially, outlining how this thing
 is going to work, how this engagement

0:08:36.180000 --> 0:08:40.680000
 is going to work from the start all the
 way to the end, what times you're

0:08:40.680000 --> 0:08:44.780000
 going to be performing the tests at or
 on based on the client's requirements,

0:08:44.780000 --> 0:08:48.320000
 if they have any, how long you're going
 to be performing the test every

0:08:48.320000 --> 0:08:53.220000
 day, how you're going to communicate
 in the event of pretty much anything

0:08:53.220000 --> 0:08:55.660000
 and the escalation procedures.

0:08:55.660000 --> 0:08:57.760000
 And then you have communication
 and coordination.

0:08:57.760000 --> 0:09:02.600000
 So this is where you establish clear communication
 channels with key stakeholders,

0:09:02.600000 --> 0:09:05.640000
 including IT personnel development
 teams and management.

0:09:05.640000 --> 0:09:10.500000
 So you can set up like weekly meetings
 that are scheduled every week with

0:09:10.500000 --> 0:09:11.880000
 certain individuals.

0:09:11.880000 --> 0:09:16.600000
 You can have a Slack channel, or you
 know, you can use teams or whatever,

0:09:16.600000 --> 0:09:19.580000
 and you coordinate with relevant personnel
 to ensure minimal disruption

0:09:19.580000 --> 0:09:21.220000
 to the production environment.

0:09:21.220000 --> 0:09:23.680000
 So you essentially tell the developers
 that on this day will be doing

0:09:23.680000 --> 0:09:26.560000
 this, you know, so on and so forth.

0:09:26.560000 --> 0:09:30.100000
 Very, very simple in terms
 of what needs to be done.

0:09:30.100000 --> 0:09:33.120000
 You then have the contract and
 non disclosure agreements.

0:09:33.120000 --> 0:09:37.060000
 This is only if it is required, but
 you sign the necessary contracts and

0:09:37.060000 --> 0:09:40.960000
 non disclosure agreements, also known
 as NDA's with the organization to

0:09:40.960000 --> 0:09:45.020000
 protect sensitive information
 and ensure confidentiality.

0:09:45.020000 --> 0:09:46.360000
 You then have a scoping meeting.

0:09:46.360000 --> 0:09:50.700000
 This is sort of a second scoping meeting
 after the initial scope was set

0:09:50.700000 --> 0:09:54.380000
 out. And what you're doing here is you're
 just verifying with the client

0:09:54.380000 --> 0:09:57.720000
 that this is what we agreed on earlier.

0:09:57.720000 --> 0:10:02.140000
 Are you guys still sure that you
 want to stick with this scope?

0:10:02.140000 --> 0:10:03.680000
 If okay, then no problem.

0:10:03.680000 --> 0:10:05.920000
 If we need to make changes,
 let's do it right now.

0:10:05.920000 --> 0:10:09.560000
 So conduct a scoping meeting with key
 stakeholders to discuss the testing

0:10:09.560000 --> 0:10:12.440000
 objective scope and any specific
 concerns or constraints.

0:10:12.440000 --> 0:10:14.060000
 So that's another good point.

0:10:14.060000 --> 0:10:17.060000
 If you're looking at the scope after
 you're defined it and you realize

0:10:17.060000 --> 0:10:21.240000
 that it may be a potential issue, you
 set up a scoping meeting so you

0:10:21.240000 --> 0:10:24.500000
 can update it or essentially
 make changes to it.

0:10:24.500000 --> 0:10:29.220000
 And then again, the there has to be
 an agreement on both sides as well.

0:10:29.220000 --> 0:10:32.700000
 So you use this meeting to clarify
 expectations and ensure everyone is

0:10:32.700000 --> 0:10:34.660000
 aligned with the testing approach.

0:10:34.660000 --> 0:10:38.900000
 And then you move on to preparation
 of tools and resources, where you

0:10:38.900000 --> 0:10:42.320000
 ensure that the testing team has all
 the required tools, licenses and

0:10:42.320000 --> 0:10:43.960000
 resources needed for the assessment.

0:10:43.960000 --> 0:10:48.260000
 So just preparing yourself and your team,
 and you set up a secure testing

0:10:48.260000 --> 0:10:51.180000
 environment and any necessary
 virtual machines for testing.

0:10:51.180000 --> 0:10:55.040000
 So in the case of Web App testing,
 getting your tools ready, ensuring

0:10:55.040000 --> 0:10:59.240000
 everyone has burp suite, everyone
 is using the spreadsheet.

0:10:59.240000 --> 0:11:02.820000
 Pretty much everyone is on the
 same Slack channel as me.

0:11:02.820000 --> 0:11:07.580000
 We have pretty much meetings every
 afternoon to track the progress.

0:11:07.580000 --> 0:11:11.340000
 And we also have own system
 tracking software.

0:11:11.340000 --> 0:11:15.400000
 We have VPSs that we set up in
 the cloud to perform the test.

0:11:15.400000 --> 0:11:20.640000
 If it's a black box pen test on a web
 application, and you know, that's

0:11:20.640000 --> 0:11:21.960000
 typically what it involves.

0:11:21.960000 --> 0:11:25.420000
 So nothing too complex there.

0:11:25.420000 --> 0:11:28.520000
 You then have risk assessment
 and acceptance.

0:11:28.520000 --> 0:11:31.140000
 This is where you perform a risk assessment
 to understand the potential

0:11:31.140000 --> 0:11:36.080000
 impact of the penetration test on the
 web application and the organization.

0:11:36.080000 --> 0:11:42.220000
 This is not usually done, but it is
 if you do this, it really, it really

0:11:42.220000 --> 0:11:51.380000
 does help where you spread sheet to see
 what the potential risks are with

0:11:51.380000 --> 0:11:52.800000
 you performing the pandas.

0:11:52.800000 --> 0:11:57.460000
 Because remember, you can actually
 perform damage by your actions as a

0:11:57.460000 --> 0:11:59.660000
 web app pen test or just
 a pen test in general.

0:11:59.660000 --> 0:12:03.580000
 So you obtain management acceptance of
 any risks associated with the testing

0:12:03.580000 --> 0:12:07.500000
 process. So you essentially tell them
 that this is what I think could

0:12:07.500000 --> 0:12:10.920000
 happen, the worst, worst case scenario.

0:12:10.920000 --> 0:12:15.980000
 In our case, you would need to you would
 agree and essentially acceptance

0:12:15.980000 --> 0:12:20.840000
 of the risks. This would be a liability
 on their end if they accept it.

0:12:20.840000 --> 0:12:23.160000
 So in most cases, usually
 are back and forth.

0:12:23.160000 --> 0:12:26.940000
 There have been cases where the pen
 testing company has other ones who

0:12:26.940000 --> 0:12:30.460000
 have accepted the risk and that
 they will be held liable.

0:12:30.460000 --> 0:12:33.780000
 You know, in that case, these pen testing
 companies usually have insurance

0:12:33.780000 --> 0:12:37.140000
 against this and have really
 good pen testers.

0:12:37.140000 --> 0:12:42.240000
 So the risk may be high, you know, the
 probability, the actual probability

0:12:42.240000 --> 0:12:44.840000
 is quite low because they're
 very, you know, careful.

0:12:44.840000 --> 0:12:49.780000
 And again, you can only be careful
 if you're using a methodology.

0:12:49.780000 --> 0:12:51.700000
 You then have the engagement kickoff.

0:12:51.700000 --> 0:12:55.640000
 So this is when you now, you know,
 essentially kick off this pen test.

0:12:55.640000 --> 0:12:59.240000
 So officially kick off the penetration
 test, confirming the start date

0:12:59.240000 --> 0:13:02.340000
 and the timeline with the
 organization stakeholders.

0:13:02.340000 --> 0:13:06.200000
 You share the rules of engagement and
 any other relevant details with

0:13:06.200000 --> 0:13:07.420000
 the testing team.

0:13:07.420000 --> 0:13:09.940000
 So you can get things started.

0:13:09.940000 --> 0:13:15.240000
 So that is pretty much what the pre engagement
 phase of any pen test looks

0:13:15.240000 --> 0:13:19.420000
 like regardless of whether it's a mobile
 pen test or a web app pen test

0:13:19.420000 --> 0:13:21.740000
 or a standard pen test or an
 active directory environment.

0:13:21.740000 --> 0:13:27.200000
 That's what it looks like in terms of
 the phases and, you know, the actual

0:13:27.200000 --> 0:13:31.540000
 documents required and, you know, how
 you go from inception or definition

0:13:31.540000 --> 0:13:36.180000
 of the goals and the scope all the
 way to actual, you know, the actual

0:13:36.180000 --> 0:13:37.960000
 kickoff of the pen test.

0:13:37.960000 --> 0:13:42.880000
 Now that we've taken a look at that,
 the pre engagement phase, we are

0:13:42.880000 --> 0:13:48.360000
 now, you know, theoretically at the
 phase where we need to perform the

0:13:48.360000 --> 0:13:50.020000
 actual web app pen test.

0:13:50.020000 --> 0:13:55.140000
 And that's what you'll be looking to do
 in the actual, in the other courses

0:13:55.140000 --> 0:13:56.540000
 within this learning path.

0:13:56.540000 --> 0:14:00.480000
 So you look at how to utilize, how to
 perform information gathering, how

0:14:00.480000 --> 0:14:05.420000
 to use web proxies, how to perform, you
 know, common attacks, SQL injection,

0:14:05.420000 --> 0:14:10.720000
 cross site scripting, and a plethora
 of other, you know, other types of

0:14:10.720000 --> 0:14:14.660000
 tests, all in alignment very closely
 to the web security testing guide.

0:14:14.660000 --> 0:14:19.720000
 But now we're going to turn our attention
 to the final phase of a pen

0:14:19.720000 --> 0:14:22.060000
 test. And that is the reporting, right?

0:14:22.060000 --> 0:14:25.800000
 So once you're done with the pen test,
 how do you put your findings into

0:14:25.800000 --> 0:14:29.640000
 a format that can be consumed
 by the actual client?

0:14:29.640000 --> 0:14:33.580000
 And with that, with that being said,
 that's going to be it for this video.

0:14:33.580000 --> 0:14:37.480000
 And I'll be seeing you in the
 final video of this course.