1
00:00:06,520 --> 00:00:10,880
Please welcome Ryan Nalette, 
Security Operations Engineer and

2
00:00:10,880 --> 00:00:15,920
Cloud Response at AWS, John 
Miller, Head of Mandiant 

3
00:00:15,920 --> 00:00:18,320
Intelligence Analysis at Google 
Cloud. 

4
00:00:18,800 --> 00:00:22,240
Alan. 
Shindo, VP of AI Threat Research

5
00:00:22,240 --> 00:00:27,600
at Wiz, hosted by Crying Out 
Cloud host Eden Kobe Naphtali. 

6
00:00:31,080 --> 00:00:35,560
Hello, my name is Eden Kobe 
Noftali and I am a product 

7
00:00:35,560 --> 00:00:39,240
manager at Wiz as well as the Co
host of the Crying Out Cloud 

8
00:00:39,240 --> 00:00:42,240
podcast. 
On the podcast, we fittingly 

9
00:00:42,240 --> 00:00:45,600
remind everyone at the beginning
of every episode that this is 

10
00:00:45,600 --> 00:00:50,400
the place to laugh, cry, and 
reconsider all of your cloud 

11
00:00:50,400 --> 00:00:54,080
security fears. 
So I think it's a good as time 

12
00:00:54,080 --> 00:00:57,840
as ever to do that. 
After Alon's amazing 

13
00:00:57,840 --> 00:01:02,160
presentation, really, it never 
ceases to amaze me the inspiring

14
00:01:02,160 --> 00:01:07,640
work that research is doing and 
also how fast the fret landscape

15
00:01:07,640 --> 00:01:11,120
is evolving. 
So thank you, Alon. 

16
00:01:11,120 --> 00:01:15,240
And Alon, in addition to being 
the VP of AI and Threat research

17
00:01:15,240 --> 00:01:19,400
at Wiz, he is also the producer 
of the Crying Out Cloud podcast.

18
00:01:19,400 --> 00:01:23,840
So this is super exciting to get
him from behind the scenes on 

19
00:01:23,840 --> 00:01:25,880
stage. 
OK. 

20
00:01:26,000 --> 00:01:29,720
And now we have an amazing 
chance to digest and continue 

21
00:01:29,720 --> 00:01:33,640
the conversation with our 
esteemed guest from GCP and AWS,

22
00:01:34,840 --> 00:01:37,360
John Miller and Ryan Dolett. 
Thank you for being here. 

23
00:01:38,080 --> 00:01:39,560
Thank you for having us. 
Yay. 

24
00:01:40,240 --> 00:01:43,720
OK, So just so everyone knows a 
little bit about who you are, 

25
00:01:43,720 --> 00:01:46,720
can you tell us a little bit 
about what your role is today? 

26
00:01:48,080 --> 00:01:52,080
Yeah, John Miller, I'm Director 
of Operations for Google Threat 

27
00:01:52,080 --> 00:01:55,240
Intelligence Group, which 
recently brought together Mandy 

28
00:01:55,240 --> 00:01:58,840
and Intelligence as well as as 
Google's Threat Analysis Group 

29
00:01:58,840 --> 00:02:02,320
tag. 
So we have a mission of applying

30
00:02:02,320 --> 00:02:05,360
threat intelligence to protect 
Google and our users and our 

31
00:02:05,360 --> 00:02:10,360
customers from advanced threats.
And my background personally is 

32
00:02:10,360 --> 00:02:13,240
in building and scaling threat 
intelligence teams. 

33
00:02:14,880 --> 00:02:18,280
And I'm Ryan Nollette. 
I'm the technical lead for the 

34
00:02:18,280 --> 00:02:20,720
vulnerability disclosure program
at EWS. 

35
00:02:21,680 --> 00:02:25,960
Basically I work with the people
who go to the dark places on the

36
00:02:25,960 --> 00:02:28,440
Internet, poke it with a stick 
and see what crawls out. 

37
00:02:29,080 --> 00:02:30,920
Those are the folks that report 
things to me. 

38
00:02:31,200 --> 00:02:34,120
I'm also the co-author of AWS 
Detective and a bunch of the 

39
00:02:34,440 --> 00:02:38,440
proactive defense tools and 
detection tools that AWS does. 

40
00:02:39,520 --> 00:02:42,400
Awesome. 
OK, so there's a question we ask

41
00:02:42,400 --> 00:02:45,520
everyone who comes on the 
podcast to actually get to know 

42
00:02:45,520 --> 00:02:48,920
them a little bit better. 
If you were a vulnerability, 

43
00:02:49,040 --> 00:02:51,040
what type of vulnerability would
you be? 

