1
00:00:25,160 --> 00:00:39,480
The. 
Welcome to the Honest Sport dot 

2
00:00:39,480 --> 00:00:42,360
podcast with this episode invite
Chris McCain to the show to 

3
00:00:42,360 --> 00:00:44,720
introduce us to the world of 
VMRV Defend. 

4
00:00:44,840 --> 00:00:47,720
Hey Chris, welcome to the show. 
Thanks Duncan, been waiting a 

5
00:00:47,720 --> 00:00:49,640
long time. 
Yeah, yeah, I know. 

6
00:00:49,640 --> 00:00:52,160
I've mentioned it a few times 
and somehow it never happened. 

7
00:00:52,160 --> 00:00:55,000
And of course, networking and 
security is not really my thing,

8
00:00:55,000 --> 00:00:58,600
so I really need to force myself
to invite the right person. 

9
00:00:58,880 --> 00:01:02,240
But today we have you on the 
show, so I'm pretty sure there's

10
00:01:02,240 --> 00:01:05,600
going to be a great episode. 
Now, before we get started, I 

11
00:01:05,600 --> 00:01:08,480
know you're kind of famous in 
the industry and of course, 

12
00:01:08,480 --> 00:01:11,080
especially the the 
virtualization community for 

13
00:01:11,080 --> 00:01:12,280
some of the books that you've 
written. 

14
00:01:12,280 --> 00:01:16,120
But maybe you can introduce 
yourself and maybe you can also 

15
00:01:16,520 --> 00:01:19,040
explain what it is that you've 
done before you joined VMS slash

16
00:01:19,040 --> 00:01:21,040
Broadcom because you've been 
around for a long time. 

17
00:01:21,480 --> 00:01:23,600
And I would also like to hear 
about a highlight of your 

18
00:01:23,600 --> 00:01:24,600
career. 
No, sure. 

19
00:01:24,640 --> 00:01:29,360
So, yeah, you know, I joined VM 
Ware 13 years ago. 

20
00:01:30,080 --> 00:01:35,160
So I've spent the last 13 years 
really focused on the networking

21
00:01:35,160 --> 00:01:39,360
and security side of things. 
Prior to that, I owned a company

22
00:01:39,360 --> 00:01:41,800
where VM Ware was my biggest 
customer. 

23
00:01:42,120 --> 00:01:46,000
So I was, I was one of three 
global companies that provided 

24
00:01:46,000 --> 00:01:50,320
contracting services to VM Ware.
So I built exams, I wrote 

25
00:01:50,320 --> 00:01:54,280
content, actually wrote the 
first set of content when VM 

26
00:01:54,280 --> 00:01:59,120
Ware bought Dynamic OPS from 
Credit Suisse, that then became 

27
00:01:59,160 --> 00:02:03,240
VM Ware Cloud Automation Center 
or V CAC as it was infamously 

28
00:02:03,280 --> 00:02:06,600
known. 
And, and then, you know, all the

29
00:02:06,600 --> 00:02:12,720
way into to VCFA now, right? 
But along the way I, you know, 

30
00:02:12,800 --> 00:02:16,360
ESX 2, I started with ESX 2. 
So I, I was the second 

31
00:02:16,400 --> 00:02:19,800
contractor that VM Ware ever 
hired to teach ESX 2. 

32
00:02:19,800 --> 00:02:21,160
I was able to go all over the 
world. 

33
00:02:21,160 --> 00:02:24,320
It was phenomenal. 
It was a pivot from Microsoft 

34
00:02:24,320 --> 00:02:27,200
and Cisco training that I was 
doing and being more kind of 

35
00:02:27,200 --> 00:02:29,920
seemed like the next big thing. 
So I got in really early, which 

36
00:02:29,920 --> 00:02:32,040
was great. 
And then, you know, when I 

37
00:02:32,040 --> 00:02:35,640
joined, I was actually trying to
grow my business. 

38
00:02:35,640 --> 00:02:39,920
I was trying to, to reach out to
the, the new NSBU they just 

39
00:02:39,920 --> 00:02:42,960
bought Nicira and I was trying 
to grow my business and say, 

40
00:02:42,960 --> 00:02:46,440
Hey, let me help you build your 
certification portfolio and all 

41
00:02:46,440 --> 00:02:50,080
your training and, and you know,
one thing led to another. 

42
00:02:50,080 --> 00:02:52,720
And I ended up joining and 
really it was about the 

43
00:02:52,720 --> 00:02:57,080
excitement around what I saw 
they were doing with networking 

44
00:02:57,080 --> 00:02:58,840
and security. 
I'd been in the hypervisor so 

45
00:02:58,840 --> 00:03:02,840
long and I saw the trajectory of
change in the data center. 

46
00:03:02,840 --> 00:03:04,880
And when I saw the networking 
and security, I was like, this 

47
00:03:04,880 --> 00:03:08,160
is, this is really cool stuff. 
And it wasn't, it wasn't 

48
00:03:08,160 --> 00:03:10,120
desktops, right? 
Desktop was kind of a very 

49
00:03:10,120 --> 00:03:12,760
complimentary thing that sat on 
top of it. 

50
00:03:12,920 --> 00:03:15,480
The networking and security was 
a completely different paradigm.

51
00:03:15,480 --> 00:03:16,880
It was a totally different 
audience. 

52
00:03:16,880 --> 00:03:20,000
So I think there was a challenge
there for me to be able to, to 

53
00:03:20,000 --> 00:03:24,120
come into VM Ware, not in a 
specific job role, but to help 

54
00:03:24,120 --> 00:03:26,920
them build this thing called 
networking and security. 

55
00:03:26,920 --> 00:03:28,680
And that that was really 
attractive to me. 

56
00:03:29,680 --> 00:03:34,120
But highlights, I think I would 
say there's 21 before I joined 

57
00:03:34,120 --> 00:03:36,520
VM Ware. 
And that was when I got my VCDX.

58
00:03:36,840 --> 00:03:38,360
You know, like I said, I was a 
trainer. 

59
00:03:38,760 --> 00:03:43,040
So for me, the VCDX wasn't about
a, a specific thing other than 

60
00:03:43,040 --> 00:03:47,400
challenging myself, seeing guys 
like you and Frank and John and 

61
00:03:47,400 --> 00:03:50,680
all these guys who were industry
vets and leaders in this space 

62
00:03:50,960 --> 00:03:53,920
and really challenging myself to
be at that level. 

63
00:03:54,280 --> 00:03:56,800
And I had a, a unique 
opportunity where as part of my 

64
00:03:56,800 --> 00:04:02,480
business, I was, I was building 
the data center design to host 

65
00:04:02,480 --> 00:04:07,080
all of Dell's training for Equal
Logic, EMC and VM Ware. 

66
00:04:07,080 --> 00:04:10,120
So they were sending all this 
year based on my design, I got a

67
00:04:10,120 --> 00:04:11,560
chance to manage it. 
And I just thought, you know, 

68
00:04:11,560 --> 00:04:14,880
this is the right fit for me to 
be able to take this thing that 

69
00:04:14,880 --> 00:04:18,880
I own and control and couple 
that with the training that I'm 

70
00:04:18,880 --> 00:04:21,120
doing and see if I can get a 
VCDX. 

71
00:04:21,120 --> 00:04:25,000
So, you know, the hardest part 
in the VCDX for me was in the 

72
00:04:25,000 --> 00:04:26,880
assembly of all the 
documentation. 

73
00:04:26,880 --> 00:04:30,080
But as far as the defense and 
things like that was natural for

74
00:04:30,080 --> 00:04:31,840
me. 
I was to standing up in front of

75
00:04:32,040 --> 00:04:34,880
12 or 15 people as the expert to
talk. 

76
00:04:35,240 --> 00:04:38,000
So it and I owned the the 
design. 

77
00:04:38,000 --> 00:04:41,080
So really it was a natural fit. 
But then I think getting that 

78
00:04:41,080 --> 00:04:44,560
that VCDX was a highlight for me
and it was a pivot in my career 

79
00:04:44,560 --> 00:04:48,120
because now I did start to focus
more on some consulting stuff. 

80
00:04:49,040 --> 00:04:51,320
So that was big. 
And I look back on that and it 

81
00:04:51,320 --> 00:04:54,920
was, it was great challenge to, 
to be able to get and then the 

82
00:04:54,920 --> 00:04:57,920
other one, it's probably being 
on stage at Explorer. 

83
00:04:59,080 --> 00:05:02,800
Do I wish it would have been 
the, the 25,000 person Explorer?

84
00:05:02,800 --> 00:05:05,560
Of course, right. 
But you know, to get to stand in

85
00:05:05,560 --> 00:05:09,520
front of 5006 thousand people 
that are there, It was, was fun.

86
00:05:09,520 --> 00:05:13,840
And, and just the way that it 
all happened organically was 

87
00:05:13,840 --> 00:05:15,120
great. 
I was a little, I was a little 

88
00:05:15,120 --> 00:05:17,600
worried, not, not nervous. 
I was a little worried because I

89
00:05:17,600 --> 00:05:20,000
knew that Explorer was a very 
scripted event. 

90
00:05:20,520 --> 00:05:23,680
And anybody who has seen me 
talk, I am not a scripted kind 

91
00:05:23,680 --> 00:05:26,080
of guy. 
Yeah, I'm shoot from the hip 

92
00:05:26,080 --> 00:05:28,760
from the tip to the to the final
buzzer. 

93
00:05:29,240 --> 00:05:30,560
But it ended up working all 
right. 

94
00:05:30,560 --> 00:05:32,960
They gave us a lot of freedom 
and flexibility to be able to 

95
00:05:32,960 --> 00:05:34,720
communicate and talk the way we 
wanted to. 

96
00:05:34,720 --> 00:05:37,520
They just wanted some bullet 
points to make sure that timing 

97
00:05:37,520 --> 00:05:39,800
is is there. 
So I understood it, but it was 

98
00:05:40,160 --> 00:05:43,240
it was great to get to hang out 
with Hock and get meet him and 

99
00:05:43,720 --> 00:05:46,440
chat with him, but see all the 
behind the scenes stuff. 

100
00:05:46,440 --> 00:05:49,800
But yeah, definitely the 
highlight from the last few 

101
00:05:49,800 --> 00:05:51,080
years. 
That's funny. 

102
00:05:51,080 --> 00:05:53,440
That's probably one of the 
things that changed the most 

103
00:05:53,920 --> 00:05:58,000
compared to the VM world days 
where we had the VM executives 

104
00:05:58,400 --> 00:06:00,080
up on the stage. 
As you said, everything was 

105
00:06:00,080 --> 00:06:04,080
scripted, every single dot, 
every single exclamation mark, 

106
00:06:04,360 --> 00:06:05,560
you know, it was all in the 
notes. 

107
00:06:05,560 --> 00:06:07,320
But as you said, you had some 
normal freedom. 

108
00:06:07,320 --> 00:06:09,880
So that's, that's good to hear. 
And I think it was clear as well

109
00:06:09,880 --> 00:06:13,400
during the presentation you guys
did did great and it was 

110
00:06:13,400 --> 00:06:15,400
extremely interesting. 
It's also one of the reasons I 

111
00:06:15,400 --> 00:06:17,600
invited you. 
Now, as I mentioned today, we're

112
00:06:17,600 --> 00:06:20,480
going to be talking about 
security mainly. 

113
00:06:20,480 --> 00:06:24,320
I had Eve on the show to talk 
about networking a couple of 

114
00:06:24,320 --> 00:06:26,400
episodes ago. 
So I figured we probably should 

115
00:06:26,400 --> 00:06:29,520
also be talking about security. 
Now, one of the things I wanted 

116
00:06:29,520 --> 00:06:31,560
to touch upon first because this
is something that you've 

117
00:06:31,560 --> 00:06:33,920
presented on many different 
times, and I think it's probably

118
00:06:33,920 --> 00:06:37,200
something that is good to hear 
for my listeners as well. 

119
00:06:37,200 --> 00:06:39,800
For those who haven't seen you 
at one of the V mugs or maybe at

120
00:06:39,800 --> 00:06:43,160
Explore, is the thing that 
you've always spoke about, which

121
00:06:43,160 --> 00:06:47,320
is NSX mindset. 
Now, of course, everything has 

122
00:06:47,320 --> 00:06:49,480
changed, the pricing, the 
packaging, but I think the 

123
00:06:49,480 --> 00:06:52,080
mindset still applies. 
So maybe you can explain what 

124
00:06:52,080 --> 00:06:56,880
that NSX mindset actually means 
and you know how people should 

125
00:06:56,880 --> 00:06:59,840
think about that. 
Yeah, it's, it's a great point. 

126
00:06:59,840 --> 00:07:04,720
So, you know, NSX mindset came 
out of the idea or the, the, the

127
00:07:04,720 --> 00:07:09,560
concept was born from the fact 
that when I joined an SBU and I 

128
00:07:09,560 --> 00:07:13,440
started going out to talk with 
customers, we had a very, very 

129
00:07:14,120 --> 00:07:16,800
cool technology in what we did 
right. 

130
00:07:16,800 --> 00:07:20,960
The abstraction of routing and 
switching into the hypervisor. 

