Cisco Systems, Inc. (CSCO) Earnings Call Transcript & Summary

Hello, everyone, and welcome to today's webinar, Achieve Consistent Security Across your Clouds. In a moment, I'll turn the session over to Gio Tan, but first, I have a few housekeeping notes to cover. [Operator Instructions] At the end of the session, a survey will automatically pop up in your browser. Please click continue to complete the survey. We really appreciate your feedback. With that, we are ready. So let's get started Gio in a few seconds, it's all yours.

Hi, everyone. Welcome to today's webinar, Simplify Multicloud Network Security -- Achieving Consistent Security Across your Clouds. So in a few moments' time, you actually hear from Anubhav Swami and Chris Consolo. So Anubhav is a principal architect for cloud and network security in Cisco. And Chris Consolo is a Product Marketing Manager at Cisco. So you would hear about Cisco Multicloud Defense and how it can help you achieve greater visibility and control and boost efficiency with built-in automation and orchestration. So the webinar has been recorded ahead of time to ensure a good webinar experience for all. So -- but if you have any questions during this webinar replay or webinar broadcast, please let us know, we will be here to help to answer any of these questions. With that, Mark, can I get your help to play the webinar playback please.

Hello, everyone, and welcome to the Cisco Multicloud Defense webinar. My name is Chris Consolo. I'm a Product Marketing Manager here at Cisco on the Cloud and Network Security team. Today, we're going to be discussing how we can help you simplify multi-cloud network security with Cisco Multicloud Defense. And I'm joined by my esteemed colleague Anubhav Swami. Anubhav, say hello.

Hello, everyone. My name is Anubhav Swami, and I'm Principal Architect here at Cisco, and I focus on Multicloud Defense and Cloud Protection Suite.

Great to have you here, Anubhav.

Sure.

