Unraveling Cloud IAM One Role At A Time

Speaker 1: 0:00

How's it going? everyone? This is another security unfiltered episode. So today we have the very first sponsorship episode with Sonarai Security where I talk with their CISO about the product, about his experience of getting into security, what he's been doing, his interests, that sort of thing. I don't want you to think that just because they sponsored the episode, that they gave me a list of questions to ask, that did not happen. This is more of a free flow conversation, like my podcast is, and we just discuss his experience where he's going in security, how he got to be a CISO and everything about the product.

Speaker 1: 0:44

So don't think that this is scripted in any way. It's really not. There actually isn't even any editing or anything like that, and hopefully you'll be able to tell that. So, with that, if you enjoy this episode or want to learn more about Sonarai Security, go ahead and click the link in the description to Sonarai Security to learn more about their offering. All right guys, thanks. I hope you enjoyed the episode. How's it going, eric? It's really good to finally have you on the podcast. I know that this thing has been in the making for a while now. So how's it going?

Speaker 2: 1:19

That's not going too bad today, joe. It's great to be here. It's a bit rainy where I am today, so it's nice to settle in and have a good chat.

Speaker 1: 1:28

Yeah, absolutely So, eric. I like to start everyone off with kind of telling their background right, because I have an audience that is trying to get into security, potentially trying to get into IET, and I feel like hearing everyone's backgrounds because it's so different. I've done over a hundred of these episodes and I haven't heard the same background right, the same journey into security. So what's your path?

Speaker 2: 1:56

So my path actually is. It's an interesting one as well. At the start it's a little almost expected. So I'm a computer engineer by schooling and I was working on my fourth year project in a lab and waiting for some code to compile while looking for a job, like hey, what am I gonna do next? right, and I came across a job posting at a very large multinational organization that doesn't exist anymore for a security analyst. And, to be quite honest, i didn't really read the posting very, very well and I just thought that it was like installing AV clients on laptops and whatever. And I thought well, you know this, you know I was always into computers and building computers and I had this sort of nascent interest in information security.

Speaker 2: 2:39

Now, caveat, this was, like you know, 1998, 1999, i don't know, 2004, sorry time frame And I just clicked on the role and applied for it and I got a call for the role and then they described what a security analyst was And it was. You know, at that time there wasn't a lot of fancy tools, so it was building tools and doing the analysis work, but we had to do it all ourselves. It was all by hand, right. So that's sort of where I got started and that's sort of kind of the typical way you think. You know you got sort of an engineering degree to come on. You do this, but that's where it got interesting. I got into the organization and I started working with different groups within this large company, you know, like the CTO's office that was doing research. And then, you know, we had business units that were also doing security stuff because we made networking gear And I started getting involved in like these other projects that were sort of outside of traditional analyst role. That led me from there into, you know, into a product management, solutions management role where we were doing, you know, at the young age of 20, whatever I started doing security consulting. As part of this business unit We were developing a security solution for customers as a story. I really got to see the business side of that And at the same time I got to leverage my analyst incident response sort of sort of background.

Speaker 2: 3:59

You know fast forward a bunch of years, you know I found myself at a new company doing a new role and sort of was leading security teams And again. So I kind of hop from your traditional path into something else, back into a security leadership, and I did that role for a while and that company merged with another one And then I actually got into doing some M&A for about two years, which was really super interesting because I was able to leverage my IT and technical background to understand that part of the M&A process. I got to leverage my risk management skills that I learned from being a security professional in that broader space And I got to learn a lot about business and the business side of things and really thinking like the business and you really see that in the M&A space. So did that for two years and learned a lot and the deal closed And then I found myself looking for another job And, sure enough, i landed a more senior security leadership role where I was basically the CIO or CISO of a company And so kind of piecing all those things together, you know. Then I got to learn the use my leadership skills and my business skills And I applied them back into the role. We were acquiring companies at that company. So I got to kind of use those skills and say, well, wait a minute, like we're doing the due diligence financially, we're doing the due diligence on the business. Is anybody doing a technical due diligence? Is everybody doing a security due diligence. So then that led to that And I basically then found myself in a CISO role for a company And then, last but not least here, i found myself in a CISO role at a vendor, which is sort of, if you think about it, it's almost full circle.

Speaker 2: 5:37

Almost 20 years later I found myself working security back at a vendor. But at this point in time I really like would call myself with it's a term, i've kind of come up with a field CISO. So I spend 75, 80% of my time working with our customers, working with our prospects, working with the market, working with the industry to help educate, to help solve problems, to do that consulting. So it's it's kind of interesting that I started at a vendor and an analyst role and now I'm at a CISO level at a vendor again, but doing a very externally facing role. So that's kind of how I got to where I am today.

Speaker 1: 6:12

Yeah, it's really interesting. You know when, when you were at that first role and you were kind of creating your own tools, did you later find that that skill set was extremely valuable? And I asked that because you know, a past couple years I worked with a colleague that you know. He did security for the military And I guess in the military, like they nine times out of 10, they don't feel like spending money on a product And so they give over you know, kind of like what they want accomplished to their security people And they say, go build it. And so he built Sims, he built EDRs, he built, you know, everything under the sun. And when I started working with him and he told me his background, i was like wait what you? you built CrowdStrike, like you know, like you built your own version of CrowdStrike and his skill sets was so far beyond everyone else at the company. I mean, this guy knew the technology better than anyone possibly could at that company. Did you feel like that kind of paid dividends for you?