131
00:07:21,280 --> 00:07:24,680
The, the architecture is of 
course unique, but in talking 

132
00:07:24,680 --> 00:07:29,000
with customers, it wasn't a 
technology discussion as much as

133
00:07:29,000 --> 00:07:33,960
it became a humanistic barrier 
for people to, to let go of what

134
00:07:33,960 --> 00:07:37,360
they were doing traditionally. 
This idea that, no, I have to 

135
00:07:37,360 --> 00:07:40,960
log into this switch and I have 
the trunk of VLAN and I, I know 

136
00:07:40,960 --> 00:07:44,720
Cisco, I have this behavioral 
momentum that every five years 

137
00:07:44,720 --> 00:07:46,200
I'm going to refresh my Cisco 
switch. 

138
00:07:46,200 --> 00:07:48,160
And that's just what I'm always 
going to do. 

139
00:07:48,760 --> 00:07:49,960
So it had nothing to do with 
technology. 

140
00:07:49,960 --> 00:07:53,800
It had everything to do with 
getting people to see networking

141
00:07:53,800 --> 00:07:56,360
and security differently. 
And that's where I think the 

142
00:07:56,360 --> 00:07:59,640
mindset piece came in because 
we're really targeting 

143
00:08:00,200 --> 00:08:03,840
understanding our technology 
from the the standpoint that 

144
00:08:03,840 --> 00:08:07,440
what we're offering to you is 
not a different skill set. 

145
00:08:07,720 --> 00:08:10,800
Networking is networking. 
It's still BGP, it's still OSPF,

146
00:08:10,920 --> 00:08:13,480
they're still default gateways, 
they're still routing. 

147
00:08:13,840 --> 00:08:17,080
But the way that it gets 
implemented was different. 

148
00:08:17,080 --> 00:08:21,320
So it was just a small shift in 
thinking, not a giant shift in 

149
00:08:21,320 --> 00:08:24,240
technology. 
So when we when, when I kind of 

150
00:08:24,240 --> 00:08:27,040
brought this to market as NSX 
mindset, I think that's what 

151
00:08:27,040 --> 00:08:29,720
started to draw people in is 
what does that, what does that 

152
00:08:29,720 --> 00:08:31,240
mean? 
Like, why, why are you saying 

153
00:08:31,240 --> 00:08:33,200
mindset? 
How does that actually relevant?

154
00:08:33,200 --> 00:08:35,960
So sounds like you're, you're 
trying to talk me out of, you 

155
00:08:36,039 --> 00:08:37,840
know, being upset about 
something. 

156
00:08:37,840 --> 00:08:41,679
It's in some psychology way, but
it was really just a humanistic 

157
00:08:41,679 --> 00:08:43,320
thing. 
And, and look, we've pivoted to 

158
00:08:43,320 --> 00:08:47,840
that several years ago. 
We did security mindset at, at 

159
00:08:47,840 --> 00:08:51,120
Explorer and it, it was great. 
I mean, we did a 90 minute 

160
00:08:51,120 --> 00:08:53,440
session. 
I think over a couple different 

161
00:08:53,440 --> 00:08:55,720
years we had over 1200 people 
come through it. 

162
00:08:55,720 --> 00:09:00,240
But I, I think people are 
interested from a humanistic 

163
00:09:00,240 --> 00:09:03,400
perspective in how they make, 
how they, how they create 

164
00:09:03,400 --> 00:09:05,640
change. 
And I think it's, it's a common 

165
00:09:05,640 --> 00:09:08,920
boundary that goes beyond 
technology is just how do we 

166
00:09:08,920 --> 00:09:11,840
fight off this fear of change? 
And that's really what we 

167
00:09:11,840 --> 00:09:15,560
focused on is that you, you got 
to get over this idea that we're

168
00:09:15,560 --> 00:09:18,640
providing any type of radical 
new technology. 

169
00:09:18,640 --> 00:09:21,560
Firewalling is firewalling. 
We're, we're not doing anything 

170
00:09:21,560 --> 00:09:23,680
special. 
Did we change the architecture? 

171
00:09:23,680 --> 00:09:25,920
Sure. 
But that's, that's got nothing 

172
00:09:25,920 --> 00:09:28,920
to do with making it difficult. 
We're making it easier for 

173
00:09:28,920 --> 00:09:31,360
people. 
So the whole mindset piece is 

174
00:09:31,360 --> 00:09:34,960
really, it's stuck over the 
years and I still have people 

175
00:09:34,960 --> 00:09:38,040
that I see wearing the T-shirts 
that say NSX mindset. 

176
00:09:38,040 --> 00:09:41,920
And so it, it kind of took on a 
life of its own over the years, 

177
00:09:41,920 --> 00:09:46,040
but it was definitely rooted in,
like I said earlier, the 

178
00:09:46,040 --> 00:09:50,080
networking and security stuff 
was a, a different demographic. 

179
00:09:50,320 --> 00:09:53,320
We weren't necessarily able to 
sell it to the people who were 

180
00:09:53,320 --> 00:09:57,000
so excited about virtualization.
We had to go to a different 

181
00:09:57,000 --> 00:10:01,000
demographic of people who 
basically we're not impacted by 

182
00:10:01,000 --> 00:10:02,720
virtualization. 
Because if you're a network 

183
00:10:02,720 --> 00:10:05,480
engineer, if you go back to VI 
three, I think we can all agree 

184
00:10:05,480 --> 00:10:08,400
VI 3 is when we really started 
to make headway. 

185
00:10:08,400 --> 00:10:11,600
But if you go back to VI 3, when
that started to reach into the 

186
00:10:11,600 --> 00:10:14,920
data centers, the operational 
model for the network engineer, 

187
00:10:15,200 --> 00:10:19,200
it didn't change significantly 
because prior to virtualization,

188
00:10:19,200 --> 00:10:21,720
if you deployed a new server and
needed a network, what'd you do?

189
00:10:21,720 --> 00:10:23,560
You picked up the phone, you 
called the networking team, you 

190
00:10:23,560 --> 00:10:25,200
said, hey, can you trunk me 
AVLAN? 

191
00:10:25,200 --> 00:10:26,520
And they're like, well, what do 
you need it for? 

192
00:10:26,520 --> 00:10:27,360
And they're like, what do you 
care? 

193
00:10:27,360 --> 00:10:29,480
And then you go back and forth 
and then finally you get your 

194
00:10:29,480 --> 00:10:31,880
VLAN. 
Well, now you had virtualization

195
00:10:32,240 --> 00:10:34,440
and we're sitting on top of the 
physical network fabric. 

196
00:10:34,440 --> 00:10:36,800
But if you deployed 50 new 
virtual machines, the way you 

197
00:10:36,800 --> 00:10:39,480
would have just deployed 1 
server and you needed a network,

198
00:10:39,480 --> 00:10:41,000
what did you do? 
You picked up the phone, you 

199
00:10:41,000 --> 00:10:43,120
called the networking team, you 
said, hey, give me AVLAN. 

200
00:10:43,120 --> 00:10:44,480
Like, what do you need it for? 
What do you care? 

201
00:10:44,480 --> 00:10:46,280
And you go back and forth and 
then you get your VLAN. 

202
00:10:46,480 --> 00:10:49,840
So the operational, the model 
didn't change for networking and

203
00:10:49,840 --> 00:10:51,760
it didn't change for storage 
because they're like, oh, give 

204
00:10:51,760 --> 00:10:52,840
me a Lun. 
What do you need it for? 

205
00:10:52,840 --> 00:10:54,560
What do you care? 
Just give me a Lun and then you 

206
00:10:54,560 --> 00:10:56,680
go virtualization and it's the 
same story. 

207
00:10:57,000 --> 00:11:00,400
So those individuals that bought
into virtualization were not the

208
00:11:00,400 --> 00:11:02,800
individuals that we were now 
trying to target from a 

209
00:11:02,800 --> 00:11:04,400
networking and security 
perspective. 

210
00:11:05,040 --> 00:11:08,720
So it really required us to 
reach deep into the bag of 

211
00:11:08,720 --> 00:11:11,960
getting people to understand 
that we're not. 

212
00:11:11,960 --> 00:11:13,600
We're not trying to take your 
job away. 

213
00:11:13,840 --> 00:11:15,720
This is not something you 
haven't been doing. 

214
00:11:15,960 --> 00:11:17,600
The skills are there. 
It's just a different tool. 

215
00:11:19,000 --> 00:11:22,520
And the interesting thing is, I 
think we had similar problems 

216
00:11:22,520 --> 00:11:24,680
with with V San. 
But of course with V SAN, we're 

217
00:11:24,680 --> 00:11:27,360
actually selling storage to the 
virtualization administrator 

218
00:11:27,360 --> 00:11:29,840
where you are selling new 
networking services or a 

219
00:11:29,840 --> 00:11:32,600
different way of doing networks 
to network engineers. 

220
00:11:32,720 --> 00:11:37,360
So yeah, it's a, I guess a more 
challenging problem, I should 

221
00:11:37,360 --> 00:11:39,720
probably say, knowing some of 
the networking engineers, right?

222
00:11:39,960 --> 00:11:42,960
For sure, for sure. 
Now one of the things of course,

223
00:11:42,960 --> 00:11:45,120
as I mentioned, we're going to 
be talking about today is 

224
00:11:45,120 --> 00:11:47,080
security. 
And we all know that V Defend is

225
00:11:47,080 --> 00:11:50,760
a big part of that. 
And recently for most people, 

226
00:11:50,760 --> 00:11:53,440
probably over the last year, 
year and a half, a lot of s s 

227
00:11:53,480 --> 00:11:56,480
has actually changed from a 
licensing perspective or 

228
00:11:56,480 --> 00:11:58,920
packaging point of view. 
I'm not, I don't want to talk 

229
00:11:58,920 --> 00:12:01,040
about numbers specifically, but 
I think packaging is 

230
00:12:01,040 --> 00:12:03,680
interesting. 
So it's probably good before we 

231
00:12:03,680 --> 00:12:07,040
actually start diving into some 
more specifics to explain what 

232
00:12:07,040 --> 00:12:10,800
the V Defen offering is and how 
it actually ties in with VCF 

233
00:12:10,960 --> 00:12:14,000
from a licensing and or 
packaging point of view I should

234
00:12:14,000 --> 00:12:15,360
say instead. 
Yeah. 

235
00:12:15,360 --> 00:12:17,560
This, this one's really 
interesting to me because when I

236
00:12:17,560 --> 00:12:24,320
think back at just the evolution
of the NSBU and the evolution of

237
00:12:24,320 --> 00:12:28,640
the product pre acquisition to 
post acquisition, right. 

238
00:12:28,640 --> 00:12:32,240
So pre acquisition when we had 
this thing that we called NSX 

239
00:12:32,640 --> 00:12:36,760
and NSX was networking and it 
was security. 

240
00:12:37,680 --> 00:12:41,080
The problem I think that we had 
and we kind of shot ourselves in

241
00:12:41,080 --> 00:12:43,920
the foot with this is, is, is we
called it networking and 

242
00:12:43,920 --> 00:12:49,200
security and the reality of it 
was it was networking and or 

243
00:12:49,200 --> 00:12:51,960
security. 
They were mutually exclusive. 

244
00:12:51,960 --> 00:12:54,440
Did they work well together? 
Yeah, absolutely. 

245
00:12:54,440 --> 00:12:57,080
Could I make the business case 
that they should be used 

246
00:12:57,080 --> 00:12:58,320
together? 
Yes, of course. 

247
00:12:58,640 --> 00:13:01,240
However, they were independent 
entities. 

248
00:13:01,240 --> 00:13:05,000
You did not have to do overlay 
networking in order to get the 

249
00:13:05,000 --> 00:13:08,040
security piece. 
So we didn't do a good job of 

250
00:13:08,040 --> 00:13:10,240
telling customers that specific 
thing. 

251
00:13:10,240 --> 00:13:12,080
So we had a lot of customers who
were very interested in 

252
00:13:12,080 --> 00:13:15,120
security, but they were under 
the thinking that, well, if I 

253
00:13:15,120 --> 00:13:17,240
want to do security, I have to 
do the networking. 

254
00:13:17,240 --> 00:13:19,640
And as you just pointed out, if 
you've got to convince a 

255
00:13:19,640 --> 00:13:23,480
networking engineer to allow you
to do overlays in order to get 

256
00:13:23,480 --> 00:13:26,640
security, you now have a giant 
hurdle that you have to 

257
00:13:26,640 --> 00:13:29,480
overcome. 
So when you Fast forward to 

258
00:13:29,480 --> 00:13:33,440
today post acquisition and 
what's happened is that the 

259
00:13:33,440 --> 00:13:37,640
networking portion of the artist
formerly known as NSX is now 

260
00:13:37,640 --> 00:13:41,960
embedded into the core platform 
that makes up the private cloud.

261
00:13:42,440 --> 00:13:47,000
And then the security portion is
an add on that now has its own 

262
00:13:47,000 --> 00:13:51,000
name of VM Ware V Defend. 
So from an art and then this is,

263
00:13:51,120 --> 00:13:53,800
this is critical because I still
think a lot of times people get 

264
00:13:53,800 --> 00:13:57,400
confused here from an 
architectural perspective, V 

