1
00:00:06,927 --> 00:00:08,280
- In 14, six, we're gonna be talking

2
00:00:08,280 --> 00:00:09,960
about application security.

3
00:00:09,960 --> 00:00:12,600
And then in 14 seven we'll
continue the discussion,

4
00:00:12,600 --> 00:00:14,880
and talk about secure coding.

5
00:00:14,880 --> 00:00:18,600
Application security is the
process of developing, adding,

6
00:00:18,600 --> 00:00:21,750
and testing security
features within applications,

7
00:00:21,750 --> 00:00:24,450
to minimize the risk
of unauthorized access.

8
00:00:24,450 --> 00:00:28,080
Confidentiality modification,
there's our integrity,

9
00:00:28,080 --> 00:00:30,630
and downtime on availability,

10
00:00:30,630 --> 00:00:32,943
or think of it as availability.

11
00:00:34,830 --> 00:00:37,560
Application security categories include,

12
00:00:37,560 --> 00:00:39,720
secure development and coding,

13
00:00:39,720 --> 00:00:41,490
code security testing,

14
00:00:41,490 --> 00:00:45,093
security and privacy controls and logging.

15
00:00:46,890 --> 00:00:49,140
So when we're thinking
about application security,

16
00:00:49,140 --> 00:00:50,250
we need to think about,

17
00:00:50,250 --> 00:00:52,200
where we're developing the application,

18
00:00:52,200 --> 00:00:56,430
where we're testing it,
where we are assessing it,

19
00:00:56,430 --> 00:00:59,190
and how we're getting
it out into production.

20
00:00:59,190 --> 00:01:01,950
And that whole process
of planning, scheduling,

21
00:01:01,950 --> 00:01:04,500
and controlling the movement of developed,

22
00:01:04,500 --> 00:01:08,163
or acquired code is
known as secure staging.

23
00:01:09,630 --> 00:01:13,080
Now, environment in this
context of secure staging,

24
00:01:13,080 --> 00:01:15,360
really refers to the host device,

25
00:01:15,360 --> 00:01:18,510
which could be physical or
virtual, and the network,

26
00:01:18,510 --> 00:01:21,213
including all of the
connectivity components.

27
00:01:22,260 --> 00:01:25,200
So let's look at the secure
staging environments.

28
00:01:25,200 --> 00:01:29,640
We have dev, test, stage, and prod.

29
00:01:29,640 --> 00:01:32,670
Dev stands for development,
test stands for test,

30
00:01:32,670 --> 00:01:35,070
stage stands for stage or staging,

31
00:01:35,070 --> 00:01:37,410
and prod stands for production.

32
00:01:37,410 --> 00:01:39,030
So let's look through each of these,

33
00:01:39,030 --> 00:01:40,773
secure staging environments.

34
00:01:41,700 --> 00:01:44,550
The dev environment is
used for code development,

35
00:01:44,550 --> 00:01:48,390
for proof of concept, for experimentation,

36
00:01:48,390 --> 00:01:51,150
for customization of acquired software,

37
00:01:51,150 --> 00:01:53,940
and for very early stage testing.

38
00:01:53,940 --> 00:01:55,980
A couple things about the dev environment,

39
00:01:55,980 --> 00:01:58,080
from a security standpoint.

40
00:01:58,080 --> 00:02:00,690
One, it's not trustworthy at all,

41
00:02:00,690 --> 00:02:03,840
so you wanna make sure that
it is not connected at all,

42
00:02:03,840 --> 00:02:07,680
to the actual production
or enterprise network.

43
00:02:07,680 --> 00:02:10,050
Two, it's not trustworthy.

44
00:02:10,050 --> 00:02:11,580
Same thing, right?

45
00:02:11,580 --> 00:02:12,413
In this case,

46
00:02:12,413 --> 00:02:15,990
you don't ever wanna be using
any kind of data, right,

47
00:02:15,990 --> 00:02:19,650
that you need to be protecting
or if if it was exposed,

48
00:02:19,650 --> 00:02:22,470
would have any problem
or any issue at all.

49
00:02:22,470 --> 00:02:25,260
So in a dev environment,
we always wanna use dummy,

50
00:02:25,260 --> 00:02:28,563
or de-identified or anonymized data.

51
00:02:29,550 --> 00:02:31,440
So that's what's happening in dev.

52
00:02:31,440 --> 00:02:34,590
Then our next phase is going to be test.

