WEBVTT

1
00:00:00.000 --> 00:00:01.290
In this lesson,

2
00:00:01.290 --> 00:00:04.350
we will learn about pre-deployment testing.

3
00:00:04.350 --> 00:00:08.220
Pre-deployment testing is used to evaluate software

4
00:00:08.220 --> 00:00:11.490
for security vulnerabilities, functional issues,

5
00:00:11.490 --> 00:00:13.410
and performance concerns

6
00:00:13.410 --> 00:00:15.540
before the software is released

7
00:00:15.540 --> 00:00:17.280
into a live environment.

8
00:00:17.280 --> 00:00:22.280
This includes Static Application Security Testing, or SAST,

9
00:00:22.350 --> 00:00:26.100
Dynamic Application Security Testing, or DAST,

10
00:00:26.100 --> 00:00:30.870
and Interactive Application Security Testing, or IAST.

11
00:00:30.870 --> 00:00:34.290
To better visualize the SAST, DAST,

12
00:00:34.290 --> 00:00:38.160
and IAST aspects of pre-deployment testing,

13
00:00:38.160 --> 00:00:40.710
let's think about preparing your car

14
00:00:40.710 --> 00:00:42.480
for a long road trip.

15
00:00:42.480 --> 00:00:46.290
Static Application Security Testing, or SAST,

16
00:00:46.290 --> 00:00:48.600
is like checking the car's engine

17
00:00:48.600 --> 00:00:50.610
before starting the trip.

18
00:00:50.610 --> 00:00:52.800
So before hitting the road,

19
00:00:52.800 --> 00:00:54.390
you inspect the engine

20
00:00:54.390 --> 00:00:57.000
to ensure everything is in good shape.

21
00:00:57.000 --> 00:00:59.430
This basic check is done

22
00:00:59.430 --> 00:01:01.800
to catch any developing problems

23
00:01:01.800 --> 00:01:03.390
such as oil leaks,

24
00:01:03.390 --> 00:01:05.310
which could lead to a breakdown.

25
00:01:05.310 --> 00:01:09.090
Similarly, Static Application Security Testing

26
00:01:09.090 --> 00:01:12.240
inspects developer code while it's static,

27
00:01:12.240 --> 00:01:15.060
identifying vulnerabilities early

28
00:01:15.060 --> 00:01:18.510
to avoid issues when the application runs.

29
00:01:18.510 --> 00:01:23.010
Next, Dynamic Application Security Testing, or DAST,

30
00:01:23.010 --> 00:01:24.540
is like taking the car

31
00:01:24.540 --> 00:01:27.060
for a pre-road trip test drive.

32
00:01:27.060 --> 00:01:30.570
During the drive, you observe how the car performs,

33
00:01:30.570 --> 00:01:32.580
paying attention to how it handles

34
00:01:32.580 --> 00:01:35.430
and responds in real conditions.

35
00:01:35.430 --> 00:01:39.870
Similarly, DAST tests an application while it's running,

36
00:01:39.870 --> 00:01:43.020
identifying vulnerabilities that only appear

37
00:01:43.020 --> 00:01:44.790
in a runtime environment,

38
00:01:44.790 --> 00:01:48.480
much like checking the car's performance in motion.

39
00:01:48.480 --> 00:01:53.310
Finally, Interactive Application Security Testing, or IAST,

40
00:01:53.310 --> 00:01:56.940
is like having a realtime diagnostic system

41
00:01:56.940 --> 00:01:58.860
installed in your car.

42
00:01:58.860 --> 00:02:02.430
Your diagnostic system continuously monitors

43
00:02:02.430 --> 00:02:03.900
the car's performance,

44
00:02:03.900 --> 00:02:06.870
providing realtime alerts for issues

45
00:02:06.870 --> 00:02:10.260
like engine trouble or low tire pressure.

46
00:02:10.260 --> 00:02:14.880
In the same way, IAST provides ongoing feedback

47
00:02:14.880 --> 00:02:16.920
during application testing,

48
00:02:16.920 --> 00:02:21.060
monitoring both the code and system behavior