265
00:13:57,400 --> 00:14:01,520
Defend is and always will be 
built into the hypervisor. 

266
00:14:01,920 --> 00:14:04,680
That does not mean that it's 
built into the packaging and 

267
00:14:04,680 --> 00:14:08,280
pricing of the VCF product 
itself. 

268
00:14:08,720 --> 00:14:11,440
So it's an add on, even though 
architecturally it's still an 

269
00:14:11,440 --> 00:14:13,800
hypervisor just like the 
networking is in the hypervisor,

270
00:14:13,800 --> 00:14:16,560
just like storage is controlled 
to the hypervisor, the security 

271
00:14:16,560 --> 00:14:19,880
is in the hypervisor, but it's 
an add on to that. 

272
00:14:19,880 --> 00:14:23,400
So it's an interesting model, 
but I do think that now there's 

273
00:14:23,400 --> 00:14:27,480
a very clear demarcation between
the networking stuff and the 

274
00:14:27,480 --> 00:14:30,920
security stuff that we have. 
One of the other things that I 

275
00:14:30,920 --> 00:14:33,600
probably probably should be 
talking about as well, because 

276
00:14:34,040 --> 00:14:37,560
I've seen some customers 
actually implementing VCF with 

277
00:14:37,560 --> 00:14:41,760
just NSX and some of them 
actually do VCF, NSX, and V 

278
00:14:41,760 --> 00:14:44,160
defense. 
Now, in your opinion, right? 

279
00:14:44,160 --> 00:14:47,520
To make things that simple for 
our listeners, does it actually 

280
00:14:47,520 --> 00:14:52,480
make sense to implement VCF plus
NSX without V defense, or should

281
00:14:52,480 --> 00:14:56,560
everyone just be using it? 
Look in, in this new Broadcom 

282
00:14:56,560 --> 00:15:01,840
world of pushing private cloud 
to compete with public cloud, I 

283
00:15:01,840 --> 00:15:05,920
don't think you can build an 
equivalent operational model to 

284
00:15:05,920 --> 00:15:10,000
the public cloud if you are not 
using both the networking and 

285
00:15:10,000 --> 00:15:14,120
the security aspects of it. 
And and there's really one key 

286
00:15:14,120 --> 00:15:16,880
reason for this. 
The operational model of the 

287
00:15:16,880 --> 00:15:23,360
public cloud requires that the 
physical network fabric not be 

288
00:15:23,720 --> 00:15:25,480
dynamic. 
You can't. 

289
00:15:25,920 --> 00:15:28,520
If you spin up something in 
Amazon, you don't pick up the 

290
00:15:28,520 --> 00:15:30,680
phone to call somebody to ask 
for a network. 

291
00:15:30,680 --> 00:15:32,920
It has to be generated 
dynamically. 

292
00:15:33,400 --> 00:15:35,320
The easiest way to do that is in
software. 

293
00:15:35,920 --> 00:15:39,440
So if customers want that model,
they have to to think 

294
00:15:39,440 --> 00:15:41,640
differently about the physical 
network fabric. 

295
00:15:41,920 --> 00:15:45,800
They have to design it once, 
wire it once and leave it alone.

296
00:15:45,920 --> 00:15:48,880
Don't touch it. 
Relegate the physical fabric to 

297
00:15:48,880 --> 00:15:50,560
passing packets. 
That's it. 

298
00:15:51,000 --> 00:15:54,520
Give me an SLA that says we're 
going to be up X amount of time 

299
00:15:54,560 --> 00:15:56,080
and we're just going to pass 
your packets. 

300
00:15:56,400 --> 00:15:59,440
But if you need a new network, 
if you want to consume some type

301
00:15:59,440 --> 00:16:02,200
of networking service, it's 
going to come out of software 

302
00:16:02,360 --> 00:16:05,760
the same way it does in AWS, the
same way it does in Azure, the 

303
00:16:05,760 --> 00:16:08,520
same way it does in Google. 
That's the only way to get to 

304
00:16:08,520 --> 00:16:11,880
that point. 
Now the problem with that is if 

305
00:16:11,880 --> 00:16:15,840
you don't use the security 
piece, then you're using this 

306
00:16:15,840 --> 00:16:20,240
legacy architecture that says in
order to apply security, I have 

307
00:16:20,240 --> 00:16:23,200
to force traffic over a layer 3 
device. 

308
00:16:23,920 --> 00:16:26,600
So that's been the biggest 
problem from a networking and 

309
00:16:26,600 --> 00:16:30,640
security perspective is that 
those two things clash because I

310
00:16:30,640 --> 00:16:33,280
want to protect something. 
But in order to protect it, I 

311
00:16:33,280 --> 00:16:36,680
got to go to the networking team
and ask for three different 

312
00:16:36,680 --> 00:16:39,920
networks for this multi tier app
because then I have to force it 

313
00:16:39,920 --> 00:16:43,200
over a firewall device, right? 
A layer 3 device. 

314
00:16:43,800 --> 00:16:46,760
That's where VDEFND completely 
changes this paradigm. 

315
00:16:47,400 --> 00:16:49,080
It it flips everything on its 
head. 

316
00:16:49,080 --> 00:16:52,880
Because for us, when we abstract
the firewall into the 

317
00:16:52,880 --> 00:16:56,920
hypervisor, we're actually 
disaggregating the relationship 

318
00:16:57,360 --> 00:17:02,320
between IP and security. 
They they're no longer matched 

319
00:17:02,320 --> 00:17:05,599
with one another. 
So for VDEFND, you do not have 

320
00:17:05,599 --> 00:17:09,960
to change a single piece of the 
physical network fabric in order

321
00:17:09,960 --> 00:17:13,760
to implement, but at the same 
time you're optimizing the 

322
00:17:13,760 --> 00:17:19,040
ability to control flows between
virtual machines that may not 

323
00:17:19,040 --> 00:17:22,000
only be sitting on the same 
host, they're on the same IP 

324
00:17:22,000 --> 00:17:26,599
network of the same host, which 
as we all know, would never 

325
00:17:26,640 --> 00:17:28,280
actually egress that host, 
right? 

326
00:17:28,280 --> 00:17:29,880
All communication would happen 
in the host. 

327
00:17:29,960 --> 00:17:33,320
So a physical firewall is 
completely irrelevant at that 

328
00:17:33,320 --> 00:17:35,360
point. 
You cannot solve that problem 

329
00:17:35,600 --> 00:17:38,600
using a physical firewall. 
You can only solve that problem 

330
00:17:38,760 --> 00:17:42,440
if you want to try and manage 
agents inside of every VM, which

331
00:17:42,440 --> 00:17:46,280
is crazy, or if you leverage the
hypervisor, which is our 

332
00:17:46,280 --> 00:17:49,520
competitive advantage. 
So by breaking that relationship

333
00:17:49,520 --> 00:17:52,480
between IP and networking, 
that's the only way you're going

334
00:17:52,480 --> 00:17:56,000
to get to a point where you can 
simplify the future state 

335
00:17:56,000 --> 00:17:59,320
architecture of design. 
Because now when you have the 

336
00:17:59,320 --> 00:18:03,600
ability to protect without 
requiring specific networking 

337
00:18:03,600 --> 00:18:07,960
configurations, you can now 
pivot the model into rather than

338
00:18:07,960 --> 00:18:11,600
building a whole bunch of small 
networks to be able to force the

339
00:18:11,600 --> 00:18:15,240
traffic over a device that can 
inspect, you can build larger, 

340
00:18:15,240 --> 00:18:18,680
flatter networks that don't 
compromise security, which makes

341
00:18:18,680 --> 00:18:22,000
the long term management of the 
network even easier. 

342
00:18:22,440 --> 00:18:26,680
So it's really, if you want to 
do things that are, are going to

343
00:18:26,680 --> 00:18:31,560
facilitate the company's ability
to automate, to be agile, to 

344
00:18:31,560 --> 00:18:35,320
scale, you have to be using both
the networking and security. 

345
00:18:35,320 --> 00:18:36,760
And look, it's storage too, 
right? 

346
00:18:36,800 --> 00:18:39,040
We, you can't take that piece 
out of it. 

347
00:18:39,320 --> 00:18:42,160
If you want to automate, you 
want to truly build something 

348
00:18:42,160 --> 00:18:45,040
that looks like AWS. 
You're talking about compute, 

349
00:18:45,040 --> 00:18:47,840
storage, networking, security. 
They all have to be automated. 

350
00:18:47,880 --> 00:18:50,880
They all have to be consumed 
dynamically and one should not 

351
00:18:50,880 --> 00:18:53,680
impact the other. 
And the easiest way to do that 

352
00:18:53,680 --> 00:18:57,040
is when you consume the full 
private cloud stack of VCF and 

353
00:18:57,040 --> 00:18:59,000
then the additional add-ons for 
security. 

354
00:18:59,600 --> 00:19:04,120
And I guess the great added 
benefit is that it also means 

355
00:19:04,120 --> 00:19:06,720
that you no longer have to talk 
to the security team, right, as 

356
00:19:06,720 --> 00:19:08,600
a, as a result of of this 
solution. 

357
00:19:08,600 --> 00:19:11,840
Now you kind of alluded to it, 
but you didn't mention it. 

358
00:19:11,840 --> 00:19:15,080
So I'm going to say the word 
micro segmentation because you 

359
00:19:15,080 --> 00:19:17,400
kind of mention it with all of 
the different virtual machines 

360
00:19:17,400 --> 00:19:19,440
connecting and preventing 
connection from happening 

361
00:19:19,440 --> 00:19:21,840
etcetera. 
Now, I know it's something that 

362
00:19:21,840 --> 00:19:26,720
as VMI we spoke about a lot many
moons ago, but I kind of, I kind

363
00:19:26,720 --> 00:19:27,960
of have the feeling that it 
disappeared. 

364
00:19:27,960 --> 00:19:31,480
And I know you touched on this 
during your explore session and 

365
00:19:31,640 --> 00:19:35,240
I thought it was something that 
we should bring up because the 

366
00:19:35,240 --> 00:19:37,800
way you explained it, I think 
really hit home. 

367
00:19:38,080 --> 00:19:40,960
So what is your opinion on micro
segmentation? 

368
00:19:40,960 --> 00:19:43,400
Or do you feel it's something 
that people should still be 

369
00:19:43,400 --> 00:19:46,080
implementing today or not? 
When does it make sense? 

370
00:19:46,280 --> 00:19:49,040
When doesn't it make sense? 
Because it seems rather complex.

371
00:19:49,640 --> 00:19:54,280
Yeah, So it is complex and I'll,
I'll give you the back story in 

372
00:19:54,280 --> 00:19:56,360
this. 
And look, I'm just as guilty. 

373
00:19:56,520 --> 00:20:00,480
So if people want to point 
fingers at me, I I can't deny 

374
00:20:00,640 --> 00:20:04,360
I'm just as guilty as every 
other person in the NSBU as 

375
00:20:04,360 --> 00:20:06,920
jumping on the micro 
segmentation bandwagon. 

376
00:20:07,680 --> 00:20:10,880
And so if I look back at the 
history and this is, you know, 

377
00:20:11,000 --> 00:20:15,200
anecdotally, what I think 
happened is in the beginning of 

378
00:20:15,240 --> 00:20:17,960
NSBU. 
We were really focused on 

379
00:20:17,960 --> 00:20:20,280
networking. 
In fact, many of the people in 

380
00:20:20,280 --> 00:20:23,920
the NSBU had come from 
networking vendors and everybody

381
00:20:23,920 --> 00:20:25,920
was so excited about the 
networking stuff. 

382
00:20:26,120 --> 00:20:29,120
And the more we talked with 
customers, the more customers 

383
00:20:29,120 --> 00:20:33,120
were like, OK, it's cool, but 
you know, I got to get my 

384
00:20:33,120 --> 00:20:35,760
networking team involved in it. 
But I, I kind of like that 

385
00:20:35,760 --> 00:20:39,360
security thing, right? 
We started to realize, OK, maybe

386
00:20:39,720 --> 00:20:43,200
the lead in here is security. 
So we go back to the drawing 

387
00:20:43,200 --> 00:20:45,440
board. 
Well, we come out and we jump 2 

388
00:20:45,440 --> 00:20:49,280
feet into micro segmentation and
we stood on every mountaintop 

389
00:20:49,280 --> 00:20:52,640
and screamed micro segmentation.
We got in every customer 

390
00:20:52,640 --> 00:20:54,800
meeting, every explore session 
we could. 

391
00:20:54,800 --> 00:20:57,280
And we said micro, seg, micro 
seg, micro seg. 

392
00:20:57,840 --> 00:21:01,480
And in the beginning, customers 
would, you know, nod their head 

393
00:21:01,480 --> 00:21:04,200
violently, yes, this is amazing,
this is great, this is great. 

394
00:21:04,400 --> 00:21:07,680
And then we would leave and they
do nothing and we're like, I 

395
00:21:07,680 --> 00:21:10,640
don't understand. 
It seemed like they love this 

396
00:21:10,640 --> 00:21:12,960
idea. 
So then you go back to the 

397
00:21:12,960 --> 00:21:14,720
customer, you say what happened?
Why? 

