As organizations continue their migration to cloud infrastructure, many find themselves juggling security across multiple cloud providers—AWS, Azure, Google Cloud, and more. The complexity multiplies when you're trying to maintain visibility and enforce consistent security policies across disparate environments, each with its own native security tools and management consoles. This fragmentation not only creates operational headaches but introduces dangerous blind spots where threats can slip through the cracks. In this episode, Mike Veedock and Andres Sarmiento explore how Cisco Multicloud Defense addresses this critical challenge by delivering unified security visibility and control across your entire cloud footprint.

What This Episode Covers

  • Unified visibility across multicloud environments — How to achieve a single pane of glass for security monitoring regardless of which cloud providers you use
  • Automated threat detection and response — The role of AI and machine learning in identifying sophisticated attacks without manual intervention
  • Centralized management and configuration — Simplifying security operations by consolidating control into one platform
  • Scalability for organizations of all sizes — Ensuring your security infrastructure grows with your business
  • Compliance and regulatory alignment — Meeting standards like PCI DSS and HIPAA across cloud deployments
  • Real-world protection scenarios — Defense against malware, ransomware, DDoS, and other contemporary threats

Deep Dive

The Multicloud Reality: Why Unified Visibility Matters

Most enterprise organizations today don’t operate in a single cloud environment. Instead, they’ve adopted a multicloud strategy—deliberately using multiple cloud providers to avoid vendor lock-in, optimize costs, take advantage of best-of-breed services, or meet regional compliance requirements. While this flexibility offers significant advantages, it creates substantial security challenges.

The problem is straightforward: each cloud provider offers its own native security tools. AWS has AWS Security Hub, Azure has Microsoft Defender for Cloud, and GCP has its own suite of tools. Managing security across these platforms requires your team to context-switch between different consoles, interpret different data formats, correlate alerts from multiple sources, and maintain separate policies and procedures. This fragmentation inevitably leads to inconsistent security posture, missed alerts, and extended mean-time-to-detect (MTTD) when incidents do occur.

Cisco Multicloud Defense addresses this by providing a centralized view across all your cloud environments. Think of it as a unified security command center where your team can see what’s happening in AWS, Azure, GCP, and other clouds from a single dashboard. This unified visibility enables your security operations center (SOC) to:

  • Spot trends and patterns across clouds that might be invisible when viewed in isolation
  • Respond faster to incidents because you’re not piecing together information from multiple sources
  • Maintain consistent security policies across all environments
  • Identify shadow cloud usage or unauthorized cloud resources

Automated Protection Through AI and Machine Learning

Traditional security approaches rely heavily on human analysis: analysts write rules, review alerts, and make decisions about which threats require action. This model struggles at scale, especially in modern cloud environments where the volume of activity can be enormous and the sophistication of attacks continues to increase.

Cisco Multicloud Defense leverages advanced artificial intelligence and machine learning to automatically detect and block threats in real time. Rather than waiting for analysts to notice anomalies or for known attack signatures to be added to security tools, these systems learn what “normal” looks like for your environment and flag deviations that suggest compromise.

In practice, this might look like:

  • Behavioral anomaly detection — Identifying when a user or service account is accessing resources in unusual ways, accessing data they don’t typically touch, or operating at unusual times or from unusual locations
  • Threat intelligence integration — Automatically correlating your network activity against known malicious indicators, updated continuously as new threats emerge
  • Workload protection — Monitoring containerized applications and virtual machines for suspicious process execution, unauthorized network connections, or attempts to escalate privileges
  • Data exfiltration prevention — Detecting when sensitive data is being accessed or moved in ways that suggest theft

The benefit here extends beyond just faster detection. By automating routine threat detection and response, Cisco Multicloud Defense frees your security team from alert fatigue and time-consuming manual investigation work. This allows your analysts to focus on higher-value activities: strategic threat hunting, security improvement initiatives, and responding to complex incidents that require human judgment.

One important caveat: automation isn’t a replacement for skilled security professionals. Rather, it’s a force multiplier that handles the volume and lets your team focus on what humans do best—strategic thinking and complex problem-solving.

Centralized Management and Operational Simplicity

Managing security infrastructure is inherently complex, and that complexity multiplies in multicloud environments. Without centralized management, your team might need to:

  • Configure firewall rules in multiple places using different syntax and data models
  • Set up network segmentation policies separately for each cloud
  • Manage encryption keys across different cloud provider key management systems
  • Update and maintain access control policies in multiple locations
  • Respond to compliance audits by gathering evidence from disparate sources

Cisco Multicloud Defense consolidates these functions into a single, unified console. From a practical perspective, this means:

  • Single policy definition — Define your security policies once and have them automatically applied across all cloud environments, with the platform handling cloud-specific implementation details
  • Consistent configuration — No more copying policies between systems or maintaining parallel configurations
  • Simplified troubleshooting — When something goes wrong, you investigate in one place rather than jumping between multiple cloud consoles
  • Reduced operator error — Fewer places to make configuration mistakes, and easier to spot inconsistencies

This operational simplicity isn’t just a convenience—it directly improves security. Configuration errors and inconsistencies are a common source of security gaps. By simplifying the management experience, you reduce the opportunity for these errors.

Scalability: Growing Your Security With Your Business

One of the defining characteristics of cloud environments is their elasticity—you can spin up new resources instantly and scale capacity on demand. Your security infrastructure needs to keep pace with this fluidity.

Cisco Multicloud Defense is built to scale horizontally, meaning it can handle the addition of new cloud accounts, new regions, and new workloads without requiring architectural changes or imposing performance penalties. Whether your organization is managing 10 cloud resources or 10,000, the platform adjusts to match your needs.

