1
00:00:00,300 --> 00:00:04,000
Building an application security
program is really about ensuring

2
00:00:04,000 --> 00:00:07,600
that security is built into that
software development life cycle,

3
00:00:07,900 --> 00:00:10,800
but not just into the software 
development lifecycle. 

4
00:00:10,800 --> 00:00:14,500
But also, how do we respond to 
vulnerabilities or findings as 

5
00:00:14,500 --> 00:00:17,100
we move along? 
That development pipeline all 

6
00:00:17,100 --> 00:00:19,400
the way into the operational 
environment. 

7
00:00:24,400 --> 00:00:27,100
Hey everyone. 
My name is Henry Surya with 

8
00:00:27,100 --> 00:00:30,500
Robin. 
And you're listening to the 

9
00:00:30,500 --> 00:00:33,700
technology, you know, podcast 
the show where I'll be bringing 

10
00:00:33,700 --> 00:00:36,800
you the greatest technical 
leaders practitioners and 

11
00:00:36,800 --> 00:00:40,600
thought leaders in the industry 
to discuss about their Journey 

12
00:00:40,800 --> 00:00:45,300
ideas and practices that we all 
can learn and apply to build a 

13
00:00:45,300 --> 00:00:48,900
highly performing technical team
and to make an impact in your 

14
00:00:48,900 --> 00:00:52,100
personal work. 
So let's dive into our Journal. 

15
00:00:57,100 --> 00:00:58,800
Hey everyone, welcome to the 
Tecla. 

16
00:00:59,000 --> 00:01:01,300
You know, podcast the podcast 
where you can learn about 

17
00:01:01,300 --> 00:01:03,300
technical leadership and 
Excellence from my 

18
00:01:03,300 --> 00:01:05,600
conversations, with great 
thought leaders in the tech 

19
00:01:05,600 --> 00:01:08,000
industry. 
If you haven't, please follow 

20
00:01:08,000 --> 00:01:10,900
the show on your podcast app and
social media on LinkedIn. 

21
00:01:10,900 --> 00:01:13,500
Twitter and Instagram for video 
content. 

22
00:01:13,500 --> 00:01:16,600
Steckle Journal is also now 
available on YouTube and 

23
00:01:16,600 --> 00:01:18,700
Tick-Tock. 
And if you want to support my 

24
00:01:18,700 --> 00:01:20,800
work by me, a coffee at 
technology. 

25
00:01:20,800 --> 00:01:23,300
Not deaths. 
Last tip or subscribe as a 

26
00:01:23,300 --> 00:01:26,400
patron at technology node. 
Death, /, Patron. 

27
00:01:27,700 --> 00:01:30,500
My guest for today's episode is 
Derek Fisher. 

28
00:01:31,000 --> 00:01:33,900
Derek is the author of 
application security, program 

29
00:01:33,900 --> 00:01:37,800
handbook, and also a security 
instructor at Temple University,

30
00:01:38,300 --> 00:01:41,600
in this episode, direct shared 
about building, an application, 

31
00:01:41,600 --> 00:01:44,200
security program, and how to 
implement it in our 

32
00:01:44,200 --> 00:01:46,900
organization. 
First, we discussed some 

33
00:01:46,900 --> 00:01:50,900
security fundamental, concepts 
such as shift, left, CIA Triad 

34
00:01:50,900 --> 00:01:54,500
and threat modeling direct then 
outline how to start an 

35
00:01:54,500 --> 00:01:57,300
application security program and
measure the programs. 

36
00:01:57,400 --> 00:02:00,900
Success, direct also touch on 
the security program maturity 

37
00:02:00,900 --> 00:02:05,000
model and gave his tips on how 
to build and higher application 

38
00:02:05,000 --> 00:02:09,400
security teams towards the end. 
Direct also give his insights on

39
00:02:09,400 --> 00:02:12,700
how to address zero day 
vulnerabilities, when it becomes

40
00:02:12,700 --> 00:02:16,000
prominent I think we don't need 
a reminder. 

41
00:02:16,000 --> 00:02:18,400
That security is very important 
to get, right? 

42
00:02:18,600 --> 00:02:21,300
And regardless, if you're 
building an application or just 

43
00:02:21,300 --> 00:02:25,100
using an application, there is 
an inherent security, risks in 

44
00:02:25,100 --> 00:02:27,200
the Technologies and software, 
we use. 

45
00:02:27,600 --> 00:02:30,100
And I hope you enjoy listening 
to this episode and learning a 

46
00:02:30,108 --> 00:02:33,000
few things about building 
application security program. 

47
00:02:33,400 --> 00:02:35,400
And if you do, it will be really
awesome. 

48
00:02:35,400 --> 00:02:38,200
If you can share this with your 
colleagues, your friends and 

49
00:02:38,200 --> 00:02:41,400
communities and also leave a 
five star rating and review on 

50
00:02:41,400 --> 00:02:45,400
Apple podcast and Spotify. 
It may sound Simple, but it will

51
00:02:45,400 --> 00:02:47,100
help me a lot in getting more 
people. 

52
00:02:47,100 --> 00:02:49,500
Discover, the podcasts on the 
platforms. 

53
00:02:49,900 --> 00:02:52,500
Let's go to the conversation 
with Derek after our sponsor 

54
00:02:52,500 --> 00:02:55,000
message. 
Are you looking for a new cool 

55
00:02:55,000 --> 00:02:56,700
swag? 
Taglit Journal. 

56
00:02:56,700 --> 00:02:59,900
Now offers you some swags that 
you can purchase online? 

57
00:03:00,300 --> 00:03:04,100
These wax are printed on demand 
based on your preference and 

58
00:03:04,100 --> 00:03:06,900
will be delivered safely to you 
all over the world where 

59
00:03:06,900 --> 00:03:10,000
shipping is available. 
Check out all the cool swag is 

60
00:03:10,000 --> 00:03:11,700
available by visiting 
technology. 

61
00:03:11,700 --> 00:03:15,300
You know dot f / shop and don't 
Get to break yourself. 

62
00:03:15,300 --> 00:03:20,800
Once you receive any of those 
tracks, hey everyone. 

63
00:03:20,800 --> 00:03:23,000
Welcome back to another new 
episode of the technology. 

64
00:03:23,000 --> 00:03:25,800
You know, today I have with me, 
a guest named Derek Fisher. 

65
00:03:26,000 --> 00:03:28,800
He's the author of a book 
titled, application security 

66
00:03:28,800 --> 00:03:32,100
program handbook, as you can 
tell from the title itself will 

67
00:03:32,100 --> 00:03:35,500
be talking a lot about 
application security and how to 

68
00:03:35,500 --> 00:03:38,300
build a program within your 
company or within your team in 

69
00:03:38,300 --> 00:03:41,700
order to put security at the 
Forefront of the software 

70
00:03:41,700 --> 00:03:43,400
development that you do. 
So direct. 

71
00:03:43,400 --> 00:03:46,000
Thank you so much for Time. 
And I'm looking forward for our 

72
00:03:46,000 --> 00:03:48,300
discussion today. 
We have thank you, Henry. 

73
00:03:48,300 --> 00:03:51,000
Thank you for having me on and 
looking forward to discussing 

74
00:03:51,000 --> 00:03:54,000
this topic. 
So Derek, I always love to ask 

75
00:03:54,000 --> 00:03:56,900
my guess to share about himself 
or herself was in the beginning.

76
00:03:56,900 --> 00:04:00,200
So maybe if you can spend a bit 
of time, telling us who you are 

77
00:04:00,200 --> 00:04:02,500
and what are your highlights or 
turning points that you think 

78
00:04:02,500 --> 00:04:06,600
are worth to share your, so in 
engineering for probably close 

79
00:04:06,600 --> 00:04:08,600
to 30 years. 
Of this point, I started out and

80
00:04:08,600 --> 00:04:11,900
Hardware engineering actually 
designing the circuit boards and

81
00:04:11,900 --> 00:04:13,700
working in mechanical 
engineering. 

82
00:04:14,200 --> 00:04:17,899
I then moved on to software 
engineering after pursuing a 

83
00:04:17,899 --> 00:04:19,800
bachelor's degree in computer 
science. 

84
00:04:20,000 --> 00:04:22,700
And while I was working in 
software engineering got 

85
00:04:22,700 --> 00:04:26,900
introduced to someone product 
security officer at Siemens, who

86
00:04:26,900 --> 00:04:30,900
then got me interested in to 
cybersecurity and decided to 

87
00:04:30,900 --> 00:04:33,600
pursue a master's degree in 
cyber security from Boston 

88
00:04:33,600 --> 00:04:36,000
University. 
At that point got into security 

89
00:04:36,000 --> 00:04:38,800
engineering security, 
architecture and started leading

90
00:04:38,800 --> 00:04:43,500
a team and never look back. 
So I currently run a product 

91
00:04:43,500 --> 00:04:46,800
security Not a leading Financial
technology company. 

92
00:04:46,900 --> 00:04:49,800
I teach software security at 
Temple University. 

93
00:04:50,000 --> 00:04:53,400
As you know, I've written the 
book on building an application 

94
00:04:53,400 --> 00:04:57,000
security program and also have 
written several children's books

95
00:04:57,000 --> 00:04:59,700
on cybersecurity as well. 
Try to stay active in the 

96
00:04:59,700 --> 00:05:01,400
community. 
There's always a lot going on 

97
00:05:01,400 --> 00:05:04,700
and I tend to keep myself busy, 
but it's been a good journey. 

98
00:05:05,400 --> 00:05:08,500
The Foley go to actually your 
book, the application security 

99
00:05:08,500 --> 00:05:10,500
handbook. 
I'm interested when you say, you

100
00:05:10,500 --> 00:05:13,500
also wrote a book for children 
about cybersecurity, maybe he 

101
00:05:13,508 --> 00:05:15,700
can tell us Little bit more 
about that book. 

102
00:05:15,700 --> 00:05:19,300
What made you wrote the book and
what kind of content that you 

103
00:05:19,300 --> 00:05:21,400
are sharing to the kids here? 
Yeah. 

104
00:05:21,400 --> 00:05:25,200
I think we like to use the term 
shift left in cybersecurity and 

105
00:05:25,200 --> 00:05:27,400
I think you're going to shift 
left, it doesn't get any further

106
00:05:27,400 --> 00:05:30,900
left and add so the reason I 
wrote the it's a series but it 

107
00:05:30,900 --> 00:05:34,300
follows a couple children as 
they can introduce the 

108
00:05:34,300 --> 00:05:37,200
technology and some of the 
pitfalls that you have to deal 

109
00:05:37,200 --> 00:05:39,100
with. 
Obviously, you know, being able 

110
00:05:39,100 --> 00:05:42,500
to set up a device securely 
password hygiene staying away 

111
00:05:42,500 --> 00:05:45,700
from strangers, using game. 
Some being able to not get 

112
00:05:45,700 --> 00:05:48,700
scammed during games, so there's
a lot of different things. 

113
00:05:48,700 --> 00:05:50,000
So there's like I said, three 
books. 

114
00:05:50,000 --> 00:05:52,200
So, there's a couple things that
Concepts that we've through 

115
00:05:52,200 --> 00:05:55,900
those books, but it's intended 
to be kind of light-hearted and 

116
00:05:55,900 --> 00:05:58,600
want a story format. 
So it's not the typical textbook

117
00:05:58,600 --> 00:05:59,600
that. 
I think we're all kind of 

118
00:05:59,600 --> 00:06:03,500
accustomed to reading it's 
developed for children that are 

119
00:06:03,600 --> 00:06:07,400
in the six two nine, six to ten 
year old range, they called 

120
00:06:07,400 --> 00:06:10,100
middle gray chapter book. 
So it's meant for that date 

121
00:06:10,100 --> 00:06:14,000
range of 6 to 10 and you know we
look at the way we are. 

122
00:06:14,200 --> 00:06:17,000
In society today, and a lot of 
children that age are obviously 

123
00:06:17,000 --> 00:06:19,700
getting their own devices if 
they're not using their parents.

124
00:06:19,700 --> 00:06:23,100
And so, I think it's important 
to try to impart some of that 

125
00:06:23,100 --> 00:06:25,600
security Concepts to them as 
early as possible. 

126
00:06:26,300 --> 00:06:28,400
Thank you for sharing that. 
So, yeah, you are right. 