53
00:02:34,590 --> 00:02:37,920
Now the testing environment
is used to merge code,

54
00:02:37,920 --> 00:02:40,680
ensure quality, isolate bugs,

55
00:02:40,680 --> 00:02:43,290
and measure performance and functionality.

56
00:02:43,290 --> 00:02:45,270
And in the test environment
is where we usually

57
00:02:45,270 --> 00:02:47,940
have our UAT or user acceptance testing.

58
00:02:47,940 --> 00:02:50,130
That would be our alpha and beta testing.

59
00:02:50,130 --> 00:02:52,260
Alpha testing is usually
testing both features,

60
00:02:52,260 --> 00:02:55,410
and functionality, where
beta testing is looking at

61
00:02:55,410 --> 00:02:57,903
functionality of all of the features.

62
00:02:59,370 --> 00:03:01,950
The dev and test can be very iterative,

63
00:03:01,950 --> 00:03:04,969
and it can be in development
and go into test.

64
00:03:04,969 --> 00:03:07,110
And then maybe there's a lot of bad code,

65
00:03:07,110 --> 00:03:08,850
maybe there's a problem,
something missing,

66
00:03:08,850 --> 00:03:10,530
it could easily go right back into dev.

67
00:03:10,530 --> 00:03:13,860
So dev and test, very
iterative environments.

68
00:03:13,860 --> 00:03:15,810
Then we get to the staging environment.

69
00:03:15,810 --> 00:03:18,695
The staging environment is used
to ensure that applications

70
00:03:18,695 --> 00:03:21,780
are going to behave as
expected and confirm,

71
00:03:21,780 --> 00:03:26,160
that they don't adversely impact
any existing applications.

72
00:03:26,160 --> 00:03:29,043
So as much as possible,
our staging environment,

73
00:03:29,980 --> 00:03:31,740
should mimic our production environment.

74
00:03:31,740 --> 00:03:35,289
This is also where we can do
things like risk assessments,

75
00:03:35,289 --> 00:03:37,680
penetration testing,
vulnerability assessments,

76
00:03:37,680 --> 00:03:40,050
because we're going to be
putting those applications,

77
00:03:40,050 --> 00:03:42,900
on the type of systems
that we're actually using,

78
00:03:42,900 --> 00:03:44,800
out in the field or out in production.

79
00:03:46,080 --> 00:03:48,510
Then lastly, we get to prod
or production environment.

80
00:03:48,510 --> 00:03:50,850
And that's really the live
environment that hosts

81
00:03:50,850 --> 00:03:53,760
the application and it's
the endpoint in the release

82
00:03:53,760 --> 00:03:57,180
management process, but it's
not really the endpoint,

83
00:03:57,180 --> 00:03:59,520
of taking care of that application.

84
00:03:59,520 --> 00:04:03,723
You know, we have ongoing
maintenance and ongoing support.

85
00:04:07,560 --> 00:04:09,840
So just a couple of
other notes about prod,

86
00:04:09,840 --> 00:04:12,210
that our prod planning
should include deployment,

87
00:04:12,210 --> 00:04:16,530
maintenance, backup, and our
disaster recovery strategies.

88
00:04:16,530 --> 00:04:18,570
Our developers should never have rights,

89
00:04:18,570 --> 00:04:20,100
to the prod environment.

90
00:04:20,100 --> 00:04:22,200
We want a segregation of duties.

91
00:04:22,200 --> 00:04:24,450
And all new functionality and bug fixes,

92
00:04:24,450 --> 00:04:27,150
should go through the
release management cycle,

93
00:04:27,150 --> 00:04:29,400
before being deployed to prod.

94
00:04:29,400 --> 00:04:33,120
So meaning going through
dev and test and stage,

95
00:04:33,120 --> 00:04:37,320
if there is an emergency change,
sometimes there might be,

96
00:04:37,320 --> 00:04:38,760
if there is an emergency change,

97
00:04:38,760 --> 00:04:41,880
it should be subject to
change management procedures,

98
00:04:41,880 --> 00:04:44,010
and vulnerability identification,

99
00:04:44,010 --> 00:04:46,770
and management is an ongoing process.

100
00:04:46,770 --> 00:04:50,010
So when something's in prod,
even though we've developed it,

101
00:04:50,010 --> 00:04:51,840
or customized that application,