Speaker 2: 7:21

Absolutely, absolutely. Those early days, like you know, there was no next generation firewall. Idses were a basic concept that weren't very good. We built all of that ourselves. We built the analytical tools, we built the reporting tools, we built the dashboards, we built everything, and in doing so it gave you a very good under.

Speaker 2: 7:41

You know, this is the old world, the networking world, right? So this gave you like, yeah, i had the degree in it and I had the theory and the knowledge, but, like you had to get your hands dirty, you had to figure stuff out, you had to break it apart. It wasn't just an alert that popped up on a screen and then you had some runbook to do something with it. You had to think of the logic to find the thing to pop the alert. And then, when the alerts popped, you really knew what they meant because you created them And you didn't have to have, you know, a runbook because, again, you knew you created runbooks because that's the right process to do whatever. And you know then I think about, though, like, individually, it was fantastic, and I, you know, like you got to get your hands dirty, especially in the times you have to get your hands dirty As a leader and as a senior leader. Now what I'm seeing is I'm seeing that we've gotten used to these tools. We've gotten used to, like you know, these types of devices that make it very beautiful and clickety-click, but a lot of people really struggle with that layer deeper. Well, this alert told me this, so we got to do this. What does that mean? Do you know that it's a real alert? Is it a false positive? Why is it real? What's your next step? What's going on here?

Speaker 2: 8:55

And I find that as we get into where we're probably not digging in as much as we should, the whole process tends to get a little muddled and confusing. Sometimes And I really think it's anybody that I talk to that's starting their career or getting into things. It's like you got to dig in, like even as a CISO out of vendor that does set cloud security. Literally before I got on this call, i was doing hands-on work helping to build stuff into our product, and I've been doing that for four years here And that's how I learned to the cloud, like, yes, i can go and talk to the CISO of the biggest airline in the world and we can have a great conversation about strategy and theory and I can work them through it, but nothing gives me more credibility than I can say oh, by the way, this is how someone in your team, four layers down, want to think about writing this analytic.

Speaker 2: 9:45

So from a leadership perspective, i also think it's very important that anybody in this field, or any tech field, really get their hands dirty and understand what's going on. Maybe in your company it's not building a tool, but maybe it's like really digging in to understand what it means. Create a lab, see if you can get a copy of the tool in the lab and get the alerts to fire and see what that means and what are. I'm talking to infosex or that incident response space, because that's where I came from, but the theory applies wherever.

Speaker 1: 10:15

Yeah, you bring up a really good point where and just thinking back on my career, even whenever I had a CISO or a manager that literally did the work, did the hands-on work understood what I was actually telling them, and they understood the complexities and the challenges that I was having, rather than just telling me to get over it or go through it, figure it out. They're right there with me. They're able to say oh yeah, that is actually really difficult. Let's work this problem. I always respected them a lot more than anyone else in leadership. It's because I just felt like they understood more of what I was going through. They understood the nuances that I was working through in my head and whatnot.

Speaker 1: 11:05

And I even had one CISO that would log into our solutions And before all security calls he would log in and see where we are with deploying our solutions and whatnot, and he would grill us on it. Do you know your solution better than I do, because I have to know the entire security stack. You only need to know one. It adds a level of personability, i feel, to leadership that can sometimes be overlooked.

Speaker 2: 11:38

I agree, but I also think it's a bit of a double-edged sword there as well. So, yes, it leads credibility. Like I say, i have to know enough to know to call BS. That's the joke. I say, right, is that real, is that not? Can I ask a bunch of intelligent questions to figure it out?

Speaker 2: 11:55

But what I often find too in this space, especially for CISOs, is that everybody's expecting them to also be the technical expert, and I see a lot of CISOs killing themselves trying to understand all of the technology that they have to understand. And I've been in the clouds now for about six or seven, probably seven or eight years now, and it's a brand new world. And listen, i'll be honest with you, i don't understand the space to near the depth that I did from the 20 years of working in the networking world. But I'm fine with that too. That's why I hire smart people, that's why I trust the people that I work for, and so that's why I say it's a double-edged sword. It's like you got to get to a point as you rise up through your career, if that's what you choose and go into leadership, management and leadership or whatever, or then executive leadership, that you're not going to know it all, and don't kill yourself knowing it all, but just find the people you trust. Do your homework, read up on your things, be very, very knowledgeable in it.

Speaker 2: 12:53

But I think we have to stop thinking of CISOs as always being the super, duper, duper technical expert, because it's not going to happen. It's like you take more established C-suite leaders like a CFO. I've worked for some great CFOs, and where I work now are CFOs. She's amazing. At the same time, she doesn't know the nuance of every little single thing. She has a tax expert and she has a this expert and a that expert And, at the same time, no one is expecting her to be either. So I think in this CISO space, it's something we're sort of working our way through as CISOs, being business leaders or security leaders being sort of business leaders and not always have to be the expert on every single thing, because it's impossible. Like you said, how is anybody going to understand every nuance, every detail of every single piece of their security stack? They're going to be working all the time and just burnt out, and that's what happens a lot of the time.