127
00:06:28,400 --> 00:06:31,200
Some, it is always better to 
have the shift left mentality, 

128
00:06:31,200 --> 00:06:32,900
right? 
So, in case of software 

129
00:06:32,900 --> 00:06:35,200
development, lifecycle shift 
life means in the earlier 

130
00:06:35,200 --> 00:06:38,400
process, but I think you go 
beyond like earlier face of 

131
00:06:38,400 --> 00:06:40,600
life, right? 
So teaching kids about 

132
00:06:40,600 --> 00:06:43,600
cybersecurity, I hope they also 
get it that these days, we all 

133
00:06:43,600 --> 00:06:45,900
have to be aware. 
About security and make sure 

134
00:06:45,900 --> 00:06:47,700
your data or privacy and 
security. 

135
00:06:47,700 --> 00:06:51,400
Best practices being implemented
in our day-to-day life, right? 

136
00:06:51,400 --> 00:06:54,600
Including talking to strangers. 
Sharing out identity, sharing 

137
00:06:54,600 --> 00:06:57,600
our data and things like that. 
Which brings us to the topic 

138
00:06:57,600 --> 00:07:00,300
today that we would like to talk
about which is to implement 

139
00:07:00,300 --> 00:07:03,200
application security program in 
a particular for example 

140
00:07:03,200 --> 00:07:05,600
company, right? 
As we all know application 

141
00:07:05,600 --> 00:07:07,600
security has been at the 
Forefront. 

142
00:07:07,700 --> 00:07:11,000
We have seen in the news about 
security breaches hacking and 

143
00:07:11,000 --> 00:07:13,100
things like that. 
Maybe if you can give a little 

144
00:07:13,100 --> 00:07:16,600
bit of background What is the 
current urgency for people to 

145
00:07:16,600 --> 00:07:19,100
start thinking about building 
application security program 

146
00:07:19,100 --> 00:07:22,400
within their company here? 
I think in the book, the 

147
00:07:22,400 --> 00:07:24,100
application security program 
handbook. 

148
00:07:24,100 --> 00:07:27,400
I talked about how every company
is a software company and 

149
00:07:27,400 --> 00:07:30,900
whether you're actually 
developing software or using 

150
00:07:30,900 --> 00:07:33,900
software, you don't companies 
that their core product may not 

151
00:07:33,900 --> 00:07:36,000
be software, but they're 
certainly utilizing it. 

152
00:07:36,300 --> 00:07:40,700
And so, I think that all of us 
that work in the software space 

153
00:07:40,700 --> 00:07:43,500
and understand how software gets
made knows that at the very 

154
00:07:43,500 --> 00:07:46,400
least, there's Body issues, if 
not security issues. 

155
00:07:46,400 --> 00:07:50,400
And so these companies that 
utilize that software will 

156
00:07:50,400 --> 00:07:54,400
oftentimes collect data from 
again, even if their core 

157
00:07:54,400 --> 00:07:56,900
function is in software, they're
collecting data about their 

158
00:07:56,900 --> 00:07:58,600
clients. 
About the customers about their 

159
00:07:58,600 --> 00:08:01,000
product. 
They may have IP that they're 

160
00:08:01,000 --> 00:08:05,200
trying to maintain and all this 
is being housed and utilized by 

161
00:08:05,200 --> 00:08:09,000
the software that they bring 
into their organization and it's

162
00:08:09,000 --> 00:08:12,600
only getting more complex. 
When all of these different 

163
00:08:12,600 --> 00:08:15,300
products talk to each other and 
And integrate with each other 

164
00:08:15,300 --> 00:08:18,300
and send data to. 
And from each other, there's 

165
00:08:18,400 --> 00:08:22,700
opportunity there for weaknesses
or vulnerabilities and so that 

166
00:08:22,700 --> 00:08:27,000
exposes the organization suppose
the data, that their housing to 

167
00:08:27,000 --> 00:08:30,500
malicious activity. 
So again, even if your core 

168
00:08:30,500 --> 00:08:33,799
competency is not software 
development and if your product 

169
00:08:33,799 --> 00:08:36,400
isn't in-house, develop 
software, you still have 

170
00:08:36,400 --> 00:08:39,000
exposure to this and it's 
critical to understand. 

171
00:08:39,200 --> 00:08:43,500
What are those vulnerabilities? 
And how do you resolve those 

172
00:08:43,500 --> 00:08:45,800
vulnerabilities? 
When they are detected. 

173
00:08:46,400 --> 00:08:47,700
Yeah. 
And I read in one particular 

174
00:08:47,700 --> 00:08:50,600
chapter, you also mentioned even
though the company is seems to 

175
00:08:50,600 --> 00:08:54,200
have just a little bit of 
Technology like enabling website

176
00:08:54,200 --> 00:08:57,000
or maybe just exposing something
to the internet, right? 

177
00:08:57,100 --> 00:09:00,700
They also have this kind of risk
so that for example, they are 

178
00:09:00,700 --> 00:09:03,800
being defaced or something data 
is being leaked out, right? 

179
00:09:03,800 --> 00:09:06,700
So all this becomes very 
relevant, even though you may 

180
00:09:06,700 --> 00:09:10,400
not be a technology pure 
company, but once you introduce 

181
00:09:10,400 --> 00:09:12,900
some kind of Technology, 
especially internet, right? 

182
00:09:13,100 --> 00:09:15,200
So things are Coming more 
dangerous. 

183
00:09:15,200 --> 00:09:18,400
So to speak you mentioned about 
building security program. 

184
00:09:18,400 --> 00:09:21,500
So maybe four people here who 
are not yet familiar, because we

185
00:09:21,500 --> 00:09:23,900
always think security is 
somebody else's job. 

186
00:09:24,200 --> 00:09:27,200
Maybe if you can explain to us a
little bit more, what do you 

187
00:09:27,200 --> 00:09:29,700
mean by building application 
security program? 

188
00:09:30,600 --> 00:09:33,700
If you're have any familiarity 
with the security organization 

189
00:09:33,700 --> 00:09:36,600
within your company or if you're
already working in a security 

190
00:09:36,600 --> 00:09:39,300
organization, you're probably 
pretty familiar with the fact 

191
00:09:39,300 --> 00:09:43,900
that we are very good at being 
able to protect the perimeter. 

192
00:09:44,300 --> 00:09:47,500
And that's an old kind of 
mentality because I see things 

193
00:09:47,500 --> 00:09:51,300
shift to the cloud. 
And as we have more sass tools 

194
00:09:51,300 --> 00:09:55,000
that were using where things are
kind of decentralized and not 

195
00:09:55,000 --> 00:09:59,100
house within a data center, we 
understand where those entry 

196
00:09:59,100 --> 00:10:02,400
points are into our system. 
We understand kind of how the 

197
00:10:02,400 --> 00:10:05,700
controls around that, but when 
your core competency is 

198
00:10:05,700 --> 00:10:08,800
developing software and when 
your core product is a 

199
00:10:09,100 --> 00:10:12,800
internally developed software 
product, its on that 

200
00:10:12,800 --> 00:10:15,900
organization to ensure, Sure 
that we're building security 

201
00:10:15,900 --> 00:10:19,300
into that product and protecting
the data that were collecting 

202
00:10:19,300 --> 00:10:22,700
and using in order to protect 
our clients building, an 

203
00:10:22,700 --> 00:10:26,300
application security program is 
really about ensuring that 

204
00:10:26,300 --> 00:10:29,500
security is built into that 
software development life cycle,

205
00:10:29,800 --> 00:10:32,700
but not just into the software 
development lifecycle. 

206
00:10:32,700 --> 00:10:36,400
But also, how do we respond to 
vulnerabilities or findings as 

207
00:10:36,400 --> 00:10:39,000
we move along? 
That development pipeline all 

208
00:10:39,000 --> 00:10:41,200
the way into the operational 
environment. 

209
00:10:41,200 --> 00:10:45,300
So when you develop software and
Push it out into a production 

210
00:10:45,300 --> 00:10:47,900
environment for development, 
that's not where it ends, right?

211
00:10:47,900 --> 00:10:50,500
There's a constant iteration 
you're constantly getting 

212
00:10:50,500 --> 00:10:52,900
feedback from your clients, you 
have defects that you have to 

213
00:10:52,900 --> 00:10:55,900
resolve and so forth. 
And those get pulled into the 

214
00:10:55,900 --> 00:10:59,500
next set of requirements and 
development and security is no 

215
00:10:59,500 --> 00:11:01,200
different one. 
We find vulnerabilities and 

216
00:11:01,200 --> 00:11:05,200
operations, or if we find a new 
0 days or so forth, those things

217
00:11:05,200 --> 00:11:08,000
need to be pulled back into the 
development environment and 

218
00:11:08,000 --> 00:11:11,900
resolve. 
So having a program in place 

219
00:11:11,900 --> 00:11:15,100
that is able to really look at 
that, That entire software 

220
00:11:15,100 --> 00:11:18,400
development life cycle and 
integrate security. 

221
00:11:18,400 --> 00:11:21,900
As part of that entire cycle is 
what building an application 

222
00:11:21,900 --> 00:11:24,400
security program is all about. 
Yeah. 

223
00:11:24,600 --> 00:11:28,000
So I think I do get what you 
mean by saying traditionally, we

224
00:11:28,000 --> 00:11:30,800
always try to protect the 
perimeter right, whether it's in

225
00:11:30,900 --> 00:11:33,800
pesos the outright and maybe it 
will class time. 

226
00:11:33,800 --> 00:11:36,700
But I guess these days and 
security threats have becoming 

227
00:11:36,700 --> 00:11:39,500
much more sophisticated, not to 
mention, there might be also 

228
00:11:39,500 --> 00:11:42,600
inside a security threat, but I 
think these days, there are so 

229
00:11:42,600 --> 00:11:45,100
many entry points where it's at 
The vulnerability is can be 

230
00:11:45,100 --> 00:11:48,700
found and even if you don't do 
anything sometimes it could also

231
00:11:48,700 --> 00:11:50,800
happen that security 
vulnerabilities are being 

232
00:11:50,800 --> 00:11:52,800
exposed. 
Think of like the log4j 

233
00:11:52,900 --> 00:11:55,200
vulnerability last time, right? 
Even though you didn't change 

234
00:11:55,200 --> 00:11:57,100
anything. 
But yeah, you still exposed 

235
00:11:57,100 --> 00:11:58,800
once. 
These vulnerabilities is found 

236
00:11:59,000 --> 00:12:02,200
which brings us to the phrase 
that we commonly hear in the 

237
00:12:02,200 --> 00:12:05,200
security world and also separate
development world, is that you 

238
00:12:05,200 --> 00:12:08,300
quoted this in the book saying 
that fixing issues in production

239
00:12:08,300 --> 00:12:12,200
is significantly more expensive 
than fixing prior to production.

240
00:12:12,500 --> 00:12:15,100
So this comes back to our Our 
discussion earlier about 

241
00:12:15,100 --> 00:12:17,300
shifting left, right? 
Maybe if you can explain a 

242
00:12:17,308 --> 00:12:20,100
little bit more about this 
philosophy, what does it mean by

243
00:12:20,100 --> 00:12:23,500
shifting lab, and why do we 
always have to care about fixing

244
00:12:23,500 --> 00:12:28,300
it earlier than the production? 
Today, if you look at 

245
00:12:28,300 --> 00:12:31,000
discovering a vulnerability in 
the production environment, 

246
00:12:31,000 --> 00:12:34,000
there's a long path. 
I mean it's a long and actually 

247
00:12:34,000 --> 00:12:37,000
relative depending on the 
organization what type of 

248
00:12:37,000 --> 00:12:38,400
release methodology that they're
in. 

249
00:12:38,400 --> 00:12:42,000
But there's a path from the code
being developed on a development

250
00:12:42,000 --> 00:12:45,200
environment and then all the way
to production and there's tools.

251
00:12:45,200 --> 00:12:48,200
There's people there's processes
that are all in place along that

252
00:12:48,200 --> 00:12:51,200
entire Pipeline. 
And that can involve QA 

253
00:12:51,200 --> 00:12:55,000
individuals, there could be 
scrum, Masters project managers 

254
00:12:55,200 --> 00:12:56,100
leadership that are all 
involved. 

