Cloud Security Posture Management: AWS, Azure, GCP
As organizations accelerate their cloud migration strategies, the security complexity multiplies exponentially. With workloads distributed across AWS, Azure, and GCP—each with their own security models, compliance requirements, and configuration options—the traditional perimeter-based security approach no longer applies. Organizations are increasingly turning to [zero trust](/pillars/zero-trust/) principles to address these challenges. In this latest episode of Security in 45, hosts Mike Veedock and Andres Sarmiento tackle one of the most pressing challenges facing modern enterprises: how to maintain visibility and control over your cloud security posture as you scale across multiple providers.
What This Episode Covers
- The strategic and operational benefits of cloud migration
- Characteristics and differences between major cloud providers (AWS, Azure, GCP)
- Essential security controls for cloud environments (MFA, network segmentation, encryption)
- The critical role of Cloud Security Posture Management (CSPM) tools
- Common cloud security risks and threat landscapes
- Industry resources for deepening cloud security knowledge
Deep Dive
The Business Case for Cloud Migration
Cloud adoption has become less of a competitive advantage and more of a business necessity. Organizations are moving to the cloud not just for the “cool factor,” but for tangible, measurable benefits that directly impact the bottom line.
Flexibility is perhaps the most immediate advantage. Cloud infrastructures allow teams to provision resources on-demand, scale up or down based on actual usage patterns, and experiment with new technologies without massive capital expenditures. A development team can spin up a test environment in minutes rather than weeks, enabling faster innovation cycles.
Scalability addresses one of the fundamental challenges of on-premises infrastructure: capacity planning. Traditional data centers require you to predict future needs and build infrastructure accordingly, often resulting in either stranded capacity or resource constraints. Cloud providers handle this elasticity natively, allowing your infrastructure to grow with demand and contract when it’s not needed.
Cost-effectiveness is often cited as the primary driver, though it’s more nuanced than simply “cheaper than on-prem.” Organizations benefit from operational expense (OpEx) models rather than capital expense (CapEx), paying only for consumed resources. However, without proper governance and monitoring, cloud costs can spiral rapidly—making cost management both a benefit and a risk.
These benefits are compelling, but they come with a fundamental trade-off: you’re no longer responsible for the physical infrastructure, but you are responsible for the security posture of what runs on it.
Understanding the Major Cloud Providers
Not all clouds are created equal. AWS, Azure, and GCP each offer comprehensive suites of services, but they differ significantly in architecture, service maturity, regional availability, and security features.
AWS dominates the market with the broadest service portfolio and longest track record. It offers unparalleled flexibility and depth, particularly for organizations with complex, heterogeneous environments. AWS’s shared responsibility model is well-documented, but the sheer number of configuration options means misconfiguration remains the #1 cause of breaches in AWS environments.
Azure integrates deeply with Microsoft’s ecosystem, making it the natural choice for enterprises heavily invested in Windows Server, Office 365, and Active Directory. Azure’s identity-centric security approach and native integration with on-premises infrastructure via hybrid cloud capabilities provide distinct advantages for traditional enterprises.
GCP emphasizes data analytics, machine learning, and containerized workloads. Google’s background in handling massive-scale data and its native Kubernetes support make it particularly attractive for organizations with sophisticated data science or container-native architectures.
The reality for many large enterprises is a multi-cloud or hybrid-cloud strategy, distributing workloads across multiple providers for redundancy, avoiding vendor lock-in, or leveraging provider-specific strengths. This architectural flexibility, however, dramatically increases security complexity.
Essential Cloud Security Controls
Cloud security isn’t fundamentally different from traditional security—the core principles remain the same. But the implementation and enforcement mechanisms are vastly different.
Multi-Factor Authentication (MFA) remains the single most effective control against credential compromise, which is the attack vector underlying the vast majority of cloud breaches. In cloud environments, MFA isn’t just for users accessing the console or API—it should extend to service accounts, automation workflows, and administrative access. The challenge is balancing security with operational efficiency; overly restrictive MFA policies can inhibit legitimate automation.
Network Segmentation in the cloud requires rethinking traditional network perimeter concepts. Instead of physical network boundaries, cloud segmentation relies on security groups, network access control lists (NACLs), virtual networks, and microsegmentation practices. The principle remains the same—isolate workloads and restrict traffic to only what’s necessary—but the implementation is fundamentally different. A web application tier should only be able to communicate with its required database tier, never with resources in other environments or applications.
Encryption deserves special attention in cloud environments because it’s both easier and more complex than on-premises. Easier because cloud providers offer encryption as a managed service; complex because you must understand the threat model you’re protecting against. Encryption in transit (using TLS/SSL for data moving between systems) is relatively straightforward. Encryption at rest (protecting stored data) is more nuanced—you must decide whether to rely on provider-managed keys or implement customer-managed key encryption, each with different security and operational implications.
Cloud Security Posture Management: The Lynchpin
If implementing individual controls is the “how,” Cloud Security Posture Management (CSPM) is the “how much” and “how well.” CSPM tools provide continuous visibility into your cloud infrastructure, identifying misconfigurations, compliance violations, and security risks before they can be exploited.
CSPM tools typically work by agentlessly scanning your cloud accounts, analyzing configurations against security best practices and compliance frameworks (CIS Benchmarks, SOC 2, PCI-DSS, HIPAA, etc.), and alerting on deviations. Unlike traditional vulnerability scanners that look for known weaknesses in software, CSPM focuses on logical misconfigurations—a storage bucket that’s publicly readable, a security group that allows unrestricted inbound traffic, a database without encryption enabled, or an identity policy that grants excessive permissions.
The value proposition is simple: visibility at scale. A single large organization might manage hundreds or thousands of cloud resources across multiple accounts and regions. Manual auditing is impossible. CSPM tools automate the auditing function, providing dashboards that show your security posture in real-time and flagging issues for remediation.
However, CSPM tools have limitations. They identify what’s misconfigured but don’t necessarily explain why or provide context. They can generate significant alert fatigue if not properly tuned to your organization’s risk tolerance. And they’re most effective when integrated into your broader security program—they’re a visibility tool, not a control mechanism.
Understanding Cloud Security Risks
The shift to cloud introduces new risk categories that many traditionally-minded security teams underestimate.
Shared responsibility model confusion is endemic. Cloud providers secure the infrastructure (the “cloud”), but customers secure what they put in the cloud (applications, data, configurations, access management). Many breaches occur because security teams assume the cloud provider is more responsible than they actually are, or conversely, try to implement controls that are the provider’s responsibility.
Misconfiguration remains the dominant risk vector. Public cloud buckets, overly permissive IAM policies, unencrypted databases, and security groups that allow unnecessary traffic are everyday discoveries. These aren’t sophisticated attacks—they’re configuration errors that expose sensitive data or systems to unauthorized access.
Lateral movement is more feasible in cloud environments than traditional networks. Once an attacker gains access to one workload, the flat network architecture and service-to-service authentication weaknesses can allow rapid movement throughout your environment.
Compliance and data residency challenges emerge when using multiple clouds across regions. Data sovereignty requirements, compliance frameworks that assume traditional infrastructure, and audit trails that span multiple systems create operational headaches.
Insider threats take on different characteristics in cloud environments. Former employees retaining credentials, excessive standing privileges, and inadequate logging can expose systems to abuse.
Implementation Considerations
For teams looking to establish or improve their cloud security posture, consider this phased approach:
Phase 1: Visibility and Assessment
- Conduct a comprehensive inventory of all cloud assets across all providers and accounts
- Deploy a CSPM tool or use provider-native tools (AWS Config, Azure Policy, GCP Security Command Center) to baseline your current posture
- Map existing controls to the shared responsibility model for your provider(s)
- Establish a security baseline aligned with industry frameworks (CIS, NIST, or provider-specific benchmarks)
Phase 2: Control Implementation
- Prioritize remediation based on risk (public-facing resources and data repositories first)
- Implement MFA for all human and service account access
- Establish network segmentation policies in your virtual networks
- Enable encryption for data in transit and at rest
- Implement proper identity and access management (IAM) least-privilege policies
- Enable comprehensive logging and monitoring
Phase 3: Continuous Improvement
- Establish an automated remediation workflow for common misconfigurations
- Integrate CSPM findings into your change management process
- Conduct regular security reviews and update baselines as your architecture evolves
- Implement automation to prevent misconfigurations at deployment time (infrastructure-as-code scanning, policy-as-code)
Technical Prerequisites
- Cloud provider accounts with appropriate credentials and permissions
- Access to provider APIs and audit logs
- Integration with your identity management system (Active Directory, Okta, etc.)
- Centralized logging infrastructure (for aggregating logs across providers)
- Deployment of cloud-native security tools or CSPM platform
Key Takeaways
- Cloud migration is driven by legitimate business benefits (flexibility, scalability, cost management), but security responsibility fundamentally shifts to your organization
- Multi-cloud environments are increasingly common, but they dramatically amplify security management complexity
- Essential controls (MFA, segmentation, encryption) apply to cloud, but implementation mechanisms are fundamentally different from traditional infrastructure
- CSPM tools are essential for organizations with significant cloud footprints—they provide the continuous visibility required to maintain security posture at scale
- Misconfiguration, not sophisticated attacks, is the dominant cloud security risk—the majority of breaches stem from logical security errors rather than zero-days
- The shared responsibility model must inform your security strategy—understand what your provider secures and what you must secure
- Start with visibility and assessment, prioritize high-risk resources, then implement controls systematically—attempting to boil the ocean leads to burnout and incomplete implementation
Why This Matters
The cloud isn’t coming—it’s already here. If you’re working in any significant IT organization, you’re already operating in hybrid or multi-cloud environments. The question isn’t whether to secure the cloud, but how to do it effectively while enabling business agility.
For network engineers and infrastructure teams, cloud security requires a fundamental mindset shift. The traditional network perimeter is gone, and with it, much of the network-based visibility and control you relied on. Instead, security in cloud environments is built on identity management, logical network segmentation, encryption, and continuous monitoring. The good news: these are increasingly well-understood practices with mature tooling available.
For security practitioners, cloud security posture management represents a critical addition to your program. You can’t protect what you can’t see, and CSPM tools provide that visibility at scale. They’re not a silver bullet—they don’t prevent all breaches or replace other security controls—but they’re table stakes for any organization managing significant cloud infrastructure. The conversation has evolved from “should we use CSPM?” to “how do we implement it effectively and integrate it into our broader security operations?”
---
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
We’ll kick it off here. Hope everyone’s ready for Christmas and the holidays. But good afternoon, everyone, or good morning if you’re joining from the West Coast. What is today, Andres?
It’s Wednesday, December 13th and welcome to the latest episode of Security in 45. We’ve got a great show for you today as we’re going to talk about an introduction to securing the cloud. If you’ve been on the show before, no slides, just good conversation. That’s kind of the motto for the show.
Hope you all had a great Thanksgiving. Christmas right around the corner. Down in Miami, are you doing the traditional Thanksgiving? Did you do the traditional Thanksgiving meal or how was it?
I actually did. It was, I believe it was the second time I made, we made turkey. I’m probably not going to take all the credit for that one. It was good that night, but the next day it was terrible.
No good leftovers there. Yeah, but no, Mike, this is nice. Really I’m very excited for today. We do have two great experts on cloud security.
We have Sudhir Desai and Edmund Nicholas from the security team of Cisco. Two technical solution experts and this is going to be super exciting. We’re going to pretty much just talk about, you know, high level, how do we approach security in the cloud. And basically today is going to be part one of the two parts that we have on cloud security.
So today we’re going to cover some basics. We’re going to go over a few pain points, things that we see in the cloud every day. And then the next section, the next session, which is going to be next month, we’re going to talk about one of our own Cisco’s product called multi-cloud defense. We’re going to touch a little bit on that today, but we’re going to just leave it for the next one.
So it’s a great topic today. Well, outstanding. You know, in terms of cloud security as a topic, I think it’s something that people traditionally have less knowledge and awareness about compared to like a traditional on-premise security stack, you know, in terms of vulnerabilities, how do we even approach that in terms of security or do we even need to secure it? So we’re going to have a good conversation today.
Now like you mentioned, this is an introduction and we will follow up next session with more detail. Like you mentioned, Andre’s multi-cloud defense. Ed and Sudhir, we’re so excited to have you guys. Sudhir, I’ve known you a long time at Cisco.
You came in years ago with the Sourcefire for Firepower Acquisition and got to work with you in TAC. You’re like a legend. You’ve been working in the security field for over 25 years. So this is going to be a great show.
Let’s kick it off and we will get right to it. Ed, first question we’ll throw out to you. Everybody’s moving to the cloud. Like what’s with the trend of all these companies moving resources into the cloud?
Clearly there are benefits there. Otherwise we wouldn’t be do it. I’ll open that up to you. Yeah, so first, thanks Mike, Andre’s for having me and Sudhir here to talk about cloud security.
Really when I have these discussions around cloud security with folks, we really talk about like, all right, what is the as a service model? How do we consume this module? Because that’s really the difference here. So at the very highest level, like the benefits of that as a service module is probably like software as a service or SaaS as some people might say.
This is where you can just consume applications as needed. We have things like Workday and SAP and Salesforce and there’s thousands of billions of other SaaS platforms out there, but you just consume them. This is very beneficial because you don’t have to deploy anything like that. The second thing is what about like maybe platform as a service, like PaaS we call them.
So think of it this way. Like database as a service. That is a platform as a service. So how do we consume that?
Think of something like a MongoDB. That’s a platform as a service. They’ll provide you the database and you can just go use the database any way you want. Build your own tables, do all that type of thing, which is basically a platform and you use it, you consume it as a service.
And then we’re all familiar with infrastructure as a service. And really what we think over here is like, we have virtual private clouds or VNets. We have networks. We have databases.
We have instances, that type of thing. But we can spend these things out and down as we need them and consume them only as we want them and be charged only as we need them. So that’s really the benefit of going to the cloud. It’s the service model that it provides.
That’s really awesome. Yeah, no. It’s interesting. I mean, what I get to see about cloud is so many things combined, so many possibilities, so many nice things and cool things that you can do.
So that always resonates with me because even though cloud has been around for a long time, I don’t know if it’s probably 10 years, 15 years or something like that, but it’s kind of new for everybody, unless you’re dedicated on working on cloud. So that was really good. Thank you for sharing that. And one thing I think is interesting is how you just mentioned there’s different ways companies are using it.
You mentioned maybe just using a particular application as a service or doing that whole platform as a service. So I guess one of the benefits there I see is flexibility in terms of how your company operates and you can truly get out of it what you want. If you just want something as a service that’s already made and you just get an account and you can log in or do we want to kind of customize this with that platform as a service and get that deployed? Yeah, that’s correct.
Awesome. Well, Sudhir, I have the next question for you. This one’s going to be just a comparison. Actually, we want you to go over, if you don’t mind, the three main cloud providers that we get to see and what are the differences if there’s anything similar between them?
But if you can share your experience with us, that’ll be awesome. Yeah. So in the US, at least the three major cloud providers I see are Google, Amazon and Microsoft with Google Cloud Platform, AWS and Azure respectively. By the US there are a couple, I know in East Asia, Alibaba or Alibaba is one of the major ones.
And in Eastern Europe, we have Yandex. So those are two others that are kind of to be aware of. But definitely here in the US and between the three, I would say they are much more similar than they are different because as we were talking about spinning up applications, doing different things like that, all three of them give you the platform and say, hey, give us your application, we’ll host it. Or they may have applications already existing from different vendors and all of them do essentially the same thing.
But the main differences, and I think we’ll chat about this a bit more further on in the webinar, but a few of the main differences are that if you want something simple that you can just spin up immediately without having to know a lot, definitely Azure could be a way to go just because of how it’s architected on the back end. Or if you want something that’s a bit more network control centric, or if you want something that gives you more controls, Google Cloud is definitely one that does that. Or like we have at Cisco with the majority of our applications being built first for AWS just because we know how to do that and we know how to work with AWS. And all three of them also provide the ability to do scaling and do load balancing across instances such as Ed was working on a project earlier, I think it was with one of the Cisco Lives where he presented on clustering within AWS with firewalls.
So you can just spin up a whole cluster and say, hey, give all these firewalls, you can have much smaller firewalls so your cost is lower, but you have multiples of them. And it round robins the traffic between those firewalls. Or you can do load-based scaling. So if you have the need to rapidly expand your firewalling capabilities, great.
You hit a button or you get an alarm coming in from the system saying, well, your load is going above 80%. Give me some more firewalls. And so Terraform as the example for the automation side of it can go and spin up more firewalls for you and then bring them back down once your load lowers. So I think those are pretty much the benefits and then the little differences here and there.
It’s interesting hearing like, yeah, it’s a good point that I guess when you say they are more similar as opposed to, I guess maybe that’s the way I think of it is they’re offering the same basic service. It’s just how they’re customizing it a little bit differently. I mean, in terms of one offer has a bigger catalog of services and the other can have their little unique parts about them. Do you guys find that customers are using all three?
One customer, how common is it to be like, in my organization, I’m spreading out that multi-cloud environment? I mean, I see obviously in the larger enterprise, diversity is definitely good. You don’t want to have all your eggs in one basket. And so a lot of my enterprise customers are saying, hey, we want to diversify in two, three, maybe even four different public clouds or even private cloud.
So think of it that way. So it’s very normal for us to span across all. That’s why they have security to be able to reach into all three or four or five clouds is very important, especially in the larger organizations. And I was going to say, I’ve seen pretty much the same thing, especially after AWS East went down a few months ago.
A couple of my customers said, well, we had everything in AWS that went very poorly for us. Let’s diversify and get out into the other clouds. I will say that the word multi-cloud started to make trends at that time. What about cloud infrastructure?
I think it’s confusing. How do packets work in the cloud, for example? If I’m real familiar with just the traditional IP based network, is that how the cloud works? How’s my data working there?
How do we talk about or learn about those differences? Well, a little bit. So IP is still IP and packets, datagrams are still packets and datagrams, but there is a big difference. And it’s the way you want to consume it, especially when we’re talking about securing the cloud, but specifically what are you securing?
Because them constructs that you have in a traditional network, like you have your segments and your VLANs, your route domains, you have your NAT, you have all this stuff that you’re used to having. And we kind of have that all in public cloud as well, but it’s different. It’s virtualized. There’s some things that you’re not going to get, like there’s no layer two in public cloud.
So we have to take that into consideration. But really, them boxes, them IP addresses, them VLANs, them static things that we’re used to configuring, they’re not really there in the public cloud. They’re served a little bit differently. So we serve services, right?
That segment, that segmentation inside a public cloud is a little bit different, right? So in VPCs, like you think of a traditional network, right? I have a segment, I have a VLAN, I have a subnet inside there, but you’re not going to be able to, you’re not only going to be using them resources inside them VPCs, right? You’re going to be using resources that are extended way behind that.
Like we already talked about database as a service, right? We have database, you’re going to be using maybe some serverless functions. You might be using like managed Kubernetes. You may be using container services.
Like these are all things that we were able to spin up and spin down. And obviously things that you can just build inside. Like when I talk about the difference between what I get with AWS as compared to what I get with Microsoft Azure is a lot of my services in Microsoft are going to be your standard Microsoft services, right? I’m going to get Exchange, I’m going to get AD inside the cloud and not have to worry about it.
But in AWS, I might be more dev-centric, so more DevOps. I might be using CI-CD code pipeline inside there. Like these are things that we need to start to understand how to secure. A lot of info on that one.
And it’s, we get to see it. We get to see a confusion. I do remember when you mentioned the layer two piece, no ARP. Yeah, it was interesting.
I know there’s a few things in differences between the networking inside of Azure and AWS, but that’s interesting stuff to know. And it’s interesting, like, because as Ed, you were given that overview there, I was kind of thinking about, yeah, you do hear about differences like with load balancing with firewalls and certain caveats when you do that type of feature in the cloud in terms of, yeah, like you said, there’s no layer two network and you got to think about it differently. Definitely. Yeah, well, think about it like I said, in every EC2 instance, there’s more likely that EC2 instance isn’t just serving up one application.
That EC2 instance is probably doing multiple things, probably has containers built inside of it. You need to know how to secure that. You need to know what’s going on inside of that device. So a firewall outside there or an IPS device outside is only going to give you north-south visibility.
It’s not going to give you what’s going on east-west inside of the application itself. Yeah, that’s true. Yes, people’s moving to the cloud, but what about this? And I don’t know if everybody just asked the same question.
I think we do at some point, but we think is our data safe? Can we assume that this thing going to be always available? I know we mentioned some of the fails of multiple clouds and things like that, but what do you think? If you can share with us when somebody is thinking about that, what would you say?
I would say that there is no responsibility on the cloud vendor to keep it safe unless you have entered into a specific contract with the cloud vendor to provide any sort of security. Going about this another way, I know in the federal space there are specific clouds, like specific instances of AWS cloud or Azure that do provide a bit more security so that the frameworks that those clouds have to meet, the security frameworks can be actually in implemented. So, there are additional pieces of security that are provided by the vendor in that case. But for the most part, your data is your data.
You need to make sure that, again, utilizing the principle of least privilege, you need to make sure that only the people, only the objects, only the other scripts that need to have access to that specific data have access to that specific data. And I think in the cloud, a lot of it, we just kind of think of like, yeah, we’re just tossing stuff to the cloud and it’s accessible from anywhere. But then we forget that the confidentiality, integrity, and availability of the data is a big balancing game. The most secure computer is in the Marianas trench encased in 10 feet of concrete.
But that’s not feasible for availability of the data. So you definitely need to make sure that when you put data into the cloud, that you’re putting acceptable industry recognized security around that. We have a bunch of components here or products here at Cisco that can help with that. I’m not going to get onto the Cisco piece.
But it’s like whatever you do put the data, yeah, as I mentioned before, whatever you put the data into the cloud, you have to make sure that you are taking responsibility for that data and not just leaving it around. Whether that’s encryption, whether that’s something like a web application firewall front end in front of your applications, or if there are any data recovery sites you might use, let’s say, hey, I have three or four instances of this data. We were talking about it before in terms of the multiple clouds where AWS may go down, but do we have business continuity elsewhere in AWS with another region or Google Cloud or Azure for the US market? But yeah, it’s definitely on you, the consumer, to ensure your data is protected at all times.
And I think it’s important to know that there’s a few, I don’t want to say just procedures or things, but just frameworks, like the one, the customer responsibility matrix and the framework for cloud architecture. So yeah, those are things that exist in the cloud world. And I guess it’s interesting and important to know them. I just, before we get on to the next question briefly, I just think that’s maybe the biggest takeaway from today’s conversation is, yeah, don’t assume your data is safe in the cloud.
Like, and it’s just further evidence of having your network and security teams working well together. Like it’s one thing to make that data available, but like, man, don’t make any assumptions there. Excellent. Okay.
Since the cloud is not completely safe, how about some examples of recent attacks maybe that some of us or some people on the call here today have maybe heard about, maybe on the news, any that you’d want to touch on there? And Mike, so there’s a couple of things a couple of years ago. I don’t know if you guys remember, there’s a big data breach at Facebook where they had like 530 million user accounts compromised and nothing Facebook had to pay out $5 billion in damages or something like that. Something crazy.
And that was just exposed from a vulnerability within one of their applications. Now, obviously vulnerability management is a big piece, but how do we tie that together within the cloud itself? Like taking another use case here, like a few years before that, inside that Alibaba cloud, they got hacked for like a billion user accounts. And that was done because of like their own misconfigured cloud resources had like no authentication or authorization.
They just went in and took it. And then obviously without the break any chops, but LinkedIn also leaked like 500 million profiles, but that was from just like a bot on the web, just scraping data from it. So the idea here is we really need to be able to secure the cloud itself, but like we also need to secure what’s in the cloud by using things like posture management. So cloud security posture management is a big thing inside of cloud.
And what that does is allow you to see exactly what is exposed. What’s the attack surface of the cloud resources that you have out there? And then also take it a step further, adding in the attack surface management as well. So what’s that blast radius within that cloud?
How far can an attacker actually get into your environment? I always take a say, like, I mean, we talked about this the other day, but when you have like an S3 bucket that’s just exposed to the public, that’s pretty easy to figure out. So, you know, any cloud security posture management is going to say, yeah, don’t do this. This is bad.
Right. But what happens if that S3 bucket is then attached to an EC2 instance that is attached to a web front end that is exposing that, and there’s some sort of vulnerability within there that allows all the data in your S3 bucket to be exposed on that web front end. Like, these are things that we need to map together in cloud security posture management, attack surface management, and a whole bunch of other products and solutions that I’ll talk about maybe a little bit later will kind of give you more information around what’s going on around your application and your cloud. Yeah.
I know we’ve talked internally at some point about those things, like, for example, and we gave a really good example, but I’ve also seen a lot of S3 buckets being publicly available just because they were misconfigured or there were some sloppy configurations that, you know, were not finished, were not locked down in the ass. And then we get to see a lot of data being exfiltrated from those customers. And at that point, it’s part of that message about the customer responsibility, right? So it’s a risk.
Definitely it’s a risk. And that number, like the Facebook one, like $5 billion, it’s just incredible to think about. I mean, talk about saving money by being proactive with your security as opposed to paying after. I mean, it’s incredible.
Yeah. Facebook’s big, but $5 billion stings Facebook. Yeah. This is going to be a super open question, but what do we do?
What are the first things that we do? We start thinking of when we start deploying these things, workloads to the cloud and things like that. How do we prevent attacks? How do we secure resources that we have inside of the cloud?
What are options? If we see that as an alternative. Yeah. So I can take that really quickly.
I would say utilize the tools in the cloud. Each cloud provider has a set of security tools that are built for it. And then if you have multiple clouds, or even if you have a single cloud provider, but you want to normalize that your risk exposure across your entire infrastructure, you can go with a product like Multi-Cloud Defense, which we’ll talk about. I think we have another session coming up on that, but something like Multi-Cloud Defense, which gives you the ability to say, this is what our security posture needs to be.
We want that security posture to be, I guess I just gave a thumbs up somehow. We want that security posture to be available across our entire environment, across each one of our public cloud vendors that we’re utilizing. And so utilizing something like that as well to ensure that unified posture is a good thing. Also multi-factor authentication is always good.
I know here at Cisco, it was a bit of a headache once we migrated to multi-factor with Duo, but now that we’ve really gotten into, now that we’ve really seen how easy it is to use multi-factor authentication once it has been set up, because I think that’s the biggest hurdle is actually getting everything set up. Once you get a good workflow going, even through multi-factor authentication, it doesn’t take much longer than what it did before to actually get, to have that data available to you. And again, as I said before, it’s definitely about that balance between availability and security or availability and confidentiality, where as long as you have access and you’re ensuring that access is controlled, that you’re good to go. I will also say that on the backend, it would also help something like multi-cloud defense or any other log storage that you can have to go through and check your audit logs and make sure that you have a product that will help you looking through audit logs and flagging any anomalous behavior, such as a service account that you don’t expect to change permissions on a file as an example.
Well, what if it does change permissions on a file? You may never know unless you have something on the backend saying, hey, we see this behavior, we think it’s bad, let’s escalate an incident for it. I think one thing that’s coming around within Cisco at least that we can do it, that we can help use is like FDR, where it can push events to the foreground that you may want to say, you should look at this behavior, it doesn’t look good to us, let’s just make sure it is actually good or it’s bad, and then we can go forward and do more of a deep dive investigation on it. That’s true.
I think we do have some interesting capabilities inside of FDR that can see that traffic, and they can raise events or incidents and things like that, so that’s a pretty cool interesting plug on XDR. I like that idea, Sudhir, that’s like a good proactive approach. Ed gave the example of Facebook having to pay all that money back, but to your point, you were just bringing up something that’s proactive. Maybe it’s just anomalous, it’s an incident, or maybe it’s an event, not a true incident, but we’re just being proactive about it.
The other thing that just came to my mind is with something like XDR, whether it’s Cisco XDR or not, but combining all our telemetry from the on-prem that we’re familiar with, but also with the cloud and those flow logs that we’ve been talking, so very cool. I think we’ve been having a really interesting conversation, and if you want to learn more about this type of thing, how did you guys get started, or where do you recommend someone listening to this? I want to learn a little bit more about the cloud, how it works, and securing it specifically. Where’s a good place to get started without getting bombarded with too many details?
Yeah, I always tell people to go to the Cloud Security Alliance homepage, so that’s cloudsecurityalliance.org. This will get you up and running as far as anything cloud, anything cloud-native. It’ll give you best practices, it’ll go through cloud compliance, it’ll give you top threats. It’ll give you all that type of stuff if you’re taking a look and digging into, hey, what’s the cloud actually exposed to?
And then obviously the other ones is SANS, because SANS.org does a really good job of bringing together some very detailed information around cloud security awareness, cloud security awareness training, DevSecOps, AppSec, so application security. The one thing that people, I think, get a little bit confused around is what’s the difference between DevOps, DevSecOps, and application security? They’re all really different things, but DevSecOps is really just part of DevOps, but it’s got its own little niche. And then the other thing that I really want people to start to dive into, and I would say the biggest thing, is cloud-native application protection.
So I talked a little bit earlier about cloud security posture management, attack surface management. Well, a lot of tools out there today are geared towards taking them, too, as well as workload protection, container Kubernetes protection, API security, CI, CD security, repo security, all this stuff, code security, application security, and rolling it in the one platform so you can start pivoting through all these things into one interface. So now, if I have an EC2 instance that’s running Kubernetes master or is running a Kubernetes stuff, and it has containers running on it, and it’s got workloads running it, and then workloads have APIs, and then APIs and code are running through a CI, CD pipeline, you want to stitch this all together and give you one holistic view of all the security in there. And that’s what CNAP, cloud-native application protection, is going to be able to give you.
So the first one you mentioned was cloudsecurityalliance.org, and then CNAP. What does CNAP stand for one more time? Cloud-native application protection platform. Write this down because I’m going to check these out as well, so thank you.
We always get to learn so much when we do this. I know. I love these. All right.
I guess we’re going to move to the next one, and this is going to be pretty much a segue into multi-cloud defenses that we’re going to ponder off to our next episode or next month. But I know everybody on this call knows that Cisco came up recently with a new thing called the Cloud Protection Suite. This is if you can tell us a little bit about what… And this is just going to be a point product inside of this suite of software for our customers.
But if you don’t mind, Siddharth, if you can expand on the multi-cloud defense, what is it? We’re going to expand more on it, but if you can give us a little teaser on that and add if at the end you want to add something, feel free to add it. Yeah, sure. So multi-cloud defense, what I mentioned briefly before, Cisco, as you guys know, loves snapping up companies that provide extra security for us.
I came from an acquisition 10 years ago now, 11 years ago now, and we’re always trying to innovate as well as purchase to innovate. And so recently we purchased Valtix, which essentially is the same thing as multi-cloud defense. And their three main products were protecting Oracle Cloud, AWS, as well as Azure Cloud. And that’s kind of the background.
And I will say if you haven’t heard of it or you’re not familiar with it, and maybe you’re familiar with Tetration or Secure Workload, where we have agents that run inside of a virtualization environment that dictate the firewall status and the firewall rules of every single workload running within that environment, that’s essentially what multi-cloud defense, what Valtix is and what they do. And so what we can do is we say, hey, actually, as I mentioned before regarding that single security posture, normalizing your risk profile, it allows you to say, cool, we have a set of APIs on the side. We’re going to go in. We’re going to set up some virtual private containers.
We’re going to set up some networks inside of the cloud. And we’re going to pass all the data through, make sure that it is secure, make sure that the firewalls in those pieces of software do what they need to do and make sure that your data is safe. That’s kind of the 10,000 foot view of multi-cloud defense. But yeah.
I always like to tell people the multi-cloud defense is take all them firewalls. You can’t take a physical firewall and stick it in the cloud. It doesn’t fit. The idea is take a security appliance, put it into your cloud, cloud natively.
What that means is let’s use cloud constructs to build it. Let’s not stick a firewall in there. And then let’s allow that to then inspect all the data as it’s going through your VPCs and between VPCs, ingress, egress, everything, and then apply things like traditional firewall rules, but also web application firewall, IPS, AV, anti-malware, so on and so on. This way you don’t have to worry about stitching, routing stuff through a firewall anymore.
It just does it natively. And then you have that one policy over all three different clouds. So AWS, Azure, GCP, you have one policy. And then you have all your dynamic rules and dynamic objects bubbled up into that one policy.
And then you’re ready to go. And you deploy the whole thing via automation. Does that one, just to kind of round this up, does the one policy mean I don’t have to know about the details of each individual cloud? Does that help with that?
Okay. Yes, exactly. Okay. Well, that’s going to be a great, great topic for next month, but a nice little overview there.
Quick time check. We’re looking good, Andres. I think we’ve got time for some dad jokes here if you guys are okay with this. Now let’s get right to it.
So really interesting question I was thinking about, because we’re talking about data storage in the cloud. And I’ve heard people ask about this. Is it true that if it’s raining, that we need to be a little concerned about our data getting wet and potentially corrupt? Yeah, no, I think you definitely have to worry about that.
I don’t know how to kind of explain how that happens, but if it rains, you’re screwed. So now that seems to me like we need a product for that, like some type of waterproof thing that can go around our resources in the cloud. Excellent. Okay.
We already have it. It’s called Umbrella. All right. I hope I don’t mess this one up, but here’s a million dollar idea probably.
If anybody going to steal it, just let me know. But is it a good idea or maybe a stupid idea? But what about a security application, security app where if you cough on your computer, your antivirus will tell you, will start running and tell you if you’re sick or not. What about that?
I think you’re a little bit late to that one, man. I think Apple already does it. So you can cough on your phone and it’ll be like, oh, you’re contagious. Stay away from others.
Yeah. I think it’s more like COVID one time. That’s a great idea, but we’re going to think of something else if we want to retire early. Yeah, I know.
Someone’s already done that. One thing, some people, it’s been like a trend, a lot of people going vegan and even just like vegetarian, but have you heard about that new technique people are doing when they go to the grocery store so that they don’t walk down the canned meat aisle and get tempted? They have, it’s called like a spam filter. That’s terrible.
Who doesn’t like spam? I know. I mean, I think even vegetarians should like it. Exactly.
It’s fake. Who doesn’t eat that? All right. All right.
The next one is going to be fun, but have you guys heard about this cyber criminal that was able to get into heaven? Funny thing is that he apparently found the password to the gate that had not been changed in about 2000 years. Oh man. You know, you would think they’d have better security than that.
Or at least like, or at least like an MFA, even with the bad password, if they have basic MFA in heaven, they still wouldn’t have been able to get in. I got to go confession just from hearing that. Right. What do we got?
Time for two more, you think? We started a little bit late. What do you think, Andre? Two more?
What would sting more? If you were like, you know, paying ransomware because you did not have your security in layers or having to peel actual layers of onions. Onions. Onions.
Onions. Yeah. Onions are the worst. But what if it was Facebook for $5 billion?
I’ll take 5 billion. All right. And I guess the last one, this one is very, very with the theme of this month, but does Santa have any cybersecurity concerns? I don’t know.
I think maybe seeing as he is who he is, he may be worried about Talos shutting down his botnet. I don’t know. Well I know I have truly enjoyed this session. I think one of the best sessions we’ve had.
Just a quick recap of today’s topic. So I thought it was interesting talking about the benefits of moving to the cloud. We all know everyone’s doing it, but why are they doing it? But getting that as a service model that’s just instantly available and then having the redundancy and the availability is huge.
We talked about and compared AWS to Azure, GCP. Sudhir you touched nicely on maybe thinking about them being kind of more similar than they are different, but they each have their unique differences in terms of what they’re offering, how they work, and then in terms of offerings of each cloud. And then Ed, nice example comparing kind of like quote unquote routing between an on-prem network and then moving to the cloud where we’ve got APIs and we’ve got containerization there. And then the risks in the cloud.
I thought one of the main takeaways, I said this earlier, but just being aware of that misconception that just because you drop something in the cloud doesn’t mean it’s secure. So just being aware that safety and security do need to be layered in on top of whatever you put there. So just some takeaways for me. Yeah.
And from my point of view, I think just thinking about those specific tech tags that we talked about a few minutes ago, make sure that if you’re implementing things to a cloud, make sure you secure them. If you don’t know, if you’re not sure what you need to secure, I guess there’s an app for that. There’s a few services for that, of course. Then I know along the hand with that one, cloud security posture management, that’s another thing that be on the lookout for.
And the next few things, basics on securing the cloud, make sure that you go and we’re probably going to put it on the event on the communication community space that we have for the cloud security alliance. This is a really good recommendation. Same thing for cloud native application protection. There’s more information there.
Again, same thing that I just mentioned, there’s an app for that. And the last part on multi-cloud defense. There’s actually three things that I do really like about multi-cloud defense, just to give you some info for, to look for the next webinar, network visibility, routing and connectivity, and then security automation. Those are three key pillars of the actual multi-cloud defense piece.
So super, super nice, Mike. I guess this has been another one that it’s super, super informative and I’ve learned a lot. Don’t forget to fill out the survey at the end, Aiden from Indiana State University won our survey fill out challenge. He’s sporting some nice swag right now, but I do want to give a special thank you to Ed and Sudhir, just amazing conversation.
Thank you both so much for, and not just for the show, but all you do in the industry to help keep people around the world secure. Our next call is going to be part two. So January 17th, Cisco’s cloud native security solution. Again, it’s called multi-cloud defense.
Again, please fill out the survey if you can so you can wear a hoodie or whatever you want. We’ll send out a gift card to the winner there. I hope you all have enjoyed the session as much as I have. Happy holidays, everyone.
We will see you in 2024. Thanks guys.
Related Posts
Multicloud Defense: Unified Visibility Across Cloud Environments
Discover how Cisco Multicloud Defense delivers unified security visibility across AWS, Azure, and GCP with AI-driven threat detection and response.
Zero Trust Security: Beyond Products to Concepts
Why zero trust security is a philosophy, not a product. Learn the foundational concepts, MFA requirements, and practical implementation strategies.
Network Segmentation Strategy: Micro vs VLAN Approaches
VLAN vs micro-segmentation: compare network segmentation strategies including Security Group Tags, group-based policy, and zero trust enforcement.