This scalability matters for several reasons:

  • No security trade-offs as you grow — Many organizations implement basic security controls initially, planning to enhance them later as they scale. This often leads to security debt that’s expensive to address retroactively. Cisco Multicloud Defense grows with you without requiring rearchitecture.
  • Support for rapid cloud adoption — If your organization is aggressively moving workloads to cloud, you need security that can keep pace with that migration velocity.
  • Consistent protection across mergers and integrations — When organizations acquire other companies or integrate new business units, multicloud defense can extend seamlessly to protect new cloud environments.

Compliance and Regulatory Alignment

Regulatory compliance is a persistent challenge in cloud environments because compliance requirements don’t respect cloud boundaries. Your data might be subject to HIPAA (if you handle healthcare data), PCI DSS (if you process payment cards), GDPR (if you handle EU resident data), SOC 2 requirements, or industry-specific regulations.

Managing compliance across multiple cloud providers traditionally requires:

  • Demonstrating that controls are in place across all environments
  • Collecting audit logs and evidence from each cloud provider separately
  • Maintaining documentation of policies and procedures
  • Proving that access controls, encryption, and other protections meet regulatory standards

Cisco Multicloud Defense helps you meet these requirements by:

  • Centralizing compliance data collection — Audit logs, access records, and security events from all clouds can be consolidated for compliance reporting
  • Enforcing consistent security controls — Many regulations require that security controls be consistently applied. Unified policy management makes this provable.
  • Simplifying audit evidence gathering — When auditors ask for proof that you’ve implemented specific controls, you can point to a single platform rather than assembling evidence from multiple sources
  • Automating compliance monitoring — Continuous monitoring for compliance violations rather than point-in-time compliance checks

Implementation Considerations

If your organization is considering Cisco Multicloud Defense or similar multicloud security solutions, here are practical considerations for successful implementation:

1. Assess Your Current State

Before implementing, document your existing cloud footprint. Which cloud providers are you using? How many accounts or subscriptions do you have? What workloads and applications are deployed in each? This inventory is essential for scoping the implementation and ensuring complete coverage.

2. Define Security Policies

Use the implementation project as an opportunity to codify security policies that may currently exist only in people’s heads or scattered documentation. What data classification scheme will you use? What are acceptable use cases for each data sensitivity level? What network segmentation policies do you want to enforce? Building consensus on these policies before implementation reduces rework.

3. Plan for Integration

Determine what other security tools and systems need to integrate with Cisco Multicloud Defense. Your SIEM (security information and event management system), ticketing system, and other security tools should ideally consume data from the multicloud defense platform. Plan these integrations early.

4. Establish Governance and Ownership

Clarify who owns the multicloud security platform. Is it the cloud infrastructure team, the security operations center, or a dedicated multicloud team? Unclear ownership often leads to adoption problems and operational gaps.

5. Plan for Transition

If you’re moving from disparate cloud-native security tools to a unified platform, plan a phased transition. You might start with read-only monitoring to validate that the platform is detecting activity correctly, then gradually shift enforcement responsibilities over time. Avoid a “big bang” cutover that creates operational risk.

6. Training and Skill Development

Your team will need training on the platform. Plan for onboarding and ensure your security team understands not just how to use the tools, but the underlying concepts of multicloud security.

Key Takeaways

  • Multicloud security fragmentation is a real problem — Maintaining separate security tools and policies for each cloud provider creates blind spots and operational inefficiencies that sophisticated attackers can exploit.

  • Unified visibility is a prerequisite for effective defense — You can’t protect what you can’t see. A single pane of glass across all cloud environments is foundational to understanding your security posture.

  • Automation extends security team capacity — By automating routine threat detection and response, AI and machine learning free your analysts to focus on strategic activities and complex investigations.

  • Consistency matters — Consistent security policies applied across all environments reduce configuration errors, improve compliance, and enable faster incident response.

  • Scalability enables growth — Security infrastructure that scales with your business eliminates the need for expensive rearchitecture as your cloud footprint grows.

  • Compliance becomes provable — Centralized security operations make it significantly easier to demonstrate to auditors and regulators that you’ve implemented required controls consistently across your environment.

  • Operational simplicity reduces risk — Every additional place you have to configure or manage security is another place where errors can occur. Consolidation inherently improves security.

Why This Matters

For IT and security professionals navigating the multicloud era, this conversation around unified defense is becoming less of a “nice to have” and more of a business necessity. As cloud adoption accelerates and threat actors become increasingly sophisticated at identifying and exploiting gaps in security posture, the cost of fragmented security operations compounds. The hours spent correlating alerts across multiple systems, the incidents missed because they only became obvious when viewed holistically, and the compliance violations discovered during audits—these represent both direct costs and business risk.

Organizations that solve for unified multicloud visibility gain a competitive advantage. They can onboard cloud environments faster because security doesn’t become a bottleneck. They can respond to incidents faster because their teams aren’t spending time context-switching between tools. They can pass compliance audits more smoothly because controls are consistently applied and centrally documented.

Furthermore, as cloud architectures become increasingly sophisticated—with containerized microservices, serverless functions, and complex networking patterns—security tools that understand cloud-native concepts become essential. Generic network security tools designed for on-premises data centers often struggle with the abstraction layers and automation-driven changes characteristic of modern cloud infrastructure. Purpose-built multicloud defense platforms integrate this cloud-native understanding, allowing security teams to operate effectively in an environment fundamentally different from traditional IT infrastructure.

    ---

    Listen to the full episode on [YouTube](https://youtube.com/@SecurityIn45) or subscribe via [RSS](https://media.rss.com/security-in-45/feed.xml).

Full Transcript

Click to expand the full episode transcript

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. 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.