EP94 Meet Cloud Security Acronyms with Anna Belak

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the Senior Product Manager for Threat Detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast's wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday Pacific time, please do hit that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, we've got acronym soup served piping hot today.

Yes, indeed. And it's— I guess I shouldn't say one of our favorite guests, but I guess I can say this because—

No, she's definitely one of our favorite guests. She's great.

She's great, but the thing is that I'd rather make a fact-based statement about her being one of our favorite guests because frankly, her episode scores so well, it's almost like an anomaly. If we were a Yuba, we would flag it.

Ah, so we've got an Anna acronym anomaly on our hands.

Exactly.

Got it. Well, maybe without further ado, let's talk— oh, and listeners, if you're new to cloud security, this is going to be great because you'll learn a lot about acronyms. And listeners, if you've been around the block in cloud security, We simplified a lot of stuff here, as you'll see. So let us know on Twitter, let us know on LinkedIn, let us know by pigeons how we got it wrong, because we'd really love to chat more about this stuff. With that, now we'll turn it over to today's guest. And with that, listeners, I'm delighted to introduce today's returning guest, Dr. Anna Belak, Director of Thought Leadership at Sysdig. Anna, one of the things I've loved about doing this podcast over the last year and a half is that we provide a way for people to learn about cloud, who maybe don't know so much about cloud security. And one of the things that I love about you is that you're so good at explaining things that Anton makes very confusing. So I thought this would be a really fun episode for us 3 to sit down and talk about some of the bizarre acronyms in cloud security that mostly start with the letter C, although not exclusively start with the letter C. So are you on your A game or your C game? No B game.

I am gonna kill it.

Okay, so let's just talk about these and help people get up to speed.

But before we go there, you have to remind the audience, Tim, that two of the three people on this call were in the acronym-making business for a good number of years.

Ah, yes, yes.

So in that sense, we weren't just looking how the sausage were made.

You were making the sausage.

We were making the sausage.

Okay, so listeners, we've got two sausage manufacturers here to explain where the sausage—

Former, former.

Reformed.

Reformed sausage manufacturer.

That's right. I'm reformed. I don't know about Anton.

I'm recovering.

Okay.

So let's start off with an easy one. What is a CSPM?

That's the easy— oh my. All right. CSPM stands for Cloud Security Posture Management, which tells you almost nothing, I imagine.

It tells cloud practitioners to stand up straight, right?

Oh yeah. I'm actually quite bad at that.

Listeners, everybody on the video call just sat up a little bit straighter and like cracked their necks. So what's CSPM?

My short version is CSBM is the modern cloudy flavor of what we used to call security configuration assessment.

If I don't know what security configuration assessment is, what does that mean?

I'll tell you. Security configuration assessment is SCA, which is actually my favorite acronym because it stands for so many things, including software composition analysis and Society for Creative Anachronism and much more. Anyway, it's about figuring out whether or not your assets, whatever they may be in your data center, presumably are configured in some kind of way that is consistent with either a compliance standard or a company policy or a random best practice that you found on the internet or what have you, such as a CIS benchmark.

But wait a second. When you said that in your mind, CSPM is somewhat similar to security configuration assessment, do you think that many vendors in the audience just cried out in pain? Because you compared a new generation of vendors to the previous generation of vendors. And usually some of the startups take pretty massive offense in that, right? So what's your take? What's your response?

Including my employer, probably.

I mean, it's a legitimate position that why are you comparing this cool DDR technology to old-style DLP? And why are you comparing this amazingly cool OpenXDR to an old SIEM? But in this case, you kind of compared CSPM to kind of vulnerability and configuration assessment circa 1998.

Oh, I didn't say vulnerability. It gets darker actually when we go there, but—

Ooh.

Anyway, I mean, I think it's because it makes it clear to people what it's doing, right?

What's the point of a CSPM? What do you get out of a CSPM? What gets better when you deploy one?

Ah, awesome. I love it. Wait, wait, wait. Let's just freeze here and say, audience, Tim asked a really good question. Ask it again.

What gets better after you deploy a CSPM tool?

I wish people think about all the vendors they buy like this.

