1
00:00:00,370 --> 00:00:01,900
Attackers have gotten very smart.

2
00:00:02,130 --> 00:00:04,950
They realize that they have to go after the backups in

3
00:00:04,950 --> 00:00:08,690
addition to the primary environment, because if an organization

4
00:00:08,740 --> 00:00:10,870
can recover, then they're not gonna pay the ransom.

5
00:00:10,889 --> 00:00:13,260
And the reality is, that the vast majority of

6
00:00:13,260 --> 00:00:16,090
ransomware events are attackers just trying to make

7
00:00:25,540 --> 00:00:25,580
money.

8
00:00:25,580 --> 00:00:27,060
Welcome to Screaming in the Cloud.

9
00:00:27,259 --> 00:00:29,990
I'm Corey Quinn, and this promoted guest episode

10
00:00:29,990 --> 00:00:32,560
is brought to us by our friends at Rubrik.

11
00:00:32,689 --> 00:00:35,449
They also bring to us their chief product officer.

12
00:00:35,820 --> 00:00:41,090
Anneka Gupta has been there for about four years now - first thank you for

13
00:00:41,090 --> 00:00:44,160
daring to put up with my slings, arrows and other implements of misfortune.

14
00:00:44,349 --> 00:00:45,790
I'm excited to be here.

15
00:00:45,800 --> 00:00:46,790
Thanks for having me.

16
00:00:47,620 --> 00:00:51,610
Let’s talk about something I’ve written about before: S3 is not a backup.

17
00:00:51,660 --> 00:00:54,129
I know, I know—you’re versioning, you’re replicating

18
00:00:54,129 --> 00:00:56,650
to another region, you even have lifecycle policies.

19
00:00:56,860 --> 00:01:00,810
Congratulations, you’ve built an expensive way to lose data slightly slower.

20
00:01:01,080 --> 00:01:03,280
Here’s the thing: when ransomware compromises your

21
00:01:03,280 --> 00:01:06,699
credentials—and it will—it can delete every version in every

22
00:01:06,700 --> 00:01:09,499
region because it’s all using the same access controls.

23
00:01:09,589 --> 00:01:10,919
That’s where Rubrik comes in.

24
00:01:11,139 --> 00:01:14,840
They actually air-gap your backups from your AWS credentials, make them

25
00:01:14,930 --> 00:01:18,679
immutable, and can tell you which snapshots are clean when you need to recover.

26
00:01:18,820 --> 00:01:19,950
That’s a backup.

27
00:01:20,050 --> 00:01:23,050
Learn more at rubrik.com/SITC.

28
00:01:24,110 --> 00:01:26,280
So let's, let's start at the very beginning here.

29
00:01:26,289 --> 00:01:30,340
What does Rubrik do, followed up with, and what

30
00:01:30,340 --> 00:01:32,740
does a chief product officer at such a place do?

31
00:01:32,930 --> 00:01:33,670
Absolutely.

32
00:01:33,880 --> 00:01:36,970
So Rubrik is a security and AI operations company.

33
00:01:36,980 --> 00:01:39,270
We help organizations recover.

34
00:01:39,440 --> 00:01:42,189
Their data when they've been hit with cyber attacks,

35
00:01:42,200 --> 00:01:45,919
uh, such as ransomware, and we help them build cyber

36
00:01:45,920 --> 00:01:49,600
resilience into their, their infrastructure and strategies.

37
00:01:49,840 --> 00:01:54,230
We're also doing a lot around helping our organizations operationalize AI.

38
00:01:54,540 --> 00:02:00,479
As a chief product officer, my day is quite varied, but my role fundamentally

39
00:02:00,500 --> 00:02:04,700
is about enabling our product strategy and product roadmap and really

40
00:02:04,719 --> 00:02:08,970
thinking about what is it that we can solve better for our customers and

41
00:02:08,970 --> 00:02:13,380
how do we continue to innovate and innovate and innovate in this highly

42
00:02:13,380 --> 00:02:17,420
evolving landscape, um, at the intersection of data security and AI.

43
00:02:17,810 --> 00:02:21,459
So I'm going to back up a little bit here and, uh, date myself

44
00:02:21,460 --> 00:02:25,000
somewhat that I'm an old crusty sysadmin from once upon a time,

45
00:02:25,020 --> 00:02:29,180
and I've always tended to view the idea of cyber resilience as

46
00:02:29,180 --> 00:02:32,900
being a fancy upmarket term for make sure that you take backups.

47
00:02:33,099 --> 00:02:34,350
We start talking about ai.

48
00:02:34,350 --> 00:02:37,320
It's, ah, but we've had tape robots since the last century.

49
00:02:37,630 --> 00:02:39,829
Uh, I get the sense that events may have

50
00:02:40,150 --> 00:02:43,350
outpaced me in this particular part of the world.

51
00:02:43,520 --> 00:02:45,370
It feels like it goes beyond backups today.

52
00:02:45,670 --> 00:02:48,940
That's a great question and a great perspective.

53
00:02:48,940 --> 00:02:50,620
I think that we end up talking to a lot

54
00:02:50,620 --> 00:02:52,859
of people that share this perspective too.

55
00:02:53,050 --> 00:02:56,390
If you think about the technology of backup and recovery

56
00:02:56,400 --> 00:02:59,500
and the way that the use cases have evolved really.

57
00:02:59,789 --> 00:03:02,770
Originally, it was really around natural disasters and

58
00:03:02,770 --> 00:03:05,790
natural disasters that were gonna hit your data center or

59
00:03:05,790 --> 00:03:09,970
operational issues that, again, end up hitting your data center.

60
00:03:10,120 --> 00:03:14,019
But what we've seen is, first of all, as the data landscape has

61
00:03:14,020 --> 00:03:18,029
evolved, as organizations both have data that are still in their

62
00:03:18,029 --> 00:03:21,120
data center, data that's in the cloud, data that's in SAS app.

63
00:03:21,210 --> 00:03:25,190
Now the surface area is so much broader and the challenges

64
00:03:25,190 --> 00:03:28,429
are so much broader as well, that on top of that, what we've

65
00:03:28,429 --> 00:03:32,120
seen is that there's been an evolution where it's not just now

66
00:03:32,120 --> 00:03:36,730
about operational failures or natural disasters, it's actually.

67
00:03:36,840 --> 00:03:39,779
A lot of the time organizations are having to recover from cyber

68
00:03:39,780 --> 00:03:44,420
attacks, and when you're actually executing a cyber recovery,

69
00:03:44,440 --> 00:03:47,620
it's actually quite different than operational recovery because

70
00:03:47,630 --> 00:03:52,109
in a cyber event, it's not just about, Hey, recover everything.

71
00:03:52,109 --> 00:03:56,070
To the most recent point in a cyber event, you have to

72
00:03:56,080 --> 00:03:59,320
answer critical questions like: What was the blast radius?

73
00:03:59,440 --> 00:04:02,340
How do I find a clean point of recovery so I don't

74
00:04:02,500 --> 00:04:05,530
reintroduce malware into my production systems?

75
00:04:05,759 --> 00:04:07,390
How do I quarantine the malware?

76
00:04:07,400 --> 00:04:10,360
How do I know if sensitive data was impacted?

77
00:04:10,529 --> 00:04:14,839
All of these questions you have to answer before you actually do a recovery.

78
00:04:15,070 --> 00:04:18,810
And the challenge is, is that to answer those questions without

79
00:04:18,850 --> 00:04:23,069
a technology like Rubrik, it often takes weeks or months in order

80
00:04:23,070 --> 00:04:25,879
to actually be able to find that clean point of recovery and

