Marina Segal of Tamnoon

00:08

Welcome to another episode of Modern Cyber, coming to you once again from the sidelines of Forward Cloud Sec 2024. And Forward Cloud Sec is a conference about security of the cloud. And I'm actually delighted to be joined by somebody who has a longer history than me in cloud security, Marina Segal. Thank you so much for taking the time to join us today. Thank you, Jeremy, for having me. It's really my pleasure. And we have a lot to get into on cloud security today. But before we do that, why don't you just take a few minutes to introduce yourself, tell the audience a little bit about your background.

00:38

Sure. So my name is Marina. Right now I'm the founder and the CEO of Tamnoon. Still dealing with cloud security, passionate about this topic. Started my career as a consultant at Deloitte doing different things. There was no cloud back then. Moved into security practitioner role and that's how I got introduced to cloud security. I was an early adopter of Dom9.

01:03

which hired me as a product manager and since then I'm building CNAPP tools, CSPM tools, probably influenced those acronyms at some point and made the mess of the acronym suit that we have in the industry. And later on after we got acquired by Checkpoint, I moved into CISDXOS, spent some time over there and then decided to start my own company. Fantastic, fantastic.

01:32

Those acronyms are really funny to think about over time. You know, we had CSPM and then CIEM and CWPP and for a little while, I don't know if you remember CNSP. Do you remember that one? That I want, I don't remember. But I do remember KSPM and ESPM. And I'm sure we are missing a few. For sure, and I would tell you there's also ASPM, API Security Posture Management. It's really interesting though.

01:59

One of the questions that I kind of have still today is, and I've been looking at this data a little bit recently, CSPM solved a very particular use case. And that is customers misconfigure assets on cloud platforms, right? Classic one is, of course, the S3 bucket, but there's any number of things, everything from RDS instances to even EC2 instance snapshots that can be made publicly accessible, right?

02:25

And so I always felt like CSPM did a great job of helping customers understand the accidental exposures, right? Just what have you configured that is exposed to the internet publicly that you didn't realize? Maybe somebody made a mistake. Most likely, I think people just don't understand all the configuration options, right? How, in your mind, has this space evolved, though? So I think we definitely started with those accidental mistakes.

02:54

it took us also through the compliance journey, right? Because there's a lot of the misconfigurations really related to the compliance and regulatory requirements. And it became about much more than just an exposure, right? Yeah. Is my logging enabled? Do I have all the permissions in line? Over time, we started to have more and more technology that helps us not only to detect misconfigurations, but also

03:21

gain visibility. So what do I have in my cloud? And then over time, the cloud detection and response tooling came in so I can detect events and things that happen. So I think as we are progressing in this journey of maturing our tool set, we pretty much are capable of doing detection and visibility in the cloud. I think we figured it out. We have enough tools.

03:49

And right now we are coming to the place where having all of those amazing technologies, what do we do with them? How do we mature operationally with the humans that are operating these tools and the processes around them? Okay. So how do we, right? Because from the human perspective, one of the downsides of CSPM is that it just generates a huge, you know, to-do list, right? I've got 10,000 issues of various types.

04:18

S3 bucket open, RDS instance exposed, etc. etc. etc. How do you suggest that humans think about taking that data and digesting it and turning it into something useful? It's a very big problem. And I don't think this problem was born with the evolution of CSPMs. We had the same problem in the EDR space. We have the same problem in vulnerability management even earlier than that. Totally. And firewalls and all of the tools basically that we build.

04:48

are generating enormous amount of very useful data and it's about how do we consume it and what do we do with that. So I think us as cloud security professionals, we need to think about what things we need to focus on and how do we go about things we do not need to do anything about. It's about risk management more than anything else. And there are a lot of tactics and processes that we can apply.

05:18

Anyone has figured it out yet. But it's a fascinating journey there. A lot of processes and tools can help us to get there. And when you think about, let's say, the processes and the tools, I think the tools have evolved a lot. And from the standpoint of what is nowadays kind of considered CNAP, let's say you have a basis of infrastructure understanding. You have an overlay of vulnerabilities on various instances. Maybe you have an application catalog on top.