This is so hard to answer. I want to say you can get a list of useless information.

Whoa, whoa, whoa.

Get a list of useless information you didn't really want to see.

That maybe doesn't speak very highly of the CSPM industry if we can't say what good they do. I have an answer to this. I can answer my own question if you want.

No, I mean, so what good they do is they will scan all of your stuff in cloud, presumably, if it's cloud security posture management, and they will alert you to things like misconfigured—

S3 buckets.

Yeah. Like you might open, open S3 buckets. You might have identities that are kind of over-permissioned and, and all these kinds of things that you really shouldn't be doing. And typically the reference point is gonna be like a CIS benchmark or maybe a PCI compliance standard or something like that, that pretty much everybody cares about. And so actually most people get involved with CSPM in the first place because they have some sort of compliance requirement they need to meet and they're like, what can I buy to deal with this? And then they buy a tool, run a scan, they see a huge list of results, which they may or may not do anything about.

This does remind me of vulnerability and security—

A little bit?

Vulnerability assessment. Yeah, exactly. This is kind of like you scan and then you see things, but a CSPM can completely automagically fix the problems, right? Right? Right?

Well, if you'd let it, perhaps, but I don't know that we let it.

There's probably some risk in having a tool automatically take action and Potentially production environment.

To remove access from all of your admins, for example.

Didn't we have an episode, Tim, where we said in the cloud you automate or die?

It was literally our 3rd episode.

Yeah, exactly.

Yeah. So that's interesting. So CSPM is really all about, let me scan my cloud infrastructure, let me find the things that are not configured very well and help a security team either automatically or manually fix those things.

There's a slight nuance here that people may care about. And it's that in this original form, CSPM was supposed to deal with the cloud control plane specifically. So there's a distinction between like the configuration of your cloud or your cloud accounts and the configuration of the workloads that you deploy into IaaS in that cloud, or even the configuration of your Kubernetes cluster that you've deployed into perhaps GKE or what have you. And CSPM initially deals with just the cloud control plane. But of course we have scope creep. So depending on whom you ask, vendors may assert that it should include more things than that and that perhaps it should also include vulnerability management.

Ah, so let's talk about vulnerability management. What's vulnerability management?

It's vulnerability management.

What does that mean?

Is it though? Because there's vulnerability management and then there's the other SCA.

There's no CVM though. There's no cloud vulnerability management. I hope you're not giving them ideas, but there is no CVM. We weren't planning to talk CVM.

Whoa, whoa, whoa.

Hang on, hang on. I'm gonna look at my document. I don't see CVM.

what vulnerability management is before we give the remaining Gartner analysts bad ideas. It sounds self-descriptive, but I want to be sure that people know what it is.

Yes, you find vulnerabilities and you hope that you fix them if you've determined that they pose a risk to your organization.

Well, that sounds simple, but I know people struggle with it.

Right. Yeah, because there's a lot of vulnerabilities and it's hard to tell if they pose a risk.

There's also a critical dimension that Anna and me, as far as I recall, wrote about while at Gartner, namely the prioritization. You don't just scan and hope, you scan, Prioritize and then hope.

How do you prioritize?

It's scan, rank, hope.

How do you prioritize?

Oh, there's a lot of attempts to prioritize based on the values and the exposure of the asset, what it's used for, roles. But a lot of them are very on-premise sounding. I think that's why maybe Tim is making a face at me. But some of them, the role of a system or what the system is connected to, what it's used for, what kind of services it runs, may have to do with how important is it to fix the vulnerability. So there's a, there are whole vendors. I don't recall what we ended up calling them at Gartner.

TVM.

RBVM?

TVM.

Risk-based vulnerability management, which was the whole brain behind ranking vulnerabilities so they can scan, rank, and then hope.

Got it.

Hope is the important part.

Hope is the important part. So listeners, one of the fun things about being a PM is you get to live in the future. We're going to have a fun future episode about exactly this problem.

Yes.

I want to shift gears and talk about another important acronym. Which is CWPP. What is a CWPP?

I think it might be my least favorite.

Mine too.