44
00:02:53,040 --> 00:02:56,680
I would not be an edge device 
vulnerability because I would be

45
00:02:56,680 --> 00:03:01,080
having a very busy year. 
So I think what I would be is 

46
00:03:01,080 --> 00:03:03,720
zero click remote code execution
because why settle for? 

47
00:03:03,720 --> 00:03:09,720
Less love it. 
I put a lot of thought into this

48
00:03:10,000 --> 00:03:15,360
so I think I'm going to go with 
zombie process because I seem 

49
00:03:15,360 --> 00:03:18,160
like I'm dead but I consume a 
lot of resources. 

50
00:03:19,760 --> 00:03:21,160
Great answer alone. 
What are you? 

51
00:03:21,440 --> 00:03:24,280
I'll be a malicious model, I 
think, because I like fancy new 

52
00:03:24,800 --> 00:03:26,760
new things. 
Yeah, he does. 

53
00:03:26,960 --> 00:03:33,280
I know that for a fact. 
OK, so now serious questions. 

54
00:03:33,280 --> 00:03:38,000
Let's start off where Alone left
off, how AI is affecting the 

55
00:03:38,000 --> 00:03:41,280
attack surface and a changing 
attacker behavior. 

56
00:03:41,680 --> 00:03:44,760
A long went through it how we 
see it from Wiz's perspective. 

57
00:03:44,760 --> 00:03:48,840
But John, I'm curious how it 
looks from the Google vantage 

58
00:03:48,840 --> 00:03:51,280
point. 
Also, as Google is incubating 

59
00:03:51,320 --> 00:03:55,800
really cool AI security 
projects, how do you think AI is

60
00:03:55,800 --> 00:03:59,640
shaping the security landscape? 
Where my mind goes with that 

61
00:03:59,640 --> 00:04:03,680
question is what do we see AI 
doing to how threat actors 

62
00:04:03,680 --> 00:04:06,000
operate? 
And the short answer there is we

63
00:04:06,000 --> 00:04:11,080
see extensive and rapid change 
in how threat actors operate 

64
00:04:11,080 --> 00:04:14,080
based on the availability of of 
AI technology. 

65
00:04:14,400 --> 00:04:17,920
And I think that's impacting the
landscape for defenders in two 

66
00:04:17,920 --> 00:04:20,959
really important ways. 
First of all, to just the level 

67
00:04:20,959 --> 00:04:25,200
of interest that we see, we see 
in underground communities, you 

68
00:04:25,200 --> 00:04:28,120
know where nation state actors 
and criminal actors source their

69
00:04:28,120 --> 00:04:31,440
capabilities. 
We see a growing number of tools

70
00:04:31,440 --> 00:04:34,440
and capabilities that malicious 
actors sell to each other that 

71
00:04:34,440 --> 00:04:37,600
are AI powered. 
Our team also took a look at 

72
00:04:37,600 --> 00:04:42,360
what threat actor activity do we
see attempting to use Gemini and

73
00:04:42,360 --> 00:04:43,800
we saw a whole lot there as 
well. 

74
00:04:43,800 --> 00:04:48,000
We saw threat actors from over 
20 countries trying to use that 

75
00:04:48,000 --> 00:04:52,960
one AI tool for capabilities 
really across the cycle of how 

76
00:04:52,960 --> 00:04:55,720
threat actors operate. 
And so, you know, given all that

77
00:04:55,720 --> 00:04:59,760
interest, what do we see 
actually happening to to how 

78
00:04:59,760 --> 00:05:02,120
threats manifest? 
And I think it comes down to two

79
00:05:02,120 --> 00:05:07,480
important changes #1 we see 
actors applying AI tooling to 

80
00:05:07,480 --> 00:05:09,960
increase the variability of 
their operations. 

81
00:05:10,120 --> 00:05:12,560
You called out just a minute 
ago, you know, generating 

82
00:05:12,560 --> 00:05:15,440
phishing content. 
We also see threat actors doing 

83
00:05:15,440 --> 00:05:18,960
things like using AI to bury the
commands that they execute in 

84
00:05:18,960 --> 00:05:21,480
victim environments. 
And I think that's challenging 

85
00:05:21,480 --> 00:05:26,160
defenders to up level their 
focus on preventing classes of 

86
00:05:26,160 --> 00:05:29,160
threats rather than individual 
instances of threats. 

87
00:05:29,400 --> 00:05:33,000
And the second change I would 
say we see being driven is an 

88
00:05:33,000 --> 00:05:36,840
increase in threat actors 
ability to respond and adapt to 

89
00:05:36,840 --> 00:05:39,480
challenges that they encounter 
in victim environments. 