398
00:21:14,800 --> 00:21:17,080
Why didn't you want to do micro 
segmentation? 

399
00:21:17,080 --> 00:21:20,800
Say, oh, it it's too hard. 
We don't, we don't know how our 

400
00:21:20,800 --> 00:21:22,840
applications actually 
communicate. 

401
00:21:23,000 --> 00:21:24,720
We don't know what flows. 
We don't even know how to build 

402
00:21:24,720 --> 00:21:28,640
the rules for this thing. 
So of course, being VM Ware, 

403
00:21:28,640 --> 00:21:30,600
what does VM Ware do when a 
customer says we don't know how 

404
00:21:30,600 --> 00:21:32,720
to do something? 
We built a product for it. 

405
00:21:32,920 --> 00:21:35,480
And so we did. 
We built this really cool tool 

406
00:21:35,480 --> 00:21:37,240
that was called security 
intelligence. 

407
00:21:37,440 --> 00:21:41,400
And security intelligence would 
look at all the flows and then 

408
00:21:41,400 --> 00:21:44,840
generate rule recommendations so
user could look at it and see 

409
00:21:44,840 --> 00:21:47,320
all the recommendations. 
And there was even a button push

410
00:21:47,320 --> 00:21:49,680
here and it would build all the 
policies for you. 

411
00:21:49,880 --> 00:21:52,160
So we go back, we show customers
because like, yeah, yeah, yeah, 

412
00:21:52,160 --> 00:21:53,840
this is great, this is great. 
And then we leave and they do 

413
00:21:53,840 --> 00:21:56,520
nothing and we come back and 
say, well, what happened? 

414
00:21:56,800 --> 00:22:00,520
Why didn't you push the button? 
And they said, well, we don't 

415
00:22:00,520 --> 00:22:04,800
know if those rules are right. 
Nobody knows nobody. 

416
00:22:04,920 --> 00:22:08,000
So the problem wasn't a 
technology thing again, it was 

417
00:22:08,000 --> 00:22:11,920
back to being a human thing, 
because a human who pushes that 

418
00:22:11,920 --> 00:22:16,240
button is essentially becoming 
accountable for the all of those

419
00:22:16,240 --> 00:22:19,560
flows that could potentially 
break the application. 

420
00:22:19,720 --> 00:22:21,800
And nobody wanted to be that 
person, right? 

421
00:22:22,160 --> 00:22:25,400
I, I put it this way, sometimes 
think about doing AV sphere 

422
00:22:25,400 --> 00:22:28,360
upgrade. 
When you do AV sphere upgrade, 

423
00:22:28,720 --> 00:22:30,000
you've probably done it before, 
right? 

424
00:22:30,000 --> 00:22:32,720
When you do AV sphere upgrade, 
if you're that guy that has to 

425
00:22:32,720 --> 00:22:36,440
push the button to start this 
upgrade, think about what that 

426
00:22:36,520 --> 00:22:41,200
feeling in your stomach is like.
You're nervous, you're thinking,

427
00:22:41,280 --> 00:22:45,280
God, please, I haven't talked to
you in a while, but please don't

428
00:22:45,280 --> 00:22:48,800
let this fail. 
Please don't let this break. 

429
00:22:49,080 --> 00:22:51,320
I've been in a position a few 
times that it broke, so I know 

430
00:22:51,320 --> 00:22:52,760
how it feels. 
Exactly. 

431
00:22:52,840 --> 00:22:55,560
But but imagine that's micro 
segmentation. 

432
00:22:56,040 --> 00:22:59,640
So that's not just once a year, 
that's not once a, that's every 

433
00:22:59,640 --> 00:23:03,840
time you deploy an and you use 
this tool to build policy, 

434
00:23:04,040 --> 00:23:07,120
that's the feeling you get 
because you could break the 

435
00:23:07,160 --> 00:23:10,640
application. 
So it became difficult. 

436
00:23:10,640 --> 00:23:12,280
So what do we do? 
Go back to the drawing board. 

437
00:23:12,840 --> 00:23:15,000
And this is where like five 
years ago, I started thinking 

438
00:23:15,000 --> 00:23:18,000
about this very differently than
micro segmentation. 

439
00:23:18,000 --> 00:23:21,640
I thought, all right, what we 
need is an easy entry point for 

440
00:23:21,640 --> 00:23:26,960
customers that reduces the time 
to value from a security 

441
00:23:26,960 --> 00:23:31,120
perspective with minimal impact 
to the operational model. 

442
00:23:32,040 --> 00:23:37,120
So how do I get more bang for my
buck and my time, but without 

443
00:23:37,120 --> 00:23:39,680
significantly overhauling the 
operational model? 

444
00:23:39,680 --> 00:23:43,960
Because no matter how good a 
security technology is, if I 

445
00:23:43,960 --> 00:23:45,720
came to you, you're a customer 
and I come to you and say, hey, 

446
00:23:45,720 --> 00:23:48,960
we've got this whiz bang tool. 
And by the way, if you implement

447
00:23:48,960 --> 00:23:52,160
our tool 2 years from now, 
you'll be really protected. 

448
00:23:52,480 --> 00:23:55,720
And in order to get there, you 
need to hire 50 new people and 

449
00:23:55,720 --> 00:23:57,560
spend thousands of man hours to 
get there. 

450
00:23:57,560 --> 00:24:01,000
You'd be like, all right, done. 
You're not interested in that. 

451
00:24:01,640 --> 00:24:04,360
So I started to look at the way 
that attacks happened. 

452
00:24:04,360 --> 00:24:07,240
You look at the attack chain, 
you'll get the anatomy of an 

453
00:24:07,240 --> 00:24:10,640
attack and you start to reverse 
engineer the things that 

454
00:24:10,640 --> 00:24:14,320
happened during that attack. 
And you you realize there's this

455
00:24:14,360 --> 00:24:17,880
aha moment of, wait a minute, 
these are things we can protect.

456
00:24:18,280 --> 00:24:21,200
These are things that are not 
specific to any particular 

457
00:24:21,200 --> 00:24:23,880
application. 
They're not specific to any 

458
00:24:23,880 --> 00:24:28,920
particular attack or ransomware,
but they are tools that threat 

459
00:24:28,920 --> 00:24:32,320
actors want to use in order to 
find things of value. 

460
00:24:32,840 --> 00:24:36,040
And so we started to make this 
pivot in going into customers 

461
00:24:36,040 --> 00:24:39,320
saying, listen, this is not an 
all or nothing proposition. 

462
00:24:39,360 --> 00:24:42,720
We've got firewall, distributed 
firewall, gateway, firewall, 

463
00:24:42,720 --> 00:24:46,160
security intelligence, IDSIPS, 
network traffic analysis, 

464
00:24:46,320 --> 00:24:48,560
network detection and response, 
malware protection. 

465
00:24:48,680 --> 00:24:52,280
We got this big portfolio of 
security products, which I think

466
00:24:52,280 --> 00:24:55,480
proves we're a security company,
but it can be overwhelming. 

467
00:24:56,040 --> 00:24:57,920
And we say this is not an all or
nothing proposition. 

468
00:24:58,040 --> 00:25:00,200
You can pick and choose the 
pieces you want. 

469
00:25:00,440 --> 00:25:02,920
Well, you know what happens if 
you leave that up to customers. 

470
00:25:03,160 --> 00:25:06,000
If you leave it to customers, 
customers, they're like, I'm not

471
00:25:06,000 --> 00:25:08,200
sure which one. 
So the best thing that we could 

472
00:25:08,200 --> 00:25:10,880
have done, which is what we're 
doing now, is to go to a 

473
00:25:10,880 --> 00:25:12,720
customer and say, look, you can 
pick where you wanna start. 

474
00:25:12,720 --> 00:25:16,680
But if you don't know, then 
here's a prescriptive plan on 

475
00:25:16,680 --> 00:25:21,720
exactly how you can implement V 
defend to buy down risk quickly 

476
00:25:21,720 --> 00:25:25,000
and easily in your environment. 
And here's what each one of 

477
00:25:25,000 --> 00:25:29,440
those stages look like. 
So at this point, you start with

478
00:25:29,920 --> 00:25:33,400
a segmentation assessment. 
What does my current environment

479
00:25:33,400 --> 00:25:35,760
look like? 
Am I protecting anything? 

480
00:25:35,960 --> 00:25:38,240
Totally optional. 
I've got some customers that 

481
00:25:38,240 --> 00:25:40,040
take crisp. 
You could run this assessment. 

482
00:25:40,040 --> 00:25:41,120
It's not going to tell me 
anything. 

483
00:25:41,120 --> 00:25:43,640
I don't know. 
I'm not doing anything, so the 

484
00:25:43,640 --> 00:25:45,320
assessment's going to come back.
I'm going to be terrible. 

485
00:25:45,320 --> 00:25:46,480
I already know it. 
Skip it. 

486
00:25:46,480 --> 00:25:48,920
Let's go to the next step. 
I've got other customers that 

487
00:25:48,920 --> 00:25:51,760
say, well, I'd like to know. 
I'd like to see what my score 

488
00:25:51,760 --> 00:25:53,960
is. 
And then that way after we spend

489
00:25:53,960 --> 00:25:57,600
some time doing some security 
stuff, we can run it again and 

490
00:25:57,600 --> 00:26:00,520
see what the delta is between 
the two times that we run it. 

491
00:26:00,880 --> 00:26:04,040
So step one, let's figure out 
where you're currently at. 

492
00:26:04,240 --> 00:26:07,280
Step 2 then is the anatomy of an
attack. 

493
00:26:07,480 --> 00:26:11,040
How do attackers move? 
They use RDP, they use SMB, they

494
00:26:11,040 --> 00:26:14,080
attack DNS, they attack Active 
Directory, NTP. 

495
00:26:14,240 --> 00:26:17,800
All of these different types of 
protocols and services are high 

496
00:26:17,800 --> 00:26:22,400
value targets in the enterprise.
So as our Step 2, that's what we

497
00:26:22,400 --> 00:26:25,040
target. 
We go in and we say, look, RDP 

498
00:26:25,040 --> 00:26:27,080
is extremely predictable. 
You know where it should come 

499
00:26:27,080 --> 00:26:28,240
from, you know where it should 
go. 

500
00:26:28,560 --> 00:26:31,360
We can protect that. 
DNS, extremely predictable. 

501
00:26:31,360 --> 00:26:34,520
If you're internal, talking to 
an internal DNS sounds good. 

502
00:26:34,640 --> 00:26:37,520
If you're an internal DNS, going
to an external DNS sounds good. 

503
00:26:37,520 --> 00:26:40,400
But if you're an internal client
going to an external DNS, that's

504
00:26:40,400 --> 00:26:42,680
bad. 
We should never let that happen 

505
00:26:43,080 --> 00:26:46,560
so we can easily build policy to
control those types of things. 

506
00:26:47,160 --> 00:26:52,040
Step 3 then is zoning. 
Every customer has prod, test, 

507
00:26:52,040 --> 00:26:55,040
dev, DMZ, staging, whatever 
these different things are. 

508
00:26:55,360 --> 00:26:58,960
But the big problem is they 
understand it from a business 

509
00:26:58,960 --> 00:27:01,280
standpoint, but they don't 
understand how to convert 

510
00:27:01,280 --> 00:27:04,720
business logic into technology. 
And so that's what we did with 

511
00:27:04,720 --> 00:27:06,400
Vdefend. 
Now is you can look at your 

512
00:27:06,400 --> 00:27:09,840
environment and say, hey, all of
this stuff here is prod, we can 

513
00:27:09,840 --> 00:27:14,280
tag it, we can tag DMZ, we can 
tag test dev, and then we build 

514
00:27:14,280 --> 00:27:16,920
simple policies that don't allow
them to communicate. 

515
00:27:17,720 --> 00:27:21,320
The fourth step is applications,
but we're still not at micro seg

516
00:27:21,320 --> 00:27:22,600
yet. 
So look at the difference. 

517
00:27:22,720 --> 00:27:24,840
We jumped in as micro seg 
leading. 

518
00:27:24,960 --> 00:27:27,360
And here I've been talking for 5
minutes and I haven't even got 

519
00:27:27,360 --> 00:27:31,200
to micro seg yet. 
So we've made a complete 180 on 

520
00:27:31,200 --> 00:27:33,520
micro seg. 
Not that it isn't important, but

521
00:27:33,520 --> 00:27:37,480
micro seg is the end state. 
Micro seg is the Nirvana that 

522
00:27:37,480 --> 00:27:42,080
we're trying to reach because it
takes so long for micro 

523
00:27:42,080 --> 00:27:45,080
segmentation to actually buy 
down significant risk in the 

524
00:27:45,080 --> 00:27:48,360
environment. 
So we do our assessment, we do 

525
00:27:48,360 --> 00:27:50,880
our infrastructure, we do our 
zoning, then we might do 

526
00:27:50,880 --> 00:27:54,680
application macro segmentation. 
So I'm not worried about within 

527
00:27:54,680 --> 00:27:57,160
an app, how are things 
communicating, but app A should 

528
00:27:57,160 --> 00:28:01,880
not talk to App B, but I do 
those things and then now I 