102
00:04:51,840 --> 00:04:55,080
we've always gotta be looking
for those new vulnerabilities

103
00:04:55,080 --> 00:04:57,540
and you know, any type
of updates or patches,

104
00:04:57,540 --> 00:04:58,833
that need to be released.

105
00:05:02,310 --> 00:05:05,700
So historically, there used
to be this real segregation,

106
00:05:05,700 --> 00:05:10,320
of developers and operations
people and security people,

107
00:05:10,320 --> 00:05:13,123
but we found that doesn't
work really well, right?

108
00:05:13,123 --> 00:05:14,640
That the best thing we
can do in an organization,

109
00:05:14,640 --> 00:05:17,027
is to have collaboration.

110
00:05:17,027 --> 00:05:19,020
And that's where SecDevOps comes in.

111
00:05:19,020 --> 00:05:20,460
That SecDevOps is short for,

112
00:05:20,460 --> 00:05:23,280
security, development, and operations,

113
00:05:23,280 --> 00:05:25,500
and the idea is that we're
promoting collaboration,

114
00:05:25,500 --> 00:05:28,530
between the development
team, the operations teams,

115
00:05:28,530 --> 00:05:30,213
and the security teams.

116
00:05:31,290 --> 00:05:35,550
The SecDevOps really emphasizes
the shared responsibility,

117
00:05:35,550 --> 00:05:37,440
of integrating security practices,

118
00:05:37,440 --> 00:05:40,050
throughout the full development lifecycle,

119
00:05:40,050 --> 00:05:42,540
ensuring that we're
talking about security,

120
00:05:42,540 --> 00:05:43,770
right from the very beginning.

121
00:05:43,770 --> 00:05:47,070
So security considerations
are incorporated early,

122
00:05:47,070 --> 00:05:49,830
and continuously through the cycle.

123
00:05:49,830 --> 00:05:52,830
Now for a developer, this
is pretty cool because,

124
00:05:52,830 --> 00:05:57,000
the SecDevOps approach enables
developers to learn more

125
00:05:57,000 --> 00:06:00,300
about what they're developing
and how it could be exploited.

126
00:06:00,300 --> 00:06:04,920
SecDevOps proactively
focuses on survivability,

127
00:06:04,920 --> 00:06:07,530
by providing this reliable software,

128
00:06:07,530 --> 00:06:09,960
with a reduced attack surface.

129
00:06:09,960 --> 00:06:12,570
And that's one of the most
concise ways of saying this.

130
00:06:12,570 --> 00:06:15,270
I love this, focuses on survivability,

131
00:06:15,270 --> 00:06:18,780
by providing reliable software
with reduced attack surface.

132
00:06:18,780 --> 00:06:19,880
That's pretty awesome.

133
00:06:21,240 --> 00:06:25,020
So let's talk through some
SecDevOps automation concepts.

134
00:06:25,020 --> 00:06:28,350
Security automation,
continuous integration,

135
00:06:28,350 --> 00:06:30,870
baseline and immutability.

136
00:06:30,870 --> 00:06:32,310
Have you heard immutability before?

137
00:06:32,310 --> 00:06:33,143
I think so.

138
00:06:34,410 --> 00:06:36,480
Security automation is automating attacks,

139
00:06:36,480 --> 00:06:38,070
against pre-production code,

140
00:06:38,070 --> 00:06:40,440
and then continuous vulnerability testing,

141
00:06:40,440 --> 00:06:41,910
against production code.

142
00:06:41,910 --> 00:06:44,550
So we're automating attacks
all the way through.

143
00:06:44,550 --> 00:06:46,860
And then we continue with
vulnerability attacks,

144
00:06:46,860 --> 00:06:48,870
or excuse me, vulnerability testing,

145
00:06:48,870 --> 00:06:50,973
even once we're into production.

146
00:06:52,200 --> 00:06:54,690
Continuous integration
is the continuous merging

147
00:06:54,690 --> 00:06:56,760
of source code by all of the developers.

148
00:06:56,760 --> 00:07:00,390
And if a failure or a
fault or a bug is seen,

149
00:07:00,390 --> 00:07:03,930
the team is expected to stop, refocus,

150
00:07:03,930 --> 00:07:08,520
and fix the build before making
any additional code changes.

151
00:07:08,520 --> 00:07:10,200
So they can't say, oh
yeah, we know that's there.

152
00:07:10,200 --> 00:07:11,033
We'll get back to it.