81
00:04:25,880 --> 00:04:28,640
to answer all these questions and to get back up and running.

82
00:04:28,750 --> 00:04:32,000
And what we have seen firsthand is with our customers, is that they've

83
00:04:32,000 --> 00:04:37,380
been able to really shorten that cyber recovery time by about a hundred x

84
00:04:37,410 --> 00:04:41,800
and that has allowed them to have, be more confident that in a cyber event

85
00:04:42,020 --> 00:04:45,670
they can actually minimize the overall downtime of their business, which

86
00:04:45,670 --> 00:04:51,289
is hugely impactful because in a cyber event, it's not just the ransom that

87
00:04:51,290 --> 00:04:55,350
you may have to pay, it's actually the cost of downtime for your business,

88
00:04:55,350 --> 00:04:59,180
which can massively outsize compared to like what a, a ransom might be.

89
00:04:59,580 --> 00:05:01,480
How challenging has it been to productize this?

90
00:05:01,500 --> 00:05:04,949
Because I think back at the places that I've worked as a grumpy

91
00:05:04,949 --> 00:05:08,370
sys admin, which we then call, you know, DevOps, or platform

92
00:05:08,370 --> 00:05:11,930
engineering or SRE, which is the same thing, they just pay better.

93
00:05:12,000 --> 00:05:12,390
Great.

94
00:05:12,710 --> 00:05:14,809
The problem that I found was that.

95
00:05:15,150 --> 00:05:16,680
Planning for backups and restores.

96
00:05:16,730 --> 00:05:17,770
'cause no one cares about backups.

97
00:05:17,770 --> 00:05:19,240
They care very much about restores.

98
00:05:19,440 --> 00:05:24,739
But getting back to a point of viability was a highly bespoke process in every

99
00:05:24,740 --> 00:05:28,760
case due to architectural limitations, implementation decisions that have been

100
00:05:28,760 --> 00:05:31,799
made in years past, and of course, the specifics of a given business model.

101
00:05:32,349 --> 00:05:32,949
Absolutely.

102
00:05:32,950 --> 00:05:38,289
So the way that Rubrik architected our systems from day one was really figuring

103
00:05:38,290 --> 00:05:45,239
out how we could build a unified platform that could create a single way to

104
00:05:45,240 --> 00:05:51,449
manage and operate your backup and recovery across on-prem, cloud, and SaaS.

105
00:05:51,889 --> 00:05:56,430
And so we have built things that makes it super operationally easy, way

106
00:05:56,450 --> 00:05:59,810
easier to deploy where you don't need as much hardware on-prem and in

107
00:05:59,810 --> 00:06:04,409
the cloud we have cloud native ways of deploying our technology and so it

108
00:06:04,410 --> 00:06:09,040
becomes a lot easier to operationalize across this, this whole ecosystem.

109
00:06:09,260 --> 00:06:13,919
And the reality is, is that the way to do recoveries well and

110
00:06:13,920 --> 00:06:17,960
fast, um, across these different surface areas is really different.

111
00:06:17,960 --> 00:06:21,130
And the limitations and technical challenges are very different.

112
00:06:21,750 --> 00:06:26,010
Also when we think about how do you actually, um, how do you actually like

113
00:06:26,010 --> 00:06:30,680
scan for malware and find clean points of recovery and know what was impacted?

114
00:06:31,030 --> 00:06:33,409
Well, how you really do it or how you tell the auditors you do it.

115
00:06:33,410 --> 00:06:33,701
I see.

116
00:06:33,701 --> 00:06:34,428
Those should be congruent.

117
00:06:34,610 --> 00:06:34,810
They should be

118
00:06:36,590 --> 00:06:36,929
congruent.

119
00:06:36,990 --> 00:06:37,310
Yeah.

120
00:06:37,310 --> 00:06:39,700
But there it's really hard, like as you said, in

121
00:06:39,760 --> 00:06:42,409
per like previous to, to customers using Rubrik.

122
00:06:42,440 --> 00:06:45,910
Often what our customers have to do is rehydrate the data.

123
00:06:46,070 --> 00:06:48,669
Then run some kind of scanning on that

124
00:06:48,670 --> 00:06:50,849
data and that can take a really long time.

125
00:06:51,059 --> 00:06:55,750
Instead, the way that rubric is architected is that we have a single

126
00:06:55,760 --> 00:07:00,370
data and metadata layer where we actually can scan the backups and

127
00:07:00,410 --> 00:07:04,100
in real time, provide insights into, here's where we found malware.

128
00:07:04,599 --> 00:07:07,060
And we can do that both, like every time we're taking snapshots

129
00:07:07,380 --> 00:07:10,710
as well as every, as going back through the historic data.

130
00:07:10,930 --> 00:07:15,450
So the ability to, the ability to scan in place really enables

131
00:07:15,460 --> 00:07:20,690
organizations to just do all of that upfront work without having

132
00:07:20,690 --> 00:07:23,719
to like set up holes, separate infrastructure and take valuable

133
00:07:23,719 --> 00:07:27,289
time in, in setting that up and then actually running the scans.

134
00:07:27,790 --> 00:07:30,750
I've always found that when you start setting these

135
00:07:30,760 --> 00:07:35,120
things out, people care about them very much right after.

136
00:07:35,120 --> 00:07:37,490
They really should have made it a point to care

137
00:07:37,490 --> 00:07:40,300
about it a smidgen more than they did already.

138
00:07:40,469 --> 00:07:43,169
Like no one is as, uh, zealous, uh, about backups.

139
00:07:43,170 --> 00:07:47,129
As someone who's lost data, how do you get people to care

140
00:07:47,129 --> 00:07:50,049
about this before it becomes a barn or a horse situation?

141
00:07:50,890 --> 00:07:53,810
I think people are already making that shift.

142
00:07:53,810 --> 00:07:57,090
Like what we have seen with, with our customers is that, you know,

143
00:07:57,099 --> 00:08:02,659
since like 2019, 2020, 2021, as ransomware became a bigger and

144
00:08:02,660 --> 00:08:07,019
bigger challenge and organizations were really facing it, boards were

145
00:08:07,060 --> 00:08:11,030
asking their management teams, Hey, what's your plan for ransomware?

146
00:08:11,070 --> 00:08:15,579
And as there was more publicized examples of massive attacks on

147
00:08:15,809 --> 00:08:20,849
healthcare companies, on Colonial Pipeline on casinos on, you know,

148
00:08:20,870 --> 00:08:25,260
all of these very, very publicized attacks now it is very top of mind.

149
00:08:25,390 --> 00:08:28,740
I think also what we're seeing is in highly regulated industries,

150
00:08:28,880 --> 00:08:33,130
there's a lot more regulation coming out saying that, Hey, you

151
00:08:33,130 --> 00:08:36,449
have to have a cyber resilience and cyber recovery strategy.

152
00:08:36,639 --> 00:08:40,709
It is unfortunately, the case that people often invest still too late.

153
00:08:40,779 --> 00:08:43,850
But I do think that, that that psyche is changing around it.

154
00:08:43,880 --> 00:08:47,430
And I, and I think the, where we're going in the future is saying, Hey, you

155
00:08:47,430 --> 00:08:51,830
actually should not just have this as an insurance policy, but you actually

156
00:08:51,830 --> 00:08:56,790
need to be doing cyber recovery simulations and cyber recovery testing on an

157
00:08:56,799 --> 00:09:01,980
ongoing and frequent basis because you don't wanna find out when you're in the

158
00:09:01,980 --> 00:09:05,590
middle of a cyber event that, hey, you actually didn't have the right technology