529
00:28:01,880 --> 00:28:03,640
might be ready for micro 
segmentation. 

530
00:28:03,640 --> 00:28:07,560
So we expect that customers are 
going to take this journey down 

531
00:28:07,560 --> 00:28:10,800
this path of security. 
And by the way, if a customer 

532
00:28:10,800 --> 00:28:15,200
says I'm going to stop at 
zoning, fine, stop at zoning. 

533
00:28:15,760 --> 00:28:19,040
We just want you to have this 
this tool in your tool belt that

534
00:28:19,040 --> 00:28:22,000
is purpose built for your 
private cloud, which by the way 

535
00:28:22,040 --> 00:28:26,080
scales linearly across your 
entire data center along with 

536
00:28:26,080 --> 00:28:29,560
your compute infrastructure. 
And if you decide later on you 

537
00:28:29,560 --> 00:28:32,400
want to add more than you add 
more, go down that path. 

538
00:28:32,400 --> 00:28:36,440
But yeah, it's interesting to 
hear micro segmentation now 

539
00:28:36,800 --> 00:28:41,280
because five years ago or six 
years ago, seven years ago, it 

540
00:28:41,280 --> 00:28:45,960
was all we wanted to talk about.
We just micro seg was that 

541
00:28:45,960 --> 00:28:48,920
buzzword and it would probably 
be said 40 times in anyone 

542
00:28:48,920 --> 00:28:51,200
presentation. 
Now I go talk to a customer. 

543
00:28:51,200 --> 00:28:53,560
It might be said twice. 
And it's one of those things 

544
00:28:53,560 --> 00:28:55,320
that we've seen that with 
virtualization as well, and 

545
00:28:55,320 --> 00:28:56,600
they've seen the same thing with
storage. 

546
00:28:56,920 --> 00:28:59,920
These conversations, you know, 
the result of those 

547
00:28:59,920 --> 00:29:02,600
conversations typically depend 
on the maturity level of the 

548
00:29:02,600 --> 00:29:06,320
customer and not necessarily 
meaning maturity itself, but 

549
00:29:06,320 --> 00:29:09,280
more, you know, how much 
knowledge do they actually have 

550
00:29:09,280 --> 00:29:11,800
of their estate? 
And as you said, it's extremely 

551
00:29:11,800 --> 00:29:13,320
complex. 
Most customers don't know what 

552
00:29:13,320 --> 00:29:15,680
talks to what. 
So it's very difficult for them 

553
00:29:15,680 --> 00:29:18,440
to actually implement that. 
Now, what stood out to me 

554
00:29:18,440 --> 00:29:21,280
though, and that's probably a 
question I should ask, is 

555
00:29:21,440 --> 00:29:23,600
because I'm the, you know, 
advocate of the devil as well 

556
00:29:23,600 --> 00:29:26,560
here, of course, you know, 
acting on behalf of the 

557
00:29:26,560 --> 00:29:29,920
listeners. 
If I listen to some of the 

558
00:29:29,920 --> 00:29:32,800
things that you've shared now 
and mentioned in terms of, you 

559
00:29:32,800 --> 00:29:35,800
know, the firewalling 
capabilities, etcetera, I can 

560
00:29:35,800 --> 00:29:38,680
also imagine that some of our 
competitors could do similar 

561
00:29:38,680 --> 00:29:41,480
things. 
So what is unique about V defen 

562
00:29:41,480 --> 00:29:42,880
compared to some of our 
competitors? 

563
00:29:42,880 --> 00:29:45,480
I'm not asking you to test the 
competitors of course, but you 

564
00:29:45,480 --> 00:29:49,160
know, maybe you can, you know, 
focus a bit on what we bring to 

565
00:29:49,160 --> 00:29:51,000
the table compared to other 
solutions. 

566
00:29:51,320 --> 00:29:54,200
Well, I mean, look, this is 
something that comes up every 

567
00:29:54,200 --> 00:29:56,280
customer meeting, right? 
I mean, everybody's looking, 

568
00:29:56,280 --> 00:29:57,920
everybody knows security is 
important. 

569
00:29:58,000 --> 00:30:00,120
Everybody's looking to solve a 
problem. 

570
00:30:01,840 --> 00:30:05,320
I would say this when it comes 
to, let me just say, for 

571
00:30:05,320 --> 00:30:07,240
firewalling to start, right, 
because there's a lot of 

572
00:30:07,240 --> 00:30:08,920
firewall vendors, a lot of 
different tools. 

573
00:30:09,720 --> 00:30:13,920
From a firewalling perspective, 
you have three options. 

574
00:30:14,400 --> 00:30:18,160
One is to install an agent 
inside of every workload that 

575
00:30:18,160 --> 00:30:22,800
you have Now, obviously agents 
adding more and more agents into

576
00:30:22,800 --> 00:30:25,160
an operating system. 
At some point there could be 

577
00:30:25,160 --> 00:30:27,560
agents that conflict and now you
have a problem. 

578
00:30:28,280 --> 00:30:31,280
I mean, we saw what happened 
with an agent last year, right, 

579
00:30:31,280 --> 00:30:34,480
where something took down a 
whole lot of infrastructure 

580
00:30:34,680 --> 00:30:38,000
because of the agent. 
But I think for me the biggest 

581
00:30:38,000 --> 00:30:43,720
issue with the agent is that if 
an attacker is able to get into 

582
00:30:43,720 --> 00:30:48,360
a system and has the appropriate
credentials, they can turn off 

583
00:30:48,360 --> 00:30:51,280
the agent, at which point 
security is gone. 

584
00:30:51,920 --> 00:30:56,200
So the agent architecture has 
vulnerabilities from that sense.

585
00:30:56,680 --> 00:30:59,280
The other way to solve the 
problem is you go below the 

586
00:30:59,280 --> 00:31:01,600
hypervisor and you go into the 
physical network. 

587
00:31:01,600 --> 00:31:05,080
Of course, the problem with the 
physical network is it lacks the

588
00:31:05,080 --> 00:31:08,280
rich contextual understanding of
what applications are doing. 

589
00:31:08,680 --> 00:31:13,560
Everything is IP port source, IP
destination port protocol. 

590
00:31:13,640 --> 00:31:16,480
So we're very limited in the way
that we can manage that. 

591
00:31:16,680 --> 00:31:18,600
And it doesn't scale for a few 
reasons. 

592
00:31:18,600 --> 00:31:22,560
Number one, if I'm trying to get
security across a broad set of 

593
00:31:22,560 --> 00:31:26,120
my infrastructure, I'm now 
adding the complexity of trying 

594
00:31:26,120 --> 00:31:29,200
to reroute my traffic to make 
sure it goes over this 

595
00:31:29,200 --> 00:31:33,880
particular security device. 
So the agent is is too high in 

596
00:31:33,880 --> 00:31:38,320
the stack, the physical firewall
is too low in the stack. 

597
00:31:38,560 --> 00:31:41,880
Well, what's in between the 
agent and the physical is the 

598
00:31:41,880 --> 00:31:45,000
hypervisor. 
So this is and always will be 

599
00:31:45,000 --> 00:31:48,240
our competitive advantage. 
We are in a spot that makes 

600
00:31:48,240 --> 00:31:53,440
security not only extremely 
efficient, but easier to manage 

601
00:31:53,440 --> 00:31:58,360
at scale because we have the 
isolation that separates us from

602
00:31:58,360 --> 00:32:01,680
the operating system. 
If, if, if an attacker gets into

603
00:32:01,680 --> 00:32:05,960
a guest OS, they can't disable 
the V defend firewall because 

604
00:32:05,960 --> 00:32:09,720
it's outside of the guest OS. 
But at the same time, we have a 

605
00:32:09,720 --> 00:32:12,560
much richer contextual 
understanding of the application

606
00:32:12,560 --> 00:32:16,840
because we're in the hypervisor.
So what we've been able to build

607
00:32:17,040 --> 00:32:20,000
taking advantage of our space in
the hypervisor, but also from a 

608
00:32:20,000 --> 00:32:23,920
management plane perspective, I 
would go toe to toe with any 

609
00:32:23,920 --> 00:32:27,320
vendor from a scale perspective.
Because when you think about it,

610
00:32:27,360 --> 00:32:29,680
then it, look, anybody that's 
been in vsphere for a long time 

611
00:32:29,680 --> 00:32:34,760
understands every time you add a
new unit of growth into your 

612
00:32:34,760 --> 00:32:38,480
data center, whether it's one 
server or a new cluster or an 

613
00:32:38,480 --> 00:32:41,160
entire rack, whatever your unit 
of growth is, right. 

614
00:32:41,280 --> 00:32:43,760
Oh, we hit this certain level. 
We need to buy more, whatever 

615
00:32:43,760 --> 00:32:47,720
that unit is that you buy more 
of at this point when you're 

616
00:32:47,720 --> 00:32:52,680
buying in to our private cloud 
story, that unit of growth is no

617
00:32:52,680 --> 00:32:54,840
longer just additional CPU in 
memory. 

618
00:32:55,880 --> 00:33:00,200
That unit of growth is CPU, 
memory, networking, storage, 

619
00:33:00,280 --> 00:33:05,680
firewall, IDSIPSNDRNTA it, it's 
all in the hypervisor. 

620
00:33:06,120 --> 00:33:10,120
So the gone are the days and you
know, it sounds like a good 

621
00:33:10,120 --> 00:33:13,560
thing, maybe not for, you know, 
architects, but gone are the 

622
00:33:13,560 --> 00:33:16,640
days where the complexity of the
physical network is something I 

623
00:33:16,640 --> 00:33:19,680
have to contend with because I'm
not trying to figure out how 

624
00:33:19,680 --> 00:33:22,840
many firewalls do I need to buy 
and how big do they need to be 

625
00:33:23,000 --> 00:33:25,840
and how much oversubscription is
there and how much throughput do

626
00:33:25,840 --> 00:33:28,120
I have the ability to grow into?
And when am I going to need a 

627
00:33:28,120 --> 00:33:29,760
new one? 
And hey, if I need a new one, is

628
00:33:29,800 --> 00:33:32,000
it even going to be available? 
Is it going to take me 8 months 

629
00:33:32,000 --> 00:33:34,800
to get? 
We eliminate all of that simply 

630
00:33:34,800 --> 00:33:38,320
because of our architecture. 
And when you add the management 

631
00:33:38,320 --> 00:33:42,480
plan in, the ability for us to 
step away from building policy 

632
00:33:42,480 --> 00:33:47,560
based on IP and now being able 
to use tags and groups or even 

633
00:33:47,560 --> 00:33:49,240
operating system. 
I mean this is one that 

634
00:33:49,240 --> 00:33:52,640
customers go crazy over because 
every customer has legacy 

635
00:33:52,640 --> 00:33:56,040
operating systems. 
But because we are so integrated

636
00:33:56,040 --> 00:33:59,560
into V Center, as you know, we 
already know the operating 

637
00:33:59,560 --> 00:34:02,320
system. 
So we don't have to go figure it

638
00:34:02,320 --> 00:34:03,520
out. 
Customers don't have to go 

639
00:34:03,520 --> 00:34:06,120
figure it out. 
Because of that integration, I 

640
00:34:06,120 --> 00:34:09,600
can build a security group that 
says where operating system 

641
00:34:09,639 --> 00:34:12,440
equals and it dynamically 
populates. 

642
00:34:12,440 --> 00:34:14,719
And now I can build policy and 
if somebody updates the 

643
00:34:14,719 --> 00:34:17,679
operating system and it steps 
outside of what we define, then 

644
00:34:17,679 --> 00:34:18,840
boom, security is gone. 
I'm done. 

645
00:34:18,840 --> 00:34:22,159
I don't have to touch it again. 
So the the operational model of 

646
00:34:22,159 --> 00:34:26,280
what we're providing is unlike 
any other security that can be 

647
00:34:26,280 --> 00:34:29,040
implemented out there. 
So to answer your question, I 

648
00:34:29,040 --> 00:34:30,760
think what we have unique is 2 
things. 

649
00:34:30,960 --> 00:34:34,600
One is our architecture being in
the hypervisor and two is the 

650
00:34:34,600 --> 00:34:37,120
management plan. 
Nobody can do the things that we

651
00:34:37,120 --> 00:34:40,719
do at the scale that we can do. 
You mentioned that it would make

652
00:34:40,719 --> 00:34:43,639
life easier for architects and 
of course from an operational 

653
00:34:43,639 --> 00:34:46,000
perspective as well, but there 
are still some decisions to be 

654
00:34:46,000 --> 00:34:47,920
made, right? 
When I was watching your session

655
00:34:47,920 --> 00:34:50,760
and I was reading some of the 
documentation and the blog post,

656
00:34:51,000 --> 00:34:52,760
one of the things that stood out
to me is that there are 

657
00:34:52,760 --> 00:34:56,320
different types of firewalls 
that we have part of the system.

658
00:34:56,320 --> 00:34:59,800
So there's a gateway firewall, 
there's a distributed firewall. 

659
00:34:59,800 --> 00:35:02,920
Now, I got kind of confused 
fairly fast, so it's probably 

660
00:35:02,920 --> 00:35:05,840
good for you to explain it to me
and probably for the listen 