I don't know. Cloud Workload Protection Platform, which sounds like it should be the next generation of endpoint protection platform.

But in the cloud.

But in the cloud, yeah. But I mean, like, that begs the question of like, well, can't you just take your EPP and put it in the cloud and call it a day. And of course, like, the vendors will squirm and be like, no, no, it's totally different. There are like APIs and stuff or whatever. I don't know.

There are APIs and stuff in the cloud. That's true.

Yeah.

I've seen them.

I've seen them. You've seen them. And the description of a CWPP by various entities, such as Anton's and mine, former employer, are also a little vague. The one thing they are clear about is that it does not deal with the cloud control plane. So in the world of Shared responsibility, presumably. CWPP deals with the things you, the user, have deployed into the cloud, not the things that the cloud provider themselves have handed to you for you to play with.

What about your use of that control plane and things like your identity policy or your organization policy?

This is an excellent question. Anna is making a face in the background.

That's like really painful, right? Because first of all, CWPP sounds like a thing you buy from a third party because the cloud's just not doing it for you. But then we have clouds that actually offer features that smell like CWPP.

Right?

Like the thing you work on. Oh God, what is it called?

Security Command Center Premium.

No, no. And VMTD in particular.

VMTD.

I think VMTD has the magic, right?

VMTD is like obviously a CWPP kind of thing, but it's like so deep in the cloud that you don't even get to see it. It's just magic, right?

It just works.

Yeah. So this is why CWPP is weird because it sounds like it should be a thing that you like install an agent and blah, but actually, right?

Have you tried installing agents in cloud? Also, attackers don't install agents in cloud in the instances they create.

Are you sure?

No, they do sometimes. Yeah. They like, if I install a script, when I compromise your cloud instance, I put a script in there. That's kind of an agent, right?

It's not an endpoint protection agent.

No, no, no, no. It's a malicious agent that an attacker put together.

Yes.

Why would an attacker do that to themselves?

But that's what I always say to people who think we're gonna secure cloud with agents. It's like, you don't understand what the attackers are doing at all.

So CWPP though is kind of, at this point, it's getting long in the tooth, right? It's kind of a—

Is it?

When was it coined? Yeah, I think they coined it 2012, '13. It's quite dated. So as far as I recall, CWPP, if you mention it in like a cool kids company, you're gonna get the look because you're like not up to date. But to really be up to date and to impress your cloud buddies, you have to say, This is coming. CNAPP.

What's CNAPP?

Oh, CNAPP.

Is this when I'm out in a boat and I go to sleep for a little while?

You know what? CNAPP. That's right. Yes. But actually it's worse than that. When I first heard of CNAPP, my first thought was like, I thought Gartner banned 5-letter acronyms because CNAPP has 2 Ps. Oh, right, exactly.

What does it stand for?

But then I read it, right? But wait a second.

So does CWPP.

To me, CNAPP is an unholy marriage of CSPM and CWPP.

Gartner also, I believe, asserts that this is the beginning of it. So CNAPP, by the way, stands for Cloud Native Application Protection Platform, which begs the question of, is that different from a workload in CWPP? And also what's up with that N of cloud native? Does that make it special? Because it wasn't cloud native workload protection platform. Anyway, very interesting. So the short version is CSPM plus CWPs.

Fed team without any interest.

Right. So the point, I guess, is, or I think the vision might have been, that it's hard to say anything about the workload security without thinking about that posture thing we discussed earlier. And so when you connect things you see when something is running with things that you see when you've just asked it how it's configured, you can reason more intelligently about its risk status, if you will. So thereby bonding these 2 things to each other somehow is supposed to help us know more about all the assets and all of their various security issues to help prioritize, as Anton pointed out earlier.

By the way, we forgot to ask Anna's team's question about what gets better when you deploy CWPP.

Oh yeah, sorry.

Sorry, I have to bring it back simply because I'm so impressed by the question. I want to try to help you by answering this, by starting to answer it, namely that I feel like what gets better is if you lift and shift. Then your cloud security becomes better once you push CWPP in there, right? No, no.

I mean, maybe, but like, why can't you just EDR in that scenario? Like lift and shift your agent with your garbage application into your garbage IaaS and you're fine.