Speaker 1: 13:52

Yeah, that's very true. It's funny because even when I go to dinners with vendors and whatnot, my contact will tell me ahead of time this is a technical dinner or this is a non-technical dinner. And in the technical dinners it's not like the CIO or the executive that's there is discussing the technical aspects of the product with me, it's their smee, it's the guy that built the product that is talking to me about it, that is able to actually answer all of those questions and whatnot. I'm having more of a conversation, like you and I are right now with that executive at the table And I think that that's an important distinction, and you mentioned it too CISOs and CIOs. They really need to know enough to call BS, but they don't need to know enough to do a reverse shell through SSH and do a server and transfer data to test out the validity of a DLP solution.

Speaker 2: 14:57

They don't need to know how to do that They don't need to know that.

Speaker 1: 15:01

They need to know that it exists, that it can be done, but they don't need to know the command. They don't need to know how to get into a CLI or anything like that. The ones that I find that do it the best, or at least are the best in the role, are the ones exactly how you stated it They know how to do it, but they don't do it Because it adds another tool to their tool belt.

Speaker 2: 15:27

I would think Yeah, exactly, i'm a car guy, i love cars, i know how cars work. In the past I've changed my oil and did all those things. I've got a modern car. I pop the hood now. I mean it's got an engine cover. I got to take an engine cover off just to see the Darnspurt plug. It's like I know enough to know about cars. If I go to the shop and they'll say, yeah, you need blah, blah, blah, i'm like, yeah, right, i do not need that. So thank you. But at the same time I don't then wheel my car out in my garage and tear it apart. It's that analogy, and I just think the reason why I bring this up with CISOs is because we have to start thinking of the role of that as a business leader, and not always just the smartest technical security person in the room. No, they have a team of people that help them with that.

Speaker 1: 16:14

Yeah, that's a very good point. So after you were the security analyst, you eventually moved into a pen tester role. Can you talk to me a little bit about that? Was there? what was the different challenges of being a pen tester compared to security analysts, and were there any similarities? How did you make that jump? Was it more of a logical jump, you would think because of your experience in engineering school.

Speaker 2: 16:43

Yeah, i mean I think the jump is this. So, as an analyst, we talk about blue team, red team, whatever the buzzwords are today. But I mean I'm going to talk what it was back then. You were the blue team or you were the defenders. So, as the analyst, i had to figure out what was going on, and a lot of the times, again, we were the ones making the tools. So we had to almost reverse engineer what was going on at the time. So you ended up doing all these things And then as part of the role it was just part of the analyst's role that again there wasn't this dichotomy of you're a pen tester, you're an analyst.

Speaker 2: 17:17

At that time you were just an analyst And that's what you did. And sometimes you'd be called upon to test your own environment. And because you're building your tools, how better to validate your work than to try to do something that your work's supposed to detect? So it's the flip side of the coin for me. Oh, ok, i got to detect that the adversary would get access to this through this and lateral through this, and did it and did it. Well, on the other side, i would just do the other side of the coin.

Speaker 2: 17:46

I still have to think like an attacker to write the defense. So now I'm just thinking like an attacker and executing what I'm writing. So it's really for me. Was really this flip side of the coin? You still had to know all the stuff either way, and it was just a different approach. Am I the one that's supposed to be looking for the person doing it? OK, well, how do I look for that? Well, then, think like that and then go do it. And, to be honest, i wouldn't necessarily call myself a pen tester in terms of what the term is now, but back then, when I was writing these tools, like as an analyst, you were both a blue teamer and a red teamer and everything else I'm doing.

Speaker 1: 18:28

It sounds very challenging, to say the least, to be in that kind of role where it's so dynamic And security already changes every single day. There isn't the same day out there. It's always changing. You always have to do something new, different, learn new things. But it sounds like that's like a different league of difficulty, so to speak, because you're not just a security analyst responding to alerts. You're creating the tool that gives you the alert and you understand the backbone of why it's alerting and what it's actually doing, and then you're also testing out. You have to generate those alerts somehow, you have to test out and actually create that attack and do those things and then write the playbook for how a blue team would do it and remediate it yourself, make sure that it remediates correctly and all that. It sounds like just a different league almost.

Speaker 2: 19:34

It was just a different time. You know, like there was just what needed to be done. I mean, the only tools out there were rudimentary AV tools. I mean there were firewalls, but I mean they were very rudimentary. I think they were like you know, just like right, so well, it's like, yeah, maciphein, semantech, rear, rear, you to be a b's, and that was it and, and You know, but it was just the time.

Speaker 2: 20:03

But super beneficial, and nowadays you got all these vendors that do all sorts of amazing and wonderful things are. You know, i need to be sometimes, but it doesn't mean people can't do that. I mean you can gain your skills. Like you know, if you're starting as an analyst, i think it's a perfect place to start. You know that's a great place to start and you can go other places. Like you can go into security architecture from there you can go work at a vendor and a vendor. You're gonna get to do a lot of this, a lot of this stuff. Maybe that's a place to start start. You know the junior role of the vendor is this like a security researcher. That's a fantastic place to start.

