1
00:00:07,840 --> 00:00:13,340
Thank you all for joining us for Not All Alerts Born Equal, guys.

2
00:00:13,880 --> 00:00:20,860
And today, I'm very excited to moderate this panel.

3
00:00:21,340 --> 00:00:24,980
And I'm actually going to interview this top professional.

4
00:00:24,980 --> 00:00:31,500
But even before we start, maybe we had a change in staffing.

5
00:00:31,840 --> 00:00:36,000
So we were supposed to have Kunal from Sentinel-1.

6
00:00:36,620 --> 00:00:41,100
And before that, I told him, Kunal, break a leg before that.

7
00:00:41,100 --> 00:00:42,860
And he actually broke his leg.

8
00:00:43,220 --> 00:00:45,720
And he went back home, flying back home.

9
00:00:45,720 --> 00:00:52,820
And I appreciate the fact that Kiran was able to fill in so immediately and promptly.

10
00:00:52,820 --> 00:00:54,700
So thank you so much.

11
00:00:54,920 --> 00:01:01,560
And of course, to the amazing team of the APSEC village for accommodating all these changes so fast.

12
00:01:01,640 --> 00:01:04,420
So with no further ado, my name is Shachar Mann.

13
00:01:04,420 --> 00:01:07,720
I'm the co-founder and CEO of Backslash Security.

14
00:01:07,780 --> 00:01:14,920
Previously, I was building from scratch the engineering and product team of a company called Aqua Security.

15
00:01:14,920 --> 00:01:22,560
With some nice open sources we put out there, like Trivy and Cubebench, et cetera, for the community.

16
00:01:22,560 --> 00:01:24,940
And now I started my own company, Backslash.

17
00:01:24,940 --> 00:01:27,460
It's more about application security.

18
00:01:28,520 --> 00:01:33,120
But let's start with our panelists.

19
00:01:33,960 --> 00:01:36,180
We start with Tripti.

20
00:01:36,280 --> 00:01:41,460
So Tripti is a senior engineering product security manager at Datadog.

21
00:01:41,880 --> 00:01:49,600
A mobile developer turned APSEC partitioner with 18 plus years of software security experience.

22
00:01:49,680 --> 00:01:56,060
Now, she believes security and mindfulness go hand in hand.

23
00:01:56,060 --> 00:02:01,440
The fun fact about her, she just came back from a 10 days vipassana.

24
00:02:01,440 --> 00:02:06,720
So she was not speaking in the last, I don't know, 10 days.

25
00:02:06,740 --> 00:02:08,820
I hope you can speak today, Tripti.

26
00:02:08,880 --> 00:02:10,440
I'll try my level best.

27
00:02:10,440 --> 00:02:11,180
Okay.

28
00:02:11,180 --> 00:02:12,720
Yeah, she's back.

29
00:02:14,400 --> 00:02:16,000
And then Kiran.

30
00:02:16,600 --> 00:02:21,080
Kiran is responsible for the security engineering function at eBay.

31
00:02:21,420 --> 00:02:25,200
He's been in the space of security for over 10 years.

32
00:02:25,200 --> 00:02:29,800
Works closely with the eBay security incident response function.

33
00:02:29,800 --> 00:02:36,460
And also works in the space of APSEC and offensive security for eBay.

34
00:02:36,800 --> 00:02:38,780
Last one, Joe.

35
00:02:38,780 --> 00:02:40,040
Joe Christian.

36
00:02:40,560 --> 00:02:46,240
Currently serves as the engineering manager for the DevSecOps platforms team at Paylocity.

37
00:02:46,240 --> 00:02:51,120
Previously, Joe held leadership positions at Brex and Zappos.

38
00:02:51,120 --> 00:02:58,460
Joe is also a cyber defense PhD student at Dakota State University, as you can read on his T-shirt.

39
00:02:59,200 --> 00:03:06,420
When not worrying about security, you can find Joe hiking various national parks across the U.S.

40
00:03:06,420 --> 00:03:10,640
So let's give them all a shout out and let's just...

41
00:03:13,650 --> 00:03:18,710
So let's start, you know, with your vast experience in the industry.

42
00:03:18,710 --> 00:03:20,670
Maybe a question to all of you.

43
00:03:21,460 --> 00:03:31,630
What kind of security best practices you use today which you found efficient in your daily work, especially when it comes to APSEC alerts?

44
00:03:31,630 --> 00:03:33,110
So many of them.

45
00:03:34,510 --> 00:03:36,450
Hi, everyone.

46
00:03:36,590 --> 00:03:39,690
How are you all doing here at Vegas?

47
00:03:42,670 --> 00:03:45,250
Can I have a bigger shout out?

48
00:03:46,510 --> 00:03:48,350
There you go.

49
00:03:48,350 --> 00:04:12,070
So in last 18 years, during my software security or application security career, I must have tried to use at least 25 plus security scanners product, security testing tools, ranging from, you know, static code analysis, dynamic application security testing,

50
00:04:12,070 --> 00:04:16,950
cloud security posture management, interactive application security tooling.

51
00:04:16,950 --> 00:04:17,810
Oh, my God.

52
00:04:17,810 --> 00:04:20,230
And I can go on and on.

53
00:04:20,230 --> 00:04:21,650
And guess what?

54
00:04:21,850 --> 00:04:33,650
During my early career years, I experienced so much fatigue of these security alerts and security findings that I quit my job twice.

55
00:04:34,130 --> 00:04:37,990
And that's when I realized, well, quitting is not going to help.

56
00:04:37,990 --> 00:04:46,130
No matter where I go, which company I join, the tools I use, the situation is pretty much going to be the same.

57
00:04:46,130 --> 00:04:57,030
That's when I put on my creative, innovative hat and started looking into how can I manage this avalanche of security alerts findings.

58
00:04:57,210 --> 00:05:01,370
And the first thing, which is obvious, is the risk severity.

59
00:05:01,370 --> 00:05:02,950
But that's not the way to go.

60
00:05:02,950 --> 00:05:11,590
I started focusing more on the exploitation share, which ones of these are actually exploitable versus not.

61
00:05:11,590 --> 00:05:16,310
I can give a breather to my developers if something is not exploitable.

62
00:05:16,310 --> 00:05:24,130
Then the second thing is blast radius, how much it's going to take to remediate, what are the efforts really required.

63
00:05:24,130 --> 00:05:31,810
So, yeah, these were some of the simple techniques that I could come up with after talking to the development team.

64
00:05:31,810 --> 00:05:41,890
And we could mutually agree which ones are the prioritized findings that we need to knock down right away and which ones we can simply wait.

65
00:05:42,790 --> 00:05:43,550
Great.

66
00:05:43,550 --> 00:05:45,290
Kiran, same question.

67
00:05:45,490 --> 00:05:46,830
That's really cool.

68
00:05:46,830 --> 00:05:52,390
So actually on similar lines, the company I work for, scale is a huge, huge problem.

69
00:05:52,390 --> 00:06:06,370
So being as close to your developers is a formula that has worked for us in integrating with CI, CD pipelines, making sure that the alerts are in the hands of the right people, running the right tool at the right time.

70
00:06:06,390 --> 00:06:09,050
Also, just don't throw everything at them.

71
00:06:09,050 --> 00:06:17,370
Make sure that it is actionable, that there is something that they can do, they understand it, have that relationship and negotiation.

72
00:06:17,370 --> 00:06:19,850
That's worked for us fairly well.

73
00:06:21,730 --> 00:06:24,510
I'm probably the one jaded person here.

74
00:06:24,510 --> 00:06:33,970
I think just working in security generally, there's a lot of new technologies that constantly evolve and emerge.

75
00:06:33,970 --> 00:06:36,970
At the end of the day, it's focusing on the basics.