Today in our agenda, we're going to discuss multi-cloud security challenges organizations face today. How Cisco Multicloud Defense is simplifying multi-cloud network security. Then we're going to have a deep dive from Anubhav into Cisco Multicloud Defense, talking about architecture and use cases, then we're going to go even further, talking about a demo and deploying the solution and securing multi-cloud infrastructure. And then finally, we're going to go over what is new and coming with Cisco Multicloud Defense. Over the last few years, we've seen the network continue to evolve with most organizations starting at the private data center, and we've seen this trend grow towards hybrid and multi-cloud environments. Now where organizations have started at the private data center, they needed greater agility, flexibility and scale to where they started adopting these cloud environments such as AWS, Azure, Google Cloud Platform and Oracle Cloud Infrastructure. And then over the last few years, we've seen more multi-cloud deployments. And what I mean by that is more organizations adopting 2 or more public cloud environments in addition to their private data center, mostly for the need of greater agility, flexibility and scale. But adopting multi-cloud environments comes with its challenges and trade-offs. We find talking to many organizations that clouds speak different languages. And this is because of the proprietary components, nuances and native services and interfaces. And it's not that there's 1 cloud or multiple clouds that are better than the other. It's just that they're different. We also see that the additions of multi-cloud environments in organization's infrastructure shows that there's more entry points and an expanded attack surface. And this typically introduces greater risk to the organization because there's more entry points, which means more monitoring, more maintenance as well as greater security policy creation. And then finally, we see that with new solutions -- new problems that arise in multi-cloud environments that there's new solutions every day being developed and organizations adopting new solutions. Well, these new solutions that solve problems are creating greater complexity inside of these infrastructures, and these traditional set-ups typically increase overhead for organizations, more room for error when configuring, creating policy. And also, there's a lack of automation between these services as well as cloud environments, which make it difficult for organizations to keep up. So when you have cloud speaking different languages, too many point solutions and managing multiple attack surface areas, this creates operational efficiency with stranger security teams. Wouldn't it be great if you alleviate cloud complexity and simplify across environments with unified security controls? Wouldn't it be great if you had greater visibility and control across your environments where you could see cloud workloads from anywhere in the infrastructure. And wouldn't it be great to increase operational efficiency for your team by delivering security at cloud speed, so essentially then security wouldn't be the bottleneck. Well, in fact, there is a solution, and that is Cisco Multicloud Defense. Our single solution delivering unified security controls across environments at cloud speed. And what it does is it helps simplify security across the clouds where you're able to manage security in realtime across your AWS, Azure, GCP and OCI environments with a single policy. We're also able to help your organization reduce risk with multi-directional protection meaning you could stop inbound threats targeting applications, block command and control, prevent data exfiltration as well as mitigate lateral movement of attacks across environments. Also, we're helping you lower cost and realize operational efficiency with built-in automation and orchestration of underlying cloud network constructs, so you can bring security and efficiency to your environment and for your teams. And a great example of a customer implementing Cisco Multicloud Defense to simplify their multi-cloud security, reduce risk and realize operational efficiency with Teradata. Now Teradata in prior state had to make trade-offs either support their customers and begin generating revenue or to increase and harden their infrastructure. They were not able to do both at once, meaning they had to trade off between one or the other. When they implemented Cisco Multicloud Defense, not only were they able to support their customers, but they were also able to upgrade and harden their infrastructure with security at the same time. And upon implementing Multicloud Defense, Teradata was able to deploy egress security in minutes to hundreds of cloud sites supporting hundreds of their customers as well as reduce infrastructure costs by 35% and see a 50% reduction in gateway provisioning. And for those who know about virtual appliances that sometimes virtual appliances can be a little tricky to implement. Using Multicloud Defense, they're able to simplify and reduce that provisioning time by 50%. And so with Cisco Multicloud Defense, we're able to help organizations simplify that security across clouds with the continuous visibility. And what we mean by this is when you onboard a cloud account, Anubhav will show you a demo later of onboarding a cloud account. When you onboard a cloud account, you're able to leverage asset discovery, which means when you onboard that cloud account, you will see applications inside of your infrastructure upon the completion of that asset discovery. You'll know each application, each workload and each service that is running in your environment. We're also able to help organizations gain full protection with a single policy. We're able to manage the security across clouds from the single solution, meaning you write that policy once and you can scale it across them all. Now we understand that cloud environments are dynamic and static IP addresses are nonexistent, which means in these environments, you could use tag-based policy to apply security policy Azure environment updates, that security policy will update with your environment and evolve with it. Now to further show how we are able to help with risk reduction, as I mentioned earlier, being able to detect, block and block command and control as well as botnets and data exfiltration, Cisco Talos reported an increase in data theft extortion in Q2 of 2023 over the prior quarter, and this also surpassed ransomware, making egress security a very important use case in cloud environments right now. We also provide ingress protection where we're able to use your cloud-based IDS as well as IPS and web application firewall to protect applications from threats that target web and non-web apps. And then finally, we're able to mitigate lateral movement with implementing segmentation. And this can be seen as inter-vPC segmentation where we place gateways at the edge of the cloud so you can protect between clouds. And then we could also place gateways at the edge of vPCs so you can protect traffic between vPCs. And finally, we're helping lower cost and realize operational efficiency for organizations. We're able to help them element those costly point solutions and solution sprawl by bringing together tools like IDS, IPS, web application firewall, FQDN-filtering, URL filtering, antivirus, all into 1 solution. But not only that, being able to manage this solution across all cloud environments from one place, the Cisco Multicloud Defense controller. Now we're also able to help organizations deploy faster and train less, meaning you don't have to be a cloud expert because all the automation and orchestration under the hood is helping you through creating your security for across your environment. And then finally, unified policy means less overhead and misconfigurations, which ultimately means less stress for organizations. So now I'll hand it off to Anubhav.

Anubhav, can you tell us more about the Multicloud Defense architecture and the value it brings for our customers?