255
00:12:56,500 --> 00:12:58,600
In the process of getting that 
code from a development 

256
00:12:58,600 --> 00:13:02,500
environment into production and 
that's real cost, right? 

257
00:13:02,500 --> 00:13:05,800
If you think of, we're looking 
at code going from development 

258
00:13:05,800 --> 00:13:07,500
to production, but think about 
it. 

259
00:13:07,500 --> 00:13:10,200
But vulnerability going from 
development, environment into 

260
00:13:10,200 --> 00:13:12,200
production and all along that 
pipeline. 

261
00:13:12,200 --> 00:13:14,800
There's been people that have 
been involved with that code 

262
00:13:14,800 --> 00:13:18,000
that is potentially vulnerable 
going along, until it gets into 

263
00:13:18,000 --> 00:13:20,500
that production environment. 
Then when it's discovered in 

264
00:13:20,500 --> 00:13:24,600
production, you now have support
individuals that have to get on 

265
00:13:24,600 --> 00:13:27,700
bridge calls to figure out what 
The issue is security, people 

266
00:13:27,700 --> 00:13:29,500
are called in. 
You might have to get pull in 

267
00:13:29,500 --> 00:13:32,900
incident, response forensics 
depending on the severity of the

268
00:13:32,908 --> 00:13:35,900
vulnerability. 
You now have a very costly of 

269
00:13:35,900 --> 00:13:38,400
vulnerability. 
Of course, results May Vary. 

270
00:13:38,500 --> 00:13:41,700
You may find a vulnerability and
production that's relatively 

271
00:13:41,700 --> 00:13:45,200
easy to resolve or get to a good
spot with and you may have ones 

272
00:13:45,200 --> 00:13:49,100
that are very extreme, right? 
But the goal of Shifting left 

273
00:13:49,100 --> 00:13:53,100
and the goal of being able to 
push the discovery of that 

274
00:13:53,100 --> 00:13:57,300
vulnerability earlier in the 
process is really About bringing

275
00:13:57,300 --> 00:14:01,300
security and detection as early 
in the process as possible. 

276
00:14:01,600 --> 00:14:05,300
And the way we do that is 
through training developers to 

277
00:14:05,400 --> 00:14:07,600
number one, not real. 
Its security vulnerabilities in 

278
00:14:07,600 --> 00:14:11,300
the first place, or at least be 
able to understand the code 

279
00:14:11,300 --> 00:14:15,100
patterns that result in Secure 
software. 

280
00:14:15,500 --> 00:14:19,800
Additionally, try to layer in 
security scanning tools as early

281
00:14:19,800 --> 00:14:23,100
as possible, so that could be 
things like static analysis, 

282
00:14:23,100 --> 00:14:27,600
software, or what we call SCA, 
or We're composition analysis to

283
00:14:27,600 --> 00:14:30,300
look for those vulnerabilities 
is early in the process as 

284
00:14:30,300 --> 00:14:32,900
possible. 
Things like Secrets, management 

285
00:14:32,900 --> 00:14:36,000
secrets of Discovery tools. 
All these can be kind of used 

286
00:14:36,000 --> 00:14:40,900
early in the process to detect 
any potential security issues 

287
00:14:40,900 --> 00:14:44,200
that could manifest in a 
production environment and then 

288
00:14:44,200 --> 00:14:47,800
all along that pipeline, you can
also integrate other scanning 

289
00:14:47,800 --> 00:14:51,400
tools that are designed for 
runtime environments like 

290
00:14:51,400 --> 00:14:54,400
Dynamic scanners or integrated 
software testing. 

291
00:14:55,000 --> 00:14:59,000
So the goal there, Is to just 
continue to implement security 

292
00:14:59,000 --> 00:15:01,900
tools along that path to 
discover those vulnerabilities 

293
00:15:01,900 --> 00:15:04,900
before they get to a production 
environment and there's many 

294
00:15:04,900 --> 00:15:09,200
different ways of doing that. 
Now, not to kind of step on the 

295
00:15:09,200 --> 00:15:11,700
term shift left here, but we're 
starting to move away 

296
00:15:11,700 --> 00:15:15,000
application security, the 
individuals are starting to move

297
00:15:15,008 --> 00:15:18,900
away from the term shift left, 
just because not that we don't 

298
00:15:18,900 --> 00:15:22,200
want to focus on discovering 
those vulnerabilities early, but

299
00:15:22,200 --> 00:15:25,500
we don't want to forget that. 
There's other methods of 

300
00:15:25,500 --> 00:15:27,300
detecting. 
Ting, vulnerabilities, and 

301
00:15:27,300 --> 00:15:30,900
ensuring, that security is 
integrated across the entire 

302
00:15:30,900 --> 00:15:33,800
life cycle. 
Because I think we're now trying

303
00:15:33,800 --> 00:15:36,700
to kind of over. 
Correct for the term shift, left

304
00:15:36,700 --> 00:15:39,900
and pushing everything into left
hand side at the development 

305
00:15:39,900 --> 00:15:43,300
lifecycle and sometimes 
forgetting about the rest of it.

306
00:15:43,900 --> 00:15:45,200
Yeah, you made a good point, 
right? 

307
00:15:45,200 --> 00:15:47,700
Security. 
He's not finished just by having

308
00:15:48,000 --> 00:15:51,500
so-called secure code and secure
development practices, right? 

309
00:15:51,500 --> 00:15:54,000
Once you put the code into 
production, that's where the 

310
00:15:54,000 --> 00:15:56,100
rubber hits the road. 
So to speak that way, you have a

311
00:15:56,200 --> 00:15:59,700
Because maybe constantly trying 
to look for vulnerabilities or 

312
00:15:59,700 --> 00:16:02,800
things where they can attack. 
And I think I even see it within

313
00:16:02,800 --> 00:16:05,400
my company from day to day, they
are some just anomalies 

314
00:16:05,400 --> 00:16:08,900
traffic's like trying to attack 
by injection or attacked by 

315
00:16:08,900 --> 00:16:11,000
other means, right? 
And there are so many security 

316
00:16:11,000 --> 00:16:14,400
scanning tools, as well, like 
hacking tools that people are 

317
00:16:14,400 --> 00:16:17,800
exposed with easily so that they
can use free software to scan 

318
00:16:17,800 --> 00:16:21,100
any kind of internet port 
websites and things like that. 

319
00:16:21,100 --> 00:16:23,500
So I think you are right that we
should not be relaxed. 

320
00:16:23,500 --> 00:16:27,100
Once we adopt secure coding 
practices, Element pipeline 

321
00:16:27,100 --> 00:16:28,900
practices. 
But always try to look 

322
00:16:28,900 --> 00:16:32,200
holistically before we actually 
go into all these techniques 

323
00:16:32,200 --> 00:16:34,000
that you implement in the 
program, right? 

324
00:16:34,000 --> 00:16:37,200
One thing is for people to 
understand the risk and normally

325
00:16:37,500 --> 00:16:40,800
the risks associated with 
security is summarized as a CIA 

326
00:16:40,800 --> 00:16:44,400
Triad, this thing about 
confidentiality integrity and 

327
00:16:44,400 --> 00:16:48,700
availability, so can you also 
explain to us what this CIA 

328
00:16:48,700 --> 00:16:51,900
Triad is? 
And can all security risk 

329
00:16:51,900 --> 00:16:54,400
actually be summarized into 
these three components only. 

330
00:16:55,000 --> 00:16:58,600
I mean it's not just Those three
components, there are other 

331
00:16:58,600 --> 00:17:02,300
acronyms that leverage the CIA 
to also include things like 

332
00:17:02,300 --> 00:17:06,900
authentication accountability. 
But when you look at what we do 

333
00:17:07,000 --> 00:17:10,200
from a security standpoint, it 
does pretty much come back to 

334
00:17:10,200 --> 00:17:13,700
ensuring that data is secure and
not expose to somebody. 

335
00:17:13,700 --> 00:17:17,800
That should be that the data is 
not corrupted and is known to be

336
00:17:17,800 --> 00:17:21,000
trusted and that data is 
available and I say data. 

337
00:17:21,000 --> 00:17:23,800
But it the application, the 
system, it's confidential the 

338
00:17:23,800 --> 00:17:27,099
data and there's confidential 
the data The systems are running

339
00:17:27,099 --> 00:17:29,600
the way they should be. 
And that there hasn't been 

340
00:17:29,600 --> 00:17:32,600
anything tampered with the 
system when you look at the CIA.

341
00:17:32,600 --> 00:17:36,200
A lot of it comes back to those 
three kind of main principles. 

342
00:17:36,200 --> 00:17:38,600
And when we talk about the 
different ways of trying to 

343
00:17:38,600 --> 00:17:42,800
integrate security to ensure 
that we're maintaining the 

344
00:17:42,800 --> 00:17:46,000
confidentiality integrity and 
availability, just from a high 

345
00:17:46,000 --> 00:17:48,200
level with confidentiality 
primarily. 

346
00:17:48,200 --> 00:17:50,600
We're talking about encryption 
making sure that data is 

347
00:17:50,600 --> 00:17:54,600
encrypted at rest and Transit 
and in use with Integrity were 

348
00:17:54,600 --> 00:17:58,000
ensuring that we have. 
Of hashing and check sums being 

349
00:17:58,000 --> 00:18:00,400
used. 
Just to ensure that the data 

350
00:18:00,500 --> 00:18:03,400
that was sent is the same data 
that was received and with 

351
00:18:03,400 --> 00:18:06,000
availability your building, 
highly redundant, highly 

352
00:18:06,000 --> 00:18:10,100
available types of systems to 
ensure that when something is 

353
00:18:10,100 --> 00:18:13,400
needed, it's available. 
I used to work in healthcare 

354
00:18:13,400 --> 00:18:17,800
space and I think the CIA was 
definitely I think more 

355
00:18:17,800 --> 00:18:20,400
prominent in the healthcare 
space than I would say in some 

356
00:18:20,400 --> 00:18:22,100
of the other fields that I've 
worked in. 

357
00:18:22,300 --> 00:18:26,800
Not that it's not elsewhere but 
definitely when you Talk about 

358
00:18:26,800 --> 00:18:30,200
using clinical applications, 
that doctors are using to make 

359
00:18:30,200 --> 00:18:33,400
decisions on patients 
potentially life and death types

360
00:18:33,400 --> 00:18:35,700
of situations. 
You want to make sure that that 

361
00:18:35,900 --> 00:18:39,300
prescription that the medication
that the doctor is prescribing, 

362
00:18:39,300 --> 00:18:42,100
is what the doctor. 
Prescribed, as what's actually 

363
00:18:42,100 --> 00:18:44,900
being administered in operating 
room, you want to make sure that

364
00:18:44,900 --> 00:18:47,700
the systems are up and running 
so that the doctor can get 

365
00:18:47,700 --> 00:18:50,900
access to that information when 
they need it and you want to 

366
00:18:50,900 --> 00:18:55,000
make sure that patient data is 
well protected and not release 

367
00:18:55,000 --> 00:18:58,000
again in other fields. 
Obviously the CIA is still 

368
00:18:58,000 --> 00:19:01,000
critical but it was very 
abundantly clear when I worked 

369
00:19:01,000 --> 00:19:05,100
in the healthcare space, how 
critical the CIA was, thanks for

370
00:19:05,100 --> 00:19:07,500
explaining that. 
So now assuming that people 

371
00:19:07,500 --> 00:19:11,500
understand security risk and you
know why it is wise to actually 

372
00:19:11,500 --> 00:19:13,300
Implement some kind of security 
program? 

373
00:19:13,500 --> 00:19:15,400
Where do people start fighting 
in your book? 

374
00:19:15,400 --> 00:19:18,000
You mentioned about this thing, 
called threat modeling as the 

375
00:19:18,000 --> 00:19:20,300
first step. 
So maybe if you can explain us, 

376
00:19:20,300 --> 00:19:23,200
what does it mean to do track 
modeling and what does it 

377
00:19:23,200 --> 00:19:25,700
entail? 
Yeah, there's a couple different

378
00:19:25,700 --> 00:19:27,100
ways. 
Of doing threat modeling. 

379
00:19:27,100 --> 00:19:30,200
And I think that we do threat 
modeling on a daily basis 

380
00:19:30,200 --> 00:19:33,200
whether we know it or not, we 
get in our car and we start 