153
00:07:11,033 --> 00:07:14,493
It's like, nope, everybody
stops, fix it before we go on.

154
00:07:15,540 --> 00:07:18,420
Baseline is just a consistent
agreed upon version,

155
00:07:18,420 --> 00:07:19,680
of the software that serves

156
00:07:19,680 --> 00:07:22,410
as the basis for future development.

157
00:07:22,410 --> 00:07:25,780
And immutability, again,
is the image of a system,

158
00:07:25,780 --> 00:07:29,580
pre-configured to a desired
known good state, right?

159
00:07:29,580 --> 00:07:33,993
Succinctly using automation
to replace rather than fix.

160
00:07:35,550 --> 00:07:38,520
So we start testing early
in the cycle, right?

161
00:07:38,520 --> 00:07:42,510
And right at the very beginning
at the source code, right?

162
00:07:42,510 --> 00:07:43,740
We can start doing what's known as,

163
00:07:43,740 --> 00:07:47,823
static application
security testing or SAST.

164
00:07:47,823 --> 00:07:50,790
Now, SAST is a testing methodology,

165
00:07:50,790 --> 00:07:55,200
that analyzes source code to
find security vulnerabilities.

166
00:07:55,200 --> 00:07:56,910
Now it takes place very, very early,

167
00:07:56,910 --> 00:07:59,010
in the software development lifecycle,

168
00:07:59,010 --> 00:08:01,710
because it doesn't require
a working application,

169
00:08:01,710 --> 00:08:05,190
and it can take place without
the code being executed.

170
00:08:05,190 --> 00:08:06,990
It can scan the application,

171
00:08:06,990 --> 00:08:10,110
before the code is even compiled.

172
00:08:10,110 --> 00:08:14,160
Now, SAST tools give de
developers real-time feedback,

173
00:08:14,160 --> 00:08:16,440
as they code helping them fix issues,

174
00:08:16,440 --> 00:08:17,730
before they pass the code,

175
00:08:17,730 --> 00:08:19,803
onto the next phase of development.

176
00:08:21,840 --> 00:08:25,350
Now, DAST, which is dynamic
application security testing,

177
00:08:25,350 --> 00:08:27,780
is a method of application
security testing,

178
00:08:27,780 --> 00:08:31,020
that examines a running application.

179
00:08:31,020 --> 00:08:34,110
The DAST works by simulating
automated attacks,

180
00:08:34,110 --> 00:08:36,450
on the application, really behaving like,

181
00:08:36,450 --> 00:08:38,160
they're the malicious attacker.

182
00:08:38,160 --> 00:08:40,200
And the goal is to find outcome,

183
00:08:40,200 --> 00:08:42,598
or results that were not expected.

184
00:08:42,598 --> 00:08:43,860
It's like, oh, we didn't
think that would happen.

185
00:08:43,860 --> 00:08:47,070
And that could be used by
attackers to compromise

186
00:08:47,070 --> 00:08:50,130
an application like
maybe a race condition.

187
00:08:50,130 --> 00:08:53,580
The DAST tools include
web and API scanning,

188
00:08:53,580 --> 00:08:55,860
pen testing, fuzzing,

189
00:08:55,860 --> 00:08:59,340
and interactive application
security testing.

190
00:08:59,340 --> 00:09:00,360
Now let's talk about fuzzing,

191
00:09:00,360 --> 00:09:02,700
'cause it always seems
to come up on the exam.

192
00:09:02,700 --> 00:09:05,820
Fuzz testing or fuzzing
is an automated testing

193
00:09:05,820 --> 00:09:07,980
technique used to discover coding errors,

194
00:09:07,980 --> 00:09:10,650
and security loopholes by inputting well,

195
00:09:10,650 --> 00:09:13,050
what's known as fuzz, which is invalid,

196
00:09:13,050 --> 00:09:15,420
unexpected, or semi-random data.

197
00:09:15,420 --> 00:09:18,123
And then monitoring the
application response.

198
00:09:19,650 --> 00:09:22,290
So lots of testing going
on, really incumbent,

199
00:09:22,290 --> 00:09:25,920
kind of understand whether
we're developing software,

200
00:09:25,920 --> 00:09:28,320
or we've acquired software
and we're customizing it.

201
00:09:28,320 --> 00:09:30,810
We always wanna make sure
that we have good, solid,