49
00:02:21.060 --> 00:02:25.740
to detect vulnerabilities as they arise in real time.

50
00:02:25.740 --> 00:02:29.010
So now let's learn even more

51
00:02:29.010 --> 00:02:32.160
about Static Application Security Testing,

52
00:02:32.160 --> 00:02:34.860
Dynamic Application Security Testing,

53
00:02:34.860 --> 00:02:38.430
and Interactive Application Security Testing.

54
00:02:38.430 --> 00:02:43.430
First, we have Static Application Security Testing, or SAST.

55
00:02:44.100 --> 00:02:49.100
SAST is used to analyze a software application's source code

56
00:02:49.170 --> 00:02:51.690
or binaries for vulnerabilities

57
00:02:51.690 --> 00:02:54.240
without executing the software.

58
00:02:54.240 --> 00:02:56.850
The primary objective of SAST

59
00:02:56.850 --> 00:03:00.420
is to identify potential security weaknesses

60
00:03:00.420 --> 00:03:04.860
such as coding flaws early in the development process.

61
00:03:04.860 --> 00:03:06.960
The detection of weaknesses early

62
00:03:06.960 --> 00:03:08.820
in the development process

63
00:03:08.820 --> 00:03:11.220
allows issues to be resolved

64
00:03:11.220 --> 00:03:13.680
before the software is deployed.

65
00:03:13.680 --> 00:03:17.250
Overall, Static Application Security Testing

66
00:03:17.250 --> 00:03:20.070
can be conducted through automated tools

67
00:03:20.070 --> 00:03:22.170
and manual code reviews,

68
00:03:22.170 --> 00:03:25.410
both of which are integral to securing software.

69
00:03:25.410 --> 00:03:30.270
Automated SAST tools such as check marks, Veracode,

70
00:03:30.270 --> 00:03:33.780
and Fortify automatically scan code bases

71
00:03:33.780 --> 00:03:37.740
for common vulnerabilities like SQL injection,

72
00:03:37.740 --> 00:03:41.010
Cross-site Scripting, buffer overflows,

73
00:03:41.010 --> 00:03:43.440
and improper error handling.

74
00:03:43.440 --> 00:03:46.140
For example, if a developer uses

75
00:03:46.140 --> 00:03:50.970
the insecure C language function, strcpy,

76
00:03:50.970 --> 00:03:54.300
an automated SAST tool can flag it

77
00:03:54.300 --> 00:03:59.223
and recommend a more secure alternative like strncpy,

78
00:04:00.060 --> 00:04:03.120
because the strcpy function

79
00:04:03.120 --> 00:04:05.580
doesn't check the size of the input,

80
00:04:05.580 --> 00:04:08.820
which can lead to potential buffer overflows.

81
00:04:08.820 --> 00:04:13.140
Next, manual code review is another key component

82
00:04:13.140 --> 00:04:16.230
of Static Application Security Testing.

83
00:04:16.230 --> 00:04:18.060
In a manual code review,

84
00:04:18.060 --> 00:04:21.810
developers carefully examine someone else's code

85
00:04:21.810 --> 00:04:26.040
for vulnerabilities that automated tools might miss.

86
00:04:26.040 --> 00:04:29.190
So while an automated SAST tool

87
00:04:29.190 --> 00:04:31.740
might flag obvious issues,

88
00:04:31.740 --> 00:04:36.150
manual code reviews can catch more complex problems

89
00:04:36.150 --> 00:04:38.370
such as logical flaws,

90
00:04:38.370 --> 00:04:41.340
improper error handling in edge cases,

91
00:04:41.340 --> 00:04:45.180
or insecure use of cryptographic libraries.

92
00:04:45.180 --> 00:04:46.830
During a manual review,

93
00:04:46.830 --> 00:04:48.540
a reviewer might spot

94
00:04:48.540 --> 00:04:53.130
a non-secure C language function like sprintf,

95
00:04:53.130 --> 00:04:56.430
which can also cause buffer overflows.

96
00:04:56.430 --> 00:04:59.340
Then the manual reviewer might suggest

97
00:04:59.340 --> 00:05:03.870
using the snprintf function instead