Speaker 2: 20:42

But again, you know the always the most I think you think best or successful because you know those are a bit you know, but It's just, it just gives you so much knowledge like it just come you know. It's so much better, you know what inside and out, and it gives you such a foundation like, literally, i'm this year, i'm in my 20th year of my career. You know, i've been a seesaw for the last probably eight plus years and i'm at the company working for, i'm doing hands on work and i'm pulling on the foundations of What i've been learning over 20 years, even 20 years ago. It's funny i was thinking about it the other day that i'm doing work that i haven't you know, like this type of stuff that i haven't done in a very, very long time. The technology is change, sure, so i gotta come up to speed on that and i gotta figure out, okay, what does this mean in the cloud and how do i do this or whatever. But the methodology for approaching solving those problems hasn't changed And that stays consistent in security.

Speaker 2: 21:42

And you know you have the fundamentals and you work upon them and if you can truly understand those more than just reading them in your cisp manual or what, pass the test. But you can work with them and be hands on with them. That foundation is the same and you can carry that forward. You know i've been through the. You know pre Next generation firewall stuff and you know when networking and then i was into the next generation firewall stuff when you get into all your Edi are, is that all these other tools that came along and i made this big shift into this, this crazy freaking world we call the cloud, which is flips a lot of these paradigms on their head and just completely obliterate some of them. Fundamentals are the same. Yeah, i gotta learn some stuff, but the fundamentals are the same. I just keep drawing on those.

Speaker 1: 22:29

Yeah, that's a very good point, that the fundamentals are pretty much always the same, you know, and it's how you deploy, it's how you enact them that really differs, you know, depending on the or the environment, what not, you know, you, you've seen a lot of different organizations, especially as a vendor to. I mean, you see everyone, right, what are some of the Security differentiate differentiators across these companies that you're seeing? and i asked this because You know, on paper it looks like everyone has roughly the same tech stack. Right, they have a firewall, it's probably polo alto, maybe Cisco. Right, they have any d r in place, is probably crowd strike. They have a sim in place. It could be Splunk, or if they couldn't afford splunk like many can't, you know, it's something else out there, right, what are you? what are you seeing that is different across these organizations?

Speaker 2: 23:37

So i mean in terms of success, is the security program? is that sort of the basis of what you're asking someone's wondering what makes a successful security program versus another one other than just technology? Yeah, number one is always buying from, you know, real senior leadership, buying from the organization that information security is a enterprise business risk or a true business risk. It's not a tech problem, it's not an i In it problem, it is a true business risk. Any organization that is that has a solid security program or is working towards a very solid security program, it's buying at the top. You know, i think of one of our customers that they made the decision Very large for 50 customer like massive company, very influential in what they do, leading what they do in the market made the decision to go fully data center 22 data centers worldwide. What is the cloud in two years? As part of that decision, they made security one of their top priorities, not somewhere down on the list of all. Yeah, we should probably think about this One of their top priorities. You know they have a fantastic security program in there. You know, in this new world and they're building it up to be what needs to be and everything else. But that's number one. Number two education and training. Every organization that i've either work for these, all these organizations that prospects are customers that i see there is a noticeable difference in the quality of the security program, the quality of the whole thing, from technical to process. Everything The company's actually invest in the education and training of their employees Is fundamental. Again, we talked about it earlier. You gotta learn these things. Where you gonna learn, you know you have to give your people time to learn and you know, right now, in this world where organizations are moving to the cloud, i see that dichotomy even more prevalent Because businesses are leading the migration to the cloud.

Speaker 2: 25:47

It's crazy to me that you know like. I remember my first one. I was at dual cso, cio role and you know my top Use, my, you know my. It later came to me and said hey, boss, we've got this twelve million dollar a year spend on an application sitting in a data center. I can reduce the cost of this by eighty six percent Overnight, or, you know, pretty much immediately. But moving to this cloud, my boss of the time was a cfo and i've never seen a cfo make a technology decisions so quickly. Point being is, the business is driving The migration to the cloud, and tech teams are finding themselves sort of behind the eight ball, and yet their business is expecting that.

Speaker 2: 26:29

I'm a rick and i'm the senior system in, and now i'm gonna be a fancy new title is a senior cloud admin, and you're expected to know it's like no, you just change my title overnight. Does it mean that the twenty years i spent learning on how to be a great system is gonna make me a great cloud admin Again? i can use my fundamentals, i can use my skills. Back to my point, though the organizations that are investing in their employees Training in real ways.

Speaker 2: 26:54

I see a huge difference, and so for people out there that are looking, either within their own organization or looking at maybe getting into this field or switching organizations, those are the questions that i would be asking what, what amount of time do i have for what i call sharpening the soft, for training myself? what budget is there in a yearly basis to do this? can i go to courses? can i go to conferences? where is the room to learn? And even in my own career, like where i started, you know, is a very research forward organization. I mean we built networking gear and telephony gear in the whole deal, so it was research mind. We were given a lot of time and space to learn. We had a fantastic security program. Because of it, you know.