Sure. Chris, thank you for that detailed introduction to Multicloud Defense. I will go ahead and double-click on the Multicloud Defense architecture. Multicloud Defense has majorly 2 components. First component is the controller. Controller is built using highly scalable cloud-native services in the cloud, and then you have gateways. And these gateways are deployed in your accounts. So whenever you deploy these gateways in your accounts, your data stays local, there is no requirement to send this data out of your infrastructure for inspection. Multicloud Defense gateways are delivered as PaaS. And why we call this as a PaaS service because we deploy gateways using controller. And controller handles the entire life cycle of the gateway, from instantiation, deployment, configuration, upgrade and auto scaling. We also have built-in auto healing functionality. If there is any failure, we automatically sense that gateway and replace it with a new functional gateway and apply same configuration to that gateway as well. Now when you talk about traffic filtering, we inspect ingress traffic, egress traffic and east-west traffic, east-west traffic can be your vPC-to-vPC traffic or it could be traffic from your vPC back to your infrastructure. Now when we deploy these gateways, we don't only deploy gateways, we deploy other components along with that like your Network Load Balancer, Transit Gateway, Gateway Load Balancer. When you deploy legacy VM-based firewalls in the cloud, it is really difficult for you to manage those appliances because, one, you have to enable auto scaling, and enabling auto scaling in the cloud is a big pain because you rely on CloudFormation templates, ARM templates, Terraform templates and if you have a bigger infrastructure like multiple accounts, multiple subscription, multiple availability zones or multi-region architecture, it is really difficult for you to manage those appliances. What we do is when we use Multicloud Defense controller, we onboard your cloud infrastructure in the controller portal and we discover all your assets. Along with that, we deploy gateways wherever these gateways are needed. Once these gateways are deployed, we also ensure that we run the network orchestration piece as well because traffic engineering in the cloud is pretty complex. If you are an expert on routing in your data center, those native configuration options are not available in the cloud, routing traffic engineering is entirely a different field in the cloud. And we abstract that information, and we configure those automatically for you. We provide you complete visibility because what we do is we ingest your DNS query logs, your vPC flow logs and your NSG flow logs and we give you detailed information in the dashboard as well. Along with that, we also have dynamic unified policy. So what dynamic unified policy is? We have a PUB/SUB model with these cloud providers, and we get the realtime updates of your tags. So you can build tag-based policy and those tag-based policies are dynamic. So if there is a change in the tag, we get that information automatically on the controller, and controller applies that configuration down to these gateways in real time. In terms of orchestration, we do have Terraform providers, and we support rest APIs as well. So any option that you will see today in the UI, those options can be orchestrated using Terraform as well. For event and logging, we have integration with Splunk, Datadog and other providers as well. So I've been working on cloud since 2013, and I've been talking to a lot of customers. Biggest pain point of deploying network security in the cloud is to get the device in the data plane, auto scale. When you have multi-availability zone, AZ architecture, how will I route traffic to the appliances in a way that your traffic stays symmetric. So those are the biggest pain points. And natively, in this architecture, we handle all those pain points, and we provide you with a centralized management from where you can manage all your cloud infrastructure. You can manage your gateways. You can apply a unified policy across all your cloud infrastructure. The solution natively provides you auto scaling, auto-healing functionality as well. So if there is a failure or if there is a requirement for adding new instances, we spin up those instances quickly, and we add it to your infrastructure and apply the required configuration on the new instance. And we quickly do all the traffic engineering and plumbing in the back end. You don't have to worry about your infrastructure. You can spend time writing your security policies. You can focus on writing security policies versus working and troubleshooting the underlying components. So we provide you that abstraction layer. You don't have to worry about how will I add my Gateway Load Balancer, how will I insert route on the Transit Gateway,. We do it automatically for you using the controller APIs, and these APIs talks to these gateways automatically. Now when we talk about gateways, we have ingress gateway and we have egress gateway as well. So all the ingress protection features like reverse proxy, TLS-decrypt, WAF, L7, DDoS antivirus Geo IP and Mal IP. These capabilities are available on ingress gateway. And considered gateway as a fleet of compute instances running in your infrastructure because by default, we enable auto scaling on the instances as well. And for the egress gateway, we handle egress traffic flow and we handle east-west traffic inspection as well. So any vPC-to-vPC traffic, VNet to VNet traffic will come to egress gateway as well. And any traffic going towards Internet will also land on egress gateway. We have single-pass architecture for these instances. And we avoid using any sort of complex service chaining. When we deploy these instances, we ask you to specify instance size. We provide you with 2 core, 4 core and 8 core gateways, and these gateways can be added in your infrastructure on demand, and you can enable auto scaling along with that. Now when we talk about security models, it is really important to understand how these gateways are deployed in your infrastructure. And you can specify whether you want to go with a distributed security model or a centralized security model. Let me spend some time on talking about these security models. Let me start out with the centralized security model. Centralized security model is a model where you have a dedicated service vPC or a security vPC and all your security services like your ingress gateway and your egress gateways are deployed in the centralized security vPC. And you have your application vPCs is connected to your security vPC using some sort of connectivity like VNet peering, vPC peering or transit gateway. And what we do is we take your traffic from the application vPC. We bring it down to the security vPC inspected. If your traffic is allowed, we send it to destination vPC. And this architecture is being used by most of our customers because it simplifies the entire cloud architecture because you have 1 single place where you have your security instances and you just connect your new account or vPC to that particular service vPC. For example, if I'm using 50 vPCs at this point of time, if I want to add another vPC and I want to enable inspection on that vPC, I will simply create that vPC, install my applications and connect my new vPC back to the security vPC, and that will automatically send my traffic back to these gateways for inspection. There is another type of deployment known as distributed security model. In distributed security model, we place these gateways next to your application in your application vPC. The advantage of this architecture is, if you have a kind of a 3-tier architecture in your application vPC, like web tier, app tier or database tier and you want to place these gateways between subnets to protect your inter vPC or inter subnet traffic, we then route traffic to these gateways for deeper inspection. And with distributed model as well, we do the egress security interest protection and east-west production as well. We also have combined security model. In combined security model we can -- we allow you to use both options. So a certain portion of your network can be protected using distributed security model, a certain portion of your infrastructure can be protected using centralized security model as well. Now when I talk about the protection, traffic protection, what we do is we provide security for your egress traffic, for your ingress traffic and your east-west traffic. And I have this slide here just to specify that these 3 inspections are available for both deployment models. We support it in security, in centralized security model as well as in distributed security model as well. So there is no limitation. You can attach your infrastructure, build your infrastructure based on your requirement and enable inspection as per your requirement. Now this is a double click on the architecture, and this is AWS centralized model. I will be talking about AWS centralized model, Azure centralized model. GCP and OCI centralized model today, and I will double-click on the traffic flow as well. But if you look at this architecture, on the right-hand side, we have a security vPC. In that security vPC, we have our security services. When I say security services, I'm referring to the Multicloud Defense gateways. Along with gateways, you will see network load balancer. You will see gateway load balancer. You will see gateway load balancer end points. In the legacy VM-based deployment, you must have deployed VM-based firewalls along with these components. And it is really a complex process where you have to use a lot of scripting, a lot of external scripts in order to enable auto scaling along with this fully deployed architecture. But with Multicloud Defense, this solution will automatically instantiate entire security vPC for you, and then it will build all these required components along with required gateways. For example, if you want to deploy ingress gateway, we go ahead and instantiate ingress gateway along with network load balancer. If you want to deploy egress gateway, we deploy egress gateway along with gateway load balancers and gateway load balancer end points. And when we deploy egress gateway and gateway load balancer, will run Genie protocol. And the reason why we run Genie protocol between gateway and gateway load balancer is because we want to maintain symmetry and we want to avoid any sort of source netting. So that's the reference architecture of the service -- the cloud service providers, and it is highly scalable. So what we do is we -- instead of inventing something new, what we have done is we have taken the a well-architected approach on CSPs, and we have created a solution which will provide you complete inspection. Now when we deploy gateways, we ensure these gateways will have resiliency, redundancy built into it. So we enable auto scaling and auto healing functionality by default. We can attach your application vPCs using a new transit gateway or we can attach to your existing transit gateway as well. And once we deploy entire solution and today, I will show you the end-to-end deployment as well, when I'll show you that, you will see that we handle the entire traffic steering as well. So we make changes to all the route tables, which is a pretty complex configuration when you have a larger cloud presence. Now this slide shows you the traffic flow for your egress traffic. So what we do is, for example, you have your application machine talking to Internet, it could be a case where you are using Google Map API on your application. And when you want to inspect that traffic, that traffic will first land on the transit gateway that you see in the middle. And from transit gateway, we forward it to the gateway load balancer endpoint. And from endpoint, we send it to gateway load balancer and then to our Multicloud Defense gateway, we inspect this traffic and send it out to Internet. If you have auto-scale instances or Multicloud Defense gateway here in this architecture, the egress IP address might change. We do have implementation where you can include AWS NAT gateway as well so that your egress traffic IP address stays the same. So we support this architecture along with NAT gateway as well. Ingress protection is a pretty simple use case where you have your application in your application vPC and you want that application to be accessed by external users on the Internet. So we have the Internet gateway in the service vPC, and there is no Internet connectivity directly in the application vPC. So we receive traffic on Internet gateway; from Internet gateway, we send it to network load balancer. And once your traffic is received on network load balancer, network load balancer will send it to gateway. And once we receive it on gateway, we apply security policies like TLS-Decrypt, IPS/IDS protection, WAF and other security capabilities, which I showed you in the previous slides. Once your traffic is allowed, we send it to transit gateway and back to your application. Here is an example for east-west traffic inspection as well. For east-west traffic inspection, what we do is we use the gateway load balancer, so we forward traffic to transit gateway. From transit gateway, we use gateway load balancer endpoints, gateway load balancer and Multicloud Defense gateway, egress gateway, I would say. And we inspect traffic there. If traffic is allowed, we send it to destination vPC using the similar kind of route as well. With this, I will quickly transition to Azure as well. Azure architecture is pretty much similar. So you have service VNet or security VNet on the right-hand side. And on the left-hand side, you have your application VNets. And there is a connectivity between your application VNet and your service VNet using vPC peering. In this architecture as well, when you want to deploy your gateways, we deploy gateways along with load balancer and required configuration, that configuration could be a configuration on the load balancer or a configuration in the CSP route table as well. When we deploy this architecture, we instantiate your gateways. We enable peering, we enable routing, we enable load balancer configuration, and we also enable auto scaling. Along with that, the entire architecture that you see on the right-hand side, the service VNet or security VNet is completely orchestrated by Multicloud Defense Controller. Here is the example for egress traffic flow. When I talk about egress traffic flow, in this architecture, we received traffic on the internal load balancer. Internal load balancer receives that traffic via VNet peering. And once traffic is received, we send it to egress gateway, and egress gateway will then forwards that traffic to Internet. Here is an example for ingress traffic flow. Ingress traffic flow in this case uses the external load balancer. In case of Azure, it is known as public load balancer. So traffic is first received on public load balancer. We inspect the traffic on gateways and then we forward it to the application VNets. For segmentation use case, for east-west traffic inspection, we send it to internal load balancer, and then to our gateways and once traffic is inspected and allowed, we send it to destination vPC using VNet peering. Now let me quickly transition to GCP centralized model as well. GCP centralized model is same kind of model where we use multiple instances of Multicloud Defense gateways. Along with that, we deploy internal load balancer, external load balancer, and we also have connectivity back to application vPC. Only difference in GCP in this architecture is there is a dedicated management vPC. And that's not the limitation that we have added here. If you have deployed instances in GCP and if you are playing with GCP, there is a requirement within GCP if you have multi-NIC instances, you have to place each NIC in a dedicated vPC. That's the reason we have management vPC in this architecture. But when you deploy this infrastructure, we handle your peering, your routing, your configuration on the load balancer, auto scaling natively in the product architecture. And we do it using APIs between the gateway and your Multicloud Defense controller. And we build the entire security vPC using controllers. So you don't have to worry about underlying infrastructure. What we do is we give you options of deploying these gateways, you just pick your vPC, your region, your vPC and we go and instantiate gateways there, and we build that entire security stack for you. For external or the egress security, we send traffic to internal load balancer and then to egress gateway and from there to Internet. I'll quickly transition to ingress protection as well. In this use case, we received traffic on external load balancer. And once traffic is received on the external load balancer, we apply security policies. And if traffic is allowed, we send it to destination vPC. And this is a use case where you have vPC-to-vPC communication and you want to enable inspection. We send traffic to internal load balancer, then to the gateways. And you must be wondering that I'm repeating all these architectures again and again. The reality is, what I want to show you is when you deploy these architecture across your cloud infrastructure, whether you're deploying it in AWS, Azure, GCP or OCI, the architecture -- underlying architecture might look different, but from the point of view of the administrator or the security admin, who is configuring this entire infrastructure, workflow in Multicloud Defense is exactly the same. You don't have to understand or know the underlying cloud services because what you will see in the workflow today is you will just define your vPC, you will define what vPC to secure, what account to secure. And all the network configuration plumbing is done automatically by Multicloud Defense controller. This is OCI centralized model as well, and I'm not going to spend too much time in the architecture today because I just want to cover demo as well. But this is, again, similar kind of architecture where we have a dedicated centralized VCN and we have application VCNs. And these VCNs are connected using local peering gateway. If it is in the same region if you have your application VCN in a different region, we use dynamic routing gateways. But in the end, we route traffic to the centralized vPC and we enable inspection. And we ensure that your traffic engineering, traffic routing and your traffic inspection is automatically handled without spending much time in configuring the underlying infrastructure. And you must be thinking about troubleshooting as well. We provide you detailed information about what's happening in your infrastructure in system logs as well. So if there is any problem with the native component of the CSP, we show you that information in the system logs as well. For example, if you are unable to build any component of the cloud. If your deployment is failing, that information can be there. And sometimes we have seen deployment fail because of limited quota in your account. So those kind of important messages are also available in our controller so that you know, okay, I need to deploy certain resources in North Virginia region. Do I have those quota enabled on my account? That information will be available in your CSP. But if there is any deployment that is -- that failed because of that reason, we can definitely show you that information in the UI. Now for egress protection, we send traffic to internal load balancer. We send it to our gateways and then to Internet. For ingress production, we receive traffic on the external load balancers and we send it to our gateways and then back to our applications VCNs. For east-west traffic, again, we use the internal load balancer. We send it to the internal load balancer, inspect it and then we forward the traffic to the destination vPC. So when I talk about deployment of these gateways, we ensure that you have auto scaling enabled. We can enable auto scaling across AZs as well. So if you want to go with multiple availability zone architecture, we fully support that architecture and we can enable auto scale accordingly in our architecture as well. So I talked about centralized security model. Now I will take some time and talk about distributed security model as well. So in the previous architectures, you have seen that Multicloud Defense gateways are deployed in a dedicated security vPC. But in the distributed model, these gateways are deployed inside of your application vPC, and we enable network load balancer if your traffic is ingress protection and we deploy, the gateway load balancer if your traffic is outbound. And if you want to enable inspection between subnets that can be also achieved.