98
00:05:03.870 --> 00:05:07.080
because it will not cause buffer overflows.

99
00:05:07.080 --> 00:05:09.720
But while SAST is powerful,

100
00:05:09.720 --> 00:05:12.030
it also has its challenges.

101
00:05:12.030 --> 00:05:15.840
One challenge is the occurrence of false positives.

102
00:05:15.840 --> 00:05:17.460
A false positive occurs

103
00:05:17.460 --> 00:05:20.130
when a tool flags potential issues

104
00:05:20.130 --> 00:05:22.860
that aren't actual vulnerabilities.

105
00:05:22.860 --> 00:05:25.020
This can frustrate developers

106
00:05:25.020 --> 00:05:27.870
and take a lot of time to investigate.

107
00:05:27.870 --> 00:05:31.380
Additionally, Static Application Security Testing,

108
00:05:31.380 --> 00:05:33.990
whether manual or automated,

109
00:05:33.990 --> 00:05:37.230
can miss vulnerabilities that only manifest

110
00:05:37.230 --> 00:05:38.940
when the application is running,

111
00:05:38.940 --> 00:05:42.030
such as issues related to the system's environment

112
00:05:42.030 --> 00:05:44.040
or dynamic logic flows.

113
00:05:44.040 --> 00:05:47.910
Second, we have Dynamic Application Security Testing,

114
00:05:47.910 --> 00:05:49.140
or DAST.

115
00:05:49.140 --> 00:05:52.890
DAST assesses the security of a running application

116
00:05:52.890 --> 00:05:55.740
by simulating attacks in real time

117
00:05:55.740 --> 00:05:58.710
to identify potential vulnerabilities.

118
00:05:58.710 --> 00:06:03.030
The main objective of Dynamic Application Security Testing

119
00:06:03.030 --> 00:06:05.340
is to find flaws that occur

120
00:06:05.340 --> 00:06:07.890
while the application is operating.

121
00:06:07.890 --> 00:06:12.240
For example, injection flaws like SQL injection

122
00:06:12.240 --> 00:06:15.030
or Cross-site Scripting can be identified

123
00:06:15.030 --> 00:06:17.400
by inserting a harmful code

124
00:06:17.400 --> 00:06:20.640
into input fields of a web application.

125
00:06:20.640 --> 00:06:24.510
Similarly, DAST can help uncover weaknesses

126
00:06:24.510 --> 00:06:26.760
in authentication processes

127
00:06:26.760 --> 00:06:28.860
where an attacker might be able

128
00:06:28.860 --> 00:06:31.140
to bypass login mechanisms

129
00:06:31.140 --> 00:06:35.160
due to improper validation or session management.

130
00:06:35.160 --> 00:06:38.370
There are a variety of tools available

131
00:06:38.370 --> 00:06:42.000
to perform Dynamic Application Security Testing,

132
00:06:42.000 --> 00:06:44.430
including open source solutions

133
00:06:44.430 --> 00:06:47.310
like the Zed Attack Proxy, or ZAP,

134
00:06:47.310 --> 00:06:49.680
and commercial ones like Burp Suite.

135
00:06:49.680 --> 00:06:52.560
Another notable tool is the Peach Fuzzer,

136
00:06:52.560 --> 00:06:55.170
which specializes in fuzzing.

137
00:06:55.170 --> 00:06:58.230
Fuzzing is a technique where a large number

138
00:06:58.230 --> 00:07:00.990
of random or unexpected inputs

139
00:07:00.990 --> 00:07:02.790
are sent to the application

140
00:07:02.790 --> 00:07:06.210
to uncover crashes and security flaws.

141
00:07:06.210 --> 00:07:10.710
For example, if an application processes uploaded files,

142
00:07:10.710 --> 00:07:14.280
the Peach Fuzzer can send a range of malformed

143
00:07:14.280 --> 00:07:17.310
or unexpected file types and data

144
00:07:17.310 --> 00:07:19.650
to observe how the system handles

145
00:07:19.650 --> 00:07:22.710
and processes each of these inputs.

146
00:07:22.710 --> 00:07:26.520
If the application crashes or behaves erratically,