Speaker 1: 27:39

Yeah, one of the very first questions that I ask any company that I interview for is always what is the training budget like? Do people on this team actually get training? Do they get certifications? Because it separates a good security team. A good security team would be a team that gets no training. It's on the job training, which, yes, is good in its own right.

Speaker 1: 28:12

But if you're not getting the additional training you know, potentially from SANS or any of the other great organizations out there that are offering the training, if you're not getting that training, you're really just dealing with someone trying to play catch up that is dealing with these other teams. They're not trying to resolve it forever. They're just trying to resolve it for the next 30 minutes so that they can work on other, you know, higher priority things And that's really what separates them. And you know, from an employee perspective, from an individual contributor, someone that wants to grow their career and is ambitious like myself, i want to see that they can work on that And I think that's a great thing. And I can't just say you know, every partner that I have that wants to grow their career and is ambitious like myself, i want to see that there is training opportunities, that there is growth opportunities, right, that I'm not locked in to one thing for X amount of time.

Speaker 2: 29:11

It just kind of makes it miserable, in my opinion. Yeah, i think at a technical level you know I say training and maybe I bucket that, maybe overload that term you know room to do your room to research with internally. So, yeah, you may have go get some awesome paid training and might go to a course for a week Those things are great and amazing But room to do your work, Like again I think back to my analyst days we were given the room to do the research, right, this new thing came in and and we don't understand it. Yeah, we could probably quickly do this, close the ticket. But like, no, like, let's mock this up, let's figure this out, let's do what we need to do research, research, research.

Speaker 2: 29:52

Richard's, giving your, your employees time to do research and to do those things as part of their roles is also valuable. I think of, you know, i think of an analyst that worked for me for, i mean, almost 15 years And he's gone off to work somewhere else now. But you know he, if you look at his career path, he started as a T, like a low level IT tech, and then he was an IT admin And then he moved into, like a system in the server space any hop to the security space. He was fantastic, like over the years, no matter what the technology, no matter what the thing, because he was given the room to do that and he taught himself and he could figure it out. He was always my best security analyst by far, and even making a jump into the cloud It was. It was the same thing, but the organizations that he worked for before he came to me gave him time to learn and gave him time to do research and stuff like play around, basically, and make it sound so formal. Play around, right, play around in the lab. Give him a lab. Hey, boss, can I get $5,000 budget for a lab? because I want A, b and C, absolutely There you go, you know, and that's why, and so I always gave my team's time for that too, and I really think that that made the difference.

Speaker 2: 31:08

And it makes a difference when you find yourself in a tough situation.

Speaker 2: 31:12

You know in this, in this industry, you are going to find yourself getting that call that you dread. You know, no matter I, and I still remember one of the companies I worked for, where I was, what time it was, what I was doing, who I was with when I got the call. And those people in those situations that know how to do that stuff and have been in the space to do that stuff, like they just stand out heads, heads above, because in those situations you're in a, you're in a, we don't know what the heck is going on. We've got a tidbit of information that usually isn't very much to go on. You probably, you know, it's probably like you know 10% of what you need. And those people that have been given the time to learn and not just go to a course but research and plan labs, they stand out, you know, heads above. So that's also another sort of hidden asset that I've learned along the way of why allow, enabling that is so important And and fostering that that culture as well.

Speaker 1: 32:09

Absolutely. So what are? what are some common challenges that you're seeing across organizations? you know for myself it's probably it has to be I am and and migrating off of solutions that were built in the 90s. You know that is a that's a huge one. But I am, especially when you're going into the cloud. It has so many unique challenges with it, because your I am environment can explode overnight And you not even know what's going on. You know you could have accounts that have the same permissions And I mean there's no warning, there's nothing telling you like, hey, this account is basically duplicated, it's being used in two, two places at the same time. There's lots of you know little tweaks and checkboxes that you need to know as the, as the technical expert on the field. Are you seeing that as well? Yeah, absolutely.

Speaker 2: 33:05

I, you know, if you, if you read any of my blogs or listen to any other podcasts or whatever I do, identity and data securities needs to be at the core of of your cloud security strategy and identity like first and foremost, like what I was doing before I was working on this was literally writing analytics around identity and validating analytics around identity. You know, this shift from the data center of the cloud we used to think of identities as people. Eric, bob, jane, you know, whatever in the cloud you've got this notion of what I call non people identities your computer roles, your service principles, your, all these other things that aren't people. they don't number the number of people identities 10 fold 24. And you know, in the DevOps space, you know there's a lot of developers that are also doing operational work, that don't have an operational background, and so you get these misconfigurations and identities that create these identity chains that allow the user Eric, who's sitting in a dev environment, to hop through different, you know, laterally move through identities, which is sort of the new buzzword in the cloud, rather than move through identities that the user Eric or shouldn't have access to. anything using non people identities can actually get to sensitive data in your, in your, in your production account.

Speaker 2: 34:20