159
00:09:05,590 --> 00:09:10,270
or strategy or people or process in place to actually do those recoveries.

160
00:09:10,660 --> 00:09:13,920
When you keep talking, referring to it as cyber, I hear this is much more

161
00:09:13,920 --> 00:09:18,639
of a security angle than my historical experience with, and, and they are

162
00:09:18,639 --> 00:09:21,850
aligned on a, a common axis, whether it's because there's an attacker that

163
00:09:21,850 --> 00:09:25,450
wound up deleting data or I once again did one of my hilarious database

164
00:09:25,460 --> 00:09:28,470
stunts that I'm sure will laugh about someday when the bleeding stops.

165
00:09:28,889 --> 00:09:32,129
I found that you care about a lot of these same things.

166
00:09:32,340 --> 00:09:35,819
Are you looking at this more as a security story?

167
00:09:35,840 --> 00:09:38,790
Is it more of an operation story or is there,

168
00:09:38,800 --> 00:09:40,439
is this a distinction without difference?

169
00:09:40,680 --> 00:09:43,650
I think it's kind of a distinction without a difference in that anything

170
00:09:43,650 --> 00:09:48,029
that we're building for cyber is also going to serve well in an operational

171
00:09:48,030 --> 00:09:52,709
recovery where in a developer dropped a database table or where there

172
00:09:52,709 --> 00:09:57,280
was some kind of server outage in your data center or where you had some

173
00:09:57,280 --> 00:10:00,590
kind of deletion or encryption event, um, in your cloud environments.

174
00:10:00,590 --> 00:10:03,429
Like all, all of the technology is the same to

175
00:10:03,429 --> 00:10:06,350
support both, I think in the cyber scenario.

176
00:10:06,469 --> 00:10:09,710
You just have these additional questions around the blast radius,

177
00:10:09,770 --> 00:10:12,510
finding a clean point in recovery that are very different than what you

178
00:10:12,510 --> 00:10:16,319
would have in other cases where you might have to execute a recovery.

179
00:10:16,530 --> 00:10:19,740
So a, a question that I have to ask, it might be slightly

180
00:10:19,740 --> 00:10:22,360
impolite, but that's sort of my brand and I, I tend to.

181
00:10:22,559 --> 00:10:27,890
Go with it is that if I take a look at how folks care about

182
00:10:27,890 --> 00:10:30,280
things in business, there there are two real categories.

183
00:10:30,320 --> 00:10:34,360
There's the proactive idea that this could triple our market share.

184
00:10:34,370 --> 00:10:36,689
It could quintuple our revenue, summon the board.

185
00:10:36,970 --> 00:10:37,390
Great.

186
00:10:37,660 --> 00:10:40,269
And then you have the, the reactive side of things.

187
00:10:40,349 --> 00:10:44,390
Security being one example, backups being another AWS cost.

188
00:10:44,400 --> 00:10:47,620
High buying fire insurance for the building, all

189
00:10:47,629 --> 00:10:50,540
things that should definitely be done and cared about.

190
00:10:50,810 --> 00:10:54,780
But you can throw effectively infinite money at these things as

191
00:10:54,780 --> 00:10:58,580
a white elephant until you have no money left, and it doesn't get

192
00:10:58,580 --> 00:11:02,650
you any closer to the business milestone that you're targeting at.

193
00:11:03,160 --> 00:11:05,510
How do you Go to Market in a story like that?

194
00:11:05,709 --> 00:11:10,880
I think if you look at security specifically, the spend going towards

195
00:11:10,880 --> 00:11:15,979
security is skyrocketing, but most of that spend is going towards prevention

196
00:11:15,980 --> 00:11:19,900
technology, and the challenge with that is that people are investing more

197
00:11:19,900 --> 00:11:24,480
and more in cyber prevention, and yet there are more and more cyber attacks.

198
00:11:24,510 --> 00:11:28,080
There's a real challenge there if you're really focused around prevention.

199
00:11:28,610 --> 00:11:33,839
What we focus on is assume breach, assume that you have already been breached.

200
00:11:33,860 --> 00:11:36,680
Assume that, um, a attacker is either already

201
00:11:36,680 --> 00:11:38,530
in your system or is going to get there.

202
00:11:38,679 --> 00:11:40,539
What are you gonna do about that?

203
00:11:40,789 --> 00:11:43,530
And how do you actually recover and respond to that?

204
00:11:43,760 --> 00:11:48,010
And so it is a separate area where traditionally,

205
00:11:48,150 --> 00:11:51,560
there's been a pretty big underinvestment there, and

206
00:11:51,560 --> 00:11:56,060
so our, our message is, Hey, you have to assume breach.

207
00:11:56,099 --> 00:11:58,760
I mean, because of the prevalence of cyber attacks.

208
00:11:58,789 --> 00:12:02,340
And if you just keep investing in prevention, prevention, prevention,

209
00:12:02,540 --> 00:12:06,660
you're never going to actually make your business resilient, and then

210
00:12:06,660 --> 00:12:11,020
you're going to be susceptible to the inevitable moment where an attacker

211
00:12:11,210 --> 00:12:15,129
breaks through your four walls and is able to to breach your environment.

212
00:12:15,400 --> 00:12:18,612
Uh, you folks have, uh, been on the record as saying that,

213
00:12:18,612 --> 00:12:21,579
I forget the exact number, but some horrifying percentage

214
00:12:21,640 --> 00:12:24,720
of security incidents backups have been compromised.

215
00:12:24,720 --> 00:12:26,060
I believe it was a majority of the time.

216
00:12:26,370 --> 00:12:31,930
Yes, for certain providers, you can actually go out on the internet and

217
00:12:31,940 --> 00:12:36,700
see how ransomware groups are specifically compromising the backups.

218
00:12:36,970 --> 00:12:41,199
Rubrik has been architected day one from a security first mindset,

219
00:12:41,210 --> 00:12:45,110
so we have multitude of controls around the backups themselves

220
00:12:45,110 --> 00:12:48,430
that prevent the backups from getting compromised during an attack.

221
00:12:48,790 --> 00:12:52,180
Now cynical question that I have to ask, is that entirely

222
00:12:52,180 --> 00:12:54,560
because the backups were explicitly targeted or is part of

223
00:12:54,560 --> 00:12:56,910
this because they've been compromised for two years back?

224
00:12:56,950 --> 00:13:00,550
Things have naturally gone, uh, organically into the backups

225
00:13:00,550 --> 00:13:03,360
before someone finally noticed that they had a problem.

226
00:13:03,599 --> 00:13:06,390
It's one of those c no evil approaches to security approach.

227
00:13:06,520 --> 00:13:08,920
As best we can tell we've never been breached

228
00:13:08,920 --> 00:13:10,760
is sort of a statement of proud ignorance.

229
00:13:10,869 --> 00:13:11,769
It's a great question.

230
00:13:12,270 --> 00:13:17,550
What I will say is that when malware lands in a primary

231
00:13:17,550 --> 00:13:20,219
environment, it can get copied into the backups, right?

232
00:13:20,220 --> 00:13:23,510
So that's a potential point of, of compromise.

233
00:13:23,759 --> 00:13:25,910
But what I will say is like usually that malware

234
00:13:25,920 --> 00:13:27,529
is not gonna be activated on the backups.

235
00:13:27,530 --> 00:13:29,439
It will just be in the primary environment.

236
00:13:29,459 --> 00:13:33,080
And we have capabilities that help you find malware specifically in the backups.

237
00:13:33,250 --> 00:13:35,550
What, when it lands, or shortly thereafter,