202
00:09:30,810 --> 00:09:32,883
secure software in our environment.

203
00:09:34,230 --> 00:09:36,690
That my friends, brings us
to a three second challenge.

204
00:09:36,690 --> 00:09:38,820
Five challenge questions,
three seconds each.

205
00:09:38,820 --> 00:09:40,520
You know how to do this, let's go.

206
00:09:41,520 --> 00:09:43,380
The environment used for experimentation,

207
00:09:43,380 --> 00:09:46,233
proof of concept and code development.

208
00:09:47,430 --> 00:09:49,260
1, 2, 3.

209
00:09:49,260 --> 00:09:52,800
This is the one I said was
really pretty dangerous.

210
00:09:52,800 --> 00:09:54,210
1, 2, 3,

211
00:09:54,210 --> 00:09:55,043
that's dev.

212
00:09:56,850 --> 00:09:58,080
Maybe I didn't say it was dangerous.

213
00:09:58,080 --> 00:10:00,130
I think I just said it was untrustworthy.

214
00:10:02,520 --> 00:10:04,980
This environment should mirror
the production environment.

215
00:10:04,980 --> 00:10:06,840
So what's this environment gonna be?

216
00:10:06,840 --> 00:10:08,343
1, 2, 3.

217
00:10:09,540 --> 00:10:11,043
And that's gonna be stage.

218
00:10:12,780 --> 00:10:14,760
The principle of using automation,

219
00:10:14,760 --> 00:10:17,940
to replace rather than fix.

220
00:10:17,940 --> 00:10:19,230
1, 2, 3.

221
00:10:19,230 --> 00:10:21,780
Everybody's gonna get this one right.

222
00:10:21,780 --> 00:10:22,773
Immutability.

223
00:10:24,090 --> 00:10:27,810
Number four, testing method
that analyzes source code,

224
00:10:27,810 --> 00:10:30,600
to find security vulnerabilities.

225
00:10:30,600 --> 00:10:32,283
1, 2, 3.

226
00:10:33,150 --> 00:10:34,830
That's gonna be SAST,

227
00:10:34,830 --> 00:10:37,683
or static application security testing.

228
00:10:38,820 --> 00:10:40,890
And then here's the one
with the silly name.

229
00:10:40,890 --> 00:10:43,830
Automated testing technique
used to discover coding errors,

230
00:10:43,830 --> 00:10:47,010
and security loopholes
by inputting invalid,

231
00:10:47,010 --> 00:10:50,280
unexpected or semi-random data.

232
00:10:50,280 --> 00:10:51,783
1, 2, 3.

233
00:10:53,280 --> 00:10:54,720
Fuzzing.

234
00:10:54,720 --> 00:10:56,970
All right, that brings us
to a security and action,

235
00:10:56,970 --> 00:10:58,413
about secure staging.

236
00:10:59,490 --> 00:11:02,250
Your organization is
under immense pressure,

237
00:11:02,250 --> 00:11:04,830
to launch an online retail store.

238
00:11:04,830 --> 00:11:08,430
The marketing team has been
advertising the launch date.

239
00:11:08,430 --> 00:11:10,950
In-house developers have
been working day and night,

240
00:11:10,950 --> 00:11:14,691
to write and test the code, and
they're reasonably confident

241
00:11:14,691 --> 00:11:17,220
that everything is set to go.

242
00:11:17,220 --> 00:11:20,070
So given the time crunch,
it's been suggested,

243
00:11:20,070 --> 00:11:22,500
that the site go right into production,

244
00:11:22,500 --> 00:11:24,720
from the testing environment.

245
00:11:24,720 --> 00:11:27,270
All right, as a security practitioner,

246
00:11:27,270 --> 00:11:29,403
would you support such a move?

247
00:11:30,360 --> 00:11:33,960
Okay, so, or under just this
incredible pressure, right?

248
00:11:33,960 --> 00:11:36,240
To get this online retail store out.

249
00:11:36,240 --> 00:11:38,550
So this online retail store, right?

250
00:11:38,550 --> 00:11:40,597
We're gonna have products,

251
00:11:40,597 --> 00:11:42,180
it's gonna have our
reputation right out there.

252
00:11:42,180 --> 00:11:44,220
We're probably gonna
take credit cards, right,

253
00:11:44,220 --> 00:11:46,410
'cause we're gonna have to have payment.

254
00:11:46,410 --> 00:11:48,390
You know, we've been advertising,
the marketing department

