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

Hi, everyone. Welcome to today's webinar, Simplifying Multicloud Network Security with Cisco Multicloud Defense. So as the adoption of hybrid and multicloud environments have made life more challenging for a lot of security teams, it actually also allows us to accelerate a lot of our digital transformation initiatives. So how does security teams keep up with the changes in the security landscape with the addition of cloud? So while in this webinar, we will be showcasing and talking through it. And our experts will be sharing a bit more about that. So on this webinar today, we have Anubhav, who is principal architect for cloud and network security at Cisco; and Chris Consolo, who is a product marketing manager at Cisco. They will talk about our Cisco Multicloud Defense solution, how it helps organizations secure multicloud networks and simplify security operations across [ core ] environments, how it provides greater visibility and control and drive efficiency through automation and orchestration. So this webinar has been prerecorded ahead of time to ensure a good webinar experience for all, so while you are watching the recording, if you have any questions, please let us know in the Q&A tool bar. And our experts will be here to answer them. With that, Mark, the floor is yours. Could you help play back the recording?

Hello, everyone, and welcome. My name is Chris Consolo, and I'm a product marketing manager here at Cisco under cloud network security.

And my name is Anubhav. And I'm principal architect at Cisco and I work on Multicloud Defense.

And today, we are going to share with -- how you can help simplify your multicloud network security with Cisco Multicloud Defense. Without further ado, let's get started. In this presentation, we're going to go over what multicloud network security is, challenges faced by organizations experiencing and using multicloud network security, how Cisco simplifies multicloud network security. And then we're going to go into an architectural overview and also describe use cases of Cisco Multicloud Defense. So what exactly is multicloud network security? Well, we can boil it down to this definition: the convergence of cloud-agnostic networking and security functions to support and protect applications against advanced threats across multiple dynamic environments and continuously variable architecture. What does that mean essentially? It means bringing networking components, security components together in a unified way to provide you easier multicloud operations in both the networking piece as well as the security piece; and also being able to update your policies in real time as those environments change, helping you simplify your multicloud operations from one cloud to another, whether it's a multicloud deployment or a hybrid deployment, et cetera. And so why does multicloud network security exist? Well, it's given rise because the network is constantly evolving. And organizations -- we understand a couple of years ago where organizations started at the private data center. Then they evolved into having a public cloud environment, both on-prem data center, private data center as well as public cloud environment. Then over time, it evolved into needing more agility, flexibility and scale, where organizations were not just using one cloud environment but also incorporating more than one. And this is true by seeing that 82% of IT leaders have adopted hybrid cloud, in our 2022 global hybrid cloud trends report. And 58% of organizations are deploying between 2 and 3 "infrastructure as a service" clouds. And some of the challenges that organizations are facing with multiple cloud environments is the lack of unified security controls. We understand that clouds speak different languages. Because of their proprietary components, nuances, native services, et cetera, they're not talking from one cloud to another. Now we also have -- where configuring individual tools takes time. Traditional setups such as virtual appliances increase overhead and room for error and misconfigurations, having to write policies across every individual cloud, across every individual tool within those clouds, but also we might say, "But that's what infrastructures code is for." But automation tools also have learning curves. And so standing up infrastructure, if you're early in your cloud journey, can be difficult without specialized resources. We also see that there's a proliferation of point solutions in these hybrid and multicloud environments. And as more organizations solve particular point problems, individual point solutions begin to stack up. We start seeing different tools such as IDS and IPS, different types of firewalls across different clouds, the different managers. We then see web application firewalls or DLP tools, firewall as a service and more, really showing you how in just that example on the slide can show how quick security tools can stack up for organizations to manage. And this leads to security gaps such -- and silos that keeps security teams and cloud architects in a constantly swiveling state at their desk, but also organizations are experiencing operational inefficiency straining their teams. Essentially, teams come to work with a full tank of gas, but when you start experiencing clouds speaking different languages and there's no unified security tools across them, too -- having too many point solutions and lack of unified security controls really starts to have your teams go from coming to work with a full tank of gas to empty very quickly. And essentially this operational inefficiency is brought on by the complexity, the learning curves and the policy alignment issues that come with these different types of problems, but wouldn't it be great if you could simplify? Wouldn't it be great to have a simpler, unified security across your clouds? Wouldn't it be great to get greater visibility and control so you can see more and detect faster in your cloud environments? Wouldn't it be great to increase your operational efficiency so you can have security that's delivered at cloud speed and scale to keep up with your business velocity? But we can do that, and we are doing that with Cisco Multicloud Defense. It is our solution that offers a single control plane with distributed enforcement points, helping you simplify security across clouds, gain multidirectional protection and reduce risk and lower costs while realizing operational efficiency. To dive in a little bit deeper to these areas. And simplifying security across clouds, we're able to help organizations achieve the cloud economic benefits without compromising on their security; and we're doing that through 3 areas. We're offering continuous visibility, helping you leverage asset discovery in real time so you can get a topographic view of your entire network so you can confidently and strategically place security controls where needed. We're also offering full protection via a single policy. And what do we mean by this? With Multicloud Defense, you're able to write the policy once; and scale it across all of your cloud environments, including AWS, Azure, GCP and OCI. We're also helping you keep up with dynamic policies. So in the cloud, we understand that these environments change very frequently and which means it could be long and cumbersome change control processes. Well, with policy-based management, you can tag these policies, and as your environments update, these policies will update with your environment in real time. The second area that we're helping organizations is helping them gain multidirectional protection. And what Multicloud Defense can offer organizations is ingress security to help stop inbound threats targeting web and non-web apps, egress security to detect and block command and control botnets and data exfiltration. And we're also offering east-west security to help reduce blast radius and protect against ransomware by mitigating lateral movement, and we do this at the inter-VPC traffic level. Also, we're helping reduce risk and lower costs while realizing operational efficiency. And we're doing this by eliminating costly point solutions and helping you operate consistently across clouds. We're helping you deploy faster, while training less, with built-in automation and orchestration; manage policies and enforcement for all clouds in a single place. As well as, unified policy means less overhead and misconfigurations and stress for your teams. We're also helping you meet compliance. And because your security does not leave your cloud's cloud account, we are helping you able to meet compliance quicker. And one of the quotes from a customer below said, "This is way faster, [ minutes versus ] it would take us 20 days with our current checkpoint virtual appliances." Now I'd like to hand it off to Anubhav to go over a little bit more in depth of the architectural overview and use cases of Cisco Multicloud Defense. Anubhav, take it away.