76
00:06:37,170 --> 00:06:42,190
So we constantly hear asset management, asset management, asset management.

77
00:06:42,370 --> 00:06:46,990
But how many of you actually know what's on your network, what's on your perimeter, what's going on?

78
00:06:46,990 --> 00:06:47,870
You probably don't.

79
00:06:47,870 --> 00:06:49,530
You've probably tried to do a CMDB.

80
00:06:49,530 --> 00:06:50,830
It's gone horrible.

81
00:06:51,550 --> 00:07:01,030
So it's really hard, but I think when you're looking at alerts, it's why is this alert tied to this particular system important, right?

82
00:07:01,030 --> 00:07:02,590
Is there PII on the system?

83
00:07:02,590 --> 00:07:05,450
Is it publicly exposed?

84
00:07:05,450 --> 00:07:12,570
There is a science to it, but I think where most folks get tripped up is they're like, oh, I'm worried about containers, I'm worried about XYZ.

85
00:07:12,570 --> 00:07:14,510
Really, I think it's just about the basics.

86
00:07:14,770 --> 00:07:17,710
Do you know what you have on your network?

87
00:07:17,870 --> 00:07:19,130
Can you secure it?

88
00:07:19,130 --> 00:07:22,470
I mean, there's dozens and dozens of different guidelines, right?

89
00:07:22,470 --> 00:07:24,650
There's NIST guidance, there's OAuth guidance.

90
00:07:24,970 --> 00:07:26,350
All says the same thing.

91
00:07:26,350 --> 00:07:29,890
You got to know your assets, got to harden it, do your thing.

92
00:07:29,890 --> 00:07:34,830
So, I mean, that would be my kind of primer, but I'm kind of jaded.

93
00:07:34,830 --> 00:07:36,570
So start with that.

94
00:07:36,930 --> 00:07:37,650
Absolutely.

95
00:07:37,650 --> 00:07:39,450
That's all great ideas.

96
00:07:39,450 --> 00:07:48,030
So maybe, Tupti, we go back to you and go even deeper with the reason you quit your job twice.

97
00:07:49,750 --> 00:07:53,930
So alert fatigue is a common challenge for security teams.

98
00:07:53,930 --> 00:08:01,490
How do you address this issue and prevent alert overload, ensuring your team can focus on the most important alerts?

99
00:08:01,710 --> 00:08:05,740
Acknowledging you're not being able to get to all of them.

100
00:08:05,740 --> 00:08:13,080
Yeah, so I'm sure how many of you are security engineers here versus developers?

101
00:08:13,080 --> 00:08:14,760
Security engineers, raise your hands.

102
00:08:14,760 --> 00:08:17,140
Okay, developers, please raise your hand.

103
00:08:18,100 --> 00:08:21,500
Okay, we have quite a few developers as well.

104
00:08:22,140 --> 00:08:31,660
So honestly speaking, the truth about security industry is most of the security tools are there in their first generation.

105
00:08:31,660 --> 00:08:37,040
And as a result, they have built tools that work.

106
00:08:37,280 --> 00:08:41,880
They have not built tools keeping the context in mind.

107
00:08:42,580 --> 00:08:59,920
If we consider the context of the application, the assets that we are trying to protect, context around the data that we are trying to protect, what we experience is suddenly the huge avalanche of alert goes significantly down.

108
00:08:59,920 --> 00:09:12,660
Then the next prioritization, once we focus on our crown jewels, is try to identify if this is something public facing or internal facing.

109
00:09:12,660 --> 00:09:19,920
Now in today's era, just like any other state actor, even malicious insider is a big threat, right?

110
00:09:19,920 --> 00:09:21,000
Do you agree with me?

111
00:09:21,020 --> 00:09:22,300
Yes.

112
00:09:22,300 --> 00:09:33,640
So the important thing here is how can we identify quickly what are the existing detective control or compensating control are already in place.

113
00:09:33,640 --> 00:09:40,980
So this is the second factor that can help us further reduce the number of alerts that we need to take.

114
00:09:40,980 --> 00:09:47,060
So I always advise my team, don't go just by the scanner output.

115
00:09:47,060 --> 00:09:50,740
Try to get the context by understanding the business criticality.

116
00:09:50,740 --> 00:09:56,040
Try to sharpen your context by understanding the compensating and detective control.

117
00:09:56,460 --> 00:10:01,540
And last but not least, get in touch with your development team.

118
00:10:01,540 --> 00:10:04,400
They are the one who are going to fix these vulnerabilities.

119
00:10:04,400 --> 00:10:06,400
Try to understand their constraint.

120
00:10:06,400 --> 00:10:16,200
Before going GA, do they have time to build, to fix this vulnerability or we need to look into adding more alternative security control.

121
00:10:16,200 --> 00:10:25,320
So these are some of the techniques I personally use to help my team to mitigate the beast of avalanche of alerts.

122
00:10:25,910 --> 00:10:28,860
I would like to give one specific example.

123
00:10:29,140 --> 00:10:35,080
How many of you have been using source code analysis tools?

124
00:10:37,690 --> 00:10:46,290
So most of the SBOM, SCA, SAS tool, they basically look for, you know, presence of vulnerable code, right?

125
00:10:46,290 --> 00:10:49,410
And then they immediately flag this as a vulnerability.

126
00:10:49,410 --> 00:10:53,650
Same thing with the software composition analysis tool.

127
00:10:53,650 --> 00:10:57,990
They blindly look for the open source library, their version.

128
00:10:57,990 --> 00:11:04,030
If the hash matches, they generate avalanche of all the CVEs, known CVEs.

129
00:11:04,030 --> 00:11:17,450
So what I have been telling my security team members and security champions mainly is, hey guys, look for if these vulnerabilities are actually exploitable.

130
00:11:17,450 --> 00:11:25,070
The vulnerable parameters, the file paths, the functions, methods that are being mentioned in these CVEs.

131
00:11:25,070 --> 00:11:28,090
Is your host application actually invoking this?

132
00:11:28,090 --> 00:11:31,350
And this is exactly what helps them with prioritization.

133
00:11:31,350 --> 00:11:38,470
Compared to 100%, after understanding the exploitability factor, this number goes down to 5%.

134
00:11:40,010 --> 00:11:40,950
Fascinating.

135
00:11:40,950 --> 00:11:43,330
Thank you for that, Rupti.

136
00:11:43,930 --> 00:11:45,830
Next one, Kiran.

137
00:11:46,930 --> 00:11:48,910
Let's talk about automation.

138
00:11:48,910 --> 00:11:52,470
So automation plays a crucial role in managing security alerts.

139
00:11:52,470 --> 00:11:58,510
Can you share examples of how have you automated alert prioritization and response processes?

140
00:11:58,510 --> 00:12:02,290
What benefits have you observed from this automation efforts?

141
00:12:02,330 --> 00:12:03,310
Absolutely.

142
00:12:03,310 --> 00:12:08,570
So I did mention that scale is very important for us in the company that I work for.

143
00:12:08,570 --> 00:12:18,250
And without automation, our teams would just get buried with security alerts and findings from all of these tools.

144
00:12:18,250 --> 00:12:28,650
So we put a lot of effort in making sure that we are in the pipelines, that the alerts and findings are going to the teams.

145
00:12:28,850 --> 00:12:40,610
But one thing that you have to keep in mind, the first time you do it, and this is a story, the first time we automated, got stuff out into developers' hands, I think we were not very empathetic.

146
00:12:40,610 --> 00:12:46,490
And it was an avalanche of alerts and findings in their space.

147
00:12:46,550 --> 00:12:49,870
So having that feedback loop is very important.

148
00:12:49,870 --> 00:12:52,550
The feedback and that conversation.