238
00:13:35,550 --> 00:13:37,960
if it's a new, new malware that was detected.

239
00:13:38,070 --> 00:13:39,900
Attackers have gotten very smart.

240
00:13:40,120 --> 00:13:42,949
They realize that they have to go after the backups in

241
00:13:42,950 --> 00:13:46,689
addition to the primary environment because if a organization

242
00:13:46,740 --> 00:13:48,870
can recover, then they're not gonna pay the ransom.

243
00:13:48,890 --> 00:13:51,270
And the reality is, is that the vast majority of

244
00:13:51,270 --> 00:13:54,480
ransomware events are attackers just trying to make money.

245
00:13:54,550 --> 00:13:57,690
It's not these like massive nation state actors.

246
00:13:57,690 --> 00:14:02,180
Those are obviously there too, but it's a lot of cyber attackers for hire.

247
00:14:02,400 --> 00:14:04,189
Or people that are just trying to extract money

248
00:14:04,190 --> 00:14:06,390
out of organizations as quickly as possible.

249
00:14:06,730 --> 00:14:10,100
In order to do that, they have to try to compromise the backups as well.

250
00:14:10,270 --> 00:14:13,535
And for legacy solutions where they were not built with the

251
00:14:13,560 --> 00:14:17,150
security first mindset, where they're taking backups over open

252
00:14:17,150 --> 00:14:21,430
protocols where the data is not immutable on the first copy.

253
00:14:21,430 --> 00:14:25,730
Like all of these things that are just not very secure, that leaves the

254
00:14:25,730 --> 00:14:28,440
backups themselves susceptible and the attackers will go after them.

255
00:14:28,800 --> 00:14:31,020
Roughly five years ago I put out a blog post

256
00:14:31,030 --> 00:14:34,599
titled, uh, Multi-Cloud is a Worst Practice.

257
00:14:34,690 --> 00:14:39,399
And despite my opinion on that, which has evolved somewhat but not entirely,

258
00:14:39,620 --> 00:14:43,160
the world has clearly gone multi-cloud either by strategy or by accident.

259
00:14:43,190 --> 00:14:45,209
Uh, sometimes it's for great reasons.

260
00:14:45,220 --> 00:14:49,490
Sometimes it's for terrible ones, but it leads to massive.

261
00:14:49,650 --> 00:14:52,550
Expense in terms of infrastructure sprawl, in terms

262
00:14:52,550 --> 00:14:55,810
of just the cost of complexity that ties into this.

263
00:14:56,049 --> 00:14:57,040
What are you seeing?

264
00:14:57,070 --> 00:15:00,240
Because that has to have security and resilience impact.

265
00:15:00,369 --> 00:15:04,780
Absolutely, and I think that not only are our organization's

266
00:15:04,810 --> 00:15:07,459
multi-cloud, and often it is by accident, right?

267
00:15:07,460 --> 00:15:13,370
It's a organization acquired another company that happened to have used a

268
00:15:13,370 --> 00:15:17,410
different cloud provider than their main cloud provider, or two different

269
00:15:17,410 --> 00:15:21,160
departments within the same company decided to use different cloud providers

270
00:15:21,160 --> 00:15:24,570
for different reasons, and that didn't get caught and reconciled together.

271
00:15:24,830 --> 00:15:27,800
There's a lot of reasons why people end up in this multi-cloud state.

272
00:15:28,010 --> 00:15:30,050
They're not only in a multi-cloud state, but they're in a

273
00:15:30,050 --> 00:15:33,729
hybrid cloud state, so they still have important data that's

274
00:15:33,730 --> 00:15:36,850
sitting on premise, um, as well as data that's in the cloud.

275
00:15:37,100 --> 00:15:40,699
Now, the challenge with all of this is that if you're managing a cyber

276
00:15:40,700 --> 00:15:45,580
resilience strategy with five different tools, one for your cloud environment,

277
00:15:45,580 --> 00:15:50,279
one for your SaaS apps, one for AWS, one for Azure, one for GCP, one for

278
00:15:50,279 --> 00:15:55,459
OCI, if you're using different tools for all of this, then first of all, the

279
00:15:55,470 --> 00:16:00,220
operational complexity is really high and second, um, actually making sure

280
00:16:00,220 --> 00:16:03,780
that you have a strong cyber resilience strategy across all of these when

281
00:16:03,880 --> 00:16:07,789
they may not be uniform and have uniform capabilities is very challenging.

282
00:16:07,990 --> 00:16:12,120
So what we see is that often organizations with this kind of complexity,

283
00:16:12,120 --> 00:16:17,500
one way they can manage the risk is by having a unified platform that

284
00:16:17,500 --> 00:16:20,600
helps them with cyber resilience across all these apps so that they have

285
00:16:20,600 --> 00:16:25,140
a single construct and way of managing cyber resilience and managing

286
00:16:25,340 --> 00:16:29,159
whether they are actually in compliance with their own policies.

287
00:16:29,320 --> 00:16:31,312
Being able to manage that in a central way.

288
00:16:31,312 --> 00:16:31,597
It, it,

289
00:16:31,740 --> 00:16:34,890
it's always strange to me seeing environments from a costing perspective

290
00:16:34,940 --> 00:16:38,539
where, oh, yes, we're spending a large amount on backup because it's worth it.

291
00:16:38,559 --> 00:16:41,350
You dive into it a little bit and you ask leading questions, and it turns

292
00:16:41,350 --> 00:16:44,990
out that they're backing up a fleet of web servers that have thousands of

293
00:16:44,990 --> 00:16:47,999
them and they're spending at great expense imaging each one of these things.

294
00:16:48,129 --> 00:16:51,420
When the entire web server fleet is created about 200 lines of

295
00:16:51,420 --> 00:16:55,300
cloud formation, it's, hmm, maybe there's a better way to do this.

296
00:16:56,750 --> 00:16:59,480
This gets worse in the multi-cloud story.

297
00:16:59,520 --> 00:17:02,700
I mean, for a while back I found that one of the more cost effective things

298
00:17:02,700 --> 00:17:07,429
companies could do is turn off all of AWS's first party security services and

299
00:17:07,430 --> 00:17:11,660
just suffer the breach because it costs less money when all is said and done.

300
00:17:11,960 --> 00:17:15,329
Uh, with multi-cloud that is no longer tenable, people are

301
00:17:15,359 --> 00:17:19,209
forced to go in a direction of third party providers that.

302
00:17:19,349 --> 00:17:20,940
Frankly have a better user experience.

303
00:17:20,940 --> 00:17:23,399
So thanks for that, but also starts letting

304
00:17:23,400 --> 00:17:25,939
them reason around this in a sensible way.

305
00:17:26,170 --> 00:17:28,930
So I guess my question for you is, is multi-cloud

306
00:17:29,000 --> 00:17:31,530
actively serving to make security worse?

307
00:17:31,570 --> 00:17:35,030
Like are we just giving people bigger attack surfaces while patting

308
00:17:35,030 --> 00:17:37,850
ourselves in the back for avoiding lock-in, even though we didn't.

309
00:17:38,540 --> 00:17:40,199
Quick word from Rubrik, who wants to have

310
00:17:40,199 --> 00:17:42,409
an awkward conversation about your backups.

311
00:17:42,430 --> 00:17:44,120
You know those snapshots you’re taking?

312
00:17:44,210 --> 00:17:46,790
The ones in the same cloud account as your production data?

313
00:17:46,850 --> 00:17:48,050
Those aren’t backups.

314
00:17:48,050 --> 00:17:50,230
That’s just... more data in the same place.