Well, thank you very much for sharing a detailed architecture, Anubhav. I really like the fact that Multicloud Defense is helping simplify this for our customers to the point where they don't have to be the cloud experts to understand how to instantiate security across all of their cloud environments because we take care of the infrastructure under the hood. And so can you tell us more about cloud onboarding and show us how easy it is to onboard cloud environments?

Sure. Chris, definitely, before I talk about onboarding, I just want to show you a 3-step process. This 3-step process is pretty simple. We start with onboarding your account. So onboarding is pretty much simple. What we do is we provide you with certain automation and orchestration using which we create IAM roles. And IAM roles for AWS accounts, and we use app IDs for Azure and other mechanism for other cloud providers as well. But the idea is just -- I just want to give you the idea that we -- when we onboard, we have the complete orchestration. Once your account is onboarded, we discover all the resources in your account. So if you want to onboard multiple accounts, we go inside your accounts, we crawl into your account, and we find out all the assets in your account, and we display that information on the dashboard. The second thing in the workflow is visibility. Visibility is a little bit different from discovery. Discovery will show you information about your assets. Visibility is the piece where we show you information about what's happening in your infrastructure. We get this information from DNS query logs or vPC flow logs and NSG flow logs in case of Azure. So once we get that information, we tell you, okay, you have these many instances in your infrastructure. These instances are accessing these destinations or any attacker on the Internet is trying to access these VMs. And we provide you detailed information about what's happening in your infrastructure. Third step in the workflow is secure your account, which is really important to understand because when you deploy these instances, that's when you are deploying or enabling enforcement. In step 1 and step 2, you are just enabling visibility and discovering your asset. And by the way, step 1 and step 2 is completely free. If you sign up for Multicloud Defense trial tenant, you can onboard your account, you can enable visibility. And you can discover what's happening in your infrastructure. Step 3 is where you will deploy your gateways. Once your gateways are deployed, you will protect your vPCs or VNets and you definitely send your traffic back to your infrastructure. So before I talk about onboarding, I just wanted to go at these 3 simple steps. And within minutes, you can have your complete infrastructure up and running and completely protected. So with this, I will quickly transition to a short demo where I will talk about how easy is to onboard an account in Multicloud Defense controller. So this is Multicloud Defense controller portal. And once I am on the dashboard, I would straight away go to set up. And once I click on set up, we give you an option of onboarding your accounts. Let's say I want to onboard AWS account. When I click on AWS, we give you a CloudFormation template that creates IAM roles, one for the inventory and one for controller to create resources in your infrastructure. Once that stack is completely deployed, what we do is we take that information, the ARN of your IAM roles and we add that information inside our cloud portal. So we define in the cloud name, account number. We define the controller IAM role. We define inventory IAM role. And we quickly go ahead and update that information in the controller. As soon as Controller receives that information, controller will then try to discover all the assets. And you can see all these assets are discovered from your cloud infrastructure. Now if I go to this dashboard here, this is where I will see information about all my assets across all my cloud infrastructure.