149
00:12:53,070 --> 00:12:57,670
In a past life, I was a software developer, so I know some of that pain.

150
00:12:58,910 --> 00:13:04,270
The two o'clock nights, you're trying to hash out stuff, things are not working.

151
00:13:04,270 --> 00:13:08,130
Maybe that one time when something works, you go, oh, yes.

152
00:13:08,290 --> 00:13:14,450
And so you want to have that empathy and that feedback loop to make sure that things are coming back.

153
00:13:14,450 --> 00:13:24,010
And in some cases, you can also even put it back into maybe frameworks that you already have or in the requirements and saying, don't do this.

154
00:13:24,010 --> 00:13:29,830
By starting right, you may prevent a lot of things further down the line.

155
00:13:32,640 --> 00:13:35,580
Actually, I can add a little bit more.

156
00:13:35,820 --> 00:13:46,540
Those who are especially early in their AppSec career, I highly recommend configuring their security scanning tools correctly, shifting the focus on crown jewels.

157
00:13:46,540 --> 00:13:53,440
Many times, if the security tool is not correctly configured, it can also generate a lot of noise.

158
00:13:53,440 --> 00:14:03,160
Once you configure, then the next step is fine-tuning the tool so that we can get rid of those low-hanging fruit, repetitive findings.

159
00:14:03,160 --> 00:14:15,640
And third, very, very important here, whether you are running AppSec tool or a threat detection tool, having automated response to manage the beast of alerts is extremely important.

160
00:14:15,640 --> 00:14:21,680
So definitely spend a few software engineering cycles to ride that automation.

161
00:14:21,680 --> 00:14:24,120
Your developers will bless you.

162
00:14:24,800 --> 00:14:26,960
Joe, would you like to add something?

163
00:14:27,960 --> 00:14:29,960
I'll add one other thought.

164
00:14:29,960 --> 00:14:39,240
So a lot of times when we port these vulnerabilities or different findings from tools, what do we do?

165
00:14:39,340 --> 00:14:44,680
We port them directly from the tool, and they're really cumbersome, right?

166
00:14:44,680 --> 00:14:51,380
And when we give them to the developer teams, they're confused because they go through and they're like, what am I looking at?

167
00:14:51,380 --> 00:14:54,000
It's not concise, it's confusing, right?

168
00:14:54,000 --> 00:14:57,300
Especially if you're looking at things like transit dependencies, it's very nested.

169
00:14:57,300 --> 00:14:59,380
So it can get confusing very, very quickly.

170
00:14:59,940 --> 00:15:14,480
So automation is a great first step, but I would also say when you're looking at particular bug classes, so whether it's like SQL injection, cross-site scripting, things like that, try to dive in a little bit further and try to make it more concise for your developer team.

171
00:15:14,480 --> 00:15:28,680
If you can do that with the automation, there's less back and forth with you as the security team, because the development teams are constantly going back to security engineers and they're saying, I got this ticket, I don't know what it means, can you help me?

172
00:15:28,700 --> 00:15:29,520
And what does that do?

173
00:15:29,520 --> 00:15:34,140
That drains a lot of cycles for security personnel and the development team.

174
00:15:34,140 --> 00:15:38,120
And quite honestly, we need to do a better job of that as well.

175
00:15:38,120 --> 00:15:43,540
So part one I would say is definitely automation, but part two is making it a little bit more concise and adjustable.

176
00:15:44,600 --> 00:15:45,340
Absolutely.

177
00:15:45,340 --> 00:15:49,120
So Joe, while you have the microphone, another one for you.

178
00:15:49,540 --> 00:15:52,660
So context, let's talk about context.

179
00:15:52,680 --> 00:16:03,140
Since context is a key understanding the impact of security alerts, and you've all touched that, so how do you ensure that alerts are assessed within the proper organizational context?

180
00:16:03,140 --> 00:16:07,420
Are there specific approaches or frameworks that help?

181
00:16:10,020 --> 00:16:17,140
How do you get this comprehensive understanding of what does it really mean in the context of what we're looking at?

182
00:16:17,140 --> 00:16:17,660
Sure.

183
00:16:17,660 --> 00:16:22,600
So many folks might not like this, but there is no silver bullet, unfortunately.

184
00:16:24,920 --> 00:16:29,980
Applications, when you look at them, there's different levels of PII.

185
00:16:29,980 --> 00:16:34,860
Maybe you're storing credit cards, maybe you're storing SSNs or driver's licenses, passports, whatever it may be.

186
00:16:35,180 --> 00:16:39,720
You've got some very, very critical information that might be stored on some applications.

187
00:16:39,940 --> 00:16:44,280
You might have some that are just a learning management system for training new employees.

188
00:16:44,640 --> 00:16:46,180
So you think about that.

189
00:16:46,180 --> 00:16:48,180
Then there's also network bounds.

190
00:16:48,280 --> 00:16:51,320
Do you have firewalls, DMZs, so on and so forth?

191
00:16:51,320 --> 00:16:52,920
Is it internal to your network?

192
00:16:52,920 --> 00:16:58,900
You're going to spend a different amount of effort looking for alerts based on the context of the network.

193
00:16:58,900 --> 00:17:06,280
And then the other thing we've kind of touched on is you can't just look at the severity rating from the tool and go, oh, it's critical, therefore it must be critical.

194
00:17:06,280 --> 00:17:12,040
Do some research and try to understand why is this critical, right?

195
00:17:12,060 --> 00:17:16,220
Is there exploitation out there?

196
00:17:17,040 --> 00:17:19,880
Is it actively being exploited by an adversary?

197
00:17:20,000 --> 00:17:21,480
Is it internet-facing?

198
00:17:21,480 --> 00:17:36,200
I think ultimately there are frameworks, but a lot of it is just rationalization and kind of that understanding of what is my network, what's out on my network, and how do I kind of issue that guidance?

199
00:17:36,200 --> 00:17:38,440
And then you just kind of pair that with the alerting aspect.

200
00:17:39,440 --> 00:17:47,160
I think the last piece of it is just making it concise and communicating it and also knowing that this is an evolutionary process.

201
00:17:48,680 --> 00:17:54,980
Applications are being developed very, very quickly, especially with containers and other things that are going on with orchestration.

202
00:17:54,980 --> 00:18:08,440
So you need to have a really good pulse with your technology teams to figure out what is their roadmap, what are they building, because no one wants to be on the wrong end of an API being deployed to prod, publicly facing, and you didn't know about it.

203
00:18:08,440 --> 00:18:09,800
That's a bad look.

204
00:18:09,800 --> 00:18:13,820
So I think, yes, there are some frameworks, there are some guidance, like I said.

205
00:18:13,820 --> 00:18:15,680
There's NIST guidance, there's OAuth guidance.

206
00:18:15,680 --> 00:18:23,160
There is a lot of good guidance out there, but you really have to digest that and figure out how it applies to your specific organization.

207
00:18:23,260 --> 00:18:25,860
So there really is no silver bullet, in my opinion.

208
00:18:27,860 --> 00:18:29,920
I would like to add one more thing.

209
00:18:29,920 --> 00:18:36,500
Joe brought up a great point of we look at the tools, we look at their severity scores, and we go by that.

210
00:18:36,880 --> 00:18:42,980
And it is great advice that maybe they are not as severe as we think because of context.

211
00:18:42,980 --> 00:18:44,420
There's also a flip to that.

212
00:18:44,420 --> 00:18:52,520
I support our incident response team, and I'm telling you, sometimes there are some that are actually very low scored on the tool, but that can become an incident.

213
00:18:52,640 --> 00:19:00,280
So one advice when you're doing these analysis, be prepared for something to go up in severity too.

214
00:19:00,380 --> 00:19:03,200
And that's something that I've learned over my career.