EDR at $50 per endpoint in the cloud? What are you talking about?

Oh, that's not very nice. I wouldn't call all lift and shift garbage. No, I think there's really serious workloads in there that need real serious protection.

There really are. There are. It's true. I think you're kind of right, Anton, but the reason I actually— you'll appreciate this— the reason I don't like CWP is it makes no mention of detection and response. You have this protection thing, which is— why is it purely preventative? I don't know. Is it blocking stuff?

Is it meant to be preventative?

It's not clear. I think it's actually meant to be more than preventative.

Okay.

Because hygiene is in, prevention is in for sure.

Yeah, yeah, yeah. But the detection and response is a little bit hand-wavy. A lot of the comments on the, what we would imagine is detection response, are things like behavioral analysis. And I'm like, I don't know what that means. That could be anything.

I don't know.

And it's probably why CWP maybe has gone a little bit out of favor because we never really defined it that well. It wasn't really that clear whom it was helping and what it was making better. And so CNAPP, to that end, I think actually makes, at least in my opinion, this is not a Gartner or Sysdig opinion. This is an Anna opinion. I think CNAPP veers specifically toward the target audience of people who are building software.

Hmm.

So there's this distinction that I obsess over that some people stare at me blankly when I say this, but I think it's actually really important that there's software you bought and there's software you built, right? And we're used to running a lot of software we bought, especially in data centers on metal that we own ourselves. And vulnerability management in the sense that Anton was describing typically also refers to software you bought. So your way of dealing with the vulnerability is waiting for the vendor to ship you a patch and hoping that your ops team will apply it someday. When you deal with software you build, there's a whole other issue here where you now own a lot more of that supply chain. So you may have included open source packages, which brings us back to our SCA acronym. You may have built your own code and CNAPP includes a lot of pieces that address problems with software you built. In fact, according to some people, CNAPP includes AST, which is application security testing. And that's a whole bunch of stuff that doesn't typically play any role for SecOps teams. So it wouldn't be part of CSPM or CWPP.

But wait a second. So CWPP, this actually is funny enough. I think what Anna said is actually kind of clear. And CWPP very much lived in the world of software you buy.

Yes, I think that's fair.

It's like, I don't think anything in CWPP documents and people who deployed it said anything about anybody writing software. All the software comes in shrink wrap in CWPP world. Nobody custom writes anything. But CNAPP lives in the modern world where, what a surprise, people write software. And they have infrastructure as code, and they have other stuff that's software-looking. So maybe that's why CWPP became a 2010s acronym and not 2020s acronym, because it lives in the bygone era.

Yeah. And it's kind of given away by the fact that if you look at the kinds of requirements that people associate with CNAPP, there are often things in there that are like container security or infrastructure as code or sort of patterns that you just didn't have on-premise because either we never got that far into automation or they evolved essentially in the cloud just because of the way that things happen.

Okay.

So, let's switch gears and shift to my least favorite acronym that starts with a C. And that acronym is, of course, SIEM. And you may say, Anton, what do you mean starts with a C? SIEM starts with an S.

It does not.

You'd think so, but you'd be wrong because there's a CIEM acronym, Anton's least favorite acronym. I'm gonna mention it maybe 3 more times. So what's your take on that? It just sounds kind of strange to me. Like the whole CIEM thing is just bizarre. What's up with that?

I think some people call it Kim to distinguish from— Kim.

Sim.

Ooh, yuck.

I don't know if there's better words.

Ugh, that's disgusting. So what is it? What is this horrible beast?

There's actually a dispute as to what it stands for. I believe the actual thing it stands for according to Gartner is Cloud Infrastructure Entitlement Management.

Just say it again. Cloud Infrastructure Entitlement Management. So the only letter that stands for the same as in SIEM with an S is an M. I and E are completely different.

It has nothing to do with SIEM whatsoever. I mean, there are logs involved sometimes, but that's about it.

What does it mean?

By the way, the other interpretation is Cloud Identity and Entitlement Management because it is an identity thing, right? So—