381
00:19:33,200 --> 00:19:36,600
driving and our mind is already 
doing whether we consciously 

382
00:19:36,600 --> 00:19:38,400
think about it or not, we're 
doing threat modeling. 

383
00:19:38,500 --> 00:19:40,300
Yo am I going the right 
direction? 

384
00:19:40,500 --> 00:19:42,800
Is you're going to traffic is 
this person going to stop at 

385
00:19:42,800 --> 00:19:44,400
this? 
Stop sign that I'm about to go 

386
00:19:44,400 --> 00:19:49,100
through and you build in certain
mitigation and you determine 

387
00:19:49,100 --> 00:19:52,000
like whether you're doing the 
right thing on the basic level 

388
00:19:52,100 --> 00:19:55,200
threat modeling is essentially 
asking what can go wrong. 

389
00:19:55,300 --> 00:19:58,000
There's a lot of Normal 
processes around threat 

390
00:19:58,000 --> 00:20:00,800
modeling, including using tools 
to do threat models. 

391
00:20:01,100 --> 00:20:04,400
But It ultimately comes down to 
asking that, basic question what

392
00:20:04,400 --> 00:20:09,000
can go wrong and once you 
identify what that wrong is, you

393
00:20:09,000 --> 00:20:11,900
start developing those 
mitigation and Remediation 

394
00:20:11,900 --> 00:20:13,600
efforts. 
But if you want to get started 

395
00:20:13,600 --> 00:20:16,300
with threat modeling, there's a 
couple different tools that I 

396
00:20:16,300 --> 00:20:18,300
usually recommend. 
One is the Microsoft threat 

397
00:20:18,300 --> 00:20:22,900
model tool, which is free to 
download a wasp also has called 

398
00:20:22,900 --> 00:20:25,900
a threat Dragon, which is also a
threat model tool. 

399
00:20:26,100 --> 00:20:28,400
Purpose-built for Designing 
threat models. 

400
00:20:28,800 --> 00:20:31,400
Other individuals and 
organizations will use things 

401
00:20:31,400 --> 00:20:35,400
like PowerPoint or Vizio or 
something like that, just 

402
00:20:35,400 --> 00:20:38,100
because essentially, when you're
doing a threat model is that 

403
00:20:38,100 --> 00:20:41,100
you're drawing out the 
architecture of the system and 

404
00:20:41,100 --> 00:20:43,500
you want to understand what the 
different touch points are in 

405
00:20:43,500 --> 00:20:46,800
that system, whether the 
third-party Integrations, or 

406
00:20:46,800 --> 00:20:49,900
whether they're internal users 
or external users, you want to 

407
00:20:49,900 --> 00:20:52,500
know, basically what that attack
surface looks like for that 

408
00:20:52,500 --> 00:20:55,200
system and then start asking 
those questions on each one of 

409
00:20:55,200 --> 00:20:57,300
those integration. 
Ask the question. 

410
00:20:57,300 --> 00:21:00,400
What can go wrong? 
Can somebody spoof this call? 

411
00:21:00,600 --> 00:21:02,900
Can somebody tampered with the 
data that's coming through? 

412
00:21:02,900 --> 00:21:05,200
Can someone perform at the 
denial of service? 

413
00:21:05,400 --> 00:21:09,500
Can someone change their access 
level from a simple user to an 

414
00:21:09,500 --> 00:21:12,100
admin user? 
And you go through that with 

415
00:21:12,100 --> 00:21:15,900
each one of those interactions 
with the system and as you do 

416
00:21:15,900 --> 00:21:18,700
that and identify like, oh yeah 
well somebody can perform a 

417
00:21:18,708 --> 00:21:22,300
denial service while is this 
high enough risk for us to 

418
00:21:22,300 --> 00:21:26,500
integrate highly available 
system for us to be able to to 

419
00:21:26,600 --> 00:21:29,600
mitigate or remediate that 
denial of service attack. 

420
00:21:29,800 --> 00:21:32,900
And so that's the basic process 
of threat modeling is designing 

421
00:21:32,900 --> 00:21:35,600
that architecture. 
Identifying the interaction 

422
00:21:35,600 --> 00:21:38,400
points and start asking those 
questions about what are the 

423
00:21:38,408 --> 00:21:40,600
different attacks that could be 
performed. 

424
00:21:40,600 --> 00:21:42,400
And then what are we going to do
about that? 

425
00:21:42,500 --> 00:21:45,800
Now, there's also a more what we
would call like a manual threat 

426
00:21:45,800 --> 00:21:48,800
model process, which is 
essentially getting a bunch of 

427
00:21:48,800 --> 00:21:52,400
individuals into a room with a 
whiteboard and doing the same 

428
00:21:52,400 --> 00:21:55,100
thing where you draw out the 
architecture, you start asking 

429
00:21:55,100 --> 00:21:58,400
those questions. 
But the tools using something 

430
00:21:58,400 --> 00:22:02,000
like owasp threat dragon or 
Microsoft, threat model tool, or

431
00:22:02,000 --> 00:22:03,900
there's commercial 
off-the-shelf, threat model 

432
00:22:03,900 --> 00:22:06,500
tools as well that exist. 
But using any of these tools 

433
00:22:06,500 --> 00:22:10,300
means that an individual or a 
very small group of individuals 

434
00:22:10,300 --> 00:22:13,900
can work on that threat model. 
You can put into maybe a central

435
00:22:13,900 --> 00:22:16,300
location where you can store 
those threat models their 

436
00:22:16,300 --> 00:22:19,300
digital format. 
So they're easy to maintain and 

437
00:22:19,300 --> 00:22:22,200
handout that's the benefit of 
using a tool for threat 

438
00:22:22,200 --> 00:22:24,200
modeling. 
But when you look at doing a 

439
00:22:24,200 --> 00:22:26,700
manual threat model on a 
whiteboard, It's more time 

440
00:22:26,700 --> 00:22:29,800
consuming you can't really take 
your white board and check it 

441
00:22:29,800 --> 00:22:33,100
into a repository somewhere, but
you're going to tend to get 

442
00:22:33,100 --> 00:22:35,800
better results in those manual 
type of threat model 

443
00:22:35,900 --> 00:22:38,600
environments because you're 
going to get more collaborative 

444
00:22:38,600 --> 00:22:42,000
responses from the people that 
are in the conversation but it 

445
00:22:42,000 --> 00:22:43,900
doesn't scale as well. 
So yeah, there's some 

446
00:22:43,900 --> 00:22:46,400
trade-offs. 
But again, it all comes down to 

447
00:22:46,400 --> 00:22:48,500
ask that question. 
What can go wrong and what are 

448
00:22:48,500 --> 00:22:51,000
we going to do about it? 
Thanks by explaining about 

449
00:22:51,000 --> 00:22:53,500
threat modeling. 
So, for people who haven't done 

450
00:22:53,500 --> 00:22:56,000
this before, how frequent should
they do this? 

451
00:22:56,200 --> 00:22:58,800
Exercise is it like every time 
there's a new thing in the 

452
00:22:58,800 --> 00:23:01,800
architecture or is it like 
periodic thing like maybe every 

453
00:23:01,800 --> 00:23:05,000
quarter every month is that some
kind of advice that you want to 

454
00:23:05,000 --> 00:23:08,700
give people when they should do 
track modeling, and after we 

455
00:23:08,700 --> 00:23:11,600
collect all these threat, 
modeling findings, how should 

456
00:23:11,600 --> 00:23:15,600
people collect and prioritize? 
This and also explaining to the 

457
00:23:15,600 --> 00:23:17,600
whole company or maybe the 
management that okay. 

458
00:23:17,600 --> 00:23:21,200
At some of these are real risk 
that we should work on here. 

459
00:23:21,200 --> 00:23:23,800
Are it comes down to 
understanding what the risk 

460
00:23:23,800 --> 00:23:26,800
level risk tolerances of the 
Organization. 

461
00:23:27,000 --> 00:23:31,300
And that's a very key component 
that I think we're missing in 

462
00:23:31,300 --> 00:23:36,900
many companies is, how do you 
really know what the risk is of 

463
00:23:36,900 --> 00:23:39,400
the findings that you find in 
your software? 

464
00:23:39,600 --> 00:23:42,200
And we don't always do a good 
job of that. 

465
00:23:42,200 --> 00:23:46,400
We know generally what our 
Flagship products are if you're 

466
00:23:46,400 --> 00:23:48,700
working inside an organization, 
you know what your Flagship 

467
00:23:48,700 --> 00:23:52,300
products are you know where your
crown jewels are in terms of 

468
00:23:52,300 --> 00:23:56,500
data, you know what, the 
critical workflows are and So 

469
00:23:56,500 --> 00:24:00,300
you can determine like, okay, 
well this vulnerability that we 

470
00:24:00,300 --> 00:24:05,200
found impacts this application 
has potential to compromise this

471
00:24:05,200 --> 00:24:08,300
data, that's high risk. 
So we should tackle that 

472
00:24:08,600 --> 00:24:12,400
however, again we're not great 
at being able to make that 

473
00:24:12,400 --> 00:24:17,200
decision quickly and in a very 
calculated way, it tends to be 

474
00:24:17,200 --> 00:24:20,100
more individuals making. 
I don't want to say gut 

475
00:24:20,100 --> 00:24:23,700
reaction, but it sort of is 
people saying, oh, this is our 

476
00:24:23,700 --> 00:24:25,900
Flagship product with a lot of 
sensitive data there. 

477
00:24:26,100 --> 00:24:29,400
For, it's got to be high risk. 
But risk really comes down to 

478
00:24:29,500 --> 00:24:31,400
technical risk and business 
risk. 

479
00:24:31,400 --> 00:24:34,900
There's technical risk of, are 
we going to lose confidentiality

480
00:24:34,900 --> 00:24:37,600
the Integrity of the data, the 
availability of the system? 

481
00:24:37,800 --> 00:24:41,100
And then from the business side,
do we have compliance concerns? 

482
00:24:41,100 --> 00:24:45,400
Do we have contractual concerns?
Do we have dollar amounts that 

483
00:24:45,400 --> 00:24:49,600
are assigned to downtime for 
this application and marrying 

484
00:24:49,600 --> 00:24:50,800
those two together? 
Really? 

485
00:24:50,800 --> 00:24:53,900
Give you the overall risk of 
what that vulnerability might be

486
00:24:53,900 --> 00:24:55,700
in the context of that 
application. 

487
00:24:56,500 --> 00:24:58,800
I think we're kind of missing 
that context and a lot of 

488
00:24:58,800 --> 00:25:03,300
organizations, in terms of, how 
do we frame those into those 

489
00:25:03,300 --> 00:25:05,500
vulnerabilities that we find? 
How do we frame them into the 

490
00:25:05,500 --> 00:25:08,200
right context of the, we know 
what we're tackling because 

491
00:25:08,400 --> 00:25:12,300
prior to zation and really 
understanding how we prioritize,

492
00:25:12,300 --> 00:25:15,200
the vulnerabilities that come in
need to be put through that lens

493
00:25:15,200 --> 00:25:18,500
of risk. 
But the other side of that is 

494
00:25:18,500 --> 00:25:22,000
from a technical standpoint is, 
what's the exploitability of 

495
00:25:22,000 --> 00:25:24,900
this vulnerability. 
And that's another kind of piece

496
00:25:24,900 --> 00:25:29,200
that we're not as a An industry,
graded getting to, and we can 

497
00:25:29,200 --> 00:25:32,000
find application. 
Security teams can find 

498
00:25:32,000 --> 00:25:34,500
vulnerabilities. 
All day penetration testers can 

499
00:25:34,500 --> 00:25:38,700
find vulnerabilities all day 
two, and we have no shortage of 

500
00:25:38,700 --> 00:25:41,800
ability to be able to find 
vulnerabilities and talk about 

501
00:25:41,800 --> 00:25:44,500
like, hey, I found 10 new 
vulnerabilities today. 

502
00:25:44,700 --> 00:25:46,300
Great. 
What are we going to do about? 

503
00:25:46,300 --> 00:25:49,100
It are these really actual 
issues that we need to be 

504
00:25:49,100 --> 00:25:51,300
concerned about? 
Are they going to actually go 

505
00:25:51,300 --> 00:25:54,100
into a production environment if
they go into that production 