315
00:17:50,639 --> 00:17:55,609
When ransomware shows up—and it will—it’s going to encrypt your production

316
00:17:55,610 --> 00:17:59,649
data AND your ‘backups’ because they’re protected by the same credentials.

317
00:17:59,869 --> 00:18:03,090
Rubrik actually air-gaps your backups and makes them immutable, which

318
00:18:03,090 --> 00:18:06,689
means attackers can’t delete them even if they compromise your accounts.

319
00:18:06,830 --> 00:18:10,540
It works across all major clouds and actually

320
00:18:10,540 --> 00:18:12,980
helps you recover when Murphy’s Law gets creative.

321
00:18:13,170 --> 00:18:15,370
Check out rubrik.com/SITC.

322
00:18:17,219 --> 00:18:21,110
anytime you're talking about the surface area expansion of data

323
00:18:21,110 --> 00:18:25,620
and applications, that is increasing the risk to your organization.

324
00:18:25,620 --> 00:18:28,650
It's increasing the number of entry points that an attacker has.

325
00:18:28,670 --> 00:18:30,780
It has, it's increasing the amount of surface

326
00:18:30,780 --> 00:18:33,010
area that your security teams have to monitor.

327
00:18:33,250 --> 00:18:36,410
So there is inevitably a risk associated with it.

328
00:18:37,390 --> 00:18:40,180
I think most of the organizations that I talk to

329
00:18:40,180 --> 00:18:43,879
that have multi-cloud environments, it is not because

330
00:18:43,920 --> 00:18:47,909
they explicitly chose it for a vendor lock-in reason.

331
00:18:48,099 --> 00:18:51,220
It's usually because they evolved into that, through

332
00:18:51,240 --> 00:18:55,010
acquisition, through not having a centralized IT team

333
00:18:55,010 --> 00:18:58,350
or infrastructure strategy and ending up in that state.

334
00:18:58,360 --> 00:19:01,440
There are some that are trying to play the clouds against each

335
00:19:01,440 --> 00:19:04,710
other and get a better deal, but I think it's becoming more and

336
00:19:04,710 --> 00:19:08,229
more common knowledge that, first of all, you're increasing your

337
00:19:08,230 --> 00:19:12,110
operational complexity and you're increasing your security risk area.

338
00:19:12,290 --> 00:19:15,670
So I think that's it’s a challenging position to take.

339
00:19:16,960 --> 00:19:20,659
Also usually the more that you commit to a given cloud,

340
00:19:20,840 --> 00:19:24,579
the more you can get discounts based on that commit.

341
00:19:24,759 --> 00:19:26,709
So if you're spreading that commit across multiple

342
00:19:26,719 --> 00:19:29,040
clouds, then you're just not gonna get the best deal.

343
00:19:29,309 --> 00:19:31,070
So I think that's a, that's a big piece.

344
00:19:31,630 --> 00:19:36,179
Cost is super important for our customers and we, you know, when we deploy our

345
00:19:36,180 --> 00:19:42,020
technology in the cloud, we are cost optimizing the storage of backups massively

346
00:19:42,040 --> 00:19:46,030
compared to the native solutions that the cloud providers provide, because that

347
00:19:46,039 --> 00:19:50,030
is one of the benefits in addition to cyber resilience that we need to provide.

348
00:19:50,040 --> 00:19:51,740
Otherwise, it becomes, as you said, cost

349
00:19:51,740 --> 00:19:53,810
prohibitive to actually provide these services.

350
00:19:54,300 --> 00:19:56,500
I should point out that as we're recording this, we are in

351
00:19:56,510 --> 00:20:00,669
the, the day after AWS's big, uh, meltdown for availability.

352
00:20:00,670 --> 00:20:01,750
That lasted half a day.

353
00:20:01,750 --> 00:20:03,640
And I really hope that by the time this publishes,

354
00:20:03,640 --> 00:20:06,030
people don't come back and have to ask which one.

355
00:20:06,039 --> 00:20:08,150
So we're, we're gonna be optimistic on that.

356
00:20:08,420 --> 00:20:10,440
But there's a lot of knee-jerk reactions of, oh,

357
00:20:10,450 --> 00:20:12,909
we're gonna start going multi-cloud for everything.

358
00:20:13,150 --> 00:20:16,820
We're going to start spreading things out so that we aren't subject to this.

359
00:20:17,410 --> 00:20:19,919
So many of these stories are not, this is

360
00:20:19,920 --> 00:20:21,709
how we eliminate a single point of failure.

361
00:20:21,790 --> 00:20:25,300
It's here's how we add a second single point of failure at tremendous

362
00:20:25,300 --> 00:20:28,700
expense, and then act surprised later if we actually do this.

363
00:20:28,860 --> 00:20:31,179
But these conversations happen every time that

364
00:20:31,180 --> 00:20:33,830
there's a significant, uh, notable cloud outage.

365
00:20:34,120 --> 00:20:38,300
But people generally don't do that once the panic has subsided

366
00:20:38,320 --> 00:20:41,309
and people, people are having the strategy they have for a reason.

367
00:20:41,559 --> 00:20:44,670
And those reasons are no less valid today than they were a week ago.

368
00:20:45,570 --> 00:20:49,610
I agree with that, and I think that there are multiple, there's multiple

369
00:20:49,610 --> 00:20:53,459
types of risk factors that companies are inevitably thinking about.

370
00:20:53,469 --> 00:20:57,300
They're thinking about, okay, like what happens if, if my tenant

371
00:20:57,300 --> 00:21:01,200
gets compromised or my account gets compromised by a cyber attacker?

372
00:21:01,430 --> 00:21:02,889
They're thinking about what happens if the

373
00:21:02,890 --> 00:21:06,420
cloud goes down in this region or zone?

374
00:21:06,600 --> 00:21:08,780
They're thinking about, what if the cloud totally goes down?

375
00:21:08,780 --> 00:21:10,659
I have to fail over to a secondary cloud.

376
00:21:10,660 --> 00:21:14,409
Like there are a, a range of different scenarios that.

377
00:21:14,450 --> 00:21:17,819
Um, companies are worried about, and we see this and we talk to 'em all

378
00:21:17,820 --> 00:21:22,870
the time, and I think there's a, you, as with any risk, you have to ask

379
00:21:22,870 --> 00:21:27,510
yourself like, what's the expected outcome of this risk actually manifesting?

380
00:21:27,510 --> 00:21:32,200
How costly is this to your organization and is this risk worth managing.

381
00:21:32,400 --> 00:21:35,459
One of the things that we found to be quite successful for

382
00:21:35,459 --> 00:21:40,720
organizations is using our technology to be able to keep a copy

383
00:21:40,720 --> 00:21:44,240
of their applications and be able to do a recovery cross region.

384
00:21:44,460 --> 00:21:48,649
So thereby you aren't reliant on a single region in the cloud.

385
00:21:49,830 --> 00:21:54,250
A multi-region outage is much less likely than a single

386
00:21:54,250 --> 00:21:57,750
region outage, and so there are coping mechanisms.

387
00:21:57,910 --> 00:22:02,110
I think truly doing cross cloud recovery, backup and recovery is

388
00:22:02,110 --> 00:22:05,579
quite challenging from a cost perspective, operational perspective,

389
00:22:05,590 --> 00:22:09,669
there's so many aspects of that that make it not super realistic today.

390
00:22:09,679 --> 00:22:10,620
I do

391
00:22:10,620 --> 00:22:12,960
see companies doing a rehydrate, the business

392
00:22:12,960 --> 00:22:15,030
level of backups to another provider.