Thank you, Chris, for the great introduction on Cisco Multicloud Defense. I will now go ahead and double-click on explaining the architecture. And I will talk about all the components available in Cisco Multicloud Defense. Cisco Multicloud Defense is a SaaS offer where you get access to highly scalable cloud-native Cisco Multicloud Defense controller, where you can onboard your AWS, Azure, GCP and OCI accounts. Once your accounts are onboarded, you can enable visibility on these accounts; and we will display information about your cloud infrastructure in the portal. Now once you have the visibility enabled, we will ask you to deploy gateways. Consider gateway as a highly scalable instance running in your account, so with this kind of integration, you don't send your traffic to us. We deploy these gateway automatically in your accounts. For the integration between Multicloud Defense controller and your cloud accounts, we don't require token or access key. We integrate using [ IM ] rules, policies or [ AD app ] kind of integration. That enables you to have a secure connection between the controller and your cloud infrastructure. Once you have these gateways in your infrastructure, you can protect traffic, like ingress protection, any traffic coming towards your application; egress protection, any traffic from your application going towards Internet. You can also protect your east-west traffic. So these appliances are delivered as platform as a service because the entire life cycle of these gateways are owned and handled by the controller. You don't have to worry about scaling these instances. Traffic engineering, upgrade, everything is automatically done in the back end by controller. So we automate and orchestrate network visibility by giving you automation tools like Terraform, CloudFormation. And those complex components are made easy by adding Cisco Multicloud Defense controller. Controller is also smart enough to make sure that your gateways are stitched in the data plane automatically. And when you deploy security using Cisco Defense Orchestrator or the controller, what we do is we learn your tags dynamically from your infrastructure and we define policies based on dynamic tags. In terms of automation, we provide you fully functional Terraform providers, so any option that you see on the UI of controller, that can be delivered as a Terraform code as well, so you can write your Terraform code and orchestrate and automate your configuration. This is the high-level architecture where we are showing that you have multicloud infrastructure. And all your accounts are onboarded into Cisco Multicloud Defense controller using [ IM ] policy, [ IB keys ] or AD integration with Azure. In this architecture, what I want to show you is we have different models of deployment. You can deploy gateways directly into your application or your spoke VPC. Or you can have a centralized, dedicated security VPC or VNet where you can deploy your gateways. These gateways can scale up and down as and when required, and you don't have to worry about keeping your infrastructure up and running. The entire infrastructure is tracked by controller, and controller will ensure that your gateways are up and running. If there is a failure of any component, self-healing functionality will kick in and replace that gateway with another gateway quickly. When I talk about gateways. Gateways are available in 2 types today. First one is ingress gateway and second one is egress gateway. Ingress gateway acts as a reverse proxy when -- it is for protecting your inbound traffic. So you have your application in the cloud and you want external users to access it. On the ingress gateway, we enable features like TLS decrypt, [ WAF ], L4 DDoS, IPS, IDS, antivirus, Geo IP, mal IP. Then we have another type of gateway, which is egress gateway. An egress gateway can protect your egress traffic as well as your east-west traffic. When I say east-west traffic, I'm referring to VPC-to-VPC traffic or VNet-to-VNet traffic or VCN-to-VCN traffic. I'm not -- I'll not go through the complete list here, but I -- what I want to highlight is you can enable features like IPS, IDS, DLB, [ WAF ], FQDN-based policies; enable segmentation using egress gateway for your east-west and egress traffic as well. Now let's look at the deployment use cases. When you deploy your gateways in your infrastructure, we provide you 2 models. First model is a highly scalable model where you can have a dedicated security VPC, VNet or VCN; and you deploy your gateways inside of that security VPC. And once your security VPC is created, you attach it to your application VPCs. And when your application VPC 1 talks to application VPC 2, that traffic is first routed to the centralized VPC and we inspect your traffic. If your traffic is allowed, we send it to the destination VPC. The other model is a distributed model. In some cases, we have seen customers would like to have a dedicated gateway in -- sitting near to their application. Because of some compliance requirement, they would like to have a separated or isolated gateway that will protect only [ our ] highly critical applications. That deployment is also supported. You can place your gateway directly next to your application in your spoke VPC and we support that model as well. In addition to that, we also support combined security model, where we have some portion of your infrastructure protected using a centralized VPC and some part of your infrastructure is protected using a distributed security model. So when we deploy these gateways inside your infrastructure, we ensure that auto-scaling is enabled. And our auto-scaling is designed in such a way that it is easy -- availability [indiscernible]. So when we scale, we ensure that there is resiliency in the network. And we scale up, scale down as and when required. Now if I talk about ingress -- or the egress use case: Egress use case is supported in centralized security model as well as distributed security model. So these are high-level architecture diagrams showing you all the possible deployment models. So for egress, both models are supported. Even for ingress, if you have your users sitting on the Internet and that user would like to access application, that traffic will first land in the security VPC if it is centralized security model. If it is distributed security model, it will land straightaway into your application VPC. For your segmentation. On the left-hand side, it's a high-level diagram where we have [ intra-VPC ] communication. So you can see [ there's a ] centralized VPC in the middle on the left side of the architecture. And application VPC to -- application VPC 1 traffic to application VPC 2 traffic is forwarded to gateways in security VPC. Now coming back to the distributed security model: This is a special kind of deployment, for example, if you have tiered architecture in a single VPC or VNet. Let's say you have your app, web and database tiers sitting in a single VPC or VNet. You can use these gateways to segment your traffic between different subnets. So in this example, if subnet 1 wants to talk to subnet 2, that traffic is routed through egress gateway sitting in the same VPC. Now when you access Multicloud Defense. What we have done recently is we have Cisco Defense Orchestrator. And Cisco Defense Orchestrator is a centralized manager that manages your on-premise firewalls, your firewalls in the cloud. We have added Multicloud Defense in the same Cisco Defense Orchestrator so that you have access to your hybrid cloud policies as well. Now if you look at this particular picture here. On the right-hand side -- when you log in to Cisco Defense Orchestrator, on the right-hand side, you will see option to access Multicloud Defense controller. Once you're in Multicloud Defense controller, there are multiple other options available but at a very high level. I'm going to talk about dashboard. Dashboard gives you information about all your accounts. So for example. Once you are in your Multicloud Defense controller, you can onboard your accounts. Once your accounts are onboarded, you can see information about those accounts here, but if you want to double-click and get more information about what's happening at the traffic level, what is happening at the instance level, VPC level, what you need to do is you need to enable visibility. Visibility can be enabled by sending DNS query logs or VPC flow logs or NSG flow logs. Once we receive that information, we create -- we display that information in a way that you get information about all your assets in your infrastructure. And this is really dynamic. What -- we have a [ periodic pool ] as well as we learn information in real time as well, so if there is a change in your infrastructure, we learn that information pretty quickly on the controller. And controller will then replicate that information to all the gateways. Now onboarding and visibility piece is completely free. You can create a free tier of CDO, cross-launch to Multicloud Defense and then enable visibility and onboard your accounts. The next part is deploying the enforcement points. And enforcement points in this particular case is your gateway. Now what I'll do is I will show you this particular piece here. You can deploy security in minutes using this 3-step simple process. Step one is to connect your account. Step two is enable visibility. Send information like [ DNS ] query logs, NSG flow logs or VPC flow logs. And don't send that information directly to us. We will ask you to send that information to an S3 bucket or the Azure Blob storage, and then we read that information directly from there. And this is done because we understand that egress costs in cloud can be pretty expensive. So if you have multiple accounts, multiple VPCs, multiple VNets, you can send that information to a single place; and we read it from there. And then next step is to secure account. This is where we deploy gateways in your accounts. So now let me double-click on these architectures. It is really [ important to ] understand, when you have multicloud infrastructure, it is really difficult for anyone to understand all the native cloud constructs and components. Like, in this example, you can see there are many moving components, like transit gateway, gateway load balancer, gateway load balancer endpoints, network load balancer Internet gateway, so this can be pretty complex to configure, but when you use Multicloud Defense controller, what we do is we onboard your account. And at the time of securing your infrastructure, we ask you whether you want to go with a centralized security model or a distributed security model. If you go with centralized security model, what we do is we orchestrate your security VPC. And if it is ingress use case, in addition to orchestrating your security VPC, we deploy gateways inside of your security VPC. And we also enable and orchestrate your network load balancer as well because, for ingress use case, network load balancer is the place where your traffic is going to land. Once it is received on network load balancer, we then forward that traffic to our gateways. And gateways are fully orchestrated and deployed by the controller. And we also take care of insertion of these gateways into data plane, and we also enable auto-scaling. So once your traffic is inspected on the gateway, we forward it to the transit gateway, and from there, we send it to destination application VPC as well. In this architecture, we orchestrate a lot of moving components. First one is the security VPC; network load balancer; transit gateway. When we orchestrate transit gateway, we can attach to your existing transit gateway. Or we can spin up a new transit gateway and spin up your transit gateway attachments as well. Now in terms of traffic routing. Traffic routing is a [ complex ] process in the cloud, but Multicloud Defense controller handles that natively. So when you enable "secure your VPC," we automatically go inside your account and make all the required changes in the [ route tables ] as well. Now egress use case is similar to this use case which I showed you in the previous slide. Only difference is traffic is initiated from inside. It lands on the transit gateway, first, and from transit gateway, we send it over to gateway load balancer. Why gateway load balancer? Because there is auto-scaling the architecture. And what we do is, with gateway load balancer endpoint and gateway load balancer, we have complete Geneve implementation with our gateways so that we can scale up and scale down properly. And when -- because these are the security appliances, we need symmetry of traffic in the traffic flow. And in the Geneve header, we enter information about which instance handled your initial traffic so that we can route subsequent packet to the right instance. So in this architecture, we orchestrate security VPC, gateway load balancer, gateway load balancer endpoint, your transit gateway, your transit gateway attachment. And we also take care of your traffic routing as well. This is a AWS centralized use case, east-west traffic inspection again. We send traffic to security VPC for inspection. In order to do that, we use egress gateways. So remember, in the previous slides, I talked about ingress gateway and egress gateway, but for east-west traffic inspection as well, we use egress gateways. So traffic will first go to transit gateway. Transit gateway will handle the traffic and send it to security VPC using the gateway load balancer endpoints. Once traffic is received on a gateway load balancer endpoint, we forward it to gateway load balancer. And from there, we forward it to the gateway for further inspection. If your traffic is allowed on the gateway, we send it back to the gateway load balancer and back to gateway load balancer endpoint, back to transit gateway; and then to the destination VPC. At a very high level, you can see this architecture looks pretty simple, pretty scalable. And this architecture is based on AWS reference architecture, but when you try and configure this manually, right, it is going to be really complex because there are multiple components. And you have to understand each and every component, but with Multicloud Defense controller, you don't have to worry about anything on the underlying network infrastructure because controller will handle that natively. You just focus on writing your security policy. Because for any security administrator or security engineer, writing security policy is the most important work rather than worrying too much about the underlying infrastructure. And we handle that on -- automatically using the controller. Now the Azure centralized model is pretty much similar to the previous ingress model. However, in this architecture, if you see, there is a centralized VNet on the right-hand side. And we have our ingress gateways sitting behind a public load balancer, so your traffic will first land on public load balancer. We receive that traffic and then we forward that traffic to our gateways. Once inspected, we send it to the destination VPC using VNet peering. And in this architecture, what we orchestrate is the security VNet, the public load balancer. We orchestrate your ingress gateway. We orchestrate your peering, routing and load balancer configuration; and also handle auto-scaling natively. This is again a use case which -- where you will see that we are using internal load balancer in AWS -- or in Azure. In this architecture, again we have a security VNet. And security VNet is connected to my application VNet using VNet peering. We send traffic to internal load balancer. From internal load balancer, we send it to the gateway, egress gateway, and then to Internet. Now again in this architecture also we do the entire orchestration for you. You don't have to worry about underlying infrastructure. You will get the drop-down menus. You just define which VNet to protect, and the rest will be handled by the controller itself. This is a east-west use case where controller simplifies the configuration, again. And we leverage internal balancer and egress gateway for this kind of traffic flow, so we send traffic to security VNet for inspection. Once your traffic is inspected, we send it to the destination VPC. And security VNet orchestration, workload balancer orchestration and the other moving components shown in this architecture is handled completely by Cisco Multicloud Defense controller. Now let's switch gears and talk a little bit about Google, Google Cloud Platform. And in this architecture, we have a security VPC on the right-hand side. And if you look at this architecture: We have additional management interface. This management VPC -- or not management interface but management VPC. This management VPC is specifically for management NIC that is being used for connection between gateways and the controller. Reason for a dedicated management VPC is, when you run instances in GCP with multiple interfaces, you need one NIC per VPC. So that's the reason we have management VPC here, but you don't have to worry about any complex configuration here because that is again handled by the gateway -- or the gateway and the controller. Now if you look at this ingress traffic flow. We send traffic, first, to the external load balancer; then to ingress gateway; and then to our destination using VPC peering. And we do all the automation and orchestration on this architecture, in this architecture as well. This is our egress traffic flow. So again, a similar kind of architecture, we use internal load balancer for receiving traffic from the application VPC. Once traffic is received on the internal load balancer, we forward it to egress gateway. And from egress gateway, we send it to external or the Internet. Now there is another flow, which is east-west flow, for your GCP traffic as well. For this kind of traffic inspection, we use our VPC peering and we send our traffic to internal load balancer. And internal load balancer then sends it to the egress gateway sitting in the security VPC. And then we send it to the destination VPC as well, so the entire architecture is controlled and automated and orchestrated by the controller. In OCI, we have architecture where we have the security VCN sitting in the middle. And on the left-hand side, we have our spoke VCNs. And on right-hand side, we have spoke VCNs but in a -- different VCNs. This kind of architecture is also supported. What we do is we use local peering gateways for local connectivity between the spoke VCN and the security VCN and we deploy our ingress and egress gateways in the security VCN. And we do all the inspections there in the security VCN, and then we send this traffic towards Internet. The other use case is the egress use case, so traffic being initiated from the applications. And we receive that information on the dynamic routing gateways because in this architecture we are doing cross-region connectivity as well. So if there is cross-region connectivity, we use dynamic routing gateways. We receive that traffic on DRG, and once we receive it on DRG, we hand it over to the centralized security VCN. We inspect the traffic on the gateway and then send it over to Internet. If traffic is local, within the same region, we use local peering gateways, but again in this architecture, for egress, we use internal load balancer. For ingress, we use external load balancer. This is east-west kind of flow. So if you have your application VCN 1 talking to application VCN 2 or application VCN A talking to application VCN B, that traffic is forwarded to security VCN for further inspection. And then we forward it to the destination VPC. And we use internal load balancer. And for connectivity towards security VCN, we either use local peering gateway or dynamic routing gateway, based on where exactly your spoke VPC -- VCN is. With this, I will hand it over to Chris again. Over to you, Chris.