05:48

Maybe you even have application-specific vulnerabilities overlaid into this picture. But the process side of things is the one that is always fuzziest in my mind. Generating the data seems relatively straightforward. You do some queries. You maybe do some follow-up queries. You build a graph. You correlate some items, and so on. But what I've always been curious about is, OK, it's a customer organization. You show up with this pile of data, and you say to them,

06:18

Here's the process for digesting this data. Any ideas, any lessons learned, any best practices for how to get started on that? Sure, I think it's about defining where you are today and where you wanna get. And it depends on which industry you are in, what kind of data you are hosting. A lot of times what helps a lot is understanding the ownership. Who owns which part of your environment?

06:45

And it's a very complicated problem. We can talk hours just about how to solve that problem. Doesn't tagging fix it all? It could. However, we see that a lot of customers, they're not very good at tagging because it's a heavy manual. I'm kind of half joking because I once moderated a panel on tagging. And I had three customers from three very large US companies. And we talked about

07:13

What's the lifecycle of a tagging policy? From the time that we're in a room and we have a whiteboard and we've drawn it all out and we said, OK, we're going to tag everything like this, right? Here's our 10 required tags and five optional and blah, blah, blah. And everything's infrastructure is code, so it should be easy for us to automate this process. We said, how long does that last? And the answers were two weeks, one hour, and as soon as we leave the meeting room, forget about it. Sorry, I didn't mean to interrupt you.

07:43

it's a tool, tagging is a tool, and we still need to have process around it. And with the dynamic nature of the cloud, when assets are coming up and down every minute, you're right, you may leave the room and the tagging strategy that you just defined is no longer viable. A lot of other things that you can do around ownership is understanding your org structures, understanding who owns which account, looking at the logs.

08:09

Cloud trails, API calls, who created that? Who was the last one to touch it? You can also look at the infrastructure as a code or you can ask questions. And the combination of all of this may help you to understand ownership. And even then, you probably would be half way through the understanding, but it's a good start. You need to start somewhere. Another thing that we found very valuable is understanding where your crown jewels are or.

08:38

maybe it's the crown jewels, not everybody would like the term, but basically understanding where are those most sensitive assets? And this understanding can help you to prioritize better. It can help you to understand which buckets you really want to close and which ones are okay not to leave open. Another thing that we found very useful is understanding...

09:06

What are those low hanging fruits that can fix a lot of risk altogether? And starting with those small wings, just getting to the wing goes a long way. Yeah. Because when you're starting your remediation and, and, um, your people, you want to make them excited about the process and you need to get them, um,

09:28

to celebrate those small wins. Yeah, it's a great point. Just organizationally, no one wants to see a never-ending to-do list. But if you see a process that's actually making progress step by step moving forward, that makes a lot of sense. A couple other things that you said there that I think are really important to understand is, number one, we don't actually do a great job as an industry of actually asking questions. We kind of rely, in my experience, we kind of rely on data. And we view data as a source of truth.

09:58

We make assumptions about, well, any human intervention process is not scalable. We can't do it because we have 1,000 cloud accounts, and we have 10,000 assets, and what have you. So we always default to, it has to be automated. It has to be data driven. But we don't often leave room for adding a questionnaire and supplementing the data in our tool with just a questionnaire, maybe even a Google form that

10:28

fill something out and then can kind of correlate that data. And then the second thing that you said that I think is really important to think about is defining those crown jewel assets and understanding where you want to get to. These to me are elements of that kind of risk management question, right? I think no organization can ever be 100% guaranteed, perfect security, no risk of breach, no risk of data exposure. So I think that point about

10:55

you know, well, what is the acceptable level of risk that we want to get to? Do you think organizations who say we're trying to get to perfect, do you think they're just setting up for failure? I don't believe in perfect in general, like in anything that we are doing in our lives. We cannot be perfect. We are not robots. And there is a lot of factors that can not allow us to get there. We should strive to get to a point where

11:24