90
00:05:40,320 --> 00:05:44,360
We see threat actors leaning on 
AI to do things like learn about

91
00:05:44,360 --> 00:05:48,200
new technology that they 
encounter in environments and to

92
00:05:48,200 --> 00:05:51,600
generate new tools quickly for 
interacting with utilities that 

93
00:05:51,600 --> 00:05:53,400
they encounter in victim 
environments. 

94
00:05:53,680 --> 00:05:56,640
And so I think that connects 
back to, you know, we heard 

95
00:05:56,640 --> 00:06:01,000
earlier today quite a bit about 
the concept of addressing 

96
00:06:01,000 --> 00:06:03,200
critical risks. 
More and more, you know, 

97
00:06:03,200 --> 00:06:07,560
defenders are in a race to solve
those before attackers do, 

98
00:06:07,560 --> 00:06:11,440
before attackers exploit them. 
And attackers speed to 

99
00:06:11,640 --> 00:06:14,800
exploiting those issues is being
accelerated by AI. 

100
00:06:16,480 --> 00:06:18,840
Totally. 
And Ryan, you have another 

101
00:06:18,840 --> 00:06:21,920
interesting viewpoint from 
another cloud provider, Amazon. 

102
00:06:21,920 --> 00:06:26,360
And also from the response side,
have you seen a change in the 

103
00:06:26,360 --> 00:06:30,600
number of incidents because of 
AI And can you share promising 

104
00:06:30,600 --> 00:06:33,560
mitigation strategies that 
you've already put into action? 

105
00:06:34,680 --> 00:06:37,080
Yeah. 
So I, I think there's a pretty 

106
00:06:37,080 --> 00:06:40,320
common theme that everyone's 
really set up today and that is 

107
00:06:40,520 --> 00:06:44,280
speed and context are the two 
really big changes with the 

108
00:06:44,280 --> 00:06:48,240
implementation of AI from the 
fence side. 

109
00:06:48,240 --> 00:06:52,920
Like I get vulnerability reports
sent to me right now, just like 

110
00:06:53,120 --> 00:06:56,840
the blue teams and everyone else
here who is using AI to try and 

111
00:06:56,840 --> 00:06:59,600
improve their life, their 
workflows, etcetera. 

112
00:07:00,000 --> 00:07:03,200
So are threat actors and 
researchers, etcetera. 

113
00:07:03,480 --> 00:07:07,520
So one of the big changes I got 
is called AI slot. 

114
00:07:08,440 --> 00:07:12,000
Most of you probably have 
members of your team who use AI 

115
00:07:12,000 --> 00:07:14,160
to generate their reports. 
So you know what I'm talking 

116
00:07:14,160 --> 00:07:17,480
about. 10 pages to say two 
things. 

117
00:07:18,000 --> 00:07:23,480
And where this really falls in 
as a big issue is that when 

118
00:07:23,480 --> 00:07:27,040
you're accepting vulnerability 
reports, you have to treat 

119
00:07:27,040 --> 00:07:31,440
everything as a valid issue 
until you prove it is not. 

120
00:07:32,000 --> 00:07:38,360
And as nice as these reports 
look, it tells you nothing. 

121
00:07:39,200 --> 00:07:42,280
And that is one of the the big 
like resource and time killers 

122
00:07:42,280 --> 00:07:44,880
that you get because people are 
leveraging AI to make the 

123
00:07:44,880 --> 00:07:49,080
reports look better. 
And it's taking human time away 

124
00:07:49,080 --> 00:07:53,000
because you have to decode those
reports on. 

125
00:07:53,080 --> 00:07:57,440
Additionally, when we do get 
those valid reports in building,

126
00:07:57,720 --> 00:08:01,920
So AWS is a team of builders. 
Our biggest focus is always on 

127
00:08:01,920 --> 00:08:04,160
securing the customer. 
You've heard a lot in our 

128
00:08:04,160 --> 00:08:07,880
messaging. 
When the things are found and we

129
00:08:07,880 --> 00:08:11,920
have to fix them, are we going 
to do some kind of vibe code and

130
00:08:11,920 --> 00:08:13,480
are we going to do regular 
development? 

131
00:08:13,480 --> 00:08:17,120
You have a senior look at it. 
How are you prioritizing the 

132
00:08:17,120 --> 00:08:19,800
risk that has come in to be 
fixed? 

133
00:08:20,080 --> 00:08:23,720
Is it a low enough risk that you
could use AI just to fix it, or 

134
00:08:23,720 --> 00:08:26,680
do you want to give it to one of
your senior developers to make 

135
00:08:26,680 --> 00:08:29,680
sure it's done and done right 
the first time? 