506
00:25:54,100 --> 00:25:56,000
environment? 
Are they actually going to 

507
00:25:56,300 --> 00:25:59,800
Exploited because if in any 
mature organization, you're 

508
00:25:59,800 --> 00:26:01,500
going to have runtime 
protection, you're going to have

509
00:26:01,500 --> 00:26:03,900
segmentation, you're going to 
have all these other controls in

510
00:26:03,900 --> 00:26:07,600
place that may make that 
vulnerability on exploitable. 

511
00:26:07,700 --> 00:26:10,600
So understanding, how to 
prioritize, vulnerabilities and 

512
00:26:10,600 --> 00:26:13,900
understanding. 
How to really contextualize them

513
00:26:13,900 --> 00:26:17,100
is not easy, it's understanding.
What is the organization's risk?

514
00:26:17,200 --> 00:26:19,100
What's the exploitability of 
that vulnerability? 

515
00:26:19,300 --> 00:26:21,500
And, you know, putting that 
together and making it a 

516
00:26:21,508 --> 00:26:24,300
decision quickly? 
When you do find those, and you 

517
00:26:24,308 --> 00:26:27,900
find one that hey, this phone, 
Ability here is in a very 

518
00:26:27,900 --> 00:26:31,100
high-risk application. 
It has potential to expose a lot

519
00:26:31,100 --> 00:26:33,600
of data which is going to put us
at compliance risk. 

520
00:26:33,600 --> 00:26:37,200
And yes, it is exploitable 
because we have no mitigations 

521
00:26:37,200 --> 00:26:39,400
in front of it. 
That should be a, I don't want a

522
00:26:39,400 --> 00:26:42,600
slam dunk, but I think that's a 
typically, a slam-dunk for 

523
00:26:42,600 --> 00:26:45,300
organizations and say, hey, 
that's the one we need to go 

524
00:26:45,300 --> 00:26:48,800
after not the other 50 that we 
found that are unexplainable. 

525
00:26:49,200 --> 00:26:52,500
And I think, for most of 
organizations getting to that 

526
00:26:52,500 --> 00:26:55,000
point and being able to show 
like, hey, here's a valid 

527
00:26:55,000 --> 00:26:58,300
vulnerability, that Is going to 
be impactful. 

528
00:26:58,600 --> 00:27:00,400
That's what they want to chase. 
They don't want to chase the 

529
00:27:00,400 --> 00:27:04,700
other 50 that are just not, you 
know, of a concern and you. 

530
00:27:04,700 --> 00:27:06,100
All right. 
Oh so like we can always find 

531
00:27:06,100 --> 00:27:08,400
vulnerabilities, right? 
But what to do about it because 

532
00:27:08,400 --> 00:27:11,100
sometimes it could be in 
hundreds and thousands depending

533
00:27:11,100 --> 00:27:14,100
on what tools you integrate. 
And speaking about tools, you 

534
00:27:14,100 --> 00:27:16,800
earlier mentioned things like 
Dynamic equation, security 

535
00:27:16,800 --> 00:27:19,900
testing, static analysis of a 
composition analysis. 

536
00:27:19,900 --> 00:27:22,900
What are the possible things 
that actually a company or 

537
00:27:22,900 --> 00:27:25,700
organization can introduce 
within their security program 

538
00:27:25,700 --> 00:27:26,800
up? 
Art from those that you have 

539
00:27:26,800 --> 00:27:29,100
mentioned. 
And where should people start? 

540
00:27:29,100 --> 00:27:30,700
Because we have so many. 
Right. 

541
00:27:30,700 --> 00:27:34,100
I don't think any new company 
can easily just introduce all of

542
00:27:34,100 --> 00:27:36,000
them, but where should people 
prioritize? 

543
00:27:36,000 --> 00:27:39,100
Maybe start as the easiest one 
first, or maybe the most 

544
00:27:39,100 --> 00:27:41,700
impactful ones, maybe you can 
give us some guidance here, 

545
00:27:41,700 --> 00:27:45,100
securing the development, life 
cycle can be done, a hundred 

546
00:27:45,100 --> 00:27:48,700
different ways, and there could 
be any combination of calls and 

547
00:27:48,700 --> 00:27:52,100
I know talking to some of my 
peers and looking at others in 

548
00:27:52,100 --> 00:27:55,600
the industry, you can see where 
some are doing things that are 

549
00:27:55,600 --> 00:27:58,200
completely Different and some 
are doing things that are very 

550
00:27:58,200 --> 00:28:00,500
similar to what I'm doing my 
company. 

551
00:28:00,600 --> 00:28:02,700
And I think it really comes down
to a few things. 

552
00:28:02,700 --> 00:28:05,100
One is, what's the budget 
tolerance? 

553
00:28:05,200 --> 00:28:07,400
You know, if you're on a 
shoestring budget, when you 

554
00:28:07,400 --> 00:28:10,800
don't have a lot of cash, it 
just throw it problem, then you 

555
00:28:10,800 --> 00:28:13,400
have to be creative. 
If you are less constrained in 

556
00:28:13,408 --> 00:28:16,500
that area, then you can have a 
little bit more leeway and being

557
00:28:16,500 --> 00:28:19,600
able to build a more robust 
security development program, 

558
00:28:19,800 --> 00:28:22,300
but it does come down to at some
point finding more 

559
00:28:22,300 --> 00:28:25,700
vulnerabilities isn't making you
more secure and but in fact it 

560
00:28:25,700 --> 00:28:28,800
made Make you you're not going 
to get invited to the Christmas 

561
00:28:28,800 --> 00:28:30,700
party and stuff like that 
because all you're doing is 

562
00:28:30,700 --> 00:28:32,900
finding more vulnerabilities and
making everybody angry. 

563
00:28:32,900 --> 00:28:36,700
So I think at some point you 
have to get quality over 

564
00:28:36,700 --> 00:28:40,000
quantity and you know with all 
that being said, I think it 

565
00:28:40,000 --> 00:28:41,900
really does depend on the 
organization. 

566
00:28:41,900 --> 00:28:45,800
What is the business budget 
tolerance and what is your risk 

567
00:28:45,800 --> 00:28:49,200
as an organization? 
If you're a company that has no 

568
00:28:49,200 --> 00:28:53,100
sense of data, you are not 
processing credit cards, you're 

569
00:28:53,100 --> 00:28:57,000
not holding client data. 
There's no It's information. 

570
00:28:57,200 --> 00:29:00,400
You're not going to want to 
integrate all the security tools

571
00:29:00,400 --> 00:29:03,600
that Gardener puts out there and
layer them all into your 

572
00:29:03,600 --> 00:29:05,800
development pipeline. 
You're going to be a little bit 

573
00:29:05,800 --> 00:29:08,300
more measured in that sense. 
But if you're a large 

574
00:29:08,300 --> 00:29:11,600
organization with high risk 
data, high-risk workflows, then,

575
00:29:11,600 --> 00:29:13,600
yeah, you're going to have a 
little different context. 

576
00:29:13,600 --> 00:29:17,200
But the way I usually try to 
approach it is that think about 

577
00:29:17,300 --> 00:29:20,800
what are you trying to discover?
And if you're looking to 

578
00:29:20,800 --> 00:29:24,300
discover vulnerabilities, the 
way to start with, that is in 

579
00:29:24,300 --> 00:29:28,700
those runtime type of, to Tools.
So dashed or I asked the other 

580
00:29:28,700 --> 00:29:31,700
thing is get a penetration test.
If you're going to use a 

581
00:29:31,708 --> 00:29:34,600
third-party that's fine, if you 
have people in house that can do

582
00:29:34,600 --> 00:29:37,200
it, that's great. 
But you want to find out what 

583
00:29:37,200 --> 00:29:40,900
are our surface vulnerabilities 
that we need to be concerned 

584
00:29:40,900 --> 00:29:45,000
about ones, that would actually 
show up in an environment and 

585
00:29:45,000 --> 00:29:47,700
those tools Bast. 
And I asked and using a 

586
00:29:47,708 --> 00:29:51,100
penetration testing engagement, 
will help you get that 

587
00:29:51,100 --> 00:29:55,500
information relatively quickly, 
but there's the concerns around 

588
00:29:55,500 --> 00:29:57,100
scope. 
Like that, we get everything. 

589
00:29:57,100 --> 00:30:00,200
When the application, are there 
any hidden Corners that didn't 

590
00:30:00,200 --> 00:30:04,500
get caught by the scans? 
And then SCA software 

591
00:30:04,500 --> 00:30:07,100
composition analysis. 
To me, it should always be 

592
00:30:07,100 --> 00:30:10,400
integrated. 
It's very low friction, usually 

593
00:30:10,400 --> 00:30:13,100
low cost, there are open source,
tools out there, that can help 

594
00:30:13,100 --> 00:30:15,200
you. 
You can build your own based on 

595
00:30:15,300 --> 00:30:19,600
some open apis for access to 
things like the nvd national 

596
00:30:19,600 --> 00:30:22,700
vulnerability database to get, 
just basically look at your 

597
00:30:22,700 --> 00:30:26,800
libraries and understand which 
one of these libraries He's have

598
00:30:26,900 --> 00:30:29,300
known vulnerabilities in it, 
that we need to replace. 

599
00:30:29,900 --> 00:30:33,600
And that again, to me is just 
low-hanging fruit set, aside the

600
00:30:33,600 --> 00:30:37,400
code that we're developing, the 
code that we're pulling from 

601
00:30:37,400 --> 00:30:41,200
repositories and third, parties.
Are those vulnerable and tools, 

602
00:30:41,200 --> 00:30:43,400
like, SCA will certainly help 
with that. 

603
00:30:43,600 --> 00:30:46,400
And so I think those, you know, 
the getting the surface level 

604
00:30:46,400 --> 00:30:49,400
vulnerabilities, and getting the
vulnerabilities that exist in 

605
00:30:49,400 --> 00:30:54,600
the libraries are using our core
application security planks. 

606
00:30:54,600 --> 00:30:56,500
I would say, in terms of 
building, Program. 

607
00:30:56,800 --> 00:30:59,400
And then you start turning the 
screws are a little bit looking 

608
00:30:59,400 --> 00:31:02,400
at static analysis because they 
tend to be noisy. 

609
00:31:02,400 --> 00:31:05,800
And they tend to turn out a lot 
of vulnerabilities but you can 

610
00:31:05,800 --> 00:31:09,000
integrate them in the 
development environment and if 

611
00:31:09,000 --> 00:31:11,900
you have a properly tuned, if 
you're using a good tool and if 

612
00:31:11,900 --> 00:31:15,400
you have Smart engineers and 
smart application security 

613
00:31:15,400 --> 00:31:18,600
individuals, then you can get 
some value out of those and be 

614
00:31:18,600 --> 00:31:22,100
able to try to head off things 
before they go into a production

615
00:31:22,100 --> 00:31:24,200
environment. 
Additionally, started looking at

616
00:31:24,200 --> 00:31:27,100
your training program, your 
security retraining program and 

617
00:31:27,100 --> 00:31:30,900
making sure that Engineers are 
getting the security training 

618
00:31:30,900 --> 00:31:33,900
that will help them try to 
again, reduce adding those 

619
00:31:33,900 --> 00:31:36,500
vulnerabilities. 
And last thing I would say is 

620
00:31:36,500 --> 00:31:39,300
like security Champions program,
which is really a sign of a 

621
00:31:39,300 --> 00:31:42,300
mature application security 
program when you're firing up a 

622
00:31:42,308 --> 00:31:45,800
championship program because 
that's usually where the tools 

623
00:31:45,800 --> 00:31:47,700
are integrated, you're getting 
the vulnerabilities. 

624
00:31:47,800 --> 00:31:51,200
Now, you need additional help in
trying to resolve those 

625
00:31:51,200 --> 00:31:53,400
vulnerabilities and that's kind 
of where Champions team comes 

626
00:31:53,400 --> 00:31:56,300
in. 
Yeah speaking abuzz SCA, So if I

627
00:31:56,308 --> 00:31:58,600
composition analysis, I think 
these days, I just want to 

628
00:31:58,608 --> 00:32:02,800
highlight, like we all use many 
software that are open source or

629
00:32:02,800 --> 00:32:06,100
are free to download, and it's 
not just in terms of libraries 

630
00:32:06,100 --> 00:32:08,500
or Frameworks, right? 
Sometimes also the container 