we reduced enough risk to sleep well in the night, right? Yeah. And it may be too expensive for us to reduce the entire risk. It's not feasible, not possible, and no one needs to get there. Yeah, yeah. What I also think is that defining that success as a short-term success rather than like, where do I wanna be in five years? Yep.

11:48

What I think works well is for us to get those top three priorities every week and focus on them. Interesting, yeah. And become almost like, okay, you don't need to solve the entire risk right now. Yep. Those are the three top priorities for you right now that we want to tackle to get to the next win. Yeah. And then we will figure out what's the next step for you. Yeah. I really like that philosophy. I think in my experience, and I've worked with a lot of organizations over the last eight years on their security journeys,

12:17

I don't think I can think of a single organization where you had the same people in place for five years. So setting out a five-year plan is really, doesn't make a lot of sense, right? And also the workloads change so much over a five-year period, right? You might move, might completely shift database technologies. You might have, I don't know, let's say a social media integration that you kill a year and a half later, but you focus so much time and energy on securing it.

12:44

So I love this idea of the short-term gains and setting a good process moving forward on that side. I have another question that's been bugging me because of something from a previous podcast guest who talked about attack surface mapping and external probing. And their view was that the data you get from testing an environment from the outside is much better and more impactful than the data that you get from the inside. And I've always been.

13:13

Like you, I come from the CSPM space. I've always been on the inside looking out. I'm now working on API security, and we're trying to do a little bit of both and correlate that data to give both an inside out plus an outside in picture. But I'm really curious from your perspective, what do you see as the advantages of one approach versus the other? I do value the external surface approach because it helps us to prioritize better. And yet.

13:42

those what are my top three priorities right now. It also gets a bias of the owners much faster, because when you're coming to them with a holistic story about here is your problem internally, and here is how the external attacker can leverage them, it gets a long way in creating that urgency for the owners to remediate and fix the problem. So I wouldn't pick one or another, and I would...

14:11

really want us to think about how we can correlate. Yeah, yeah, makes a ton of sense. There's another question that's kind of been a hot topic in the cloud security space for a number of years now, and that's automated remediation. If we look across the current landscape, I've probably heard, I don't know, 10 different opinions, and all very strong opinions, by the way. Nobody, I've never talked to anybody who's like, eh, I could go either way.

14:36

Everybody that I talked to has a pretty strongly held opinion about it. So what's yours? Automated opinion. Good. I remediation. Good idea. Bad idea. Full automate is a bad idea in remediation space because, um, you can break stuff that works. Yep. And the moment you break something that works, you are losing this trust of the owners of your customer. And you don't want to be that vendor or that.

15:03

security person who enabled auto remediation that caused a company to lose millions of dollars in sales. So I think we need to think about different way of automating the remediation flows and it's not about the actual action of remediation. It's about how can we automate the operations, how can we automate the decision making and make humans to be involved at the places where we need them.

15:33

to be. I always think about it almost like a self-driving car. When we are driving the remediation process and we are in the driver's seat, there are a lot of roads, there are a lot of conditions that can cause us to just crash. So while we want to have this technology that helps us to automate the remediation, we still need the driver to make the most important decisions in the driver's seat. So we need almost to...

16:00

Think about how we scale the human operations on top of the tools that we have. We'll think about you want to encrypt a lot of different assets in your cloud. How do you make sure as a first step that those are not attached to anything, that those are not impacting anything that is working, right? Yeah. And start with the ones that are not going to impact anything first, remediate that part and then move to the next one.

16:27

But for that process to be successful, you still need human intervention to make the right decisions. So you almost need to build the technology around the humans to make them successful. But this is really interesting, because I could take a different line of argument here. And I'm not sure, by the way. I may be one of those few people who have seen both sides of this. I've also seen customers destroy entire environments using automated remediation that was done poorly. So anyway.

16:57

What you said is kind of like work your way up, right? So it is, if I could boil it down into one interpretation. And yet the counter argument that I might give is if I know what my crown jewels are, I know that these are my production accounts and I'm gonna scope my automated remediation to those production accounts only. And I'm going to pick five use cases that are kind of like written in stone laws that should never be violated, right? So in my production accounts,