393
00:22:15,070 --> 00:22:18,530
Uh, not necessarily because there's a tremendous risk of

394
00:22:18,740 --> 00:22:22,040
AWS suffering, its first ever, uh, global network outage.

395
00:22:22,040 --> 00:22:23,750
They've never had an issue that hit.

396
00:22:23,790 --> 00:22:27,180
Every region they've had control plane issues, but there

397
00:22:27,190 --> 00:22:29,520
it's easier for some of these companies to do this than

398
00:22:29,520 --> 00:22:33,260
explain to their auditor every period why they didn't do it.

399
00:22:33,290 --> 00:22:37,310
It checks a box there that feels like it is much less tied to

400
00:22:37,590 --> 00:22:41,130
the specifics of a risk and more of a decision that they make.

401
00:22:41,190 --> 00:22:42,859
There are a lot of check, check the box

402
00:22:42,860 --> 00:22:45,869
capabilities that people wanna be able to, to offer.

403
00:22:45,870 --> 00:22:48,599
And, uh, we think about those and, and offer solutions,

404
00:22:48,710 --> 00:22:50,980
different kinds of solutions for those check the box features.

405
00:22:51,190 --> 00:22:52,720
And then there's stuff where that needs to be operationalized

406
00:22:54,030 --> 00:22:57,110
really well because it is something that you will likely rely

407
00:22:57,110 --> 00:23:01,240
upon in a real event, like cross region application recovery and

408
00:23:01,250 --> 00:23:05,000
being able to orchestrate, um, a full application recovery across.

409
00:23:05,119 --> 00:23:08,399
The different resources and data that make up your application

410
00:23:08,440 --> 00:23:11,080
as opposed to doing it on a service by service basis.

411
00:23:11,310 --> 00:23:13,149
So there's a lot of things that are like real

412
00:23:13,160 --> 00:23:15,273
challenges that you want more than a checkbox for.

413
00:23:15,273 --> 00:23:18,034
And then there's some stuff that's understandably, you need a

414
00:23:18,034 --> 00:23:20,319
checkbox for the auditors, and that's kind of the way it goes.

415
00:23:20,450 --> 00:23:23,009
It's always difficult to test these things because you can

416
00:23:23,010 --> 00:23:26,180
simulate a full region outage of your cloud provider of choice

417
00:23:26,230 --> 00:23:29,560
whenever you want, but there are other companies involved in the

418
00:23:29,560 --> 00:23:33,610
critical path of getting you in front of customers and you can't.

419
00:23:33,730 --> 00:23:36,600
Test their ability to survive that with their

420
00:23:36,600 --> 00:23:38,960
critical path vendors and so on and so forth.

421
00:23:39,170 --> 00:23:41,439
And somebody, it winds up being a giant thorny knot

422
00:23:41,449 --> 00:23:43,550
because everyone cross depends on everyone else.

423
00:23:43,760 --> 00:23:46,200
So we see these challenges of how do people come back up

424
00:23:46,210 --> 00:23:49,480
when everyone is codependent on one another already working?

425
00:23:49,720 --> 00:23:51,840
And that's where some of the fun firefighting

426
00:23:51,840 --> 00:23:53,939
engineering tends to come into play.

427
00:23:54,300 --> 00:23:55,400
How do you think about that?

428
00:23:55,530 --> 00:23:59,370
There's always going to be externalities and things that you haven't

429
00:23:59,379 --> 00:24:02,840
tested and that you're going to have to deal with in real time.

430
00:24:02,920 --> 00:24:05,000
That is just the nature of doing business.

431
00:24:05,030 --> 00:24:08,680
You cannot map out every single dependency between

432
00:24:08,690 --> 00:24:11,870
all of your technologies for all of your applications.

433
00:24:11,889 --> 00:24:13,240
So I think one is.

434
00:24:13,460 --> 00:24:17,189
Figuring out what are your, what is your minimum viable business like?

435
00:24:17,190 --> 00:24:20,580
What are the applications that are absolutely critical

436
00:24:20,760 --> 00:24:23,170
to servicing your business that you cannot live without?

437
00:24:23,180 --> 00:24:25,340
So then you shrink kind of your surface area.

438
00:24:25,340 --> 00:24:29,369
Really thinking about those, those applications, and then test what you

439
00:24:29,370 --> 00:24:34,089
can test, like go and, and test the pieces that you're able to test.

440
00:24:34,109 --> 00:24:38,370
And that way you get the reps in on the things that you can control and

441
00:24:38,370 --> 00:24:41,350
the things that you can see and the dependencies that you do know about.

442
00:24:41,560 --> 00:24:44,760
And that way when you know, let's say there's, you're able to test and,

443
00:24:44,800 --> 00:24:49,879
and manage 80% of those things, then when you're hit with a real cyber

444
00:24:49,889 --> 00:24:53,799
event you can spend all your brain power on the 20% that is unexpected

445
00:24:53,809 --> 00:24:57,510
because in an event there's always gonna be unexpected issues that emerge.

446
00:24:57,530 --> 00:24:59,929
Some of them may be technology, some of them may be people

447
00:24:59,930 --> 00:25:02,440
and process like, oh, you don't have the phone number for

448
00:25:02,440 --> 00:25:04,800
this vendor that you thought you had the phone number for.

449
00:25:04,800 --> 00:25:04,980
Right.

450
00:25:05,160 --> 00:25:06,279
It's, it's simple or you

451
00:25:06,370 --> 00:25:08,460
do, but it turns out they have one or two other

452
00:25:08,460 --> 00:25:10,959
customers that might be in the phone tree ahead of you.

453
00:25:11,049 --> 00:25:12,000
Yeah, exactly.

454
00:25:12,010 --> 00:25:15,909
So there are many things that you can control, but I think if you have.

455
00:25:16,140 --> 00:25:19,850
The ability to actually test recoveries for, for things that are incredible,

456
00:25:19,880 --> 00:25:22,250
like for the applications that are really incredibly valuable to you,

457
00:25:22,250 --> 00:25:27,459
and you're able to cover 50 to 80% of, of that whole process, that just

458
00:25:27,460 --> 00:25:31,149
sets you up even better for when you actually have to face a cyber event.

459
00:25:31,240 --> 00:25:31,360
What

460
00:25:31,870 --> 00:25:35,430
do you think people are mostly getting wrong right When you take a look

461
00:25:35,460 --> 00:25:40,710
at the, at the broad sweep of how they're thinking about cyber resilience.

462
00:25:41,070 --> 00:25:46,050
I think specifically in the cloud, there are a couple of patterns that I see.

463
00:25:46,109 --> 00:25:50,770
One pattern is people thinking that because the cloud is redundant,

464
00:25:51,010 --> 00:25:54,200
that means that they are actually protected in a cyber event.

465
00:25:54,590 --> 00:25:57,879
But the reality is, is that if the data is corrupted.

466
00:25:58,240 --> 00:26:01,940
Redundancy only means that that is gonna get replicated throughout.

467
00:26:02,309 --> 00:26:03,940
Replication is not a backup.

468
00:26:03,940 --> 00:26:05,169
You learn this at your peril.

469
00:26:05,209 --> 00:26:05,429
Yeah.

470
00:26:05,440 --> 00:26:05,890
Correct.

471
00:26:05,890 --> 00:26:06,249
Yeah.

472
00:26:06,299 --> 00:26:09,460
Um, so I think that's one, one thing that's not super well

473
00:26:09,460 --> 00:26:13,790
understood all the time is that that's not a cyber recovery strategy.

474
00:26:13,890 --> 00:26:17,670
That's a, a failover if your infrastructure is down, but your data is fine.