Awesome, Anubhav. And see that was really quick and easy. You also mentioned the next step is visibility. Can you show us how to enable visibility and tell us more about how the visibility process works inside of Multicloud Defense?

Sure. Visibility is a really important piece because without visibility, you cannot really tell what's happening in your infrastructure. So I'll quickly transition to visibility demo. So here, again, I'm on the dashboard, I go to set up and I click on visibility. Again, in this demo, I'm going to enable visibility for my AWS infrastructure. Step 1 is to select my account. Once my account is selected, I will go ahead and select my region. And inside my region, I am selecting vPC where I want to enable visibility. So I just click these 2 vPCs and I specify my S3 bucket. So S3 bucket is needed because we send our vPC flow logs in the S3 bucket, and we need that information out of the S3 bucket to provide you complete visibility. Within a couple of minutes, you will have your completely -- a complete environment where you have complete visibility of your infrastructure. And if I go to discover again, if I go to topology view -- topology view is really an interesting view from where you can see the global view of your infrastructure. You can see what all vPC's accounts are onboarded. And in this example, I have a vPC where I can see some malicious activity going on, so I can double-click on that. And then I go inside one of the vPCs. And you can see here, I have a workload, and this workload is connecting to a malicious destination. So I can click on traffic view. I can view this traffic based on country, IP addresses, FQDN, services and port. So this is kind of detailed information that you get from the infrastructure. I can click on log. And once I click on log, we show you detailed information of what's happening inside of your vPC. And we do similar -- we do provide similar kind of visibility for Azure, GCP and other providers as well. And if I go to summary tab, this is the place where you get information about your vPC traffic, your instance traffic, and we give you information based on IP addresses, based on instances. So this information is learned in realtime from these providers. So what we do is we give you a detailed view of your entire infrastructure. And this is an example where I've just added 1 account. It could be multiple accounts as well.