So is this just monitoring our IAM policies and telling us when stuff's overprovisioned?

Kinda, yeah, kinda.

That's not so interesting. Why does that get an acronym?

Why not? I mean, don't they get paid by the letter?

Why not call it ITDR, Identity Threat Detection and Response? I think somebody did.

That's asking a lot.

Why not just call it part of your managed threat detection offering and move on?

Or call it IAM feature.

Yeah.

You'd be a terrible analyst, Tim.

Yeah, I know.

Can you say something? Maybe you can say something nice for SIEM, for SIEM, for whatever it is.

This sounds like a feature, not a product, but go on.

I mean, there's some nuance. I think there's a cloudiness element to it because I know nothing, by the way, about old school identity and access management or new school identity and access management. But CIAM specifically deals in cloud identities, which are very different from your traditional understanding of accounts, users, and identities on-premise. So you have things like non-human identities and all these different kinds of roles and who can assume those roles and all these weird permissions. So it helps you deal with that nightmare.

Yeah. And listeners, if you find that area interesting, you should check out our episode with Dylan Avery on some of the risks associated with that.

Which is awesome. I totally listened to it. But there is an element of monitoring there. So there's supposed to be some checks to see if, for example, some unusual activity has occurred where maybe permissions were removed or permissions were granted where they shouldn't have been and so on.

So it has both a configuration aspect as well as a behavioural detection aspect.

Yeah. And so the reason I kind of laugh at Anton's sim comment is if you sprinkle enough glitter, you can sort of smell a bit of UEBAA in there, actually.

Please don't pronounce that acronym. I always make my team say U-E-B-A.

U-E-B-A. I'm sorry, U-E-B-A is so much cooler than UEBAA.

Oh my God. I also sometimes hear U-E-B-A. I'm like, ugh.

I think U-E-B-A does sound kind of scary, especially if you start thinking how if you write it in Russian, it starts to look even worse. That is inappropriate. I think Anna is funny enough to cheer.

Well, listeners, that's a joke I'm not sure I get, but we've got one more acronym to cover before we wrap up and we're getting towards time.

By wrap up, you mean before we ask about CASB, right? And then the whole thing unravels and we have to run.

Yeah, yeah, yeah. We'll get there. We'll get there. We'll melt Anna's brain. And it's like, what's CDR?

No, no one knows. I'm just kidding. Some people know. It's not as common. So CDR, I think actually mostly gets used by vendors, not so much by Gartner. I don't, know why. I have a theory, which again, this is not a Gartner's opinion, is that they meant for CDR to actually be CWPP, but they kind of like never bothered to add the DR part.

Mm-hmm.

So then people like myself and Anton who are like out in the world now thinking, gee, y'all forgot the SecOps team, which seems critically important to this whole cloud phenomenon and they need a thing. Thought like maybe we should call that CDR or something of that nature. There is Again, you get into questions about, well, why can't you just EDR? And the answers are sort of things that Tim would say, like, okay, we don't want an agent, or how do we EDR on serverless? Or how do we EDR on things that are super ephemeral and all this stuff? Right. There's no EDR. So you do get into some fairly substantial technical challenges of how to implement such a thing such that you actually have enough information to detect anything. And when it's things that can't be done by, e.g., your cloud provider, like what Tim works on, it becomes quite hairy quite quickly, especially when you're talking about software you build, because then it's also unclear what to even look for potentially. So yeah, there's a lot of work to do there. And, you know, shameless plug, that's part of what Sysdig is working on. So check us out.

I like the idea of forgot about SecOps. That's like, y'all know me, still the same OG, but I've been low-key. Yeah, it's a Forgot About Dre reference, everybody. But no, I think that's really interesting because how could you forget about the DNR team? Like, that's one of the most critical pieces.

Yeah, this whole CDR thing is a bit of a story, and I think I'm going to pitch my own blog, Does the World Need CDR Acronym? Right?

VergeR.