So I think about it in two ways. right, it's like a I use this term a lot the double sided coin. you know, on one side you've got the identities. you have to know what your identities are in that inventory, and I don't mean your 30, 60, 90, 180 day certification process. I mean you have to know all the time what your identities are. You then have to know what their end to end permissions are not just Eric's in this group, and Eric has these permissions. Well, does that permission give Eric the ability to assume an AWS role that can control a piece of compute that can do whatever? So you got to calculate your chain. So what are my you know what are my identities, what are their end to end permissions? What data do they have access to? So here's where the data piece comes in. What data do they have access to? What can they theoretically do with that level of access? So there's your risk. And then the last point is what are they actually doing? That's your incident or not?

Speaker 2: 35:13

And then you flip the coin and you look at the data piece and data sprawling the cloud is crazy. So you first have to ask yourself where is all my data? And I always tell the story of I remember walking into a company. I was a new CSO in the cloud and I said, hey, can you tell me where all our sensitive data is? Somebody got up and one of the smart security architects got up on the whiteboard and drew our architecture and said here's where our sensitive data is. And I said, well, that's great, that's where our data is supposed to be. But can you tell me that it's not there? So you've got to know where your data is. but, more importantly, you've got to also know what your data is. Does anybody care that my blog is sitting on some public folder somewhere? No, who cares? Someone wants to go steal that or deface that. It kind of sucks, but it's not going to ruin my business. So you've got to be able to classify your data and say what is it so we can protect it.

Speaker 2: 36:03

And this is where the identity comes in. You take the data perspective What identities can access me? What can they do to me? And then risk or incident what are they doing with me? And I think again, identity and data has to be at the core of your cloud security strategy, and this is where I spend so much of my time. I mean, i'm in my fourth year here at the company I work for that. we've focused just on that And I still do most of my job as educating, educating, educating organizations around these risks, around these things. And you can't solve these problems without tooling. God love them. I know a company a couple of years ago that tried to map out all their identities and all the end to end permissions using spreadsheets in a boardroom, and after about three or four months they said, hey, we're done. And I kind of didn't have the heart to tell them that you know what? that probably was wrong five minutes after you started.

Speaker 1: 36:59

Wow, yeah, there's a lot to unpack there When you are going through really troubleshooting. Iam issues, specifically in AWS or really any cloud, brings me back to when I was testing for the AWS Security Specialist Certification, and the only way that I could logically figure out how to figure out these problems in my head was by thinking of these IAM questions in reverse of saying what does this person actually need to do? OK, let's take it a step back. What are they actually doing? And then where's the identity at? That was the only way that I could work it, but trying to work that for thousands of identities is an impossible task that you'll spend an entire career on and not be done. So what company are you at right now? Because it sounds like you're dealing in the cloud space, right? What company are you at right now? Where are you guys specializing? What's your bread and butter?

Speaker 2: 38:07

So the company I work for is called SonRi Security. Funny enough, sonri, our founder, is Irish, sonri means data in Irish Galax, and that's what we focus on. We take what we call an inside out view. A lot of the traditional security, especially networking, is outside in. You create your border, you lock it down and you protect the outside in. We take that view of OK, where is your sensitive data After you've done the where is and what is and what are that? And we take the identity view as OK, what identities can access this? And we compute those chains out to show you like OK, of your 10,000 identities in your cloud. Well, you've got problems with this 100 because these 10 users in this group and I'll use an AWS example, but it could be analogous to GCP errors or whatever these 10 users in this dev account group have the ability to assume a role And they can assume that role into, say, staging. But once they assume that role, that role has permission to actually assume and do actions in prod. So, realistically, the end to end or effective permission of all those users in dev have the ability to go put, touch a piece of prod data And that's what it is. So, again, it's identity and data at the core of the cloud security strategy, and that's really where our bread and butter is.

Speaker 2: 39:23

But again, in the cloud, you have to think about it. So those are two pillars. There's four of them that I think about. There's the CSPM, or the configuration of your cloud. Is my cloud configured securely? And that is a pillar you definitely have to think about.

Speaker 2: 39:35

And then workload protection. You've got these workloads, whether it be static or ephemeral, that can have vulnerabilities, and so what we also help to do is we bring all that together and we provide risk and context. And I think about it this way In the cloud, you might have 10,000 spears pointing at you wanting to get you As a security team. You can't deal with 10,000 problems. You need to know right now what are the top two, three, four, five problems, the highest risk things that I need to deal with. So we take that identity and data piece, we add the CSPM, we add the workload protection And we show customers. It's like here's your biggest risks in your cloud that you need to go address now, because that's another, and we could talk for hours on how security teams, especially in the cloud world, are drowning with alert overload And they're just stuck, but that's a topic for another day, i think.

Speaker 1: 40:29

Yeah, it's almost like the cloud is going through what security teams used to go through on-prem with alert fatigue, with just being overwhelmed with the amount of stuff that is thrown at you In the cloud. There's very few solutions that I have found that give you actionable alerts every single time. Pretty much 90% 95% of the time they actually give you actionable alerts. So when an alert comes through, you actually should be paying attention to it.

Speaker 1: 41:03