So what we're showing there is how quickly we are able to enable visibility. And this is even before we start building gateways, correct, Anubhav?

Yes.

And there is one interesting view that I really like inside of Multicloud Defense being able to look at that global topology, seeing all of your cloud environments together in one view and being able to see is there a potential malicious traffic. Now in that side of that vPC view, we saw connections being made to those malicious places. How can you show us how to secure with gateways?

Definitely. Next up is the demo on Secure Your Account. Secure Your Account is the step where we deploy gateways in your infrastructure. So before I talk about this particular demo, let me spend some time and talk about topology. So if you look at this architecture here, we have security vPC on the right-hand side, we have our application vPC 1, application vPC 2 on the left-hand side. And these 3 vPCs are connected using a transit gateway. And we want -- and today, we will demonstrate ingress protection, egress protection as well as east-west, which is the segmentation piece as well. But I won't tell you that everything that you see in the architecture will be done automatically by controller. So what we will do today is we will start from scratch, so I'll quickly transition to the demo and show you the dashboard again. We go to set up again and in setup, this time, I'll click Secure Your Account. When I click on Secure Your Account, we give you option of distributed or centralized security model. For this demo, I'm going to use centralized security model. So I'll click on centralized security model. I'll give it a name. So first step is to define name for my security vPC, then I will select my CSP account, select a region. So in this case, I'm going to deploy the security vPC in North Virginia region. I will define CIDR range for this security vPC. Then I will select multiple availability zone. I can select one availability zone as well, but recommendation is to go with multiple availability zones. I can connect to an existing Transit Gateway, but in this demo, I'm using a new transit gateway, so that I can show you that controller can instantiate new transit gateway as well. And then I auto accept my attachments as well because I want my transit gateway to automatically accept these, these attachments. And I also have the option of enabling transit gateway as well. But in this demo, I'm just skipping the transit gateway. The moment I clicked on next, it took a couple of minutes to deploy my security vPC, my transit gateway and everything. Now step 2 is to deploy gateways. When I deploy gateways, first thing is I define in what vPC or VNet I want to deploy gateway. Right now, the status of the gateway's active pending, it will change to active in few minutes. The moment, it has changed to the active state, I define size of the instance. So in this demo, I'm using 2 core instance, then I define I want to use ingress gateway. I want to deploy egress gateway as well. I define name for these gateways and then I attach policy to each gateway as well. Then next step is to define the key. And this key is required if you want to gain access to these gateway out of band by SSH -- by doing our SSH into the device, you can definitely come back to this, use these keys to SSH into the device. Now I clicked on deploy. So this process will now deploy ingress gateway and egress gateway inside of the vPC, which we deployed in the previous step. So let me quickly go and show you the service vPC here. So I have this service vPC, which was automatically created by controller. And inside of that vPC, we have 2 gateways, ingress gateway and egress gateway. Now if I look at the instances here, you can see right now these gateways are not up. These gateways are in enabling state right now because controller is trying to instantiate those gateways inside your account. So generally, it takes 2 to 3 minutes to deploy each instance and once your instance is deployed, you will see that your traffic -- the instant state change to active. Once you are sure that the instances are active, you -- next step in the flow is you can route your traffic to these gateways. So for that, what we do is we go to vPCs under inventory and we search for the required vPC. These vPCs are not protected. So what I can do is I can pick up any of the vPC of my choice, which I want to protect. I click on that and I specify my security vPC and then I specified route table. This route table is applied to my application vPC. And what I'm doing here is the controller will go and make changes to the route table. So you don't have to worry about making changes to the route table as well. So I have protected my application vPC 1. Now I will go ahead and protect application vPC 2 as well. So you can look at this workflow. This is pretty simple workflow. You don't have to understand or you don't have to be an expert on the cloud infrastructure. You don't have to worry about how will I create vPC, how will I create gateway load balancer, how will I create Transit Gateway, how will I enable routing. That is done automatically by controller.