That's a good question, right? When we were writing and researching stuff for Gartner, we didn't think of coining CDR because we did assume that the DNR functionality is included in the CWPP platform. So that was very much what I was thinking about when writing papers about SOC. And I think if I look up my Gartner work from, say, 2017, I would say something like, you must have CWPP feed your SIEM where your cloud telemetry, cloud events would come from CWPP. This was the assumption. But the whole CWPP thing kind of maybe not unraveled, but kind of went off the rails a little bit.

Mm-hmm.

So, we couldn't even say, oh, everybody deployed it, and that's the main source of events and detection activities from the cloud because that's not the reality at all. So, maybe today we live in the world where CDR Either built by Tim/cloud provider or built by Anna/vendors needs to exist.

And when you said feeds your sim, you mean sim with an S, not sim with a C?

No. Yeah, sim with a C is dead for me. I don't want to even think about it.

Your sim with a C can feed your sim with an S if you really want.

That's true.

Just don't do it to me, please.

Or it could feed your CDR.

I'm going to go run away and look for whiskey in my room, and it's still kind of early, so no.

It's a little early for that.

Okay.

We've got one more. What's a SASE?

But we need to briefly, briefly have a 10-second, 2-second thinking pause. Are we going to go there? Are we going to go to CASB?

No, don't do it.

Okay. We'll talk about CASB another time.

Don't do it.

And I actually think listeners, I actually think listeners, there's a really interesting episode we did with the Obsidian guys about how they bring CASB to software as a service rather than infrastructure as a service. Really interesting stuff there. So that's That's basically the time we have for today, Anna. I, as always, enjoy having you here. I would love to do this again and talk about a whole bunch of other acronyms. Listeners, please let us know where we got it wrong. I think this is one of the episodes where we'll get the most hate mail on Twitter of all the episodes. So you know how to find us. We're looking forward to it.

But we have to ask our favorite closing question, of course.

Oh my God, our closing questions.

How can you forget?

Yes, Anna, first off, any recommended reading? And second, I don't even know how, how do you get good at cloud acronyms?

I'm going to, I'm going to cheat and answer the question I want instead of the one you asked.

Perfect.

So, classic Gartner analyst, right? Recommend reading. I don't have any great acronym reading. I mean, you should read Gartner stuff if you have access to it, just to get an idea of how they concocted all this nonsense, because it sort of helps a little bit. I will shamelessly plug our own content. So we have 2 pretty cool assets that aren't about acronyms, but they're actually about the things acronyms are meant to address. There's a Sysdig paper called Anatomy of a Cloud Attack that talks about how cloud attacks are different from on-prem attacks trying to achieve the same thing. And there is a Sysdig Cloud Native Threat Report, which our fantabulous threat research team has released recently, that is very, very interesting. You should read about it. I'm going to tell you though what to think about when you, the end user hopefully, are trying to navigate this nonsense. And it kind of is what Anton and I were pointing out In terms of SecOps team being forgotten, right? The name of the tool doesn't really matter. And even the list of things the vendor alleges the tool does doesn't really matter. What matters is who's supposed to use this thing, right? If you're buying it for your SecOps team, you need to make sure it contains functionality that the SecOps team expects or needs, whether that's in cloud, on-prem, wherever. And so things like, what is CSPM or what is CWPP, actually are kind of pointless questions because the question you should be answering is, what am I trying to accomplish and who is meant to be using this?

What gets better as a result of using it?

What gets better? Yes.

Yeah.

What gets better? about to say, or think like Tim does, what gets better when you deploy it? And if you are in a head-scratching mode for 3 days trying to figure it out, maybe don't. Then maybe the answer is don't deploy it.

Maybe don't buy it. Yeah. And I mean, some of these things are evolving, right? So like CNAPP itself is very confusing because it potentially targets multiple buyers in your organization. Some of whom may be SecOps and some of whom may be DevOps and some of whom may be somewhere in between. And so understanding what the specific tool you're considering or the specific use case you're dealing with is supposed to do and who is supposed to deal with it is really much more critical than how many letters were in the acronym or why Gartner made it up in the first place.

Well, with that thoughtful answer, thank you so much for joining us today.

It was an absolute pleasure. You guys are always very fun.

And now we are at time. Thank you very much for listening and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton_Chuvaikin and _TimPico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.

Security.