When it's on-prem or with these other solutions, i guess it's very easy to get lost in these alerts and start to discredit them and kind of write them all off, even the valid ones. Recently, or at least in the past couple of years, i was looking at CSPM solutions to purchase at the company that I was at at that time And there was only one solution that didn't give me garbage alerts. I'm a team of one right, so me managing my workflow, my processes, optimizing my time is extremely important, and it's surprising to me because I didn't spend a whole lot of time looking at it beforehand. It's amazing to me that companies are still catching up to that mentality of let's not overload these people with alerts. Let's give them actionable alerts that they actually want to know about.

Speaker 2: 42:07

Yep, no, it's definitely. You're seeing that. It's like history repeating itself Again, when we created our own tools back in the day. That's part of the reason why we did it too Well, this thing that claims to do what we think we need to do is garbage, and all it gives me is a bunch of crap. It's about context, and I use that term a lot. It's risk in context. You have your CSPM and let's say you have 10 accounts and only one of them is a production account. Do you really need to focus on the other nine accounts? And if they're dev and gross accounts, like Sandbox, they're probably blowing up with alerts. No, what you need to focus on your team of one right now. That's going to help your business the most is the alerts coming from the product account, and then you can do all your work to tune them and get them to where you need to be, because no solution is a magic bullet. But that's it. It's risk in context. And then, when you put these four pillars together, you really need that risk in context mentality And the example I give.

Speaker 2: 43:04

I don't like to talk in theoreticals. I mean, we can think of a real world breach that happened a couple of years ago to a very large financial institution, who will leave nameless, but the gist of it is this They had a VM that was misconfigured to be exposed to the internet. Or maybe it was meant to be exposed to the internet We won't even call it misconfiguration But it was exposed to be exposed to the internet risk. Was it the highest risk in that organization? Maybe, maybe not. Ok, so that VM also had a vulnerability on it. So the other context is now a VM with a vulnerability. Let's assume that that vulnerability was a medium. I like to use this example. So it's like ah, it's critical because of the you know, let's assume it was a medium. Ok, well, that's probably not getting looked at anytime soon, but you've got a medium vulnerability that's exposed to the internet.

Speaker 2: 43:56

So your risk profile starts to change when you take it into context. In this case, that VM with the vulnerability on the internet had an identity because in the cloud your compute can have identities attached to them had an identity on it that had permission to do data, reads data, writes data, data data, data data data, whatever. Ok, that becomes a bit interesting. In its own sphere, i would say that that's risky. Again, it's on the internet with a vulnerability. Your risk profile changes.

Speaker 2: 44:26

Well, the data they could access just happened to be that company's super sensitive data.

Speaker 2: 44:32

So when you put all those four things together, what, in a silo, might have not been the biggest deal to that company, when you put the risk in context, especially with the identity having access to the sensitive data to be able to basically steal it, that's what happened. And so if an organization had the ability to see that in that context, guaranteed red flag should have shot up all over the place or flares should have gone up saying, oh my god, this is the biggest thing we need to deal with. Even if it was a team of one, we'll never know what happened there, but that is a real world example of where risk in context comes into place and why solutions need to be thinking about that, especially in the cloud, because it moves at a speed in the scale that is mind blowing. And listen, i've been doing this 20 years and you thought keeping up in the data center was tough. Keeping up in the cloud is. It's just a new world, like we're all trying to adapt to. How do we do this?

Speaker 1: 45:34

So how does Sonorai security implement that risk assessment into their solution? The reason why I ask is because what you just said is very complex methodology right That humans can go through, but it's very rare to kind of see a computer go through that and make that calculation right. So can we talk a little bit about potentially what goes on behind the scenes to make that risk assessment associated with a vulnerability or an issue that the solution is finding in the cloud? Because, to be honest, from this side where I'm at right Not the vendor side, the purchaser side there's a lot of solutions out there that provide a lot of risk assessments, risk scores right, and I mean it's kind of a crapshoot of if it's correct, if it's accurate, you know, and then it gives you this number. That doesn't mean a whole lot to me, to be completely honest. So how do you add that context around these numbers to give the value to the teams to know to react to something differently?

Speaker 2: 46:48

Yeah, i mean some of it is very, very objective and some of it is very subjective. I mean in terms of, if you look at the vulnerability piece, the workload protection, the vulnerabilities are assigned to CVE. Okay, that's a hard and fast number that we all follow in the industry. Now, every CVE these days feels like it's a nine or a 10, so whatever, but you know, at least that's a hard and fast number. In some other areas, you know, it becomes the context. You know, and we rate things. You know, if an S3 bucket is exposed to the internet, so that's like a CSPM configuration without an encryption turned on, you would call that a high risk, right, and everybody's gonna mostly agree to that. So you know, in these four pillars we classify the risks in terms of high, medium, low information, like the tools, like the nomenclature we're used to. But then again and we use some very advanced analytics, like in the identity and data space, to do this in the CSPM space, we do that, but then we have this other layer of analytics. Well, not just one, but a bunch of analytics that puts it all together. But again, let's take that example I just used Okay, you've got a CSPM, maybe a medium to low risk. You've got a vulnerability risk of a medium, but you've got an identity risk of a critical and when you add the data piece, it's like woo-hoo, like super critical. You know we have analytics that put that all together and provide that context to the user.

Speaker 2: 48:09