631
00:32:08,500 --> 00:32:11,500
images, your VM images, and 
things like that. 

632
00:32:11,600 --> 00:32:13,600
There are so many things that 
people have built. 

633
00:32:13,700 --> 00:32:16,200
I'm not saying that open source 
is not secure, but they are 

634
00:32:16,200 --> 00:32:19,500
always points where maybe some 
kind of hackers include some 

635
00:32:19,500 --> 00:32:22,200
kind of malicious software 
inside those open source tools. 

636
00:32:22,500 --> 00:32:25,200
And hence, having this SCA is 
actually very important. 

637
00:32:25,300 --> 00:32:28,100
And I think I I heard maybe last
time that people called it, the 

638
00:32:28,100 --> 00:32:32,100
software that you write in an 
organization, maybe even like 

639
00:32:32,100 --> 00:32:35,100
more than a half of it is 
actually coming from these open 

640
00:32:35,100 --> 00:32:36,600
source under the party 
libraries, right? 

641
00:32:36,600 --> 00:32:39,800
So that is actually the 
potential risks that you are. 

642
00:32:39,800 --> 00:32:42,800
Assuming if you use a lot of 
Open Source, software tools, 

643
00:32:42,800 --> 00:32:44,700
these are a lot of attack 
surface. 

644
00:32:44,700 --> 00:32:47,200
And speaking about maturity, you
mentioned just now. 

645
00:32:47,200 --> 00:32:50,600
When we talk about maturity it's
always coming to this maturity 

646
00:32:50,600 --> 00:32:52,600
model. 
Is there something like maturity

647
00:32:52,600 --> 00:32:56,300
model for implementing security 
program within an Action. 

648
00:32:57,100 --> 00:33:00,700
Yeah, there are beasts M and Sam
are the two that probably come 

649
00:33:00,700 --> 00:33:03,200
to mind for most people. 
And they're two different ways 

650
00:33:03,200 --> 00:33:07,300
of looking at a maturity model 
and be Sim building Security in 

651
00:33:07,400 --> 00:33:11,500
maturity model, is what be some 
stands for is looking at other 

652
00:33:11,500 --> 00:33:15,400
organizations and doing 
basically an assessment of that 

653
00:33:15,400 --> 00:33:17,000
organization and saying? 
Well, here's where this 

654
00:33:17,000 --> 00:33:20,900
organization is from the 
maturity standpoint and you as 

655
00:33:20,900 --> 00:33:23,900
your organization can then look 
at that and say well where are 

656
00:33:23,900 --> 00:33:25,400
we at? 
It's essentially measuring 

657
00:33:25,400 --> 00:33:27,900
yourself. 
I'm up against your peers and 

658
00:33:27,900 --> 00:33:30,400
understanding. 
Okay, what are the other 

659
00:33:30,400 --> 00:33:33,100
organizations of my size in my 
industry? 

660
00:33:33,400 --> 00:33:36,700
What is the one or two? 
Three things that they that 

661
00:33:36,700 --> 00:33:38,700
everybody in this category is 
doing? 

662
00:33:39,400 --> 00:33:41,900
Am I doing those things, right? 
And so that's a good way of 

663
00:33:41,900 --> 00:33:44,500
looking at, okay. 
Are we doing things that our 

664
00:33:44,500 --> 00:33:49,600
peers are doing with owasp Sam? 
That's more of classic maturity 

665
00:33:49,600 --> 00:33:52,400
model, where? 
Okay, here's the level that 

666
00:33:52,400 --> 00:33:55,500
you're starting at and here are 
the things you need to do to get

667
00:33:55,500 --> 00:33:57,800
the One and then here's the 
things you need to do to get the

668
00:33:57,800 --> 00:34:01,000
level 2 and so forth. 
And the goal there is to really 

669
00:34:01,000 --> 00:34:04,900
look at those steps in the 
maturity model and having 

670
00:34:04,900 --> 00:34:07,200
targets for where you want to 
be. 

671
00:34:07,500 --> 00:34:10,600
You may not have to be at the 
highest level of maturity. 

672
00:34:10,900 --> 00:34:12,900
Again going back to 
understanding what your 

673
00:34:12,900 --> 00:34:15,699
organization does if you're not 
processing credit cards, if 

674
00:34:15,699 --> 00:34:18,699
you're not holding client 
sensitive data and into your not

675
00:34:18,699 --> 00:34:21,199
a critical app, you don't need 
to be at the highest level. 

676
00:34:21,199 --> 00:34:23,600
Maybe level one level two is 
just fine. 

677
00:34:23,800 --> 00:34:26,800
But what that does is it allows 
you to look at That if we want 

678
00:34:26,800 --> 00:34:29,100
to get the level to hear the 
things we need to do, you can 

679
00:34:29,100 --> 00:34:31,500
build out a roadmap that says, 
here are the steps were going to

680
00:34:31,500 --> 00:34:34,300
take to get to that level. 
And here's a timeline that we're

681
00:34:34,300 --> 00:34:38,100
going to go to be there. 
Personally, I have the Derek 

682
00:34:38,100 --> 00:34:40,699
maturity model so it's a little 
different. 

683
00:34:41,199 --> 00:34:45,100
I think be Sim is more valuable 
to me than Sam. 

684
00:34:45,500 --> 00:34:48,400
And the reason is I want to know
what are the other organizations

685
00:34:48,400 --> 00:34:52,600
doing are we in line with that? 
But sometimes just having 

686
00:34:52,600 --> 00:34:55,699
conversations with your peers is
just as relevant. 

687
00:34:55,900 --> 00:34:58,400
I've had conversations with 
peers and just trying to see 

688
00:34:58,400 --> 00:35:00,700
what they're doing, compared to 
what I am doing and we'll kind 

689
00:35:00,700 --> 00:35:03,600
of exchange notes and you get 
that sense of like, hey okay 

690
00:35:03,600 --> 00:35:06,900
we're doing mostly well but at 
the same time, we had the same 

691
00:35:06,900 --> 00:35:09,800
challenges trying to figure out 
how we deal with the 

692
00:35:09,800 --> 00:35:11,700
vulnerabilities that we detect 
and so forth. 

693
00:35:11,700 --> 00:35:14,800
And just having conversations 
with your peers is just as 

694
00:35:14,800 --> 00:35:18,200
helpful I think I like the 
direction of maturity model so 

695
00:35:18,200 --> 00:35:21,100
you just even speaking in 
conferences or in networking or 

696
00:35:21,100 --> 00:35:24,700
even within PS, right? 
I think you can also maybe find 

697
00:35:24,700 --> 00:35:27,400
insights of what kind of 
security practices you should 

698
00:35:27,400 --> 00:35:29,700
include. 
And speaking about building this

699
00:35:29,700 --> 00:35:31,800
program, obviously we need 
people, right? 

700
00:35:31,800 --> 00:35:34,500
But like I mentioned in the 
beginning, sometimes the mindset

701
00:35:34,500 --> 00:35:37,500
is that we always assume 
security is somebody else's 

702
00:35:37,500 --> 00:35:38,800
problem. 
In this case, it's like 

703
00:35:38,800 --> 00:35:41,800
application security team in 
your experience. 

704
00:35:41,800 --> 00:35:44,200
How should people go about 
hiring this application? 

705
00:35:44,200 --> 00:35:46,600
Security team and what's the 
ratio size? 

706
00:35:46,800 --> 00:35:49,800
And from my experience as well, 
hiring a good security Engineers

707
00:35:49,800 --> 00:35:52,600
are really really tough, and 
it's not just that they are 

708
00:35:52,600 --> 00:35:56,500
highly in demand, but the supply
is also not that many So what 

709
00:35:56,500 --> 00:35:58,700
would you go about building the 
security teams? 

710
00:35:58,700 --> 00:36:00,800
How do we find good security 
engineers? 

711
00:36:00,800 --> 00:36:03,700
And yeah, how do we scale this 
with an organization? 

712
00:36:04,300 --> 00:36:06,800
I think the first thing to 
realize is you're never going to

713
00:36:06,808 --> 00:36:08,900
scale to what you need. 
Don't even bother. 

714
00:36:09,100 --> 00:36:12,100
It's not possible. 
I've had very large teams, I've 

715
00:36:12,100 --> 00:36:14,400
had very small teams my team 
right now. 

716
00:36:14,400 --> 00:36:17,500
I would say it's relatively 
large compared to what I've had 

717
00:36:17,500 --> 00:36:20,900
in the past and anybody that 
follows Miriam has heard me on 

718
00:36:20,900 --> 00:36:22,900
other conversations, I'll say it
again. 

719
00:36:22,900 --> 00:36:25,400
Like I could double the size of 
my team and it probably still 

720
00:36:25,400 --> 00:36:28,000
wouldn't be sufficient. 
And a lot of it is because 

721
00:36:28,000 --> 00:36:31,200
application security is very 
different than Security 

722
00:36:31,200 --> 00:36:34,000
operation centers. 
Very different than network 

723
00:36:34,000 --> 00:36:37,400
security and so forth. 
The way I always describe it is 

724
00:36:37,400 --> 00:36:40,700
that application security teams 
are the sidecar to engineering. 

725
00:36:41,000 --> 00:36:43,800
We are the ones that have to be 
part of that development 

726
00:36:43,800 --> 00:36:46,400
process, to ensure that security
is integrated. 

727
00:36:46,600 --> 00:36:49,600
Now, that doesn't mean it has to
be an individual and if it is an

728
00:36:49,600 --> 00:36:53,000
individual doesn't have to be an
application security individual,

729
00:36:53,000 --> 00:36:55,700
which is why things like 
champions. 

730
00:36:55,900 --> 00:37:01,100
G for security education. 
Programs are very helpful in the

731
00:37:01,100 --> 00:37:04,900
sense that you're helping to 
drive security education across 

732
00:37:04,900 --> 00:37:09,100
the engineering organization. 
But you are tasked with building

733
00:37:09,100 --> 00:37:12,200
an application security team, it
comes down to asking the 

734
00:37:12,200 --> 00:37:13,700
question. 
What do we want to do? 

735
00:37:13,900 --> 00:37:18,300
Do we want to just be a team of 
penetration testers? 

736
00:37:18,300 --> 00:37:23,200
Do we want to just be a team of 
Engineers that are working with 

737
00:37:23,200 --> 00:37:25,700
the developers in engineering 
and helping? 

738
00:37:25,800 --> 00:37:29,800
Them to create secure code, do 
we just want to integrate tools 

739
00:37:29,800 --> 00:37:32,300
and not do anything other than 
create integrate tools? 

740
00:37:32,300 --> 00:37:34,300
Find, vulnerabilities, and tell 
some a go fix them. 

741
00:37:34,600 --> 00:37:37,400
So it really comes down to 
understanding what is your 

742
00:37:37,400 --> 00:37:41,400
organization going to tolerate 
and what are the actual needs 

743
00:37:41,500 --> 00:37:43,900
for the team? 
So every organization is going 

744
00:37:43,900 --> 00:37:47,000
to have a different kind of view
on that and it really comes down

745
00:37:47,000 --> 00:37:49,800
to understanding. 
What is the budget, tolerance? 

746
00:37:49,800 --> 00:37:52,400
What is the need from an 
organization perspective? 

747
00:37:52,700 --> 00:37:57,400
And what is the road map for the
And security team is it again 

748
00:37:57,400 --> 00:38:00,100
just developing integrating 
tools and finding 

749
00:38:00,100 --> 00:38:02,700
vulnerabilities. 
Do we want to get more proactive

750
00:38:02,700 --> 00:38:05,700
in terms of blue, teaming and 
purple, teaming and red, teaming

751
00:38:05,700 --> 00:38:08,700
to determine discover those 
vulnerabilities or are we just 

752
00:38:08,700 --> 00:38:10,900
going to stick to architecture 
and design? 

753
00:38:11,000 --> 00:38:14,300
So there's a lot of different 
ways of tackling that but again,

754
00:38:14,300 --> 00:38:18,600
I go back to my first comment is
that being able to hire the 

755
00:38:18,600 --> 00:38:21,500
quote unquote, right size in 
terms of individuals that you're

756
00:38:21,500 --> 00:38:23,700
not going to do it. 
And I don't recall the numbers 

757
00:38:23,700 --> 00:38:25,700
off the top of my head, but I 
know be simple. 