Thank you, Anubhav. So why Cisco? Well, to recap everything Anubhav shared: We're helping organizations simplify their security across multiple cloud environments. We're helping them gain multidirectional protection to protect their applications and workloads in the cloud. And we're helping them alleviate multicloud complexity and increase efficiency through automation and orchestration, as well as alleviating the learning curves that come with multiple -- having multiple cloud environments. Now Cisco is the only organization that can protect your clouds with unified security controls and deliver them from a single solution where you can write a policy once and scale it across your environment. We also offer the widest integrated security portfolio on the market, not just multicloud network security but everything from network security to security service edge, to XDR and more. We also offer one of the largest commercial threat intelligence teams on the planet to help keep your security tools updated, with the latest threats in the landscape, through Cisco Talos. And if you would like to learn more about Cisco Multicloud Defense and you're ready to give it a try, feel free to check out our free trial here with the QR code. And if you would like to see it in action first, feel free to take our product tour, where you could get step-by-step instruction for trying it out on your very own. It includes captions. It includes an interface that can help you understand Multicloud Defense so you could start and begin to protect your applications in the cloud. Thank you, everyone, for your time. We really appreciate you joining our webinar. If you have any questions, please feel free to reach out to us on social media. We would be happy to help.

I would like to thank you all for attending this event. We hope you found it informative. Especially, thank you to the speakers and the panelists for presenting today. 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. Thank you for joining, and have a great day.