The. Welcome to the Honest Sport dot
podcast with this episode invite Chris McCain to the show to
introduce us to the world of VMRV Defend.
Hey Chris, welcome to the show. Thanks Duncan, been waiting a
long time. Yeah, yeah, I know.
I've mentioned it a few times and somehow it never happened.
And of course, networking and security is not really my thing,
so I really need to force myself to invite the right person.
But today we have you on the show, so I'm pretty sure there's
going to be a great episode. Now, before we get started, I
know you're kind of famous in the industry and of course,
especially the the virtualization community for
some of the books that you've written.
But maybe you can introduce yourself and maybe you can also
explain what it is that you've done before you joined VMS slash
Broadcom because you've been around for a long time.
And I would also like to hear about a highlight of your
career. No, sure.
So, yeah, you know, I joined VM Ware 13 years ago.
So I've spent the last 13 years really focused on the networking
and security side of things. Prior to that, I owned a company
where VM Ware was my biggest customer.
So I was, I was one of three global companies that provided
contracting services to VM Ware. So I built exams, I wrote
content, actually wrote the first set of content when VM
Ware bought Dynamic OPS from Credit Suisse, that then became
VM Ware Cloud Automation Center or V CAC as it was infamously
known. And, and then, you know, all the
way into to VCFA now, right? But along the way I, you know,
ESX 2, I started with ESX 2. So I, I was the second
contractor that VM Ware ever hired to teach ESX 2.
I was able to go all over the world.
It was phenomenal. It was a pivot from Microsoft
and Cisco training that I was doing and being more kind of
seemed like the next big thing. So I got in really early, which
was great. And then, you know, when I
joined, I was actually trying to grow my business.
I was trying to, to reach out to the, the new NSBU they just
bought Nicira and I was trying to grow my business and say,
Hey, let me help you build your certification portfolio and all
your training and, and you know, one thing led to another.
And I ended up joining and really it was about the
excitement around what I saw they were doing with networking
and security. I'd been in the hypervisor so
long and I saw the trajectory of change in the data center.
And when I saw the networking and security, I was like, this
is, this is really cool stuff. And it wasn't, it wasn't
desktops, right? Desktop was kind of a very
complimentary thing that sat on top of it.
The networking and security was a completely different paradigm.
It was a totally different audience.
So I think there was a challenge there for me to be able to, to
come into VM Ware, not in a specific job role, but to help
them build this thing called networking and security.
And that that was really attractive to me.
But highlights, I think I would say there's 21 before I joined
VM Ware. And that was when I got my VCDX.
You know, like I said, I was a trainer.
So for me, the VCDX wasn't about a, a specific thing other than
challenging myself, seeing guys like you and Frank and John and
all these guys who were industry vets and leaders in this space
and really challenging myself to be at that level.
And I had a, a unique opportunity where as part of my
business, I was, I was building the data center design to host
all of Dell's training for Equal Logic, EMC and VM Ware.
So they were sending all this year based on my design, I got a
chance to manage it. And I just thought, you know,
this is the right fit for me to be able to take this thing that
I own and control and couple that with the training that I'm
doing and see if I can get a VCDX.
So, you know, the hardest part in the VCDX for me was in the
assembly of all the documentation.
But as far as the defense and things like that was natural for
me. I was to standing up in front of
12 or 15 people as the expert to talk.
So it and I owned the the design.
So really it was a natural fit. But then I think getting that
that VCDX was a highlight for me and it was a pivot in my career
because now I did start to focus more on some consulting stuff.
So that was big. And I look back on that and it
was, it was great challenge to, to be able to get and then the
other one, it's probably being on stage at Explorer.
Do I wish it would have been the, the 25,000 person Explorer?
Of course, right. But you know, to get to stand in
front of 5006 thousand people that are there, It was, was fun.
And, and just the way that it all happened organically was
great. I was a little, I was a little
worried, not, not nervous. I was a little worried because I
knew that Explorer was a very scripted event.
And anybody who has seen me talk, I am not a scripted kind
of guy. Yeah, I'm shoot from the hip
from the tip to the to the final buzzer.
But it ended up working all right.
They gave us a lot of freedom and flexibility to be able to
communicate and talk the way we wanted to.
They just wanted some bullet points to make sure that timing
is is there. So I understood it, but it was
it was great to get to hang out with Hock and get meet him and
chat with him, but see all the behind the scenes stuff.
But yeah, definitely the highlight from the last few
years. That's funny.
That's probably one of the things that changed the most
compared to the VM world days where we had the VM executives
up on the stage. As you said, everything was
scripted, every single dot, every single exclamation mark,
you know, it was all in the notes.
But as you said, you had some normal freedom.
So that's, that's good to hear. And I think it was clear as well
during the presentation you guys did did great and it was
extremely interesting. It's also one of the reasons I
invited you. Now, as I mentioned today, we're
going to be talking about security mainly.
I had Eve on the show to talk about networking a couple of
episodes ago. So I figured we probably should
also be talking about security. Now, one of the things I wanted
to touch upon first because this is something that you've
presented on many different times, and I think it's probably
something that is good to hear for my listeners as well.
For those who haven't seen you at one of the V mugs or maybe at
Explore, is the thing that you've always spoke about, which
is NSX mindset. Now, of course, everything has
changed, the pricing, the packaging, but I think the
mindset still applies. So maybe you can explain what
that NSX mindset actually means and you know how people should
think about that. Yeah, it's, it's a great point.
So, you know, NSX mindset came out of the idea or the, the, the
concept was born from the fact that when I joined an SBU and I
started going out to talk with customers, we had a very, very
cool technology in what we did right.
The abstraction of routing and switching into the hypervisor.
The, the architecture is of course unique, but in talking
with customers, it wasn't a technology discussion as much as
it became a humanistic barrier for people to, to let go of what
they were doing traditionally. This idea that, no, I have to
log into this switch and I have the trunk of VLAN and I, I know
Cisco, I have this behavioral momentum that every five years
I'm going to refresh my Cisco switch.
And that's just what I'm always going to do.
So it had nothing to do with technology.
It had everything to do with getting people to see networking
and security differently. And that's where I think the
mindset piece came in because we're really targeting
understanding our technology from the the standpoint that
what we're offering to you is not a different skill set.
Networking is networking. It's still BGP, it's still OSPF,
they're still default gateways, they're still routing.
But the way that it gets implemented was different.
So it was just a small shift in thinking, not a giant shift in
technology. So when we when, when I kind of
brought this to market as NSX mindset, I think that's what
started to draw people in is what does that, what does that
mean? Like, why, why are you saying
mindset? How does that actually relevant?
So sounds like you're, you're trying to talk me out of, you
know, being upset about something.
It's in some psychology way, but it was really just a humanistic
thing. And, and look, we've pivoted to
that several years ago. We did security mindset at, at
Explorer and it, it was great. I mean, we did a 90 minute
session. I think over a couple different
years we had over 1200 people come through it.
But I, I think people are interested from a humanistic
perspective in how they make, how they, how they create
change. And I think it's, it's a common
boundary that goes beyond technology is just how do we
fight off this fear of change? And that's really what we
focused on is that you, you got to get over this idea that we're
providing any type of radical new technology.
Firewalling is firewalling. We're, we're not doing anything
special. Did we change the architecture?
Sure. But that's, that's got nothing
to do with making it difficult. We're making it easier for
people. So the whole mindset piece is
really, it's stuck over the years and I still have people
that I see wearing the T-shirts that say NSX mindset.
And so it, it kind of took on a life of its own over the years,
but it was definitely rooted in, like I said earlier, the
networking and security stuff was a, a different demographic.
We weren't necessarily able to sell it to the people who were
so excited about virtualization. We had to go to a different
demographic of people who basically we're not impacted by
virtualization. Because if you're a network
engineer, if you go back to VI three, I think we can all agree
VI 3 is when we really started to make headway.
But if you go back to VI 3, when that started to reach into the
data centers, the operational model for the network engineer,
it didn't change significantly because prior to virtualization,
if you deployed a new server and needed a network, what'd you do?
You picked up the phone, you called the networking team, you
said, hey, can you trunk me AVLAN?
And they're like, well, what do you need it for?
And they're like, what do you care?
And then you go back and forth and then finally you get your
VLAN. Well, now you had virtualization
and we're sitting on top of the physical network fabric.
But if you deployed 50 new virtual machines, the way you
would have just deployed 1 server and you needed a network,
what did you do? You picked up the phone, you
called the networking team, you said, hey, give me AVLAN.
Like, what do you need it for? What do you care?
And you go back and forth and then you get your VLAN.
So the operational, the model didn't change for networking and
it didn't change for storage because they're like, oh, give
me a Lun. What do you need it for?
What do you care? Just give me a Lun and then you
go virtualization and it's the same story.
So those individuals that bought into virtualization were not the
individuals that we were now trying to target from a
networking and security perspective.
So it really required us to reach deep into the bag of
getting people to understand that we're not.
We're not trying to take your job away.
This is not something you haven't been doing.
The skills are there. It's just a different tool.
And the interesting thing is, I think we had similar problems
with with V San. But of course with V SAN, we're
actually selling storage to the virtualization administrator
where you are selling new networking services or a
different way of doing networks to network engineers.
So yeah, it's a, I guess a more challenging problem, I should
probably say, knowing some of the networking engineers, right?
For sure, for sure. Now one of the things of course,
as I mentioned, we're going to be talking about today is
security. And we all know that V Defend is
a big part of that. And recently for most people,
probably over the last year, year and a half, a lot of s s
has actually changed from a licensing perspective or
packaging point of view. I'm not, I don't want to talk
about numbers specifically, but I think packaging is
interesting. So it's probably good before we
actually start diving into some more specifics to explain what
the V Defen offering is and how it actually ties in with VCF
from a licensing and or packaging point of view I should
say instead. Yeah.
This, this one's really interesting to me because when I
think back at just the evolution of the NSBU and the evolution of
the product pre acquisition to post acquisition, right.
So pre acquisition when we had this thing that we called NSX
and NSX was networking and it was security.
The problem I think that we had and we kind of shot ourselves in
the foot with this is, is, is we called it networking and
security and the reality of it was it was networking and or
security. They were mutually exclusive.
Did they work well together? Yeah, absolutely.
Could I make the business case that they should be used
together? Yes, of course.
However, they were independent entities.
You did not have to do overlay networking in order to get the
security piece. So we didn't do a good job of
telling customers that specific thing.
So we had a lot of customers who were very interested in
security, but they were under the thinking that, well, if I
want to do security, I have to do the networking.
And as you just pointed out, if you've got to convince a
networking engineer to allow you to do overlays in order to get
security, you now have a giant hurdle that you have to
overcome. So when you Fast forward to
today post acquisition and what's happened is that the
networking portion of the artist formerly known as NSX is now
embedded into the core platform that makes up the private cloud.
And then the security portion is an add on that now has its own
name of VM Ware V Defend. So from an art and then this is,
this is critical because I still think a lot of times people get
confused here from an architectural perspective, V
Defend is and always will be built into the hypervisor.
That does not mean that it's built into the packaging and
pricing of the VCF product itself.
So it's an add on, even though architecturally it's still an
hypervisor just like the networking is in the hypervisor,
just like storage is controlled to the hypervisor, the security
is in the hypervisor, but it's an add on to that.
So it's an interesting model, but I do think that now there's
a very clear demarcation between the networking stuff and the
security stuff that we have. One of the other things that I
probably probably should be talking about as well, because
I've seen some customers actually implementing VCF with
just NSX and some of them actually do VCF, NSX, and V
defense. Now, in your opinion, right?
To make things that simple for our listeners, does it actually
make sense to implement VCF plus NSX without V defense, or should
everyone just be using it? Look in, in this new Broadcom
world of pushing private cloud to compete with public cloud, I
don't think you can build an equivalent operational model to
the public cloud if you are not using both the networking and
the security aspects of it. And and there's really one key
reason for this. The operational model of the
public cloud requires that the physical network fabric not be
dynamic. You can't.
If you spin up something in Amazon, you don't pick up the
phone to call somebody to ask for a network.
It has to be generated dynamically.
The easiest way to do that is in software.
So if customers want that model, they have to to think
differently about the physical network fabric.
They have to design it once, wire it once and leave it alone.
Don't touch it. Relegate the physical fabric to
passing packets. That's it.
Give me an SLA that says we're going to be up X amount of time
and we're just going to pass your packets.
But if you need a new network, if you want to consume some type
of networking service, it's going to come out of software
the same way it does in AWS, the same way it does in Azure, the
same way it does in Google. That's the only way to get to
that point. Now the problem with that is if
you don't use the security piece, then you're using this
legacy architecture that says in order to apply security, I have
to force traffic over a layer 3 device.
So that's been the biggest problem from a networking and
security perspective is that those two things clash because I
want to protect something. But in order to protect it, I
got to go to the networking team and ask for three different
networks for this multi tier app because then I have to force it
over a firewall device, right? A layer 3 device.
That's where VDEFND completely changes this paradigm.
It it flips everything on its head.
Because for us, when we abstract the firewall into the
hypervisor, we're actually disaggregating the relationship
between IP and security. They they're no longer matched
with one another. So for VDEFND, you do not have
to change a single piece of the physical network fabric in order
to implement, but at the same time you're optimizing the
ability to control flows between virtual machines that may not
only be sitting on the same host, they're on the same IP
network of the same host, which as we all know, would never
actually egress that host, right?
All communication would happen in the host.
So a physical firewall is completely irrelevant at that
point. You cannot solve that problem
using a physical firewall. You can only solve that problem
if you want to try and manage agents inside of every VM, which
is crazy, or if you leverage the hypervisor, which is our
competitive advantage. So by breaking that relationship
between IP and networking, that's the only way you're going
to get to a point where you can simplify the future state
architecture of design. Because now when you have the
ability to protect without requiring specific networking
configurations, you can now pivot the model into rather than
building a whole bunch of small networks to be able to force the
traffic over a device that can inspect, you can build larger,
flatter networks that don't compromise security, which makes
the long term management of the network even easier.
So it's really, if you want to do things that are, are going to
facilitate the company's ability to automate, to be agile, to
scale, you have to be using both the networking and security.
And look, it's storage too, right?
We, you can't take that piece out of it.
If you want to automate, you want to truly build something
that looks like AWS. You're talking about compute,
storage, networking, security. They all have to be automated.
They all have to be consumed dynamically and one should not
impact the other. And the easiest way to do that
is when you consume the full private cloud stack of VCF and
then the additional add-ons for security.
And I guess the great added benefit is that it also means
that you no longer have to talk to the security team, right, as
a, as a result of of this solution.
Now you kind of alluded to it, but you didn't mention it.
So I'm going to say the word micro segmentation because you
kind of mention it with all of the different virtual machines
connecting and preventing connection from happening
etcetera. Now, I know it's something that
as VMI we spoke about a lot many moons ago, but I kind of, I kind
of have the feeling that it disappeared.
And I know you touched on this during your explore session and
I thought it was something that we should bring up because the
way you explained it, I think really hit home.
So what is your opinion on micro segmentation?
Or do you feel it's something that people should still be
implementing today or not? When does it make sense?
When doesn't it make sense? Because it seems rather complex.
Yeah, So it is complex and I'll, I'll give you the back story in
this. And look, I'm just as guilty.
So if people want to point fingers at me, I I can't deny
I'm just as guilty as every other person in the NSBU as
jumping on the micro segmentation bandwagon.
And so if I look back at the history and this is, you know,
anecdotally, what I think happened is in the beginning of
NSBU. We were really focused on
networking. In fact, many of the people in
the NSBU had come from networking vendors and everybody
was so excited about the networking stuff.
And the more we talked with customers, the more customers
were like, OK, it's cool, but you know, I got to get my
networking team involved in it. But I, I kind of like that
security thing, right? We started to realize, OK, maybe
the lead in here is security. So we go back to the drawing
board. Well, we come out and we jump 2
feet into micro segmentation and we stood on every mountaintop
and screamed micro segmentation. We got in every customer
meeting, every explore session we could.
And we said micro, seg, micro seg, micro seg.
And in the beginning, customers would, you know, nod their head
violently, yes, this is amazing, this is great, this is great.
And then we would leave and they do nothing and we're like, I
don't understand. It seemed like they love this
idea. So then you go back to the
customer, you say what happened? Why?
Why didn't you want to do micro segmentation?
Say, oh, it it's too hard. We don't, we don't know how our
applications actually communicate.
We don't know what flows. We don't even know how to build
the rules for this thing. So of course, being VM Ware,
what does VM Ware do when a customer says we don't know how
to do something? We built a product for it.
And so we did. We built this really cool tool
that was called security intelligence.
And security intelligence would look at all the flows and then
generate rule recommendations so user could look at it and see
all the recommendations. And there was even a button push
here and it would build all the policies for you.
So we go back, we show customers because like, yeah, yeah, yeah,
this is great, this is great. And then we leave and they do
nothing and we come back and say, well, what happened?
Why didn't you push the button? And they said, well, we don't
know if those rules are right. Nobody knows nobody.
So the problem wasn't a technology thing again, it was
back to being a human thing, because a human who pushes that
button is essentially becoming accountable for the all of those
flows that could potentially break the application.
And nobody wanted to be that person, right?
I, I put it this way, sometimes think about doing AV sphere
upgrade. When you do AV sphere upgrade,
you've probably done it before, right?
When you do AV sphere upgrade, if you're that guy that has to
push the button to start this upgrade, think about what that
feeling in your stomach is like. You're nervous, you're thinking,
God, please, I haven't talked to you in a while, but please don't
let this fail. Please don't let this break.
I've been in a position a few times that it broke, so I know
how it feels. Exactly.
But but imagine that's micro segmentation.
So that's not just once a year, that's not once a, that's every
time you deploy an and you use this tool to build policy,
that's the feeling you get because you could break the
application. So it became difficult.
So what do we do? Go back to the drawing board.
And this is where like five years ago, I started thinking
about this very differently than micro segmentation.
I thought, all right, what we need is an easy entry point for
customers that reduces the time to value from a security
perspective with minimal impact to the operational model.
So how do I get more bang for my buck and my time, but without
significantly overhauling the operational model?
Because no matter how good a security technology is, if I
came to you, you're a customer and I come to you and say, hey,
we've got this whiz bang tool. And by the way, if you implement
our tool 2 years from now, you'll be really protected.
And in order to get there, you need to hire 50 new people and
spend thousands of man hours to get there.
You'd be like, all right, done. You're not interested in that.
So I started to look at the way that attacks happened.
You look at the attack chain, you'll get the anatomy of an
attack and you start to reverse engineer the things that
happened during that attack. And you you realize there's this
aha moment of, wait a minute, these are things we can protect.
These are things that are not specific to any particular
application. They're not specific to any
particular attack or ransomware, but they are tools that threat
actors want to use in order to find things of value.
And so we started to make this pivot in going into customers
saying, listen, this is not an all or nothing proposition.
We've got firewall, distributed firewall, gateway, firewall,
security intelligence, IDSIPS, network traffic analysis,
network detection and response, malware protection.
We got this big portfolio of security products, which I think
proves we're a security company, but it can be overwhelming.
And we say this is not an all or nothing proposition.
You can pick and choose the pieces you want.
Well, you know what happens if you leave that up to customers.
If you leave it to customers, customers, they're like, I'm not
sure which one. So the best thing that we could
have done, which is what we're doing now, is to go to a
customer and say, look, you can pick where you wanna start.
But if you don't know, then here's a prescriptive plan on
exactly how you can implement V defend to buy down risk quickly
and easily in your environment. And here's what each one of
those stages look like. So at this point, you start with
a segmentation assessment. What does my current environment
look like? Am I protecting anything?
Totally optional. I've got some customers that
take crisp. You could run this assessment.
It's not going to tell me anything.
I don't know. I'm not doing anything, so the
assessment's going to come back. I'm going to be terrible.
I already know it. Skip it.
Let's go to the next step. I've got other customers that
say, well, I'd like to know. I'd like to see what my score
is. And then that way after we spend
some time doing some security stuff, we can run it again and
see what the delta is between the two times that we run it.
So step one, let's figure out where you're currently at.
Step 2 then is the anatomy of an attack.
How do attackers move? They use RDP, they use SMB, they
attack DNS, they attack Active Directory, NTP.
All of these different types of protocols and services are high
value targets in the enterprise. So as our Step 2, that's what we
target. We go in and we say, look, RDP
is extremely predictable. You know where it should come
from, you know where it should go.
We can protect that. DNS, extremely predictable.
If you're internal, talking to an internal DNS sounds good.
If you're an internal DNS, going to an external DNS sounds good.
But if you're an internal client going to an external DNS, that's
bad. We should never let that happen
so we can easily build policy to control those types of things.
Step 3 then is zoning. Every customer has prod, test,
dev, DMZ, staging, whatever these different things are.
But the big problem is they understand it from a business
standpoint, but they don't understand how to convert
business logic into technology. And so that's what we did with
Vdefend. Now is you can look at your
environment and say, hey, all of this stuff here is prod, we can
tag it, we can tag DMZ, we can tag test dev, and then we build
simple policies that don't allow them to communicate.
The fourth step is applications, but we're still not at micro seg
yet. So look at the difference.
We jumped in as micro seg leading.
And here I've been talking for 5 minutes and I haven't even got
to micro seg yet. So we've made a complete 180 on
micro seg. Not that it isn't important, but
micro seg is the end state. Micro seg is the Nirvana that
we're trying to reach because it takes so long for micro
segmentation to actually buy down significant risk in the
environment. So we do our assessment, we do
our infrastructure, we do our zoning, then we might do
application macro segmentation. So I'm not worried about within
an app, how are things communicating, but app A should
not talk to App B, but I do those things and then now I
might be ready for micro segmentation.
So we expect that customers are going to take this journey down
this path of security. And by the way, if a customer
says I'm going to stop at zoning, fine, stop at zoning.
We just want you to have this this tool in your tool belt that
is purpose built for your private cloud, which by the way
scales linearly across your entire data center along with
your compute infrastructure. And if you decide later on you
want to add more than you add more, go down that path.
But yeah, it's interesting to hear micro segmentation now
because five years ago or six years ago, seven years ago, it
was all we wanted to talk about. We just micro seg was that
buzzword and it would probably be said 40 times in anyone
presentation. Now I go talk to a customer.
It might be said twice. And it's one of those things
that we've seen that with virtualization as well, and
they've seen the same thing with storage.
These conversations, you know, the result of those
conversations typically depend on the maturity level of the
customer and not necessarily meaning maturity itself, but
more, you know, how much knowledge do they actually have
of their estate? And as you said, it's extremely
complex. Most customers don't know what
talks to what. So it's very difficult for them
to actually implement that. Now, what stood out to me
though, and that's probably a question I should ask, is
because I'm the, you know, advocate of the devil as well
here, of course, you know, acting on behalf of the
listeners. If I listen to some of the
things that you've shared now and mentioned in terms of, you
know, the firewalling capabilities, etcetera, I can
also imagine that some of our competitors could do similar
things. So what is unique about V defen
compared to some of our competitors?
I'm not asking you to test the competitors of course, but you
know, maybe you can, you know, focus a bit on what we bring to
the table compared to other solutions.
Well, I mean, look, this is something that comes up every
customer meeting, right? I mean, everybody's looking,
everybody knows security is important.
Everybody's looking to solve a problem.
I would say this when it comes to, let me just say, for
firewalling to start, right, because there's a lot of
firewall vendors, a lot of different tools.
From a firewalling perspective, you have three options.
One is to install an agent inside of every workload that
you have Now, obviously agents adding more and more agents into
an operating system. At some point there could be
agents that conflict and now you have a problem.
I mean, we saw what happened with an agent last year, right,
where something took down a whole lot of infrastructure
because of the agent. But I think for me the biggest
issue with the agent is that if an attacker is able to get into
a system and has the appropriate credentials, they can turn off
the agent, at which point security is gone.
So the agent architecture has vulnerabilities from that sense.
The other way to solve the problem is you go below the
hypervisor and you go into the physical network.
Of course, the problem with the physical network is it lacks the
rich contextual understanding of what applications are doing.
Everything is IP port source, IP destination port protocol.
So we're very limited in the way that we can manage that.
And it doesn't scale for a few reasons.
Number one, if I'm trying to get security across a broad set of
my infrastructure, I'm now adding the complexity of trying
to reroute my traffic to make sure it goes over this
particular security device. So the agent is is too high in
the stack, the physical firewall is too low in the stack.
Well, what's in between the agent and the physical is the
hypervisor. So this is and always will be
our competitive advantage. We are in a spot that makes
security not only extremely efficient, but easier to manage
at scale because we have the isolation that separates us from
the operating system. If, if, if an attacker gets into
a guest OS, they can't disable the V defend firewall because
it's outside of the guest OS. But at the same time, we have a
much richer contextual understanding of the application
because we're in the hypervisor. So what we've been able to build
taking advantage of our space in the hypervisor, but also from a
management plane perspective, I would go toe to toe with any
vendor from a scale perspective. Because when you think about it,
then it, look, anybody that's been in vsphere for a long time
understands every time you add a new unit of growth into your
data center, whether it's one server or a new cluster or an
entire rack, whatever your unit of growth is, right.
Oh, we hit this certain level. We need to buy more, whatever
that unit is that you buy more of at this point when you're
buying in to our private cloud story, that unit of growth is no
longer just additional CPU in memory.
That unit of growth is CPU, memory, networking, storage,
firewall, IDSIPSNDRNTA it, it's all in the hypervisor.
So the gone are the days and you know, it sounds like a good
thing, maybe not for, you know, architects, but gone are the
days where the complexity of the physical network is something I
have to contend with because I'm not trying to figure out how
many firewalls do I need to buy and how big do they need to be
and how much oversubscription is there and how much throughput do
I have the ability to grow into? And when am I going to need a
new one? And hey, if I need a new one, is
it even going to be available? Is it going to take me 8 months
to get? We eliminate all of that simply
because of our architecture. And when you add the management
plan in, the ability for us to step away from building policy
based on IP and now being able to use tags and groups or even
operating system. I mean this is one that
customers go crazy over because every customer has legacy
operating systems. But because we are so integrated
into V Center, as you know, we already know the operating
system. So we don't have to go figure it
out. Customers don't have to go
figure it out. Because of that integration, I
can build a security group that says where operating system
equals and it dynamically populates.
And now I can build policy and if somebody updates the
operating system and it steps outside of what we define, then
boom, security is gone. I'm done.
I don't have to touch it again. So the the operational model of
what we're providing is unlike any other security that can be
implemented out there. So to answer your question, I
think what we have unique is 2 things.
One is our architecture being in the hypervisor and two is the
management plan. Nobody can do the things that we
do at the scale that we can do. You mentioned that it would make
life easier for architects and of course from an operational
perspective as well, but there are still some decisions to be
made, right? When I was watching your session
and I was reading some of the documentation and the blog post,
one of the things that stood out to me is that there are
different types of firewalls that we have part of the system.
So there's a gateway firewall, there's a distributed firewall.
Now, I got kind of confused fairly fast, so it's probably
good for you to explain it to me and probably for the listen
listeners as well, what those things are and when you would
use either of the two. Because, you know, I was kind of
lost within within two minutes. I'm not a networking guy, so
sorry about that. So no, it's a great question and
there's actually 1/3 option too. Here's the interesting piece.
When we, when we go out talking to customers and and look, most
of our customers are very heavily invested in
virtualization. That's just the nature of who we
meet, that's who we talk to. But there are still customers
out there that say, hey, I'm only 70% virtualized.
I still have 30% that's not virtualized.
So customers would inevitably ask if I do this firewall thing
that's in the hypervisor, what about my other stuff?
What about the things that are not virtualized?
So at that point we realized, well, we're leaving stuff on the
table here, number one. Number two, we're putting our
customers in a position where we can't solve the security problem
for them because they still have a portion of the estate that is
not running on our hypervisor. So the distributed firewall is
and always will be the most efficient, most scalable
architecture from a security perspective.
However, if a customer still has physical assets running on Vlans
that are not on a hypervisor, the gateway firewall is our
instantiation of an appliance based firewall.
So it can be deployed as a virtual machine or it can be
deployed as a physical machine. So you think about customers as
Oh well, I've got, you know, vendor X is my physical firewall
down here and I'm controlling traffic between my V Lans.
Well, as part of the V defend vendor X can go away.
The gateway firewall can slide in and now you have one single
management plane to control all traffic within your private
cloud. Now this is not to get, I just
want to be clear. This is not to get rid of the
north-south boundary that is there into and out of the data
center. I would expect every customer
wants to have a multi IT vendor strategy.
So it whatever your vendor is protecting the data center, you
lead that. But inside the data center if
you want one single management plane, then the gateway firewall
can handle those non virtualized workloads.
The third option is we actually make agents.
So I know it might be a little hypocritical here because I was
just saying agents aren't great, but sometimes we don't have a
choice but to put an agent. Now our agent does work
differently. So I've seen various competitors
where the agent actually manipulates the Windows firewall
or the agent manipulates the Linux IP tables.
The the fire, the Windows firewall one is interesting to
me. I don't know how much Windows
experience you've had managing, but you know, back in Windows
2000, this thing called group policy, you could manage the
Windows firewall using Group policy.
Nobody did it, but you could. So now there's actually vendors
who build an agent to be able to manage the Windows firewall.
Why? Why would I need an AI could do
it in Group policy? It's weird to me to do that.
But look, sometimes it's, it's, that's the only architecture we
have now, our agents a little different.
We're not managing the Windows firewall.
We're not managing Linux IP tables.
We have a different architecture that allows us to still consume
tags and groups and the things that we have in our management
plane because otherwise it really wouldn't scale.
It wouldn't scale if we said, hey, we got all this great stuff
up here that you can use, but by the way, on your physical you
have to treat it and just do IP addresses again.
So the architecture of the DFW, like I said it's the best one to
have, but gateway firewall does serve a need for customers that
have non virtualized workloads as well as the agents.
Hopefully that cleared up for you.
Yeah, no, that clears it up. And I, I'm kind of shocked that
we also do the the physical component.
But I, you know, I think it makes a lot of sense.
As you said, it helps you creating a solution which can be
managed from a single control plane.
So I think that is, that is fantastic.
Now the other thing that we also have as part of the, the, the V
defense solution is advanced threat protection.
And it's one of those solutions that got me very excited.
I've been talking a lot lately about ransomware recovery, but
of course there is no recovery if there is no breach.
And that's what ATP comes into play, right?
So it's probably also good to explain what ATP is and, and,
and how it relates to the actual firewall offering itself.
Because I think it's one of those things that although you
probably talk a lot about it, somehow it doesn't pop up in a
lot of conversations. And I think that's a shame.
So, you know, please shine the light on it.
Yeah. And look, there's a reason for
that there. There's a natural evolution from
a security perspective that a customer is going to have to go
through trying to push all of this at one time.
Like I said, it's really overwhelming for customers.
But let's let's start with first of all, ATP, OK?
Or what we formally called ATP, it's actually all in one SKU
now. So V Defend is V Defend, you get
everything. We used to have AV Defend
firewall SKU and we had AV Defend ATP SKU.
It's two different things. So you could buy the firewall or
you could buy firewall and ATP. Now it's just all one.
So when you buy V Defend, you get everything inside of there.
So the firewalls and the security intelligence tool.
Built into the hypervisor. Like we talked about, the ATP
portion starts with IDSIPS. So just like we have firewall
built into the hypervisor, right, stateful L4 through L7
firewall, IDSIPS built into the hypervisor.
So in real time, we have the ability to inspect traffic flows
against known bad traffic patterns.
If there's a vulnerability and there's a signature for that
vulnerability, we can stop that from happening.
And again, our management plan allows us to curate these
signatures because I might only want the most severe, right?
I don't want the little, I just want the most severe or I want
specific things on specific virtual machines.
So it's all policy driven. This is not something carte
Blanche has turned on across the entire infrastructure.
This is defense in depth. This is I've whitelisted the
things that I want in my environment and now I want to
check against known bad signatures.
So the IDSIPS allows us to do that.
And it's extremely powerful in the sense that again, it's
happening in real time in the hypervisor.
We are not hairpinning this traffic to some third party
device. We don't have to do spans and
taps and all these different things.
It's right there in the hypervisor.
So back to our unique architecture.
The other parts of ATP is, is network traffic Analysis or MTA.
If you think about this V Defend has a, a data collection engine
called Security Services Platform.
SSP, it had a previous name. It was a little difficult for
us, but now SSP, this is no small entity.
We're like 96 VCPUS and terabytes of memory across a
containerized platform. But the value in this is in the
data that we collect and the information that we provide back
to our customers. So SSP is picking up all the
flows. I had an EBC with a large credit
card company and they want everything.
They want to know everything about the environment.
That's what SSP is doing. It's every flow in your private
cloud. Now what do we do with that?
We apply machine learning to it so that we can identify are
there anomalies in the traffic patterns.
So imagine I've got thirty 6090 days worth of traffic and all of
a sudden 2 virtual machines that have never talked to each other
before are all of a sudden talking to each other.
Is that good or bad? I don't know, but I might want
to know it. I might want to know that this
new form of communication or this new flow is happening in my
environment. So the machine learning aspect
of SSP and MTA is to pick up that we haven't seen this
before. You might want to go take a look
at it. And security people love this
because they love information, they love data.
Now they don't like false positives, but they like data.
So NTA is going to give that. Now, realistically, if I'm a
security person, yeah, that's great that you told me about an
anomaly, but I actually want to know if it's good or bad.
I actually want to know, is this just a random flow or is this
part of an attack chain? Now that's where we get to
network detection and response. So another part of V Defend in
in the ATP suite of things is network detection and response.
So you mentioned recovery and this is where I think that the
NDR feature of V Defend coupled with something like the live
recovery feature inside of ACC, these two are meant to be
together. There's no question about it.
And I hope in the future that we start to find ways to actually
engineer these things together. But think about it this way.
NDR is looking at all these flows in SSP, and if there's an
attack that happens, the NDR engine, the machine learning,
the AI that's built into SSP is going to recognize that these
aren't random flows. These are flows that correlate
together as part of an attack campaign.
So if you think through the way an attack happens, there's
infiltration and then there's command and control, then
there's lateral movement, then there's command and control,
then there's lateral movement, then there's X filtration, then
there's ransomware. So I mean only a couple of VMS.
But look, most attacks, they really only have 3 or 4 hops.
Attackers are smart. They don't have to go to
hundreds of places to find something of value.
So when that infiltration command and control lateral
movement command, when that's happening, SSP is looking at
these flows saying, hey, this is actually an attack.
And it puts it together, Duncan, I'm not kidding.
It puts it together in this beautiful timeline.
You see exactly what get hacked, What was the attack?
What was the severity of the attack?
And to me, most importantly, when did it happen?
What time did it happen? So if you're a customer and
you're trying to figure out how to build, let's say ransomware
recovery runbooks and VM Ware comes in and says, hey, we've
got this ACC tool and it's got VLR and it builds a clean room
and it can do all this stuff and you just push a button and it
does the restore. That's all great.
But if I don't have the understanding of what happened
in the attack, then what does that recovery look like?
Well, I've got to restore AVM, wait till it's done, go into the
VM, see if there's any bad stuff in there, and if there is,
delete that one and go to the next one.
And then go look at it. And it really I'm going to
iterate through every possible thing.
Because remember, if there's an attack and I just mentioned 4
VMS or three VMS, if there's an attack and I don't know which
ones, you're going to have to check everything because you
can't just restore the one that had the ransomware.
If the attacker is still in the network with command and control
software, you're going to restore it.
What's he going to do, go right back and and ransom it again?
So we have to clean the entire thing.
We need the attack chain. So when I take that, that rich
data that I get with NDR and I know who and when I can take
that into my VLR and say, OK, I need VM9 and VM9 was compromised
at 1:55 PM on February 2nd. All right, what's the backup I
have before it? I'll take that one.
And it was VM7 and VM7 was compromised at this day and this
time, OK, I'll take the one before it.
So my mean time to recover is drastically reduced for two
reasons. One, the power of VLR being able
to restore into that clean room and having the snapshots that I
need. And two, is the understanding of
what exactly happened in the attack because of NDR.
It's it's a beautiful story. Yeah, I think it's a fantastic
story and actually just recorded the demo for the upcoming VMA
Connect in Amsterdam. But I'm actually showing VLR
with ransomware recovery and I'm actually going to go through the
whole workflow and show you virtual machines that were
exposed to the Internet and of course, they got encrypted as a
result. And I'll show you how to recover
from that as well. And, and look, VLR is great
because you know, it's got the tools to be able to show you
when the ransomware event happened.
The piece that's missing is what are the other nine VMS that it
wasn't a ransomware event, It was just command and control.
Just command. That's why you have to have the
two of them together. You, you need that understanding
of everything. So it's really cool.
Yeah, I think the the way they explained and especially with
the correlation, I think that is really important.
And I'm going to show that of course in the demo.
But I've said that that explorer as well, if you look at VLR, it
provides the ability to show you, you know, the, the, the
change rate that happened and the entropy, so the randomness
of the data. But there is not a guarantee
that that was the actual point in time that you were
compromised. You still got to restore.
Look at it and check it and make sure that yeah, that's why they
have to be. Guessing in some sort of way
based on what we see from a data point of view, but not what is
actually happening from a networking stream point.
So I think this is a fantastic story end to end.
Now, of course when I listen to this as a as a storage geek, one
of the things that immediately pops up because we're talking
about inspecting traffic streams, we're talking about
firewalls, disputed or gateway firewalls, etcetera.
It does sound and of no, of course it's based on, you know,
the hypervisor component, but it does sound that it could
potentially impact the workload in terms of latency.
So from a performance perspective, do people need to
be concerned about that at all, or is that something that, you
know, we can forget about? So you absolutely have to be
concerned with it, but only if you decide not to build policy
using best practices. And, and it's a great question
because it comes up, you know, anybody who's a virtualization
person does exactly what you did.
They start thinking, OK, in my hypervisor, in my hyper, OK,
that's more in my hypervisor. What's the impact in my
hypervisor and is it actually going to impact the workload?
So let's look at it this way. If you treat the the V defend
firewall like a traditional firewall, and let's say your
traditional firewall has 10,000 rules.
If the rule that allows or blocks the traffic for any given
VM flow, if the rule that allows or blocks is rule #9999.
And I've got to get to that. Every time this flow happens,
you are absolutely going to have a performance hit.
There's no way around it. And, and, and, and remember,
take that exponentially across every other VM.
It may not be 9999, but it may be 8000.
It may be fine, right? You're still going through a
lot. So when I talked about one of
the advantages of our product being the management plane, this
is part of it. So we've actually designed into
the product that we build efficiency into the way that the
policies are applied to AVM that we actually have a feature
called applied to. So if I take a particular VM and
there's 10,000 policies, of those 10,000, there might be 8
that are relevant to this. So I filter out every other rule
and now we only have 8. You're not going to know with
eight, eight is not going to impact the performance of the
virtual machine. So you do have to follow our
best practice. You do have to have the security
mindset shift of I'm not going to treat the V defend firewall
like a physical firewall and micromanage from this one to
this one using IP. It doesn't work that way.
It's really hard to manage, it's hard to scale and it's not
efficient. But if you buy into the
management platform and the strategy, then we don't have
those types of issues. Now, of course, with security,
it is universal truth that nothing will ever, ever, ever,
ever perform better if you apply security than not having to
secure. There's just no way, right?
Same thing with manageability. Nothing will ever, ever, ever be
easier to manage if you didn't have to secure it.
So when you look at it, if I add IDSIPS to the mix, IDSIPS is
more security overhead. Now, we've done a really good
job with the latest version of the product to have something
called IDSIPS Turbo Mode. So let's take a 10 gig Nic for
example. On a 10 gig Nic, if you did
IDSIPS before turbo mode, it took your throughput from 10
gigs to three gigs. Ouch, right?
I mean, that's a big hit from a security perspective.
So now with Turbo mode, we've 3X the throughput. 10 gig Nic will
take you to 9:00, but you get IDSIPS.
So you, you know, when you design, there's always a
balance. You always have to figure out
where, where do I balance these things?
I, I don't want extreme difficulty in management at the
expense of getting my super security.
I want good security, but I want my manageability to be retained.
So it's not that difficult. So some things can coexist and
some things cannot. It's where do you find that
balance between the two? And that's where I think we've
done a really good job of being able to improve security
dramatically, but minimizing the impact to manage.
Now, before we actually started recording, one of the things
that you mentioned is that you would easily fill up the hour.
And I think we're starting to reach that hour.
So the last thing I actually want to do is ask you to give
your elevator pitch to us and explain why customers should
actually buy V defense in just two or three sentences.
And I know that's going to be hard for you, but try to stick
it to just a few sentences. Toughest part of the whole
thing, Yeah. No, honestly, I think it's
simple. I think V Defend changes the
security paradigm in a way that allows customers to buy down
risk as quickly as possible without having to change
existing infrastructure. There is no other tool that's
going to allow them to do that. There is no other tool that's
going to scale the way that V Defend product suite scales.
It's just as simple as that, but it requires you to think
differently about security. That's the biggest challenge.
It's not a technology thing, it's a people thing.
And if you want to solve problems from a security
perspective in today's modern private cloud, and we love that
term, then you have to think about security that's embedded
into the architecture, not an add on to the problem.
Fantastic, Chris. Now, before I let you go, any
famous last words or any final thoughts you would like to share
with the audience? Well, look, you know the last
few years have been interesting to be to go from this transition
from VM Ware to Broadcom. But I will say this, as much
hesitancy as there might have been to see this renewed focus
and this laser sharp focus on private cloud, I think has been
a phenomenal change for me personally, but for the
organization too. And I don't know your feelings
on this, but I feel like in the last two years we have achieved
more from an engineering standpoint than we had in the
previous five or six or seven years.
And so it really forced everybody to start to think
about how important the the collective pieces of private
cloud really were. And now I think we're past the
point where customers see it as a bad thing.
And they're really starting to say this actually helps us, this
is better for us as a customer to look at this entire stack and
see how it solves business problems.
So it's been an interesting transition from VMR to Broadcom
and it's been an interesting transition from the first year
of Broadcom to going on to the third year of Broadcom.
But customers are starting to buy into the strategy and
they're starting to recognize the value.
And what I see happening now it probably over the next three to
five years is the continued, I guess you could say consumption
of other products, right? V San may not be deployed on day
one, but in 12 months, 18 months, when a customer says
it's time for a storage refresh and they realize, holy cow, I've
already got what I need in V San boom, now we're going to see
more V SAN. Same with the networking when,
when a customer looks 12 months down the road and says, hey,
it's time to revamp our Dr. strategy, let's stretch layer 2
boom, we already own NSX. So that continued consumption
and value that customers are going to get back because they
own these assets already as part of the private cloud.
I think I'm really excited to to see those things come to
fruition. Well, I couldn't agree more
Chris. Thanks for that amazing episode.
Thanks Duncan, It's fun. And that's it.
Thanks for tuning in to the Unexplored Territory podcast.
If you enjoyed this episode, don't forget to subscribe and
leave a reviewer rating wherever possible.
And please join us again next time as we cover more insights
into cutting edge solutions shaping the world of IT.
Until then, staying comfortable, keep exploring.