661
00:35:05,840 --> 00:35:08,480
listeners as well, what those 
things are and when you would 

662
00:35:08,480 --> 00:35:11,440
use either of the two. 
Because, you know, I was kind of

663
00:35:11,440 --> 00:35:13,880
lost within within two minutes. 
I'm not a networking guy, so 

664
00:35:13,880 --> 00:35:16,400
sorry about that. 
So no, it's a great question and

665
00:35:16,400 --> 00:35:19,240
there's actually 1/3 option too.
Here's the interesting piece. 

666
00:35:19,760 --> 00:35:22,840
When we, when we go out talking 
to customers and and look, most 

667
00:35:22,840 --> 00:35:24,800
of our customers are very 
heavily invested in 

668
00:35:24,800 --> 00:35:26,760
virtualization. 
That's just the nature of who we

669
00:35:26,760 --> 00:35:29,840
meet, that's who we talk to. 
But there are still customers 

670
00:35:29,840 --> 00:35:32,280
out there that say, hey, I'm 
only 70% virtualized. 

671
00:35:32,520 --> 00:35:35,720
I still have 30% that's not 
virtualized. 

672
00:35:36,320 --> 00:35:39,760
So customers would inevitably 
ask if I do this firewall thing 

673
00:35:39,760 --> 00:35:43,640
that's in the hypervisor, what 
about my other stuff? 

674
00:35:43,920 --> 00:35:46,000
What about the things that are 
not virtualized? 

675
00:35:46,560 --> 00:35:49,240
So at that point we realized, 
well, we're leaving stuff on the

676
00:35:49,240 --> 00:35:53,080
table here, number one. 
Number two, we're putting our 

677
00:35:53,080 --> 00:35:57,360
customers in a position where we
can't solve the security problem

678
00:35:57,360 --> 00:36:00,520
for them because they still have
a portion of the estate that is 

679
00:36:00,520 --> 00:36:04,120
not running on our hypervisor. 
So the distributed firewall is 

680
00:36:04,120 --> 00:36:07,000
and always will be the most 
efficient, most scalable 

681
00:36:07,000 --> 00:36:08,840
architecture from a security 
perspective. 

682
00:36:09,720 --> 00:36:14,880
However, if a customer still has
physical assets running on Vlans

683
00:36:15,200 --> 00:36:19,760
that are not on a hypervisor, 
the gateway firewall is our 

684
00:36:19,760 --> 00:36:22,560
instantiation of an appliance 
based firewall. 

685
00:36:23,120 --> 00:36:26,240
So it can be deployed as a 
virtual machine or it can be 

686
00:36:26,240 --> 00:36:29,520
deployed as a physical machine. 
So you think about customers as 

687
00:36:29,520 --> 00:36:33,280
Oh well, I've got, you know, 
vendor X is my physical firewall

688
00:36:33,280 --> 00:36:36,720
down here and I'm controlling 
traffic between my V Lans. 

689
00:36:37,040 --> 00:36:40,400
Well, as part of the V defend 
vendor X can go away. 

690
00:36:40,600 --> 00:36:43,880
The gateway firewall can slide 
in and now you have one single 

691
00:36:43,880 --> 00:36:46,840
management plane to control all 
traffic within your private 

692
00:36:46,840 --> 00:36:48,520
cloud. 
Now this is not to get, I just 

693
00:36:48,520 --> 00:36:50,800
want to be clear. 
This is not to get rid of the 

694
00:36:50,800 --> 00:36:55,080
north-south boundary that is 
there into and out of the data 

695
00:36:55,080 --> 00:36:57,480
center. 
I would expect every customer 

696
00:36:57,480 --> 00:36:59,640
wants to have a multi IT vendor 
strategy. 

697
00:36:59,880 --> 00:37:03,240
So it whatever your vendor is 
protecting the data center, you 

698
00:37:03,240 --> 00:37:06,160
lead that. 
But inside the data center if 

699
00:37:06,160 --> 00:37:09,680
you want one single management 
plane, then the gateway firewall

700
00:37:09,680 --> 00:37:12,400
can handle those non virtualized
workloads. 

701
00:37:13,000 --> 00:37:15,880
The third option is we actually 
make agents. 

702
00:37:16,120 --> 00:37:18,720
So I know it might be a little 
hypocritical here because I was 

703
00:37:18,920 --> 00:37:21,560
just saying agents aren't great,
but sometimes we don't have a 

704
00:37:21,560 --> 00:37:24,600
choice but to put an agent. 
Now our agent does work 

705
00:37:24,600 --> 00:37:27,320
differently. 
So I've seen various competitors

706
00:37:27,320 --> 00:37:31,480
where the agent actually 
manipulates the Windows firewall

707
00:37:32,000 --> 00:37:35,240
or the agent manipulates the 
Linux IP tables. 

708
00:37:35,520 --> 00:37:38,280
The the fire, the Windows 
firewall one is interesting to 

709
00:37:38,280 --> 00:37:40,200
me. 
I don't know how much Windows 

710
00:37:40,280 --> 00:37:43,080
experience you've had managing, 
but you know, back in Windows 

711
00:37:43,080 --> 00:37:48,160
2000, this thing called group 
policy, you could manage the 

712
00:37:48,160 --> 00:37:50,600
Windows firewall using Group 
policy. 

713
00:37:51,880 --> 00:37:55,880
Nobody did it, but you could. 
So now there's actually vendors 

714
00:37:55,880 --> 00:37:59,680
who build an agent to be able to
manage the Windows firewall. 

715
00:38:00,280 --> 00:38:02,320
Why? 
Why would I need an AI could do 

716
00:38:02,320 --> 00:38:04,640
it in Group policy? 
It's weird to me to do that. 

717
00:38:04,640 --> 00:38:07,320
But look, sometimes it's, it's, 
that's the only architecture we 

718
00:38:07,320 --> 00:38:08,880
have now, our agents a little 
different. 

719
00:38:09,080 --> 00:38:10,600
We're not managing the Windows 
firewall. 

720
00:38:10,600 --> 00:38:12,400
We're not managing Linux IP 
tables. 

721
00:38:12,520 --> 00:38:15,640
We have a different architecture
that allows us to still consume 

722
00:38:15,880 --> 00:38:18,760
tags and groups and the things 
that we have in our management 

723
00:38:18,760 --> 00:38:21,320
plane because otherwise it 
really wouldn't scale. 

724
00:38:21,320 --> 00:38:23,440
It wouldn't scale if we said, 
hey, we got all this great stuff

725
00:38:23,440 --> 00:38:26,160
up here that you can use, but by
the way, on your physical you 

726
00:38:26,160 --> 00:38:28,360
have to treat it and just do IP 
addresses again. 

727
00:38:28,680 --> 00:38:33,240
So the architecture of the DFW, 
like I said it's the best one to

728
00:38:33,240 --> 00:38:37,520
have, but gateway firewall does 
serve a need for customers that 

729
00:38:37,520 --> 00:38:39,920
have non virtualized workloads 
as well as the agents. 

730
00:38:40,360 --> 00:38:41,360
Hopefully that cleared up for 
you. 

731
00:38:41,520 --> 00:38:44,440
Yeah, no, that clears it up. 
And I, I'm kind of shocked that 

732
00:38:44,440 --> 00:38:46,280
we also do the the physical 
component. 

733
00:38:46,280 --> 00:38:48,440
But I, you know, I think it 
makes a lot of sense. 

734
00:38:48,440 --> 00:38:51,520
As you said, it helps you 
creating a solution which can be

735
00:38:51,520 --> 00:38:53,600
managed from a single control 
plane. 

736
00:38:53,600 --> 00:38:56,040
So I think that is, that is 
fantastic. 

737
00:38:56,520 --> 00:39:00,120
Now the other thing that we also
have as part of the, the, the V 

738
00:39:00,120 --> 00:39:02,840
defense solution is advanced 
threat protection. 

739
00:39:03,240 --> 00:39:06,560
And it's one of those solutions 
that got me very excited. 

740
00:39:06,560 --> 00:39:10,200
I've been talking a lot lately 
about ransomware recovery, but 

741
00:39:10,200 --> 00:39:13,120
of course there is no recovery 
if there is no breach. 

742
00:39:13,520 --> 00:39:15,880
And that's what ATP comes into 
play, right? 

743
00:39:15,880 --> 00:39:19,680
So it's probably also good to 
explain what ATP is and, and, 

744
00:39:20,000 --> 00:39:22,720
and how it relates to the actual
firewall offering itself. 

745
00:39:22,720 --> 00:39:26,120
Because I think it's one of 
those things that although you 

746
00:39:26,120 --> 00:39:30,040
probably talk a lot about it, 
somehow it doesn't pop up in a 

747
00:39:30,040 --> 00:39:32,080
lot of conversations. 
And I think that's a shame. 

748
00:39:32,080 --> 00:39:34,120
So, you know, please shine the 
light on it. 

749
00:39:34,760 --> 00:39:36,560
Yeah. 
And look, there's a reason for 

750
00:39:36,560 --> 00:39:38,840
that there. 
There's a natural evolution from

751
00:39:38,840 --> 00:39:41,320
a security perspective that a 
customer is going to have to go 

752
00:39:41,320 --> 00:39:45,480
through trying to push all of 
this at one time. 

753
00:39:45,480 --> 00:39:47,720
Like I said, it's really 
overwhelming for customers. 

754
00:39:48,080 --> 00:39:51,960
But let's let's start with first
of all, ATP, OK? 

755
00:39:52,000 --> 00:39:56,560
Or what we formally called ATP, 
it's actually all in one SKU 

756
00:39:56,560 --> 00:39:58,600
now. 
So V Defend is V Defend, you get

757
00:39:58,600 --> 00:40:00,320
everything. 
We used to have AV Defend 

758
00:40:00,320 --> 00:40:03,080
firewall SKU and we had AV 
Defend ATP SKU. 

759
00:40:03,080 --> 00:40:06,000
It's two different things. 
So you could buy the firewall or

760
00:40:06,000 --> 00:40:08,760
you could buy firewall and ATP. 
Now it's just all one. 

761
00:40:09,080 --> 00:40:12,640
So when you buy V Defend, you 
get everything inside of there. 

762
00:40:12,960 --> 00:40:18,480
So the firewalls and the 
security intelligence tool. 

763
00:40:19,440 --> 00:40:22,280
Built into the hypervisor. 
Like we talked about, the ATP 

764
00:40:22,280 --> 00:40:26,680
portion starts with IDSIPS. 
So just like we have firewall 

765
00:40:26,680 --> 00:40:30,000
built into the hypervisor, 
right, stateful L4 through L7 

766
00:40:30,000 --> 00:40:33,240
firewall, IDSIPS built into the 
hypervisor. 

767
00:40:33,240 --> 00:40:38,480
So in real time, we have the 
ability to inspect traffic flows

768
00:40:38,760 --> 00:40:41,720
against known bad traffic 
patterns. 

769
00:40:43,040 --> 00:40:45,880
If there's a vulnerability and 
there's a signature for that 

770
00:40:45,880 --> 00:40:48,200
vulnerability, we can stop that 
from happening. 

771
00:40:48,680 --> 00:40:51,800
And again, our management plan 
allows us to curate these 

772
00:40:51,800 --> 00:40:55,280
signatures because I might only 
want the most severe, right? 

773
00:40:55,280 --> 00:40:58,400
I don't want the little, I just 
want the most severe or I want 

774
00:40:58,400 --> 00:41:01,320
specific things on specific 
virtual machines. 

775
00:41:01,520 --> 00:41:04,400
So it's all policy driven. 
This is not something carte 

776
00:41:04,400 --> 00:41:06,800
Blanche has turned on across the
entire infrastructure. 

777
00:41:07,000 --> 00:41:10,160
This is defense in depth. 
This is I've whitelisted the 

778
00:41:10,160 --> 00:41:12,960
things that I want in my 
environment and now I want to 

779
00:41:12,960 --> 00:41:15,320
check against known bad 
signatures. 

780
00:41:15,800 --> 00:41:18,200
So the IDSIPS allows us to do 
that. 

781
00:41:18,320 --> 00:41:21,000
And it's extremely powerful in 
the sense that again, it's 

782
00:41:21,000 --> 00:41:23,680
happening in real time in the 
hypervisor. 

783
00:41:23,680 --> 00:41:27,240
We are not hairpinning this 
traffic to some third party 

784
00:41:27,240 --> 00:41:29,120
device. 
We don't have to do spans and 

785
00:41:29,120 --> 00:41:30,440
taps and all these different 
things. 

786
00:41:30,640 --> 00:41:32,560
It's right there in the 
hypervisor. 

787
00:41:32,560 --> 00:41:34,760
So back to our unique 
architecture. 

788
00:41:35,640 --> 00:41:40,200
The other parts of ATP is, is 
network traffic Analysis or MTA.

789
00:41:40,960 --> 00:41:45,560
If you think about this V Defend
has a, a data collection engine 

790
00:41:45,560 --> 00:41:47,320
called Security Services 
Platform. 

791
00:41:47,320 --> 00:41:51,840
SSP, it had a previous name. 
It was a little difficult for 