136
00:08:30,120 --> 00:08:35,880
And with the increase of AI 
usage, we're seeing that the 

137
00:08:35,880 --> 00:08:41,159
human factor of deciding where 
in the loop the human goes in 

138
00:08:41,159 --> 00:08:44,680
the AI workflow really depends 
on the severity of the risk. 

139
00:08:44,720 --> 00:08:48,360
And it allows us to change 
prioritization and how we assess

140
00:08:48,360 --> 00:08:50,560
risks. 
And hopefully a bit later we'll 

141
00:08:50,560 --> 00:08:54,080
talk more about different types 
of vibe coding and ways to kind 

142
00:08:54,080 --> 00:08:55,800
of improve the security around 
those. 

143
00:08:56,240 --> 00:08:58,800
But those are the two of the big
things that we see. 

144
00:08:58,800 --> 00:09:01,680
Also you guys are probably 
seeing in the news, there are 

145
00:09:01,680 --> 00:09:06,760
now entire development teams 
that are AI bug hunters. 

146
00:09:08,480 --> 00:09:14,040
We have worked with a few very 
low fidelity so far in finding 

147
00:09:14,040 --> 00:09:17,800
things successfully that are of 
any critical criticality. 

148
00:09:19,280 --> 00:09:21,880
And I think that's going to 
change over the next couple of 

149
00:09:21,880 --> 00:09:24,240
years. 
But vulnerability scanners 

150
00:09:24,240 --> 00:09:26,160
started out like this as well, 
right? 

151
00:09:26,160 --> 00:09:28,480
They looked for the common 
things, the stuff everybody kind

152
00:09:28,480 --> 00:09:31,880
of knows to look for, but get 
missed sometimes by people in a 

153
00:09:31,880 --> 00:09:34,120
rush. 
And as they mature, they're 

154
00:09:34,120 --> 00:09:37,040
going to be more complex and 
they're going to be looking at 

155
00:09:37,040 --> 00:09:39,120
things besides just your supply 
chain. 

156
00:09:39,360 --> 00:09:44,200
Yeah, that's Kelly. 
And so how are you using AI to 

157
00:09:44,200 --> 00:09:47,240
help you and your teams, not 
just looking at AI as a threat? 

158
00:09:50,200 --> 00:09:53,480
Yeah, good question. 
First of all, we definitely are 

159
00:09:53,480 --> 00:09:57,400
seeing many use cases where AI 
is really accelerating what our 

160
00:09:57,400 --> 00:10:02,040
team can do from being able to 
process large amounts of event 

161
00:10:02,040 --> 00:10:05,240
data and tell our experts where 
they need to look closer, 

162
00:10:05,560 --> 00:10:10,320
identify new malicious codes, 
generate detections, monitor 

163
00:10:10,320 --> 00:10:13,160
underground communities where 
there's a lot of noisy activity.

164
00:10:13,880 --> 00:10:17,640
And I think a key question a lot
of organizations are having to 

165
00:10:17,640 --> 00:10:21,960
ask right now is given just how 
much opportunity there is and 

166
00:10:21,960 --> 00:10:25,480
how many different opportunities
they hear about, how can they 

167
00:10:25,480 --> 00:10:28,120
make sure that they're not 
missing the right opportunities,

168
00:10:28,360 --> 00:10:31,680
you know, to apply those 
capabilities to to their own 

169
00:10:31,680 --> 00:10:33,520
organizations? 
And so I think it's really 

170
00:10:33,520 --> 00:10:37,240
important to be able to step 
back and look at the area of 

171
00:10:37,240 --> 00:10:39,680
security you're assessing and 
ask, you know, what's a useful 

172
00:10:39,680 --> 00:10:42,920
framework to be able to 
inventory the things that need 

173
00:10:42,920 --> 00:10:46,960
to happen and think about where 
can I apply AI to those? 

174
00:10:46,960 --> 00:10:49,440
And I'll give an example in the 
world of threat intelligence. 

175
00:10:49,440 --> 00:10:53,920
SO1 framework for thinking about
what has to happen in order to 

176
00:10:53,920 --> 00:10:57,680
create threat intelligence would
be 3 things, visibility, 

177
00:10:57,960 --> 00:11:01,400
processing, and interpretation. 
Visibility would be I have 

178
00:11:01,400 --> 00:11:05,400
access to useful security data, 
for example, malicious emails. 

179
00:11:05,680 --> 00:11:09,880
Processing would be, I use that 
to create useful standardized 

180
00:11:09,880 --> 00:11:13,440
observations. 
For example, what malware did we

181
00:11:13,440 --> 00:11:15,680
see associated with malicious 
emails? 