215
00:19:03,980 --> 00:19:10,140
I 100% agree with Joe and Kiran.

216
00:19:10,140 --> 00:19:21,520
What I have seen is we as a security engineering team, we are so hyper-focused on high and criticals that we do not pay attention to the lows and medium.

217
00:19:21,520 --> 00:19:25,380
We have a tendency to see a pattern, oh, this is repetition, and we forget.

218
00:19:25,380 --> 00:19:38,500
But many times when we consider four mediums and three lows together and build context around that, it actually has the ability to create impact at high severity level.

219
00:19:38,520 --> 00:19:45,380
So that vulnerability correlation, and I'll speak more about it later, is extremely important.

220
00:19:45,380 --> 00:19:49,780
Gone are the days when we used to look at vulnerabilities in isolation.

221
00:19:49,780 --> 00:19:58,060
Now context around the business, as well as the security context, along with the technology context, everything has become extremely important.

222
00:19:58,060 --> 00:20:02,120
And let's not forget about product managers and their launch schedule.

223
00:20:02,280 --> 00:20:07,620
That context is also very important.

224
00:20:07,620 --> 00:20:11,520
We often feel that these launch schedules randomize us.

225
00:20:11,520 --> 00:20:16,840
We already have 10 times more workload that we can handle, but that is also very important.

226
00:20:16,840 --> 00:20:21,040
If something is going to get released three months from today, let's not worry about that.

227
00:20:21,040 --> 00:20:25,260
Let's focus on something that's going to get out in the world right away.

228
00:20:25,360 --> 00:20:27,220
So yeah, context is the king.

229
00:20:28,980 --> 00:20:30,840
So, Trupti, let's stay with you.

230
00:20:30,840 --> 00:20:39,380
So with the increasing volume of security alerts, how do you effectively triage them and differentiate between the critical and non-critical?

231
00:20:39,380 --> 00:20:45,700
I mean, process-wise, what do you actually put in place in order to differentiate between those?

232
00:20:45,700 --> 00:20:57,500
Yeah, you know, I see that we are, again, going back to the similar conversations, which are the attention-worthy vulnerabilities or alerts and which ones are not, right?

233
00:20:57,780 --> 00:21:06,440
When we have so much volume, at my current employer, we have to deal with 18 to 20 security scanners, right?

234
00:21:06,440 --> 00:21:08,180
So fatigue is very natural.

235
00:21:08,180 --> 00:21:13,120
And coming back to Sher's question, how can we effectively triage them?

236
00:21:13,120 --> 00:21:25,380
We already discussed a lot of good points, such as, you know, understanding the exploitability, whether something is external-facing, internal-facing, something is exploitable, not exploitable, is there a clear attack path?

237
00:21:25,380 --> 00:21:30,220
But I want to bring the audience's attention towards vulnerability correlation.

238
00:21:30,220 --> 00:21:46,680
When we have so many scanners emitting gazillion vulnerabilities constantly, it is probably a good idea to take some time aside and look into some software engineering solution that can correlate these vulnerabilities.

239
00:21:47,020 --> 00:21:51,280
Less overwhelming for security engineer and for developer, right?

240
00:21:51,280 --> 00:22:03,200
When we have same vulnerability reported by five, six different tools, and we know this is the same thing, shifting our focus on remediation, that's the way to go.

241
00:22:03,200 --> 00:22:19,660
So I would say, you know, Sher, in the avalanche of these alerts, if people can find the right tool to correlate vulnerabilities and then shift the focus on remediation, that's the way to go to manage this beast.

242
00:22:21,440 --> 00:22:25,780
Maybe one additional point on something that I've been thinking about.

243
00:22:25,780 --> 00:22:27,560
So you don't need to do it alone, right?

244
00:22:27,560 --> 00:22:29,880
So we have this concept of security champions.

245
00:22:29,880 --> 00:22:31,500
Maybe you have it in your company.

246
00:22:31,520 --> 00:22:36,260
These are people in your product teams, right, in your dev wars.

247
00:22:36,260 --> 00:22:38,240
They have an interest in security.

248
00:22:38,240 --> 00:22:40,960
Involve them in your conversations.

249
00:22:40,960 --> 00:22:51,240
In fact, there was one, when we started up our security champions program, there was always one or two people that were very, very focused, challenging us as to why are you doing this?

250
00:22:51,240 --> 00:22:52,660
Why are you not doing this?

251
00:22:52,720 --> 00:22:55,560
Why don't we, I don't know, ride this much ahead?

252
00:22:55,640 --> 00:22:59,300
And one actually came over to our AppSec team, too.

253
00:22:59,300 --> 00:23:01,680
So great source of talent sometimes, right?

254
00:23:01,680 --> 00:23:09,020
So you use other resources and people in your company in that space to do some of this, too.

255
00:23:11,140 --> 00:23:12,620
Great point, Kiran.

256
00:23:12,620 --> 00:23:19,600
And I want to add that many times security engineers, they feel the burden, oh, we have to do it all.

257
00:23:19,640 --> 00:23:25,440
And somehow they feel that it's not okay to disturb the developer or engineering manager.

258
00:23:25,660 --> 00:23:26,400
Guess what?

259
00:23:26,400 --> 00:23:27,780
You don't want to get burned out.

260
00:23:27,780 --> 00:23:29,740
You don't want to face that alert fatigue.

261
00:23:29,740 --> 00:23:31,360
Start involving them.

262
00:23:31,740 --> 00:23:33,360
These are their application.

263
00:23:33,360 --> 00:23:34,060
They own it.

264
00:23:34,060 --> 00:23:36,520
As such, security teams don't own anything.

265
00:23:36,520 --> 00:23:39,620
And when we reach out to them, they know it is important.

266
00:23:39,620 --> 00:23:41,220
They are not going to ignore you.

267
00:23:41,220 --> 00:23:50,920
In fact, they will become our partners and help us build that deeper technical context that as a security engineer we may not have.

268
00:23:50,920 --> 00:23:57,160
So without any fear, definitely involve the developers, engineering manager, directors you work with.

269
00:23:57,160 --> 00:23:59,760
They will expedite your things.

270
00:23:59,760 --> 00:24:08,820
Then train them and then hand over the vulnerability triage, not just the remediation work, but the overall triage and assessment work to them.

271
00:24:08,820 --> 00:24:14,280
So thank you very much, Kiran, for mentioning the role of security champions here.

272
00:24:15,380 --> 00:24:20,520
Yeah, Kiran, let's move back to you and talk a little bit about ASPM.

273
00:24:20,520 --> 00:24:28,920
It seems like a new category is shaping, starting earlier this year, application security posture management with a lot of hype around it.

274
00:24:28,920 --> 00:24:38,920
It represents a major shift in how organizations manage application security, moving from siloed individual approach into more integrated contextual one.

275
00:24:38,980 --> 00:24:44,540
So do you agree with this statement, what's happening in this area?

276
00:24:44,540 --> 00:24:46,600
I absolutely agree with that statement.

277
00:24:46,660 --> 00:24:49,240
In fact, Joe actually brought it up earlier.

278
00:24:49,240 --> 00:24:51,080
It's about security basics, right?

279
00:24:51,080 --> 00:24:54,820
It's about knowing what's on your network, what's going on.

280
00:24:54,820 --> 00:24:58,900
So we have actually done this in the infrastructure vulnerability space.

281
00:24:58,900 --> 00:25:03,920
Because a little bit of the incident response side, it's worked over there fairly well.

282
00:25:03,920 --> 00:25:07,160
And I'm surprised we have not done this already.

283
00:25:07,520 --> 00:25:13,820
And I know in some aspects of DevOps, DevSecOps, we do it all and we have done it.