792
00:41:51,840 --> 00:41:55,720
us, but now SSP, this is no 
small entity. 

793
00:41:55,720 --> 00:41:59,560
We're like 96 VCPUS and 
terabytes of memory across a 

794
00:41:59,560 --> 00:42:03,120
containerized platform. 
But the value in this is in the 

795
00:42:03,120 --> 00:42:07,160
data that we collect and the 
information that we provide back

796
00:42:07,520 --> 00:42:10,800
to our customers. 
So SSP is picking up all the 

797
00:42:10,800 --> 00:42:13,280
flows. 
I had an EBC with a large credit

798
00:42:13,280 --> 00:42:15,120
card company and they want 
everything. 

799
00:42:15,120 --> 00:42:16,960
They want to know everything 
about the environment. 

800
00:42:17,080 --> 00:42:21,040
That's what SSP is doing. 
It's every flow in your private 

801
00:42:21,040 --> 00:42:22,920
cloud. 
Now what do we do with that? 

802
00:42:22,920 --> 00:42:26,960
We apply machine learning to it 
so that we can identify are 

803
00:42:26,960 --> 00:42:30,040
there anomalies in the traffic 
patterns. 

804
00:42:30,280 --> 00:42:34,560
So imagine I've got thirty 6090 
days worth of traffic and all of

805
00:42:34,560 --> 00:42:37,240
a sudden 2 virtual machines that
have never talked to each other 

806
00:42:37,240 --> 00:42:39,840
before are all of a sudden 
talking to each other. 

807
00:42:40,400 --> 00:42:42,960
Is that good or bad? 
I don't know, but I might want 

808
00:42:42,960 --> 00:42:45,440
to know it. 
I might want to know that this 

809
00:42:45,440 --> 00:42:49,480
new form of communication or 
this new flow is happening in my

810
00:42:49,480 --> 00:42:52,320
environment. 
So the machine learning aspect 

811
00:42:52,320 --> 00:42:56,640
of SSP and MTA is to pick up 
that we haven't seen this 

812
00:42:56,640 --> 00:42:58,640
before. 
You might want to go take a look

813
00:42:58,640 --> 00:43:00,880
at it. 
And security people love this 

814
00:43:01,040 --> 00:43:04,360
because they love information, 
they love data. 

815
00:43:04,720 --> 00:43:09,000
Now they don't like false 
positives, but they like data. 

816
00:43:09,520 --> 00:43:12,360
So NTA is going to give that. 
Now, realistically, if I'm a 

817
00:43:12,360 --> 00:43:14,960
security person, yeah, that's 
great that you told me about an 

818
00:43:14,960 --> 00:43:18,120
anomaly, but I actually want to 
know if it's good or bad. 

819
00:43:18,720 --> 00:43:22,240
I actually want to know, is this
just a random flow or is this 

820
00:43:22,240 --> 00:43:25,160
part of an attack chain? 
Now that's where we get to 

821
00:43:25,160 --> 00:43:28,600
network detection and response. 
So another part of V Defend in 

822
00:43:28,600 --> 00:43:33,040
in the ATP suite of things is 
network detection and response. 

823
00:43:33,280 --> 00:43:35,920
So you mentioned recovery and 
this is where I think that the 

824
00:43:36,000 --> 00:43:41,400
NDR feature of V Defend coupled 
with something like the live 

825
00:43:41,400 --> 00:43:46,280
recovery feature inside of ACC, 
these two are meant to be 

826
00:43:46,280 --> 00:43:47,960
together. 
There's no question about it. 

827
00:43:47,960 --> 00:43:51,240
And I hope in the future that we
start to find ways to actually 

828
00:43:51,400 --> 00:43:53,680
engineer these things together. 
But think about it this way. 

829
00:43:54,240 --> 00:43:58,760
NDR is looking at all these 
flows in SSP, and if there's an 

830
00:43:58,760 --> 00:44:03,720
attack that happens, the NDR 
engine, the machine learning, 

831
00:44:03,720 --> 00:44:07,840
the AI that's built into SSP is 
going to recognize that these 

832
00:44:07,840 --> 00:44:11,080
aren't random flows. 
These are flows that correlate 

833
00:44:11,080 --> 00:44:13,280
together as part of an attack 
campaign. 

834
00:44:13,680 --> 00:44:16,000
So if you think through the way 
an attack happens, there's 

835
00:44:16,000 --> 00:44:20,440
infiltration and then there's 
command and control, then 

836
00:44:20,440 --> 00:44:23,040
there's lateral movement, then 
there's command and control, 

837
00:44:23,040 --> 00:44:26,080
then there's lateral movement, 
then there's X filtration, then 

838
00:44:26,080 --> 00:44:29,160
there's ransomware. 
So I mean only a couple of VMS. 

839
00:44:29,160 --> 00:44:32,240
But look, most attacks, they 
really only have 3 or 4 hops. 

840
00:44:32,560 --> 00:44:34,800
Attackers are smart. 
They don't have to go to 

841
00:44:34,800 --> 00:44:37,120
hundreds of places to find 
something of value. 

842
00:44:37,560 --> 00:44:40,720
So when that infiltration 
command and control lateral 

843
00:44:40,720 --> 00:44:43,960
movement command, when that's 
happening, SSP is looking at 

844
00:44:43,960 --> 00:44:46,960
these flows saying, hey, this is
actually an attack. 

845
00:44:47,240 --> 00:44:49,520
And it puts it together, Duncan,
I'm not kidding. 

846
00:44:49,680 --> 00:44:52,200
It puts it together in this 
beautiful timeline. 

847
00:44:52,720 --> 00:44:57,240
You see exactly what get hacked,
What was the attack? 

848
00:44:57,520 --> 00:44:59,640
What was the severity of the 
attack? 

849
00:44:59,880 --> 00:45:02,520
And to me, most importantly, 
when did it happen? 

850
00:45:03,000 --> 00:45:06,520
What time did it happen? 
So if you're a customer and 

851
00:45:06,520 --> 00:45:09,360
you're trying to figure out how 
to build, let's say ransomware 

852
00:45:09,360 --> 00:45:13,280
recovery runbooks and VM Ware 
comes in and says, hey, we've 

853
00:45:13,280 --> 00:45:16,800
got this ACC tool and it's got 
VLR and it builds a clean room 

854
00:45:16,800 --> 00:45:19,320
and it can do all this stuff and
you just push a button and it 

855
00:45:19,320 --> 00:45:21,600
does the restore. 
That's all great. 

856
00:45:21,920 --> 00:45:25,280
But if I don't have the 
understanding of what happened 

857
00:45:25,280 --> 00:45:28,800
in the attack, then what does 
that recovery look like? 

858
00:45:29,320 --> 00:45:33,720
Well, I've got to restore AVM, 
wait till it's done, go into the

859
00:45:33,720 --> 00:45:37,520
VM, see if there's any bad stuff
in there, and if there is, 

860
00:45:37,760 --> 00:45:39,440
delete that one and go to the 
next one. 

861
00:45:39,440 --> 00:45:42,160
And then go look at it. 
And it really I'm going to 

862
00:45:42,160 --> 00:45:43,880
iterate through every possible 
thing. 

863
00:45:43,880 --> 00:45:46,640
Because remember, if there's an 
attack and I just mentioned 4 

864
00:45:46,640 --> 00:45:50,200
VMS or three VMS, if there's an 
attack and I don't know which 

865
00:45:50,200 --> 00:45:52,880
ones, you're going to have to 
check everything because you 

866
00:45:52,880 --> 00:45:55,240
can't just restore the one that 
had the ransomware. 

867
00:45:55,520 --> 00:45:58,960
If the attacker is still in the 
network with command and control

868
00:45:58,960 --> 00:46:00,760
software, you're going to 
restore it. 

869
00:46:00,760 --> 00:46:05,000
What's he going to do, go right 
back and and ransom it again? 

870
00:46:05,160 --> 00:46:07,040
So we have to clean the entire 
thing. 

871
00:46:07,040 --> 00:46:10,440
We need the attack chain. 
So when I take that, that rich 

872
00:46:10,440 --> 00:46:14,480
data that I get with NDR and I 
know who and when I can take 

873
00:46:14,480 --> 00:46:20,000
that into my VLR and say, OK, I 
need VM9 and VM9 was compromised

874
00:46:20,000 --> 00:46:23,480
at 1:55 PM on February 2nd. 
All right, what's the backup I 

875
00:46:23,480 --> 00:46:25,280
have before it? 
I'll take that one. 

876
00:46:25,560 --> 00:46:29,120
And it was VM7 and VM7 was 
compromised at this day and this

877
00:46:29,120 --> 00:46:30,480
time, OK, I'll take the one 
before it. 

878
00:46:30,600 --> 00:46:36,000
So my mean time to recover is 
drastically reduced for two 

879
00:46:36,000 --> 00:46:39,440
reasons. 
One, the power of VLR being able

880
00:46:39,440 --> 00:46:42,360
to restore into that clean room 
and having the snapshots that I 

881
00:46:42,360 --> 00:46:44,840
need. 
And two, is the understanding of

882
00:46:44,840 --> 00:46:47,440
what exactly happened in the 
attack because of NDR. 

883
00:46:48,240 --> 00:46:51,840
It's it's a beautiful story. 
Yeah, I think it's a fantastic 

884
00:46:51,840 --> 00:46:56,040
story and actually just recorded
the demo for the upcoming VMA 

885
00:46:56,040 --> 00:46:58,400
Connect in Amsterdam. 
But I'm actually showing VLR 

886
00:46:58,400 --> 00:47:01,000
with ransomware recovery and I'm
actually going to go through the

887
00:47:01,000 --> 00:47:04,200
whole workflow and show you 
virtual machines that were 

888
00:47:04,200 --> 00:47:08,720
exposed to the Internet and of 
course, they got encrypted as a 

889
00:47:08,720 --> 00:47:10,680
result. 
And I'll show you how to recover

890
00:47:10,680 --> 00:47:13,000
from that as well. 
And, and look, VLR is great 

891
00:47:13,000 --> 00:47:15,520
because you know, it's got the 
tools to be able to show you 

892
00:47:15,520 --> 00:47:17,240
when the ransomware event 
happened. 

893
00:47:17,760 --> 00:47:22,040
The piece that's missing is what
are the other nine VMS that it 

894
00:47:22,040 --> 00:47:24,560
wasn't a ransomware event, It 
was just command and control. 

895
00:47:24,560 --> 00:47:26,520
Just command. 
That's why you have to have the 

896
00:47:26,520 --> 00:47:29,600
two of them together. 
You, you need that understanding

897
00:47:29,600 --> 00:47:31,040
of everything. 
So it's really cool. 

898
00:47:31,240 --> 00:47:33,480
Yeah, I think the the way they 
explained and especially with 

899
00:47:33,480 --> 00:47:35,560
the correlation, I think that is
really important. 

900
00:47:35,560 --> 00:47:37,600
And I'm going to show that of 
course in the demo. 

901
00:47:37,600 --> 00:47:41,000
But I've said that that explorer
as well, if you look at VLR, it 

902
00:47:41,000 --> 00:47:43,800
provides the ability to show 
you, you know, the, the, the 

903
00:47:43,800 --> 00:47:46,440
change rate that happened and 
the entropy, so the randomness 

904
00:47:46,440 --> 00:47:49,080
of the data. 
But there is not a guarantee 

905
00:47:49,080 --> 00:47:51,480
that that was the actual point 
in time that you were 

906
00:47:51,480 --> 00:47:53,080
compromised. 
You still got to restore. 

907
00:47:53,200 --> 00:47:56,640
Look at it and check it and make
sure that yeah, that's why they 

908
00:47:56,680 --> 00:47:58,400
have to be. 
Guessing in some sort of way 

909
00:47:58,400 --> 00:48:02,000
based on what we see from a data
point of view, but not what is 

910
00:48:02,000 --> 00:48:04,000
actually happening from a 
networking stream point. 

911
00:48:04,000 --> 00:48:08,360
So I think this is a fantastic 
story end to end. 

912
00:48:08,840 --> 00:48:13,000
Now, of course when I listen to 
this as a as a storage geek, one

913
00:48:13,000 --> 00:48:15,920
of the things that immediately 
pops up because we're talking 

914
00:48:15,920 --> 00:48:20,000
about inspecting traffic 
streams, we're talking about 

915
00:48:20,000 --> 00:48:23,920
firewalls, disputed or gateway 
firewalls, etcetera. 

916
00:48:24,640 --> 00:48:28,640
It does sound and of no, of 
course it's based on, you know, 

917
00:48:28,640 --> 00:48:31,440
the hypervisor component, but it
does sound that it could 

918
00:48:31,440 --> 00:48:34,880
potentially impact the workload 
in terms of latency. 

919
00:48:35,160 --> 00:48:37,960
So from a performance 
perspective, do people need to 

920
00:48:37,960 --> 00:48:41,400
be concerned about that at all, 
or is that something that, you 

921
00:48:41,400 --> 00:48:45,640
know, we can forget about? 
So you absolutely have to be 

922
00:48:45,640 --> 00:48:52,080
concerned with it, but only if 
you decide not to build policy 

923
00:48:52,720 --> 00:48:55,680
using best practices. 
And, and it's a great question 