758
00:38:25,800 --> 00:38:29,100
Had some numbers around what is 
the right size but again, it 

759
00:38:29,100 --> 00:38:31,900
varies it could be for every 
engineer. 

760
00:38:31,900 --> 00:38:34,900
You have or for every 100 
Engineers, you have one knapsack

761
00:38:34,900 --> 00:38:36,800
person for every 50, you have 
one. 

762
00:38:36,800 --> 00:38:40,700
It really depends on the 
organization but when it comes 

763
00:38:40,700 --> 00:38:43,300
down to hiring, one of the 
things that I typically try to 

764
00:38:43,300 --> 00:38:46,200
look for is somebody that has 
some type of development 

765
00:38:46,200 --> 00:38:49,600
background because if you can 
speak the language with the 

766
00:38:49,600 --> 00:38:51,700
development team, then, you 
know, you're already at a 

767
00:38:51,700 --> 00:38:55,200
disadvantage, not that you can 
be an application security 

768
00:38:55,200 --> 00:38:57,300
because obviously, We have 
plenty of people that didn't 

769
00:38:57,300 --> 00:39:00,300
come out of development that are
in application security but it's

770
00:39:00,300 --> 00:39:03,500
certainly helpful to have those 
individuals on your team to be 

771
00:39:03,500 --> 00:39:06,500
able to really translate these 
vulnerabilities that come out of

772
00:39:06,500 --> 00:39:09,000
these tools and penetration 
testing and go back to the 

773
00:39:09,000 --> 00:39:11,900
development team and say, 
looking at your code, here's 

774
00:39:11,900 --> 00:39:14,800
exactly what the problem is. 
And here's exactly how you can 

775
00:39:14,800 --> 00:39:18,000
resolve it. 
I think that goes a long way, 

776
00:39:18,200 --> 00:39:21,100
not just in making the 
organization more secure and 

777
00:39:21,100 --> 00:39:22,600
making the application more 
secure. 

778
00:39:22,800 --> 00:39:25,400
But also building that 
relationship between 

779
00:39:25,400 --> 00:39:28,200
development, I meant team and 
the application security team 

780
00:39:28,200 --> 00:39:29,800
where we both understand each 
other. 

781
00:39:29,800 --> 00:39:32,400
Therefore, we're on somewhat 
Common Ground there. 

782
00:39:32,600 --> 00:39:35,600
So I do, typically look for 
people that have either come out

783
00:39:35,600 --> 00:39:38,800
of the development space or have
some type of development 

784
00:39:38,800 --> 00:39:41,500
background. 
I would say that I agree with 

785
00:39:41,500 --> 00:39:43,900
your opinion as well, that we 
should hire a security engineer 

786
00:39:43,900 --> 00:39:45,400
with some development 
background. 

787
00:39:45,400 --> 00:39:48,000
What I find in the industry. 
Typically is, there are so many 

788
00:39:48,000 --> 00:39:52,000
security so-called experts, but 
they are mainly specialize in 

789
00:39:52,000 --> 00:39:53,800
tools. 
Like, I'm a specialist of these 

790
00:39:53,800 --> 00:39:55,600
tools. 
I know how to implement these 

791
00:39:55,600 --> 00:39:57,600
two. 
And use it, but not necessarily 

792
00:39:57,600 --> 00:40:00,300
going back into the development 
lifecycle and even advising 

793
00:40:00,300 --> 00:40:02,000
developers. 
Okay, you should not do this or 

794
00:40:02,000 --> 00:40:05,200
even looking at the code, right?
How things should be prevented 

795
00:40:05,200 --> 00:40:07,500
in the first place? 
So I think you're having this 

796
00:40:07,500 --> 00:40:09,700
kind of knowledge of 
development, background will be 

797
00:40:09,700 --> 00:40:10,700
first of all like you mentioned,
right? 

798
00:40:10,700 --> 00:40:13,800
Build a good relationship. 
But obviously if we can prevent 

799
00:40:13,800 --> 00:40:17,000
security issues in the earlier, 
phase again, coming back to the 

800
00:40:17,000 --> 00:40:19,300
shift left. 
I think that makes a lot more 

801
00:40:19,300 --> 00:40:21,800
impact. 
So speaking about doing this 

802
00:40:21,800 --> 00:40:24,600
security program, building some 
kind of roadmap understanding, 

803
00:40:24,600 --> 00:40:26,800
what do we want out of? 
This security team. 

804
00:40:26,800 --> 00:40:29,700
And if we have established, this
security team, what could be a 

805
00:40:29,700 --> 00:40:32,800
good indicator of success? 
What are the measurement of 

806
00:40:32,800 --> 00:40:34,600
success? 
How should you evaluate? 

807
00:40:34,600 --> 00:40:36,800
Is it just by number of 
findings? 

808
00:40:36,900 --> 00:40:39,500
Or is it just number of security
breaches incidents? 

809
00:40:39,600 --> 00:40:42,200
Or is there any other 
measurement that you advise 

810
00:40:42,200 --> 00:40:44,600
people to look at for measuring 
the success? 

811
00:40:45,400 --> 00:40:49,200
Yeah, I think there's two main 
ones that I would focus on one 

812
00:40:49,200 --> 00:40:52,200
is for the downward trend on 
vulnerabilities. 

813
00:40:52,300 --> 00:40:55,400
Not upward again, we have no 
problem, finding vulnerabilities

814
00:40:55,400 --> 00:40:58,900
we can Find them all day every 
day, but it's really, are we 

815
00:40:58,900 --> 00:41:02,300
moving the needle on reducing 
that backlog that to me is 

816
00:41:02,300 --> 00:41:07,400
better indicator of a security 
program where we're ducing that 

817
00:41:07,400 --> 00:41:10,600
backlog, not adding to it. 
And to be honest there's been 

818
00:41:10,600 --> 00:41:15,600
times where we've had scans done
or tests done and there weren't 

819
00:41:15,600 --> 00:41:19,100
any vulnerabilities that were 
found and all of us that work in

820
00:41:19,100 --> 00:41:22,500
the security space here like 
that I call BS on that. 

821
00:41:22,500 --> 00:41:25,400
That's why there's no way and 
you kind of second guess 

822
00:41:25,400 --> 00:41:27,100
yourself. 
I swear, it's like, wait, that 

823
00:41:27,100 --> 00:41:28,400
can't be right. 
You know, there's got to be 

824
00:41:28,400 --> 00:41:31,300
something. 
And after seeing several of 

825
00:41:31,300 --> 00:41:33,000
those I'm starting to come 
around to the idea is like, 

826
00:41:33,000 --> 00:41:35,500
well, hey maybe the program is 
working, you know, maybe we're 

827
00:41:35,500 --> 00:41:38,200
actually stopping these things 
from going out and that's a good

828
00:41:38,200 --> 00:41:39,700
thing. 
But like I said, all of us in 

829
00:41:39,700 --> 00:41:42,500
the security space immediately 
when you see a scan, the comes 

830
00:41:42,500 --> 00:41:44,300
back with no results. 
You're like, wait a minute, that

831
00:41:44,300 --> 00:41:47,100
can't be right. 
But yeah, I think it's always. 

832
00:41:47,100 --> 00:41:49,100
You can validate that know. 
This is right. 

833
00:41:49,200 --> 00:41:51,700
I think that's a good indication
as well as that the program is 

834
00:41:51,707 --> 00:41:53,800
working, right? 
We're not finding things as 

835
00:41:53,800 --> 00:41:55,700
much. 
We're not adding to the backlog.

836
00:41:55,800 --> 00:41:58,300
Reducing it. 
I think the other thing too is 

837
00:41:58,300 --> 00:42:00,800
something I'll steal from the 
operational spaces. 

838
00:42:00,800 --> 00:42:03,200
You know? 
Meantime to remediation how 

839
00:42:03,200 --> 00:42:05,200
quickly are we resolved in those
vulnerabilities. 

840
00:42:05,200 --> 00:42:08,700
Do we have vulnerabilities that 
are sitting out there for weeks 

841
00:42:08,700 --> 00:42:11,700
months maybe even years? 
If that's the case, that's the 

842
00:42:11,700 --> 00:42:14,500
problem and there's a couple 
things with that especially ones

843
00:42:14,500 --> 00:42:17,800
that are very long. 
Lasting vulnerabilities, past 

844
00:42:17,800 --> 00:42:20,400
several months or even a year or
more. 

845
00:42:20,700 --> 00:42:23,000
If they ask question, is this 
even still a valid issue of 

846
00:42:23,000 --> 00:42:25,200
something that's been out there 
that long that there's something

847
00:42:25,200 --> 00:42:28,800
not Right there, but I think 
looking at the amount of time 

848
00:42:28,800 --> 00:42:31,800
that it takes to actually 
remediate a vulnerability is 

849
00:42:31,800 --> 00:42:35,100
also critical indicator of how 
successful the program is. 

850
00:42:35,100 --> 00:42:37,800
Because again, we can find 
vulnerabilities all day but if 

851
00:42:37,800 --> 00:42:40,900
critical vulnerability is found 
and we're able to remediate that

852
00:42:40,900 --> 00:42:44,600
within a few hours or a day or 
two or something like that, it's

853
00:42:44,600 --> 00:42:47,000
very strong indicator that your 
program is humming along the 

854
00:42:47,000 --> 00:42:47,600
way. 
It should. 

855
00:42:48,200 --> 00:42:49,600
Yeah. 
Speaking about remediation, I 

856
00:42:49,607 --> 00:42:52,600
think the ultimate thing will be
the zero day vulnerabilities, 

857
00:42:52,600 --> 00:42:54,200
right? 
Whenever it's found. 

858
00:42:54,300 --> 00:42:57,100
And how long does it take for 
The organization to actually 

859
00:42:57,100 --> 00:42:59,600
take an action. 
May be in your opinion, you are 

860
00:42:59,600 --> 00:43:01,500
in the security space a lot 
more. 

861
00:43:01,500 --> 00:43:04,100
How should people build this 
kind of zeroed a capability? 

862
00:43:04,600 --> 00:43:08,000
Yeah, I think that comes down to
that mean time to remediation, 

863
00:43:08,000 --> 00:43:10,600
right? 
I'll go back to the sca example,

864
00:43:10,600 --> 00:43:14,600
the software composition, we can
develop software and you can 

865
00:43:14,600 --> 00:43:18,200
have zero vulnerabilities when 
that the software goes out into 

866
00:43:18,200 --> 00:43:20,900
production. 
The next day, some component 

867
00:43:20,900 --> 00:43:24,300
that we pulled in from a 
repository could be vulnerable. 

868
00:43:24,300 --> 00:43:26,900
Whether it's a zero day or 
whether Saint identified public 

869
00:43:26,900 --> 00:43:28,600
vulnerability. 
Either way, it's vulnerable, 

870
00:43:28,700 --> 00:43:30,600
right? 
And you did everything right 

871
00:43:30,600 --> 00:43:33,700
time will result in 
vulnerabilities being found. 

872
00:43:33,900 --> 00:43:38,900
And so, it really comes down to 
how your process is in place to 

873
00:43:38,900 --> 00:43:40,600
take those vulnerabilities that 
have been discovered in a 

874
00:43:40,600 --> 00:43:43,100
production environment and get a
remediation out the door. 

875
00:43:43,100 --> 00:43:45,600
And in short period of time, 
that goes back to that mean, 

876
00:43:45,600 --> 00:43:49,200
time to remediation, where if we
find an issue in production and 

877
00:43:49,200 --> 00:43:53,100
we're able to get a remediation 
push to production in a very 

878
00:43:53,100 --> 00:43:56,100
short period of time, that could
be hours, that could be He's 

879
00:43:56,200 --> 00:43:58,900
could be week or so. 
Then great that means that your 

880
00:43:58,900 --> 00:44:02,000
programs is again doing very 
well, something that we didn't 

881
00:44:02,000 --> 00:44:04,700
really touch on and it's not 
because I was ignoring it, but 

882
00:44:04,700 --> 00:44:08,100
runtime protection, there are 
tools out there whether it's 

883
00:44:08,100 --> 00:44:11,500
laughs web application firewall 
or runtime application security 

884
00:44:11,500 --> 00:44:14,200
protection. 
Those also go a long way and 