284
00:25:13,820 --> 00:25:18,940
But the fact that the terminology and this focus on it, I'm absolutely excited and thrilled about it.

285
00:25:20,640 --> 00:25:22,040
Anyone else?

286
00:25:22,400 --> 00:25:27,980
Yeah, I think application security posture management is a fairly new category.

287
00:25:27,980 --> 00:25:34,360
For many of the AppSec or software security engineers, it did not exist five, six years back, right?

288
00:25:34,360 --> 00:25:35,880
It's fairly new.

289
00:25:35,940 --> 00:25:46,780
We as AppSec engineers, we were so hyper-focused on just looking at one service, one application or a data center or a library, that we would lose the big picture.

290
00:25:46,780 --> 00:25:51,420
And this is exactly where application security posture management comes up.

291
00:25:51,420 --> 00:25:54,020
It helps us think strategy point of view.

292
00:25:54,020 --> 00:25:55,740
Okay, this is my network.

293
00:25:55,740 --> 00:26:01,000
These are the 10,000 applications my team is responsible for securing.

294
00:26:01,000 --> 00:26:04,700
How can I look at it from AppSec posture management?

295
00:26:04,700 --> 00:26:06,400
Which ones I need to protect?

296
00:26:06,400 --> 00:26:09,020
Which ones already got good coverage?

297
00:26:09,060 --> 00:26:17,820
Where I can put strong remediation control that can mitigate the entire category of vulnerabilities.

298
00:26:17,820 --> 00:26:24,080
So I think application security posture management is the way to go going forward.

299
00:26:24,080 --> 00:26:28,460
We cannot keep relying on just SAST or secret scanner or DAST.

300
00:26:28,460 --> 00:26:35,260
I think application security posture management brings together all the AppSec tools.

301
00:26:35,260 --> 00:26:36,980
So extremely crucial.

302
00:26:36,980 --> 00:26:42,440
And I urge all AppSec engineers here to take some time aside and learn about it.

303
00:26:42,440 --> 00:26:47,160
How these tools work versus working with individual tools in isolation.

304
00:26:49,100 --> 00:26:51,340
Next one is to you, Joe.

305
00:26:51,600 --> 00:26:57,740
It's more about the process and the human part of the process and resource allocation.

306
00:26:57,740 --> 00:27:05,400
So how do you prioritize and allocate resources for addressing high priority alerts in your team today?

307
00:27:06,580 --> 00:27:09,860
Yeah, I think there's two things, right?

308
00:27:09,860 --> 00:27:13,860
We talked a bit about severity, right?

309
00:27:13,860 --> 00:27:19,500
And a lot of us are probably like, oh, I've got a CVSS assigned to this vulnerability or whatnot.

310
00:27:20,200 --> 00:27:26,500
But that's usually generated off the base score, not temporal or your environment of what's actually being construed.

311
00:27:26,500 --> 00:27:33,500
So one is not just taking those base scores and actually applying some science behind it and figuring out how does this apply to my network.

312
00:27:34,460 --> 00:27:37,160
The other thing is, is Jerry Gamblin out in there?

313
00:27:37,380 --> 00:27:38,400
Is he out in the audience?

314
00:27:38,400 --> 00:27:39,520
I talked to him earlier.

315
00:27:39,720 --> 00:27:40,760
Maybe not.

316
00:27:40,760 --> 00:27:46,840
He did talk at BSides earlier this week, and he developed a web app called PatchThis.app.

317
00:27:46,840 --> 00:27:48,340
I don't know if anyone's heard of it.

318
00:27:48,340 --> 00:27:55,900
But it basically takes CISA's KEV, so Known Exploitable Vulnerabilities, if I could talk today, and EPSS.

319
00:27:55,900 --> 00:27:58,760
And it's basically just a threat feed for those vulnerabilities.

320
00:27:58,760 --> 00:28:10,380
And so when you look at critical and high alerts, there's a lot of fatigue there because you're getting a lot because typically the CVSS is pretty high because the researchers are like, I want a high CVSS.

321
00:28:10,380 --> 00:28:13,220
And this is how I'm assigning the scoring to it.

322
00:28:13,760 --> 00:28:16,560
But the question is, right, is that really exploitable?

323
00:28:16,560 --> 00:28:18,680
Is this really, should I be spending my time?

324
00:28:18,680 --> 00:28:26,940
So if you take those other kind of like vulnerability intelligence feeds and kind of applying that to your list, it cuts down pretty drastically.

325
00:28:26,940 --> 00:28:28,580
So that's the first part.

326
00:28:28,780 --> 00:28:35,000
The second piece we kind of talked about as well is automation, making sure it's ingested preferably into a single pane of glass.

327
00:28:35,000 --> 00:28:38,300
So we've talked about how there's dozens and dozens of scanners, right?

328
00:28:38,300 --> 00:28:40,860
There's SAS, there's DAS, there's SCA.

329
00:28:40,860 --> 00:28:46,540
There's a lot of different technologies that's coming in, but you want to ingest it into one single pane of glass.

330
00:28:46,540 --> 00:28:51,300
So developers can go, okay, I want to look at all the vulnerabilities for my specific application.

331
00:28:51,780 --> 00:28:52,720
And it's right there.

332
00:28:52,720 --> 00:28:53,720
They can go to it.

333
00:28:53,720 --> 00:28:55,700
They don't want to log into the security tool.

334
00:28:55,700 --> 00:29:00,960
They want to go to their technology process that they're familiar with, right?

335
00:29:00,960 --> 00:29:07,020
Whether it's directly into Git or into a single pane of glass where it's like all the security information is there.

336
00:29:07,020 --> 00:29:08,040
That's another piece.

337
00:29:08,040 --> 00:29:10,800
And I would say the other thing too is just communication.

338
00:29:10,840 --> 00:29:13,820
We've kind of touched on it a bit here.

339
00:29:14,340 --> 00:29:16,180
But I think even further, right?

340
00:29:16,180 --> 00:29:22,840
Like a lot of times we send these tickets over to development teams and we reach out and say, hey, like when can we expect this to be remediated?

341
00:29:22,960 --> 00:29:24,860
We have SLAs assigned.

342
00:29:24,860 --> 00:29:27,220
Maybe an engineer goes and comments on the ticket.

343
00:29:27,280 --> 00:29:28,140
They don't hear anything back.

344
00:29:28,140 --> 00:29:30,220
And they go, well, I didn't hear anything back.

345
00:29:30,220 --> 00:29:32,400
You need to be persistent, right?

346
00:29:32,400 --> 00:29:33,920
You really need to hold the security bar.

347
00:29:33,920 --> 00:29:34,900
Be the champion.

348
00:29:34,940 --> 00:29:37,460
Especially if you're the one working in your security team, right?

349
00:29:37,500 --> 00:29:40,920
You're the person that's there setting the guidance, setting that step.

350
00:29:40,920 --> 00:29:43,560
So, you know, you really have to follow up with these teams.

351
00:29:43,560 --> 00:29:45,820
And don't treat it as like I'm annoying somebody.

352
00:29:45,960 --> 00:29:47,080
You're caring about security.

353
00:29:47,080 --> 00:29:48,500
You're upholding what you have to do.

354
00:29:48,500 --> 00:29:50,140
It's in everyone's policies.

355
00:29:50,860 --> 00:29:53,620
And, right, you're there to protect your organization.

356
00:29:53,620 --> 00:29:56,600
So the other piece is communication and persistence.

357
00:29:56,900 --> 00:30:00,300
And from there, you can chop down that list of vulnerabilities.

358
00:30:00,300 --> 00:30:02,320
You've automated it into a single point.

359
00:30:02,320 --> 00:30:05,580
And then you've kind of built those relationships with your development team.

360
00:30:05,580 --> 00:30:07,200
And you're persistent with them.

