All right, well, let's kick it off here.
So happy New Year, everybody.
It's Wednesday, January 17th.
It is 2024.
Welcome to the first Security in 45 show of the year.
Last episode, we covered the introduction to this session.
We had Sudhir on with Ed as well,
and we were talking about an introduction
to cloud security and the great benefits
that come with moving data, apps,
and resources up to the cloud.
And then we kind of started alluding into a big misconception
in the industry, which is the assumption that our cloud
resources are safe.
Now, cloud-specific attacks, including the ones
we talked about on the last call, big ones, Facebook,
LinkedIn, those collectively cost customers billions
of dollars.
So unless you have a security-specific agreement
with your cloud provider, please do not
assume your resources are safe.
Now, today is the follow-up to that previous session.
And we are going to focus on the security aspect
here with an exciting new product called
Cisco Multi-Cloud Defense.
Yeah, Mike, thank you.
And happy New Year to everybody here.
Happy New Year to everybody listening in for Security in 45.
I can't believe it's 2024.
I know, man.
I know.
It's crazy.
But no, for anybody who missed the previous episode,
it was an entrance to cloud security, as Mike just
mentioned.
It was really nice.
We got to hear from our experts on what
are the things that we need to consider,
talking about security in the cloud.
It was really nice.
And the product that we're covering today is interesting.
It's something new that actually that happened really quick.
It happened last year, and we're really integrated
into a lot of our products.
And for today, our guests, Jason and Sudhir are here.
They're two experts in cloud security.
And we're super excited to have them here.
And of course, we have a great lineup,
like we always want to have every episode.
So we're super happy to be joined by Jason and Sudhir.
So let's get started.
All right, awesome.
Yeah.
Sudhir, Jason, glad to have you on the show.
Sudhir, are we talking about it?
Absolutely.
And Jason, I know you specifically
work with this product.
So I really appreciate the time from both of you.
Well, let's jump into it.
Jason, I'll start with you being the product expert here
on this specific solution.
Could you give us just kind of a high level, what
is multi-cloud defense?
What kind of problems is it trying to solve?
Yeah, man.
Thanks for having me, by the way.
Appreciate it.
Any opportunity to talk about it is going to be taken.
So yeah, at a high level, really what this product is
and what it gives us is, and let me actually
step back, pre-acquisition.
It was a company called Valtix.
And it was ex-Cisco engineers who started the company.
They saw a niche that wasn't necessarily
being addressed at the time.
Everything originally, pre-this, was
people trying to take something that they knew,
like a virtual version of a Palo or an ASA or an FTD,
and trying to port it over to the cloud and use it over there.
And to some extent, it works.
There's always going to be some hurdles.
But they weren't purpose-built for the cloud.
So what they tried to do is create a cloud-native solution,
something that was purpose-built for the cloud, that would,
one, allow us to reduce tool sprawl,
because all these cloud providers, as you guys know,
they all speak different languages.
So they might call something, one thing's a VPC.
It's a VNet over here, VPC again over here.
All those constructs make the infrastructure
kind of hard to handle.
For somebody who may be new to cloud, even somebody who's
well-versed in cloud, like myself, sometimes I go in there
and I stumble around trying to kick up
architectures and infrastructure.
So they tried to ease that.
How can we take away some of the infrastructure complexity,
take it off our customers' plates,
and move them more to where they're consuming security
more easily?
And that's exactly what they did.
They went out there and they said, hey,
how can we automate the vast majority
of this infrastructure, kind of overhead that we have?
Even if we're moving a physical appliance
in a virtual format over, you have
to configure all the underlying infrastructure.
So they automate that to the best of their abilities.
You can't meet every use case, but the 80-20 rule
kind of applied.
They said, hey, let's automate what
we can from an infrastructure perspective,
and then let's lay these gateways down.
And this reduces tool sprawl.
All these vendors, they have different services
for things like IPS, IDS, anti-malware, data loss
prevention.
How can we reduce that sprawl of tooling
that customers are having to kind of use
and move it into maybe the guise of a single tool?
And that's really what we're doing here.
That's great.
I know we'll get more into it, but I'm
real interested to hear about how it does.
You mentioned the abstraction of the clouds
and kind of this is a product of simplicity,
which everyone in the world is looking for,
because as you mentioned, the tool sprawl.
So I know we'll get to kind of you
mentioned you being very familiar with how
these each individual cloud providers work, AWS, Azure, GCP.
But I'll be curious.
I know we'll talk more about that coming up.
But my takeaway so far, native built into the cloud.
It's abstracting how each individual cloud works
and kind of simplifying all of that.
I don't know if anybody else has a comment there, takeaway.
Looks like it's going to bring a lot of great features
and simplicity.
Everybody's looking for simplicity today,
network, security, all the things that we do
get very complicated at times.
So that's really good to hear.
So let me ask you real quick, what about,
how's the deployment work?
Is it turnkey?
Is this a solution that it is just we deploy and we're
good to go?
Can you tell us a little bit about that if you don't mind?
Sure.
So the solution itself is, while it's individual
for each customer, depending on which clouds they have deployed,
whether it's Google or Microsoft or Amazon,
it does come down to a single basic framework
that you go and you click a couple of buttons
and you have it install into that network.
Now, I think for me, the biggest part of the deployment for me
was getting all the information together.
And I would say it maybe took 45 minutes to an hour at most,
with the majority of that being the information collection
phase once I plugged everything into the scripts.
And I think we'll talk about this in a little bit later on.
But it's all automated.
And basically, one click of a button, fill the information out,
and you have deployed virtual private networks or VPCs
on, I believe, both Google and AWS.
And outside of that, it's fairly simple.
The one cool thing you can do, or not the cool thing you can do,
but to get to multi-cloud defense, it's very simple as well.
You just go through Defense Orchestrator.
So like CDO, right?
Yeah, CDO.
Cisco Defense Orchestrator.
I love all the acronyms.
I'm not good at the acronyms, so I apologize.
Yeah, the CDO.
You go through CDO to get to it.
And it's very straightforward from there.
Basically, you click the link in the According menu on the left,
and you get to multi-cloud defense.
Well, just to clarify, all that's done from our SAT,
there's two portions of this, right?
The SAS controller, which is where
he's kind of referring to all the control and management,
like that a customer would log in would
be done from that controller.
But the deployment of the infrastructure,
which we deliver as PaaS, Platform as a Service,
is actually, so all the VPCs, the VNets, the security
gateways, those are all actually deployed in the customer's
infrastructure, right?
So again, keeping all that, and we'll
talk about the security features later,
but keeping all that data kind of local
to a customer's infrastructure.
So we're not shipping data off to somebody else's cloud
to provide security, right?
It's all done locally within their cloud environments.
That's good.
I mean, I think going again with the simplicity
just makes a lot of sense to, like if it's
that simple to just implement that,
that sounds like a really good solution, I guess.
What about scaling?
As my cloud resources grow, is this
going to scale with the growth of my business?
Assuming, yes.
Yes.
Yeah, and it's pretty linear with the load,
as load increases.
The provisioning of resources on the multi-cloud defense side
also crack of that.
I like that.
Yeah.
I like that.
There's vertical scaling.
So like the gateways that we deploy within every cloud
provider, there's several, we call them vertical scaling
options where you can do two, four, eight virtual CPUs.
But then we also do horizontal auto scaling horizontally,
meaning per availability zone, if you initially
deploy a single gateway, we actually
add SLAs on the controller where if bandwidth, CPU,
or memory actually exceeds a predefined threshold,
we'll actually scale those out for you
without customers having to do anything.
And then as soon as that threshold is kind of crossed
in the other direction for a specific period of time,
we'll actually scale them back in.
So you're again, very cloud native.
You're only kind of using what you actually
need at any given point in time.
That's awesome.
Now, some of the internal trainings that I've seen here
at Cisco talk a lot about what it
means to have a unified policy.
So I'd like to, Jason, ask you a little bit about what
a unified policy is and kind of how
that relates into the product.
And I'm assuming that this is going
to tie in with various different cloud providers
and unifying it all together.
Yeah, exactly.
And I always call it the utopian vision for policies.
It's something everybody strives for,
but very rarely achieved.
And you can't do it with this product.
That's the thing.
It is achievable, but it's commonly
operational problems on the customer side
or just disparate teams that cause it not to actually happen.
But that vision is that you can have a single policy,
like my cloud workload out to the internet policy,
a single policy that could be applied to security devices,
gateways, in Google Cloud, AWS, Azure, OCI.
And that single policy that you have
could work regardless of where it's physically put.
And we do that by a couple of means.
One is when we connect those cloud accounts
to multi-cloud defense, we're actually
reading an inventory, very similar to what
you'd see from a cloud security posture management system.
Like Jupiter 1 or our Panoptica with LightSpin solution,
where we can pull inventory information, metadata,
and then we can use that metadata to group things together
into object groups, or we can define policy against it,
or a combination of both.
But it makes it to where, instead of using
your common network boundaries, like IP address or CIDR blocks,
we can say things like, hey, if your environment equals
production, we're going to allow you to get out to the internet.
If your environment equals production,
we're not going to allow you to talk to environment dev.
It becomes, one, much more human readable,
and two, very dynamic, because then any additional workloads
that pop up in what is a very ephemeral cloud environment,
we're going to be able to apply policy pretty much
in real time.
So in that rule, you said production
can maybe reach out to a different group
or out to wherever.
As I onboard more resources, I can just
drop them in that production group,
and I don't need to worry about on the back end
which cloud they're part of and how that's set up.
I just add them to the group.
Exactly.
And that's one thing I've been evangelizing.
When I go out and do tech days in these events,
Cisco Live presentations, it's having a source of truth
for tagging and labeling becomes super important
when you start to use this metadata defined policy.
Because now you have a place that you
can go to that, if you have ServiceNow workflows that
are kicking up workloads, they can automatically
pull from this source of truth to apply the proper tags
and labels.
But then you have to start protecting
that source of truth, right?
Because it becomes, if tags and metadata
is starting to define policy, a user theoretically
could go in and just manipulate tags to manipulate policy.
Makes sense.
And let me ask you, Jason, is, and I
know this is kind of industry standard in cloud security.
Everybody is getting into the motion
of adding tags into workloads or instances and things like that.
But is there a possibility that we
can use anything different other than tags
for creating that policy?
Yeah, yeah.
We bring in, so we don't bring in all inventory.
But what they did bring in was what they thought
was important to network security.
So you're going to see things like VPC IDs,
actually a really good question.
I appreciate that.
Because a lot of people, they move into the cloud
and they're like, hey, we still want to use subnet boundaries.
We still, we know that this IP cider block
can talk to this one.
We kind of urge them, hey, while that's still applicable,
you can very much do it within the system.
Let's think outside the box in more cloud native terms.
And maybe use things like subnet IDs
that are being provided through cloud-based metadata or VPC
IDs that we can then use.
And again, one, it's a little bit more dynamic.
Two, it's a little bit more cloud native
in terms of what construct you're
using to define that policy.
Yeah, I think that's what the standard is going to,
to make sure everybody's tagging their infrastructure,
everybody's putting some information there.
Well, and the one thing you always have to have applied,
like if you're thinking about AWS, for instance,
you always have to have a security group applied.
You can actually group things together by security group
within AWS, for instance.
We can use security group identifiers
as a basis to group things together or define policy
again.
So again, just kind of changing the way
we think a little bit as we move to cloud
and the ways we think about policy.
That's nice.
I guess, Sudhir, I have the next question for you.
And this is more on all the things
that we see about multi-cloud defense, what we have,
for example, in our page.
There's a big call about visibility.
If you don't mind sharing with us,
what do you get to see with multi-cloud defense
when we talk about visibility?
Sure.
So in terms of visibility, multi-cloud defense
does act on both north-south traffic, so on-premises
to cloud or cloud-to-on-premises or cloud
to external other clouds, as well as east-west traffic,
which is internal to that cloud.
So within AWS, different parts of your network in the cloud,
you get visibility into that.
And the multi-cloud defense does act on that traffic.
Now, a little kind of gotcha here.
You won't necessarily see logs for that activity
until you enable log profiling, stuff like that, where
by default, you're not going to see anything.
But if you do enable those logs, sorry, when I say by default,
you will see activity and you will see data
within Defense Orchestrator.
But for external tools and for getting things out
to Splunk, as an example, we do have specific connectors
for that.
So Google's log collector or Splunk or Datadog
is another one that we have a native connector for to provide
additional logging capabilities out to those sources.
Because what we like to do is we like
to have more complete logging versus just sending 128 bytes
or 300 bytes of a syslog message out to whatever
that connection was.
The log connectors themselves give you
a much more complete view of all the traffic going in
and through the network.
So that's what we do.
And it's pre-formatted, right?
Yeah, it could be in JSON instead of just raw text.
Right, exactly, exactly.
What about integration with any type of,
I'm just thinking threat feeds or any way to?
Yeah, so in terms of threat feeds,
you can import feeds from Bright Cloud,
from TALOS, different sources to give you
a bit more security intelligence into what you're doing.
Yeah, it'll actually, if you are bringing your VPC or VNet flow
logs and multi-cloud defense has some vantage point
into what's actually flying around in your cloud
environments.
It does bring in TrustWave, Bright Cloud for malicious IP
feeds, right?
So that we can at least correlate,
hey, you've got some workloads that are maybe talking out
bound to known malicious IPs or FQDNs.
And it might be some low hanging fruit for people to go in
and kind of pick off or investigate.
Now, so that's great visibility, east, west, north, south.
And I've been on customer calls where customers are moving away
from the traditional, hey, I'm manually
managing some type of virtual firewall in the cloud
and moving to this multi-cloud defense solution.
I'm curious what kind of, in terms of controls,
like if we're replacing a virtual firewall,
I'm assuming there's similar or more controls
in this solution as well.
How about if you can touch on the controls,
maybe any type of automation would be cool?
Yeah, yeah.
So pretty much anything you get with the standard next gen
firewall, you're going to get with this solution.
They built part of the intellectual property
of this was the security pipeline
that the developers actually built,
which the developers were actually the founders, funny
enough.
They built what's called a flexible single pass data path
pipeline.
And that's a mouthful, I know.
But what it is is a very efficient pipeline
that's only going to be passed through a single time.
There's no looping back through specific portions
of the pipeline.
So it really minimizes the impact
of bandwidth and latency.
But it's everything you could imagine.
So you're going to go through your typical layer three,
layer four firewall stuff, so your matching criteria,
like source and destination IP port protocol.
In addition to that, actually, there
was a lot of use cases early on to push out some,
and I'm sure, squid proxies.
So squid proxies were very prevalent.
And a lot of major enterprises.
But once you get hundreds of squid proxies out there,
they become a little bit cumbersome to manage.
So they agreed to move to multi-cloud defense
if we had an FQDN match criteria.
So very similar.
How can I match a flow based on source or destination IP
or port?
Now they've added FQDN matching so
that we can identify a specific flow based on, hey,
something's egressing to this domain.
Beyond that, though, everything you
could imagine in terms of TLS based decryption,
being able to do IPS, IDS, we do have the snort engine running,
anti-malware, we do data loss prevention, and URL filtering,
which is distinctly different from FQDN filtering,
as most of us know.
But yeah, it's a fully featured security pipeline.
And any of those can be turned off or on,
much like you'd see with Firepower,
on a per rule basis.
So you could come in and say, hey,
I don't want any advanced security running
with regards to this flow.
Just match it based on the five tuple header
and permit or deny, and then let it go.
Or you could selectively add on any of those additional security
features.
So a couple you mentioned, the TLS decryption, the IPS,
the anti-virus, like file type inspections, URL filtering,
domain filtering.
What about geolocation?
Can this solution, does it have any type of geo stuff
filled into it?
Yeah, absolutely.
They have all the predefined blocks for every country
in the world.
So you can go in and selectively,
and use that as part of your matching criteria.
Same thing, actually, now that you bring it up.
Malicious IPs can be, and we baked those in
from a predefined threat feed now.
So yeah, you can selectively deny stuff or permit stuff
from different countries.
Any DLP?
Yes, the data loss prevention is all control.
Of course, it operates better if we can see into the payload.
So if it's encrypted, have a decryption profile.
But it's all using Parallel Compatible RedWax.
Super stupid flexible in terms of implementation.
And all this, mind you, can be done through Terraform.
Like this was purpose built for the cloud.
So what they did, and apologies if you hear my dog,
all of this was done.
Wait, not dogs.
I've got, Andre says that little Hope dog that's
always on his shoulder.
And oh, there he is.
And I've got those two great dancers.
Sidir, I know you're a big dog guy too.
Anything you do through click ops in our UI
can be done with Terraform.
And we actually, our Terraform provider
is probably better documented than our UI.
And everything that you do in the UI,
there is a corresponding Terraform export
for that specific object.
So you can move literally from no Terraform experience
to everything being baked in using a Terraform or CI-CD
pipeline.
It's very slick.
I want to ask you something.
And hopefully I'm not derailing the whole thing.
But wanted to ask you, for customers that, let's say,
they do have a cloud presence and they're
looking to connect their on-prem infrastructure
to multi-cloud defense, what is required from them
on their end?
Oh, who's been whispering in your ear?
Has someone been telling you?
No.
We actually have VPN coming out.
It's supposed to be out in February.
I've seen it.
It's an engineering preview.
So we're going to have VPN functionality for on-prem
to cloud, cloud to cloud.
And that's going to be supplemented with BGP.
So we're going to have the ability to do IPsec as well
as BGP routing from the gateways themselves.
It's actually a long story, right?
But the short version of it is, think of companies like Aviatrix
who do multi-cloud connectivity very well.
They went into it with the mindset of, hey,
let's get cloud networking done right.
Security was kind of an afterthought.
We went into it with security is our main focus.
Networking is kind of going to be an afterthought, right?
So now it's coming kind of full circle
where now that we're integrated with Cisco,
we're really moving into how do we
integrate some advanced networking capabilities,
really ease that cloud transition for our customers,
not only in terms of security, but also connectivity.
Well, that's good.
That's good information.
I think I've heard a few customers
asking about those things.
So just wanted to make sure that I'll put it in there.
I guess for the next question I have,
Sudhir, if you don't mind, this one
is based on alerting what do we get, like when we see a tread,
what are the things that we can tell from the management
perspective?
Yeah, so a couple of things.
And it really depends how you have things
set up in your environment.
By going from like a zero nothing environment,
not much in the way of actual, no really repercussions
for things that are going on.
You'll get alerts for them, but you may not
get the behavior you expect from a traditional ASA firewall,
where the bottom line is it blocks everything.
So it actually brings up a great point
that one of the things we do recommend
when you do set this product up, when you do set multi-cloud
defense up, is to go in and say, hey, I
want to make sure that I've only set my configuration says
I know exactly what traffic needs to go from one place
to another, and that's it.
So one thing we do recommend, strongly recommend,
is to set up a baseline deny everything rule.
Just black hole it.
Because when we're talking about security,
we talked about this in the last section as well,
but you define your own security posture.
The clouds aren't going to define the security posture.
And I think you even mentioned this at one point, Andres,
not today, but in the past, it's kind of flipping around
what a firewall does, where it's allowing everything
until you put blocks in to stop things.
So you need to go through, look at the alerts that come in,
and that's one thing that's great about multi-cloud
defense being within Defense Orchestrator
is that we also have the tie-in to XDR,
where you can come through and build out automations.
You can do different things.
And also being Terraform native, where you can come through
and say, hey, if I see this traffic,
I don't want this traffic.
Let's set an automation to run, or let's do something that
says, hey, if I see this, send it back through
and make sure a rule is in place to block it.
Or utilizing dynamic access lists as an example.
And what Jason mentioned earlier regarding
the IDs for the networks and the IDs for the subnets,
hey, I see this traffic trying to reach this one subnet
I don't want it to go to.
Utilizing that subnet ID and being completely dynamic,
you can go and very granularly control what traffic comes in,
goes out in, I guess, I don't want to say cloud native again,
but in a very automated way that happens today versus in the past
where you'd have to go in and say,
deny all IP any, any whatever.
Completely agree.
AWS, by the way, is full whitelist only.
Even when you go in to do an AWS security group,
it's a deny all.
They make you explicitly define what traffic you want to allow.
And it's really the way, we've been preaching zero trust
for years and years and years.
And very few have actually implemented it.
And at least they're urging us or pushing us
a little bit in that direction.
Yeah, I think it's going in that direction at some point.
And just to give credit on that sentence to flip the firewall,
I think I heard about this on the Talos podcast,
probably like two episodes before,
the one from December or November,
but it was very interesting.
It kept me thinking for like five minutes,
flip the firewall, how do we do that?
And so that's that's like way on that.
Definitely a different way of thinking about writing your rules.
One thing I was going to mention,
Siri, you mentioned XDR and how we can automate do workflows.
So we did have a session on Cisco XDR.
So, you know, everybody go back and check that out if you didn't see.
And it'll make a lot more sense if you're wondering what is XDR,
how does it integrate?
And we on that episode, we did talk about specifically Cisco XDR as well.
So I think that will benefit a lot of people.
All right.
I think a question on a lot of people's minds is,
I like the simplicity of this product and then the breadth of it.
And I don't have to know about these individual clouds,
which is great, abstracting all that.
But is this just on top of basically,
do I need to buy additional security if I own this product?
Is this product a true replacement for the virtual firewalls I may have already?
Is it all I need? Is it all I need to secure my cloud presence?
Yeah, we actually we get this a lot, right?
We have kind of two camps.
We have the camp where they've they've went the virtual route.
They're kind of deploying their own thing,
whether that's a Cisco, Palo, Fortinet.
They're just pushing those virtual appliances out there and they're running with it
because they're familiar with it, right?
And they work, right?
But there's still a lot of overhead and then management.
And then when you start to think about things like HA,
we're just much simpler because we were built specifically for the cloud.
Can we replace them? Yes, absolutely.
We do every day.
Same thing with cloud native tools.
So you think about things like the Azure firewalls,
same thing in Google Cloud, you know, security groups,
security groups like within AWS, they're still going to be in the mix, right?
Because they have to be attached to VNICs.
But what we do is we kind of add additional security capabilities.
You can have a permit all in your security group.
You're still going to get advanced network security using our gateways.
What we do see a lot, though, is customers are kind of locked into the cloud provider
or cloud native tooling, like the specific things like the the GCP firewall,
the Azure firewall.
And, yeah, we can we can replace those two, which becomes very nice
for a lot of customers because those are very expensive in terms of a lot
of those firewalls from the cloud providers charge based on like
how much bandwidth you're pushing, which can get crazy, stupid expensive.
It was just going to mention that.
Was just going to mention that in terms of scaling, too.
If you if you if you're scaling up, you're going to have to pay more
if you're using a cloud specific firewall.
100 percent. Yeah.
So we've seen like some customers drastically reduce their cloud charges
by moving to multi cloud defense and just decommissioning those products.
Because, again, now you're if you think about it, that could the
firewalling capabilities within Azure, you could be using a very minimal
set of capabilities within there and still have pretty exorbitant charges.
We're actually going to give you a point solution that can be used
across all your different cloud providers from a single SAS controller
that is normally going to be significantly cheaper in the long run.
Interesting. And I'm just thinking in terms of staging it and having kind of
a zero downtime or at least zero downtime in terms of security.
Can I deploy multi cloud defense out?
Can I have my existing firewalls in place, deploy multi cloud
defense on top of them initially, see everything working well and then go
back and decommission those individual Azure firewalls and just leaving
multi cloud defense in place at that point?
Now, good question, Mike. Absolutely.
That's our primary use case.
Like people are already in the cloud.
They've got brownfield operating as it is right there on Internet gateways,
et cetera. You can deploy again, even from a fully orchestrated
standpoint, you can deploy all your centralized kind of hub security
VPCs or VNets, deploy the gateways to find the rules and all that can be
done with your existing infrastructure kind of just doing its thing.
When it's time to cut over, we can actually handle all the route plumbing
as well, meaning you can go in and say, hey, I want to connect this kind of
spoke VPC to our new security hub and we will actually attach it to transit
gateways or do peerings and then adjust the routing to go over those
peerings rather than out the local Internet gateway for those spokes.
That's great.
It's a mouthful.
But that's interesting to hear all that information.
I really like all the details that we've gone through.
So I guess everybody in the audience is going to appreciate that.
And I think that was one of the questions that we mainly wanted to hear.
I know it was a little bit controversial with the existing infrastructure
and things like that.
But the other question that is on people's minds today is how do we get started?
And if you don't mind mentioning some of how customers will get started,
POVs, trials, what do we do to start playing with multi cloud defense?
Yeah, it's funny.
This question is coming up because Corey also asked it in the Q&A panel where
basically if you have defense orchestrator now on the accordion menu on
the left hand side of the screen for defense orchestrator, there is a
multi cloud defense tie in.
Click there and then you can start playing around with multi cloud defense.
If you don't have defense orchestrator, you can always spin up a trial for that
and multi cloud defense trial is kind of built into that as well.
So there are a number of ways you can get to it.
Then once you do that, definitely reach out to if you know your Cisco security
team, your security sales specialist or your security account manager,
reach out to them and we can get you tied in with whatever level of technical
depth and whatever detail you need to make the trial successful and then make
the implementation successful.
I think Jason mentioned this a bit earlier where the guys who built out
multi cloud defense, but it was Voltex, they're still with us.
They're here at Cisco now and depending on the level of need, they can even step
in and say, hey, this is where we intended to go.
This is what we think will be beneficial to you, Mr.
Customer, to be successful in your deployment.
The process itself is click, click, click and you have a trial, maybe four.
Always compare it.
Do you guys have kids?
There was a show called Oh So Special.
Do you guys ever watch this?
It's like a bear, right?
And he was always solving these mysteries and it was always three simple steps.
Our wizard is actually three simple steps.
It's like literally onboarding telemetry security.
It's stupid simple to go through.
We've done POVs where we've had people soup to nuts, like where they didn't have
anything deployed, so they had multi cloud defense, gateways running and passing
traffic in 90 minutes.
Nice.
And Sidhu, you had mentioned you set this up on your own and the biggest part was
when you mentioned the gathering of information, were you talking about like
the inventory of where your cloud assets are?
Yeah, just making sure that the admin user was there properly, the type of admin
user and making sure we just actually, we just talked about permissions and making
sure like zero trust side of things, but making sure that the users I wanted to
use for multi cloud defense were actually users that had the minimum amount of
permissions to have a successful deployment of multi cloud defense.
Yeah.
That's awesome.
That's often the stumbling block for POVs is customers just figuring out what
accounts they can use to onboard the accounts that has sufficient privileges.
Once they get past that, it's clear as hell.
And bottom line is we come in and Cisco is going to give some assistance there to
get someone up and running.
I assume so, like basically all products.
What about package tiers or like offering levels?
Yeah, so there are currently two offerings.
I mean, I think it would be cool if we had three offerings, but I guess, you know,
we're not doing the whole essentials advantage in Premiere for multi cloud
defense, we're just doing advantage in Premiere.
But actually, in my opinion, I guess if you don't need it, you don't need it.
But a couple of my customers this past quarter had asked me about APIs and about
making sure that their APIs weren't getting abused.
So let's say one of my customers had a bunch of Lambda functions in AWS.
How do we make sure that people can't brute force those APIs and, you know,
you're kind of stuck at the end of the day since there's no real there isn't a
real like DDoS solution for cloud based materials, cloud based services.
A cool thing about the Premiere package for multi cloud defense is that it does
contain that capability.
So that's, in my opinion, one of coming from more of a programming side, one of
the biggest differentiators for me between Premiere and advantage is getting
the ability to actually do that rate limiting.
Another thing that's cool is that you can now do more of a like an upload
download system or you can file share within the clouds.
And with the Premiere package, you get antivirus, anti malware built into that
outside of, you know, on the advantage side, you have your basic ideas.
Some of the features we chatted about before, but then on the Premiere side,
you get antivirus and you also get the I think Joel mentioned this in a question.
What if we want to replace our web application firewall?
That's one of the other features that is brought through with the Premiere package
that you actually get a web application firewall replacement.
So maybe you have, you know, I think we mentioned this earlier, a bunch of
different products that are kind of bolted into the cloud and aren't exactly,
sorry, again, cloud native, but cloud native, they're not exactly cloud native.
So with the Premiere side, you can actually go through and actually rip out
everything, you know, as Joel was asking, the straight replacement of all these
things.
Yeah, literally is a straight replacement of all these things.
Yeah, thanks for the question, Joel.
That's a good one.
And thank you, Sudhir, for the answer.
Real brief, and I don't know, Jason, you work specifically on this product.
So I don't know if you had any customer success stories or anything you can share
about any customers that have done this journey.
Yeah, yeah, actually, Teradata, there's a publicly referenceable white paper from
Cisco on Teradata, who's probably to date our largest customer with thousands of
gateways deployed.
It'll kind of tell the success criteria from them as to like what both
operational and technology benefits they gained by moving from what they were
using to multi-cloud defense, which were many, right?
And they're a full Terraform shop.
So as they like onboard new customers, they actually fully automate the
provisioning of the gateways, the service VPCs and the rule sets as they kind of
onboard new customers.
Very good read.
Yeah, and that's great.
It's publicly available.
So we'll put that in the webinar notes as well.
So that's outstanding.
Well, that's all the questions that we had for our guests.
Let's move on to some serious business now.
And I don't know how I feel about these questions because they're a little funny,
but I'm just going to jump right into it.
So Jason, I wanted to tell you about over the break, I did spin up Cisco's cloud
email security solution over Christmas break.
So just not going to talk for.
OK, that's all right.
That's all right.
Now, it worked great at first, this email solution.
But I had to take it for some therapy sessions because it was feeling
overwhelmed shortly after I enabled it.
Any idea why it was feeling overwhelmed and so stressed out?
No idea.
Did it get sick?
It had too many attachment issues.
Oh, my gosh.
So yeah.
We got those attachment issues resolved, and my email security solution's
doing great now.
Awesome.
Let's see if I can pop that one out, Mike.
I told you, I told you, I wasn't sure how I felt about these ones, but OK.
Awesome.
Now, we're talking about therapy.
And speaking of cloud-specific therapy issues,
I heard that Azure AD started taking therapy sessions as well.
Do you guys know why?
No.
Apparently, it has a lot of identity problems it's working through.
I'll give you that.
How about another thing I did over Christmas break,
there was a really nice wedding I went to.
There were two 5G towers.
They were getting married.
How do you think the wedding went?
Everybody got COVID.
Yes.
The ceremony was kind of average, but the reception was amazing.
Probably got time for one more, Andres.
Promise is the last one.
Did you guys see the news reports about restaurants
trying to find more people who are good at Microsoft Excel?
Have you guys heard about that?
Because apparently, it's very hard to find food industry workers who
are really good at joining tables.
I worked at a restaurant for years.
I don't think I could join two tables on Microsoft Excel,
so I won't be able to apply for that restaurant job.
Oh, that's great.
That's great.
So thanks for containing yourself, everyone, during those amazing dad
jokes.
And Andres, I guess let's wrap this up and conclude it out.
My personal takeaways, I know Jason started off
giving that kind of high level overview.
It's a SaaS-based offering.
And one of the things you mentioned or you alluded to
was that this is going to be single or multi-cloud.
So I thought that was cool.
Even if I just have my resources in one cloud,
this still works just the same.
It's called multi-cloud defense, but even single or multi-cloud.
And that being a turnkey, ready-to-go solution.
And you guys both talked multiple times about native integrations,
which is key here.
It's pre-built into the various cloud providers.
And I really like the unified policy.
For me, one of the biggest things, takeaways today,
was that I don't need to be an expert on how AWS works versus Azure versus Google.
This product is abstracting those differences
because they really shouldn't matter when I'm doing intent-based security.
And then Sudhir, we talked about, I think that went to you, visibility.
Not just the north-south, but the east-west.
Pretty cool there.
And we talked about some of those threat feeds.
I think you mentioned Datadog and the others, Asplunk.
Those were the log profiles, yeah.
Those are the log providers, yes, yes.
Thank you, Jason.
So yeah, those were my main takeaways.
Andres?
Yeah, I really feel the takeaways that I have for me,
similar things that we do have with infrastructure today with next generation firewalls,
which is geolocation, the IPS, the malware prevention, things like that.
We already have in our infrastructures.
It makes a lot of sense to also have it there.
I know we mentioned the LP, and I know we also squeezing a little bit on the WAF piece,
which I think was super interesting.
The alerting, those things, those connectors that we can have with multiple sources
and multiple things just to make sure that we make sense of alerts and things that we see.
And the other one that I was thinking that it was interesting to hear,
and it's going to be that multi-cloud defense is looking like it's everything that we need
if we're going to a cloud with no additional things to think about.
The last thing, just like any other product that we work with here in Cisco,
is that ease or simplicity on how we get started.
Just make sure you know about Cisco Defense Orchestrator.
That's the place where you can start a trial, start playing with multi-cloud defense.
So with that, I think that's all I had.
And Jason, to make sure I got that right with the specific connectors,
Splunk, Datadog, and Google Log Collector.
Yeah, GCP Logging.
I've got some others, but yeah, they're all in there.
Wanted to make sure I had that right. Thank you so much.
Jason, Sudhir, thank you both so much.
Not just for today's call, but just the keeping our industry safe.
So much appreciation there.
Absolutely. It's been a great conversation.
Next call or next episode, February 21st, as we will discuss the security intelligence brains
behind all of Cisco Security Products. That's the Talos organization.
We're also going to cover incident response on that same session.
So I hope everyone has enjoyed today's conversation on multi-cloud defense.
Jason, Sudhir, Andre, it's been a pleasure.
Stay secure and we will see you on the next one.