147
00:07:26.520 --> 00:07:29.250
it may indicate a vulnerability

148
00:07:29.250 --> 00:07:31.800
that could be exploited by an attacker.

149
00:07:31.800 --> 00:07:36.210
So Dynamic Application Security Testing is powerful,

150
00:07:36.210 --> 00:07:38.910
but it also has some weaknesses.

151
00:07:38.910 --> 00:07:43.770
Since DAST only tests the application from the outside,

152
00:07:43.770 --> 00:07:46.320
it might miss internal vulnerabilities

153
00:07:46.320 --> 00:07:50.430
or logic flows that can only be seen in the source code.

154
00:07:50.430 --> 00:07:54.030
Also, like Static Application Security Testing,

155
00:07:54.030 --> 00:07:56.370
Dynamic Application Security Testing

156
00:07:56.370 --> 00:07:59.130
can also generate false positives

157
00:07:59.130 --> 00:08:01.260
by flagging potential issues

158
00:08:01.260 --> 00:08:03.720
that are not actually exploitable,

159
00:08:03.720 --> 00:08:06.780
and DAST can be less effective

160
00:08:06.780 --> 00:08:09.120
against complex vulnerabilities

161
00:08:09.120 --> 00:08:11.610
that require a deeper understanding

162
00:08:11.610 --> 00:08:14.520
of the application's business logic.

163
00:08:14.520 --> 00:08:16.410
Third and finally,

164
00:08:16.410 --> 00:08:21.410
we have Interactive Application Security Testing, or IAST.

165
00:08:21.690 --> 00:08:23.790
IAST is a hybrid approach

166
00:08:23.790 --> 00:08:25.890
that combines the strengths

167
00:08:25.890 --> 00:08:29.130
of both Static Application Security Testing

168
00:08:29.130 --> 00:08:32.430
and Dynamic Application Security Testing.

169
00:08:32.430 --> 00:08:35.190
The primary objective of IAST,

170
00:08:35.190 --> 00:08:38.580
or Interactive Application Security Testing,

171
00:08:38.580 --> 00:08:42.510
is to offer realtime feedback on vulnerabilities

172
00:08:42.510 --> 00:08:44.640
while an application is running,

173
00:08:44.640 --> 00:08:47.760
unlike Static Application Security Testing,

174
00:08:47.760 --> 00:08:50.580
which only examines static code,

175
00:08:50.580 --> 00:08:53.640
or Dynamic Application Security Testing,

176
00:08:53.640 --> 00:08:56.370
which interacts with running applications.

177
00:08:56.370 --> 00:08:58.230
From an external viewpoint,

178
00:08:58.230 --> 00:09:01.290
Interactive Application Security Testing

179
00:09:01.290 --> 00:09:05.130
works by integrating directly with the application

180
00:09:05.130 --> 00:09:06.690
as it operates.

181
00:09:06.690 --> 00:09:10.770
This enables IAST to analyze both the code

182
00:09:10.770 --> 00:09:13.920
and runtime behaviors simultaneously,

183
00:09:13.920 --> 00:09:17.220
providing a more comprehensive assessment

184
00:09:17.220 --> 00:09:19.380
of security issues.

185
00:09:19.380 --> 00:09:21.750
For example, in the development

186
00:09:21.750 --> 00:09:24.270
of a new e-commerce platform,

187
00:09:24.270 --> 00:09:27.930
developers could use an IAST tool

188
00:09:27.930 --> 00:09:30.570
while running their functional tests.

189
00:09:30.570 --> 00:09:32.730
As they interact with different parts

190
00:09:32.730 --> 00:09:34.140
of the application

191
00:09:34.140 --> 00:09:36.120
such as the payment gateway

192
00:09:36.120 --> 00:09:38.010
or user registration,

193
00:09:38.010 --> 00:09:41.100
the interactive application security tool

194
00:09:41.100 --> 00:09:43.800
could analyze the application's behavior

195
00:09:43.800 --> 00:09:47.250
and highlight security risks in real time.

196
00:09:47.250 --> 00:09:51.390
The IAST tool might identify vulnerabilities