182
00:11:15,680 --> 00:11:19,600
And, and #3 Interpretation would
be, I use that to answer a 

183
00:11:19,600 --> 00:11:23,320
stakeholder questions like how 
big a risk is this type of 

184
00:11:23,320 --> 00:11:26,240
malware to our organization? 
And you can break down 

185
00:11:26,240 --> 00:11:29,480
capability that way. 
And in that example, say, OK, 

186
00:11:30,000 --> 00:11:35,040
visibility, the advent of MCP 
servers, excuse me, the advent 

187
00:11:35,040 --> 00:11:39,960
of MCP servers is making it a 
lot easier for organizations to 

188
00:11:39,960 --> 00:11:43,600
accelerate integration work for 
new data sources, effectively 

189
00:11:44,000 --> 00:11:47,400
processing lots and lots of 
opportunities there because 

190
00:11:47,560 --> 00:11:50,840
there is stereotypically so much
security data that was below the

191
00:11:50,840 --> 00:11:52,720
threshold of what anyone can 
look at. 

192
00:11:52,720 --> 00:11:56,400
And now an agentic workflow can 
look at it to at least some 

193
00:11:56,400 --> 00:12:01,040
extent the interpretation phase,
we see probably the most need 

194
00:12:01,040 --> 00:12:03,400
for a human in the loop because 
that's often the point where 

195
00:12:03,400 --> 00:12:06,360
you're making a significant 
security decision, but still 

196
00:12:06,360 --> 00:12:08,680
plenty of opportunity to 
accelerate workflows. 

197
00:12:08,880 --> 00:12:11,400
So overall, you know, being able
to step back and look at 

198
00:12:11,400 --> 00:12:14,120
capabilities through the lens of
that type of framework is really

199
00:12:14,120 --> 00:12:16,720
important to make sure the 
organization is pursuing the 

200
00:12:16,720 --> 00:12:21,840
right opportunities. 
Human in the OODA loop, right? 

201
00:12:21,840 --> 00:12:26,000
For those who don't do a lot of 
security, UDA is a fighter jet 

202
00:12:26,120 --> 00:12:29,240
or a dog fighting type thing 
that was invented for military a

203
00:12:29,240 --> 00:12:32,840
long time ago, stands for 
observe, Orient decide act. 

204
00:12:33,000 --> 00:12:36,640
And it's critical part of 
incident response and you know, 

205
00:12:36,680 --> 00:12:37,760
siding fact. 
Thank you. 

206
00:12:38,080 --> 00:12:40,080
There's four people clapping, 
which is surprising. 

207
00:12:42,280 --> 00:12:46,280
And that was a really bad joke. 
All right, moving on to a couple

208
00:12:46,280 --> 00:12:49,520
other things that we're seeing 
with AI internally to try and 

209
00:12:49,520 --> 00:12:52,840
improve things for us. 
As I said, I read a lot of 

210
00:12:52,840 --> 00:12:55,720
reports. 
I also read a lot of content. 

211
00:12:55,800 --> 00:13:03,280
Part of my groups or my teams 
role is being the CNA for Amazon

212
00:13:03,280 --> 00:13:05,600
and AWS. 
So we issue out security 

213
00:13:05,600 --> 00:13:10,440
advisories, so CVS, GHS as 
security bulletins, lots of 

214
00:13:10,440 --> 00:13:14,040
written content that all has to 
get generated. 

215
00:13:14,160 --> 00:13:18,560
And a lot of it has to also go 
through content that researchers

216
00:13:18,560 --> 00:13:21,480
send us, you know, blogs, 
presentations, things like that,

217
00:13:21,480 --> 00:13:23,840
that they'd like technical 
feedback on. 

218
00:13:24,520 --> 00:13:26,400
You know, how do we assess them 
at scale? 

219
00:13:26,880 --> 00:13:32,080
So we've written things that 
allow us to consistently and 

220
00:13:32,080 --> 00:13:37,320
repeatedly assess content for 
the same questions over and over

221
00:13:37,320 --> 00:13:39,200
and over. 
So very much like what you would

222
00:13:39,360 --> 00:13:44,480
have your analysts do, we're 
trying to write things with Jen 

223
00:13:44,480 --> 00:13:48,360
AI to do. 
So there's a couple of 

224
00:13:48,360 --> 00:13:52,400
challenges that I've seen. 
So last week I wrote my first 

225
00:13:52,400 --> 00:13:56,440
ever completely independent MCP 
server for an application that I

226
00:13:56,440 --> 00:13:58,160
like has nothing to do with my 
work. 

227
00:13:59,160 --> 00:14:02,600
After actually writing it and 
making sure it all worked, I 