924
00:48:55,680 --> 00:48:58,440
because it comes up, you know, 
anybody who's a virtualization 

925
00:48:58,440 --> 00:49:00,560
person does exactly what you 
did. 

926
00:49:00,560 --> 00:49:04,120
They start thinking, OK, in my 
hypervisor, in my hyper, OK, 

927
00:49:04,120 --> 00:49:07,440
that's more in my hypervisor. 
What's the impact in my 

928
00:49:07,440 --> 00:49:10,200
hypervisor and is it actually 
going to impact the workload? 

929
00:49:10,200 --> 00:49:14,960
So let's look at it this way. 
If you treat the the V defend 

930
00:49:14,960 --> 00:49:17,560
firewall like a traditional 
firewall, and let's say your 

931
00:49:17,560 --> 00:49:19,920
traditional firewall has 10,000 
rules. 

932
00:49:20,920 --> 00:49:25,960
If the rule that allows or 
blocks the traffic for any given

933
00:49:25,960 --> 00:49:32,600
VM flow, if the rule that allows
or blocks is rule #9999. 

934
00:49:33,680 --> 00:49:37,640
And I've got to get to that. 
Every time this flow happens, 

935
00:49:38,080 --> 00:49:41,240
you are absolutely going to have
a performance hit. 

936
00:49:41,480 --> 00:49:44,040
There's no way around it. 
And, and, and, and remember, 

937
00:49:44,160 --> 00:49:47,360
take that exponentially across 
every other VM. 

938
00:49:47,640 --> 00:49:50,600
It may not be 9999, but it may 
be 8000. 

939
00:49:50,600 --> 00:49:52,200
It may be fine, right? 
You're still going through a 

940
00:49:52,200 --> 00:49:54,320
lot. 
So when I talked about one of 

941
00:49:54,320 --> 00:49:57,400
the advantages of our product 
being the management plane, this

942
00:49:57,400 --> 00:50:00,280
is part of it. 
So we've actually designed into 

943
00:50:00,280 --> 00:50:04,320
the product that we build 
efficiency into the way that the

944
00:50:04,320 --> 00:50:08,920
policies are applied to AVM that
we actually have a feature 

945
00:50:08,920 --> 00:50:12,320
called applied to. 
So if I take a particular VM and

946
00:50:12,320 --> 00:50:16,440
there's 10,000 policies, of 
those 10,000, there might be 8 

947
00:50:17,120 --> 00:50:20,720
that are relevant to this. 
So I filter out every other rule

948
00:50:20,720 --> 00:50:22,240
and now we only have 8. 
You're not going to know with 

949
00:50:22,240 --> 00:50:25,720
eight, eight is not going to 
impact the performance of the 

950
00:50:25,720 --> 00:50:27,920
virtual machine. 
So you do have to follow our 

951
00:50:27,920 --> 00:50:30,440
best practice. 
You do have to have the security

952
00:50:30,440 --> 00:50:34,400
mindset shift of I'm not going 
to treat the V defend firewall 

953
00:50:34,480 --> 00:50:37,840
like a physical firewall and 
micromanage from this one to 

954
00:50:37,840 --> 00:50:40,720
this one using IP. 
It doesn't work that way. 

955
00:50:40,960 --> 00:50:44,120
It's really hard to manage, it's
hard to scale and it's not 

956
00:50:44,120 --> 00:50:46,160
efficient. 
But if you buy into the 

957
00:50:46,160 --> 00:50:49,200
management platform and the 
strategy, then we don't have 

958
00:50:49,200 --> 00:50:52,040
those types of issues. 
Now, of course, with security, 

959
00:50:52,720 --> 00:50:57,560
it is universal truth that 
nothing will ever, ever, ever, 

960
00:50:57,600 --> 00:51:02,200
ever perform better if you apply
security than not having to 

961
00:51:02,200 --> 00:51:04,440
secure. 
There's just no way, right? 

962
00:51:04,640 --> 00:51:07,040
Same thing with manageability. 
Nothing will ever, ever, ever be

963
00:51:07,040 --> 00:51:10,600
easier to manage if you didn't 
have to secure it. 

964
00:51:10,920 --> 00:51:16,080
So when you look at it, if I add
IDSIPS to the mix, IDSIPS is 

965
00:51:16,080 --> 00:51:19,240
more security overhead. 
Now, we've done a really good 

966
00:51:19,240 --> 00:51:22,000
job with the latest version of 
the product to have something 

967
00:51:22,000 --> 00:51:26,320
called IDSIPS Turbo Mode. 
So let's take a 10 gig Nic for 

968
00:51:26,320 --> 00:51:28,520
example. 
On a 10 gig Nic, if you did 

969
00:51:28,520 --> 00:51:31,800
IDSIPS before turbo mode, it 
took your throughput from 10 

970
00:51:31,800 --> 00:51:35,160
gigs to three gigs. 
Ouch, right? 

971
00:51:35,160 --> 00:51:38,000
I mean, that's a big hit from a 
security perspective. 

972
00:51:38,240 --> 00:51:41,600
So now with Turbo mode, we've 3X
the throughput. 10 gig Nic will 

973
00:51:41,600 --> 00:51:44,080
take you to 9:00, but you get 
IDSIPS. 

974
00:51:44,080 --> 00:51:47,120
So you, you know, when you 
design, there's always a 

975
00:51:47,120 --> 00:51:49,440
balance. 
You always have to figure out 

976
00:51:49,440 --> 00:51:51,760
where, where do I balance these 
things? 

977
00:51:51,760 --> 00:51:56,920
I, I don't want extreme 
difficulty in management at the 

978
00:51:56,920 --> 00:51:59,560
expense of getting my super 
security. 

979
00:51:59,800 --> 00:52:03,400
I want good security, but I want
my manageability to be retained.

980
00:52:03,400 --> 00:52:07,120
So it's not that difficult. 
So some things can coexist and 

981
00:52:07,120 --> 00:52:09,480
some things cannot. 
It's where do you find that 

982
00:52:09,480 --> 00:52:11,480
balance between the two? 
And that's where I think we've 

983
00:52:11,480 --> 00:52:14,680
done a really good job of being 
able to improve security 

984
00:52:14,680 --> 00:52:18,000
dramatically, but minimizing the
impact to manage. 

985
00:52:19,640 --> 00:52:22,760
Now, before we actually started 
recording, one of the things 

986
00:52:22,760 --> 00:52:25,480
that you mentioned is that you 
would easily fill up the hour. 

987
00:52:25,480 --> 00:52:27,360
And I think we're starting to 
reach that hour. 

988
00:52:27,360 --> 00:52:33,280
So the last thing I actually 
want to do is ask you to give 

989
00:52:33,280 --> 00:52:37,160
your elevator pitch to us and 
explain why customers should 

990
00:52:37,160 --> 00:52:40,760
actually buy V defense in just 
two or three sentences. 

991
00:52:40,960 --> 00:52:43,760
And I know that's going to be 
hard for you, but try to stick 

992
00:52:43,760 --> 00:52:46,200
it to just a few sentences. 
Toughest part of the whole 

993
00:52:46,200 --> 00:52:49,800
thing, Yeah. 
No, honestly, I think it's 

994
00:52:49,800 --> 00:52:53,640
simple. 
I think V Defend changes the 

995
00:52:53,640 --> 00:52:58,760
security paradigm in a way that 
allows customers to buy down 

996
00:52:58,760 --> 00:53:02,640
risk as quickly as possible 
without having to change 

997
00:53:02,640 --> 00:53:05,800
existing infrastructure. 
There is no other tool that's 

998
00:53:05,800 --> 00:53:08,840
going to allow them to do that. 
There is no other tool that's 

999
00:53:08,840 --> 00:53:13,560
going to scale the way that V 
Defend product suite scales. 

1000
00:53:14,000 --> 00:53:17,960
It's just as simple as that, but
it requires you to think 

1001
00:53:17,960 --> 00:53:22,560
differently about security. 
That's the biggest challenge. 

1002
00:53:22,560 --> 00:53:25,600
It's not a technology thing, 
it's a people thing. 

1003
00:53:25,920 --> 00:53:28,280
And if you want to solve 
problems from a security 

1004
00:53:28,280 --> 00:53:31,480
perspective in today's modern 
private cloud, and we love that 

1005
00:53:31,480 --> 00:53:36,400
term, then you have to think 
about security that's embedded 

1006
00:53:36,400 --> 00:53:40,320
into the architecture, not an 
add on to the problem. 

1007
00:53:40,560 --> 00:53:43,320
Fantastic, Chris. 
Now, before I let you go, any 

1008
00:53:43,320 --> 00:53:46,120
famous last words or any final 
thoughts you would like to share

1009
00:53:46,120 --> 00:53:49,280
with the audience? 
Well, look, you know the last 

1010
00:53:49,280 --> 00:53:53,480
few years have been interesting 
to be to go from this transition

1011
00:53:53,480 --> 00:53:58,480
from VM Ware to Broadcom. 
But I will say this, as much 

1012
00:53:58,480 --> 00:54:03,800
hesitancy as there might have 
been to see this renewed focus 

1013
00:54:04,360 --> 00:54:10,680
and this laser sharp focus on 
private cloud, I think has been 

1014
00:54:10,680 --> 00:54:14,440
a phenomenal change for me 
personally, but for the 

1015
00:54:14,440 --> 00:54:17,040
organization too. 
And I don't know your feelings 

1016
00:54:17,040 --> 00:54:20,920
on this, but I feel like in the 
last two years we have achieved 

1017
00:54:20,920 --> 00:54:24,560
more from an engineering 
standpoint than we had in the 

1018
00:54:24,560 --> 00:54:27,320
previous five or six or seven 
years. 

1019
00:54:27,880 --> 00:54:31,040
And so it really forced 
everybody to start to think 

1020
00:54:31,040 --> 00:54:34,880
about how important the the 
collective pieces of private 

1021
00:54:34,880 --> 00:54:38,000
cloud really were. 
And now I think we're past the 

1022
00:54:38,000 --> 00:54:42,080
point where customers see it as 
a bad thing. 

1023
00:54:42,400 --> 00:54:46,000
And they're really starting to 
say this actually helps us, this

1024
00:54:46,000 --> 00:54:51,000
is better for us as a customer 
to look at this entire stack and

1025
00:54:51,000 --> 00:54:53,080
see how it solves business 
problems. 

1026
00:54:53,560 --> 00:54:56,480
So it's been an interesting 
transition from VMR to Broadcom 

1027
00:54:56,600 --> 00:54:59,320
and it's been an interesting 
transition from the first year 

1028
00:54:59,320 --> 00:55:02,800
of Broadcom to going on to the 
third year of Broadcom. 

1029
00:55:02,960 --> 00:55:05,480
But customers are starting to 
buy into the strategy and 

1030
00:55:05,480 --> 00:55:07,560
they're starting to recognize 
the value. 

1031
00:55:08,040 --> 00:55:11,320
And what I see happening now it 
probably over the next three to 

1032
00:55:11,320 --> 00:55:16,920
five years is the continued, I 
guess you could say consumption 

1033
00:55:17,160 --> 00:55:20,320
of other products, right? 
V San may not be deployed on day

1034
00:55:20,320 --> 00:55:23,480
one, but in 12 months, 18 
months, when a customer says 

1035
00:55:23,480 --> 00:55:26,640
it's time for a storage refresh 
and they realize, holy cow, I've

1036
00:55:26,640 --> 00:55:30,320
already got what I need in V San
boom, now we're going to see 

1037
00:55:30,320 --> 00:55:32,800
more V SAN. 
Same with the networking when, 

1038
00:55:32,800 --> 00:55:35,160
when a customer looks 12 months 
down the road and says, hey, 

1039
00:55:35,160 --> 00:55:38,480
it's time to revamp our Dr. 
strategy, let's stretch layer 2 

1040
00:55:38,640 --> 00:55:42,240
boom, we already own NSX. 
So that continued consumption 

1041
00:55:42,240 --> 00:55:45,520
and value that customers are 
going to get back because they 

1042
00:55:45,520 --> 00:55:47,920
own these assets already as part
of the private cloud. 

1043
00:55:48,200 --> 00:55:50,920
I think I'm really excited to to
see those things come to 

1044
00:55:50,920 --> 00:55:53,080
fruition. 
Well, I couldn't agree more 

1045
00:55:53,080 --> 00:55:55,200
Chris. 
Thanks for that amazing episode.

1046
00:55:55,760 --> 00:55:57,680
Thanks Duncan, It's fun. 
And that's it. 

1047
00:55:57,840 --> 00:56:00,200
Thanks for tuning in to the 
Unexplored Territory podcast. 

1048
00:56:00,400 --> 00:56:02,760
If you enjoyed this episode, 
don't forget to subscribe and 

1049
00:56:02,760 --> 00:56:04,400
leave a reviewer rating wherever
possible. 

1050
00:56:04,400 --> 00:56:07,040
And please join us again next 
time as we cover more insights 

1051
00:56:07,040 --> 00:56:09,120
into cutting edge solutions 
shaping the world of IT. 

1052
00:56:09,600 --> 00:56:12,040
Until then, staying comfortable,
keep exploring.