The thing about our platform as well is that's also configurable. I mean me being a hands-on person that used to do it myself and then when you got into tools the tools that I hated the most when I had to use them, that didn't allow me to add my own context to things, and so we allow our customers, our users of our platform, to do that as well. So we might throw an analytics in that we'll use the same example and we'll say it's in your org. Holy moly, this thing explodes. The internet with the vulnerability, the data access is critical because that's the way we see it. But any tool lacks is the actual business context. You might look at that and go, oh, i can see how they got there. However, you know what, like that data they thought was really sensitive to us really isn't for this reason. So we'll just downgrade it. So we allow our customers to also up and down dial, if you will, to give them that configurability to do that so that they can tune in the risk to themselves.

Speaker 2: 49:03

But, like any solution, nothing's a magic bullet And it comes back to where we started this conversation about good endless and understanding your environment. That's also the job of a really good security endless, or wherever you find yourself in the security space, is learning to understand how to tune your environment. How does your environment work? What's the business risk to this thing? And then you have to turn the knobs yourself, like anybody else. But we provide the ability to do that, as opposed to just speeding out an answer and saying, okay, take this and run with it, because the tools that did that never lasted in my teams at all. They're like, no, this is not right and I can't do anything, so this is going in the garage. You're gonna find something else with those.

Speaker 1: 49:45

So can you talk a little bit about the roadmap for the solution at SONRI security? What's on the horizon? Is there potential for a solution that has kind of like ML baked in or something that it learns in the environment or potentially even learns across other customers and brings that intelligence in and adjust the risk score or alerts differently because of it? What's coming in the future to really enhance your offer and your customers?

Speaker 2: 50:18

So right now, i mean we do have those analytics and that learning built into our platform and that's always evolving as we go, finding better ways to reduce, to take the complexity of the cloud and the risks of the cloud and make them more consumable by the end user. We recognize and I recognize this that the consumer of these tools might be a junior analyst and they might not have the depth of experience at. So how do you make the results more consumable, how do you make them more easy to understand? How do you help somebody fix the problem? And that's key is how do you help them fix the problem at the speed and the scale of the cloud? And that's really leaning heavily into things like automation, native automation in the cloud, and enabling them to do that. Right now, we're really really heavily focused on that data identity piece uncovering those identity risks, raising them to the top, putting them into context and finding better ways to help customers solve the problems.

Speaker 2: 51:17

Like one example we have is like least privilege. Everybody says you gotta be least privileged. Well, that's freaking great. We've been saying that for 20 years and they were saying that for 10 years before I started, but we have this really great analytic that says okay, here's this again. I'll pick on an Azure service principle, this time as opposed to Amazon, and it's been permissioned this way. And as we get a baseline of that a running baseline, because we see the actions that it's taking, after, say, i'm making a step, say a month, of letting it run, you can actually go in and say, well, this role, we'll tell you that the role is over permission for these reasons, but you can actually use our analytics to go in and say this is what the policy looks like today And we will generate you a least privileged policy based on the baseline that we have to say this is the policy that you probably need.

Speaker 2: 52:06

Your developer went and gave this IAM star. I'm mixing the clouds now, but who cares? Your developer gave this data read, data, data star, everything you can do with data everywhere. Make it up. But in the last 30 days, we've actually seen it do just data update or data check, but we didn't see the delete, we didn't see the add, we didn't see the modify. So the policy you have should actually look like this. So there's a solution. And then we're using automation to say, but we realize that this needs to be deployed at scale. Why don't you click this button? you can deploy this automation in your cloud and it will correct the problem for you. That's a lot of the areas that we're leaning very heavily into right now.

Speaker 1: 52:47

That's very exciting to see what's coming on the horizon. So, eric, i really appreciate you coming on and I'm always very cognizant of my guest time. So, before I let you go, how about you tell me, or tell my audience, where they can find you if they wanted to reach out to you, what the website of Solaris Security is and all that good information if they wanted to find out more?

Speaker 2: 53:13

The best way to find me is on LinkedIn. You'll find I'm very active in that community. I mean, i'm a firm believer. My mentor said this to me many years ago send the elevator back down, and it's something that I've always, always had. So if you have questions or whatever, find me on LinkedIn. Add me, ask me a question To find Sunry. It's S-O-N-R-A-I securitycom. You can find us there. If you have any questions, reach out to us there. And that's really like. We're very active in social and I'm very active in the space as well. So check us out, check out my blogs.

Speaker 2: 53:44

There's a lot of great learning by myself and a lot of my peers at our organization that I feel can really help, and not just in because we sell a product in the cloud security space, but in educating in this new world that we all find ourselves in. I don't see the security community as a bunch of competing even in the vendor space as a bunch of competing communities the people that are actually having to secure the organization. So when I do my inside job, we're all in the same boat And it doesn't matter what company you work for If you work for our biggest competitor, those people inside. I have the same heart and care for them that I do for my own security employees, because we are all in this boat together And we're all gonna have to help each other learn and grow, and especially again in this new cloud space. I think that's really important.

Speaker 1: 54:30

Absolutely Well, eric, i really appreciate you coming on. I feel like we could talk for another hour or two, right, just going in depth with these topics. But again, i really appreciate you coming on And I hope everyone enjoyed this episode.