228
00:14:02,600 --> 00:14:05,440
then went and I tried to do a 
security review of it. 

229
00:14:05,680 --> 00:14:10,120
So I used a bunch of different 
AI tools from various vendors to

230
00:14:10,120 --> 00:14:12,240
actually do security assessments
against it. 

231
00:14:13,080 --> 00:14:15,960
The biggest thing I found was 
inconsistency. 

232
00:14:15,960 --> 00:14:19,320
Even when you asked the question
the same way in the same prompt.

233
00:14:19,640 --> 00:14:25,120
So it brought up, how do we 
improve that response? 

234
00:14:25,240 --> 00:14:29,920
And as a lot of vendors are 
saying now, context, making your

235
00:14:30,040 --> 00:14:34,920
AI context aware so it's able to
see all the information. 

236
00:14:35,320 --> 00:14:38,880
So we have things like vector 
databases and RAG and all that 

237
00:14:38,880 --> 00:14:41,040
kind of cool stuff. 
Each vendor I believe has a 

238
00:14:41,040 --> 00:14:44,880
different name for it, but we're
using that to improve the 

239
00:14:44,880 --> 00:14:49,640
repeatability and accuracy. 
Additionally, what I like to 

240
00:14:49,640 --> 00:14:52,320
write in my Gen. 
AI stuff when I'm assessing 

241
00:14:52,320 --> 00:14:55,960
contents, tickets, entire 
engagements, is that when it 

242
00:14:55,960 --> 00:15:00,760
gives a a response that it gives
a quote from where it found that

243
00:15:00,760 --> 00:15:05,160
answer and the exact text that 
was used to answer that 

244
00:15:05,160 --> 00:15:07,840
question. 
So then we can score it for 

245
00:15:07,840 --> 00:15:11,640
accuracy after the fact because 
a large part of using AI 

246
00:15:11,640 --> 00:15:15,200
internally is scoring right? 
How accurate was it? 

247
00:15:15,200 --> 00:15:16,920
How do I improve it going 
forward? 

248
00:15:17,360 --> 00:15:22,360
Thinking of the AI assistant as 
just a very junior analyst and 

249
00:15:22,360 --> 00:15:24,920
training it the same way you 
would train a very junior 

250
00:15:24,920 --> 00:15:28,680
analyst is how we've been trying
to implement. 

251
00:15:28,960 --> 00:15:32,760
Yeah, for sure. 
And following the threat of AI, 

252
00:15:32,760 --> 00:15:34,480
one of the things that Leung 
talked about was like the 

253
00:15:34,480 --> 00:15:39,120
Singularity incident where AI 
and supply chain security 

254
00:15:39,360 --> 00:15:42,440
crossover. 
What trends are you seeing in 

255
00:15:42,440 --> 00:15:44,320
threats to supply chain 
security? 

256
00:15:46,360 --> 00:15:48,840
Well, we see a lot of 
opportunities for improvement, 

257
00:15:49,400 --> 00:15:52,160
especially supply chain 
management. 

258
00:15:52,880 --> 00:15:57,880
We do see not, not just like 
particularly at AWS, but when 

259
00:15:57,880 --> 00:16:01,560
you look at the open source 
offerings with LLM in general or

260
00:16:01,640 --> 00:16:04,800
AI in general, there's a lot of 
reuse of code. 

261
00:16:05,040 --> 00:16:08,120
Like 3 people figured out how to
do something and posted it on 

262
00:16:08,120 --> 00:16:10,880
Stack Overflow and everyone just
copied it. 

263
00:16:11,040 --> 00:16:14,720
So now when there's an issue 
there, it's not just an issue in

264
00:16:14,720 --> 00:16:18,440
one person's package, it's an 
issue in 30,000 packages because

265
00:16:18,440 --> 00:16:22,000
they all either copied the same 
function or they're using it as 

266
00:16:22,000 --> 00:16:25,800
a dependency. 
So how do you go up the supply 

267
00:16:25,800 --> 00:16:29,240
chain and get those things fixed
for all the downstream people 

268
00:16:29,360 --> 00:16:33,160
who really, And that's one of 
the areas our team looks at, 

269
00:16:33,320 --> 00:16:36,440
because we're trying to help the
community secure itself. 

270
00:16:36,800 --> 00:16:40,920
So finding who actually wrote 
this and like the top 

271
00:16:40,920 --> 00:16:44,520
attribution person to get it 
patched so then everyone below 

272
00:16:44,520 --> 00:16:47,560
it can inherit the patch and 
secure the community as a whole 

273
00:16:47,560 --> 00:16:51,240
is one of our big goals. 
And also call out one of the 

