Upwind CSO Rinki Sethi on Tackling Cloud Security Challenges in Runtime Environments
Rinki Sethi, chief security officer for Upwind, dives into the cloud security challenges organizations securing runtime environments.
Transcript
Hey guys, thanks to Throw. We're here with rinky. Sethy is newly appointed chief security officer for Upwind, and we're gonna have a little chat about what's going on with cloud security.
Rinky, welcome to the show. Thanks for having me, Michael. Thanks.
You've been around the block a couple of times From your resume, it appears that you've been at Twitter and a few other places over the years. Um, from your perspective right now, it seems like we're having some sort of seminal moment here in the transition cloud security, but what's going on and what attracted you to join the company? I just joined Upwind Security.
Um, it's been about four months. Um, and it's interesting, I met Upwind back in 2022 when they were just getting started. Um, and it was the very first time, um, that I had heard the word runtime security, um, and I thought it was gonna be another buzzword or something like that.
Um, and it was when the CEO Ami Ramad shared with me, like, rinky, you can't do security, right unless you're in runtime. And up till that point, like a lot of cloud security, I feel was driven because of compliance requirements that you needed to have in the cloud that you need to make sure that you have some kind of tooling that's gonna ensure that your configurations are right, that you're getting the right kind of reporting out of it, and you are still seeing that there were massive attacks happening in the cloud. Um, and now having gone through many, many cloud secure, uh, cloud transformations at companies, um, it, it becomes really noisy as you're implementing tools and yet you're still not able to catch the tax as they're happening.
And I became a true believer of you can't get security, right unless it's at runtime. Unless you have something in runtime, you need to understand how, what is happening within your applications at real time. Um, and so I heard this the first time back in 2022, kind of followed the company and followed the product.
Um, one of the products that we were using at the time ended up getting acquired by another company. The quality went down and it was time for us to go do a POC and look at different solutions. And so of course, upwind was in the running in addition to a lot of other, um, products.
And the tech just blew me away. Uh, and um, when the opportunity came to join the company to help them build, it was a no-brainer. And so here I am and, um, I think cloud security is shifting, um, quite a bit.
And, and you have to be there, um, in runtime. And I think when we think about what's gonna happen with AI being introduced and kind of this future where we're gonna have agents talking to agents within the security, um, uh, security vertical, you were gonna be reliant and be absolutely dependent on having tooling and runtime to be able to have, then those agents have access to that to be able to make better decisions. It also seems that cloud security environments are getting more complex.
We're seeing so-called cloud native technologies, containers and Kubernetes alongside virtual machines and serverless and who knows what else is in there. And to your point now we'll see AI workloads, have we reached some sort of inflection point here with a complexity is just greater than what our legacy platforms can keep up with. It's it's so true.
Um, and you know, when we think about like securing cloud native AI workloads and like you said, it's like how do you secure containers and data pipelines and models, and then how do you be like, how are you do, are you dynamic in terms of ensuring that you have monitoring of your runtime behavior? And so it's security to a whole different level and environments are be becoming highly complex. And just because you have these ephemeral systems or that you have these instances that are coming up and down, it doesn't mean that you just ignore security around them.
'cause we've seen time and time again that the attacks are still happening and, and they're able, since the attackers are now leveraging ai, um, and have more complexity in what they're able to leverage, they're able to then get in really quickly, learn your environment quickly and, and behave accordingly. One of the things about UPW is it's an early adopter of this transition to EBPF, um, which is kind of core to the whole runtime story. How much of that EBPF is out there, because I, as I understand it, it requires kind of the latest versions of Linux and maybe we'll see it on Windows one day soon.
But, um, where does that fit in the overall strategy? I Think upwind was really an, or it, in fact, I had not, again, I had not heard about EBPF until I met upw. And UPW was a really early adopter of eeb EBPF, um, using it to deliver like really, really deep runtime visibility without trading off any kind of performance or context.
Um, and it actually made, its such that they could build these sensors that were extremely lightweight. Um, and so I think it's like super. Um, and then, you know, you saw like after that, um, more companies started leveraging EBPF to build their tech and it kind of now has become a little bit of a buzzword, but really it's kind of changed the way that sensors behave.
Um, like how they do system calls, um, how they just, uh, monitor container behavior in real time. And it's, um, really changed kind of, uh, how agents work because agents and sensors had like a very, it's almost a bad word with security practitioners because of the heavy weight nature of it. But with eeb PF it's just, um, it's, it's changed the way that sensors behave.
And I, I'm a true believer that you do need to have sensors or agents in your infrastructure to have full context and, um, even though that's like a hurdle sometimes to get through with engineering teams because you are sitting in their production environment. So, um, I think like this is this kind of a game changer. We've been debating this whole thing around application security now with a hard tilt towards the notion of shifting left and maybe getting developers to take more responsibility for application security, but I can't help but wonder how practical that really is.
So what's your take on this whole shift, left versus shift right kind of conversation that we're trying to have these days? I think you need a little bit of, um, I, I like it's, it's, it's hard for me because like shifting left, um, is is always been res like important. Even when we're thinking about things like cloud security, it's like how do you, how do you uh, get closer to DevOps to how do you get closer to engineers to do the right things upfront?
How do you actually make it easier such that it's kind of like just built into, um, security's built into the infrastructure and security's baked in. And so we've been working really hard at that pushing developers to take on more security responsibility earlier in the life lifecycle. Um, but without the right tools and support, we've seen that like this can really backfire too.
Um, and so to me, I think like it's not optional. We do still have to fix fi, we still do have to shift left. Um, but you can't like just dump security onto engineering without guardrails.
Um, so I think that's really important. Um, but then on the shift right side too, um, it gives you context. Um, and so you're, you're shifting left.
You're giving more to developers, more tooling to make sure that you're thinking about security, but then you still wanna be scanning and doing the right things on the right side. Um, so I don't think it's like, and it's like remember back in the day we was like, it's prevention versus detection and then we started going back to, well, detection is a form of prevention actually. And so like you can't, it's not one or the other.
I do really think you have to think about both. One of the other things that's also come up is, um, how much authority should security people be given to fix vulnerabilities? 'cause developers will argue, well, we should fix the vulnerability.
'cause you might break things. However, the developers will then say, we don't have time to actually fix the vulnerabilities. So, um, is there a role for security people to be more proactive about taking responsibility for maybe fixing some of the vulnerabilities without any help from a developer?
It's, uh, it's funny because it really depends on where I think security teams sit and what the accountability levels are. Um, and so if you have a sec, and, and again we have um, like division of access for a reason, right? And so if you're gonna now gonna have the security teams that are governing the systems also have access to fix it, is that gonna be the right separation of duties that you need?
Um, that's question number one for me. But also I think a lot of times securities teams don't have, we're you we're doing the scanning, we know we can even provide them now with AI product products we can provide back to the developers that have access to that infrastructure and system. And here's exactly what you need to do to fix this.
A lot of the tooling actually has, now they have the capabilities to auto remediate and nobody wants to do it. So like can security teams just press a button and say, go fix it? And then who's responsible if the infrastructure falls down as a result because there wasn't proper testing and things that were done.
Um, and so I think there is a process and a lot of change control that goes into remediation. Um, and that's why it takes companies so long sometimes to fix some of these vulnerabilities is because there's other, you need to test it in the right way. If something falls over, you need to go fix those issues before you go fix the vulnerability.
And so, um, I mean, can teams do it? Sure. But then is your infrastructure so resilient and is it built in a way that it's not gonna fall over?
Um, so I do, I do think there's a maturity that needs to happen and I hope we move to this world where, yeah, like we just press a button and things can remediate. So what's your best advice to organizations as they kind of look at all of this in the age of cloud security? Because even 10 years out, I feel like they're still struggling.
A lot of them, it's not even the tech, it's the processes that seem to be different and they're trying to move things that they did on premise in the cloud, but it doesn't really work. So how do I get to something that feels like truly cloud secure? 'cause people still list as their top a number one issue for not moving the cloud secured.
Yeah, I think that when you're thinking about cloud security, you do have to bring a different mindset, right? Completely. Because you're now putting like the spin up of infrastructure in your developer's hands.
It's no longer the same way that we used to architect applications. And so you do have to think about cloud just security in a completely different way. Um, I think that the number one thing that you wanna focus on, yes, you build things with guardrails and you kind of set the right, um, standards, but at the end of the day, you have to be in runtime.
It's why I'm at upwind right now is because they're the ones that focus on runtime first. Um, and it was a hard decision at the time to make right, because you still do have to solve for regulation, regulatory requirements and compliance. You do have to have the posture management piece, um, which all the products have now, but it's the runtime security piece of it I think is focused on like where the attacks are happening.
And I think like from there, build out your program around cloud security. This is the only way I think we're gonna stay ahead. It's the thought leadership and like how people are thinking about this needs to change.
Um, there's still, I think it it, this is why I love being here too, because I think there's still a lot of education that needs to happen around what is runtime, why do you need to care about what's happening right now, right this second in your infrastructure? Um, and so I think that's a really, really important piece. And then like what we talked about earlier, I actually like the way you asked the question too.
I think it's a shift left plus shift shift, right? When you stop having the versus, it's like you do need to think about end to end how you're securing your cloud. Is there something securing people should be doing about having a conversation with software development teams about security?
Then we'll change their mindset. 'cause a lot of times they're like, well, security is a, maybe somebody else's job. B I'm in a hurry.
I gotta do all this thing c you send me a bunch of vulnerabilities to go fix, I go look for them. And turns out they're not running in memory or the application's not internet facing. And there's this tension that exists between developers and security people and has been there for a long time.
How do we kind of get beyond that? You have, we have to reframe security as, as a dev. Like this is a dev problem.
Um, and that you have to secure code when it's being written, not weeks later, not to review, not post breach. Um, I think you have to make it personal as well. Um, and so, and what I mean by make it personal is like I think if you just say, oh, look like that company was breached or this is what happened, like, they'll be like, oh yeah, yeah, but we're better than that.
And so the best way to do this is bring the data to them, like do a red team attack and show them how easy it was to get into the code. Like into their, you know, to have an attack or to have a breach or show them that a data exposure that can happen with the code that they've written or the infrastructure that they've stood up. And I think then it's like, oh my gosh.
And it's like, how long did that take? And it's like five minutes from a red teamer. Um, or that you found it through a pen testing.
'cause a lot of times we do, what we do is we do these pen tests, then we look at all the issues, we file tickets and have people fix 'em. There's a missed opportunity there on saying like, if this was done by an attacker, like going and driving the education on what could have happened to the company and why this could have been prevented so, so easily. And so I think winning the hearts and minds of a developer starts with kind of like show them what an attacker could have done with the work that they've done.
Um, actually it's, it's interesting you asked that because like right outta college, I was trying to find my passion into cyber and it was exactly that. I I, I was a developer, I was a computer science engineer, and I was like, I can't, I can't figure out why I am in cybersecurity. And where I found it was my, one of my first roles was to go and train developers on cybersecurity.
And I realized like reading the oasp top 10 to them wasn't resonating. Their eyes were glazing over. And it was like, how do we teach security and win the hearts and minds of developers early on to understand?
And, um, I brought a company in that was like thinking about that differently at the time on saying like, let's just have 'em ha hands on, teach them how to hack and like teach them how to like break their own stuff. And it, it immediately people were like, oh my gosh, I get it right. Can we have a unified approach to cloud security?
'cause a lot of folks are convinced that each of these platforms are fundamentally different and I can't really translate the things that I know for Google over to Amazon and vice versa. Or can we really centralize this because there's people out there who are dubious. Ideally, I wish we could centralize it.
And I think that a lot of companies are working, uh, towards like building a platform that can give you very, uh, basically give you the same thing that you would see in, in go GCP or AWS or your on-prem environment. Um, unfortunately we're hearing about like some of these companies being acquired by other large companies and there's a question on is it gonna be like, are they gonna bias us more heavily towards that particular cloud? Um, I do think there's, uh, you know, like right now tools are fragmented, right?
And so you have like all these acronyms, CAP and CSPM and CM or DSPM, um, and every company is trying to say like, let's try to build this into one platform. I know like up when we have a platform that covers everything. Um, and I think it's like really important again, like up when started with runtime security, um, and realize very quickly we need to go build CSPM.
We need to go understand identities across workloads and data and network. And without that, people are gonna have all these fragmented solutions, which is what exists today. And so now companies are trying to say like, we have to build this into one product so that companies don't operate this way.
And I know as a practitioner how I had to have it that I cared about runtime security, I went with upw, I needed other products to like help really kind of scale out. And then, oh, now you're like stitching products together to understand your security, um, posture. And that's actually why I joined UPW is because I wanna like change this dynamic with customers and like, how do we really go and build the platform that people need or security leaders need where it is one platform because I think it is chaos today, Was that one thing you see organizations still doing out there that from a cybersecurity professional perspective just makes you shake your head and go, folks, we need to be better than that.
When ai, I, I forget it was like early last year, it's been, it's been a while now, but like, it was like the start of everybody talking about AI and then every security leader was like freaking out, including myself, and you're like, okay, they're gonna ask me what we need to do around safety and security. And then the buzzwords came out like every security vendor LA came out and like was using, um, security LMS and like, here's how we're doing like AI security. And it's like, wait, are you solving for security using ai?
Are you solving AI security? What is going on? Is this LL like, and there was all these questions and you saw these like security leaders that went and like bought these niche solutions and made some vendors like really, really successful.
And then you realize like that's actually a feature in a product. And I think this is why the chaos exists. We as security leaders need to go and like push to actually have products that are solving big problems.
Otherwise we have these chaotic environments where, uh, oh, now we have this feature, somebody else is building it into their platform. Um, and we're just like creating this environment then that like needs to be stitched together. And I, I think that things are changing right?
Quite rapidly. Um, and I would say like one thing we need to look at as security leaders, um, and is that let's re-look at our programs completely today such that like, how is AI gonna impact what the future of this team looks like? Because we want our practitioners to make sure that they're going to have incredible rules and careers in the new AI world.
And that, are we making sure that we're investing in the right tech and then in the right training and skills for our teams? Because I think everything's gonna change in the future here. All right folks.
Sha heard here, there's more change than ever in the land of cloud security and for that matter, security in general. The only issue is how proactive are you gonna be about responding to it? Hey, rinky, thanks for being on the show, Michael, thank you so much.
It was a pleasure. All right. And back to you guys in the studio.