361
00:30:07,200 --> 00:30:10,480
Really treat it as a learning and educating kind of space.

362
00:30:10,480 --> 00:30:12,840
So that's what I would say in terms of prioritization.

363
00:30:12,840 --> 00:30:13,220
Great.

364
00:30:13,220 --> 00:30:14,000
Thank you for that.

365
00:30:14,000 --> 00:30:16,520
Maybe a more general comment about prioritization.

366
00:30:16,520 --> 00:30:21,980
I keep reminding myself, even when I talk to my kids, that prioritizing is hard.

367
00:30:21,980 --> 00:30:28,360
When you have 10 items you need to look at, there's more than 3 million options to put them in order.

368
00:30:28,360 --> 00:30:28,660
Right?

369
00:30:28,660 --> 00:30:32,860
It's almost inhuman to really prioritize.

370
00:30:32,860 --> 00:30:33,100
Right?

371
00:30:33,100 --> 00:30:34,460
And that's just 10 items.

372
00:30:34,460 --> 00:30:38,460
Just imagine, you know, we all have hundreds, sometimes thousands.

373
00:30:38,500 --> 00:30:38,820
Right?

374
00:30:38,820 --> 00:30:45,120
So we need techniques that will help us making it more human achievable.

375
00:30:45,140 --> 00:30:47,900
So thank you for that, Joe.

376
00:30:48,460 --> 00:30:50,580
Do we have time for one more?

377
00:30:50,580 --> 00:30:53,820
Or should we open up for 30 minutes?

378
00:30:54,280 --> 00:30:54,940
Okay.

379
00:30:54,940 --> 00:30:58,120
So, guys, first of all, thanks for the panelists.

380
00:30:58,120 --> 00:31:02,260
But we would definitely like to open it up for questions from the crowd.

381
00:31:02,260 --> 00:31:09,420
So feel free to go line up or you can use this microphone if you're comfortable.

382
00:31:12,000 --> 00:31:12,700
Yeah.

383
00:31:12,760 --> 00:31:14,220
I can go first.

384
00:31:14,280 --> 00:31:14,960
Yeah, sure.

385
00:31:14,960 --> 00:31:16,360
My name is Sanket.

386
00:31:16,640 --> 00:31:20,300
So question for you, Joe, you brought up and perhaps for the rest of the panelists.

387
00:31:20,300 --> 00:31:28,320
So you talked about when the first question was asked, you need to know what's on your network.

388
00:31:28,320 --> 00:31:39,800
So do you have any suggestions for what's worked for you successfully in the past to figure out what's on your network, all the assets, software, hardware, virtual?

389
00:31:49,870 --> 00:31:51,270
No, that's a great question.

390
00:31:51,270 --> 00:31:56,930
I spoke in my opening remarks about a CMDB, right?

391
00:31:56,930 --> 00:31:59,970
And there's a lot of emphasis in having that.

392
00:31:59,970 --> 00:32:05,230
I think there's another immersion if you've played around with Backstage quite a bit.

393
00:32:05,230 --> 00:32:09,770
It's a pretty powerful open source from the Spotify team that made it.

394
00:32:09,770 --> 00:32:15,670
But if you can have someone that maintains that within your org, that's a good first step.

395
00:32:15,670 --> 00:32:20,550
The other thing is we all have tools that scan our networks.

396
00:32:20,550 --> 00:32:23,550
They scan our network blocks and it identifies assets.

397
00:32:23,550 --> 00:32:26,150
It pulls back a host name, right?

398
00:32:26,170 --> 00:32:36,390
Take that data and go back to the CMDB team or whoever kind of maintains that asset list and say, these are the assets I'm identifying on this network.

399
00:32:36,530 --> 00:32:37,830
What's going on?

400
00:32:37,970 --> 00:32:41,350
Same thing with containers, load balancing, all that, right?

401
00:32:41,350 --> 00:32:43,870
You're going to have distributed, especially with cloud services, right?

402
00:32:43,870 --> 00:32:45,590
You're going to have distributed applications.

403
00:32:45,590 --> 00:32:47,910
And so it's a good opportunity to talk with the team.

404
00:32:47,910 --> 00:32:50,170
And this goes back to basic threat modeling.

405
00:32:50,770 --> 00:32:52,290
How is your app being built?

406
00:32:52,290 --> 00:32:54,050
Are there multiple containers being split off?

407
00:32:54,050 --> 00:32:57,230
Do they have multiple EC2 instances that are balanced across?

408
00:32:57,650 --> 00:33:04,590
So the more that you can kind of divulge and go through it, the easier that you can kind of create that mapping.

409
00:33:04,590 --> 00:33:08,850
So it's a hard problem to solve and a lot of teams struggle with it.

410
00:33:08,850 --> 00:33:12,110
But if you can kind of correlate between the two, that's extremely helpful.

411
00:33:12,110 --> 00:33:13,910
And that's what I've seen through my career.

412
00:33:15,310 --> 00:33:26,570
So yeah, asset inventory, having accurate prioritized asset inventory is a way more harder problem than any of the security problem out there, right?

413
00:33:26,570 --> 00:33:28,050
We all agree.

414
00:33:28,050 --> 00:33:34,330
One of the interesting criteria that my teams have used is revenue.

415
00:33:34,910 --> 00:33:41,770
Which asset, if it gets breached or compromised, can have direct impact on revenue?

416
00:33:41,770 --> 00:33:49,930
Which assets handle that important sensitive data that can introduce lack of customer trust?

417
00:33:49,930 --> 00:34:05,950
So depending on the organization you work at and depending upon your organization's mission, business goal, your engineering department's goal, the criteria to prioritize your asset, it's going to be different.

418
00:34:06,430 --> 00:34:10,030
Things that work for one organization may not work.

419
00:34:10,030 --> 00:34:13,090
Things that may not work for another organization.

420
00:34:13,090 --> 00:34:23,810
So I would highly recommend when you work with your IT team or engineering team to build that asset inventory, get buy-in on that criteria.

421
00:34:33,010 --> 00:34:33,710
So...

422
00:34:35,910 --> 00:34:37,310
Sorry.

423
00:34:37,650 --> 00:34:46,130
There was a discussion from you, I believe, about pushing triaging towards developers to reduce workload, which I completely agree makes total sense.

424
00:34:46,130 --> 00:34:50,630
But whenever that's been brought up or I've heard it being discussed, there's been pushback from security teams.

425
00:34:50,630 --> 00:34:53,650
Not just application security teams, just security teams in general.

426
00:34:53,850 --> 00:35:03,370
Because there's mistrust that developers will not be able to do it accurately or they could just take work away from themselves.

427
00:35:03,370 --> 00:35:10,490
So how would you handle that cultural issue so that both sides can actually get what they need?

428
00:35:10,510 --> 00:35:12,590
Yeah, great question.

429
00:35:12,590 --> 00:35:24,510
So the question is, you know, the way security engineers are really good at triaging, they're fast at triaging, no matter how much we train our developers, will they become equally good?

430
00:35:24,510 --> 00:35:26,590
The simple answer is no.

431
00:35:27,490 --> 00:35:31,430
They have 100 things on their plate.

432
00:35:31,430 --> 00:35:38,850
And the most important thing is to build, develop those shiny new features that generates revenue, right?

433
00:35:38,850 --> 00:35:44,190
And here comes security team trying to teach them how to triage vulnerability.

434
00:35:44,430 --> 00:35:51,050
So first thing we have to understand is not all developers have the security DNA.

435
00:35:51,050 --> 00:35:56,990
Not all developers have taken a security class when they were doing their college.

436
00:35:56,990 --> 00:36:01,070
So select those very few security champions.

437
00:36:01,530 --> 00:36:03,250
Invest time in them.

