Loading summary
Transcript30 lines
- [00:03]
A
Hello everyone, this is Tom Uren. I'm here with another Risky Business News sponsor interview and today I have with me Travis McPeak. G'day, Travis, how are you?
- [00:13]
B
Hey, great, thanks for having me.
- [00:15]
A
Travis is the CEO and founder of Resourcely, which is a company that makes it easy to safely deploy cloud resources in a way where configurations and policies make it safe so that you don't end up in five years down the track in a huge mess. Now, first of all, Travis, how old is Resourcely?
- [00:36]
B
Two and a half years.
- [00:38]
A
Okay, so my talking about five years down the road of a cloud migration is perhaps apt in that you wanted to talk about remediation in cloud environments. So can you kind of draw us a picture of what it looks like when a company has been heading down the road of a migration or a, a cloud environment and five years down the track and they're looking around and how's the security posture of that environment?
- [01:04]
B
Yeah, so believe it or not, a lot of companies, despite being in the cloud for a long time, are just getting their first visibility solution now. So wiz in particular has done a really good job. People love that product. And so organizations are just getting their first inventory and visibility solution and now they're finding out just the volume of misconfiguration that they have. So all of these kind of cloud settings that they need to go and like somehow fix and make better.
- [01:28]
A
Right, right. So I guess you have a window into your cloud environment which is like a console and then like a command line. I mean, in the past and nowadays you've got something that gives you a sort of aggregated picture of what's going on.
- [01:42]
B
Exactly, yeah.
- [01:44]
A
And so then is that what's driving them to think about how do we secure this stuff and clean it up? That visibility?
- [01:52]
B
Yeah, so visibility first. I hear numbers from thousands of cloud misconfigurations that folks have to clean up. Tens of thousands and even more. Any of those things. I think many companies think, okay, we'll just auto remediate in practice. They typically don't because any of those cloud configuration changes might cause an outage. And so auto remediation is typically same for very, very low traffic, very high impact cloud misconfiguration. Also the way that auto remediation is done today is typically via cloud API. It doesn't play nice with infrastructure as code. And so if you auto remediate something and that thing was defined in something like terraform, then you have immediate drift and you can end up with what I call a bot fight. Where your CSPM remediates terraform remediates that. And so you get this kind of like back and forth loop.
- [02:41]
A
Right. So cspm, cloud security, posture management. And so that's some sort of system that'll go and try and fix things. Right. Is that the takeaway for an UPTI like me?
- [02:51]
B
So typically it's above all, it will call all of your cloud APIs and give you an inventory and visibility and then it has rules out of the box that will tell you about misconfigurations that you have. Now. The numbers actually sometimes look worse than they are. For example, these solutions don't have context about whether an open bucket is accidentally open or whether it was your marketing micro site. So some of the quote misconfigurations might actually be completely benign and they don't have the context to know that. So kind of step one is you have to go and collect information because these are so it's such a slow process at times. What I've seen organizations do more than they probably should is draw a line. We're going to fix all of the criticals, maybe like most of the highs and then we're going to leave everything else alone. Just because the back and forth and remediation process can be so slow and painful and disruptive for developers.
- [03:43]
A
Yeah, so I guess that leaves the logical question of well, what's a better way then? I mean to me that sounds logical, right? You go high critical. What other metric can I use?
- [03:54]
B
Yeah, so I have a whole gripe track about this. I think CBSs, it's a good starting place. But again that lacks context. So for example, if you had a CVSS 10 in a sandbox environment, that actually might not be as bad business impact wise as a medium if it's in your front door proxy. So I think in lack of context cvss, you compare one to the other just based on number is kind of good enough. But typically what we want to do first is collect some of that information about what are these things? So who owns it, what app is it associated with, what kind of data does it deal with? All of that context is kind of step one. And then based on that in resourcely we have context driven policies. So now you don't have to have one blanket policy that applies everywhere. You can say we have this rule in prod and we have a more permissive rule in test or we have this rule for any data that touches EU citizen data and we don't have that everywhere else in the infrastructure. So with that you can actually Cut out a lot of the kind of non actionable remediation, just things that didn't need to be done. And then step two, you really want to make this easy for developers. So it's not that developers don't want to do the right thing and fix infrastructure, it's that one, they often don't get enough guidance about specifically what to do and how to do it. And then two, any of those infrastructure changes might be breaking, it might cause an outage. And so from a developer's standpoint, it's not a good value proposition for them, like they'd rather ignore it. It might break if they do it. And so our better way of doing it is make it just dead simple. So we'll take developers directly to the line of code and show them what options they have to fix it. But we also give context about like what kind of change are we dealing with here? Is it like a completely benign no op, it won't do anything, it'll just fix the setting? Or is this the kind of thing where unbeknownst to you, it's going to actually like delete your database and create a new database? Because infrastructure changes can cover both.
- [05:45]
A
Right, right. So I'm seeing a picture of where you've got developers who know how to develop but don't necessarily know how to manage a cloud environment, which is fair enough, why would you expect that? And then you've also got a cloud environment that's kind of shifting under their feet in that things change, APIs change, systems change, and that people have been learning as they've been going. So you've got this long heritage of technical debt that you've built up. But understanding all that context, I would have thought that that to me sounds like a very painful job for a person.
- [06:20]
B
Exactly. Yeah. That's the point. That's why when organizations try and deploy a tagging strategy and backfill that when they didn't have it before, it's very painful. You have this bootstrap problem. It's like, okay, well who do we even go and ask about the infrastructure? So you can get some clues if you're using infrastructure as code. Like maybe the person that touched the repo last could be the owner. Maybe the person that review could be the owner.
- [06:44]
A
You're following the breadcrumbs through the maze.
- [06:47]
B
Yep. Yes. Once you get that kind of bootstrap problem, then you can go, and if you have the right owner, they'll know about their application, they'll know what kind of data they're dealing with their up and downstream dependencies. So taking that information and then storing it back as metadata that now you can programmatically use ends up being quite valuable in itself.
- [07:05]
A
Right, so that's what companies are having to do now. Is that sort of tracing the breadcrumbs through the maze?
- [07:12]
B
Exactly. I've been through two cycles of that at different companies and it's extremely painful. Oftentimes you don't get to 100%, but it involves just ton of manual work. Right. It's like, okay, let's make a big list of all the infrastructure that we don't know anything about. Let's go and manually check the repo and see if we can figure out who might own it, reach out to them and ask them. And so one of the goals in Resourcely via campaigns, which we're releasing this month, is to automate a lot of that manual process. So go and create the way that people can give context back and then once they've done that, now selectively apply like what policies actually matter to them and what should they do about it, and then hand walk them through exactly how to fix it and show them whether it's safe.
- [07:52]
A
Yeah, yeah. Okay, so that's. You're not proposing to automate everything, right? You're saying you'll automate a lot of it and that just makes it easier for people to step through that process. Is that what I'm understanding?
- [08:06]
B
Exactly, yeah. There is some automation that you can do yourself. So often, let's say that you have a property and you want to upgrade it. So we know that the property value A is bad, that's going to cause whatever data leakage or too much cost or something. But there's other options for what the user can pick. So B, C and D are all valid. We could assume B and just migrate them to that. But what we do is present the user with exactly those options and explain when to pick which. If the right answer is just fixed, it's like, okay, it can't be A, it always has to be B. Then we can just create PRs and somebody can still review it if they want, and those just get deployed.
- [08:44]
A
So by the time this podcast comes out, you'll have rolled out, you're calling it campaigns. So that'll be something that people can just pick up and use and that'll help them remediate the technical debt that they've built up over the years. How do people try it out?
- [08:58]
B
So we have self service. You can come in today onto our website and sign up for free with any kind of OIDC account. So that would be step one. From there, campaigns is still gonna be gated to customers, but if you request an upgrade, we're happy to give that to you. And then we have kind of two options. One is very low touch, you don't have to integrate anything. We basically give you some sample data and show you exactly how it works. And then if you want to actually use it in your own environment against your data, we'll have very detailed instructions. It's not a ton of work, but very guided walkthrough on how to set it up. And because we're security conscious founders, we've done this in a way where customers data never has to leave their environment. So that's what the setup's for.
- [09:39]
A
Right. And so this is really aimed at people who have realized that their cloud environment is a bit of a mess and they want to do something about it and they're willing to spend a little bit of time to figure out what the right thing to do is, rather than just the simple dumb thing that appears attractive but may not be the right or the best option. Is that the way that you would sort of pitch this?
- [10:03]
B
Exactly. If you do the math on how many cloud misconfigurations you need to fix and you think about the time to go and file Jira tickets, track developers down, how many of those are going to get fixed in a reasonable timeframe? Oftentimes teams in that position think, wow, this is a lot of work for us. And so the whole point of Resourcely is offload. The grunt work just guide developers both in our current product and, and campaigns. It's how can we just make this stuff just very simple and easy for developers? I think too much in security we tend to do things that are annoying and obstructive for developers. And the whole point of us is what if security was actually a business enabler and we let developers move faster both for setting up things and then now with remediation.
- [10:44]
A
It also strikes me that doing something like what you've called campaigns, which is going back in time and trying to fix things, mistakes or misconfigurations that have happened in the past, it's both a business opportunity for you, but it also must be tremendously painful. Do you wish you were in a world where Resourcely just existed from the beginning?
- [11:07]
B
Yeah, I do. One of the things that comes up again and again with customers since the beginning, if you use Resourcely, what we say is the point of us is to stop the bleeding. So from this day forward, things are going to be well configured and they're going to do so in a way that's fast for developers. Those developers don't have to go and ask an expert for help and wait until they get around to helping them. But something that just came up all the time was, okay, great, we have this big existing pile of brownfield misconfiguration. How can you help with that? And so campaigns is our answer for that. It uses the same guardrails, the same policies, and it actually assists developers in cleaning those things up and buying down the security tech debt that you have.
- [11:46]
A
Well, Travis McPeak, CEO and founder of Resourcely, thank you very much.
- [11:52]
B
Thank you. Thanks for having me.