That's awesome, Anubhav. Thank you very much for the detailed architecture and overview and even showing us how to secure your account with the different use cases. Now can you tell us a little bit more about how we license the product. I know we have advantage in Premier, and we also have a few things coming up. Could you go through those?

Licensing can be a pretty complex topic. With Multicloud Defense, we have a licensing model that is simplified. We license this product based on gateway hours. You buy gateway hours in bulk and then you use those gateway hours against your compute instances. When I say computer instances, I'm referring to your Multicloud Defense gateways running in your account. If you have annual cloud spend with AWS and you want to use your annual cloud committed spend for purchasing Multicloud Defense, we can do that. We can enable private offer with AWS, and we can help you purchase Multicloud Defense gateways against your committed AWS annual spend. For the tiers, we have Advantage tier and Premier tier. Premier tier provides you features like URL filtering, DLP, WAF, EIP rate limiting antivirus and multi-cloud networking and hybrid cloud segmentation. I will talk about these in the next slide, and I will talk about how multi-cloud networking and hybrid cloud segmentation can enable a complete solution that will protect your infrastructure. So multi-cloud networking piece is something where we are enabling fully orchestrated connectivity back to your infrastructure. It could be your site to cloud connectivity or cloud-to-cloud connectivity. So if you have your critical database in your data center and you want -- and your application tier is running in the cloud and you want a secured connectivity back to your infrastructure, we will definitely have a solution for that as well. So multi-cloud networking enables you to add VPN-enabled gateway in your infrastructure. And if you have -- ASA or firepower threat defense in your infrastructure, we can form tunnel back to you automatically. And if you have Azure, GCP and OCI, you can spin up new incidents there as well. And you just define -- in the workflow, you define your source VPN gateway and your destination VPN gateway and we build IPsec tunnel automatically. And you don't have to worry about routing piece as well because we enabled route-based VPN along with that. We use BGP as well.