274
00:16:51,280 --> 00:16:55,440
most important trends in supply 
chains threats that that I'm 

275
00:16:55,440 --> 00:16:57,960
seeing right now. 
Actually one of the one of the 

276
00:16:58,240 --> 00:17:01,080
threat actors and, and campaigns
that we heard called out a 

277
00:17:01,080 --> 00:17:04,960
couple minutes ago, the 5221 
Rickstorm activity, I think is a

278
00:17:04,960 --> 00:17:08,560
really good illustration of, of 
this particular trend. 

279
00:17:08,560 --> 00:17:12,319
So this is a sophisticated China
Nexus actor. 

280
00:17:12,480 --> 00:17:15,319
And what we've seen is this is 
an actor that historically has 

281
00:17:15,319 --> 00:17:18,920
been tied to targeting 
technology companies in order to

282
00:17:18,920 --> 00:17:22,280
get insight into undisclosed 
vulnerabilities. 

283
00:17:22,520 --> 00:17:26,800
The brickstorm activity that we 
reported recently, we saw this 

284
00:17:26,800 --> 00:17:29,880
actor engaging in in campaigns 
that were that were notable for 

285
00:17:29,880 --> 00:17:33,200
a couple reasons. 
In at least some of those cases 

286
00:17:33,480 --> 00:17:36,800
we saw and at least some of the 
compromises that we saw, the 

287
00:17:36,800 --> 00:17:40,480
threat actor was getting in by 
exploitation of edge devices. 

288
00:17:41,200 --> 00:17:44,040
Two, in a lot of cases it was 
difficult to tell how they got 

289
00:17:44,040 --> 00:17:47,240
in because they've been present 
in the environment for over a 

290
00:17:47,240 --> 00:17:50,200
year before they were detected, 
which is is kind of crazy. 

291
00:17:51,240 --> 00:17:54,400
And 3rd in, in a lot of those 
cases, you know, they were 

292
00:17:54,400 --> 00:17:58,040
targeting software as a service 
and other supply chain providers

293
00:17:58,200 --> 00:18:01,880
where they could get at 
potentially both sensitive data 

294
00:18:02,040 --> 00:18:05,440
as well as again potentially 
insight into undisclosed 

295
00:18:05,440 --> 00:18:07,920
vulnerabilities. 
And So what we see there is 

296
00:18:07,920 --> 00:18:12,800
possibly a cycle of supply chain
activity where supply chain 

297
00:18:12,800 --> 00:18:16,000
incidents enable this attacker 
to continue to conduct more 

298
00:18:16,000 --> 00:18:18,720
supply chain attacks. 
And I think, you know, again, 

299
00:18:18,720 --> 00:18:22,160
referencing back to the fact 
that these incidents involved 

300
00:18:22,160 --> 00:18:25,680
compromise of edge devices that 
really highlights the importance

301
00:18:25,680 --> 00:18:29,360
that we heard called out 
earlier, defenders being able to

302
00:18:29,360 --> 00:18:33,480
understand and get visibility 
and to address risks around 

303
00:18:33,680 --> 00:18:36,120
these devices. 
This is a particular area where 

304
00:18:36,120 --> 00:18:39,480
we see threat actors challenging
defenders today and there is a 

305
00:18:39,480 --> 00:18:41,760
connection to supply chain 
threats. 

306
00:18:42,760 --> 00:18:46,240
And can I also just chime in 
that this is actually a a really

307
00:18:46,240 --> 00:18:50,920
good topic with the supply chain
because there's a big event 

308
00:18:50,920 --> 00:18:56,560
coming up in December where a 
WSGCP and Azure are all 

309
00:18:56,560 --> 00:19:05,120
combining with wiz0day.cloud 
event where the the targets that

310
00:19:05,120 --> 00:19:09,040
are in there, well, they're all 
dependencies that a bunch of the

311
00:19:09,040 --> 00:19:11,480
CSPS use. 
Why are we joining up to do 

312
00:19:11,480 --> 00:19:14,120
this? 
To protect the shared customer. 

313
00:19:14,520 --> 00:19:16,720
We all use these dependencies. 
Yeah. 

314
00:19:16,800 --> 00:19:20,240
So let's let's put the money 
where our mouth is, right? 

315
00:19:20,240 --> 00:19:22,200
And let's see where it goes. 
OK. 

316
00:19:22,240 --> 00:19:25,760
On that note and to wrap in 
front of your cloud security 

317
00:19:25,760 --> 00:19:29,240
leaders, practitioners, teams 
and given all the trends we've 

318
00:19:29,240 --> 00:19:31,960
looked at in the current 
threatscape, if you had to give 