475
00:26:18,099 --> 00:26:21,639
The second thing that I would, uh, also mention is that

476
00:26:21,759 --> 00:26:25,850
every cloud company has their own native backup solution that

477
00:26:25,850 --> 00:26:29,320
essentially is taking cloud snapshots of the environment.

478
00:26:29,510 --> 00:26:31,939
There are a lot of challenges with these solutions

479
00:26:31,970 --> 00:26:33,830
that is putting it very charitably.

480
00:26:34,679 --> 00:26:34,840
Yes.

481
00:26:34,860 --> 00:26:36,750
And I think a lot of people are like, well, I

482
00:26:36,750 --> 00:26:39,899
have a solution because I have native backup.

483
00:26:39,910 --> 00:26:44,330
And the reality is that there are a lot of gaps in native backup,

484
00:26:44,370 --> 00:26:48,780
even from an immutability, recoverability, granular recovery.

485
00:26:48,990 --> 00:26:52,620
And then when you talk about all of the cyber capabilities of being

486
00:26:52,639 --> 00:26:56,280
able to detect malware, find a clean point of recovery, detect

487
00:26:56,280 --> 00:26:59,500
the blast radius, all of that, then the tools are really lacking.

488
00:26:59,750 --> 00:27:03,360
And so that is the cyber resilience plus the

489
00:27:03,360 --> 00:27:05,960
actual like granular capabilities, immutability.

490
00:27:06,970 --> 00:27:09,419
And on top of that, the cost that some of the native

491
00:27:09,429 --> 00:27:13,100
backup solutions add to your storage bill is quite high.

492
00:27:13,320 --> 00:27:17,000
So with our solution, we optimize all of those

493
00:27:17,230 --> 00:27:20,550
pieces, and we're not just limited to a single cloud.

494
00:27:20,550 --> 00:27:23,960
So in your inevitable sprawl of multi-cloud because of the way your

495
00:27:24,010 --> 00:27:27,190
business has evolved, now you have one solution that can cover all of that.

496
00:27:27,420 --> 00:27:29,170
It's worth pointing out as well.

497
00:27:30,110 --> 00:27:33,330
It, it's easy to to to become overly negative when

498
00:27:33,339 --> 00:27:35,449
looking at a lot of the first party offerings.

499
00:27:35,449 --> 00:27:37,919
I mean, I've stared too long into that abyss and it is gazed

500
00:27:37,950 --> 00:27:40,240
deeply and thoroughly into me, which probably explains a lot

501
00:27:40,620 --> 00:27:44,389
the but this, these are hard problems and it's very tricky to

502
00:27:44,389 --> 00:27:48,039
start building things that are holistic solutions for folks.

503
00:27:48,080 --> 00:27:52,039
We've been talking about cloud, but there's an awful lot of hybrid out there.

504
00:27:52,039 --> 00:27:54,400
It turns out that building data centers wasn't

505
00:27:54,410 --> 00:27:57,390
knowledge lost to the ancients, and now only.

506
00:27:57,440 --> 00:27:59,170
Three specific companies can do it.

507
00:27:59,420 --> 00:28:02,200
Lots of companies have on-prem facilities and

508
00:28:02,200 --> 00:28:04,389
are in a variety of different hybrid approaches.

509
00:28:04,639 --> 00:28:05,840
What's your story for those folks?

510
00:28:06,290 --> 00:28:08,260
That's like our ideal customer.

511
00:28:08,270 --> 00:28:09,020
Honestly.

512
00:28:09,130 --> 00:28:12,659
We have so many organizations that we support that have a piece

513
00:28:12,660 --> 00:28:15,720
of their, their applications on-prem, some of their applications

514
00:28:15,720 --> 00:28:19,610
in the cloud, some applications that span on-prem and cloud

515
00:28:19,610 --> 00:28:20,929
and have different components, and being able to have us.

516
00:28:20,929 --> 00:28:21,789
Single solution and platform to be able to,

517
00:28:25,320 --> 00:28:29,330
to provide cyber resilience across all of these applications

518
00:28:29,330 --> 00:28:32,890
and have the same paradigms, have different ways of actually

519
00:28:32,910 --> 00:28:35,790
taking the, the backups and doing the recovery themselves based

520
00:28:35,790 --> 00:28:38,460
on the tools that are available in each of these environments.

521
00:28:38,740 --> 00:28:40,720
It's really important and that's why.

522
00:28:40,960 --> 00:28:45,930
Um, a lot of our, our customers come to us because they, they want that solution

523
00:28:45,930 --> 00:28:49,460
that's gonna span across, and they also want the flexibility of saying, Hey,

524
00:28:49,480 --> 00:28:53,070
maybe in three years I'm gonna move even more of my application to the cloud.

525
00:28:53,080 --> 00:28:54,950
Will you be there with me on my journey,

526
00:28:54,950 --> 00:28:56,489
or am I gonna have to start from scratch?

527
00:28:56,530 --> 00:28:57,930
They don't wanna have to start from scratch.

528
00:28:58,469 --> 00:29:01,300
I'll also point out that you have a variety of approaches

529
00:29:01,309 --> 00:29:03,449
that make sense for a modern cloud infrastructure.

530
00:29:03,450 --> 00:29:06,440
I've, I've worked with so many, quote unquote legacy vendors, which,

531
00:29:06,440 --> 00:29:09,580
you know, a condescending engineering term for it makes money where you

532
00:29:09,600 --> 00:29:12,590
go in and they're, oh, so what are your instances for your database?

533
00:29:12,590 --> 00:29:13,720
Like it, it's DynamoDB.

534
00:29:13,890 --> 00:29:14,859
What do you mean, instance?

535
00:29:14,870 --> 00:29:15,220
Like what?

536
00:29:15,220 --> 00:29:15,919
What's that?

537
00:29:15,929 --> 00:29:19,260
Can you just pull a disc image from it and then we close the page

538
00:29:19,260 --> 00:29:22,399
and look at something more reasonable for us as a closing thought?

539
00:29:22,430 --> 00:29:24,979
And I understand that this might be controversial for.

540
00:29:25,080 --> 00:29:27,050
Well, most companies, but I'm gonna roll with it anyway.

541
00:29:27,430 --> 00:29:29,080
When it comes to cyber resilience, it's one of

542
00:29:29,080 --> 00:29:32,080
those things that absolutely positively has to work.

543
00:29:32,389 --> 00:29:34,629
When people are dealing with Rubrik, they're

544
00:29:34,630 --> 00:29:37,709
already having a pretty bad day on some level.

545
00:29:38,480 --> 00:29:40,339
Why is this a great spot for ai?

546
00:29:43,500 --> 00:29:43,620
: try

547
00:29:43,840 --> 00:29:45,669
to keep it as not insulting as I possibly could

548
00:29:45,669 --> 00:29:47,572
and I feel I may not have succeeded for it.

549
00:29:47,572 --> 00:29:50,149
I dunno, I don't think that that's an insulting question.

550
00:29:51,059 --> 00:29:52,820
AI is a double-edged sword, right?

551
00:29:52,840 --> 00:29:58,120
There are wondrous capabilities that AI is going to to give us.

552
00:29:58,670 --> 00:30:01,080
Things that we're investing in from our,

553
00:30:01,130 --> 00:30:03,260
like improving our solutions, leveraging ai.

554
00:30:03,990 --> 00:30:06,310
And then AI is also a risk, right?

555
00:30:06,310 --> 00:30:07,800
That has to be managed.

556
00:30:07,850 --> 00:30:10,909
And so when we think about AI, you know, I was telling you,