So this is a great alternative if say, direct connection is not available or if you choose to keep your infrastructure and your operations in-house.

Right. Definitely. I've seen a lot of customers facing a lot of challenges with Inter-cloud connectivity. And this feature is going to enhance that experience. We have completely kind of a solution that is under 1 console. So using the Multicloud Defense console, you can protect your workloads. At the same time, you can enable secured connectivity back to your infrastructure. The second piece of the new offering is the hybrid cloud segmentation. So you have your on-premise firewall and you have gateways running in the cloud. You want to create a policy with same objects or you want to share objects, right? So we have enabled this functionality. And we have the Cisco Defense Orchestrator. Using Cisco Defense Orchestrator if you're managing your on-premise firewalls, it could be ASA, it could be firepower threat defense. What we do is we learn your objects using the Cisco Secure Dynamic Attribute Connector, which will receive that information in realtime from your infrastructure, and that information is related to CDO and from Cisco Defense Orchestrator, that information is also related to Multicloud Defense controller. So if you have a database object, network objects on your firewall and you want to use that object in your Multicloud Defense controller as well, you can seamlessly use that and build policy on that as well.

Thank you, Anubhav, for the really great overview of multi-cloud networking and the hybrid cloud segmentation capabilities. Really excited for these to go to our customers in the market. So let's move on to why Cisco. So only Cisco protects your cloud with unified security controls delivered from a single solution. We offer the widest integrated security portfolio on the market, and we have one of the largest commercial threat intelligence teams Cisco Talos to help protect you from known and unknown threats in your hybrid and multi-cloud environment. So if you're ready to give Multicloud Defense a try, check out the QR code here that will take you to our free trial. And if you wanted to see Multicloud Defense in action for yourself, you're also welcome to take our product tour. Now we will be opening up the floor for a few questions. So feel free to send them in, and we'd be happy to answer.

We'd like to thank you all for attending the event. We hope you found it informative. And as a reminder, please take a moment to complete the confidential survey that has been posted in the chat panel. It will also pop up in your browser as you exit. So thank you for joining, and have a great day.