438
00:36:03,250 --> 00:36:06,190
One training after another training.

439
00:36:06,190 --> 00:36:22,710
If you are new to triaging these vulnerabilities, invite them to your office hours and see, do a quality analysis of their work and give them that much needed, you know, quality feedback to raise their awareness slowly.

440
00:36:22,970 --> 00:36:32,070
If they have done anything wrong or not done a thorough job, do not penalize them or do not take away the work from them, but be their partner, work with them.

441
00:36:32,070 --> 00:36:39,810
And please keep in mind, teaching security to developers is not an easy job.

442
00:36:39,810 --> 00:36:45,830
We are trying to create organizational behavioral change and any change takes time.

443
00:36:45,830 --> 00:36:47,810
So be patient with them.

444
00:36:47,810 --> 00:36:49,830
Be patient with yourself.

445
00:36:49,830 --> 00:36:54,390
It takes at least three years for any program to get mature.

446
00:36:54,390 --> 00:36:59,830
So when we have that realistic expectation, we as a security engineer do not get frustrated.

447
00:36:59,830 --> 00:37:09,250
Create those much needed run books, training that shows real examples and then make your work through that.

448
00:37:09,250 --> 00:37:25,690
Last but, you know, the most important thing is when our developers are doing really nice job of whether vulnerability triaging or fixing a vulnerability, give a huge shout out, not only among security teams, but among developers.

449
00:37:25,690 --> 00:37:31,230
Don't be afraid to write a mail to their VP or director applauding their security effect.

450
00:37:31,230 --> 00:37:40,010
And because of such positive enforcement, you will see the change will happen quicker than the slower pace.

451
00:37:41,890 --> 00:37:57,850
So one more thing that's worked for us, it's a story that a few years back, as we expanded our security teams, there was one particular team that had to do with identity and things like that.

452
00:37:57,850 --> 00:38:01,830
We had a very heavy touch with them because there was always issues and stuff.

453
00:38:01,830 --> 00:38:03,290
There was a lot of conflict.

454
00:38:03,730 --> 00:38:06,910
And our leadership team did something very well.

455
00:38:06,910 --> 00:38:08,630
They went with their leadership team.

456
00:38:08,630 --> 00:38:09,650
They were empathetic.

457
00:38:09,650 --> 00:38:12,390
They knew that they had to build features.

458
00:38:12,390 --> 00:38:14,070
They had other business metrics.

459
00:38:14,150 --> 00:38:17,330
So together as a leadership team, they went up to the CTO.

460
00:38:17,330 --> 00:38:19,410
And we got funding for them.

461
00:38:19,490 --> 00:38:25,050
And post doing that, post getting a little bit of funding for them, our relationship got much better.

462
00:38:25,050 --> 00:38:28,110
It's not all roses, but it definitely got much better.

463
00:38:28,110 --> 00:38:33,250
So being empathetic to the earlier point there, it's very important.

464
00:38:33,250 --> 00:38:35,850
Understand that it's not going to be built in a day.

465
00:38:35,850 --> 00:38:37,730
It will take time.

466
00:38:37,730 --> 00:38:39,230
Start small.

467
00:38:41,370 --> 00:38:43,890
Work in their footstep.

468
00:38:43,890 --> 00:38:45,870
Be in their shoes.

469
00:38:45,870 --> 00:38:48,290
And just build on top of that.

470
00:38:51,690 --> 00:38:52,530
Okay.

471
00:38:52,530 --> 00:38:58,930
I heard you with respect to looking at the CVSS scores and adjusting.

472
00:38:58,930 --> 00:39:09,210
We took a little bit different tact on that because what we discovered was that mostly CVSS scores, it took a while to investigate.

473
00:39:09,670 --> 00:39:16,090
And usually developers can easily just update the package faster than they can go talk to security.

474
00:39:16,130 --> 00:39:18,910
So most developers now just go update stuff.

475
00:39:18,910 --> 00:39:23,230
So we built all this stuff into our CICD pipelines.

476
00:39:23,330 --> 00:39:26,390
And what we're discovering is everything's great.

477
00:39:27,570 --> 00:39:28,910
Most people are getting through.

478
00:39:28,910 --> 00:39:30,670
Some people need a little waivers.

479
00:39:30,670 --> 00:39:37,610
The problem is what we're trying to do is get everybody to recycle their applications on a reoccurring basis.

480
00:39:37,890 --> 00:39:42,770
We're not having a whole lot of luck there yet except trying to create some policies.

481
00:39:42,770 --> 00:39:53,050
But I was wondering if any of you guys have gone through that whole process of mandating that every application must go through your pipeline, say, every 30 days.

482
00:39:54,050 --> 00:40:00,270
Because our philosophy is the CICD pipeline is where our rules are at, where our policy is implemented at.

483
00:40:00,270 --> 00:40:03,850
And it gets constantly updated, all those rules.

484
00:40:03,930 --> 00:40:12,690
And if something's sitting out there for two years, even if it doesn't have a vulnerability, it may have a weakness in there in the static code analysis or whatever else that we've updated those rules on.

485
00:40:12,730 --> 00:40:20,770
So have any of you had any success with getting your developers to constantly maintain your software?

486
00:40:22,710 --> 00:40:25,010
Maybe I can start with this one.

487
00:40:25,010 --> 00:40:33,890
So while I did say a portion of it as being empathetic and understanding, sometimes having policies also work.

488
00:40:33,890 --> 00:40:41,850
So we also noticed a very similar problem of older stuff being on our network, vulnerabilities creeping up.

489
00:40:41,850 --> 00:40:53,050
So what our leadership team did is long ago we negotiated across the engineering teams an SLA saying that we will adhere to this kind of an SLA.

490
00:40:53,050 --> 00:41:01,470
We'll use it sparingly, but if we find something and essentially ticket you in your ticketing system, we need to maintain that SLA.

491
00:41:01,470 --> 00:41:11,530
And those who don't, unless there is a business justified reason that we mutually agree on, we kind of establish a naughty list and that goes up all the way to the CTO.

492
00:41:11,570 --> 00:41:14,330
And VPs don't like being on the naughty list.

493
00:41:14,710 --> 00:41:21,690
So that has worked for us in terms of getting something recycled and all.

494
00:41:21,690 --> 00:41:27,930
But it has also focused primarily on when we find something on the old stuff that's out there.

495
00:41:30,450 --> 00:41:42,690
I would say that in smaller organizations, establishing such culture where we will block applications if they don't follow the CICD security SLAs and whatnot works very well.

496
00:41:42,690 --> 00:41:44,410
Because the surface is small, right?

497
00:41:44,410 --> 00:41:48,070
The number of applications, the dev teams, they know you all.

498
00:41:48,070 --> 00:41:55,130
But in bigger organizations, this type of processes have not worked.

499
00:41:55,130 --> 00:41:56,330
They don't give a damn.

500
00:42:01,010 --> 00:42:02,430
They don't.

501
00:42:02,430 --> 00:42:17,470
And here I would give a call out to AppSec Engineer that please put more emphasis on fine-tuning your SAS, DAST, any tool that you have integrated so that it is less work for developers.

502
00:42:17,470 --> 00:42:22,930
And again, shift the focus from accurate identification to actionable remediation.

503
00:42:22,930 --> 00:42:27,830
When they know that, hey, it's going to take me 10 minutes to upgrade this package.

504
00:42:27,830 --> 00:42:29,650
It's not going to cause regression.

505
00:42:29,650 --> 00:42:33,910
They are more willing to just do it rather than ignoring it.

506
00:42:39,680 --> 00:42:40,400
Hello.

507
00:42:40,520 --> 00:42:46,460
So my question, and I work more so on the infrastructure vulnerability side, so I might just not see what you guys see.