319
00:19:31,960 --> 00:19:35,560
a one liner piece of advice to 
these teams, what would it be? 

320
00:19:37,440 --> 00:19:40,520
I'm terrible with one liners. 
I think you can do a few lines. 

321
00:19:40,760 --> 00:19:45,920
OK, Yeah, across the, you know, 
the, the activity that we see at

322
00:19:46,320 --> 00:19:50,960
I think what stands out to us, 
there are a couple areas of 

323
00:19:51,400 --> 00:19:54,120
opportunity that are really 
important for defenders right 

324
00:19:54,120 --> 00:19:56,160
now. 
We we heard a couple minutes ago

325
00:19:56,160 --> 00:19:59,560
that threat actors are 
increasingly tailoring their 

326
00:19:59,800 --> 00:20:02,880
their behavior to cloud assets. 
We absolutely do see that 

327
00:20:02,880 --> 00:20:07,600
happening and the areas where we
see in breaches that we look at 

328
00:20:07,600 --> 00:20:10,440
defenders having the most 
opportunity really come down to 

329
00:20:10,680 --> 00:20:14,840
identity. 
Integrations with on premise and

330
00:20:14,840 --> 00:20:18,800
visibility identity attackers 
are focusing in on you know how 

331
00:20:18,800 --> 00:20:20,840
can they subvert getting 
credentials, How can they 

332
00:20:20,840 --> 00:20:24,400
subvert multi factor connection 
to on premise. 

333
00:20:24,600 --> 00:20:29,200
As an example, we have seen 
cases in which attackers 

334
00:20:29,200 --> 00:20:32,280
targeted identity management 
solutions that were synchronized

335
00:20:32,280 --> 00:20:37,520
between on premise and cloud and
targeted the on premise side of 

336
00:20:37,520 --> 00:20:40,360
things as a way to get into the 
cloud environment. 

337
00:20:40,360 --> 00:20:44,640
So taking a close look at 
connections back into on premise

338
00:20:44,640 --> 00:20:47,240
is really critical. 
And then the third visibility, 

339
00:20:47,440 --> 00:20:51,040
many organizations approach to 
logging they find just doesn't 

340
00:20:51,040 --> 00:20:53,920
translate well when they're 
having to investigate a cloud 

341
00:20:53,920 --> 00:20:56,720
incident. 
And so pursuing cloud specific 

342
00:20:56,840 --> 00:21:00,000
sources of visibility is really 
critical as well. 

343
00:21:00,000 --> 00:21:02,360
So I would say those are some of
the most important themes we see

344
00:21:02,360 --> 00:21:02,880
right now. 
Good. 

345
00:21:03,480 --> 00:21:07,200
Advice. 
OK, visibility and 

346
00:21:07,200 --> 00:21:10,200
accountability. 
If you can't see it, you can't 

347
00:21:10,200 --> 00:21:12,560
account for it. 
So keep improving your 

348
00:21:12,560 --> 00:21:15,920
visibility until you can answer 
the three basic questions of who

349
00:21:15,920 --> 00:21:20,080
did what and when. 
Amazing and. 

350
00:21:20,080 --> 00:21:23,560
It's a another thing that 
written in the vision space is 

351
00:21:23,560 --> 00:21:26,280
eyes on the ball. 
I think that I agree with what 

352
00:21:26,280 --> 00:21:29,720
you said, but we here today and 
especially now with AI, there's 

353
00:21:29,720 --> 00:21:33,520
so much noise and, and you know,
there are new novel techniques 

354
00:21:33,520 --> 00:21:37,640
that you see and you read about.
But in the end, most of the real

355
00:21:37,640 --> 00:21:41,280
incidents that we see, they 
start from the areas that we 

356
00:21:41,280 --> 00:21:43,600
already know from, you know, 
data leaks from the 

357
00:21:43,600 --> 00:21:46,960
infrastructure to even when 
there are new techniques, you 

358
00:21:46,960 --> 00:21:51,280
always have to stick to the 
frameworks and principles that 

359
00:21:51,280 --> 00:21:54,640
you already have for your 
involvements today and think how

360
00:21:54,640 --> 00:21:57,840
you can extend them to these new
type of Nova threats. 

361
00:21:58,520 --> 00:22:00,720
Amazing. 
Thank you all, and thank you for

362
00:22:00,720 --> 00:22:02,840
listening to our live episode of
the podcast. 

363
00:22:02,840 --> 00:22:06,080
If you want to listen to more, 
you can on wherever you listen 

364
00:22:06,080 --> 00:22:08,800
to your podcasts. 
And thank you for joining us. 

365
00:22:10,640 --> 00:22:10,960
Thank you.