255
00:11:48,390 --> 00:11:50,833
has been advertising the launch date.

256
00:11:50,833 --> 00:11:52,230
So everybody knows when it's coming,

257
00:11:52,230 --> 00:11:54,240
the in-house developers are exhausted.

258
00:11:54,240 --> 00:11:56,310
They've been working
day and night to write,

259
00:11:56,310 --> 00:11:59,760
and test the code and they
say, well, you know what?

260
00:11:59,760 --> 00:12:00,810
That we like our code.

261
00:12:00,810 --> 00:12:03,750
You know, we're reasonably confident,

262
00:12:03,750 --> 00:12:05,283
that everything is set to go.

263
00:12:06,300 --> 00:12:07,980
So given the time crunch,

264
00:12:07,980 --> 00:12:10,170
suggest to the site go
right into production,

265
00:12:10,170 --> 00:12:14,310
meaning going right from test
to prod, what are we skipping?

266
00:12:14,310 --> 00:12:15,810
We're skipping stage.

267
00:12:15,810 --> 00:12:17,740
Are you gonna support such a move?

268
00:12:17,740 --> 00:12:19,500
Put me on pause for a moment,

269
00:12:19,500 --> 00:12:21,573
jot down your response and come on back.

270
00:12:23,520 --> 00:12:28,140
No, no and no, this is a
really bad idea, right,

271
00:12:28,140 --> 00:12:30,840
to go right from test to production,

272
00:12:30,840 --> 00:12:34,170
is a really, really, really bad idea.

273
00:12:34,170 --> 00:12:37,260
A transition from test to prod is risky.

274
00:12:37,260 --> 00:12:39,420
It could result in a negative launch,

275
00:12:39,420 --> 00:12:41,940
might be reputation damage,
might be financial damage,

276
00:12:41,940 --> 00:12:44,310
might even be credit card compromise.

277
00:12:44,310 --> 00:12:48,000
You know, if the site isn't
functional or exposes customers,

278
00:12:48,000 --> 00:12:51,600
to security faults and or
has performance issues,

279
00:12:51,600 --> 00:12:53,880
you're really much better off waiting,

280
00:12:53,880 --> 00:12:55,653
than having all that happen.

281
00:12:56,730 --> 00:12:59,040
The test environment does not,

282
00:12:59,040 --> 00:13:01,500
does not, mirror the prod environment.

283
00:13:01,500 --> 00:13:04,776
The stage environment is
where our kind of real world,

284
00:13:04,776 --> 00:13:06,960
security testing should always take place.

285
00:13:06,960 --> 00:13:09,030
That's where we can do
our dynamic application,

286
00:13:09,030 --> 00:13:11,790
security testing, our penetration testing,

287
00:13:11,790 --> 00:13:13,650
our vulnerability assessment,

288
00:13:13,650 --> 00:13:16,740
as well as testing any
rollback procedures.

289
00:13:16,740 --> 00:13:18,840
So the answer, really succinctly,

290
00:13:18,840 --> 00:13:21,540
was, should you support such a move?

291
00:13:21,540 --> 00:13:22,740
No. (laughs)

292
00:13:22,740 --> 00:13:26,010
And being able to really
stand up and fight the trend,

293
00:13:26,010 --> 00:13:27,930
you know that's tough to do,

294
00:13:27,930 --> 00:13:30,390
and you're gonna find
yourself in this situation,

295
00:13:30,390 --> 00:13:32,910
at some point where from
a business perspective,

296
00:13:32,910 --> 00:13:35,220
they just wanna get something done,

297
00:13:35,220 --> 00:13:37,500
and you're the one to say, no.

298
00:13:37,500 --> 00:13:40,156
But what's really important there is,

299
00:13:40,156 --> 00:13:41,370
that you can explain the why,

300
00:13:41,370 --> 00:13:44,220
not just say no, but explain why,

301
00:13:44,220 --> 00:13:47,340
and why your reasoning
is strategically aligned,

302
00:13:47,340 --> 00:13:50,130
with the good of the organization.

303
00:13:50,130 --> 00:13:53,340
That my friends, is
security in action, right?

304
00:13:53,340 --> 00:13:55,470
There is your word cloud.

305
00:13:55,470 --> 00:13:56,940
You know what to do.

306
00:13:56,940 --> 00:13:58,390
I'll see you the next lesson.