885
00:44:14,200 --> 00:44:17,900
being able to provide some cover
for a period of time until you 

886
00:44:17,900 --> 00:44:19,900
can get that remediation out the
door. 

887
00:44:20,300 --> 00:44:23,400
So there's a lot of levers that 
we can kind of pull from a 

888
00:44:23,400 --> 00:44:26,500
security perspective to ensure 
that we are Are providing that 

889
00:44:26,500 --> 00:44:29,400
protection against especially 
things like zero days, where 

890
00:44:29,400 --> 00:44:32,200
something like runtime 
protection does come into play 

891
00:44:32,400 --> 00:44:35,200
because it allows you to do 
virtual patching, that allows 

892
00:44:35,200 --> 00:44:38,400
you to potentially stop any 
malicious activity. 

893
00:44:38,400 --> 00:44:41,700
Until you get code out the door,
thanks for the plug for the 

894
00:44:41,700 --> 00:44:44,000
runtime, the Woof, and all these
things. 

895
00:44:44,000 --> 00:44:46,800
So I think that sometimes can be
very useful, especially if you 

896
00:44:46,800 --> 00:44:49,700
are being attacked as well DDOS.
For example, when suddenly 

897
00:44:49,700 --> 00:44:52,900
somebody from the internet, just
Target your system. 

898
00:44:53,100 --> 00:44:55,600
So having this kind of run time,
protection definitely is very 

899
00:44:55,700 --> 00:44:57,200
Spoil. 
If you don't have it, please 

900
00:44:57,200 --> 00:44:59,200
Implement that as soon as 
possible. 

901
00:44:59,700 --> 00:45:01,600
So direct has been a great 
conversation. 

902
00:45:01,600 --> 00:45:03,800
Learning about security is very 
exciting as well. 

903
00:45:03,900 --> 00:45:06,700
Unfortunately, we reach the end 
of our conversation but I have 

904
00:45:06,700 --> 00:45:08,800
one last question that I 
normally ask for all my guests 

905
00:45:08,800 --> 00:45:11,000
which I call the tree technical 
leadership, wisdom. 

906
00:45:11,200 --> 00:45:13,400
So think of it just like an 
advice that you want to give to 

907
00:45:13,400 --> 00:45:15,600
the listeners here. 
Maybe if you can share us your 

908
00:45:15,600 --> 00:45:18,400
version of three. 
Technical leadership wisdom here

909
00:45:18,400 --> 00:45:22,300
I think one is stay curious. 
One thing with technology is 

910
00:45:22,300 --> 00:45:23,300
that it's always changing, 
right? 

911
00:45:23,300 --> 00:45:26,600
And the prime example, 
everyone's on the A I trained 

912
00:45:26,600 --> 00:45:29,500
right now where it's everywhere.
It's inescapable and everyone's 

913
00:45:29,500 --> 00:45:31,800
trying to figure out what to do 
with it and it's just a prime 

914
00:45:31,800 --> 00:45:34,700
example of how things change. 
And I think there's a lot of 

915
00:45:34,707 --> 00:45:37,000
people trying to figure out, is 
this a danger or is this going 

916
00:45:37,000 --> 00:45:39,500
to be helpful? 
I think there's pluses minuses. 

917
00:45:39,500 --> 00:45:41,100
There's two sides that it's just
again. 

918
00:45:41,100 --> 00:45:43,700
It's an example of where 
technology is always changing. 

919
00:45:44,000 --> 00:45:46,500
One of the things with my 
application Security in general 

920
00:45:46,500 --> 00:45:50,600
or more specifically, is that we
have to stay up to speed with 

921
00:45:50,600 --> 00:45:53,000
what developments doing. 
You know, the things that we 

922
00:45:53,000 --> 00:45:55,900
were doing five years ago, or 
vastly different than what Doing

923
00:45:55,900 --> 00:45:58,200
today. 
And so you have to be able to 

924
00:45:58,207 --> 00:46:01,800
stay curious. 
Stay engaged and be able to know

925
00:46:01,800 --> 00:46:03,700
where the new technology is 
heading. 

926
00:46:04,400 --> 00:46:08,000
I think the other thing is be a 
mentor if you can or be able to 

927
00:46:08,100 --> 00:46:11,600
help others again especially in 
this space with security Henry 

928
00:46:11,600 --> 00:46:15,000
mentioned earlier about how 
there's a lot of openings in 

929
00:46:15,000 --> 00:46:18,700
security and we're having 
trouble filling them and I think

930
00:46:18,700 --> 00:46:21,800
we need help in this space. 
We definitely need people that 

931
00:46:21,800 --> 00:46:26,400
want to get into security and I 
think being able to to help 

932
00:46:26,400 --> 00:46:29,700
Mentor people and be able to 
bring them into this space is 

933
00:46:29,700 --> 00:46:32,300
going to help all of us. 
So find somebody that might be 

934
00:46:32,300 --> 00:46:35,200
interested in security and try 
to help them along the way. 

935
00:46:35,500 --> 00:46:37,300
I guess. 
The last point I would make is I

936
00:46:37,300 --> 00:46:40,100
know, we were kind of sorted on 
the same thing with in terms of 

937
00:46:40,100 --> 00:46:43,900
hiring and Staffing but 
certifications aren't always the

938
00:46:43,900 --> 00:46:46,500
answer. 
I know that I could probably sit

939
00:46:46,500 --> 00:46:49,400
down and probably take the 
certification test and pass it 

940
00:46:49,400 --> 00:46:51,200
today without studying on many 
of these. 

941
00:46:51,400 --> 00:46:54,300
That doesn't mean that I've 
achieved anything, right? 

942
00:46:54,300 --> 00:46:56,500
I'm not saying certifications. 
Long or anything like that 

943
00:46:56,500 --> 00:46:59,100
because there's definitely value
and certifications. 

944
00:46:59,100 --> 00:47:01,500
I know a lot of organizations 
look, specifically for 

945
00:47:01,500 --> 00:47:03,600
certifications to make a hiring 
decision. 

946
00:47:03,800 --> 00:47:07,100
But what I've often found is 
that I like studying for 

947
00:47:07,100 --> 00:47:10,600
certifications whether I take 
the exam or not because I had to

948
00:47:10,600 --> 00:47:13,300
learn from that. 
I think especially in this 

949
00:47:13,300 --> 00:47:16,000
space, we see a lot of people 
that just want to get into 

950
00:47:16,000 --> 00:47:18,500
security and the first question 
is, which certification should I

951
00:47:18,500 --> 00:47:20,400
take? 
And it's like well you don't 

952
00:47:20,400 --> 00:47:23,000
necessarily have to get a 
certification in order to get 

953
00:47:23,000 --> 00:47:24,700
into space. 
I mean you need to know 

954
00:47:24,700 --> 00:47:27,100
something, right? 
So So start dabbling start 

955
00:47:27,100 --> 00:47:29,900
getting involved when you're 
looking at application security,

956
00:47:29,900 --> 00:47:32,800
specifically start understanding
how software is developed. 

957
00:47:32,900 --> 00:47:36,800
Start understanding about cicp 
pipelines and integrating tools 

958
00:47:36,800 --> 00:47:40,100
and how code gets delivered and 
deployed and maintained. 

959
00:47:40,400 --> 00:47:44,100
If you're looking into getting 
into other aspects of security, 

960
00:47:44,100 --> 00:47:46,700
you know, start understanding 
those different corners and 

961
00:47:46,700 --> 00:47:50,700
really, really understand it, 
not just understand enough to 

962
00:47:50,700 --> 00:47:54,800
pass an exam, so that's my 
advice, right? 

963
00:47:54,900 --> 00:47:56,500
Thank you for including The 
certifications. 

964
00:47:56,500 --> 00:47:58,700
Yeah, I think now that you 
mention it, I'm very aware that 

965
00:47:58,700 --> 00:48:01,900
a lot of people in the security 
space ones to collect so-called 

966
00:48:01,900 --> 00:48:04,800
certifications right there. 
So many security organizations 

967
00:48:04,800 --> 00:48:06,900
and things like that and people 
tend to chase these 

968
00:48:06,900 --> 00:48:08,800
certifications or but it like 
you mentioned, right? 

969
00:48:08,800 --> 00:48:10,300
It's always about the 
practicality. 

970
00:48:10,500 --> 00:48:12,700
It's not just the knowledge 
only, you can accumulate all 

971
00:48:12,700 --> 00:48:14,900
this knowledge but the 
practicality I think, is the 

972
00:48:14,900 --> 00:48:17,200
most important. 
Like, how do you actually deal 

973
00:48:17,200 --> 00:48:19,800
with security, vulnerabilities, 
or even prevent it from the 

974
00:48:19,800 --> 00:48:23,400
development life cycle? 
So directly, people enjoy this 

975
00:48:23,400 --> 00:48:25,500
composition, they would want to 
learn from you. 

976
00:48:25,600 --> 00:48:27,800
Maybe the directs maturity 
model, right? 

977
00:48:27,800 --> 00:48:31,300
Is there a place where they can 
find you online here on, try to 

978
00:48:31,300 --> 00:48:34,100
stay pretty active on LinkedIn? 
Like I said, I'd stay pretty 

979
00:48:34,100 --> 00:48:37,600
busy but I try to get on 
LinkedIn and post and things 

980
00:48:37,600 --> 00:48:40,700
like that and I've been creating
some content that I've been 

981
00:48:40,700 --> 00:48:42,100
releasing. 
Anybody that's been following me

982
00:48:42,100 --> 00:48:44,500
on LinkedIn will see that. 
But yeah, the best way to get 

983
00:48:44,500 --> 00:48:47,200
ahold of me as on LinkedIn. 
I've seen some of your YouTube 

984
00:48:47,200 --> 00:48:49,200
videos. 
I think that's really cool and 

985
00:48:49,200 --> 00:48:51,500
fun. 
So yeah, maybe people should 

986
00:48:51,500 --> 00:48:53,900
check those out as well. 
So thank you again Derek for 

987
00:48:53,900 --> 00:48:56,200
this opportunity. 
I'll really Learn a lot from 

988
00:48:56,200 --> 00:48:59,700
security the conversation today 
and I hope people do as well. 

989
00:48:59,700 --> 00:49:01,100
So thank you for that. 
Thank you. 

990
00:49:05,000 --> 00:49:08,300
Thank you for listening to this 
episode and for staying, right 

991
00:49:08,300 --> 00:49:10,800
until the end if you highly 
enjoyed it. 

992
00:49:10,900 --> 00:49:13,200
I would appreciate if you share 
it with your friends and 

993
00:49:13,200 --> 00:49:16,200
colleagues who you think would 
also benefit from listening to 

994
00:49:16,200 --> 00:49:18,300
this episode. 
And if you are new to the 

995
00:49:18,300 --> 00:49:21,200
podcast, make sure to subscribe 
and leave me your valuable 

996
00:49:21,200 --> 00:49:24,300
review and feedback. 
It helps me a lot in order to 

997
00:49:24,300 --> 00:49:27,500
grow this podcast better. 
You can also find the full show 

998
00:49:27,500 --> 00:49:30,900
notes of this conversation on 
the episode page at technology, 

999
00:49:30,900 --> 00:49:34,800
not death website, including the
full transcript and Arresting 

1000
00:49:34,800 --> 00:49:37,700
courts and links to the 
resources mention from the 

1001
00:49:37,700 --> 00:49:40,600
conversation. 
And lastly make sure to 

1002
00:49:40,600 --> 00:49:43,800
subscribe to the show's mailing 
list on tackling Journal dot f 

1003
00:49:44,000 --> 00:49:46,500
to get notified for any future 
episodes. 

1004
00:49:46,900 --> 00:49:49,400
Stay tuned for the next package 
you know, episode. 

1005
00:49:49,700 --> 00:49:36,000
And until then goodbye. 
Arresting courts and links to 

1006
00:49:36,000 --> 00:49:38,500
the resources mention from the 
conversation. 

1007
00:49:38,900 --> 00:49:41,900
And lastly make sure to 
subscribe to the show's mailing 

1008
00:49:41,900 --> 00:49:45,700
list on tackling Journal dot f 
to get notified for any future 

1009
00:49:45,700 --> 00:49:48,400
episodes. 
Stay tuned for the next package 

1010
00:49:48,400 --> 00:49:51,300
you know, episode. 
And until then goodbye.