17:26

Crown Jewel databases on RDS and Dynamo and my file assets in S3 should never, ever, ever, for any reason, be exposed to the public. And I put in place a remediation rule that if anybody ever tries to make those open, just bang, you know, roll back that change, auto remediate. What's wrong with that approach? Nothing wrong. We are kind of in agreement. We still needed to make this decision. So this is the human input into the? Absolutely.

17:55

decided that auto remediation needs to work only for five assets that are most important in your environment. You still had human intervention there and you had an educated call of the human who is a cloud architect probably or security specialist who decided that auto remediation will only be taking actions on those five. The rest thousands that are surrounding those five are not going to be touched by auto remediation. So that is kind of the...

18:24

combination of human supervision that I'm also talking about. You do need tools and technology to define what are those five. And you do need tools and technology to identify how do I make sure that there are no other five tomorrow that I need to add to this auto remediation. And what happens if API is going to change? How do I adjust my auto remediation? So this is the tango that we need to play with technology in order to make it successful.

18:54

But I do find it interesting that the majority of customers are still uncomfortable with automatic remediation, in my experience. From my perspective, I would actually start from a production environment and a very small set of rules and work my way down, as opposed to starting with low risk environments and kind of rolling out automations there and then working my way up. And I think I look at it from the perspective of the risk management.

19:24

for the organization, because the one mistake in production is worth a thousand mistakes in non-production, especially if we're anonymizing data for use in staging environments and things like that. The actual live customer data in prod is so high risk that that's where I would want to start my automated remediation. I would agree with what was starting there. What I would also think that may be helpful is before you apply anything

19:54

and you would always start post-testing it in your testing environment, right? On anonymized data. And there are ways to get from one environment to another. And even if you are starting with your production environments, there are so many perimeters that relate to it. What about users? Which one do you start with? What about your network rules? So yeah, we can simplify it by saying, let's start there. And...

20:24

apply five most important rules, but it doesn't mean that attackers cannot get to those same assets through a different way. And what we find when we work with a lot of different CNAPP tools is that a medium risk can become critical if you have a combination of problems on the same asset. So yeah, we can overgeneralize, but it's the...

20:49

The devil is in the details here. Yeah, no, and you're totally right. It's not that you have eliminated the risk. You've eliminated one aspect of the risk, and maybe not even that completely, right? So we're coming up to kind of time on the episode, but there's maybe two other topics that I want to kind of get into. One is just talk to us a little bit about what you guys are doing at 10 noon and how you're viewing this problem, because there's so much more cloud in general than

21:17

when either of us probably got started in cloud security eight years back in my case, two is what's kind of the unique view that you have on it with the length of time that you've been working in this space? So I think we came to a conclusion that the space is underserved when it comes to manage offerings. Okay. And because we don't believe in full automation and autopilot for remediation.

21:46

In the end of the day, we have all the technology we need today for visibility and detection in the cloud. The challenge lies in the people's and the process side, and that's where the managed service needs to help the companies who are struggling to retain talent, to hire talent, and help them to take care of their mediation and the operational part of the cloud.

22:12

of the CNAPP space. So Tamnoon is about managed CNAP. And we are building the technology that helps us to provide it in the most cost-effective manner possible in the most scalable way possible. So it's humans powered by a very powerful technology that is built for cloud risk configurations. Makes a ton of sense. And for people who want to learn more, where should they go? tamnoon.io

22:40

Isn't that T-A-M-N-O-O-N.IO? That's correct? All right. Any story behind the name? It's an octopus and a Hebrew intelligent animal that helps you with a lot of hands and chemicals. Awesome, awesome. Well, Marina Segal, thank you so much for taking the time to join us, for taking some time out of the conference to take some time to join us on Modern Cyber. Thank you for your insights, for your years of experience, and what you shared with the audience here today. For anybody watching.

23:07

Stay tuned until the next episode. Until then, please sharing is caring. Like, subscribe, rate, review, all that good stuff. Let a coworker know about the podcast and we'll talk to you next time. Bye bye.

‍