557
00:30:10,950 --> 00:30:13,500
uh, earlier, you earlier about the journey of people having

558
00:30:13,500 --> 00:30:17,569
to recover from natural disasters and then cyber events,

559
00:30:17,600 --> 00:30:21,090
they're gonna have to recover from AI making mistakes as well.

560
00:30:21,100 --> 00:30:26,430
So this is just gonna be another vector of risk that you, or that's

561
00:30:26,430 --> 00:30:31,070
gonna necessitate having really great capabilities around recovery

562
00:30:31,160 --> 00:30:34,600
now, I think like AI is obviously still in its infancy and there's

563
00:30:34,600 --> 00:30:39,340
a lot of, uh, challenges that organizations are facing as they think

564
00:30:39,350 --> 00:30:42,780
about the adoption of AI and how they can truly get value from it.

565
00:30:42,780 --> 00:30:46,610
Because I think, you know, if you talk to, survey organizations, most

566
00:30:46,610 --> 00:30:50,279
organizations say AI's a top priority, but most projects are stuck in prototype.

567
00:30:50,290 --> 00:30:51,519
They're not getting to production.

568
00:30:51,799 --> 00:30:54,659
It is certainly not the top of the spend curve in the common case.

569
00:30:55,219 --> 00:30:55,719
Correct.

570
00:30:55,730 --> 00:30:58,980
And I think, but, but there's a big challenge around how do

571
00:30:58,980 --> 00:31:03,509
you provide, um, monitoring for AI agents, governance for

572
00:31:03,740 --> 00:31:07,590
AI agents, and remediation when AI agents make mistakes.

573
00:31:07,590 --> 00:31:09,639
So that's something that we're thinking about in the

574
00:31:09,639 --> 00:31:13,995
contex of our, our platform and where we can offer it.

575
00:31:14,010 --> 00:31:19,350
And we're also looking at, in this complex sprawl of data and

576
00:31:19,370 --> 00:31:22,440
infrastructure and applications, what are the ways that we can use

577
00:31:22,450 --> 00:31:28,860
AI to help organizations monitor their infrastructure better and

578
00:31:28,869 --> 00:31:34,030
make recommendations of what are their most critical applications?

579
00:31:34,180 --> 00:31:36,560
How can they be protecting these applications better?

580
00:31:36,560 --> 00:31:39,630
I think there's a lot of use cases like that that we can, troubleshooting

581
00:31:40,040 --> 00:31:43,490
failures in backup and recovery, like all these use cases are

582
00:31:43,490 --> 00:31:46,929
things that we're also looking at, well, can we use AI to make, to

583
00:31:46,930 --> 00:31:50,590
make it better, to make it simpler, to make it easier to operate

584
00:31:50,710 --> 00:31:55,480
our technology and provide cyber resilience to large enterprises.

585
00:31:55,570 --> 00:31:58,909
Yeah, and I think that that is a reasonable take on this.

586
00:31:58,969 --> 00:32:01,599
There's a, there's a lot of challenge that I have.

587
00:32:01,900 --> 00:32:04,210
With folks that are tripping all over themselves to take

588
00:32:04,219 --> 00:32:06,249
what they already are doing and already going to market with.

589
00:32:06,279 --> 00:32:08,710
And then, nope, it's AI and has been forever.

590
00:32:08,960 --> 00:32:11,830
But it does change some things, not everything.

591
00:32:11,830 --> 00:32:14,779
I don't think that it's, it's clearly not valueless, but I

592
00:32:14,780 --> 00:32:17,009
also don't think we're gonna properly summon God through JSON.

593
00:32:17,240 --> 00:32:20,410
I think the truth probably is somewhere between those two, and

594
00:32:20,420 --> 00:32:23,160
we're still figuring out as a society what that looks like.

595
00:32:23,160 --> 00:32:27,980
Technology advances and taking an approach of optimism,

596
00:32:27,980 --> 00:32:30,010
but with a sense of caution to, it seems reasonable.

597
00:32:31,000 --> 00:32:31,516
Yeah, I think so.

598
00:32:31,670 --> 00:32:34,530
I mean, I think with any technology, there's great advantages

599
00:32:34,530 --> 00:32:36,680
that come with it, but you have to figure out how to leverage it.

600
00:32:36,719 --> 00:32:39,359
And at the end of the day, it has to be solving a real problem.

601
00:32:39,420 --> 00:32:42,980
And that's, I, I think we're still in the time with AI where we're

602
00:32:42,980 --> 00:32:46,590
trying to figure out how to make it, like, how to take this technology

603
00:32:46,600 --> 00:32:51,180
and leverage it to solve really interesting problems, and it hasn't been

604
00:32:51,210 --> 00:32:56,040
totally figured out yet, especially for, for the large enterprise context.

605
00:32:56,420 --> 00:32:57,450
I, I think you're right.

606
00:32:57,589 --> 00:32:59,229
We're gonna see where this plays out.

607
00:32:59,230 --> 00:33:02,620
I, I'm very curious to see how it goes, but fortunately if it winds up,

608
00:33:02,620 --> 00:33:06,430
uh, not doing what we had hoped and ends up being an entire boondoggling

609
00:33:06,460 --> 00:33:09,530
disaster, well at least we'll have some resiliency around our data.

610
00:33:09,730 --> 00:33:10,920
I sure hope so.

611
00:33:11,300 --> 00:33:13,240
Thank you so much for taking the time to speak with me.

612
00:33:13,240 --> 00:33:13,949
I appreciate it.

613
00:33:14,030 --> 00:33:15,320
Yeah, thanks for having me.

614
00:33:15,580 --> 00:33:17,169
If people wanna, if you wanna learn more,

615
00:33:17,170 --> 00:33:18,639
where's the best place for 'em to find you?

616
00:33:18,750 --> 00:33:20,920
If you wanna find me, I'm on LinkedIn.

617
00:33:20,950 --> 00:33:22,189
Um, you can look up my name.

618
00:33:22,360 --> 00:33:24,040
I work at Rubrik Chief Product Officer.

619
00:33:24,180 --> 00:33:26,720
If you wanna look up Rubrik, um, go to rubrik.com and

620
00:33:26,780 --> 00:33:29,480
you can also find us on all social media platforms.

621
00:33:29,650 --> 00:33:31,449
Yes, and I believe the New York Stock Exchange or

622
00:33:31,450 --> 00:33:32,999
you, nasdaq, I can never remember who's on which.

623
00:33:33,059 --> 00:33:35,199
Uh, NYSE:RBRK.

624
00:33:35,939 --> 00:33:36,919
Apologies.

625
00:33:36,940 --> 00:33:37,770
Yeah, it's one of those.

626
00:33:37,780 --> 00:33:40,840
Things where it's like certain people care very much,

627
00:33:40,840 --> 00:33:43,270
and for the rest of us, it just gets lost in the details.

628
00:33:43,950 --> 00:33:47,669
Uh, Annika Gupta, chief Product Officer at Rubrik.

629
00:33:47,790 --> 00:33:51,210
I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud.

630
00:33:51,320 --> 00:33:52,999
If you've enjoyed this podcast, please.

631
00:33:52,999 --> 00:33:56,320
We have a five star review on your podcast platform of choice, whereas if

632
00:33:56,320 --> 00:34:00,310
you've hated this podcast, please leave a five star review on your podcast

633
00:34:00,310 --> 00:34:03,629
platform of choice along with an angry, insulting comment that we're just

634
00:34:03,639 --> 00:34:07,519
going to scatter to the winds because we will not be taking care of that data.