197
00:09:51.390 --> 00:09:54.000
like improper input validation,

198
00:09:54.000 --> 00:09:58.320
where the application doesn't properly check user inputs,

199
00:09:58.320 --> 00:10:01.020
or insecure data storage,

200
00:10:01.020 --> 00:10:02.790
where sensitive information

201
00:10:02.790 --> 00:10:06.480
such as passwords are not encrypted correctly.

202
00:10:06.480 --> 00:10:08.820
Because the feedback is immediate,

203
00:10:08.820 --> 00:10:12.510
developers can address these issues on the spot,

204
00:10:12.510 --> 00:10:14.820
making it easier to fix problems

205
00:10:14.820 --> 00:10:17.730
before the application goes live.

206
00:10:17.730 --> 00:10:20.580
There are several tools available

207
00:10:20.580 --> 00:10:23.760
for Interactive Application Security Testing,

208
00:10:23.760 --> 00:10:28.230
including contrast security and Veracode.

209
00:10:28.230 --> 00:10:31.020
These tools integrate seamlessly

210
00:10:31.020 --> 00:10:33.420
into the development environment,

211
00:10:33.420 --> 00:10:36.870
providing developers with actionable insights

212
00:10:36.870 --> 00:10:40.470
as they test and build the application.

213
00:10:40.470 --> 00:10:44.670
This real time feedback reduces the time it takes

214
00:10:44.670 --> 00:10:47.610
to discover and fix vulnerabilities

215
00:10:47.610 --> 00:10:51.240
compared to traditional security testing approaches.

216
00:10:51.240 --> 00:10:54.870
However, Interactive Application Security Testing

217
00:10:54.870 --> 00:10:57.360
is not without its weaknesses.

218
00:10:57.360 --> 00:11:01.290
Since it relies on the application being actively tested,

219
00:11:01.290 --> 00:11:04.800
it might not uncover all vulnerabilities

220
00:11:04.800 --> 00:11:08.100
unless the application is thoroughly exercised

221
00:11:08.100 --> 00:11:09.480
during the testing.

222
00:11:09.480 --> 00:11:12.450
This means that any parts of the application

223
00:11:12.450 --> 00:11:15.300
that are not tested go unchecked.

224
00:11:15.300 --> 00:11:20.300
Additionally, IAST tools may have performance impacts

225
00:11:20.370 --> 00:11:22.980
on the running application itself,

226
00:11:22.980 --> 00:11:25.260
slowing down functional tests

227
00:11:25.260 --> 00:11:28.740
or affecting the overall development workflow.

228
00:11:28.740 --> 00:11:32.280
So remember, pre-deployment testing

229
00:11:32.280 --> 00:11:35.850
is used to identify security vulnerabilities,

230
00:11:35.850 --> 00:11:39.450
functional issues, and performance concerns

231
00:11:39.450 --> 00:11:43.650
before software is released into a live environment.

232
00:11:43.650 --> 00:11:46.110
This testing includes techniques

233
00:11:46.110 --> 00:11:50.250
like Static Application Security Testing, or SAST,

234
00:11:50.250 --> 00:11:54.420
Dynamic Application Security Testing, or DAST,

235
00:11:54.420 --> 00:11:59.420
and Interactive Application Security Testing, or IAST.

236
00:11:59.670 --> 00:12:02.250
Static Application Security Testing

237
00:12:02.250 --> 00:12:06.480
analyzes the source code without running the application,

238
00:12:06.480 --> 00:12:09.150
Dynamic Application Security Testing

239
00:12:09.150 --> 00:12:12.300
evaluates security during runtime,

240
00:12:12.300 --> 00:12:15.720
and Interactive Application Security Testing

241
00:12:15.720 --> 00:12:19.740
combines both approaches for realtime feedback.

242
00:12:19.740 --> 00:12:23.190
Each method has its own strengths and weaknesses.

243
00:12:23.190 --> 00:12:28.190
Using a combination of SAST, DAST, and IAST

244
00:12:28.350 --> 00:12:30.180
is the best approach

245
00:12:30.180 --> 00:12:33.063
for comprehensive pre-deployment testing.