mnemonic security podcast
The mnemonic security podcast is a place where IT Security professionals can go to obtain insight into what their peers are working with and thinking about.
mnemonic security podcast
CNAPP
In this episode of the mnemonic security podcast, Robby is joined by Scott Piper from Wiz and Håkon Sørum from O3 Cyber to talk cloud security.
They cover the evolution of cloud security products since Amazon's release of S3 and EC2 in 2006 and how the market has matured into the CNAPP we know today. They chime in on most of the buzzwords associated with CNAPP, including Cloud Security Posture Management (CSPM), Cloud Workload Protection Platform (CWPP), Cloud Infrastructure Entitlement Management (CIEM), and Cloud Detection and Response (CDR), as well as other key areas of CNAPP such as vulnerability scanning, "shift-left" security, cloud data security, and compliance.
They explain the definition and challenges of "cloud-native attacks" and misconfigurations and discuss whether third-party SOCs can add context and enhance detection capabilities.
From our headquarters in Oslo, norway, and on behalf of our host, robbie Perelta. Welcome to the Mnemonic Security Podcast.
Speaker 2:The cloud is just someone else's computer, but their parents make more money than yours. Therefore, they just have cooler things than you do more money than yours. Therefore, they just have cooler things than you do. If you're in an organization with cloud-native applications and DevOps practices, my guess is that you've already felt the need for a CNAP tool, even if you don't know what the abbreviation stands for, and as you'll soon hear, it's basically an umbrella term for all the tools needed to protect cloud-native applications. So how do we organize ourselves in a world where our assets are in the cloud but our procedures and thinking are still in the basement? Scott Piper and Håkon Sudum welcome to the podcast.
Speaker 1:Thanks for having us. Thank you.
Speaker 2:I love you, Håkon, but your name is impossible to say in English.
Speaker 3:I know, I know you can just go with Nick Much easier.
Speaker 2:I would call you Håkwan, but you've never heard that one before.
Speaker 3:No, that's a new one.
Speaker 2:But you two know each other from before. How do you guys know each other?
Speaker 1:So I guess I originally met Karim, who works at O3 Cyber, one, but you two know each other from before. How do you guys know each other? So I guess I originally met Karim, who works at O3 Cyber, and I ended up going to Oslo a few months ago in order to go to an event out there and spoke there, and so I met Hoken out there.
Speaker 3:Yeah cool Through mutual cloud security. Friends, as we say.
Speaker 2:I actually saw you on stage there, scott, and I was just like a little girl in the back, like I don't want to go ask him yet, so I'll just hit him up on LinkedIn.
Speaker 1:Awesome.
Speaker 2:And Håkon, who are you?
Speaker 3:Oh, first of all, thank you for having us on Like. I'm so honored to be on with the closest thing we can get to a rock star within cloud security research. So I'd like to say that I'm a career consultant. I actually started my career in Mnemonic some years back and then I've worked with network security, security, monitoring, cloud security application security, all that ever since.
Speaker 2:You've done well for yourself. Håkon, I'm very proud of you. Even though you left mnemonic, you're always a mnemonic in my heart.
Speaker 3:Yeah, you can never. It's the best education in cybersecurity you can get in Norway. I'd say I won't disagree.
Speaker 2:And Scott, for those that live under a rock or don't work with cloud security. Who is Scott Piper?
Speaker 1:So I started in cloud security maybe in like 2016 or something. I had started up my own consulting business and I released a number of open source tools and other free things so flawscloud CloudMapper, some tools like that, other free things so flawscloud CloudMapper, some tools like that and then I also helped to organize Forward CloudSec, which is a conference that's focused on cloud security. So I've been actively involved in that, ended up moving from that consulting business to working for a company on their cloud security team and then, in about two years ago, ended up joining Wiz, which is a cloud security vendor.
Speaker 2:So we have O3 Cyber. I used to call you my favorite startup, but I'm not sure if you're a startup anymore, so I won't call you that, and I definitely can't call Wiz a startup who says no to $23 billion.
Speaker 1:I know as an employee that has, I some some stock options that hurt a little bit to you always. You always want an exit, um, but but yeah, hopefully good things to come though Still with that.
Speaker 2:Yeah Well, if you said no, that means you have ambitions for the future. But anyway, boys um see nap. I don't know who wants to start. What does that mean? In 2020, whatever, whatever year? We're in, 2024, 2024?
Speaker 1:Yeah, so I can, I guess, go first and try and tackle this. I guess the quick answer is that it really just means like everything cloud security related all into one product, and so I think like a quick history lesson is kind of valuable. And so the cloud more or less started with AWS in 2006. They released S3 and EC2. And when they released those two things, they worked fairly differently than they do today, in the sense that S3 buckets could be public, but we didn't have even resource policies back then. We had S3 ACLs, which are a more awkward way of doing things. People, I would say, generally more air-prone in a lot of ways.
Speaker 1:And so things progress, more services get added, more cloud providers exist, and then we ended up having this concept called CSPM, and so Cloud Security Posture Management, and so this was a tool, and so I'll talk about, for example, security Monkey. They came about in 2014. They were the first open source tool to be a CSPM. It was released by Netflix, and so what this really does is it basically makes3 bucket policy. So looks at that one thing and, based on the metadata associated with it, determines whether or not there should be a finding. So is this bucket public? Is this EC2 instance public, so looks at kind of like specific things like that.
Speaker 1:And so then we ended up having some other tools that dove into some other areas of kind of expertise. So so we had what's called Keem, or C I, e, m, uh, which is basically looking at your IEM policies and so so a tool that would specifically look at, look at that specific type of problem and try to give you guidance on how do you improve least privileges. Maybe it tells you what has access to what in your environment, and so you had that as like a separate product. And then you also had what's called CWPP, which is Cloud Workload Protection product.
Speaker 3:I'm not even sure what some of these things stand for.
Speaker 1:But this was basically looking at the different compute in your environment so your EC2s, your containers, things like that and it would look at whether or not there's any known CVEs associated with the libraries and applications that are installed on there. And you had kind of two ways of doing this. You had either installing an agent onto all those things or you had agentless, and so in basically 2000, you ended up having this agentless solution ended up coming about from some of the different vendors, and what this would do is you basically take a snapshot of the disk of your compute services that are running in the cloud, and now you can spend as much time as you want analyzing that, so you can look at all the libraries that are installed, you can look for vulnerabilities associated with CVEs, you can look for secrets that are on there, so any type of access tokens or anything like that, you can look for malware that's on there, and you can do all of that one without their performance hit. But then, two, you're able to do this by making an API request to the cloud provider as opposed to having to install the agent. And so, in 2021, log4shell happened, and this ended up being something where that agentless solution became very valuable because log for shell was an easily exploitable problem, and so most people had kind of dedicated their vulnerability management resources towards looking at what are their services that are publicly exposed and making sure that those are patched. But with Log4Shell, anything in your backend could be exploited easily with that vulnerability, and so you really had to look at everything, and one of the problem areas there was if you had any type of vendor tools in your environment.
Speaker 1:As you're using your cloud environment, you start deploying various applications that aren't your own, and so now you don't know what all goes into those other applications. You're just deploying those, and some of those may be running in weird operating systems that maybe your agent doesn't work in or you don't know how to deploy to those other EC2 instances or other compute inside your environment. So the agentless solution really shined when that happened, and then I would say we ended up having some consolidation where some of these kind of expert solutions for example, the Kim solution focusing on IM those startups started getting acquired by different places, or some of the vendors started to integrate those capabilities into themselves, and so now you had these cloud security products that weren't just doing that CSPM aspect anymore. They weren't just making an API call and checking the response. Now they were integrating a whole lot of other capabilities into that. And so for Wiz, we focused a lot on using a graph database, so pulling everything into this graph so everything could be interrelated with one another.
Speaker 1:And, as you and as you did that, now you know, the market or the product vendors decided they needed a new term because they were no longer just a CSPM. They didn't want to say, you know, they don't want to. You know, give you this whole acronym soup of you know, you're a CSPM, you're a CIEM, you're a CWPP, all those things together. So they created yet another acronym, so that was CNAP, which is Cloud Native Application Protection, product maybe, or platform, I'm not even sure what many of these things mean, but basically. So that's what happened. And basically you had a lot of expert tools and they were focused on certain problem areas, and then you started to have this consolidation into having a tool that does all of these things. And so then that's what happened with, I guess, creation of the CNAP term.
Speaker 2:So it's an umbrella term for a lot of everything you described. Yeah, yep, and Håkon, there's a difference between the US and Norway, right, and I would look at you when it comes to, like the Norwegian companies that are embracing cloud and starting to use this stuff which of those 50 billion things that Scott just named is actually being like, utilized in Norway?
Speaker 3:Yeah, I would say most, if not all of the features described are being used. What we see and what we experience is that it's not really like one vertical or one industry that needs this. It's like if you move most of your IT or most of your product or software development to the cloud, some and in most cases all of the features are useful, like if you, if you have some hyperscaler cloud, you have an IDP as a service or multiple, then you start losing visibility, almost even if you're like a 20 person company or a 1000 person company, or in Norway, which is large in Norwegian context but very small in Scots context. So for most, I think you start out with we've lost track of what we have. We need to create some visibility, we need an asset inventory.
Speaker 3:And then you start seeing the fact that we've covered our entire on-premise state with edr agents, but we have none of that functionality in the cloud. How can we make that work in a container context? And then you add on the cwpp features and then maybe you realize okay, we have a tool that has a lot of data. Maybe we can use that tool to start scanning for secrets in memory or we can start scanning for data stored places. It shouldn't be so like the use cases expand by themselves, because it really helps you achieve the security outcomes you're after in at least the cases we see.
Speaker 2:So, basically, if you're using the cloud for your business, these things are just going to be a no-brainer for you. You're gonna you're gonna find the value in them. Is that correct? Because it's hard to export data, basically yeah, well it's.
Speaker 3:It's hard to contextualize that data. To get it is quite easy. Like you, you just scan the same APIs as the C-Map does, but then paying a human to do that regularly and then go through it and look for the misconfigurations and then start seeing a misconfiguration here and an IAM issue here and maybe some data there. That's going to be very costly compared to buying it as a service.
Speaker 2:Why doesn't just Microsoft just do all this? Or why doesn't AWS just do it on their own? Why is there a space for Wiz?
Speaker 1:I think part of the issue is, at least some of the cloud providers like to imagine that no other cloud provider exists. So there's at least one of the cloud providers that holds that view pretty strongly and, as a result, they're never going to make a tool that works with all the other cloud providers and some of the other cloud providers as well. They may not make a tool that is as focused and dedicated on this problem the usability of this issue and so I think that that also is part of the reason as well.
Speaker 2:And would you say, when he's in terms of usability back to your points that there's, you know so many different things. Who uses your types of products Like is it? I can, I can assume like a developer or something that's responsible for infrastructure or yeah, so it's going to be initially usually the cloud security team.
Speaker 1:if you happen to have a cloud security team, if a company is big enough for that, the CISO or some other management wants to start figuring out are we progressing, are we improving, is this actually helping us in some way? And so then they want to see some dashboards. And so now the CISO is looking in the scale of yourself and various other reasons, you start having developers that are potentially part of creating some of the misconfigurations in some way or being responsible for fixing those misconfigurations or other issues. Instead of having the security team relay those problems to those developers, oftentimes you start sending the issue directly to them, so they start going directly back to the product. So now they're looking in there and oftentimes we see that they start understanding more value behind just looking at security problems. Now they're starting to use it for that asset inventory issue or just understanding their environment in some way.
Speaker 1:So you know the cloud security vendors. They don't really focus as much on helping you understand what all your environment looks like. You know what is your network configurations look like. What does access to what? How many EC2s do I have? Or you know other types of questions like that Very easy with tools like this, whereas it can be a lot more difficult if you're trying to do that just with, like, the cloud provider themselves.
Speaker 2:It reminds me a little off topic. I just had an episode with Darktrace, one of the things I know, like the networking guys really love Darktrace because they see their network and they see what's talking to what and it's like it gives them some value in their job. I guess that's kind of like the same. Instead of just pushing telling somebody, hey, come do this in the name of security, but if it gives them value back in their job, then they actually like it.
Speaker 3:I feel often developers and engineers like to build stuff and most of them like to build high quality stuff. They love to do that but to like time pressure and maybe lack of expertise, they might do some mistakes in their day-to-day job and when you can enable them to resolve those mistakes more easily, quicker, better, more efficiently, most of them like that you're solving something for them so they can go back to kind of solving the core business logic problems that they would rather spend their time on, so often driven by security. And then a lot of people start adopting it because, okay, I can use this tool and it can make me more efficient in this security domain I have responsibility for, so I can spend more time on what I might think is more important or more fun or whatever.
Speaker 2:Empowering them Interesting. Is there really like cloud native attacks or is that like a marketing thing?
Speaker 1:Are there cloud native attacks. I mean, in some ways they're like general problems that are just specific to the cloud. So like the classic example of a public S3 bucket. You know, like S3 buckets only exist in the cloud, they only exist in AWS. Therefore it's an AWS problem, but like the general problem of, like, do you have a file share of some sort that is publicly accessible or do you have, like, your firewall being too open in some way is a very similar problem as, like a public S3 bucket. So there are, you know, these cloud native things. But really it just becomes like it's going to be specific aspects of the technology in some way that make it going to be a cloud problem. But as a kind of general problem with the cloud is that in your classic on-prem environment you have a much more controlled ingress to that environment, so it's usually much more easy to identify what is your public attacks exposure. If somebody was trying to scan your IP range or perhaps a single IP address, you'll be able to see what ports are open and identify what those applications are. And oftentimes if somebody wants to make something public, they have to reach out to whoever the firewall admin is and ask them to open up a port in some way, whereas in the cloud it's very easy to make things publicly accessible. It is a single API call in most cases to make that accessible, and so you have what you assumed was your attack surface, and then one day somebody is able to change what that attack surface looks like, and so a single individual is able to do that. There is some ways to have kind of that more on-prem like environment where you do have, you know, somebody that controls the network, somebody that controls what can be publicly exposed, the network, somebody that controls what can be publicly exposed, and so this is especially true with, for example, aws just released this concept called resource control policies, so they just released a new feature makes this a lot easier to implement, but it's still generally a problem there. You also, I would say, have problems of shadow. It is going to be a lot more common in the cloud versus on-prem.
Speaker 1:In an on-prem world, if somebody wants to have their own server hosted somewhere, that means they're purchasing a server, they're deploying it somewhere. That's a lot of work and a lot of effort, but in the cloud, again, this is very quick and easy. Spinning up your own AWS account becomes just punching in a credit card number and you have this server that is out there in the world that you can make public, and so that becomes a lot easier there. But, along with all those problems, it becomes easier in some ways because getting the ability to see everything in your environment when it all is in one of those AWS organizations becomes much easier, much faster.
Speaker 1:Wizz, for example, prides itself on having that quick ability to show value, because once you deploy in AWS and IAM role to your accounts and their similar concepts in the other cloud environments. But basically through some of those APIs, you're able to very quickly get visibility and you don't need to, especially for the agentless solutions. You don't need to figure out how do I install this agent, how do I test this agent to make sure we don't have performance, impact and reliability issues and all these other problems that you may have, and getting sign-off from different teams and your DevOps team who's worried you're going to break things in the environment. So you're able to much more quickly get that visibility and access and be able to see what all is happening inside your environment.
Speaker 2:That visibility and access and be able to see what all is happening inside your environment. So, håkon, how does this look from a security monitoring viewpoint?
Speaker 3:First of all, I agree on Scott's main point and I think the traditional approach of security monitoring is like getting sensors, logs and telemetry from everywhere all the time into some sort of indexable storage and then we have a known set of attacks that we have observed over the years and we have the ability to like, take certain parts of those and put together and then start saying something about are are we now observing malicious behavior? So it's just like log everything always and log it or and ship it to a central storage, which works, but in the cloud that can become very costly. You can consume a lot of logs that are very verbose but have little to no value and actually detecting malicious behavior. So if you try to do the same thing, you'll get no value out of it. Very often I or kind of the the discussion I've had the most about security monitoring in the cloud versus on the premise is people that want a full packet capture of everything on the cloud and cloud network and I usually just say you can try to call microsoft or whoever and try to get it, but and they are like you have the virtual networked app and stuff like how we've done. It does not work and I don't believe trying to make the cloud into on-premise is what we're trying to achieve then then you can just go 37 signals and exit the cloud and be really skilled at on-premise instead. So that's one thing.
Speaker 3:And then there's the dynamic, hybrid nature of the cloud. Your environment changes based on the engineers and the developers, and the environment itself is changing. So the CSPs are adding new APIs, they're adding new API endpoints, they're changing API endpoints, so what you are monitoring for might not be relevant anymore. Or there's stuff you're not monitoring that's very, very relevant. And you have an ephemeral nature of some resources we have in the cloud. They only exist for a very short period of time. Do we need to monitor them the same way as we monitor whatever is long living? And then you have an issue where the cloud service provider isn't necessarily logging what you want. So it's only one year ago Microsoft released their public preview of graph activity logs, so you couldn't see the full API calls towards one of the most important APIs in the Microsoft Cloud ecosystem before one year ago.
Speaker 3:So you get a lot of logs from some sources, which is very hard to do threat detection on, and then they don't log what you actually need. In some cases, and what we experience is many times it ends up being a very bespoke detection environment. So it's the CSPs. Some of them have some detections out of the box. You need to look for this stuff. Maybe they've open sourced it or maybe it's closed sourced within their CM that they're trying to sell you and then you do just detection engineering based on how you know the environment is supposed to be configured.
Speaker 3:So if we see someone calling this API to get this role, there has to be an alert, because that should never come from that principle, for example. So I think it's also quite a bit about traditional threat detection, traditional monitoring. We've been doing that for many, many years and the cloud is much newer than traditional IT, on-premise IT, so we don't have as large of a database of known attacks or attack vectors. So we're struggling also to detect maybe malicious activity that we don't know about yet, that unknown unknowns. So it's a multifaceted problem, I'd say multifaceted problem, I'd say.
Speaker 2:But there's one question I wanted to ask. Both of you like the concept of the detection engineering, looking for a behavior that we know, we have observed and we know to be malicious.
Speaker 1:So that's the same in the cloud and on premise uh, yes, generally, I guess, um, as hogan was saying, is that, um, you sometimes don't have as much capability to have the visibility in the cloud, whether or not the cloud provider chooses to have the ability to log certain things, or whether or not you have the flexibility to filter certain things out, because that could impact. You can have very large costs in your cloud environment if you try and log everything and so when you have things running on-prem, you have, in some ways, a lot more control over that. You know, if you really wanted to, you could do things hooking, function calls and things like that in order to get access to certain areas. You could potentially modify how certain services work if you really really wanted to in that environment. But in the cloud, you are sometimes beholden to what the cloud provider is providing you in terms of those capabilities.
Speaker 1:And another point that Hoken made there was that in your cloud environments, if you're not super familiar with the cloud versus on-prem, you may think like oh, the cloud is just giving me access to some virtual machines, maybe the ability to have a place I can store some data, whereas just AWS, which is only one of the cloud providers they have over 300 services now and over 10,000 APIs across all of those services, so it is extremely complex. They have all sorts of different services, so it's much more complex than people may naively realize if they haven't been using the cloud very much and aren't aware that how much is actually possible in those.
Speaker 2:Does that mean that you have a team at Wiz that has to understand all those 10,000 APIs and all those services and like, what's weird and what's not Is that? How is that actually how it works?
Speaker 1:Yes, and so you know, and going back to the term CNAP, like we have to have experts in all of these different areas. So we have people that focus entirely on CVEs and you know, and making sure the different CVEs are detected, or sometimes the information about whether or not a CVE is publicly exploitable is not, like things haven't been updated. We have to make sure we update that in our product. So we have people that are focused on that. We have people that are focused on just Kubernetes and so just that as a technology. We have people that are focused on just the detection problem, so reviewing cloud events and those logs and trying to determine whether or not there's malicious activity in those. We have people that are just focused on that. We have me.
Speaker 1:I focus only on AWS.
Speaker 1:I don't touch any of the other cloud providers.
Speaker 1:I can't really even speak about any of the other cloud providers in any intelligent way, and so you have at Wiz, you have people that have expertise that is very deep into certain areas, and that's one of the reasons why you pay for product vendors or services is to get access to that expertise, because you probably, depending on your company and business, you probably aren't going to have people that can focus as deeply and narrowly on one very specific niche subject area.
Speaker 1:So, like for me myself, because I focus on AWS, like I read the commits to the SDK every single day, every day. That is like part of my job and that is not something that I assume many other people out like I think there's like two other people I know of that like do this with any regularity and updates to IAM. There's what are called managed policies in AWS. So these are gonna be policies that AWS provides that are giving a certain set of permissions and AWS periodically will update those Again. Like I am manually reviewing those updates to see have they perhaps made a mistake? And historically they were making mistakes. Aws has done a much better job about not making mistakes in those policies anymore and so, yeah, you have people like myself that are like way too focused like to be healthy, on a very niche area.
Speaker 2:You smile a lot for a person that reverse engineers an SDK every single morning for breakfast.
Speaker 1:Yeah, sure.
Speaker 2:So, håkon, with such a big product when you bring this back to Norway, right, where do people start? Do they buy? I would assume they kind of invest in a product like this, or I guess their first. If they only have Microsoft or only have AWS, they'll probably try to look for the native platform and not go for something like Wiz. Is that fair to say, or how do you view it?
Speaker 3:Yeah, as you know very well, Robby, Microsoft Azure has the largest footprint of the three hyperscalers in Norway. So very often it's someone starting out with having looked at or having activated the Defender for Cloud suite based on. They roll out the Microsoft landing zone accelerator, turn on everything and it all starts. Or they just realize that there's a gap and then they look into a scene app it all starts. Or they just realize that there's a gap and then they look into a CNAP. Because one thing I like to say is that the first control, or the first two controls in the SIS version 8 controls is related to asset inventory. But in my career I've never seen anyone actually have a full, updated asset inventory of software or hardware, because there's no ai in it.
Speaker 2:It's not sexy enough so.
Speaker 3:so that's kind of uh for most, I feel, where it starts. So we can't see our vulnerabilities and we can't even tell you what we have. So and the native tooling often, I would argue, isn't good enough at displaying that. And especially when you have it's like there's the azure environment and then some developers has started developing in gke and then you start using some aws services like simple email service and that evolves from there. And then you're like okay, I have this native tooling in my CSP, I can see some stuff there, but they're not very good at the others, and some auditor is asking me what we actually have in the cloud.
Speaker 3:And then it starts from there to get that asset inventory, both of the assets, the software and everything. We have the identities, and from there it's actually being able to do modern vulnerability management. And when I say vulnerability, I'm talking about actual software vulnerabilities and third-party software in packages, libraries, dependencies, it's misconfigurations, it's misunderstandings on what IAM roles actually allow. And then you start getting some pretty or you can start doing some pretty educated guesses on the maturity or the security posture of your environment. And then most people can do some calculations and see if this is more cost efficient than what they're doing today or their risk appetite.
Speaker 2:What does vulnerability management mean in a cloud setting for a company that's like all in on no on-prem, at least?
Speaker 3:for a company that's like all in on, no on-prem at least. It's uh, I would say in essence the same thing. But, uh, you need to have a very like attentive eye to what you mean when you say vulnerability. So if it's any, any, any situation where a malicious actor could exploit some sort of error, it's a quite broad term. But if you're talking about only software vulnerabilities, it's exactly the same thing. But when you start compounding these things like a software vulnerability, a misconfiguration, a misunderstanding, you have a toxic combination where you have an exploitable attack path and you have have a very bad situation in some cases but like a misconfiguration, you say like a toxic combination.
Speaker 2:So a misconfiguration gives them a door in that they shouldn't have, and then they have to do something else to, uh yeah, take advantage of the door being open to do something bad, right? Can one of you explain that in more detail?
Speaker 1:yeah, so. So I guess I guess this goes into kind of the. The value of the c-nap, like that consolidates all these capabilities together, is if you, if you were just to look at some of the different point solutions and, and you know, see the findings from them, you're going to be flooded with, you know, like millions of findings and a lot of those don't really matter that much because you're not taking into consideration the context that some of those findings are in. And so, as an example of like this concept of toxic combination and how we, you know, at Wiz, we prioritize those findings for people, is we're going to tell you, you know, not only do you have, like you know, a CVE associated with a library that's on this EC2 instance, you know, and so that by itself, you know, may or may not be like that big of an issue, because there's a lot of other context to take into consideration, like is that a CVE that's only exploitable if it's, you know, publicly accessible in some way? And what does that EC2 instance have access to in the environment?
Speaker 1:So you may have two EC2 instances with the exact same vulnerability on them, whereas this EC2 instance is in your production environment, so we're able to see that this EC2 is publicly accessible to the internet.
Speaker 1:It has an IAM role associated with it which gives it access to this S3 bucket, and that S3 bucket has sensitive data in it, and so we're going to prioritize that as being a critical issue for you, because this CVE is very easy to exploit and it's going to have access to a lot of sensitive data ultimately, whereas this other EC2, with that exact same CVE associated with it, it may be in your sandbox environment, it doesn't have access to any sensitive data. It's not publicly exposed to the internet in some way. So, even though, yes, maybe you should get around to patching that CVE, eventually it's not going to be as important as this other one. And so what we pride ourselves on is, even though we're able to find all the findings that you know that, you know that other tools you know may be able to find as well we we focus a lot on that prioritization. So, instead of telling you you have 10,000 critical issues in your environment which you know, you tell somebody they have 10,000 critical issues like that. That doesn't help them, you know like either.
Speaker 1:Either that environment is yeah, either that environment is like so horrible that you know like they've already been, you know, hacked a billion times, um, or you know those aren't actually, you know, all going to be critical issues, and so so you have to help them prioritize better, and so what we try to do is is tell people, you know, here here are the dozen critical issues, and they're actually critical. These are actually issues that you know you need to fix right now because, because of all these different things combined, that toxic combination is a problem that is going to, you know, be breached immediately with high impact. And then, and then you know your highs and mediums and lows, like those are going to be where other findings end up in, where aren't, where they're not going to have as great a likelihood of being exploited and the impact of that risk isn't going to be as high as well. So you know, that's how you define that severity is the likelihood times the impact.
Speaker 2:And that defining that severity, and you know how risky any action is. That's why you have so many people in your research team, right, Yep? You have to build that context and that changes all the time. Exactly, that's a yeah, you have so many people in your research team, right, Yep?
Speaker 2:You have to build that context and that changes all the time. Exactly, you have a lot to do at work All these efforts. It's all very customer specific, right? Is there a role for a third party, soc, in this world moving forward, when it's you know, since every environment is so unique and you have all these customized services for your environment, right?
Speaker 3:I think it's a very interesting discussion to be had and I would say there is definitely a role for a third-party SOC or MDR or CDR or whatever you want to call it. Some actors, like Mnemonic and WIS, see a lot of different environments. They can start baselining. They can start understanding what are the specific TTPs towards cloud environments. They can start baselining, they can start understanding what are the specific TTPs towards cloud environments that I, as an end customer, would never have the ability to actually see because I only see my own environment.
Speaker 3:And then we often observe that organizations have a cloud journey and they forget about their internal security incident managers or SOC analysts or whatever it is.
Speaker 3:So they don't really know what the cloud is or what's happening and they need context, they need enablement and they need remediation, guidance and maybe even understanding of what is the kind of underlying issue that's being exploited or attempted at being exploited there.
Speaker 3:So I think it's still like the same effects that goes into play today that allows, like a third party, to security monitor. An on-premise environment is very much still alive and well in the cloud. You just have to do it a bit differently and maybe there's a future where everything that's product, so internal products we develop, that's handled by a sockless rotation of engineers, and alerts from WIS or whatever like cloud detection response engine you have is routed to them or to experts, either internal or external, that can help you understand it. And then the productivity fleet, because we can't forget about that. There's still endpoints, there's still email servers, even if it's a service. There's still PowerPoint sheets, everything that can be very commoditized from a security monitoring perspective. So maybe the MDR SOC vendor is very, very good at detecting malicious behavior in the Microsoft Graph activity logs and SharePoint logs and then you have another solution for your products and software services in the cloud.
Speaker 2:So I guess this is really important to understand what can a third party possibly provide value for us and what is just? We have to fix it with some engineers and some internal people.
Speaker 3:I think for most organizations, that's a conversation they should be having with their third-party vendor already, like what can you actually detect in our environment now that 60% of our stuff is running in the cloud, and what do we need to look for and what might the both of us be looking for right now so we can optimize there as well? For most organizations that are not aiming to become a security vendor, they should be having that conversation with their vendor to help them get better, so you get better stuff back.
Speaker 2:Good insight there. And then what are you guys using your time on? Looking forward.
Speaker 1:For myself personally what I'm working on. I let's see. I'm finishing up some research that I'll publish soon, so I don't want to, I guess, give that away on what that is. But another thing that I'm working on more immediately is so, as I mentioned, aws just came out with this RCP capability, and so I'm working on a blog post related to that to give people some guidance on what I consider to be some cool policies that people can create with that in order to create good guardrails in their environment.
Speaker 1:Started asking about quantum encryption and basically how to prepare for that.
Speaker 1:This is a problem that today, technically, our encryption is safe, but at some point in the future, at some point in time, there's going to be a need to switch over to some other ciphers there, and there's some dates I think it's basically a decade in the future that the government the US government has mandated that people switch over these things, and so a number of companies just want to prepare for that. They want to start getting an inventory of how they're using cryptography currently, and so this becomes a little bit of an issue, because you don't want to just tell somebody all the places in which they're using OpenSSL library, because that's going to be every single compute instance in their environment. You just want to tell someone every everywhere you're using cryptography, so. So I'm working on kind of that problem to give people again like that more prioritized guidance. And when, what is? The things you know that are going to matter that you should be prioritizing and switching over to new ciphers today versus ones you can wait for in the future awesome, awesome.
Speaker 3:What we often observe is like misconfigurations around CICD, gitops stuff. So we are working on an open source tool to be able to detect some very specific things we've seen allow for privilege escalation from pipelines into cloud environments. So expect that soon, and especially now that I've said it publicly. I actually have to get into the coding Just wasting all your time on podcast, håkon.
Speaker 2:Well, gentlemen, I've learned a lot. Thank you so much for sharing your expertise and, scott, I will make sure to follow you. It might be that I ask you to come back on again and, hawken, you're invited on when you finally get around to making that product of yours.
Speaker 3:Sounds good All right.
Speaker 2:Gentlemen, Thank you for having us Take care.
Speaker 1:Thanks, thanks for having us Bye.
Speaker 3:Thank you, you too.
Speaker 2:Well, that's all for today, folks. Thank you for tuning in to the mnemonic security podcast. If you have any concepts or ideas that you'd like us to discuss on future episodes, please feel free to hit me up on LinkedIn or to send us a mail to podcast at mnemonicno. Thank you for listening and we'll see you next time.