508
00:42:46,460 --> 00:42:50,180
On the correlation, totally agree that it's really important to be able to do that.

509
00:42:50,180 --> 00:43:01,000
And I've seen really good ways or decent ways of automating the identification of attack paths between, like, infrastructure and vulnerability or network and vulnerability configurations.

510
00:43:01,000 --> 00:43:07,120
But I haven't seen so much on, like, if you have several mediums and lows, how to correlate those together.

511
00:43:07,120 --> 00:43:11,240
And I was wondering if you guys have had any specific success stories around that in automation.

512
00:43:13,860 --> 00:43:15,660
I guess I'll go on this one.

513
00:43:15,660 --> 00:43:22,280
In terms of lows and mediums, I think that's a really hard problem to really solve.

514
00:43:22,860 --> 00:43:26,720
Exploit chaining is not an easy thing to do.

515
00:43:28,020 --> 00:43:42,680
I mean, this is why I kind of go back to know your network, know your applications, because the adversaries are putting in the time to know your network, to know your stack, and they're going to win 9 out of 10 times, realistically.

516
00:43:42,680 --> 00:43:46,400
I think that's where threat modeling really comes to mind.

517
00:43:46,660 --> 00:44:01,660
And as you're going through the threat modeling process, and you should be doing this on major revisions to the application, doing it pretty frequently, right, don't just look at the new features that the team is building.

518
00:44:01,660 --> 00:44:09,380
Go back into the tools and say, you've got some mediums, you've got some lows, and bring that into your threat model.

519
00:44:09,380 --> 00:44:18,860
And so that way, it's not just like, hey, there's this lingering JIRA ticket that's been out here for 100 plus days, and it's a medium, but you're developing a new product feature.

520
00:44:18,860 --> 00:44:28,640
That threat model is an opportunity for you to kind of bring up those conversations about exploit chaining again that may be used against you and moving laterally throughout the infrastructure.

521
00:44:28,920 --> 00:44:31,600
So I think that's definitely one part.

522
00:44:32,400 --> 00:44:43,160
The other thing, too, and it's somewhat related and somewhat unrelated, but the understanding that you want to impose costs to your adversary, right?

523
00:44:43,160 --> 00:44:46,520
So think of your network as a maze.

524
00:44:46,520 --> 00:44:52,980
And the adversary is navigating that maze, trying to get to the other side where your data is.

525
00:44:52,980 --> 00:45:03,300
And your blue team has different detection methodologies that are in between, you know, placed inside the maze, and your goal is to catch them before they get to the other side.

526
00:45:03,300 --> 00:45:09,980
And so that's typically how I try to think of those applications is like, are we doing logging or how are we doing our detection?

527
00:45:11,260 --> 00:45:21,380
In terms of CICD, I think in the very, very, you know, future state, where we need to do is partner with our detection response teams, right?

528
00:45:21,380 --> 00:45:28,540
There's a lot of talk right now this week going on like code provenance, doing Salsa framework and code notary, code signing.

529
00:45:29,020 --> 00:45:37,160
Your detection response team should ultimately be then consuming, you know, that activity like, oh, this hash didn't match.

530
00:45:37,240 --> 00:45:38,600
Someone go investigate it, right?

531
00:45:38,600 --> 00:45:46,100
I think that's really the next generation of, you know, security monitoring, where it's I'm not looking so much for the vulnerability.

532
00:45:46,100 --> 00:45:54,540
I'm looking for the actual active exploitation at the code level, which is, as far as I'm aware, almost not done today at scale.

533
00:45:55,100 --> 00:45:57,500
So I'll pass it over.

534
00:45:58,160 --> 00:46:03,020
Yeah, I think Joe said it very accurately, right?

535
00:46:03,020 --> 00:46:04,300
Threat model.

536
00:46:04,640 --> 00:46:07,380
That's a very important term.

537
00:46:07,380 --> 00:46:15,200
And threat model cannot be done just by application security engineer or just by, you know, infrastructure security engineer.

538
00:46:15,200 --> 00:46:28,100
And 10, 15 years back, we used to have this clear distinction between, you know, application developer, front end developer, back end developer, and then infrastructure engineer.

539
00:46:28,100 --> 00:46:32,560
But with the rise of full stack development, that line has blurred.

540
00:46:32,560 --> 00:46:34,920
We no longer segregate that.

541
00:46:34,920 --> 00:46:47,040
So as Joe said, when we want to look at, you know, bunch of lows and highs, everything together, we need people from different background and different teams in that room.

542
00:46:47,040 --> 00:46:58,700
We have to have the developer architect, plus we need infrastructure security engineer, a threat detection engineer, maybe a privacy expert if there is a privacy flaw, supply chain security person.

543
00:46:58,700 --> 00:47:10,020
And when all of us sit together, that's when we can take a look at a bunch of vulnerabilities for that feature application service very objectively.

544
00:47:10,020 --> 00:47:20,040
And that's what going to give us the, you know, correlation as well as what controls are already there, and it will help us understand the residual risk.

545
00:47:21,920 --> 00:47:31,820
Just adding to what my co-panelists are saying, I also think while this doesn't scale so much, threat emulation and threat simulation is also something that you should think about.

546
00:47:31,820 --> 00:47:36,280
So we have a red team that is actively attacking our network.

547
00:47:36,380 --> 00:47:39,060
We also have a blue team that's looking at stuff.

548
00:47:39,060 --> 00:47:41,620
So we are a great fan of purple teaming.

549
00:47:41,620 --> 00:47:44,000
Sometimes we go, okay, let's just take this.

550
00:47:44,000 --> 00:47:45,700
This is a critical asset.

551
00:47:45,700 --> 00:47:53,380
Can we go all the way from an external, you know, from the external perimeter all the way into our databases?

552
00:47:53,400 --> 00:48:01,580
And we kind of try to purple team that, you know, get everybody in a room, have some overall goals, get anything other than pizza, right?

553
00:48:01,580 --> 00:48:05,400
So that usually, it does get good things.

554
00:48:05,400 --> 00:48:10,220
But again, at scale, this doesn't scale so well.

555
00:48:10,220 --> 00:48:11,900
This is right.

556
00:48:11,900 --> 00:48:13,900
At the beginning, it doesn't scale.

557
00:48:13,900 --> 00:48:32,980
But I want to tell you all of you, tomorrow my esteemed co-worker Neelit is having a talk on how to build threat modeling-based pipeline where she's exactly going to talk about, you know, how you can do these different assessments in parallel, what input goes from one security assessment to another.

558
00:48:32,980 --> 00:48:37,620
So do not forget to attend her talk tomorrow along with Larkins.

559
00:48:37,620 --> 00:48:39,600
Can you guys raise your hands?

560
00:48:39,600 --> 00:48:43,080
Yeah, tomorrow definitely check their talk.

561
00:48:44,240 --> 00:48:46,960
Okay, everyone, we'll need to wrap up now.

562
00:48:46,960 --> 00:48:48,200
We're in time.

563
00:48:48,400 --> 00:48:55,780
We'll take the last question maybe offline, if that's okay, because we're already finished the time.

564
00:48:55,780 --> 00:49:03,040
I'd like to say thank you with a great shout out to Joe, Kiran, and Tupti for this panel.

565
00:49:04,400 --> 00:49:09,580
Sharing their amazing combined knowledge in application security.

566
00:49:09,580 --> 00:49:12,340
And of course, to the AppSec village.

567
00:49:12,340 --> 00:49:13,880
Hasn't it been great?

568
00:49:13,880 --> 00:49:15,540
I mean, it's growing bigger.

569
00:49:15,540 --> 00:49:16,760
It's amazing to see that.

570
00:49:16,760 --> 00:49:18,720
So thank you so much for having us today.